Agent Harness 是什么？为什么模型之外，真正拉开差距的是 harness

模型能力仍然重要，但在 Agent 进入真实仓库之后，模型只是系统的一半。另一半是 harness：负责给模型上下文、工具、权限、状态、反馈循环和停止条件的运行时。

最近关于 harness engineering 的讨论升温，原因并不是又出现了一个更大的模型，而是同一个模型换了不同的执行外壳后，结果可能明显变化。Google 公开的 Harness² 项目把重点放在“如何组织 agent 的运行过程”，而不是只比较模型参数。社区转述的分数提升需要以项目原始评测为准，不能把社交媒体里的单个数字当成普遍结论。

一个可用的 harness 至少回答六个问题：模型现在看到了哪些文件？它能调用哪些工具？每次调用是否有预算？失败后如何收敛？什么时候应该停止？最终结果如何被测试和审计？没有这些环节，Agent 只能不断生成“看起来合理”的动作。

这解释了为什么两个团队使用同一个模型，交付能力却差很多。优秀的 harness 会在任务开始时建立工作集，在工具调用前做权限检查，在每个阶段留下可恢复的状态，并用测试而非模型自评来决定是否完成。它把 Agent 从聊天窗口变成了一个有边界的工程流程。

对开发者而言，下一步不是立刻换模型，而是建立三张表：工具表、风险表和验收表。工具表说明每个工具能读写什么；风险表说明哪些动作必须人工确认；验收表说明什么结果才算完成。模型越强，错误动作的影响半径往往也越大，harness 的价值因此会越来越接近安全基础设施。

我的判断是，未来的模型评测会从“单轮回答得分”转向“在约束下完成任务的成功率”。真正有竞争力的产品，不一定使用最强模型，而是能让多个模型在同一套上下文、权限和验证层上稳定工作。

来源

Google Harness² 项目、Theo 关于 harness engineering 的讨论。社交媒体数据仅作为热度线索，不作为性能证明。