同一句需求——“做一个 2D 复古游戏制作器”——同样使用 Claude Opus 4.5。单 Agent 跑了 20 分钟，花了 9 美元，界面看起来像模像样，点进游戏却发现角色根本动不了；另一边，Planner、Generator、Evaluator 三个 Agent 组成的 Harness 跑了 6 小时，花了 200 美元，最后做出的游戏虽然粗糙，核心玩法却真的能跑。

中间没有换更强的模型。真正换掉的，是模型外面那套工作方式。

Anthropic 在 2026 年 3 月发布的《Harness design for long-running application development》，研究的是怎样让 Claude 独立工作几小时，做出一套完整应用。

如果你读过我前面写的《Loop Engineering 到底怎么用、怎么搭》，这篇可以看成一个更具体的续篇：Loop 解决的是“怎么让 AI 持续干活”，Harness 继续追问“它持续干了几个小时之后，交出来的东西到底能不能用”。

我读完最大的感受是，AI 编程正在经历一个很像软件工程早期的转折。大家不再只盯着“这个程序员会不会写代码”，而是开始设计分工、评审、验收、交接和返工。换句话说，瓶颈正在从模型本身，转向怎么组织模型工作。

一、Harness 不是多开几个 Agent，而是给模型搭一套工作系统

先把 Harness 这个词讲明白。

它直译有“挽具、马具”的意思。在 Agent 工程里，它指的不是某个神奇框架，而是包在模型外面的整套工作系统：谁负责规划、谁负责执行、完成标准写在哪里、用什么工具检查、失败后怎么返工、上下文快满时怎样交接。

如果模型是一台发动机，Harness 就是底盘、方向盘、仪表盘和刹车。发动机马力再大，没有这些东西，也只会在原地吼得很热闹。

Anthropic 最初采用的是三个角色：

• Planner：把用户一到四句话的模糊需求，扩成完整产品规格；
• Generator：按功能逐段实现应用；
• Evaluator：像 QA 一样操作真实页面，检查功能、接口和数据库状态，没过线就打回去。

这里最容易产生的误解，是觉得效果提升来自“三个 Claude 比一个 Claude 聪明”。其实不是。三个角色用的仍是同一类模型，提升来自注意力被拆开了：规划者只管“该做什么”，执行者只管“怎么做出来”，评估者只管“它到底做对没有”。

这很像一支小团队。不是每个人都比独立开发者更聪明，而是有人把需求想全，有人沉下去实现，还有一个不欠人情的测试同事专门挑刺。角色一分开，原本挤在同一次推理里的几种冲突目标，也被分开了。

所以我觉得，Harness 真正设计的不是 Agent 数量，而是责任边界。

二、最值钱的 Agent 不是会写代码的，而是敢说“不合格”的

原文里最让我有共鸣的，不是 Planner 能把一句话扩成十个 Sprint、16 个功能，而是 Anthropic 花了很大力气，才把 Evaluator 调成一个合格的 QA。

模型有个很人类的毛病：自己写完的东西，自己看着总觉得还不错。尤其是界面设计这类没有“测试通过 / 失败”二选一答案的任务，它很容易把“能显示”夸成“很完整”，把“没报错”当成“很好用”。

Anthropic 先在前端设计上做实验，把审美拆成四个可以评分的维度：整体设计、原创性、制作细节和功能可用性。其中，他们刻意提高了整体设计与原创性的权重，专门惩罚那些安全、规整，却一眼就是模板拼出来的“AI 味”页面。

这一步特别重要。“做得漂亮一点”只是愿望，“不要默认组件堆砌，要有一致的视觉气质和明确的原创选择”才是标准。 就像你不能只对厨师说“做得好吃”，还得说清楚想要清爽还是浓郁、主味是什么、哪些东西不能抢戏。

然后，Evaluator 拿着这些标准，通过 Playwright 真正打开网页、点击功能、截图观察，再把批评交回给 Generator。一次前端生成会迭代 5 到 15 轮，完整流程最长跑到 4 小时。一个荷兰艺术博物馆网站做到第九轮时还只是精致的深色落地页，第十轮却推翻原方案，变成了可以穿过“门洞”游览的 3D 展厅。

