题记：本文编译自 Anthropic 官方博客《A harness for every task: dynamic workflows in Claude Code》，由 Anthropic 工程师 Thariq Shihipar 和 Sid Bidasaria 撰写。

Claude Code 的默认模式是单 Agent，一个上下文窗口搞定规划和执行。大多数编程任务这就足够好用了。

但是也有很多场景你怎么优化都跑不好。单 Agent 在长时间运行、大规模并行、需要对抗性验证的任务上，有三个已知的退化模式：

第一个是偷懒。让它做一轮安全审查，50 个检查项查到 20 个就宣布完成了。这不是幻觉，是 Agent 在长上下文里的行为退化。第二个是自我偏爱。让它评判自己的产出，它天然倾向于给好评，需要严格验证的场景里这是致命的。第三个是目标漂移。上下文压缩是有损的，每压缩一次，原始需求里的边缘条件、约束细节就丢一点。时间长了之后，Agent 在优化的目标可能已经偏离了你最初给它的任务。

这三个问题不是模型能力问题，是单上下文窗口同时承担规划和执行带来的架构局限。Anthropic 显然也清楚这一点，所以之前陆续搞了 Research、安全审计、Agent Teams、Code Review 这些定制 Harness，每个都是针对特定任务类型写死的调度逻辑。

上周他们把这个能力泛化了：Claude Code 现在可以自己写调度逻辑，针对当前任务实时生成编排脚本，也就是 Dynamic Workflows。

工作原理

动态工作流的核心思路是：用独立的子 Agent 各自占一个干净的上下文窗口，每个子 Agent 只干一件事，由一个确定性的 JavaScript 脚本来调度它们的执行顺序和依赖关系。

动态 vs 静态：区别在哪

之前用 Claude Agent SDK 或者claude -p 来编排多个 Claude Code 实例，本质上是静态工作流。你得提前写好脚本，考虑各种边界情况，写出来的东西往往比较通用。

动态工作流不一样。Claude Code 自己看任务，自己写调度脚本，针对当前这一个具体任务量身定制。Opus 4.8 的能力已经足够让它自己写出高质量的 Harness。

我自己试了一下，感受是：对于那些你本来就知道怎么拆分的任务，静态工作流更可控。但对于"我大概知道要做什么，但不确定最优的拆分方式"的场景，让 Claude Code 自己决定怎么调度确实省事。

六种调度模式

Claude Code 在构建动态工作流时会组合使用几种基本模式：

最基础的是分类路由，一个分类 Agent 判断任务类型，分发给不同的处理 Agent。也可以反过来，在最后加一个分类器决定输出格式。

用得最多的是扇出合并。把任务拆成很多小步，每个小步一个独立 Agent，最后一个合并 Agent 汇总结果。好处是每个子 Agent 有干净的上下文，互不污染。

对抗验证是直接针对自我偏爱问题的解法：每个生成 Agent 配一个独立的验证 Agent，专门挑毛病。生成过滤类似，先大量生成，再按标准筛选去重，只留通过验证的。

然后是锦标赛模式。N 个 Agent 用不同策略做同一件事，两两比较淘汰，留下赢家。最后是循环到完成，不设固定轮次，一直跑到满足停止条件为止。

这些模式可以组合。比如先扇出，每个分支内部做对抗验证，合并时再跑一轮锦标赛选最优方案。

实际能干什么

那这些模式实际能用在哪？原文列了不少场景，我挑几个觉得实用的说。

大规模迁移和重构

Bun 从 Zig 重写成 Rust 就用了工作流。核心思路是：把需要改的地方拆成独立单元（调用点、失败的测试、模块），每个单元派一个子 Agent 在独立的 worktree 里修，另一个 Agent 做对抗性 Review，通过了再合并。

这个场景我觉得价值最大。平时做大规模重构最头疼的就是改着改着上下文丢了，或者改了 A 忘了 B 也要跟着改。每个修改点一个独立 Agent，天然避免了交叉污染。

深度验证

