Model + Harness = Agent：产品差距的大头，不在模型

过去一年我日常重度使用 Claude Code、Codex、Cursor、OpenCode，还自己搭了一套 17 个角色的多 Agent 协作系统。踩了足够多的坑之后，我收敛出一个判断：

Model 决定 Agent 能力的上限；Harness 决定有多少人能稳定地够到这个上限。

同一个模型，放进 Claude Code 和放进一个裸 ReAct loop，可用性差一个数量级——差的全是 Harness。我甚至愿意给一个更激进的估计：当前 Agent 产品体验的差距，约 80% 不在模型，在模型之外的那层工程。

Harness 是什么：六件事

“Harness”这个词最近很热，但多数讨论停留在”就是包一层工具调用”。我把它拆成六件具体的事，每一件都有自己的深水区：

1. 上下文工程——在有限窗口里，每一步都放对的东西。检索、压缩、分层记忆，这是信息架构问题，不是 prompt 技巧问题。
2. 工具调用与安全——让模型能动手，但动不了不该动的。沙箱、权限分级、human-in-the-loop、fail-closed。
3. 人机交互——steering、审批、可中断、可回看。人始终在环里，且不累。
4. 记忆——跨会话、跨任务的知识，且带来源、可质疑、会过期。
5. 多 Agent 编排——拆解、派发、并发、验收、收敛，像一个真正的团队那样工作。
6. 评测闭环——能量化”到底有没有帮到人”，而不是”看起来跑通了”。

用这六个维度去看市面上的产品，会看到一个有意思的现象：每家都只做对了两三件。

Claude Code 和模型配合极深（KV Cache 友好的 prompt 结构、subagent 上下文隔离），但没有内置评测体系——Agent 做得好不好，全靠用户主观感受。Codex 的工程化程度最高（沙箱 + 分阶段 handoff），但阶段之间信息流失严重，每个阶段的 Agent 都像”失忆重启”。Cursor 证明了 IDE 深度集成是最高频的开发者场景，但它的 Harness 几乎没有治理——Agent 行为的约束全靠用户盯着屏幕。

所有人共同的缺失

拆完这些产品，最明显的感受是一句话：

所有人都在用模型补 Harness 的短板，而不是用 Harness 约束模型的不确定性。

具体表现为四个共性问题:

• 都依赖模型自己”做对事”，没有系统性的独立验证层——Agent 说”我做完了，测试通过了”，产品就信了；
• 工具权限都是”要么全开、要么全关”，缺少按任务粒度的控制——allow 了 bash，整个 session 都能用；
• 都没有可量化的 Agent 表现度量——好不好全靠感觉；
• 上下文管理都偏被动（模型自己记），缺少主动的结构化记忆注入。

这四个缺口，就是 Harness 这个方向真正值得做的事。

一个可验证的推论

如果上面的判断成立，它会给出一个可验证的推论：在模型能力接近的前提下，验收层做得更硬的产品，任务闭环率会显著更高。

我在自己的多 Agent 系统里验证过这一点。系统里的协调者不信任执行 Agent 的自我报告——每个任务交付后，它会独立重跑测试、对照任务入列时写下的完成标准（我把它叫 Done Definition）、再根据 diff 规模和敏感操作信号决定要不要追加人工审查。加上这层独立验收之后，最直接的变化是：“假完成”再也混不过去了。Agent 声称完成但实际没跑通的交付，会被 Gate 打回并附上失败证据，而不是流到我面前浪费我的时间。

这层东西和模型无关。换任何模型，它都在那里兜底。这就是 Harness 的价值：模型的进步是别人给的，Harness 的可靠性是自己挣的。

为什么现在写这个系列

接下来我会把这一年在 Harness 深水区踩过的坑写成一个系列：怎么让 Agent 知道”做到什么程度算完”（规格三要素）、为什么不能信 Agent 的自报（验收 Gate 的设计）、上下文压缩会吃掉你的约束（context engineering 实战）、记忆为什么需要”怀疑主义”（Skeptical Memory）、以及怎么量化”Agent 是否真的帮到了人”（指标体系）。

每一篇都遵守同一个写作规格：有真实机制、有踩坑代价、有可以直接抄走的设计。 不写”十大技巧”，只写深水区。

---

这是「Harness 深水区」系列的第一篇。下一篇：《Agent 不知道什么叫”做完了”——规格三要素的设计》。