但这套做法并不神奇。原文很坦率地说，未经调教的 Claude 并不是一个好 QA：它会发现真实问题，然后自己劝自己“问题不大”，最后还是给通过；它也容易只走一遍正常流程，不主动去戳边界情况。

这意味着，再单独开一个 Reviewer 并不会自动得到第二意见。如果验收标准含糊，第二个 Agent 只是换了把椅子继续客气。

真正有效的是三件事：

1. 把“好”拆成可观察的标准；
2. 让评估者接触真实运行环境，而不是只读一遍代码；
3. 反复对照人的判断和评估日志，专门修正它放水的地方。

这也让我重新理解了所谓“品味”。品味当然不能被几个分数完整装下，但它可以被一点点写进标准、反例和权重里。等 AI 大量参与生产之后，一个团队最稀缺的资产，可能不只是代码和提示词，而是那套能稳定回答“什么算好”的验收体系。

三、先谈妥“怎样算做完”，再开始写代码

这套 Harness 里还有一个很聪明的设计：每个 Sprint 开始前，Generator 和 Evaluator 会先谈一份 Sprint Contract，也就是这轮开发的验收合同。

Planner 给的是高层产品规格，不会过早规定每个函数怎么写。Generator 再提出这轮具体做什么、准备怎么证明它做完了；Evaluator 检查这些标准够不够完整。双方谈妥，才开始动代码。

听起来多绕了一圈，实际上是在避开 Agent 开发里两个常见的坑。

一个坑是规格太松。只说“做一个关卡编辑器”，Generator 很容易做出几排按钮、一个画布，就宣布完成。另一个坑是规格太死。Planner 在还没看见真实代码之前，就把技术细节规定到函数级，一旦前面猜错，错误会沿着后续任务一路传下去。

Sprint Contract 选了中间那条路：锁定结果，不锁死路径。

复古游戏项目的第三个 Sprint 最终列出了 27 条关卡编辑器验收标准。Evaluator 不是问“代码看起来专业吗”，而是真的检查“拖动鼠标能不能填满一个矩形”“选中的出生点能不能删除”“动画帧重排接口是否可用”。因此它抓到的也不是空泛的“建议优化体验”，而是具体到事件没有在 mouseUp 触发、路由顺序导致参数解析失败这类可直接返工的问题。

图（来自 Anthropic 原文）：单 Agent 生成的试玩界面看起来完整，但实体与游戏运行时没有正确连上，角色无法响应操作。

这让我想到，过去我们把需求文档当成“写给开发看的说明书”，而在 Agent 工作流里，它正在变成一种可执行的交付协议。好的规格不只描述要造什么，还要告诉另一个 Agent 怎样亲手证明它真的存在。

“完成”不是执行者说了算。能被独立复现，才算完成。

四、9 美元的废品和 200 美元的原型，哪个更贵

看到 20 分钟、9 美元和 6 小时、200 美元这组对比，第一反应很容易是：这 Harness 也太烧钱了。

确实烧钱。完整 Harness 的成本超过单 Agent 20 倍，还带来了更长延迟、更复杂的编排和更多 Token 消耗。它绝不该成为每个任务的默认配置。

但只比较 Token 账单，也会漏掉另一半事实：9 美元那一版的核心玩法是坏的。它作为演示截图有价值，作为游戏制作器几乎没有交付价值。200 美元那一版仍谈不上成熟产品，至少主要链路能工作，而且规划出了动画、行为模板、音效、AI 辅助设计和分享等完整产品结构。

图（来自 Anthropic 原文）：完整 Harness 版本的物理效果仍有瑕疵，但角色已经可以移动，核心玩法能够运行。

后来 Anthropic 用精简后的 Harness 做浏览器版数字音频工作站，又跑了 3 小时 50 分钟，总成本 124.70 美元。Evaluator 第一轮就指出，应用虽然好看，但音频片段不能拖动、乐器没有真正的操作面板，一些核心功能只是摆设；第二轮又抓到录音按钮只有状态切换，并没有真的调用麦克风。

这些都不是边角料，而是最容易被“页面很漂亮”掩盖的交付空洞。

所以更合理的成本单位，不是“完成一次生成花多少钱”，而是“得到一个可用结果花多少钱”。9 美元生成一个不能玩的游戏很便宜，也可能是最贵的那种便宜。

