这篇内容真正有意思的地方，不是它又做了一个新框架，而是它把很多人已经模糊感受到的问题明说了出来：模型做长任务时，会焦虑、会草草收尾；模型评价自己时，会过度自信，明明结果一般，却很容易给自己打高分。

Anthropic 的解法也很直接：既然“干活”和“验收”这两件事天然冲突，那就别再让同一个 Agent 同时扮演两种角色。于是，一个更像 GAN 的多智能体框架就出来了——生成器负责做，评估器负责挑刺，再配一个 planner 负责把需求展开。结果是，Claude 不只是能跑得更久，出来的东西也明显更像“真的能交付”的产品。

Anthropic 想解决的，其实是长任务里最难的两个老问题

Anthropic Labs 团队成员 Prithvi Rajasekaran 在博客里提到，他之前不管是做前端设计 skill，还是做长时间自主编码 harness，靠提示词工程已经把 Claude 的表现推得很高了，但最后都会撞上同一堵墙。

1. 上下文焦虑：任务越长，模型越容易提前收工

第一个问题叫 context anxiety。说白了，就是模型一旦意识到上下文越来越满，快碰到窗口上限了，就容易开始“保守行事”。它会下意识压缩探索范围，提前总结，甚至在工作还没真正完成时就急着收尾。

这个现象在长任务里特别明显。因为任务一长，模型就不只是“记不住更多内容”这么简单，而是会真的影响策略选择：本来应该继续打磨、继续调试，最后却会变成“差不多就这样吧”。

Anthropic 当时的处理办法是做 上下文重置。也就是让一个 agent 干完当前阶段后，不把整个上下文硬拖进下一轮，而是通过结构化交接文件把关键信息传给下一个 agent。这样下一个 agent 拿到的是一份整理过的状态，而不是一个已经快塞满的上下文窗口。

2. 自我评估失真：模型很难真正挑自己毛病

第二个问题更关键：模型并不擅长评价自己刚刚做出来的东西。

如果让 Claude 自己回头看自己写的代码、自己做的页面、自己生成的交互，它很容易给出一种“总体不错、可以通过”的判断。尤其是在设计这类主观任务里，这个问题更严重，因为不像测试用例那样有明确的 pass/fail 标准。

也就是说，很多时候不是它不会做，而是它不会严厉地审自己。于是 Anthropic 最终把两个问题放在一起，用一套统一思路来解决：把生成和评估彻底分离。

从 GAN 借来的思路，为什么会适合 Agent

Anthropic 这套框架的灵感来自生成对抗网络，也就是 GAN 的经典分工：

一个 generator 负责生成结果

一个 discriminator 负责识别、挑错、判断好坏

把这个思路搬到 Agent 系统里，就变成了：

Generator agent：负责真正干活，写代码、做页面、推进任务

Evaluator agent：负责打分、找问题、提出修改意见

然后让两者迭代循环。Generator 先产出一个版本，Evaluator 看完之后指出问题，再把反馈扔回去，Generator 按意见继续改。这个过程不是“同一个模型反思一下自己”，而是明确换了一个角色、换了一个任务目标。

这里最有价值的洞察是：你不需要把模型本身训练得更自我批判，只需要给评估任务单独做一个更苛刻的 agent。

这比让 generator 一边做事一边审自己，难度低得多，也稳定得多。

第一个实验：让 Claude 做前端时不再总是“安全但平庸”

Anthropic 先拿前端设计做实验，因为这正好能暴露单 Agent 最典型的问题：页面能做出来，但风格很容易收敛到一眼 AI 味很重的默认解。

他们给 generator 和 evaluator 都设定了四个评分维度：

设计质量：整体是不是有统一气质，而不是拼装组件

原创性：有没有真正的创意决策，而不是默认模板拼出来

工艺性：字体、间距、层次、色彩对比这些是否到位

功能性：用户是不是看得懂、找得到关键操作

这里有个很重要的操作：他们故意把“设计质量”和“原创性”的权重拉高。因为 Claude 在功能性和基础工艺上本来就不算差，真正的短板在于太保守，不敢做更激进的视觉尝试

