模型下水之后：Harness 决定它能游多远

同一颗模型，换一套壳，表现会像换了一个物种。

凌晨两点，我盯着一份 agent 的运行记录。

它读完了文件，改了 compatibility 层里的三行代码，跑测试，红了。第二次它换了条命令，还是红。第三次，它把同样的命令原样敲了一遍。到第十四次，它停下来，输出一句 command failed，然后问我：要不要继续？

我往上翻，发现测试脚本把真正的错误吞了。退出码、stderr、当前目录、最近一次通过的 commit，全都不在工具返回里。模型拿到的只有一句话：失败了。它像被蒙住眼睛的人，站在一间不知道多大的房间里，摸到一堵墙，就以为那是门。

我们太容易把这类时刻算在模型头上。可在那份记录里，模型没换，任务没换，换的只是壳递过去的信息。

做 agent 的人给这层壳起了个名字：harness。模型之外，负责把它和世界接起来的那部分运行时。循环、工具、上下文、权限、编排、扩展接口，都算。2026 年 7 月，一篇解剖了十一个编码 agent 的论文把它拆成七个子系统，顺手给了一个很短的公式：Agent = Model + Harness（arXiv:2609.00006）。

模型的分数决定它能不能看懂，壳决定它能不能做完。

一、它看见的世界，是你拼出来的

Anthropic 的工程团队做过一个长时 agent 的实验，任务是从零搭一个可用的 Web 应用。他们很快碰到两个难看的失败：模型总想一口气把整个应用写完，写到一半上下文满了，留下一个半成品；或者项目做到后半程，新进来的会话看到已经有不少代码，直接宣布完工。

他们的解法没有多神秘。第一个会话只做初始化：列一份可验证的功能清单，建一个进度文件，留一个干净的 git 提交。后面的每个会话进来，先读进度和 git log，跑一遍基础测试，再从清单里挑一个功能做。做完，提交，写进度，离开。

功能清单用 JSON 存，每一条都有描述、操作步骤和一个 passes 字段。模型可以改 passes，不能删测试。这个约束听起来很土，效果却比一大段“请认真完成”的提示词好。JSON 的结构比较硬，模型不太会随手把它改成一锅粥。

这套东西里，最值得抄的是那份交接笔记。

上下文快满的时候，harness 会把前面的对话压缩成一段摘要。摘要最容易写成流水账：读了哪些文件，跑了哪些命令，改了几行。下一班真正需要的，往往不在这些里面。

我现在会让 agent 留四段：

## 现在在哪
当前分支、最近一次通过的提交、正在改的文件。

## 已经确认
哪些假设被验证过，哪些测试是绿的。

## 走过的弯路
试过但失败的方向，以及失败的原因。

## 下一步
一个具体的动作，最好带文件路径。

“走过的弯路”最值钱。没有它，下一个会话会把上一个人踩过的坑，原样再踩一遍。上下文压缩省下的是 token，交接笔记省下的是命。

二、报错信息，是写给模型看的界面

写工具的人常把错误信息当成日志。对 agent 来说，错误信息就是它下一步的输入。

我见过不少工具，出错时只回一个 500，或者一句 command failed。模型拿到这句话，只能猜：是命令不存在，是权限不够，是工作目录错了，还是测试真的挂了？猜错一次，就多烧一轮 token。

好的错误信息有四个要素：发生了什么，在哪里发生，原本期望什么，下一步可以试什么。比如：

exit code: 1
cwd: /repo/packages/compat
command: pnpm test --filter compat
stderr: TypeError: Cannot read properties of undefined (reading 'version')
hint: 最近一次通过的提交是 4f2a1c9；可先运行 pnpm install 检查依赖版本。

这段东西不优雅，但它把模型从迷宫门口领到了第一个路口。

工具的名字和描述也在提示模型。run_command 这种名字，等于把整个 shell 塞进一个黑盒；拆成 read_file、edit_file、run_tests，模型的动作空间会清楚很多。描述里写清楚“这个工具会修改文件”“这个工具只读”，模型在选工具时就少一点赌博。

工具数量也是一个容易走偏的地方。那篇论文里，十一个 harness 的内置工具从 1 个到 109 个都有。数量本身不说明问题，关键是模型能不能在正确的时候想起正确的那一个。工具太多，提示词里塞不下，模型会在目录里迷路；有些 harness 干脆把不常用的工具藏起来，等模型搜索后再加载。像进一个巨大的仓库，门口先给你一张目录，别把一万吨货全倒在地上。

三、权限是在画行动半径

Agent 的手脚是工具给的，边界是权限给的。

权限太松，一次 rm -rf 就能把一下午的工作抹掉；权限太紧，agent 会变成每隔三十秒举手的小学生，人成了它的输入设备。两种都难受。

