模型与 Harness

一句话理解：模型是引擎，Harness 是整辆车；用户感受到的“好不好用”，大半取决于车，而不只是引擎。

你可能有过这样的体验：同一个模型，在官方聊天界面里只会给建议，在某个 Coding Agent 里却能自己读代码、跑测试、改完提交；换到另一个产品，又常常“做到一半就忘了目标”。模型没变，变的是模型外面那一层——业内通常叫它 Harness（直译是“挽具、线束”，指套在模型外、让它能真正干活的运行系统）。

对产品经理来说，这一课的意义在于：Agent 产品的竞争力，很大一部分是可以设计出来的，而不是只能等下一代模型。

Harness 到底包含什么

把一次 Agent 运行想象成：模型只负责“读一段输入，输出一段文字或一个工具调用”。除此之外的所有事情，都是 Harness 做的。

逐项对应到用户体验：

Harness 能力	做得好时的体验	做得差时的症状
上下文管理	长任务不跑偏，记得最初目标	做了 30 步后忘了要干嘛
工具集与工具描述	选对工具、参数填得准	反复调用错误工具，或参数格式错
工具结果处理	大结果被截断、摘要后再给模型	一次返回 5 万行日志，把上下文撑爆
权限与确认	危险操作前停下来问你	要么什么都问、烦死人，要么什么都不问
执行环境	在沙箱里放心跑命令	不敢让它执行，或者执行出事故
错误恢复	工具报错后换个方式继续	一报错就整体失败，或无限重试
验证机制	改完代码自动跑测试确认	自信地宣布“已完成”，其实没完成
可观测性	能回看每一步做了什么、为什么	出问题只能猜

为什么差距会这么大

原因一：模型只能看见 Harness 给它的东西。 模型不知道你的代码仓库有多大、数据库有哪些表、上一步工具返回了什么——除非 Harness 把这些信息以合适的形式放进上下文。给得太少，它瞎猜；给得太多，它被淹没。

原因二：模型只能做 Harness 允许它做的事。 没有终端工具，再强的模型也跑不了测试；工具描述写得含糊，模型就会用错。

原因三：错误会累积。 假设每一步有 95% 的概率做对，一个 20 步的任务全部做对的概率不到 40%。Harness 的验证与恢复机制，决定了中间某一步出错后，任务是“就此失败”还是“发现并修正”。

一个 Coding Agent 的对比

同一个模型，同一个任务：“修复用户登录后跳转到 404 的 Bug”。

Harness A：简单聊天界面 + 代码粘贴

1. 用户粘贴一个文件，模型猜测问题在路由配置。
2. 模型给出修改建议，但看不到其他文件，不知道路由其实在另一个模块定义。
3. 用户手动修改、手动运行，发现没修好，再回来贴报错。
4. 来回五六轮。

Harness B：带文件、终端、测试工具的 Coding Agent

1. 模型搜索代码中“redirect”相关位置，找到三处。
2. 读取相关文件，发现登录成功后跳转路径拼接时少了语言前缀。
3. 修改代码，运行相关测试，一个测试失败。
4. 读失败信息，补充修改，重新运行，全部通过。
5. 展示 diff，等待用户确认提交。

模型的“智商”完全一样，差距全部来自 Harness：能不能主动获取信息、能不能执行、能不能验证。这也是 Coding 领域的 Agent 最先成熟的原因之一——代码有编译器和测试这种天然的验证器，详见办公 Agent 与 Coding Agent。

模型与 Harness 如何分工

一个实用的分工原则：需要理解、判断、生成的交给模型；需要确定、可审计、必须遵守的交给 Harness。

事情	交给模型	交给 Harness
判断下一步查什么	✓
从报错信息里推断原因	✓
限制最多执行 50 步		✓
禁止执行 rm -rf 这类命令		✓
把 10MB 的日志截断成摘要		✓
决定报告的结构与措辞	✓
记录每次工具调用的参数与耗时		✓
检查 SQL 是否只读		✓

当模型升级时，Harness 也需要跟着调整：更强的模型可能需要更少的“手把手”步骤指令，但权限、验证、可观测性这些部分不会因为模型变强而消失。

常见误区

• “等下一代模型出来，问题自然就解决了。” 上下文组织、工具设计、权限与验证是系统问题，模型再强也需要它们。很多“模型不行”的抱怨，换个 Harness 就消失了。
• “Harness 就是某个开源框架。” 框架只提供了一部分通用能力。针对你的业务的工具描述、上下文策略、审批规则，仍然需要自己设计。框架选型见框架与 SDK 选型。
• “用了最强模型，Harness 简单点也行。” 恰恰相反，越强的模型被赋予越多自主权，越需要可靠的权限、验证与可观测性兜底。

产品经理检查清单

评估一个 Agent 产品（自己的或竞品）时，别只问“用的什么模型”，问这些：

• 模型每一步能看到哪些信息？谁决定给它看什么？
• 工具列表是什么？工具返回过大时怎么处理？
• 哪些动作需要确认？确认规则由谁、在哪里执行？
• 工具失败时，是重试、换方案还是停下来问人？
• 它怎么知道任务真的完成了？
• 最多执行多少步、花多少钱？超出后怎么办？
• 出了问题，能不能回放每一步？

练习

用 45 分钟，拿两个你能访问的 AI 产品（例如一个通用聊天产品和一个 Coding Agent，或同一厂商的聊天界面与 Agent 模式），给它们同一个任务：

读取某个公开网页（例如一篇产品文档），总结其中的三条关键规则，并指出其中有没有互相矛盾的地方。

记录并对比：

维度	产品 A	产品 B
它是否主动获取了信息？
执行了几步？每步做了什么？
有没有验证自己的结论？
出错时如何处理？
结论质量

最后写一句话：两者的差异中，有多少可以归因于 Harness 而不是模型？

延伸阅读

• Anthropic：Building effective agents，强调工具接口与文档设计对 Agent 表现的影响。
• Anthropic：Effective harnesses for long-running agents，介绍如何让 Agent 跨越多个上下文窗口持续推进长任务。

下一步

Harness 的核心是一个循环。下一课「初识 Agent Loop」拆解这个循环的四个环节：Observe、Reason、Act、Verify。