Harness设计：长时间运行应用开发的多智能体架构深度解析

一、引言

当我们让AI自主开发一个完整的全栈应用时，真正棘手的问题往往不是“能不能写出代码”，而是：它能不能持续工作几个小时、能不能把任务真正做完、做出来的东西是不是既能用又好用。

Anthropic工程团队的 Prithvi Rajasekaran 在 2026 年 3 月发表的工程博文 Harness design for long-running application development，讨论的正是这个问题：当模型不再只负责“补几行代码”，而是要在数小时内持续完成规划、实现、验证和修复时，应该怎样为它设计一套外部运行框架，让它从“会写代码”进化到“能交付应用”。

文章提出的核心方案是 Harness。它不是单一 Prompt，也不是一个更复杂的工作流脚本，而是一种围绕模型能力边界搭建的运行时编排系统：

把生成、评估、规划、状态传递和验收标准从单个模型内部“外部化”出来，交给多个专职 Agent 和一组结构化工件共同完成。

这篇文章值得深挖的原因在于，它讨论的不是“如何让模型更聪明”，而是一个更工程化的问题：当模型本身并不稳定、也并不总是能自我纠错时，系统设计应该如何补位。

二、先给结论：Harness 真正解决的是什么

如果只看表面，很容易把 Harness 理解成“多加了一个 QA Agent”。但这篇博文真正有价值的地方，在于它揭示了长时间运行应用开发的三个系统性难题，以及对应的工程解法。

2.1 它解决的不是“写代码能力”，而是“任务闭环能力”

模型经常能产出“看起来像完成了”的代码，却做不到：

• 在数小时任务中保持目标一致性
• 在复杂交互里发现自己忽略的问题
• 在主观质量上持续迭代，而不是停留在第一版的“差不多”

因此，Anthropic 的目标不是让单个 Agent 一次写对，而是让系统具备一种持续逼近高质量结果的闭环能力。

2.2 它的核心不是多 Agent，而是“三种外部化”

从工程视角看，Harness 最关键的不是 Agent 数量，而是把原本试图压进单个上下文窗口中的三个任务拆出来：

这三种外部化，本质上是在把模型不擅长的事情交给系统来兜底。

2.3 它不是固定架构，而是“随模型能力变化的脚手架”

文章最有启发性的一点是：Harness 并不被描述为一套永久正确的架构。相反，Anthropic 明确展示了从 Sonnet 4.5 到 Opus 4.6 的演进过程中，某些组件是如何被移除的。

也就是说，Harness 不是产品，而是脚手架；不是原则本身，而是原则在某一代模型能力边界上的具体实现。

三、长时间运行应用开发的两大瓶颈

在设计 Harness 之前，Anthropic 团队在让 AI 长时间自主工作时，首先遇到的是两个非常典型、但很少被系统讨论的问题。

3.1 上下文焦虑：模型会在“快到极限”时提前收工

旧版模型（如 Sonnet 4.5）在上下文窗口接近限制时，会出现一种近似“焦虑”的行为：它不是真的完成了任务，而是开始倾向于尽快结束任务。

这会带来一种非常糟糕的工程现象：

• 任务看似进入收尾阶段，实则许多功能还没打通
• 模型开始更频繁地产生“总结性语言”，而不是继续推进实现
• 它会在关键地方留下“半截工程”——界面有了，交互没做完；API 写了，联调没验证；逻辑补了，但缺少最终测试

为什么“上下文压缩”不够

一个很自然的想法是做上下文压缩，即在同一对话内总结历史，再让模型继续干活。但文中给出的经验是：压缩并不能消除模型对上下文边界的行为偏移。

Anthropic 采用的是更激进但也更有效的做法：

• 直接启动一个新的 Agent
• 清空当前上下文窗口
• 通过结构化交接工件，把必要状态移交给新 Agent

这不是简单的“缩短历史”，而是重置运行时心理负担。从系统设计角度说，这等于把长期任务拆成多个局部最优的连续任务片段。

3.2 自我评估偏差：模型对自己的作品往往过于宽容

第二个问题更关键：让同一个 Agent 既做事又验收，往往会产生严重偏差。

它的问题不是完全不会发现错误，而是：

• 容易把“局部可用”误判为“整体可交付”
• 容易把“界面看着没问题”误判为“交互已经完成”
• 在主观任务上，容易对平庸结果给出过高评价