如果你写了一篇技术文章，里面有大量事实性声明，可以用工作流让一个 Agent 先把所有事实性声明提取出来，然后每个声明派一个子 Agent 去核实。还可以再加一层，验证核实 Agent 引用的信息源本身是否可靠。

排序

对定性内容排序（比如按 Bug 严重程度排 1000 条工单），单次 Prompt 的质量会随数量急剧下降。工作流的做法是用锦标赛模式，两两比较。比较判断比绝对评分可靠得多，而且每次比较是一个独立 Agent，确定性的循环逻辑只负责维护对阵表。

规则遵守

有时候明明在 CLAUDE.md 里写了规则，但 Claude Code 跑着跑着就忘了。这时候，就可以用工作流做一个验证层：一条规则一个验证 Agent，每个验证 Agent 用怀疑论者的视角去检查是否违规。

反过来也行：扫最近的 session 日志和 Code Review 评论，找反复出现的纠正，聚类、验证（这条规则真的能防住之前的错误吗？），然后把确认有效的提炼成新的 CLAUDE.md 规则。

根因分析

调试最怕的是认定了一个假设就一路追到底。单 Agent 在一个上下文窗口里特别容易犯这个错误。工作流可以结构性地避免：分别从日志、文件变更、数据状态生成独立假设，每个假设面对一组验证者和反驳者。

这个模式不只适用于代码。销售数据下降、数据管道故障、任何需要事后复盘的场景都能用。

大规模分流

每个团队都有处理不完的支持队列。工作流可以对每条工单做分类、去重（跟已有的 ticket 对比）、尝试自动修复或升级给人。

这里有个有意思的设计模式叫隔离区：读不可信外部内容的 Agent 不允许执行高权限操作，高权限操作由另一个 Agent 负责。读和写分离，避免 prompt injection 导致的越权。

什么时候不需要工作流

动态工作流消耗的 token 显著更多，适合复杂、高价值的任务。

日常写代码，问自己一个问题：这件事真的需要 5 个 Reviewer 组成的评审团吗？大多数常规编程任务可能并不需要。

我的判断标准是：如果你能在 Prompt 里一句话描述清楚要做什么，而且做完之后你自己能快速验证结果，那就不需要工作流。需要工作流的场景通常有两个特征：任务可以被拆成独立的并行单元，或者验证成本高到你不想自己一个个检查。

用法和技巧

开启动态工作流的方法有两种：直接在 Prompt 里要求 Claude 创建工作流，或者用触发词ultracode。

描述调度模式的时候要具体。不是”用工作流做这件事”就完了，而是告诉 Claude Code 你想要什么样的验证方式、什么样的并行策略。上面那六种模式的名字可以直接用在 Prompt 里。

对于可重复的工作流（分流、监控、验证），搭配/loop 设置定期执行，/goal 设置硬性完成条件。工作流很容易跑飞，在 Prompt 里加一句“用 10k token”（大概一两轮对话的量）就能限制消耗。

工作流运行时按s 可以保存脚本，存到~/.claude/workflows 或者通过 Skill 分发给团队。

几个实际的 Prompt 示例

原文给了一组示例 Prompt，我觉得比理论解释更直观：

• 这个测试大概 50 次跑挂一次。用工作流复现它，形成竞争性假设，不找到经得起验证的根因不许停。
• 用工作流扫我最近 50 个 session，找到我反复在纠正的模式，把重复出现的提炼成 CLAUDE.md 规则。
• 拿我的商业计划，用工作流让不同 Agent 分别从投资人、客户、竞争对手的视角撕它。
• 这个文件夹有 80 份简历，用工作流按后端岗位排名，前 10 名交叉验证一遍。先用 AskUserQuestion 问我评分标准。
• 用工作流把我们的 User 模型全局重命名成 Account。

共同点很明显：都是可以拆分成独立并行单元的任务，并且都需要某种形式的验证或对抗。

写在最后

三个月前的《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，当时聊的是 Anthropic 用 Generator-Evaluator 模式做长时间全栈开发。那套架构需要人手动搭建，三个 Agent 跑 6 小时花 200 美元。

