最近在读 Anthropic 官方的一篇技术文章，讲的是他们如何用多 Agent 架构来解决复杂应用的开发问题。这篇文章是 Claude 官方团队的经验总结，他们在开发复杂 AI 应用时遇到的坑和总结的方法论，都非常有参考价值。
作者提到一个常见的现象：让 AI 做一个复杂项目，开头往往很顺利，但做到后面就会越来越偏，最后功能根本跑不通，或者设计出来的东西"能看但不好用"。这不是模型能力的问题，而是工作方式的问题。这让我想起了自己做课程设计的经历。
上下文焦虑——长时任务的"注意力涣散"
人脑和 AI 都会"糊"
文章里提到一个概念叫 “Context Anxiety”（上下文焦虑）。简单说就是，当 AI 连续工作几个小时后，即使还没超出它的上下文限制，表现也会明显下降：开始忽略关键的约束条件、重复犯已经修复过的错误、对明显的 bug 视而不见。
这跟我期末考试前连续复习 8 小时的状态简直一模一样。第一天复习，精神抖擞，看什么都清晰。连续学几个小时不休息后，脑子就"糊了"，明明书上的内容都看过，但已经开始遗漏知识点、做出错误判断。
AI 的"疲劳"体现在上下文窗口上。我们平时可能只觉得 context 是个成本问题（token 多了调用变贵），但这篇文章指出了更深层的限制：当上下文被填满，模型的"注意力"会涣散。就像人连续工作太久，注意力无法集中一样。
两种缓解策略
文章提到了两种应对方式：
1. Context Compaction（上下文压缩）
把历史对话中的细节丢掉，只保留关键信息。类似于我们做笔记摘要。但摘要有风险，你以为不重要的细节，可能恰恰是关键线索。
2. Context Reset（上下文重置）
直接"换一个人接力"——清空当前上下文，让新的 Agent 实例接手任务。新 Agent 带着有限但清晰的上下文进场，反而能做出更好的判断。
这两种方式不是互斥的，而是在不同场景下各有优势。对于需要连续推理的代码修改，压缩更合适；对于阶段性完成的任务（比如"设计完成，进入开发"），重置往往更有效。
这让我想到：长时任务失败，不一定是能力问题，可能是"注意力管理"出了问题。就像我不能指望自己连续高强度工作 8 小时还保持清醒，也不能指望单个 AI 在超长的上下文里始终"清醒"。
自我评估偏差——AI 也会"护短"
设计评审中的尴尬
文章里提到一个有趣的实验：让 AI 设计一个网页组件，然后让它给自己的设计打分。结果是——即使设计得很平庸，AI 也会给出 8 分、9 分的高评价。但把同样的设计拿给另一个独立的 AI 评审，可能只给 5 分或 6 分。
我也经常"护短"
这让我想起自己刚写完一段代码，觉得逻辑挺清晰的。但放一天再看，或者找同学 review，突然发现边界条件没处理。测试一跑，各种奇怪的场景都能让代码崩掉。
AI 也有同样的问题。让同一个模型去验证它自己写的代码，它容易"护短"——潜意识里想证明自己是对的，于是对那些 bug 视而不见。
这就是为什么需要独立的 Evaluator（评估者）。这和人类团队需要 Code Review 是一个道理。
解决方案——Multi-Agent 的本质是"分工"
既然单个 AI 会有"注意力涣散"和"自我评估偏差"的问题，那解决方案就很自然了：让多个 Agent 分工协作，各自专注自己最擅长的环节。
这不是为了技术而技术，而是在模拟真实的人类团队协作。
Agent 分工模型
| Agent 角色 | 对应岗位 | 职责 |
|---|---|---|
| Planner | 产品经理/项目负责人 | 把模糊需求变成可执行的计划和规格说明 |
| Generator | 程序员/设计师 | 实际写代码、做设计 |
| Evaluator | 代码审查/测试 | 客观评判质量，指出问题 |
这个分工对应了人类解决复杂问题的自然流程：先规划（确定要做什么）、再执行（实际动手）、后验证（检查做得对不对）。
可量化的评分标准
Evaluator 不能只说"这个设计不好看"——这种主观评价没有可操作性。好的 Evaluator 会把"好不好"变成可量化的维度：
| 维度 | 含义 | 评分标准 |
|---|---|---|
| 设计质量 | 视觉效果和用户体验 | 1-10 分，基于专业设计原则 |
| 原创性 | 是否有抄袭或过度模仿 | 与参考设计的相似度检测 |
| 工艺 | 代码/设计的精细程度 | 细节处理、边界情况覆盖 |
| 功能性 | 是否满足需求规格 | 需求覆盖度百分比 |
原来"审美"也可以工程化。通过定义清晰的评分维度，主观的质量评判变成了可执行、可迭代的客观标准。
迭代循环
三 Agent 不是各干各的，而是形成一个迭代循环：
这个循环跑 5-15 轮，质量会有显著提升。这和人类团队的"写代码 → Code Review → 修改"循环是一样的逻辑。
与单 Agent 的本质区别
单 Agent 的问题在于"身兼数职"——同一个上下文里，它既要规划、又要执行、还要评判。这三个角色对上下文的需求是冲突的：
- 规划者需要全局视角，关注目标和约束
- 执行者需要专注细节，关注当前任务
- 评估者需要客观中立，关注问题和风险
让一个人同时扮演这三个角色，结果就是三个角色都做不好。Multi-Agent 架构通过物理隔离（每个 Agent 有自己的上下文窗口）解决了这个冲突。
与之前学习的呼应
之前我写过一篇文章讲 Agent 的基本公式：Agent = 模型 + 工具 + 循环 + 状态。那篇文章聚焦于单个 Agent 的运转机制。
这篇文章是自然的延伸：从单个 Agent 到 Multi-Agent，是从"一个人单打独斗"到"团队协作"的演进。
两篇文章的核心洞察是一脉相承的：
| 主题 | 单个 Agent | Multi-Agent |
|---|---|---|
| 核心问题 | Agent 是什么、如何运转 | 复杂任务为什么需要多个 Agent |
| 关键机制 | 模型 + 工具 + 循环 + 状态 | Planner + Generator + Evaluator |
| 工程原则 | 状态管理是 Agent 的生命线 | 上下文管理是复杂任务的生命线 |
随着模型能力进化，实现 Multi-Agent 的方式也在变化。但核心原则始终不变：复杂任务需要分工，主观质量需要外部评估。这不是模型能力的问题，而是认知架构的问题——就像再聪明的人也需要团队协作来解决复杂问题。
我的收获和启发
读完这篇文章，我有几点很深的体会：
1. 上下文管理是"注意力管理"
长时任务要考虑"注意力窗口"而非无限上下文。连续工作几小时后出现"context anxiety"是正常的——换我在图书馆连续学 8 小时，脑子也会糊。以后做项目，我要学会主动分段，而不是一股脑死磕。
2. 找人 Review 是必要的
自我评估不可靠，独立评估者是质量保证的关键。自己写的代码自己评，就像学生自己给自己打分——结果往往偏高。以后做课程设计，我要更主动地找同学互相 review，而不是写完就交。
3. Multi-Agent 的本质是团队协作
这不是什么高深的技术炫技，而是在模拟人类解决复杂问题的分工逻辑。Planner + Generator + Evaluator 的分工，对应的就是产品经理 + 程序员 + 测试的经典组合。
写在最后
这篇文章给我的启发不只是 AI 工程的知识，更是做项目的方法论：
- 不要试图一口气写完一个大作业——先规划、再实现、最后检查
- 代码写完后放一放再看，或者找同学 review，会比自己看发现问题更多
- 一个人埋头苦干 8 小时的效果，往往不如分 4 个 2 小时，中间休息和讨论
这和 AI 工程的最佳实践是一样的：复杂任务需要分工，质量需要外部视角，持续高强度工作需要管理注意力。