最近我把开发主力切到了本地跑模型用 DeepSeek Harness 搭了一个 Coding Agent专门干一件事用标准模式让 Agent 直接写一个带 GUI 的小游戏。整个过程从环境搭建到游戏能玩大概花了一个周末的碎片时间中间踩了不少坑也摸清了本地 Agent 的工作流怎么调才顺。这篇就把整个实战过程完整拆开讲讲包括为什么选标准模式而不是推理模式、Harness 怎么装怎么连本地模型、以及用 Agent 从零开发 2048 小游戏时提示词怎么写、代码怎么审、报错怎么丢回去让 Agent 自己改。内容偏操作向适合已经跑过本地模型、但还没正经让 Agent 干活的人参考。1. 核心设计为什么是“本地 Coding Agent 标准模式”1.1 Coding Agent 和普通 AI 助手差在哪普通的 AI 助手是“问你一句答你一句”你复制代码、粘贴回编辑器、运行、再把报错复制回去循环往复。一次小改动可能都要来回好几轮做个小游戏能折腾半天。Coding Agent 不一样。它不只是对话而是拿着任务去规划、读文件、改文件、执行命令、看输出、自己判断下一步。相当于你给它一个工程目录和一个目标它在里面自己干活干完了叫你验收。中间的具体过程你可以全程看着但不一定需要你每次都手动介入。我用的 DeepSeek Harness 就是干这个的。它本身是一个本地工作流框架支持把大模型包装成一个能调用工具、读写代码文件、执行命令的 Agent。关键点在于它完全跑在本机模型推理、文件操作、命令执行都在本地完成不需要把代码上传到第三方平台。这个区别很重要。做一个带界面的小游戏代码量不大但迭代频繁——加个颜色、调个布局、修个按键冲突每一版都要改文件跑一次。如果用在线助手的问答模式光复制粘贴就能把人搞烦但用 Agent你只需要说“把数字的颜色改成暖色调”它就自己找到绘制逻辑、改掉、运行给你看。1.2 为什么选择标准模式大模型现在普遍有“标准模式”和“思考模式”的区别。思考模式有时叫推理模式会在回答前生成一段内部推理把问题拆解清楚再给结果。听起来更聪明但实际用下来有两个问题一是慢本地模型尤其明显一个问题要先“想”几十秒甚至几分钟二是 token 消耗大而且往往会在简单任务上“想太多”给出一堆不必要的封装。标准模式就是我们熟悉的直接生成模式输入提示词模型马上输出结果。没有中间推理过程速度快、输出稳定、token 开销小。在 Coding Agent 的场景里标准模式其实更合适。因为 Agent 的工作方式是多次迭代每次只做一个小改动。这种小改动不需要深度推理它需要的是快速、准确地按上下文要求生成代码。你让 Agent 改一个游戏的计分逻辑它不需要“深度思考”算法本质只需要照着现有代码风格把计分函数改对。我用的是标准模式来做整个 2048 小游戏的开发思考模式只用来做需求拆解就是让 Agent 先帮我梳理功能清单真正动手写代码全部切回标准模式。这样整体节奏快很多每轮迭代基本几秒到十几秒就能看到结果。标准的“快”和“确定性”是本地 Coding Agent 做 GUI 开发最需要的素质因为没有耐心等一个改背景色的操作都要推理三十秒。1.3 本地部署的选择理由聊到本地肯定有人问用在线 API 不是更快吗确实如果你用的是云端大模型 API推理速度通常比本地家用机器快尤其在跑大参数模型的时候。但本地部署有几个不可替代的优势。首先是数据安全项目代码不用离开你的电脑对一些不想外传的个人项目或实验代码来说这是硬需求。其次是成本API 按 token 计费做 Agent 开发时会频繁调用一天下来可能跑几十万 token长期用不是小数目。本地模型一次性投入硬件成本之后无限用。最后是可控性本地可以随时换模型、调参数、改提示词模板完全不受平台策略影响。当然本地部署也有门槛。主要就是硬件要求跑稍微像样的模型至少需要 16GB 内存最好有 8GB 以上显存的显卡。如果没有独显用 CPU 跑小参数量模型也不是不行但速度会慢很多。我自己的机器是 16GB 内存加一张 8GB 显存的旧卡跑 7B 量级的量化模型基本能流畅对话生成代码的速度大概每秒十几到二十个 token对于一个逐行输出代码的场景来说是可以接受的。如果你打算跑更大参数的模型建议先确认显存是否够用或者用 Ollama 跑 CPU 版本的量化模型先试试水。2. 环境搭建从安装 Harness 到连接本地模型2.1 硬件与软件准备开始之前先把环境清单理清楚。我当前的环境结构是这样的操作系统Windows WSL2Ubuntu 22.04显卡8GB 显存驱动已装好本地推理服务Ollama用来跑模型Agent 框架DeepSeek Harness跑在 WSL 里为什么用 WSL2因为 Harness 在 Linux 环境下跑工具链更省心而且和 Docker 配合更好。如果你直接在 Windows 上跑也不是不行但文件路径、命令执行、依赖安装这些地方多少会有些别扭。Ollama 的安装在 Linux 下一个命令就搞定curl -fsSL https://ollama.com/install.sh | sh装完后拉取一个支持代码生成的模型。我用的是 deepseek 系列的一个 7B 量化版本ollama pull deepseek-r1:7b注意这里有个坑deepseek-r1 默认是带思考模式的生成时会先输出一段推理过程这会让“标准模式”跑不起来。如果要用标准模式需要在模型配置里把think关掉或者在 Harness 的生成参数里禁用 reasoning。还有另一个思路是直接拉一个不带思考能力的模型。这里我选择的是在 Harness 里配置时明确设置不启用思考模式。不同的 Harness 版本这一项的配置位置不太一样但语义是同一个关闭 thinking / reasoning 开关。2.2 安装 DeepSeek Harness安装 Harness 的方式取决于你下载的是源码包还是发行版。从官方仓库克隆源码的方式比较灵活方便后续跟踪更新和改插件git clone https://github.com/deepseek-ai/harness.git cd harness pip install -e .安装完执行harness --version能正常输出版本号就说明装好了。我用的时候最新版本已经到 0.2.x但网上很多教程还在讲 0.1.x 的用法两个版本在配置格式上有差异看教程时留意一下版本对不上。如果你想固定用某个旧版本直接从 Git 切到对应 tag 再安装即可git checkout v0.1.5-rc.2 pip install -e .装好之后建议先跑一遍harness doctor之类的自检命令。它会检查依赖是否完整、模型服务是否可达、配置文件是否能正常解析。这些检查能帮你提前暴露很多环境问题省得后面开发到一半才发现某个依赖没装。2.3 配置供应商与模型连接Harness 本身不直接推理它需要连接一个模型服务。Ollama 启动后默认监听127.0.0.1:11434同时暴露一个 OpenAI 兼容的 API 端点地址是http://127.0.0.1:11434/v1。这个端点很重要因为 Harness 的供应商配置就是按 OpenAI 兼容协议填的。我在 Harness 的配置文件里这样设置llm: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 api_key: ollama model: deepseek-r1:7b reasoning_effort: none注意reasoning_effort: none这一行这就是把模型切成标准模式的关键。如果不关掉即使你用的是 Harness模型每次生成还是会在内部走一圈思考流程速度和输出格式都会受影响。配置完成后先跑一个简单的连通性测试比如让 Agent 执行一个“输出 hello world”的任务。如果配置有问题Harness 通常会在这一步就报错最常见的错误就是“尚未配置 AI 供应商或未授权使用本地配置”。这个报错说明配置文件没被正确加载或者供应商名称写错了回头检查一下配置项的大小写和缩进就好。如果一个供应商满足不了需求还可以配置多个供应商比如一个本地 Ollama、一个在线兼容 API开发时按需切换。这个功能在 Harness 里叫供应商管理还挺实用。3. 实战开工用标准模式开发 2048 小游戏3.1 需求拆解给 Agent 一个“好骨架”让 Agent 干活最忌讳的是一上来就丢一句“给我写个 2048”。模型虽然能生成代码但生成的代码大概率结构混乱、功能残缺。正确的方式是先帮 Agent 把需求拆成清晰的模块。我让 Harness 先把需求拆一遍提示词大概长这样请帮我把一个 2048 小游戏的需求拆成功能清单按“核心逻辑”“界面渲染”“交互控制”三个维度分类每个维度列出具体功能点。很快 Agent 给出了清单我直接基于它继续开发核心逻辑4x4 棋盘初始化、方向移动、方块合并、随机生成新方块90% 生成 210% 生成 4、判断胜利出现 2048、判断失败无可移动方块界面渲染4x4 网格绘制、数字颜色映射、分数显示交互控制方向键监听、重新开始按键、退出按键这个清单看起来简单但它决定了整个开发的边界。没有这个清单Agent 很容易把代码写成一个大类里面堆一堆函数调试和扩展都困难。有了这个清单我就能让 Agent 按模块逐个生成每次只聚焦一个维度。拆完需求后我建了一个专门的项目目录snake-2048/让 Harness 在这里面工作。3.2 让 Agent 动手第一次生成的代码我选择了 Python Tkinter 作为技术栈理由很简单Tkinter 是 Python 标准库自带的 GUI 框架不需要额外安装依赖生成代码后可以直接运行。如果用 Pygame还要装依赖、处理图形渲染对 Agent 来说多一层出错概率。第一轮提示词是在 game.py 中实现 2048 的核心逻辑。棋盘用 4x4 的二维列表表示提供 init_board、add_random_tile、move_left、move_right、move_up、move_down、can_move 和 get_score 这几个函数。不要写 UI只写逻辑部分用 print 简单演示移动效果。这里特意让 Agent “不要写 UI”是因为先把核心逻辑跑通是最重要的一步。如果一上来就 UI 和逻辑混在一起运行出错了很难判断是逻辑问题还是渲染问题。Agent 生成的代码结构大致是这样的import random SIZE 4 score 0 def init_board(): board [[0] * SIZE for _ in range(SIZE)] add_random_tile(board) add_random_tile(board) return board def add_random_tile(board): empty [(i, j) for i in range(SIZE) for j in range(SIZE) if board[i][j] 0] if not empty: return i, j random.choice(empty) board[i][j] 2 if random.random() 0.9 else 4 def merge_row(row): res [] i 0 while i len(row): if i 1 len(row) and row[i] row[i 1] and row[i] ! 0: res.append(row[i] * 2) i 2 else: res.append(row[i]) i 1 res [0] * (len(row) - len(res)) return res def move_left(board): global score new_board [] for row in board: merged merge_row(row) gained sum(merged) - sum(row) score gained new_board.append(merged) return new_board def transpose(board): return [list(row) for row in zip(*board)] def move_right(board): reversed_board [row[::-1] for row in board] moved move_left(reversed_board) return [row[::-1] for row in moved] def move_up(board): transposed transpose(board) moved move_left(transposed) return transpose(moved) def move_down(board): transposed transpose(board) reversed_board [row[::-1] for row in transposed] moved move_left(reversed_board) moved_reversed [row[::-1] for row in moved] return transpose(moved_reversed) def can_move(board): for row in board: if 0 in row: return True for i in range(SIZE): for j in range(SIZE - 1): if board[i][j] board[i][j 1]: return True for i in range(SIZE - 1): for j in range(SIZE): if board[i][j] board[i 1][j]: return True return False逻辑怎么验证我让 Agent 生成一段简单的自测脚本模拟向左移动的输出。跑一遍看结果发现基本正确。唯一的问题是从右往左移动时分数计算多了因为sum(merged) - sum(row)在反转行上计算得分时重复计了一次。这是后话调试部分细说。3.3 核心逻辑实现细节2048 的核心难点其实就在“移动合并”这个操作上。任何方向的移动最终都可以归约成“向右”的变体。看到 Agent 生成的代码用了transpose和reverse的组合这个思路是对的。左移对每一行做压缩合并右移每行先反转左移后再反转回来上移矩阵转置后左移再转置回来下移矩阵转置后反转左移再反转再转置这个技巧的核心在于只需要写一种方向的合并逻辑其余方向靠矩阵变换复用。代码短出 bug 的概率也低。我当时检查这里的时候专门确认了一件事transpose返回的是新列表而不是原地修改。如果 Agent 写的是原地转置原棋盘会被破坏一整局游戏都很难调试。另一个关键点是“同一行只能合并一次”。比如[2, 2, 2, 2]左移后应该是[4, 4, 0, 0]而不是[8, 0, 0, 0]。Agent 生成的那个merge_row用 while 循环、按索引跳跃的方式实现遇到相同就取两个并跳到下一对正好满足这个规则。这里值得点个赞。分数计算我后来也做了调整不在merge_row里算而是在move_left里比较每行合并前后的总和差值差值就是这次移动新增的分数。这样统一由一个入口计分不会重复累计。3.4 GUI 渲染与交互核心逻辑跑通之后第二轮让 Agent 加 GUI。这轮提示词是基于 core.py 中已有的 init_board、add_random_tile、move_left、move_up、move_down、move_right、can_move 函数在 game.py 中用 Tkinter 实现图形界面。要求4x4 网格用不同颜色显示不同数字方向键控制移动显示当前分数按 R 重新开始按 Q 退出。不要让逻辑代码和界面代码混合界面类命名为 GameApp。Tkinter 的界面代码其实不复杂,Agent 生成的版本包括了这些核心点用一个Canvas绘制网格和数字bind_all绑定方向键事件每次移动后重绘棋盘游戏结束时弹窗提示其中有一个细节容易出错方向键的绑定。Tkinter 里方向键的 event keysym 是Up、Down、Left、Right不是WASD。Agent 第一次生成时用了Up这种写法运行起来居然不响应按键。排查后发现是绑定写法少了尖括号修正为canvas.bind_all(Up, handler)就正常了。我还让 Agent 加了一个小节合成一个“移动后判断游戏是否结束”的函数。因为 2048 的结束条件是“棋盘满且任何相邻格子都不相同”不是简单的“没有空格”。如果没有can_move这类判断游戏会在棋盘满后直接卡住按方向键没反应体验很糟。4. 调试与反馈Agent 协作中的真实问题4.1 运行报错怎么丢回给 Agent本地 Agent 开发的日常流程是改代码、运行、出问题、把报错丢回给 Agent、Agent 自行修复。这里有一个实践技巧报错信息一定要原样贴全最好再附一句“期望行为是什么”。比如这样回复 Agent运行 game.py 后报错TypeError: move_left() missing 1 required positional argument: board。期望结果按左方向键后棋盘向左合并并新增随机方块。请修复。Agent 会对照代码找出问题。多数情况下这种错误是因为调用处传了多余的self参数或者函数签名不一致。这类修复对本地小模型来说不算难但前提是你给它的是清晰的反馈而不是“代码有问题你自己看”。4.2 逻辑 Bug2048 合并次数问题的 Debug 过程我遇到的最经典的一个 bug 是右移的分数重复统计。也就是前面提到过的move_right里先对行反转然后调用move_left计分move_left内部又计算了分数两次计算叠加导致一次右移加了两倍分。这个问题如果自己看代码需要一点时间才能发现。但把现象直接告诉 Agent 就好解决了连续按两次右移分数增加的量是实际合并分数的两倍比如合并两个 4 得到 8分数却加了 16。请检查分数计算逻辑。Agent 很快就定位到问题出在move_right复用了move_left的计分逻辑。修复方式是让merge_row只负责合并不负责计分所有方向的得分统一在GameApp.key_handler里计算也就是只在 UI 层调用方向函数时算一次分。这个 bug 也说明了架构的重要性如果 Agent 一上来就把逻辑和 UI 写在一起这种问题会非常难修。好在拆分得早改动只在几个函数之间两三行就搞定了。4.3 界面卡顿/无反应的排查另一个实际遇到的问题游戏运行几分钟后界面突然不响应键盘事件了。排查过程是这样的先怀疑是键盘绑定被覆盖了检查bind_all没问题再怀疑是事件循环被阻塞看了代码发现add_random_tile后有额外的循环打印日志到控制台阻塞了 Tk 的主循环。是的Agent 在调试阶段留了一行print(board)在移动逻辑里。如果不加限制每次移动都会往 stdout 输出棋盘,导致界面线程卡顿。解决办法是加了一个DEBUG开关DEBUG False def move_left(board): # ... if DEBUG: print(board) return new_board这个开关在开发时打开游戏运行时关闭非常实用。Agent 自己也能理解这种模式因为提示词里写一句“用 DEBUG 开关控制调试输出”它就照做了。4.4 常见问题速查表把这次实战里遇到的和朋友交流时提到频率高的问题整理成一个速查表问题现象可能原因解决方法报错“尚未配置 AI 供应商或未授权使用本地配置”配置文件里的 provider 名称写错或配置没被加载检查配置的 provider 字段是否和启动参数一致确认配置文件路径正确调用模型时报 400提示 thinking 相关错误模型接口不支持 thinking 参数或标准模式被关闭后仍传了相关字段在配置里把 reasoning_effort 设为 none并确认模型服务版本支持模型响应很慢一条代码生成要几十秒本地模型太小或显存不足或模型在跑思考模式切换标准模式尝试更小的量化版模型检查显存占用Tkinter 界面按键不响应键盘事件绑定写法错误或事件循环被阻塞检查 bind 语法移除阻塞主线程的打印或耗时操作生成的代码有 API 调用但没装依赖Agent 只写了代码没加依赖清单提示词里明确指定“只能使用标准库”或让 Agent 一并提供 requirements.txt想退回到旧版本的 Harness新版本配置格式变了或插件不兼容从 Git 切换到目标 tag 后重新 pip install -e .5. 把标准模式用出高级感工作流经验5.1 提示词里的“上下文契约”用 Agent 开发了一段时间后我最大的感触是提示词不是“说清楚要什么”就行而是要建立一个可维护的上下文契约。什么意思就是让 Agent 在一个会话里始终清楚“当前项目的状态、已经完成的部分、下一步要做什么”。我的做法是在项目目录下建一个CONTEXT.md里面写清楚项目技术栈Python 3 Tkinter只用标准库文件职责划分core.py 是逻辑game.py 是 UI当前完成的功能清单已知的问题和待办事项每次开始新一轮开发前把CONTEXT.md的内容作为系统提示的一部分喂给 Agent。这样即使中间隔了很久Agent 重新读取上下文时也不会“失忆”。这个习惯帮我省掉了大量重复解释的功夫。5.2 一次开发会话的控制手法标准模式的 Agent 生成速度快但也容易“自作主张”。比如我让它修复一个 bug它可能顺手重构了整个函数结构导致其他部分出错。控制这个问题的方法是把任务拆小一次会话只干一件事。我在一次会话里通常只提交一个目标“实现 move_left 函数”“添加分数显示”“修复右移分数重复计算”如果同时让 Agent 做三件事它往往会在中途迷失优先级产出质量明显下降。这不是模型笨而是标准模式没有深度推理来帮你取舍多条指令它只能线性地逐条执行。所以指令越单一输出越稳定。另外每次 Agent 改完代码后我都会自己跑一遍哪怕只是简单运行看结果。本地 Agent 写小项目已经能省很多力气但完全撒手不管还不行至少在当前阶段人工验收还是必要的一环。5.3 适合本地 Agent 的模型配置体验最后说说模型本身。这段时间我试过几类不同的本地模型配置感受差异挺大。不带思考能力的 7B 模型响应速度快标准模式下几乎感觉不到延迟写简单逻辑、改界面都很流畅。缺点是复杂任务容易“一本正经地胡说八道”比如生成一个与现有代码风格完全不匹配的实现。带思考模式的大模型分析能力强但默认跑起来很慢。只有把它配成标准模式后响应速度才会回到可用水平。量化位数的影响观察下来 4-bit 量化在 8GB 显存上跑最流畅代码质量也比 2-bit 好很多。如果显存不够建议优先降参数量而不是降量化位数。我的建议是如果只是做小游戏、小工具这类目标明确的编程任务选一个 7B 到 14B 的模型用标准模式跑性价比最高。真要解决架构设计或疑难 bug再切到思考模式慢慢分析。最后再分享一个小技巧。本地 Agent 跑 GUI 程序有一个天然优势程序崩溃了你不会影响任何线上服务可以随意让 Agent 反复试错。所以遇到代码跑不通别急着亲自上手改把报错和期望行为丢回去让它多试两轮。很多问题它自己改着改着就通了你要做的就是保持耐心并且把每轮的报错信息收整齐。这也是我这几周用 Harness 做本地开发最大的心得把 Agent 当成一个需要明确交代任务的实习生而不是一个全知全能的神用起来反而顺手得多。