动态工作流的思路是把"搭建 Harness"这件事也交给 Claude Code 自己。不再需要你预先想好怎么拆分、怎么验证、怎么合并，Claude 看了任务之后自己决定。

这是不是靠谱？说实话，我的体感是：对于你已经有经验的任务类型，自己写静态工作流更可控；对于探索性的任务，让 Claude Code 自己决定调度方式确实能发现一些你没想到的拆法。两者不矛盾，动态工作流可以保存下来变成静态的。

不过话说回来，Harness 可能也像 prompt engineering 一样，是大模型发展过程中的一个中间状态。模型不够强的时候需要人写精巧的调度逻辑，需要多个 Agent 互相制衡才能把一件事做好；模型足够强了，这些逻辑就会被内化。今天你还在想怎么编排子 Agent，也许下一代模型根本不需要外部编排，自己就能在内部完成任务分解和对抗验证。当然，这个"也许"到底要多久，没人知道。

相关资源：

• 原文链接：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
• 动态工作流文档：https://code.claude.com/docs/en/workflows
• 前作：Bun 重写（Jarred Sumner）：https://x.com/jarredsumner/status/2060050578026189172

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them》，由 Cara Phillips 撰写。

用一个 Agent 搞不定复杂任务？上多 Agent 吧。这个判断现在大家基本都认了。但上多 Agent 之后紧跟着一个更具体的问题：这些 Agent 之间怎么配合？

我之前写过 Anthropic 的 Harness 设计和 Managed Agents 架构，都涉及到多 Agent 的分工协作。但那两篇偏重怎么搭基础设施，没有系统聊过协调模式本身该怎么选。网上能找到的多 Agent 教程大多也停留在“拆任务 + 合结果”这个层面，对模式之间的取舍和演进路径讲得不多。Anthropic 刚发的这篇博客正好补了这个缺口，把多 Agent 协调归纳成五种模式，从最简单到最复杂，还给出了什么时候该从一种演进到另一种的判断标准。

读完最大的感受是：大部分团队的问题不是不知道多 Agent 的好处，而是上来就挑了一个听起来最酷的模式，结果被协调开销拖死了。Anthropic 的建议是，从最简单的能跑通的模式开始，看它哪里撑不住了，再往上演进。

模式一：生成-验证

这是最简单的多 Agent 模式，也是部署最广的。

逻辑很简单。一个 Agent 负责生成输出，另一个负责评估。评估通过就结束，不通过就把反馈打回给生成方，重新来一轮。循环下去直到通过或者达到最大迭代次数。

最典型的应用是代码生成：一个 Agent 写代码，另一个写测试、跑测试。客服场景也适用，生成方起草邮件回复，验证方检查是否准确引用了产品文档、是否回应了用户提到的每个问题。

这个模式看着简单，但踩坑的地方也很集中。

最常见的失败是验证标准太模糊。如果你只告诉验证方检查输出是否足够好，它大概率会糊弄人，放行所有东西。验证方的价值完全取决于你能不能把“好”拆成具体的、可检查的标准。

这一点在我之前写 Harness 设计那篇里也提过。Anthropic 的工程师 Prithvi 花了很多精力调教 Evaluator，反复看日志、找判断偏差、改 Prompt，来回迭代了好几轮才让它的评分标准达到合理水平。

另一个问题是迭代循环可能卡死。生成方解决不了验证方提的问题，两边来回震荡不收敛。所以必须设最大迭代次数，加一个兜底策略，比如升级给人处理，或者返回当前最好的版本并标注问题。

模式二：编排-子 Agent

这是层级式的分工。一个 Agent 当 Team Lead，负责规划任务、分配工作、汇总结果。子 Agent 接到具体任务后执行完就汇报。

Claude Code 用的就是这个模式。主 Agent 自己写代码、编辑文件、跑命令，需要搜索大型代码库或者调查独立问题时，就在后台派 subagent 去做，自己继续手头的活。每个 subagent 在自己的上下文窗口里工作，完成后把精炼过的结果返回给主 Agent。

