学习目标：
- 说出单个 Agent 在长任务里会遇到的两种具体限制：上下文污染和注意力稀释
- 用官方给出的 token 成本数据，判断一个任务是否值得引入多个 Agent
- 识别「协调开销大于收益」的场景，说出多 Agent 系统今天不擅长做哪类任务
前置要求：完成前 5 门课（会写 prompt、懂工具调用协议、了解 Agent 记忆与状态、能读基础 JS） | 下一课 第 2 课 >>
假设你让一个 Agent 完成这样一个任务：「调研三家云服务商最近一年的定价变化，横向对比，写一份 2000 字的选型建议。」
单个 Agent 会怎么做：先搜第一家的定价页面，读进来一大段 HTML 和价格表；再搜第二家，又是一大段；再搜第三家的历史变更记录，可能还要翻几页；期间搜到几条不相关或者过时的结果，也一并读了进来；最后基于这一整段越滚越长的对话历史，写出那份 2000 字的建议。
这个过程本身没有问题——前几门课你已经知道，这就是 Agent 的基本工作方式：读取上下文、决定下一步、调用工具、把结果放回上下文，循环往复。真正的问题出在任务变长、变复杂之后，这条越滚越长的单一上下文，会在两个地方悄悄拖累最终结果。
调研进行到一半，Agent 搜到了一条误导性的结果——也许是一篇过时的博客文章，报了一个已经作废的价格；它没有意识到这条信息有问题，把它当作真实数据继续往下推理，甚至写进了对某家云服务商的初步判断里。
这条错误判断产生之后，并不会凭空消失。它留在对话历史里，成了后续所有推理的一部分背景。等 Agent 真正搜到权威、最新的定价页面时，两条互相矛盾的信息都摆在同一个上下文窗口里，模型未必能干净地识别出哪条才该被采信——尤其是当那条错误信息出现得更早、被反复引用过的时候。
这就是上下文污染：早期一步产生的错误或无关信息，混进了后续全部推理都要依赖的同一份上下文里，而且很难被后来的正确信息彻底冲刷掉——上下文窗口里的 token 越多，模型从中准确回忆、分辨具体信息的能力反而越低1。任务越长、中间步骤越多，这类污染累积的机会就越大。
第二个问题和第一个不同——不是信息错了，而是信息「太多」本身就是代价。三家云服务商的定价页面、历史变更记录，加起来可能是几万字的原始内容，全部堆进同一个上下文窗口。模型在生成最终建议时，理论上要同时兼顾这几万字里的每一处细节，但它对其中任何一处细节的「注意力」，会随着上下文变长而被摊薄。
这就是注意力稀释：模型解析大量上下文时靠的是一份有限的「注意力预算」，每多一个 token 都会消耗掉一点1——同一个上下文窗口里塞的内容越多，模型对其中任意一小段具体信息的关注程度就越低，越容易在总结、对比这类需要精确记住多处细节的任务上出错或遗漏。
上下文污染和注意力稀释合在一起，就是「单上下文」这条路径的天花板：任务一旦长到一定程度，靠一个 Agent 从头做到尾，质量会逐步往下掉——官方把这种退化描述为「渐变而非断崖」1——而且单靠加长 prompt 很难补回来。
多 Agent 系统给出的答案，是把一个大任务拆成几块，分别交给几个独立的 Agent 去做，而不是塞进同一个越滚越长的上下文里。官方给出的定义是：「多 Agent 系统由多个 Agent（在循环中自主使用工具的 LLM）协同工作组成。」2
放回云服务商调研的例子：与其让一个 Agent 一路读完三家公司的所有资料，不如分别让三个 Agent 各自专心调研一家——每个 Agent 有自己独立的上下文窗口，互不干扰2。第一家调研里搜到的过时博客文章，只会污染那一个 Agent 自己的上下文，不会混进另外两家的推理过程——官方把这称为「关注点分离」，各自独立的工具、提示词和探索路径降低了路径依赖2；每个 Agent 手上要兼顾的原始内容也从「三家公司的全部资料」变成「一家公司的资料」，注意力稀释的问题也跟着减轻。这种「一个中心 Agent 拆任务、多个 Agent 并行处理、再汇总结果」的结构，具体怎么运作，下一课会展开讲。
分给多个 Agent 不是免费的。每个子 Agent 都要重新读一遍任务背景、组织自己的推理，这些都要消耗 token；最后还要有一步把几个 Agent 的结果汇总起来，这一步也要消耗 token。官方给出的实测数据是：「在我们的数据中，Agent 消耗的 token 通常约为对话式交互的 4 倍，而多 Agent 系统约为对话式交互的 15 倍。」2
15 倍不是一个小数字。这意味着引入多 Agent 系统，只有在任务本身的价值足够高、值得为提升效果多付这份 token 成本时才划算——官方原文也是这么说的：「多 Agent 系统要具备经济可行性，需要任务本身的价值高到足以覆盖性能提升带来的额外开销。」2
具体该配几个子 Agent，也不是越多越好。官方给出过一条效果扩展规则：简单的事实查找，1 个 Agent 配 3 到 10 次工具调用就够；直接的横向对比，2 到 4 个子 Agent、每个 10 到 15 次调用；只有足够复杂、任务边界能被清楚拆分的调研，才值得用到 10 个以上子 Agent。2 早期版本里，团队踩过反例——有的 Agent 给一个简单查询就派生出 50 个子 Agent，或者无休止地满网搜一个根本不存在的来源，多个 Agent 之间还互相发一堆没必要的更新，把彼此的注意力也占满了。2
这条规则背后的态度，和 Anthropic 在另一篇讲 Agent 架构的文章里给出的建议是一致的：「只有在能明确改善结果时，才应考虑增加复杂度。」3 先把任务用一个 Agent 跑通，观察它到底卡在哪一步、是上下文污染还是注意力稀释，再决定要不要、以及在哪一步引入多 Agent，比一上来就搭一套复杂的多 Agent 系统更划算。
多 Agent 系统的价值建立在「任务可以被拆成几块、各自独立处理」这个前提上。一旦这个前提不成立，拆分本身就成了额外负担——这就是协调开销：为了让多个 Agent 分工协作而额外花费的时间和 token，包括拆任务、汇总结果、处理 Agent 之间互相矛盾的产出。当一个任务本来就没多少能真正拆开并行化的部分时，协调开销很容易超过拆分带来的好处。
官方明确指出过一类不适合的场景：「大多数编码任务比调研任务能真正并行化的部分要少得多，而且 LLM Agent 目前还不太擅长实时协调、委派给其他 Agent。」2 修一个 bug 通常需要理解代码里前后相关的好几处逻辑，这些逻辑环环相扣，很难干净地切成几块分给不同 Agent 各自处理而不互相踩脚——这类任务更接近深度优先任务：答案藏在一条需要逐步深入的推理链条里，而不是分散在几个互不相关的方向上。相反，官方总结多 Agent 系统真正擅长的，是那些「涉及大量并行化、信息量超出单一上下文窗口、需要对接大量复杂工具」的高价值任务2——调研云服务商定价、横向对比多份文档，属于广度优先任务：答案分布在几个相对独立的方向上，可以真正分头去查、互不依赖彼此的中间结果。
判断一个任务该不该上多 Agent，可以先问三个问题：这个任务能不能拆成几块互相独立的子任务？拆开之后总的信息量是不是超过了一个上下文窗口能装的范围？任务的价值是不是高到能覆盖那笔多出来的 token 成本？三个问题只要有一个答案偏向「不能」或「不值得」，先老老实实用一个单 Agent 系统把任务做完，通常比强行拆成多 Agent 更划算。
Effective context engineering for AI agents（Anthropic Engineering） — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩2 ↩3
How we built our multi-agent research system（Anthropic Engineering） — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
Building effective agents（Anthropic Engineering） — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
Jot down thoughts, sticking points, things you didn't get. Written to this course's appendix only — the lesson file is never touched.