Anthropic《Harness design for long-running application development》结构译述
本文基于 Anthropic 于 2026-03-24 发布的文章《Harness design for long-running application development》进行结构化译述。正文保留原文结构与主要判断，加入少量关键英文原句作为观点锚点。
- 原文标题：
Harness design for long-running application development - 发布方：Anthropic Engineering
- 发布日期：
2026-03-24 - 原文链接：anthropic.com/engineering/harness-design-long-running-apps
为什么值得读
Section titled “为什么值得读”如果说上一篇《Effective harnesses for long-running agents》讲的是怎样让长任务 agent 不要掉线，那么这篇文章讲的就是下一步：怎样让 harness 不只是“接得住任务”，还真正提升输出上限。
Anthropic 在这里把问题推得更远了一层。他们发现，只靠单个 agent 即使能连贯地工作，也会卡在两个天花板上：主观质量难以稳定提升，以及 agent 很难对自己的产出做严格审查。于是，这篇文章开始从单 agent harness 走向多 agent 结构。
当任务同时包含主观质量和客观正确性时，harness 的关键不只是把任务拆小，而是让不同 agent 分别承担规划、生成和评审职责，并把“好不好”转写成可 grading 的规则。
文章结构译述
Section titled “文章结构译述”从旧 harness 的天花板开始（对应原文：Why naive implementations fall short）
Section titled “从旧 harness 的天花板开始（对应原文：Why naive implementations fall short）”Anthropic 开篇先回顾此前 long-running harness 的成果：initializer agent、逐功能推进的 coding agent、跨 session handoff，这些已经能让 agent 在长任务上明显优于裸跑模式。但对更复杂任务，这套结构仍然会失效。
文章指出两个持续存在的问题。第一是长期任务中的连贯性衰减，尤其当上下文逐渐变长时，模型会开始出现“context anxiety”，也就是明明任务没完成，却逐渐倾向于收尾。第二是自我评估失真，模型容易过于宽容地夸奖自己的产出，尤其在前端设计这类主观性任务上更明显。
原文里一个很关键的问题句是："is this design good?" 之所以值得保留，是因为它准确暴露了难点。很多任务不是没有标准，而是标准太隐性、太主观，模型无法稳定把它变成可执行判断。
先在前端设计上验证 evaluator 思路（对应原文：Frontend design: making subjective quality gradable）
Section titled “先在前端设计上验证 evaluator 思路（对应原文：Frontend design: making subjective quality gradable）”Anthropic 没有一上来就在复杂全栈任务中试图解决所有问题，而是先把最主观的场景拿出来单独攻克：前端设计。这里的核心思路，是先把“好设计”这类抽象判断转写成更可 gradable 的 criteria。
他们给前端设计 evaluator 写了四类标准：design quality、originality、craft、functionality。其中 design quality 和 originality 被赋予更高权重，因为模型默认已经比较容易做出“能用”的页面，但容易滑向平庸、套模板、带典型 AI 味道的输出。
这里最有启发的一点，不是 criteria 的具体名字，而是 harness 开始显式表达审美倾向。比如原文中提到 "museum quality" 这种措辞，实际上会直接把生成器往某种更激进、更明确的风格方向推。换句话说，grader 不只是验收工具，也在反向塑造生成空间。
generator 和 evaluator 的反馈回路（对应原文：Frontend experiment 的 loop）
Section titled “generator 和 evaluator 的反馈回路（对应原文：Frontend experiment 的 loop）”在前端实验里，Anthropic 用 Claude Agent SDK 搭了一个 generator-evaluator 循环：生成器先产出前端，评审器再借助 Playwright MCP 亲自打开页面、导航、截图、检查细节，然后按 criteria 打分并输出详细 critique。
关键不只是“打分”，而是 evaluator 的反馈真的会作为下一轮 generator 的输入。每一轮生成器都要根据评审结果决定：继续沿当前方向优化，还是直接换一种审美路线重新来过。这样一来，系统不再是单次生成，而是一个带明确外部反馈的改进回路。
文章还强调，这个过程不一定线性变好。有时中间轮次反而比最后一轮更有意思，后续迭代会把实现推向更复杂、更冒险的方向。但 Anthropic 的判断是，这种可迭代的外部评价，本身就是突破“安全但平庸”默认输出的重要杠杆。
把思路扩展到全栈应用开发（对应原文：Scaling to full-stack coding）
Section titled “把思路扩展到全栈应用开发（对应原文：Scaling to full-stack coding）”这部分是全文真正的核心升级。Anthropic 把 generator-evaluator 模式移植到完整应用开发，并在旧的 long-running harness 基础上增加了 planner，于是得到 planner、generator、evaluator 三代理结构。
planner 负责把短 prompt 扩展成完整产品规格说明，但刻意不写过细的技术实现，以免错误过早固化；generator 按 feature 或 sprint 推进构建；evaluator 用 Playwright MCP、接口检查和数据库状态验证来执行 QA，并按产品深度、功能、视觉设计、代码质量等 criteria 打分。
这里最值得注意的是 evaluator 不只是末端验收。generator 和 evaluator 在每个 sprint 前先协商一个 sprint contract，先定义这一轮“done 长什么样、要怎么验证”，再开始写代码。这一步把高层产品规格和具体可测试实现之间的空隙补上了。
sprint contract 与文件化协作（对应原文：The architecture）
Section titled “sprint contract 与文件化协作（对应原文：The architecture）”Anthropic 把 agent 之间的沟通做得非常工程化。几个 agent 不是靠隐含记忆协作，而是通过文件交换：一个 agent 写文件，另一个 agent 读后回应，再继续往下传。这种设计的好处，是把多 agent 协作从“会话里的隐式上下文”搬到了可检查、可继承的 artifacts 上。
sprint contract 是这里的关键中间件。它让 generator 不能随便凭直觉定义完成标准，也让 evaluator 不是事后拍脑袋指出问题。双方先对齐这轮要交什么、用什么标准验收，再让生成器实施。这个步骤降低了“做偏了但没人及时发现”的概率。
实验结果与 evaluator 的现实边界（对应原文：Running the harness / Results from the updated harness）
Section titled “实验结果与 evaluator 的现实边界（对应原文：Running the harness / Results from the updated harness）”Anthropic 用一个复古游戏编辑器和后续的浏览器内 DAW 作为案例，对比了 solo run 与 full harness。文章结论很明确：full harness 成本高很多，但产品完整性、功能深度与可用性都显著更强。
尤其值得注意的是 evaluator 的作用，不是让产出完美，而是把很多“看起来挺像回事，但实际不能用”的问题揪出来。文章展示的 bug 例子很具体：UI 操作路径不通、API 路由定义顺序有误、关键交互只有表面展示没有真正实现。也就是说，evaluator 的价值主要体现在找最后一公里问题，而不是代替生成器完成主体工作。
Anthropic 同时强调 evaluator 不是恒定必要的。随着模型能力提升，一些原本需要强评审才能完成的任务，可能会逐渐落回模型的自然能力边界内。harness 设计因此不是固定模板，而是要随着模型进步重新审视哪些部分还在真正提供 lift。
What comes next（对应原文：What comes next）
Section titled “What comes next（对应原文：What comes next）”文章最后给出的判断非常成熟：模型变强后，harness 的空间不会消失，只会迁移。原文中一个重要短句是 "the space of interesting harness combinations"。它的意思不是组合越多越好，而是随着模型基线能力变化，真正值得设计的 scaffold 会改变。
这也是这篇文章最重要的工程启发。不要把 harness 当成一次性定稿的脚手架，而应把它看成一组关于模型边界的假设。模型变了，任务变了，哪些结构还“load-bearing”，哪些已经是多余开销，都要重新验证。
关键观点提炼
Section titled “关键观点提炼”- 当任务包含主观质量时，必须先把隐性的“好”转写成可 grading 的 criteria。
- evaluator 的价值不只是验收，更在于给 generator 提供迭代方向。
- 三代理结构中，planner 解决规格扩展，generator 负责建设，evaluator 负责验证与反馈。
- sprint contract 是高层规格与可测试实现之间的重要桥梁。
- 随着模型能力变化，harness 中哪些部件仍然有效，需要持续重估。
对工程团队的启发
Section titled “对工程团队的启发”如果你在做能跑几个小时的复杂 agent，这篇文章很值得拿来当进阶版参考。它最大的启发不是“多 agent 一定更好”，而是你要先问清楚：当前系统的瓶颈到底是规划、生成、验证，还是自我评估偏差。只有明确瓶颈，角色拆分才有意义。
另一个很现实的启发是，grader 不只是评分器，也是一种偏好注入机制。你给 evaluator 写下的标准，本质上会定义系统向什么方向优化。对主观输出尤其如此，criterion 的措辞本身就是产品方向的一部分。
原文链接与出处说明
Section titled “原文链接与出处说明”原文由 Anthropic Engineering 发布：
本文为结构化译述与观点整理。如需查看原文案例、成本对比与更完整的上下文，请直接阅读原始页面。