这个模式适合任务拆分清晰、子任务之间依赖少的场景。比如自动化代码审查：一个 PR 进来，需要查安全漏洞、检查测试覆盖率、评估代码风格、验证架构一致性。每个检查维度独立、上下文不同、输出格式明确。编排 Agent 把每个检查派给专门的子 Agent，收集结果后合成一份统一的 Review。

问题出在信息瓶颈上。当子 Agent 发现了对其他子 Agent 有用的信息时，这条信息必须经过编排 Agent 中转。安全子 Agent 发现了一个认证漏洞，这个发现影响架构子 Agent 的分析。编排 Agent 需要识别这种依赖关系并正确路由信息。经过几轮中转之后，关键细节经常被丢失或者在摘要中被省略掉。

我在用 Claude Code 的 subagent 时也有类似体感。subagent 搜完代码库回来的结果有时候会把关键上下文压缩掉，主 Agent 拿到的是一个干净但不够完整的摘要。对于简单查询这不是问题，但对于需要子 Agent 之间共享发现的复杂任务，编排模式就开始吃力了。

模式三：Agent 团队

编排模式里的子 Agent 是用完即弃的。接到任务，干完活，交结果，走人。但如果任务需要 worker 在多轮中积累经验呢？

Agent 团队模式的区别就在这里：worker 是持久的。

一个协调者启动多个 worker Agent 作为独立进程。领任务，干活，交结果。不重置，不遗忘。每个 worker 在多轮迭代中积累对自己负责领域的熟悉度。

最直观的例子是大规模代码迁移。每个 worker 分管一个服务，在反复处理这个服务的依赖、测试、部署配置的过程中，逐渐摸清它的脾气。一次性 subagent 每次接手都要重新理解服务的配置约定和依赖关系，持久 worker 第一次弄明白之后后续迭代直接复用，省掉重复的上下文加载。

但独立性是硬前提。

团队模式里的 worker 没有中间人帮忙传话。一个 worker 的改动影响了另一个，谁都不知道，产出可能冲突。多个 worker 操作同一个代码库时尤其明显，常见的应对方式是文件级别的分区或者合并前跑冲突检测，但这增加了协调者的复杂度。完成时间的参差也是个问题，一个 worker 两分钟搞定，另一个要二十分钟，协调者得有耐心等。

模式四：消息总线

前面三种模式都有明确的协调者在指挥交通。但如果 Agent 数量继续增加、交互模式变得不可预测呢？

消息总线引入了一个共享通信层。核心操作就两个：发布和订阅。Agent 订阅自己关心的 topic，路由器负责分发。新 Agent 上线不需要改已有的连接，订阅相关 topic 就能开始接收工作。搞过微服务事件驱动架构的应该不陌生，本质上就是 Kafka 那套思路，只不过参与者从服务变成了 Agent。

Anthropic 举的例子是安全运维自动化。告警从多个来源进来，分诊 Agent 分类后路由给对应的调查 Agent，调查结果再流向响应协调 Agent。事件一个阶段接一个阶段地流下去，新出了什么威胁类型就加个新 Agent，各个 Agent 还能独立开发部署。

代价是可追溯性变差了。一个告警触发五个 Agent 之间的事件级联，要搞清楚到底发生了什么，调试难度比编排模式那种顺序决策链高了不少。路由器分错类或者丢了事件更麻烦，系统会静默失败，什么都不处理但也不崩溃。

模式五：共享状态

前四种模式里都有一个中心角色在管理信息流。共享状态模式把这个中间人去掉了。

没有中央协调者。Agent 自主运行，读写一个共享的数据库、文件系统或文档。工作一般从往存储里丢一个问题或数据集开始。停下来的条件有几种：时间到了、结果收敛了，或者有个专门的 Agent 判断存储里的东西已经够用了。

研究综合场景是这个模式的主场。多个 Agent 分头调查一个复杂问题的不同方面，学术 Agent 发现了一个关键研究者，这条信息对行业 Agent 调查这个研究者的公司立刻就有用。不用等协调者来路由，发现直接写进存储，其他 Agent 马上就能看到。附带好处是没有单点故障，任何一个 Agent 停了，其他 Agent 继续读写。