Evaluator 不是看截图，而是真的上手操作页面

评估器不是拿一张静态截图就开始主观打分，而是配了 Playwright MCP，可以直接点页面、切交互、截图、检查状态。这意味着 evaluator 看的不是一个静态效果图，而是一个实际可操作的网页。

每一轮迭代通常会跑 5 到 15 次，完整生成一次最长能到 4 个小时。这个成本显然比单次调用高很多，但也正因为可以持续来回打磨，最后出现了一个很典型的变化：输出不再总是落回“安全模板”。

从“像样”到“有创意”，差别就出在多轮批评

Anthropic 让 Claude 做一个荷兰艺术博物馆网站。前九轮出来的结果其实都不差，是一个典型的深色页面，稳、顺眼、可用，但没有明显记忆点。

到了第十轮，生成器突然换了方向：不再做普通网页，而是变成一个 3D 空间式体验。它用了 CSS perspective 做棋盘地面，把画作直接挂在墙上展示，用门洞来替代传统滚动导航。

这个跳跃之所以重要，不是因为它“更花”，而是因为它说明 evaluator 持续强调原创性之后，生成器终于开始离开默认审美轨道了。这也是单次生成里很少出现的现象。

Prompt 的措辞本身，就会塑造最终设计

Anthropic 在这个实验里还发现了一个很值得开发者记住的点：评估标准不是中立的，它会直接塑造输出。

比如他们在 prompt 里加了一句“最好的设计应该是博物馆级别的”，结果整个页面风格就明显向某种更精致、更展陈化的视觉方向收敛。也就是说，评估语言不只是“验收标准”，它本身也是生成约束的一部分。

第二个实验：让 Claude 真正连续跑几小时写完整应用

接下来 Anthropic 把同样的思路推到了全栈开发上。

这次系统不只两个 agent，而是三个：

Planner：把一句两句需求扩写成详细 spec

Generator：按阶段实现功能

Evaluator：像 QA 一样真实点应用、测功能、按验收条件打分

Planner 负责定义目标，不负责替后续 agent 决定实现细节

Planner 的职责不是把技术方案也写死，而是把需求讲清楚：要交付什么、要支持哪些 AI 功能、产品要满足哪些能力边界。

这一点很关键。Anthropic 强调的是 spec-first，而不是 implementation-first。因为如果 planner 在一开始就把技术实现也猜错了，那这个错误会顺着整条链路一路传下去，后面每个 agent 都会在错误前提上工作。

所以更好的做法是：planner 只规定“做什么”，把“怎么做”留给 generator 自己决定。

Generator 和 Evaluator 会先协商“合同”再开工

在每个 sprint 开始前，generator 和 evaluator 不是直接开写，而是先通过文件协商一个合同：

Generator 提出这一阶段准备完成哪些内容

Evaluator 检查这些条件是否清晰、是否可验收

两边先达成一致，后面再进入真正实现

注意，这里它们不是直接聊天，而是通过文件读写来沟通。这么做的好处是状态更稳定，也更容易在轮次之间做上下文重置。

Evaluator 会真实点击页面、测接口、查数据库状态

评估器做的事并不只是“读代码然后主观评价”。它会借助 Playwright MCP 真实操作应用，检查：

UI 交互是否正常

API 端点是否按预期返回

数据库状态是否符合合同要求

而且它不是宽松验收，而是有明确阈值，只要某一项低于标准，就直接打回去让 generator 重做。

一个 20 分钟和 6 小时的对比，把差距拉得很直观

Anthropic 用这套多智能体系统做了一个叫 RetroForge 的项目，也就是 2D 复古游戏制作器，然后拿它和单 Agent 跑出来的版本做对比。

结果很残酷：

从时间和花费上看，三 agent 方案贵了 20 多倍。但成品质量几乎不是一个量级。

单 agent 的版本虽然能打开，屏幕上也有 entity，但交互几乎没真正跑通，核心游戏机制是断的。harness 版则明显更像一个完整产品：可以实际游玩，角色能移动、能跳，还内置了 Claude 集成，可以通过 prompt 去生成游戏元素。