这类偏差在前端设计里尤其明显。一个模型自己做出的页面，只要颜色不冲突、布局不崩，就很容易被自己判定为“还不错”；但从真实设计审美看，它可能依然非常模板化、缺乏原创性。

因此，Anthropic 选择把“执行者”和“评估者”彻底分开，让评估器成为一个被刻意调优为更苛刻、更怀疑、更偏向发现问题的独立角色。

四、核心架构：生成器—评估器反馈循环

Harness 的最小可行单元，是一个受到 GAN 思想启发的生成器—评估器循环。这里借用的不是 GAN 的训练机制，而是其最核心的系统直觉：高质量输出不是靠一次性生成得到的，而是靠“生成—判别—再生成”的对抗式迭代逼出来的。

4.1 这套循环是如何工作的

它的基本流程并不复杂：

1. 生成器 Agent 根据任务目标产出代码、页面或功能实现
2. 评估器 Agent 通过真实运行环境观察结果，而不是只看代码片段
3. 评估器给出结构化评分与详细批评
4. 生成器基于反馈做出策略判断：是沿当前方向继续优化，还是彻底转向新的方案
5. 重复迭代，直到关键维度达标

注意，这里最重要的不是“有反馈”，而是反馈必须满足两个条件：

• 结构化：不能只是“再优化一下 UI”，而要明确指出差在哪个维度、为什么差、怎么验证改好了
• 可操作：必须让生成器能据此做策略决策，而不是停留在模糊的主观评价上

4.2 为什么这不只是“多加了一个 QA”

从系统设计角度看，这个环路真正带来的提升，是把输出优化从“Prompt 驱动”升级为“闭环控制”。

单 Agent 模式更像开环系统：

• 输入一个目标
• 生成一个结果
• 假设模型会自己负责质量

而 Harness 则是闭环系统：

• 系统持续测量输出质量
• 将偏差反馈给生成器
• 让下一轮生成朝着更小误差的方向迭代

对工程师来说，这个差异非常关键。前者依赖模型一次性命中答案，后者依赖系统不断减少偏差。 当任务足够复杂时，后者明显更可靠。

4.3 关键技术支撑：不是“看代码”，而是“操作应用”

文中一个非常务实的设计是：评估器大量使用 Playwright MCP。这意味着评估器不是像 code review 一样只读源代码，而是像真人测试人员一样：

• 访问运行中的页面
• 点击按钮
• 导航不同视图
• 截图并观察视觉结果
• 验证交互路径是否闭环

这一步非常关键，因为很多真实缺陷并不出现在代码语法层，而出现在跨层连接处：

• 前端按钮存在，但没绑定正确事件
• API 返回成功，但状态没有真正持久化
• 路由定义没问题，但具体匹配顺序导致端点失效
• 页面布局看上去存在，但可用性和流程引导很差

换句话说，Harness 的评估不是静态审查，而是运行时验收。

五、前端设计实验：如何把“审美”变成可迭代的工程对象

Anthropic 首先在前端设计任务上验证了 Harness。这个选择很有代表性，因为设计类任务恰好暴露了单 Agent 自评最弱的一面：你很难要求模型凭空“更有品位”，但你可以要求系统更严格地区分什么叫平庸、什么叫优秀。

5.1 四维度评分体系：把主观判断拆开

他们把“这个页面好不好”拆成了四个维度：

这套标准的价值不只在于评分本身，而在于它强迫系统承认：设计不是单一维度的“好看”，而是多个维度共同达标。

例如：

• 一个页面可能有不错的色彩，但原创性很差
• 一个页面可能很有创意，但功能性很弱
• 一个页面可能布局没崩，但工艺水平很粗糙

如果没有维度拆分，评估器就很容易给出“整体还行”的宽松判断；一旦拆分后，系统就能精准知道下一轮该优化哪里。

5.2 文中最值得注意的点：评估器会逼生成器“转向”，而非只做微调

很多人理解迭代时，默认是“在第一版上继续修修补补”。但从文中的实验看，Harness 的价值之一恰恰在于：评估器不仅会要求优化，还会逼迫生成器放弃已经证明平庸的方向。

文章举的荷兰艺术博物馆网站就是典型例子：

• 早期版本更像一个普通落地页
• 随着迭代推进，系统逐步意识到这种方案虽然“合格”，但缺少独特性
• 到后期版本，生成器转向了一个更具空间感的 3D 透视房间体验