代价也很明显。Agent 可能重复工作或者走互相矛盾的方向。更棘手的是反应式循环：Agent A 写了一个发现，Agent B 读到后写了跟进，Agent A 看到跟进后又回应。系统持续烧 token 但不收敛。重复工作和并发写入有成熟的工程方案，加锁、版本控制、分区都行。但反应式循环是行为层面的问题，必须认真设计终止条件：时间预算、收敛阈值，或者专门的 Agent 来判断何时该停。

这个模式让我想到分布式系统里的最终一致性。没有强协调者的好处是吞吐量高、没有瓶颈，但你需要在应用层面处理冲突和收敛问题。Agent 领域也是同样的取舍。

怎么选，怎么演进

五种模式摆在面前，选哪个？Anthropic 给了几组对比的决策逻辑，我觉得最实用的是前两组。

编排-子 Agent vs Agent 团队

两者都有协调者分派工作，区别在于 worker 需要维持上下文多久。子任务短小、输出明确的，用编排模式。子任务需要多步骤持续工作、会从积累的上下文中受益的，用团队模式。判断标准是：当子 Agent 需要跨调用保留状态时，团队模式更合适。

我自己的经验也验证了这一点。Claude Code 日常的代码搜索、文件查阅用编排模式完全够用，subagent 干完就走。但之前写复杂 feature 的时候，需要多个 Agent 持续处理不同模块的开发和测试，编排模式的一次性 subagent 就不够用了，每次都要重新理解模块上下文。

编排-子 Agent vs 消息总线

两者都能处理多步骤工作流，区别在于工作流结构是否可预测。步骤顺序事先已知的，用编排模式。工作流由事件驱动、可能随发现变化的，用消息总线。有个经验法则：当编排 Agent 里的条件分支越来越多、需要处理越来越多的特殊情况时，就该考虑换消息总线了。

Agent 团队 vs 共享状态

各管各的互不交叉，用团队模式。发现需要实时流通，用共享状态。一旦 worker 之间需要互相沟通而不只是最后汇总结果，共享状态更自然。

消息总线 vs 共享状态

事件从一个阶段触发到下一个阶段然后完成的，用消息总线。Agent 在持续积累的知识基础上反复迭代的，用共享状态。还有一个值得留意的信号：如果消息总线里的 Agent 发布事件是为了分享发现而不是触发动作，那你可能需要的是共享状态。

写在最后

实际生产系统往往会混用多种模式。常见的组合是外层用编排-子 Agent 管整体工作流，内层某个协作密集的子任务用共享状态。或者外层用消息总线做事件路由，每种事件类型由一个 Agent 团队来处理。这五种模式是积木，不是互斥的选项。

Anthropic 的建议是从编排-子 Agent 开始。它能覆盖最广的问题范围，协调开销也最低。等它在特定场景下撑不住了，再根据具体瓶颈演进到其他模式。

Claude Code 就是编排-子 Agent 模式的典型实现，对大多数日常任务来说完全够用。只有当任务复杂到需要多个 Agent 持续协作、共享中间发现的时候，才值得引入更复杂的模式。

有意思的是，不同框架对协调模式的抽象思路差异很大。Anthropic 这套分类偏描述性，告诉你有哪些模式、怎么选。LangGraph 走的是 graph-based 的路子，用状态图来定义 Agent 之间的流转逻辑，更偏编程范式。CrewAI 则是角色分工优先，先定义 Agent 的角色和目标，协调模式隐含在角色关系里。三种抽象各有适用场景，但底层要解决的问题是一样的：谁跟谁通信、信息怎么流、什么时候该停。

相关资源：

• 原文链接：https://claude.com/blog/multi-agent-coordination-patterns
• 构建多 Agent 系统：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• Harness 设计：https://www.anthropic.com/engineering/harness-design-long-running-apps
• Managed Agents：https://www.anthropic.com/engineering/managed-agents
• 构建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程博客《Harness design for long-running application development》，由 Anthropic Labs 团队的 Prithvi Rajasekaran 撰写。