我喜欢的默认值很朴素：可逆操作放行，不可逆操作停下来；读操作宽一点，写操作窄一点；网络默认关，需要时按域名开。删文件、改数据库、发文章、推远端，这些动作应该让 agent 先说明它要做什么，再等人点头。

审批弹窗也有讲究。只写“是否允许执行该命令”，人只能凭感觉点“是”。写清楚工作目录、影响范围、能不能撤销，人才知道自己在批什么。一个负责任的 harness，会把爆炸半径写在按钮旁边。

Codex 在权限上做得很重：策略规则、审批复核、操作系统级沙箱，一层套一层。Claude Code 则把 hook 挂在工具调用的前后，让团队可以把检查、审计、格式化塞进生命周期。路径不同，目的相近：让 agent 知道边界在哪，别等它撞上去再骂它。

四、会失败，才算真正开始工作

长时 agent 最难的部分，是让它在一段很长的时间里，持续做对小事。

Anthropic 记录过两种典型失败。一种是贪多，想在一个上下文窗口里把整个项目做完，结果留下一地半成品；另一种是过早宣布胜利，看到项目里已经有模有样，就说“完成了”。第二种更隐蔽，因为它的输出看起来很自信。

他们的对策不复杂：每轮只做一个功能；每轮结束前提交 git、写进度；下一轮先跑基础测试，确认没把房子弄塌，再动下一块砖。还有一步很关键：让 agent 用浏览器自动化，像用户一样把功能点一遍。代码层面的测试绿了，不代表用户真的能点开那个按钮。

一个成熟的 harness，会在 agent 说“完成”的时候，自动跑测试、看 diff、截图、检查控制台。我把这类机制叫绊线。它不负责让 agent 更聪明，只负责在 agent 自我感觉良好的时候，拉一下它的衣角。

绊线要早，要硬，要能重复。等 agent 写完一篇“已完成”的总结再去验，成本就高了。

五、四种壳，四种水质

这几种壳，气质差别很大。

Claude Code 像一个被产品化的工作台。hooks、subagents、权限模式、会话恢复，接口一层层露出来，适合把 agent 嵌进团队流程。它的思路偏向“给你一套可组合的零件”，用不用得好，看你怎么装。

Codex 像一台带安全舱的潜水器。操作系统级沙箱、审批栈、AGENTS.md，先保证不把船凿沉，再谈速度。它对“agent 能碰什么”这件事有一种工程上的执拗。

Kimi CLI 和 Qwen Code 更像开放的终端工具。Kimi 把 agent swarm 做进了 CLI，Qwen Code 沿着 Gemini CLI 的骨架长出来；skills、MCP、子 agent，社区想接什么就接什么。模型便宜、壳轻，适合自己改。它们的优势在于迭代快，代价是很多东西还没有沉淀成稳定约定。

DeepSeek 的姿势不太一样。2026 年 10 月 17 日，V4.1 Flash 的发布说明里有一句话很值得玩味：新模型针对 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 等平台框架做了优化，在多个 harness 下达到新的性能—费用帕累托最优。模型厂开始为壳做适配，壳厂开始为模型做路由。两边正在互相塑形。

那篇论文还有一个判断：harness 正在从工具变成平台。SDK、插件市场、跨 harness 的元编排层，都在冒出来。对普通用户来说，这些词有点远。它们背后的变化很近：你选的不再只是一个模型，你选的是一整套让模型干活的方式。

六、换模型之前，先问五个问题

如果你正在挑一个 agent 工具，或者准备把现有的流程接进去，可以先问五个问题。

它断线之后，下一班能读到什么？ 有没有进度文件、提交记录、未完成清单？还是只能从零开始猜？

工具报错时，它拿到的是判决书，还是地图？ 错误信息里有没有位置、上下文、下一步？模型能不能自己从失败里走出来？

哪些动作可以直接做，哪些必须叫人？ 边界是写死的，还是靠提示词劝？不可逆的操作有没有确认？

它说完成时，谁负责验证？ 有没有测试、截图、diff、控制台检查？还是只靠模型自己说“我做好了”？

换模型之后，壳要不要重新调？ 工具描述、上下文预算、权限策略，都是跟着模型脾气走的。换发动机不换底盘，车不一定跑得更快。

回到凌晨两点

后来我改了测试脚本，让失败时输出完整命令、工作目录、退出码和最近一次通过的 commit。还是那个模型，还是那个任务。它第三次就找到了问题，修完，跑绿，写了一句很短的总结。

我没换模型。我只把水换了一下。

鱼能游多远，看水。Agent 能走多远，看壳。

这是「深水区手记」的第一篇。后面会继续写 agent、harness，以及那些在演示视频里看不到的失败现场。

参考资料

posted @ 2026-10-27 16:35  keeper123  阅读(42)  评论(0)    收藏  举报