评估器使用 Playwright 真实地与页面交互，然后打分。经过 5-15 轮迭代，生成的设计明显比单次输出更有特色。有个案例到第 10 轮时，生成了一个 3D 空间博物馆体验，这是单智能体很难做到的。
三智能体全栈架构：分工才是关键
前端设计验证了思路，接下来是更复杂的全栈应用开发。Anthropic 设计了一个三智能体系统：
graph LR
A[Planner<br/>规划智能体] -->|产品规格| B[Generator<br/>生成智能体]
B -->|实现代码| C[Evaluator<br/>评估智能体]
C -->|反馈报告| B
C -.->|重大问题| A
classDef plannerStyle fill:#1A5050,stroke:#1A9090,stroke-width:2px,color:#fff
classDef generatorStyle fill:#2A4A6A,stroke:#4A8ACA,stroke-width:2px,color:#fff
classDef evaluatorStyle fill:#4A3A5A,stroke:#8A6A9A,stroke-width:2px,color:#fff
class A plannerStyle
class B generatorStyle
class C evaluatorStyle
单智能体的两大顽疾：上下文焦虑（窗口填满后急着收尾）和自我评估偏差（对自己的输出过度自信） 借鉴 GAN 的对抗思维：用独立的评估器替代自我评估，通过 Playwright 真实交互后打分，形成生成-评估对抗循环 三智能体架构：Planner 规划、Generator 实现、Evaluator 测试，通过文件通信建立"冲刺合约" 成本换质量：单智能体快但残缺（20分钟/9），完整框架慢但可用（6小时/9），完整框架慢但可用（6小时/9），完整框架慢但可用（6小时/200） 运行框架会过时：每个组件都编码了"模型做不到"的假设，模型进化后需要定期审计和简化 分工比智能更重要：把"生成"和"评估"分离，比提升单个智能体能力更有效 对软件流程的启示：开发者自测的局限性与 AI 自我评估问题本质相同，都需要独立评估机制
单智能体为什么会"累"？ 很多人第一反应是：模型不够聪明，或者上下文窗口太小。经过 5-15 轮迭代，生成的设计明显比单次输出更有特色。#8A6A9A,stroke-width:2px,color:#fff
各自的职责 Planner（规划智能体）
把简短的需求扩展成详细的产品规格 重点是范围界定，而不是具体实现细节 输出"冲刺合约"：定义这个迭代要完成什么
Generator（生成智能体）
使用 React、Vite、FastAPI、SQLite/PostgreSQL 实现功能 增量式开发，每次实现一部分 用 git 做版本控制
Evaluator（评估智能体）
用 Playwright 像真实用户一样测试功能 对照"冲刺合约"检查是否达标 识别 bug 和遗漏的功能
通信机制 智能体之间通过文件通信，而不是直接对话。
Harness这个词最近被越来越多的提及。这两天在读 Anthropic 工程团队的一篇技术博文《Harness Design for Long-Running Application Development》，提出了一个更值得工程团队重视的变化：
当 AI 模型的上下文窗口越来越大、能力越来越强时，限制 AI 编程质量的瓶颈，正在从"模型能不能做"转向"怎么让模型持续做好"。
Anthropic 的工程师 Prithvi Rajasekaran 把这个问题拆得很透彻，并给出了一套基于多智能体架构的解决方案。更重要的是，这套方案背后的思路，对我们重新思考软件开发流程有不少启发。
太长不看版
单智能体为什么会"累"？
很多人第一反应是：模型不够聪明，或者上下文窗口太小。
但如果认真看 Anthropic 的分析，会发现真正的问题是：
问题一：上下文焦虑
这是个很有意思的现象。当上下文窗口逐渐填满时，模型会表现出一种"焦虑"——它会主动加速收尾，即使任务还没完成。
就像一个开发者看到 deadline 临近，开始草草了事一样。模型似乎"感知"到了上下文的边界，然后选择提前结束，而不是继续深入。
问题二：自我评估偏差
更致命的是，当你让 AI 评估自己写的代码时，它会表现出过度自信。
一个典型场景：
这不是模型"撒谎"，而是自我评估机制的固有缺陷。就像让开发者自己测试自己的代码，很容易陷入"我觉得应该能跑"的思维定式。
从 GAN 借来的对抗思维
Anthropic 的解法很巧妙：既然自我评估不可靠，那就引入一个独立的评估者。
这个思路直接借鉴了生成对抗网络（GAN）的设计：
关键在于，评估器不是简单地"看代码"，而是真的去用。
前端设计的实验
在前端设计任务中，Anthropic 设置了四个评分维度：
评估器使用 Playwright 真实地与页面交互，然后打分。经过 5-15 轮迭代，生成的设计明显比单次输出更有特色。有个案例到第 10 轮时，生成了一个 3D 空间博物馆体验，这是单智能体很难做到的。
三智能体全栈架构：分工才是关键
前端设计验证了思路，接下来是更复杂的全栈应用开发。Anthropic 设计了一个三智能体系统：
各自的职责
Planner（规划智能体）
Generator（生成智能体）
Evaluator（评估智能体）
通信机制
智能体之间通过文件通信，而不是直接对话。这样做有两个好处：
实际效果：成本换质量值不值？
理论听起来不错，但实际效果如何？Anthropic 给出了两个对比案例。
在复古游戏制作器项目中，同样的需求用两种方案实现：单智能体 20 分钟花费 9，但核心功能损坏无法使用；完整运行框架6小时花费200，功能完整可正常使用。20 倍的成本差距，但产出质量天壤之别。单智能体版本看起来"完成了"，实际上核心功能根本跑不通。
更有意思的是数字音频工作站（DAW）案例。使用升级后的运行框架（基于 Claude Opus 4.6），3 小时 50 分钟花费 $124.70 完成开发。关键发现是：生成器一度认为"任务完成"，但评估器发现还有重要功能没实现。如果没有独立评估，这些问题会被掩盖。
这两个案例说明，评估器的价值不只是找 bug，更重要的是防止生成器"自欺欺人"式的完工。
运行框架也会过时
这里有个很重要的洞察，Anthropic 的原文是这么说的：
换句话说，运行框架本质上是对模型能力边界的补偿。当模型能力提升时，有些补偿就不再需要了。
实际演进案例
在早期版本中，Anthropic 的运行框架包含了"冲刺分解"功能——把大任务拆成小任务，逐个完成。
但当升级到 Claude Opus 4.6 后，他们发现这个功能可以移除了。新模型已经能够自己管理复杂任务的节奏，不需要外部框架强制分解。
移除这个组件后：
这说明什么？运行框架不是一劳永逸的，需要随着模型进化定期审计。
对传统软件开发流程的反思
读到这里，如果你是工程师或架构师，可能会有种似曾相识的感觉。
Anthropic 遇到的问题，和我们在传统软件开发中遇到的问题，本质上是一样的：
开发者自测的局限
让开发者测试自己写的代码，会遇到什么问题？
这和 AI 的自我评估偏差，是同一个问题的不同表现。
为什么需要 QA
传统开发流程中，我们引入独立的 QA 角色，原因是：
Anthropic 的评估器智能体，扮演的就是 QA 的角色。
分工的价值
更深层的启示是：分工比智能更重要。
不是说单个智能体不够聪明，而是"既要写代码，又要判断好坏"这件事本身就很难做好。把这两个职责分离，比提升单个智能体的能力更有效。
这和康威定律的逻辑一致：系统架构会反映组织的沟通结构。当我们把"生成"和"评估"分离成两个独立角色时，自然就形成了更健康的反馈循环。
架构师的新角色：设计智能体协作
如果 AI 编程的未来是多智能体协作，那架构师的角色也会发生变化。
从系统架构到协作架构
过去的架构师：
未来的架构师：
注意，这不是替代，而是扩展。系统架构依然重要，但多了一层"智能体协作架构"。
什么时候需要多智能体
不是所有任务都需要复杂的运行框架。Anthropic 的经验是：
单智能体够用的场景：
需要多智能体的场景：
关键是渐进式引入复杂度：先用最简单的方案试错，遇到瓶颈再加入分工机制。
给工程团队的实践建议
基于 Anthropic 的经验，结合当前的软件开发实践，这里有几个可以立即尝试的方向：
建立"生成-评估"分离意识
重新审视自测机制
设计"冲刺合约"机制
写在最后
当工具变得足够强大时，限制我们的往往不是工具本身，而是我们使用工具的方式。
AI 模型越来越聪明，但如果我们还是用"单兵作战"的方式使用它，就会遇到上下文焦虑和自我评估偏差这样的系统性瓶颈。
解决方案不是等待更强的模型，而是重新设计协作架构——把生成和评估分离，建立真实的反馈循环，让每个角色专注做好自己的事。