引言：什么是 Harness Engineering
如果你最近在关注 AI Agent 的技术圈，一定到处都能看到Harness Engineering这个词。但大部分人对它的理解停留在"给 agent 加约束"这个层面，这远远不够。
今天我们将彻底讲清楚这个概念。看完之后，你会发现业界一直以来对 agent 做的技术优化，本质上都在做同样的事情——优化模型周围的系统，而非模型本身。
核心公式：Agent = Model + Harness
模型包含智能，Harness 让这个智能变得有用。
一、Harness 概念解析
Harness 这个词来自马术，指的是缰绳、马鞍等用来引导马匹朝正确方向走的装备。这个比喻是刻意的：
- 马 → AI 模型：强大、快速，但它自己不知道该往哪走
- 骑手 → 人类工程师：提供方向，而不是亲自跑
- Harness → 骑手和马之间的控制系统
Harness 最早的定义非常简洁：每当你发现 agent 犯了一个错误，你就花时间设计一个解决方案，让 agent 永远不会再犯同样的错误。
LangChain 在此基础上给出了一个更精炼的公式：
Agent = Model + Harness
把模型想成引擎，agent 就是整辆车，而 harness 就好比方向盘和刹车——最好的引擎没有方向盘和刹车，去不了任何有用的地方。
二、LangChain 实战案例：Terminal Bench 排名提升
先从一个反直觉的事实说起：LangChain 的 Coding Agent 在 Terminal Bench 排行榜上，从 30 名开外一路冲到了前五。
整个过程中，底层模型一行没换，始终是同一个模型。他们只动了三个东西：
- 系统提示
- 工具配置
- 中间件钩子
这个结果直接挑战了 AI 开发中一个根深蒂固的假设：更好的性能需要更大或更新的模型。
LangChain 用实际数据证明：模型不变的前提下，光靠优化模型周围的系统就能带来数量级的提升。他们用的方法论就叫 Harness Engineering。
三、Harness vs Context Engineering
你可能听过另一个类似的概念叫 Context Engineering（上下文工程）。它们是什么关系？
一句话讲清楚：
- Context Engineering 问的是：我们给 agent 看什么？
- Harness Engineering 问的是：系统预防了什么、测量了什么、修复了什么？
更准确地说：
- 上下文工程主要关注怎么管理 agent 的上下文窗口：给它看什么信息、不看什么信息、什么时候看
- Harness Engineering的范围更广，还包括架构约束、自验证循环、文档治理和系统的可演进性
四、Harness 六大核心组件详解
1. 上下文架构
前沿团队一致发现：给 agent 塞太多信息，反而有害。有研究表明，agent 的性能在上下文利用率超过大约 40% 之后开始下降。
所以关键不是给 agent 一本百科全书，而是给它一张地图，让它按需查找。
- OpenAI 的做法：把 agent 文件控制在约 100 行，只充当目录，指向更深层的文档。agent 需要什么信息自己去查，而不是一开始就全部塞进去
- Anthropic 的做法：渐进式加载理念，按需加载技能
2. 架构约束
大多数人靠 prompt 来约束 agent 的行为："请遵循以下规则……"但 prompt 里的规则本质上是建议，模型可以听，也可以不听。
前沿团队的做法是：用确定性的工具来机械式执行约束，比如自定义的 lint 和结构化测试规则。一旦编码，就在所有 agent 的对话中同时生效，不依赖模型的自觉性。
这里有一个反直觉的发现：v0 一开始给 agent 提供了大量工具，结果 agent 反而变得困惑，做冗余调用。后来他们移除了 80% 的工具，只留最必要的，agent 反而更快更可靠。约束解空间，反而提高了产出。
3. 自验证循环
Agent 有两个常见的失败模式：
- 陷入死循环，对同一个文件反复编辑十几次，但问题始终没解决
- 交付时跳过验证，第一个看起来合理的方案就直接输出
LangChain 的方案是用中间件钩子来解决：
- 一个中间件跟踪每个文件的编辑次数，超过阈值就提醒 agent 重新审视方案
- 另一个中间件在 agent 准备退出时拦截，强制执行一轮完整验证
他们还发现了一个非常有价值的策略叫"推理三明治"：
- 规划阶段：用最高推理强度，充分理解问题
- 执行阶段：降到高等推理强度，保证速度
- 验证阶段：再拉回最高推理强度，捕获错误
全程最高推理强度反而成绩更差，因为会超时。把算力花在刀刃上效果最好。
4. 上下文隔离
当任务复杂到需要多个 agent 协作时，关键不是按角色分工（什么前端 agent、后端 agent），而是把子 agent 当做上下文防火墙。
父 agent 只看到它给子 agent 的指令和子 agent 的最终结果，中间所有的工具调用和中间产物都被隔离掉了。这样，每个执行单元的上下文都保持干净，不会被无关信息污染。
5. 文档治理
Agent 的持续运行时间越长，系统的混乱度就越高：文档过时、架构漂移、知识库和代码不一致。
OpenAI 的方案是引入一个后台运行的文档梳理 agent，定期扫描过时的文档，并自动提交修复。为 agent 服务的文档，由 agent 来维护，形成自维护的闭环。
6. 可拆卸性
这是最高维度的一层：更好的模型会让某些 harness 组件变成瓶颈。
2024 年需要复杂流水线的任务，2026 年可能一个 prompt 就搞定了。所以 harness 必须是模块化的、可拆卸的。
LangChain 的中间件架构是目前最好的参考，每个中间件独立添加特定能力，不需要的时候直接移除，不影响其他部分。
五、Anthropic 多 Agent 系统实战
Anthropic 用 Harness Engineering 的方法，让 Claude 自主写了四个小时代码，最终从一句话 prompt 生成了一个能用的浏览器端音乐制作软件——不是 demo，不是 toy project，是一个有编曲视图、混音器、音轨编辑，还内置 AI 助手的完整应用。
他们借鉴了深度学习里经典的GAN（生成对抗网络）思路：有一个生成器负责创造，一个判别器负责挑刺，二者对抗博弈，互相逼着对方进步。
Anthropic 把这个思路搬到了 agent 的架构上，设计了三 agent 系统：
- 规划器（Planner）
- 生成器（Generator）
- 评估器（Evaluator）
每个 agent 解决一个明确的失败模式。
规划器：从一句话到产品规格
大多数人用 agent 写代码，上来就是一句 prompt 直接开干。Anthropic 发现这样做 agent 会严重低估项目的范围，做出来的东西功能很单薄。
所以他们加了一个规划器 agent，专门负责把你的一句话 prompt 扩展成一份完整的产品规格说明。
但这里有一个非常反直觉的设计决策：规划器只写高层产品设计，故意不写技术实现细节。
为什么？因为如果规划器在前期把某个技术细节写错，这个错误会一路传导到后面所有的实现环节，越错越离谱。不如只约束要做什么，让后面的 agent 自己决定怎么做。
设计原则：当你设计多 agent 系统时，上游 agent 的输出粒度要非常克制——给方向，但不给路径。
生成器：真正写代码的 agent
生成器就是真正写代码的 agent。Anthropic 一开始的设计是让它按迭代周期来工作，一次只做一个功能，每个迭代周期结束后自评一次，再交给评估器。
六、上下文焦虑与上下文重置
这里引出了 Anthropic 在这篇文章里揭示的第一个重大失败模式，叫"上下文焦虑"。
什么意思呢？当 agent 持续工作，上下文窗口越填越满的时候，有些模型会开始慌——它们会觉得自己快到上下文上限了，然后开始草草收工，提前结束任务。
注意：不是真的到了上限，而是模型自己以为快到了。
这个问题用常规的上下文压缩解决不了。所谓压缩，就是把前面的对话摘要一下，让 agent 在缩短的历史上继续工作。但问题是：agent 虽然拿到了更短的上下文，心理上的焦虑并没有消失，它仍然觉得自己快到极限了。
Anthropic 的解法叫上下文重置：不是压缩，而是彻底清空。启动一个全新的 agent，然后通过一个结构化的交接文档，把前一个 agent 的状态和下一步计划传递过去。给模型一块干净的白板。
代价是增加了编排复杂度和延迟，但效果显著。
重要发现：当 Anthropic 后来发布了更强的 Opus 模型之后，上下文焦虑这个问题基本消失了。这意味着上下文重置这个组件可以被拆掉——模型进步会让某些 harness 组件过时。
七、评估器设计与校准
评估器是整套 harness 里最关键也最难做好的部分。
Anthropic 发现了第二个重大失败模式：agent 在评价自己的工作时倾向于自信地表扬自己，即使产出质量明显平庸，它也会说"做得不错"。
这个问题在主观任务上尤其严重（比如前端设计好不好看），agent 自评的时候几乎永远给自己高分。即使是在有客观标准的编程任务上，agent 也会犯同样的错误——它发现了一个 bug，然后说服自己这不是大问题，然后放行了。
Anthropic 的解法是：把生成和评估彻底分离，让另一个独立的 agent 来当裁判。
但注意：仅仅分离是不够的，因为评估器本身也是一个 LLM，它天然对 LLM 生成的内容宽容。关键的洞察是：调用一个独立的评估器让它变严格，比让生成器学会自我批判要容易得多。
如何让评估器真正严格起来？
Anthropic 做了两件事：
第一件事：把主观变成客观
把"好不好"变成可打分的具体维度，定义了四个评分标准：
- 设计质量：看颜色、排版、布局是否形成统一的整体感
- 原创性：看有没有定制化的设计决策，还是千篇一律的模板和 AI 生成套路
- 工艺：看技术执行力，兼容性、一致性、对比度这些基本功
- 功能性：看用户能不能顺利完成任务
然后做了很聪明的权重分配：工艺和功能性权重低（因为 Claude 默认就做得不错），设计质量和原创性权重高（因为这是模型的短板）。
而且他们在评分标准里明确写了：要惩罚那些一眼就能看出是 AI 生成的套路（比如紫色渐变配白色卡片）。
第二件事：用 few shot 示例加详细的评分分解来校准评估器
确保评估器的品位和开发者的品位对齐。评估器不是看截图打分的，它通过 Playwright 实际操作运行中的应用，点击导航、截图仔细研究，然后才输出评估。
每一轮反馈都回传给生成器，生成器要么继续优化当前方向，要么整体推翻重来。
惊艳的例子：让模型生成一个荷兰艺术博物馆的网站。前九轮迭代模型一直在做一个深色主题的落地页，视觉上很精致，但在预期范围内。到第十轮，模型突然推翻了整个方案，把网站重新想象成一个空间体验——一个用 CSS 透视渲染的 3D 房间，棋盘格地板，画作自由悬挂在墙上，通过门廊在画廊之间导航。
这种创造性的跳跃在单次生成中从来没见过，这就是对抗式反馈循环的力量。
评估器校准需要投入
Anthropic 也非常坦诚地说，让评估器达到这个水平花了大量功夫。Claude 开箱即用的时候是一个很差的 QA agent。他们的调优方法是：
- 读评估器的日志
- 找到它的判断和你的判断不一致的地方
- 改 prompt
- 再跑、再看日志、再改
反复多轮之后，评估器才开始输出合理的判断。
八、迭代合同机制
一个很精妙的机制叫迭代合同。
在每个迭代周期开始之前，生成器和评估器会先协商一份合同。合同明确定义这个迭代周期做到什么程度算完成，包括具体要实现的功能和可测试的验收标准。双方要反复讨论，直到达成一致。
然后，生成器按合同来构建，评估器按合同来验收。
为什么要这样做？因为规划器的产品规格说明是故意写得很高层的，不会细到告诉你某个按钮应该怎么实现。迭代合同就是在高层规格和可测试的实践之间搭了一座桥。
通信方式也值得一提：Agent 之间不是通过对话来沟通的，而是通过文件——一个 agent 写一个文件，另一个 agent 读这个文件，然后回应。简洁、可追溯、不会污染各自的上下文。
评估器在验收时的严格程度到什么级别？文章给了几个实际例子：
- 一个关卡编辑器的矩形填充工具，评估器发现它只在拖拽起点和终点放置了瓷砖，而不是填满整个矩形区域，精确指出了是哪个函数没有在 mouseup 事件上被正确触发
- 一个 FastAPI 的路由问题，评估器发现 reorder 这个路径被定义在了带参数的路由后面，导致 FastAPI 把 reorder 这个字符串当成了整数类型的 frame ID 去解析，返回了 422 错误
这种力度的 QA 是真正在用层面上找问题，而不是走过场。
九、可拆卸性原则
最后说整篇文章里最有战略价值的一个认知。
当 Anthropic 发布了更强的 Opus 4.6 模型之后，他们做了一件很重要的事：回过头去重新审视整个 harness，看哪些组件还有存在的必要。
他们提出了一个原则：Harness 中的每一个组件，本质上都编码了一个假设——就是模型自己做不好这件事。这些假设需要反复被压力测试，因为它们可能一开始就是错的，也可能随着模型进步而过时。
具体来说，他们一开始想大刀阔斧地简化，直接砍掉一半组件，结果失败了——产出质量明显下降，而且搞不清楚是哪个组件的缺失导致的。
后来，他们换了一个更稳妥的方法：每次只移出一个组件，观察对最终结果的影响。最终他们成功地移除了整个迭代周期结构，因为 Opus 4.6 的持续工作能力大幅提升：
- 生成器可以连续编码两个多小时而不丧失连贯性，不再需要把工作切成小块
- 评估器也从逐周期评审改成了最后统一评审一次
但评估器本身没有被移除，因为在模型能力的边界上，评估器仍然能抓到生成器遗漏的功能和 bug。它的价值变成了动态的：任务越接近模型的能力极限，评估器的价值就越大。
简化之后的 harness 跑了一个浏览器端的数字音频工作站，四个小时 125 美元，最终产出一个有编曲视图、混音器、多音轨编辑的完整应用，而且内置的 AI 助手可以通过 prompt 来设置节拍、编写旋律、构建鼓轨、调整混音、添加混响。
从一句话 prompt 到一个能用的音乐制作软件，全程无人干预。
总结
从这篇文章里可以带走的最核心的几个认知：
- 永远不要让 agent 自己评价自己的工作——生成和评估必须分离，然后花时间把评估器调严格
- 主观质量是可以被打分的——定义具体的评分维度，用 few shot 校准，按短板加权，你就有了一个可以驱动迭代的反馈信号
- 上游规划要克制——只给方向，不给路径，避免错误级联
- Harness 的每一个组件都应该是可拆卸的——模型在进步，今天需要的脚手架，明天可能变成瓶颈。保持模块化，定期审视，每次只动一个变量
- Harness 的有趣组合空间不会随着模型进步而缩小——它只是在移动。模型能力的边界往外推了，harness 的设计空间也跟着往外推
一句话总结：Anthropic 用实战证明了 agent 的性能天花板不取决于模型能做什么，而取决于你在模型周围搭建了什么样的系统。模型进步一个台阶，harness 跟着进化一个台阶，两者叠加才是真正的前沿。
这就是 Harness Engineering。
← 返回博客首页核心主张：Agent 的可靠性瓶颈不在模型，在模型周围的系统。模型是引擎，agent 是整辆车——引擎再强，没有方向盘和刹车，到不了目的地。