当然，这不等于所有任务都该上三 Agent、跑四小时。Anthropic 早在《Building effective agents》里就反复强调：从最简单的方案开始，只有简单方案确实不够时，才增加复杂度。我的理解是，Harness 适合用在任务刚好超出当前模型稳定能力边界的地方。边界以内，让一个 Agent 直接做；边界以外，才值得花钱买规划、复核和返工。

五、最好的 Harness，应该随模型升级而主动过期

这篇文章最值得反复琢磨的一句话，不是“三 Agent 效果更好”，而是：Harness 里的每一个部件，都暗含了一个“模型自己做不到”的假设。

早期方案用 Sonnet 4.5 时，模型接近上下文上限会出现“上下文焦虑”——像快到下班时间的人一样，明明活没干完，却开始匆忙收尾。于是系统需要定期清空上下文，再用进度文件把任务交给一个全新的 Agent。

换到 Opus 4.5 后，这个问题明显减轻，Context Reset 就可以删掉，只靠自动压缩维持一个连续会话。再换到 Opus 4.6，模型本身更会规划、能连续工作更久，原先帮助拆解任务的 Sprint 结构也不再那么必要，于是 Anthropic 把它拆了，只保留仍然承重的 Planner 和 Evaluator。

这里的思路很像改造一栋老房子：不能因为某根梁过去很重要，就认定它永远不能动；也不能一口气全拆了，再凭感觉判断到底是哪根梁让房子塌的。Anthropic 后来采用的办法，是一次拿掉一个组件，观察最终结果发生什么变化。

这其实是一种针对 Agent 系统的“消融实验”：逐项拆零件，看性能掉不掉，从而找出谁真的承重。

我很喜欢这个判断，因为它戳破了 AI 工程里一种常见冲动：一旦某套复杂架构奏效，就赶紧把它固化成最佳实践。可模型每隔几个月就会换一代。今天为了补模型短板写出的精巧编排，明天可能只剩延迟和账单。

因此，Harness 不是一次设计完的架构，而是一套要跟着模型能力持续删改的假设清单。

六、如果现在让我搭一套 Harness，我会先做这五件事

读完这篇文章，我不会马上给每个项目塞进 Planner、Generator、Evaluator。更实际的起点，是下面五步：

1. 先跑单 Agent 基线。 不先看它独立能做到哪一步，就不知道复杂系统到底补了什么。
2. 先写验收合同，再写实现提示。 把“功能存在”改写成用户可以执行、评估者可以复现的行为。
3. 把执行和验收分开。 尤其是跨模块、长耗时和主观质量高的任务，不让写作者独自签收自己的作业。
4. 让评估者接触事实。 能跑测试就别只读代码，能操作页面就别只看截图，能检查数据库就别只相信界面提示。
5. 模型升级后做减法。 一次删一个流程，观察质量是否下降；不再承重的部分，及时拆掉。

这五步背后其实是同一件事：别把模型偶尔做成过一次，当成系统以后都能稳定交付。

写在最后

过去我们习惯把 AI 编程理解成“找一个更厉害的程序员”。Anthropic 这篇文章让我更确信，下一阶段的竞争不只是谁有更强的模型，还包括谁更会给模型组织工作。

模型升级，当然会让单个 Agent 做得更久、更完整。但它不会自动替你长出产品边界、验收标准、团队品味和不留情面的 QA。这些东西仍然要被设计，只是它们不再全由人来执行，而是被写进角色、工具、文件和反馈循环里。

真正好的 Harness 也不是越复杂越好。它应该像一副合身的外骨骼：模型够不到的地方，它补上；模型自己已经能做到的地方，它就让开。

让 AI 连续工作几个小时，已经不算最难的事。难的是几个小时之后，它仍在做正确的事，而且我们有办法证明，它真的做对了。

---

参考资料

• Anthropic，Harness design for long-running application development，2026 年 3 月 24 日：https://www.anthropic.com/engineering/harness-design-long-running-apps
• Anthropic，Effective harnesses for long-running agents，2025 年 11 月 26 日：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic，Building effective agents，2024 年 12 月 19 日：https://www.anthropic.com/engineering/building-effective-agents