这说明 Harness 做的不只是质量抛光，更是在帮助系统进行解空间搜索：当当前设计方向的上限已经不高时，系统需要探索新的方向，而不是继续在旧方向上做局部优化。

5.3 这对产品设计意味着什么

Anthropic 的这套做法给了一个很强的工程启发：

对于主观任务，最有效的系统设计，不是让模型学会“审美”，而是让评估机制足够具体，能持续淘汰平庸方案。

也就是说，审美提升不是直接来自模型“更懂设计”，而是来自系统对低质量方案的不断否决。

六、从前端到全栈：三智能体协作架构

当前端实验验证有效后，Anthropic 把相同思路扩展到了全栈应用开发，并将 Harness 进一步演化为一个包含 规划器、生成器、评估器 的三智能体系统。

6.1 三个角色分别在优化什么

这三类 Agent 不是简单分工，而是在分别优化不同目标：

这个拆分特别重要，因为它避免了单 Agent 在不同目标之间反复切换：

• 规划需要发散和抽象能力
• 编码需要持续推进和局部细化
• 评估需要挑错和怀疑能力

把这三种目标硬塞给一个 Agent，同一轮里就可能出现“既想扩展 scope，又想赶紧写完，又想替自己辩护”的目标冲突。Harness 的做法，本质上是通过角色隔离来避免这种内耗。

6.2 规划器：不是“写一份 PRD”，而是主动扩展问题空间

规划器的职责，不是把用户那 1-4 句话 Prompt 稍微润色一下，而是把它扩展成真正可驱动实现的规格说明。文中特别强调了两个点：

• 规划器要主动寻找更有雄心的 Scope
• 规划器要主动挖掘AI 可以嵌入产品的机会

这很值得注意。Anthropic 不是把规划器当成一个“记录员”，而是把它当成一个产品放大器。在案例中，很多原始 Prompt 只描述了一个传统产品轮廓，但规划器会把它扩展成更完整的功能集，甚至引入 AI 生成能力，使最终产物的上限显著高于用户最初输入。

6.3 生成器：用 Sprint 推进，但不靠 Sprint 自证完成

在 Sonnet 4.5 阶段，生成器以 Sprint 方式工作：

• 每轮从规格中选一个功能块推进
• 写完后先做自评
• 再交由评估器验收

这里最重要的不是 Sprint 本身，而是 Sprint 的工程意义：它把一个长达数小时的大任务，拆成若干可被验证的小闭环。

但 Anthropic 同时也承认：生成器的自评只能作为局部检查，不能当成正式验收。真正决定这一轮是否成功的，仍然是外部 QA。

6.4 评估器：像真正的 QA 一样横跨 UI、API 和数据库

评估器的强大之处在于，它不是只盯着某一层：

• 它会点击 UI，确认交互路径是否成立
• 它会检查 API 响应，确认服务端逻辑是否成立
• 它会看数据库状态，确认数据是否真的写入和更新

这意味着评估器天然能发现“跨层错位”问题。很多应用之所以“看上去完成了，实际上不可交付”，恰恰是因为每一层单独看都像是正常的，但层与层之间没有真正闭合。

6.5 Sprint 合同：Anthropic 最工程化、也最容易被低估的设计

文中我认为最精彩的设计之一，是 Sprint 合同（Sprint Contract）。

在 Builder 真正写代码之前，Builder 和 QA 需要先协商两件事：

• 这一轮到底要交付什么
• 交付完成以后，怎样验证它真的完成了

这个设计的价值极高，因为它把“验收标准”前移了。

如果没有合同机制，常见情况会是：

• 规划器写得很高层
• 生成器按自己的理解写了一版
• 评估器按另一套理解否掉
• 双方不断返工，但并不清楚争议到底在哪里

而 Sprint 合同的作用，就是把“做什么”和“如何算做完”变成一个显式协议。这实际上是在为 Agent 系统引入一种轻量级需求对齐协议。

6.6 基于文件的通信：简单，但恰好适合长任务

三个 Agent 之间通过文件系统通信，这看起来朴素，但恰恰非常适合长时间运行的任务：

• 文件天然可持久化
• 交接过程天然可追溯
• 状态在 Agent 重启后仍可恢复
• 没有复杂的消息队列依赖

更重要的是，文件让“状态”从上下文窗口里解耦出来。Agent 可以丢上下文，但项目状态不会丢。这一点正是 Harness 能支撑长任务的基础设施前提。