让 AI 写一个页面、一个函数，现在大多数编程 Agent 都能做得不错。但如果你给它一句话需求，让它自己规划产品、拆分任务、写代码、测试、迭代修 Bug，连续跑好几个小时，最后交付一个完整的全栈应用呢？

这个问题 Anthropic 一直在啃。他们之前发过一篇长时间 Agent Harness 的文章（《Effective harnesses for long-running agents》），解决了多会话上下文传递的问题。但两个更深层的问题一直没搞定：Agent 跑着跑着就开始划水，它还对自己的产出盲目乐观。

这次 Anthropic Labs 的工程师 Prithvi 换了个思路，从 GAN（生成对抗网络）借了个核心理念：把“生成”和“评估”拆给不同的 Agent。结果挺有意思：一句话需求，6 小时后拿到一个能玩的复古游戏编辑器，还自带 AI 辅助功能。

单 Agent 的两个死穴

在聊多 Agent 架构之前，先说清楚为什么单 Agent 搞不定长时间开发任务。

**第一个问题是上下文焦虑。**之前在 Sonnet 4.5 上观察到一个现象：随着上下文窗口慢慢填满，模型会开始赶工，提前收尾正在做的事。然而这并不是因为它把活做完了，而是它感觉自己快没空间了。

这个问题有两种解法。一种是 Compaction，在上下文里就地压缩早期对话。另一种是 Context Reset，彻底清空上下文，起一个新 Agent 接手，通过结构化的交接文档传递状态。Anthropic 测试下来发现，Compaction 解决不了焦虑问题，因为模型还是在同一个会话里，它还是会觉得空间不够。Context Reset 更干净，代价是交接文档必须写得足够好，否则新 Agent 接不上。

**第二个问题更致命：自我评估偏差。**让 Agent 评价自己的产出，它会非常自信地给出好评，哪怕在人看来质量一般。这在前端设计这种主观任务上尤其明显，没有二进制的对错标准，模型打分一律往高了给。

Anthropic 试过让 Generator 自己做 Code Review，效果也不好。但把评估拆成独立 Agent 之后，事情变得可控了。j 就像原文说的，调教一个独立的评估 Agent 让它变得严格，比让一个生成 Agent 自我批判要容易得多。

这个观察其实不意外。人也是这样，让写代码的人自己 Review 自己的代码，效果肯定不如让另一个人来看。

前端设计：怎么让 AI 不再有 AI 味

在全栈开发之前，Prithvi 先拿前端设计做了实验。这个方向有个好处：设计质量虽然主观，但可以通过制定明确的评分标准来量化。

他定了四个评分维度：

• 设计质量：颜色、排版、布局有没有统一的气质，还是东拼西凑
• 原创性：有没有主动的创意决策，还是在用模板默认值。紫色渐变配白卡片这种 AI 标配直接扣分
• 工艺：字体层级、间距、对比度这些基本功
• 功能性：用户能不能看懂界面、找到操作入口

前两个维度的权重更高。因为 Claude 的基本功本来就不错，Craft 和 Functionality 通常能过关，但设计和原创性上经常输出平庸的东西。

评估 Agent 配了 Playwright MCP，它不是看截图打分，而是实际在浏览器里操作页面：点按钮、滚页面、截图分析，然后写详细的批评意见反馈给 Generator。每轮 5-15 次迭代，整个过程可能跑四个小时。

有一个案例我觉得挺值得说的。Prithvi 让模型做一个荷兰美术馆的网站，前九轮迭代都在渐进改进，产出了一个深色调的着陆页，视觉上已经挺不错了。然后第十轮，模型突然推翻了整个方案，做了一个 3D 空间体验，用 CSS 透视渲染了一个有格子地板的房间，画作挂在墙上，房间之间通过门导航，而不是传统的滚动或点击。

这种创意跳跃在单次生成里几乎不可能出现。是评估反馈的累积压力逼着 Generator 去冒险，而不是停在安全区。下面是前端设计迭代过程的演示视频：

