什么是 Agent Harness：为什么模型越强，「壳」越重要

从一个反直觉的现象说起

同一个模型，接到不同产品里，表现天差地别。同样的 Claude，在这个工具里像个靠谱的资深工程师，改代码前先看测试、做完主动验证；在另一个工具里却笨手笨脚，改完就宣布完成，测试红了一片也浑然不觉。

刷 benchmark 的人对此更有体感：同一个模型跑 SWE-bench，换一套脚手架（scaffold），分数就是另一个故事。模型是同一个，差别全在包着它的那层「壳」上——这层壳，现在通行的叫法是 harness。

Harness 原意是马具、缰绳。这个词选得准：马的力气是马的，但它能不能把车拉到目的地，取决于套具怎么设计。对 agent 来说，harness 决定了模型能看到什么（上下文）、能做什么（工具）、按什么节奏做（循环）、犯错之后怎么办（恢复）。

模型的能力是模型的，但能兑现几成，看的是这四条皮带。

模型决定能力上限，harness 决定发挥出几成。

Harness 和提示词工程的区别

这两件事经常被混为一谈，但它们不在一个层面上。

提示词工程是说服：怎么把话说清楚，让模型理解你的意图。Harness 工程是制度设计：模型每一步能看到什么、被允许做什么、结果如何被验证、出错了走哪条路。前者是沟通的艺术，后者是组织的架构。

三个典型的 harness 问题，感受一下它们和提示词的距离：

• 模型改完代码就宣布完成，但没跑测试——这不是话没说清，是 harness 没有把「验证」做成强制环节
• 上下文塞满了无关文件，模型注意力被稀释——这是上下文管理策略的问题
• 任务做到一半 token 用完，一切归零重来——这是没有设计中间状态的持久化

**这些问题共同的特点：换更强的模型也解决不了。**你可以把提示词写成散文诗，但只要制度里没有”验证”这个环节，再强的模型也会在某个深夜自信地交付一段跑不通的代码。

Loop 工程：Agent 的心跳

Agent 的本质是一个循环：观察 → 思考 → 行动 → 验证，再回到观察。Harness 里最见功力的部分，就是这个循环的质量。

循环里最贵的一个部件，是那块「停」的牌子。

什么时候该停

最难的不是让 agent 动起来，而是让它知道什么时候停。停早了任务没完成，停晚了在原地打转烧 token。好的 harness 会给循环装上**「完成」的客观定义**——测试通过、构建成功、验收清单核对完毕——而不是让模型自己觉得”差不多了”。

「差不多了」是人类拖延症的语言，也是 agent 翻车报告里出现频率最高的心理活动。

犯错之后走哪条路

初级的循环犯错后重试同一动作，像一只反复撞玻璃的飞蛾。成熟的循环会先分类：这是环境问题（重试就好）、方法问题（换条路）、还是理解问题（回头重读需求）？**错误分类的颗粒度，直接决定一个 agent 的智能观感。**很多时候你觉得某个 agent “聪明”，其实是它的 harness 在替它体面地兜底。

一个身边的例子

这个概念听起来抽象，但它已经渗透到很小的设计细节里了。

前几天我把微信读书接进这个网站，官方 Agent 网关有个细节让我停下来看了很久：每次请求都要带 skill_version，版本过旧时，接口不报错，而是在回包里塞一个 upgrade_info，附上最新接口文档的下载地址——文档本身就是随协议分发的一组 Markdown。

翻译一下：**这个工具在教 agent 怎么升级自己对它的理解。**接口文档不再是写给人看的网页，而是 harness 的一部分，随数据一起流动。为人设计的 API 返回错误码，为 agent 设计的 API 返回”你该去读的新说明书”——这个差别很小，但它就是 harness 思维和传统 API 思维的分水岭。

为什么说 harness 是新的护城河

模型能力在快速趋同，各家旗舰的差距肉眼可见地缩小；协议层也在标准化——MCP 统一了工具怎么接，Skills 统一了知识怎么给。看起来”壳”的门槛应该越来越低才对。

但同样的模型、同样的协议，不同产品的体验差距反而在拉大。差的就是那些抄不走的细节：上下文怎么切分、长任务怎么分段、权限怎么收放、模型犯傻时怎么兜底。这些答案不在任何论文里，它们是几万个真实的边界情况喂出来的。

提示词可以一夜抄走，harness 抄不走——它是时间的产物。

小结

• Harness = 上下文管理 + 工具设计 + 循环控制 + 错误恢复
• 提示词工程在「说服模型」，harness 工程在「设计制度」
• 循环里最贵的部件是「停」：完成的定义必须客观，不能靠模型自觉
• 模型越强，harness 的杠杆越大——它决定强模型的能力能不能兑现

这篇还会随着理解加深继续修剪。