真正拉开差距的，是 evaluator 能抓到“像人类 QA 一样”的问题

Anthropic 给出的一个细节很说明问题：在 Sprint 3 里，评估器面对的是 27 个验收条件，而且它报出来的 bug 已经具体到函数、路由和触发条件。

比如：

矩形填充工具拖拽无效：fillRectangle 函数虽然存在，但没有在 mouseUp 时触发

entity spawn point 无法删除：删除键要求同时存在 selection 和 selectedEntityId，但点击 entity 时只设置了后者

动画帧重排序接口失败：PUT /frames/reorder 路由写在 /{frame_id} 后面，FastAPI 把 reorder 当成整数 frame_id 解析，直接返回 422

这说明 evaluator 的价值不只是“帮忙看看”，而是真的能像一个较严格的自动 QA 一样，把功能断点找出来，并且写成 generator 能执行的修复反馈。

Anthropic 也承认，想把 evaluator 调到这个水平并不简单。原生 Claude 并不是一个天然优秀的 QA，它有时会发现问题，但随后又在推理里说服自己“这个问题不算太严重”，最后放行。团队是通过一轮轮读日志、观察偏差、修改 prompt，才把 evaluator 逼到足够严格的状态。

Opus 4.6 出来之后，这套架构反而被简化了

这篇工程复盘里另一个特别有价值的点是：Anthropic 没有把 harness 当成永远正确的架构，而是明确说，新模型一来，很多原本必要的组件可能就该删掉。

上下文重置不再是硬需求

等他们用 Opus 4.6 重跑同样的流程时，发现模型在长任务里的稳定性明显提升，context anxiety 基本不再是核心问题。

结果就是：

原来为了 Sonnet 4.5 设计的 sprint 拆分可以去掉

专门的上下文重置机制也不再是刚需

模型可以连续跑两个多小时还保持比较稳定的任务推进

这其实很重要。因为它说明 multi-agent harness 不是越复杂越好，而是应该随着模型能力升级不断被重新审视。

同样三 agent，但流程已经变轻了很多

最终产物已经具备完整的 arrangement view、mixer、transport，而且内置了 AI agent，可以通过 prompt 调节 tempo、key、旋律、鼓点、混音和混响。

当然，它离专业 DAW 还差很远。Anthropic 也直接点明了局限：Claude 听不见声音，所以 QA 没法判断“好不好听”，只能检查功能是否存在、交互是否通顺。

Evaluator 仍然能抓到“看起来像做了，其实没做完”的问题

在这个 DAW 项目里，第二轮 QA 依然发现了几个很实质的问题：

录音功能只是个 stub，没有真正实现

clip 拖拽没做完

效果器 UI 只有数值滑块，没有图形化的 EQ 曲线

也就是说，即便新模型更强了，evaluator 在模型能力边界附近仍然很有价值。它不是总要开着，但在复杂产品型任务里，仍然能明显提高交付质量。

这篇复盘里最值得开发者带走的几个工程结论

Anthropic 这篇内容真正有价值的，不只是案例本身，而是它把几条很有操作性的工程结论说得很清楚。

1. Evaluator 不是永远必要，但在“临界任务”上非常值钱

Anthropic 的判断是：当任务刚好处在 generator 能力边界附近时，evaluator 的收益最大。

如果任务太简单，generator 自己就能完成，多一个 evaluator 只是额外成本；如果任务太难，generator 连基本结构都立不起来，evaluator 也帮不了太多。真正适合上 evaluator 的，是那些“模型大体能做，但很容易漏细节、漏边角、漏验收”的复杂任务。

2. Harness 的每个组件，本质上都是对模型局限的假设

这句话几乎可以算这篇博客最值得记住的一句：harness 的每个组件，都编码了一个“模型自己做不好这件事”的假设。

比如：

需要上下文重置，意味着你假设模型长任务会失稳

需要 evaluator，意味着你假设模型自评不可靠

需要 planner，意味着你假设输入需求本身不够清晰

这些假设不是永恒成立的。模型一升级，就该重新测试：哪些组件还有必要，哪些已经变成过度工程。

3. Prompt 语言不仅是约束，还是架构的一部分