不过也有个有趣的副作用：评分标准里的措辞会直接影响生成方向。Prithvi 在标准里写了“最好的设计应该是博物馆级别的”，结果模型的审美开始往某种特定方向收敛。也就是说，标准本身不只是评分工具，也是风格引导。

三个 Agent，一个完整应用

前端设计验证了 Generator-Evaluator 模式的可行性之后，Prithvi 把它扩展到了全栈开发。架构变成了三个 Agent。

Planner：从一句话到完整产品规格

之前的 Harness 需要用户写好详细的产品 Spec。现在 Planner 接手了这个活：给它一句话需求，它输出完整的产品规格文档，包括功能列表、设计语言、Sprint 划分，甚至主动在产品里嵌入 AI 功能。

Prithvi 特意让 Planner 只做高层设计，不写具体实现细节。逻辑是这样的：如果 Planner 在规格里写死了技术方案但写错了，这个错误会一路传到下游。不如只约束“做什么”，让 Generator 自己决定“怎么做”。

Generator：按 Sprint 推进

Generator 接过 Spec，按 Sprint 一个一个实现功能。技术栈是 React + Vite + FastAPI + SQLite，有 Git 版本控制。每完成一个 Sprint，在提交给 Evaluator 之前先自评一轮。

这里有个设计细节：每个 Sprint 开始前，Generator 和 Evaluator 先谈判一份 Sprint Contract，约定这个 Sprint 具体要交付什么、怎么验收。这一步弥补了高层 Spec 和具体实现之间的鸿沟。

Agent 之间怎么通信？通过文件。一个 Agent 写文件，另一个读文件并回复，没有用复杂的消息队列或 API 调用。简单，但够用。

Evaluator：用 Playwright 当真正的用户

Evaluator 不是看代码打分，而是用 Playwright 像真实用户一样操作应用，真正去点按钮、填表单、测 API、查数据库状态。然后根据 Sprint Contract 里的验收标准逐条打分，不达标就打回去。

这个 Evaluator 调教起来不容易。Prithvi 说 Claude 开箱即用作为 QA Agent 其实很差劲：早期运行中，我看着它发现了真实的问题，然后说服自己这些问题不是大问题，最后批准了。它还倾向于只测表面功能，不深入边界情况。

调教的方法是反复看 Evaluator 的日志，找到它的判断和人的判断不一致的地方，然后针对性地改 Prompt。来回迭代了好几轮才让它的评分标准达到一个合理的水平。

9 块钱 vs 200 块钱：差距有多大

Prithvi 用同一个需求测了单 Agent 和三 Agent Harness。需求很简单：做一个 2D 复古游戏编辑器，要有关卡编辑、精灵编辑、实体行为和可玩测试模式。

贵了 20 倍，但产出质量完全不是一个级别的。

单 Agent 的版本乍看还行，但点进去就出问题了。布局浪费空间，面板用了固定高度，大片空白。工作流没有引导，用户得自己猜到”先做精灵和实体，再布关卡”的操作顺序。最要命的是游戏本身跑不了，实体出现在画面上但不响应任何输入，代码里实体定义和游戏运行时的连接是断的，表面看不出来。

三 Agent 版本从同一句话需求出发，Planner 把它扩展成了 10 个 Sprint、16 个功能的完整 Spec。除了基础编辑器和测试模式，还规划了精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成和关卡设计，甚至游戏导出和分享链接。Planner 还读了 Anthropic 的 frontend-design Skill，为整个应用制定了统一的视觉设计语言。

实际体验下来，画布用满了视窗，面板大小合理，界面有统一的视觉风格。精灵编辑器工具更丰富，颜色选择器更好用，缩放控制也更顺手。因为 Planner 主动嵌入了 AI 功能，应用内置了 Claude 集成，可以用自然语言生成精灵、设计关卡。

最关键的区别是在游戏模式能玩了。角色能移动、能跳跃，虽然物理引擎有些粗糙（角色跳到平台上会出现重叠），但核心功能是通的。

Evaluator 在这个过程中抓到了很多具体问题。比如矩形填充工具只在拖拽起止点放置了瓦片，而不是填满区域；删除实体生成点的快捷键判断条件写错了；FastAPI 的路由顺序有问题，reorder 被当成了frame_id 去解析。这些是单 Agent 版本里根本不会被发现的 Bug。

