精读《Harness design for long-running application development》：真正拉开差距的，不是模型本身，而是你怎么给它搭脚手架

原文：Harness design for long-running application development

Anthropic 这篇文章最值得读的地方，不是它又做出了一个“多 agent 系统”，而是它把一个经常被说得很玄的命题讲清楚了：当模型开始承担数小时、跨阶段、带主观判断的软件构建任务时，决定上限的往往不只是模型能力，而是 harness，也就是你为模型设计的工作流、角色分工、反馈机制和上下文管理方式。

如果把全文压缩成一句话，就是：不要把模型当成一个会自动完成复杂任务的万能体，而要把它当成一个需要被拆分、被校准、被监督、被持续重构的生产系统。

这篇文章到底解决了什么问题

作者一开始面对的是两个看似不同、其实很像的问题：

1. 怎样让 Claude 产出更有审美质量的前端设计。
2. 怎样让 Claude 在几小时内自主做出一个完整应用，而不是半路跑偏。

这两个问题的共同难点在于，单个 agent 很容易在长任务里出现两类失败：

• 第一类是“长程失稳”。上下文变长后，模型会逐渐失去连贯性，甚至出现作者说的“context anxiety”，也就是还没到极限就开始草草收尾。
• 第二类是“自我评价失真”。模型做完一个东西后，往往会高估自己的产出，尤其是在设计这种没有标准答案的任务上。

前者是记忆与执行控制问题，后者是评价机制问题。文章的核心贡献，就是分别给这两个问题配上了工程化解法。

最关键的洞察：把“主观好坏”改写成可评分标准

作者先从前端设计入手，因为这里最容易暴露模型“自卖自夸”的问题。默认情况下，模型很容易做出“能用但普通”的界面：安全、规整、功能没问题，但没有明确气质，也缺少真正的设计判断。

于是作者没有直接问模型“这个设计美不美”，而是把评价标准拆成四项：

• 设计质量：整体是否统一，是否形成明确气质。
• 原创性：有没有真实的设计决策，而不是模板味和 AI 味。
• 工艺：排版、间距、配色、对比度这些基本功是否扎实。
• 功能性：用户能不能顺畅理解和使用界面。

这一步非常关键。因为它说明了一个常被忽略的事实：主观任务不是不能评估，而是要先把“感觉”翻译成“准则”。

也就是说，harness 的工作不只是分配 agent，更重要的是把模糊目标转成模型可以反复对齐的评分坐标系。你一旦把“好设计”从抽象审美，改写成“设计质量 + 原创性 + 工艺 + 功能性”的组合，模型就不再只是在瞎猜人类偏好，而是在一个可迭代的评价空间里优化。

从 GAN 得到启发，但真正落地的是工程闭环

文章借用了 GAN 的思路：一个 generator 负责生成，一个 evaluator 负责打分和批评。这个类比很好懂，但更重要的是它在工程上的具体实现：

这里真正有效的不是“多 agent”这三个字，而是闭环的设计：

• generator 不负责给自己打分。
• evaluator 不直接写代码，而是保持外部审视视角。
• planner 负责把一句模糊需求扩展成更完整的规格和设计语言。

这相当于把人类团队里“产品规划 - 开发实现 - QA/评审”这套结构压进了模型工作流里。作者的发现也很直接：让一个 agent 自我反思很难，让另一个 agent 专门怀疑它，反而更可控。

为什么这套方法对长任务有效

文章里还有一个容易被忽视但非常重要的点：长时任务不是简单地“把调用时间拉长”，而是要解决任务分段、状态传递和稳定性问题。

Anthropic 之前的做法，是通过 context reset 加结构化 handoff 来缓解上下文过长导致的失稳。这里的思想很值得记住：

• 不是一味保留更多上下文。
• 而是敢于清空上下文，再用结构化工件把必要状态交给下一个 agent。

这个思路和很多人的直觉相反。很多人以为“上下文越完整越好”，但作者指出，压缩历史并不能完全解决模型的“上下文焦虑”。有时真正有效的不是带着旧包袱继续跑，而是让新 agent 带着清晰交接重新开始。

到了 Opus 4.6，作者又重新评估这套 harness，发现一些原本必要的结构已经不再承重，于是去掉 sprint 拆分，保留 planner 和 evaluator，并把 QA 改为构建末尾的集中评审。这个变化背后其实是全文最成熟的工程观点：

harness 不是固定模板，而是一个要随着模型能力变化不断删改的系统。

最值得借鉴的，不是“三代理架构”，而是这三个工程原则

读完整篇文章，我觉得最值得带走的不是具体 prompt，也不是 agent 数量，而是三条更普适的原则。

1. 先承认模型有盲区，再用结构把盲区包起来

作者并没有假设模型会天然擅长长任务、自评、审美判断或 QA。相反，他先承认模型在哪些地方不可靠，再为这些薄弱点设计专门结构。

这是一种非常成熟的 AI 工程思路：不是要求模型“变完美”，而是让系统对模型的不完美有弹性。

2. 评价标准本身就是产品能力的一部分

文章里 evaluator 的价值，不只是“检查 bug”，而是把“什么叫好结果”明确写进系统。对设计来说，这叫评分标准；对编码来说，这叫 sprint contract、验收条件和 Playwright 测试。

换句话说，模型产出的上限，部分取决于你能否把验收标准写得足够清楚。

很多 agent 项目做不起来，不是生成能力太弱，而是没有把“什么算完成、什么算优秀、什么算失败”表达清楚。

3. 每个脚手架组件都应该被持续怀疑

这是我最喜欢的一点。作者没有把早期成功经验神化，而是主动去测试：

• sprint 还必要吗？
• context reset 还必要吗？
• evaluator 的收益是否还覆盖它的成本？

这意味着 harness 设计不是“越复杂越强”，而是“复杂度必须证明自己仍然值得存在”。模型一升级，旧脚手架就可能从增益变成负担。真正好的工程团队，会不断重跑这个判断。

这篇文章对我们今天做 agent 有什么现实启发

如果你正在做 coding agent、设计 agent、工作流 agent，Anthropic 这篇文章至少给了三个非常实用的提醒。

• 第一，先别急着追求全自动。把任务拆成规划、执行、评估三个层次，通常比让一个 agent 从头包到尾更稳。
• 第二，主观任务也可以做，只要你愿意花力气把“感觉”变成“准则”。
• 第三，新模型出现后，不只是换模型参数，更要回头检查老 harness 里哪些还承重，哪些已经是历史包袱。

从这个角度看，所谓 agent engineering，核心并不是“怎么多调几个 API”，而是如何把模型能力、任务结构、评价标准和运行成本一起设计成一个可持续迭代的系统。

我的结论

这篇文章最有价值的地方，在于它把一个正在形成中的行业共识讲得很具体：未来 AI 应用的竞争力，很大程度上会来自 harness design，而不仅仅来自模型选型。

模型当然会持续变强，但随着模型变强，harness 并不会消失。它只会迁移到新的边界上，去解决那些“模型单独还做不好，但加上结构就能明显变好”的问题。

所以这篇文章真正想告诉我们的，也许不是“Anthropic 又做出了一个三 agent 系统”，而是：

有趣的工程空间并不会因为模型变强而缩小。真正的机会，在于持续找到下一个仍然值得加脚手架的组合点。