不管是设计实验里“博物馆级别”的措辞，还是代码实验里 generator 和 evaluator 的合同条件，Anthropic 都发现：语言本身会塑造产物。

评估器写下什么标准，最后产品就会向那个标准收敛。验收条件怎么定义，最后系统就会围绕那些条件长出来。所以在多智能体系统里，prompt 不只是配置项，它本身就是一层软架构。

社区讨论里，大家已经开始往“去中心化多智能体”想了

这篇博客发出来之后，社区里有个特别有意思的讨论方向：Anthropic 现在这套还是一个中心化编排框架。

也就是说，planner、generator、evaluator 虽然分工不同，但它们依然被一个统一 runtime、统一 harness、统一控制流程串起来。所有 agent 的生命周期、协作顺序和执行回路，本质上还是由同一套 Python 代码在调度。

下一步更值得探索的方向，可能是把这些 agent 彻底做成独立实体：

planner 独立运行

generator 独立运行

evaluator 独立运行

它们通过开放协议互相发现、协商和通信

如果真走到这一步，多智能体系统就不再只是“一个程序里有多个角色”，而会更接近真正的 Agent 网络。

另一条很有洞察力的评论则点出了更深一层的问题：evaluator 不只是评判者，它其实也在决定最终被构建出来的东西。

这个观察和 Anthropic 整篇复盘高度一致。因为只要你承认“标准会塑造生成”，那 evaluator 就不只是 QA，它实际上已经成为产品设计者的一部分。

Claude 到底是什么，为什么这篇文章对开发者这么重要

如果你只把 Claude 理解成一个聊天机器人，这篇文章会显得有点夸张；但如果你把它看成一个正在演化中的自主编程 Agent，Anthropic 这次分享的东西就非常关键了。

Claude 尤其是 Claude Code 这类产品形态，真正的能力已经不只是回答问题，而是围绕任务目标持续行动。它可以：

读项目文件和代码结构

搜整个仓库找上下文

修改多个文件

执行终端命令

跑测试和构建

调试报错并继续修复

配合 Playwright、MCP、Git 等工具完成更长链路任务

这也是为什么 Anthropic 现在讨论的重点，不再是“模型答得对不对”，而是“怎么让它更稳定地干完一个长任务”。

官方常见公开订阅档位里，Claude Pro 大约 20 美元/月，Max 5x 大约 100 美元/月，Max 20x 大约 200 美元/月。对国内用户来说，官方订阅在支付和网络环境上通常都不算轻松。如果嫌这些环节麻烦，可以看看 Code80，真实订阅帐号转 API，换个 endpoint 就能直接用。详情可以到官网了解：code.ai80.vip

常见问题

Q1：Anthropic 这套多智能体框架，核心创新点到底是什么？

A：核心不是“多加几个 agent”本身，而是把生成和评估拆开，用 evaluator 去解决长任务里的自我评估失真问题，同时用上下文重置等机制对抗长任务中的 context anxiety。

Q2：为什么让模型自己评估自己不行？

A：因为模型在评价自己刚生成的代码或设计时，天然容易过度乐观。它经常能发现问题，但又会在后续推理里把问题合理化，最后给自己放行。

Q3：这套方案是不是以后写复杂应用的标准做法？

A：还不能这么说。Anthropic 自己也强调，harness 的每个组件都只是对当前模型局限的临时补丁。模型升级之后，有些机制可能会直接失去必要性。

Q4：Opus 4.6 为什么会让这套系统变轻？

A：因为它在长任务稳定性和代码自审能力上更强，很多原本为了 Sonnet 4.5 设计的上下文重置和 sprint 拆分机制，在 Opus 4.6 上已经不是刚需了。

Q5：多智能体系统里，evaluator 最适合用在什么场景？

A：最适合用在那些“模型大体能做，但很容易漏细节”的复杂任务上，比如产品级前端、全栈应用、真实交互验收这类场景。

Q6：国内用户如果也想更方便地用 Claude 做这类长任务开发怎么办？

A：如果主要是想少折腾支付和网络，国内用户可以通过 Code80 更方便地使用。