七、案例分析：Harness 的价值到底体现在哪里

7.1 案例一：复古游戏制作器

原始 Prompt 很简单：

“Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.”

如果单看 Prompt，你会以为这是一个“做出编辑器原型”的任务。但在 Harness 下，系统并没有止步于一个原型，而是把它扩展成更完整的产品：更多功能、更细的交互、更高的完成度，以及额外的 AI 辅助能力。

7.2 单 Agent vs Harness：差异不是线性的，而是台阶式的

文中的对比非常有说服力：

这里最值得强调的一点是：Harness 带来的不是 10% 或 20% 的优化，而是从“能演示”到“能使用”的级别跨越。

7.3 评估器发现的 Bug，恰恰说明了它为什么必要

文章中列出的几个 Bug 非常典型：

• 矩形填充工具只填了起点和终点，而没有真正填充区域
• 删除键逻辑判断有误，导致实体无法删除
• FastAPI 路由顺序不对，使 PUT /frames/reorder 被动态路由错误吞掉，返回 422

这些问题有一个共同特征：它们不是“写没写这段代码”的问题，而是“系统在真实运行中是否真的成立”的问题。

换句话说，这些 Bug 之所以重要，不是因为它们难修，而是因为它们揭示了单 Agent 自评的盲点：模型很容易在“局部代码合理”时，误以为“整体功能成立”。

7.4 案例二：浏览器端 DAW

第二个案例是浏览器端数字音频工作站（DAW），Prompt 更宏大，也更能测试模型在长任务中的持续能力：

“Build a fully featured DAW in the browser using the Web Audio API.”

这个案例使用的是针对 Opus 4.6 优化后的精简 Harness。其指标大致如下：

更重要的是，即使在 Opus 4.6 这样更强的模型下，评估器依然发现了关键缺口：

• 音频片段无法拖拽
• 录音功能只是空壳
• 效果器缺少真正可理解的图形化可视化

这说明一个事实：模型变强，会降低 Harness 的复杂度需求，但不会自动消除对外部评估的需求。

7.5 这两个案例共同证明了什么

如果把两个案例放在一起看，可以得到一个更清晰的判断：

1. 规划器提高的是上限：它让任务从“一个 demo”变成“一个完整产品方向”
2. 生成器提高的是推进速度：它把复杂规格持续落到代码上
3. 评估器提高的是下限：它防止系统在“看似完成”的假象中停下来

也就是说，Harness 的真正价值不在于某个 Agent 特别强，而在于三个角色共同塑造了一个更高上限、更高下限的系统。

八、模型变强以后，为什么 Harness 反而要变简单

Anthropic 在文中反复强调一个原则：随着模型能力提升，Harness 应该被主动简化。 这一点非常重要，因为很多工程系统一旦做复杂了，就会天然倾向于继续堆复杂度；而 Anthropic 的做法恰恰相反。

8.1 Sonnet 4.5 时代：复杂架构是在补模型短板

在 Sonnet 4.5 阶段，复杂 Harness 是必要的，因为模型本身存在明显短板：

• 长上下文运行不稳定
• 复杂任务容易提前收尾
• 自主规划能力不足
• 需要显式拆成多个 Sprint 才能稳步推进

此时，引入 Sprint、合同、上下文重置、密集 QA，本质上是在用系统设计弥补模型能力缺陷。

8.2 Opus 4.6 时代：移除不再提供价值的部件

到了 Opus 4.6，Anthropic 观察到：

• 模型能更长时间连续工作
• 对长任务的整体把握更强
• 自我修正能力比过去更好
• 许多原本必须显式拆分的步骤，如今可以自然完成

于是，他们果断移除了部分脚手架，例如 Sprint 结构和频繁上下文重置，把系统压回更简单的形态。

这背后的思想很工程化：复杂度本身从来不是价值，只有在它确实能对冲风险时才值得存在。

8.3 为什么评估器被保留下来了

最值得注意的是：在被删掉那么多部件之后，评估器并没有消失。

这说明 Anthropic 已经在实践中验证了一个稳定结论：

规划能力、自我修正能力和长上下文能力会随着模型升级而改善，但独立评估的价值衰减得最慢。

原因很简单：

• 规划和分解属于“内部思考能力”，模型强了以后会自然改善
• 但评估尤其是运行时评估，属于“输出后的独立验证”，它天然站在模型自我叙述之外