Opus 4.6 来了，Harness 该减肥了

上面这套三 Agent 架构是用 Opus 4.5 跑的。等 Opus 4.6 发布之后，Prithvi 做了一件所有维护 Harness 的人都应该做的事：重新审视每个组件，看哪些还有存在的必要。

比如，之前 Harness 里的每个组件都编码了一个关于模型不能做什么的假设，而这些假设值得反复检验。

Opus 4.6 在规划能力、长上下文检索和自我纠错上都有明显提升。Prithvi 于是把 Sprint 机制整个拿掉了，不再把工作拆成小块，让 Generator 一口气连续写代码。

Planner 保留了，因为没有它 Generator 会低估项目范围，直接开始写代码，最后做出来的东西功能少很多。Evaluator 也保留了，但从每个 Sprint 结束后评分改成了全部开发完再做一轮 QA。

这个简化改变了 Evaluator 的角色定位。在 4.5 时代，开发任务本身就在模型能力的边界上，Evaluator 几乎每轮都能抓到有意义的问题。到了 4.6，模型的裸能力边界往外扩了，很多以前需要 Evaluator 把关的东西现在 Generator 自己就能做好。Evaluator 的价值集中在那些仍然超出 Generator 能力的部分。

简化后的 Harness 测了一个更大的需求：用 Web Audio API 在浏览器里做一个 DAW（数字音频工作站）。

Generator 连续写了两个多小时的代码，没有 Sprint 拆分也没有跑偏，这在 4.5 上是做不到的。

QA 仍然抓到了关键问题。第一轮反馈说：“应用设计很好，AI Agent 集成也不错，但好几个核心 DAW 功能只是展示用的，时间轴上的音频片段不能拖动，没有乐器 UI 面板，没有可视化的效果编辑器。这些不是边缘功能，是让 DAW 可用的核心交互。”第二轮继续追：“录音功能还是空壳，片段裁剪和分割没实现，效果可视化只有数字滑块没有图形。”

最后跑出来的 DAW 离专业软件自然还很远，但核心组件都有了：编排视图、混音器、音频传输控制。Prithvi 甚至通过内置的 AI Agent 完全用自然语言编曲，设定节拍和调性、铺旋律、加鼓点、调混音、上混响。下面是 DAW 的演示视频：

写在最后

这篇文章给我最大的触动不是三 Agent 架构本身，而是 Prithvi 对 Harness 简化过程的记录。他一开始试过激进地砍组件，发现不行，又改成一次只去掉一个来观察影响。这种方法论比架构本身更有迁移价值，不管你是在做 Agent 还是做传统系统，理解每个组件为什么存在、它的假设是否还成立，都是工程上很重要的习惯。

另一个让我印象深刻的点是 Evaluator 的调教过程。它不是写几行 Prompt 就能用的，而是要反复看日志、找判断偏差、改 Prompt、再看日志。这跟我在做 Agent 评估时的体验一致，评估系统本身就是一个需要持续迭代的产品。

有趣的是，这套架构和 OpenAI 最近在 Codex 上做的方向形成了对照。Codex 更偏“单 Agent + 强上下文管理”路线，Anthropic 走的是“多 Agent 分工 + 外部反馈”路线。两条路各有取舍：单 Agent 更简单、更便宜，多 Agent 在复杂任务上的上限更高但成本也高得多。$124 做一个 DAW 和 $9 做一个游戏编辑器，差距不只是价格，更是产出质量的级别差异。

模型在变强，Harness 在变简单，但“找到下一个有效的 Agent 组合”这件事不会消失。用 Prithvi 的话说：“有意思的 Harness 组合空间不会随模型进步而缩小，它只是在移动。”

相关资源：

• 原文链接：https://www.anthropic.com/engineering/harness-design-long-running-apps
• 前作《长时间 Agent Harness》：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Frontend Design Skill：https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md
• 上下文工程：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Building Effective Agents：https://www.anthropic.com/research/building-effective-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。