因此，评估器更像是一种长期存在的“系统安全边界”，而不是某一代模型的过渡补丁。

九、从 Anthropic 的实践中，可以提炼出什么工程方法论

如果把这篇文章只当成 Anthropic 的内部经验分享，价值其实被低估了。更有意义的做法，是把它提炼成一套可迁移的方法论。

9.1 第一条：把模型当组件，而不是当完整系统

Harness 的前提假设非常明确：模型不是系统本身，模型只是系统中的一个高能力但不稳定的组件。

一旦接受这一点，很多设计就顺理成章了：

• 评估应该外置
• 状态应该外置
• 验收标准应该外置
• 关键过程应该可追溯、可恢复、可重启

这和传统分布式系统设计并没有本质区别：当某个组件能力强但行为不完全可预测时，系统要通过协议、状态和边界来约束它。

9.2 第二条：先让系统有“纠偏能力”，再追求一次做对

很多 AI 工作流都默认一个目标：通过更好的 Prompt、更强的模型，让第一次输出尽量正确。但 Anthropic 的实践指向另一种思路：

在复杂任务上，比起追求“一次命中”，更重要的是让系统具备“持续纠偏”的能力。

原因很现实：

• 复杂任务的正确解往往不是单点，而是一个需要搜索的区域
• 主观质量本来就不可能靠一次生成达到最优
• 真实产品的缺陷很多只会在运行后显现

因此，Harness 的价值不在于“确保第一次就做对”，而在于确保做错了也能被发现，并继续逼近正确答案。

9.3 第三条：把“是否值得上 Harness”做成判断题，而不是信仰题

并不是所有任务都值得套上完整 Harness。结合文中经验，我认为可以用三个问题来判断：

问题一：任务时长是否超过单轮高质量上下文的稳定边界？

如果一个任务 10 到 20 分钟就能稳定完成，上下文重置、状态交接这些机制通常意义不大。

问题二：结果质量是否依赖真实交互，而不是只看静态代码？

如果用户价值体现在复杂 UI、端到端流程、数据库联动和功能可用性上，那么独立评估器往往是值得的。

问题三：任务是否处于模型能力边界附近？

如果模型对这类任务已经非常成熟，Harness 可能只是额外成本；但如果任务本身涉及创新设计、复杂交互或长链路集成，Harness 往往会显著提高成功率。

简化成一句话就是：任务越长、越主观、越依赖运行时验证、越接近模型能力边界，就越值得引入 Harness。

9.4 一个可落地的最小版 Harness

如果团队想把文中的思想迁移到自己的 AI 开发流程里，不一定要一步到位做三智能体系统。一个最小可用版本其实可以是：

1. 一个 Builder Agent：负责实现功能
2. 一个 Evaluator Agent：只做运行时验证和验收反馈
3. 一组文件化工件：至少包括任务说明、验收标准、修复反馈
4. 一个退出条件：例如“所有关键测试通过，且四个维度评分均达阈值”

也就是说，最先应该搭起来的不是复杂编排，而是：

• 独立评估
• 结构化反馈
• 显式验收标准

这三件事，几乎构成了 Harness 价值的最小闭包。

十、总结：Anthropic 真正展示的是一种“模型之上的系统设计”

回到最开始的问题：Anthropic 这篇文章真正讨论的，究竟是什么？

我的判断是，它讨论的不是某个 Agent Prompt 的写法，也不是某种特定模型的技巧，而是一个更本质的问题：

当模型已经足够强，但还不足以稳定独立完成复杂应用开发时，我们应该如何在模型之外搭建一层系统，使其输出从“偶尔惊艳”变成“可重复交付”。

Harness 的答案非常清晰：

• 用独立评估器解决自评偏差
• 用状态外部化解决长任务稳定性问题
• 用显式验收和合同机制解决对齐问题
• 并随着模型能力提升，持续移除不再必要的复杂度

这套方法最有启发性的地方，在于它并不神化模型，而是把模型放回到工程系统里看待。模型负责生成潜力，系统负责质量边界。

从 Sonnet 4.5 时代的复杂多 Sprint 架构，到 Opus 4.6 时代的精简单次 QA，Harness 的演化本身已经说明了一切：最好的 AI 系统，不是最复杂的系统，而是能随着模型进步不断收缩脚手架的系统。

原文链接：Harness design for long-running application development — Anthropic Engineering Blog, 2026.03.24

× 爱折腾的工程师

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post