第 20 章 · 多智能体协作模式：从线性到全连接 07-09
本章观点
第 19 章我们讲了规划工作流，让一个 Agent 先规划再执行。但当任务真的复杂到一个 Agent 装不下时，就需要多智能体协作。
吴恩达 Agentic AI 课程（Bilibili BV1DfrdByE2H，p29-p30）提出一个反直觉的判断：
多智能体系统的关键不是"代理数量越多越好"，而是怎么划分角色、配置工具，以及设计代理之间的通信与协调方式。
同样是研究员 / 设计师 / 撰稿人三个代理，线性传递、经理协调和自由讨论会产生完全不同的系统行为。通信模式选错了，再多代理也救不了；选对了，三个代理就够用。
本章对应本教程"四权模型"里的控制权：单 Agent 是 LLM 控制一个 loop，多 Agent 是控制权在多个 loop 之间传递。谁能调谁、谁决定下一步、什么时候结束任务，这些都需要显式设计。
我们会讲清楚四件事：
- 多智能体到底比单 Agent 强在哪里（什么时候值得拆）。
- 四种通信模式：线性 / 单层层级 / 深层级 / 全连接，各自的工程权衡。
- 通信协议设计：消息该包含什么字段，怎么避免上下文污染。
- 多 Agent 系统的调试：为什么必须看 trace，不能只看最终答案。
20.1 为什么需要多智能体
第 2 章讲过，单 Agent 是 "LLM + 工具 + 循环 + 状态 + 停止边界"。它已经能处理很多任务。什么时候才值得拆成多 Agent？
20.1.1 单 Agent 的三个瓶颈
瓶颈 1：工具数量爆炸
一个客服 Agent 如果同时处理订单查询、退货、库存、邮件、报表，工具列表可能 30+。LLM 每轮都要看全部工具 schema，token 浪费、选错工具概率上升。第 3 章讲的 Context Rot 会更严重。
瓶颈 2：提示词冲突
一个 Agent 既要"礼貌回复用户"又要"严格执行退货政策"时，prompt 会很长很矛盾。LLM 在两个目标间摇摆，输出不稳定。
瓶颈 3：上下文污染
第 8 章讲过上下文污染：长对话里 LLM 忘记原始目标。单 Agent 跑 20 轮，context 里堆满中间结果，模型开始幻觉、跑题。Subagent 隔离是解法，但隔离本身就需要多 Agent 架构。
20.1.2 多 Agent 的价值
多 Agent 把任务拆成多个角色，每个角色：
- 只看自己关心的工具（研究员只看搜索，撰稿人只看文本生成）
- 只读自己的 prompt（角色边界清晰，不会互相矛盾）
- 在独立 context 里跑（不污染主 context）
这就像人类团队：你不会让一个人同时做研究、设计、写作、审核；而是分工，每个人专注自己的领域。
20.1.3 但多 Agent 也有代价
Anthropic Multi-agent Research System 博客给了一个量化数据：
多 Agent 系统的 token 消耗是普通聊天的约 15 倍。
代价来源：
- 通信成本：Agent 之间传消息，每次都是 LLM 调用。
- 协调成本：orchestrator 决定下一步调谁，也是 LLM 调用。
- 重复工作：多个 Agent 可能独立做同一件事，浪费 token。
- 调试困难：失败时 trace 涉及多个 Agent，比单 Agent 难分析。
判断准则：
- 任务真的需要多个技能角色（研究 / 设计 / 写作 / 审核）吗？
- 工具数量是否超过 10 个？
- 单 Agent 跑 20 轮以上还会失焦吗？
- 三个问题都"是"，才值得上多 Agent。否则优先用单 Agent + Subagent 隔离。
20.2 角色分工的设计
多 Agent 系统的第一步是拆角色。一个好的拆法应该让每个 Agent 满足三个条件：
- 职责单一：一个 Agent 只做一类事（研究 / 写作 / 审核）。
- 工具匹配：每个 Agent 的工具集小而精（3-7 个工具）。
- 输出清晰：每个 Agent 的输出格式明确，下游 Agent 能直接用。
吴恩达课程给了一个典型拆法：太阳镜营销手册。
最终任务：为太阳镜品牌做夏季营销手册
代理 1：研究员
- 工具：网络搜索、资料整理
- 输入：品牌信息 + 季度 + 目标客户
- 输出：市场趋势、竞品分析、关键卖点、数据来源
- 成功标准：覆盖 5 个竞品 + 3 个趋势
代理 2：图形设计师
- 工具：图像生成、图像处理、代码执行（生成图表）
- 输入：代理 1 的研究摘要
- 输出：视觉方向、图表、设计说明、配色建议
- 成功标准：3 套视觉方向 + 至少 2 张图表
代理 3：撰稿人
- 工具：文本生成（无外部工具）
- 输入：研究摘要 + 视觉素材
- 输出：营销手册草稿
- 成功标准：覆盖趋势、竞品、卖点、目标客户
代理 4（可选）：营销经理
- 工具：无（只做协调和审核）
- 输入：用户请求 + 各代理输出
- 输出：任务分派、审核反馈、最终优化版本
- 成功标准：手册符合品牌调性、覆盖所有维度关键设计：
- 研究员不调图像生成（工具不匹配角色）。
- 撰稿人不调搜索（它只整合已有材料）。
- 经理代理没工具（它只协调，不执行）。
反模式：
- 让一个 Agent 既研究又写作（职责不清）。
- 给经理代理配 10 个工具（它应该只协调）。
- 让所有 Agent 共享一个大 prompt（失去拆分意义）。
20.3 四种通信模式
拆完角色，下一步是设计通信模式。吴恩达课程（p30）讲了四种。
20.3.1 线性模式（Linear）
研究员 -> 设计师 -> 撰稿人 -> 最终输出特征：代理按固定顺序依次执行，上游输出成为下游输入。
适合：
- 流程清晰、顺序固定的任务
- 报告生产、营销素材流水线、数据分析后生成文案
优点：
- 实现简单（一个 for 循环就行）
- 调试容易（trace 是线性的）
- 延迟可控（无协调开销）
- token 成本可预测
缺点：
- 不灵活：如果上游输出有问题，下游只能硬接
- 没有全局协调：无法处理"先研究再决定要不要设计"这类动态决策
伪代码：
def linear_pipeline(user_request):
research = researcher.run(user_request)
design = designer.run(research)
draft = writer.run(research, design)
return draft20.3.2 单层层级模式（Manager-Coordinator）
经理代理
/ | \
研究员 设计师 撰稿人特征：一个经理代理负责规划、分派、收集中间结果、决定下一步和最终整合。子代理只做自己擅长的事，把结果回传给经理。
适合：
- 需要统一目标管理、任务分派、审核的复杂任务
- 子任务有依赖关系（撰稿人要等研究员和设计师都完成）
- 需要审核和迭代（经理看了不满意，可以让子代理重做）
优点：
- 全局视图：经理能看到所有子代理输出，做整体决策
- 灵活：经理可以根据中间结果调整后续分派
- 容错：子代理失败时，经理可以换方案
缺点：
- 经理代理是瓶颈：所有通信都经过它，延迟和成本上升
- 经理 LLM 调用次数多：每轮分派、收集、整合都要调
- 调试更难：trace 是树形的，要追多个分支
伪代码：
def manager_coordinator(user_request):
plan = manager.plan(user_request) # 经理先规划
results = {}
for subtask in plan:
agent = pick_agent(subtask.role) # 经理决定调谁
results[subtask.id] = agent.run(subtask, prior_results=results)
if manager.is_not_satisfied(results[subtask.id]):
results[subtask.id] = agent.run(subtask, feedback=...) # 重做
return manager.integrate(results)20.3.3 深层级模式（Deep Hierarchy）
顶层经理
/ \
中层经理 中层经理
/ \ / \
研究员 事实核查 撰稿人 引用核查特征：子代理还可以调用更下层代理。研究员下面有网络研究员和事实核查员；撰稿人下面有引用核查员。
适合：
- 大型任务中存在专门子问题
- 子任务本身复杂到需要拆分
- 不同层级有不同视角（顶层管战略，中层管协调，底层管执行）
优点：
- 关注点分离：每层只管自己的事
- 可复用：事实核查代理可以被多个上层代理调用
- 扩展性强：加新能力只需加新子代理
缺点：
- 通信路径爆炸：N 层层级，最坏情况 trace 长度是 N × 子代理数
- 调试极难：失败可能发生在第 4 层的某个子代理
- 控制权传递风险：每层委派都可能丢上下文
工程做法：深层级不要超过 3 层。Anthropic Multi-agent 博客提到，超过 3 层后 token 成本和延迟会指数上升，而准确率提升边际递减。
20.3.4 全连接模式（Fully Connected / Mesh）
研究员 ←→ 设计师
↕ ↕
撰稿人 ←→ 审核员特征：每个代理都可以和其他代理直接通信，类似自由讨论。
适合：
- 探索性、创意性任务
- 容错空间较大的场景
- 多视角讨论能带来价值（如营销创意、设计评审）
优点：
- 灵活性最高
- 能产生意外协作（研究员突然问撰稿人某个点怎么表达）
缺点：
- 不可预测：很难提前知道对话会怎么走
- 成本失控：消息数是 O(N²)，N 个代理互相聊 token 爆炸
- 终止条件难定：什么时候停？谁决定停？
- 调试极难：trace 是网状的
反模式警告：生产系统慎用全连接。Anthropic 博客明确指出，全连接模式在生产环境的成本/收益比通常很差。它适合研究实验，不适合稳定生产。
20.3.5 四种模式对比
| 模式 | 复杂度 | 延迟 | 成本 | 可控性 | 调试难度 | 适合 |
|---|---|---|---|---|---|---|
| 线性 | ★ | 低 | 低 | 高 | ★ | 流程固定 |
| 单层层级 | ★★ | 中 | 中 | 中 | ★★ | 大多数复杂任务 |
| 深层级 | ★★★ | 高 | 高 | 中低 | ★★★ | 大型专门任务 |
| 全连接 | ★★★★ | 不可控 | 极高 | 低 | ★★★★ | 探索性研究 |
选型原则：
- 先用线性，跑不通再升级
- 需要协调和审核时上单层层级
- 子任务本身复杂才上深层级（最多 3 层）
- 全连接只用于研究实验，不进生产
20.4 通信协议设计
多 Agent 系统的隐性失败大多来自通信协议不清。一条消息该包含什么？谁来决定结束？这些都得显式定义。
20.4.1 经理 -> 子代理的消息模板
任务：分析 Q3 太阳镜销售数据，找出销量下滑的原因
背景：用户反馈最近销量下滑，怀疑是竞品降价。需要数据支持或反驳这个假设。
可用输入：
- /data/sales_q3.csv（字段：date, product, region, quantity, revenue）
- /data/competitor_prices.csv
期望输出：结构化报告，包含：1) 销量下滑幅度 2) 是否与竞品降价相关 3) 其他可能原因
格式要求：Markdown，500-1000 字
完成标准：每个结论必须有数据支撑，引用具体数字
限制条件：不要做预测，只做事实分析每个字段的作用：
- 任务：子代理要做什么（动作级）
- 背景：为什么要做（战略级，避免子代理跑偏）
- 可用输入：子代理能读哪些数据（防止它瞎调工具）
- 期望输出：输出长什么样（结构化）
- 格式要求：Markdown / JSON / 自由文本
- 完成标准：什么叫"做完了"
- 限制条件：哪些事不能做
20.4.2 子代理 -> 经理的回传模板
完成状态：完成 / 需要更多信息 / 失败
结果摘要：Q3 销量同比下滑 23%，其中 7 月下滑最严重（-31%）
关键产物：
- 销量趋势图：/output/sales_trend.png
- 详细数据：/output/sales_breakdown.csv
不确定点：竞品价格数据只覆盖 80%，可能漏掉区域品牌
建议下一步：可以再让"区域经理代理"按地区拆分分析关键字段：
- 完成状态：经理需要知道是直接整合，还是重做，还是补充信息
- 不确定点：让经理判断要不要再调一个代理补充
- 建议下一步：子代理对自己产出最了解，可以建议后续
20.4.3 避免上下文污染
第 8 章讲过上下文污染。多 Agent 系统更容易污染，因为消息在多个 context 之间传递。
反模式：
# 经理把所有历史都传给子代理
def bad_manager_call(subtask):
return sub_agent.run(
task=subtask,
full_history=manager.messages, # ← 把经理的所有历史塞进去
)子代理拿到经理的完整历史，会：
- Token 成本爆炸
- 注意力被无关历史稀释
- 可能被历史里的某个 prompt injection 攻击
正确做法：
def good_manager_call(subtask, prior_results):
# 只传当前任务需要的信息
return sub_agent.run(
task=subtask.description,
background=subtask.background,
relevant_inputs={k: v for k, v in prior_results.items()
if k in subtask.depends_on},
)工程原则：Agent 之间只传必要信息，不传完整 context。这是 Anthropic Multi-agent 博客的核心建议之一。
20.5 一个最小的多 Agent 系统
用 Anthropic SDK 写一个经理协调模式的最小示例：经理代理 + 研究员 + 撰稿人。
import anthropic
import json
client = anthropic.Anthropic()
# 子代理：研究员
def researcher(topic: str) -> str:
resp = client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=1024,
messages=[{"role": "user", "content":
f"你是研究员。请就主题 '{topic}' 提供 3 个关键事实和 2 个数据来源。只输出研究摘要，不要客套。"}]
)
return resp.content[0].text
# 子代理：撰稿人
def writer(research: str, audience: str) -> str:
resp = client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=1024,
messages=[{"role": "user", "content":
f"你是撰稿人。基于以下研究，写一段面向 {audience} 的文案（200 字内）：\n\n{research}"}]
)
return resp.content[0].text
# 经理代理：决定调谁、什么时候停
MANAGER_PROMPT = """你是项目经理。用户给你一个任务，你要决定：
1. 调用 researcher(topic) 做研究
2. 拿到研究后调用 writer(research, audience) 写文案
3. 如果文案不满意，可以让 writer 重写（带反馈）
4. 最多迭代 2 次
输出 JSON 决策：
{{"action": "researcher" | "writer" | "done", "args": {{...}}, "feedback": "..."}}
用户任务：{task}
已有结果：{state}
"""
def manager(task: str, max_steps: int = 5) -> str:
state = {}
for step in range(max_steps):
resp = client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=512,
messages=[{"role": "user", "content":
MANAGER_PROMPT.format(task=task, state=json.dumps(state, ensure_ascii=False))}]
)
decision = json.loads(resp.content[0].text)
if decision["action"] == "done":
return state.get("final", "未完成")
elif decision["action"] == "researcher":
state["research"] = researcher(**decision["args"])
print(f"[Step {step}] researcher -> {state['research'][:100]}...")
elif decision["action"] == "writer":
state["draft"] = writer(
research=state.get("research", ""),
audience=decision["args"].get("audience", "general")
)
print(f"[Step {step}] writer -> {state['draft'][:100]}...")
state["final"] = state["draft"]
return state.get("final", "步数上限")
if __name__ == "__main__":
print(manager("写一段关于 Claude 4.5 的产品文案"))运行流程：
[Step 0] researcher -> Claude 4.5 是 Anthropic 2025 年发布的多模态...
[Step 1] writer -> Claude 4.5 来了：更强的多模态、更长的上下文...
[Step 2] done
最终输出：Claude 4.5 来了：更强的多模态、更长的上下文...注意经理代理没有工具调用权限，它只输出 JSON 决策。真正的执行（调 researcher / writer）由代码完成。这是"LLM 决策，代码执行"原则的体现（第 19 章讲过）。
20.6 多 Agent 系统的调试
多 Agent 系统最大的工程难点不是写出来，是出问题时能找到根因。吴恩达课程强调：多 Agent 系统一定要看 trace，不能只看最终答案。
20.6.1 只看最终答案会错过什么
最终答案不好，可能是：
- 经理没委派（自己瞎做）
- 经理委派错代理（让撰稿人做研究）
- 子代理指令不清（研究员没理解任务）
- 子代理工具参数错（搜索关键词不对）
- 子代理输出格式不对（下游无法使用）
- 状态没保存（撰稿人看不到研究员的输出）
- 终止条件触发太早（经理觉得"差不多了"就停）
每种失败的修法完全不同。只看最终答案，你不知道是哪一种。
20.6.2 trace 应该记录什么
每条事件包含：
- timestamp
- agent_name（哪个代理）
- event_type：message_in / message_out / tool_call / tool_result / decision
- content（消息内容或工具调用参数）
- token_cost
- latency_ms
每轮包含：
- 当前经理状态
- 各子代理状态
- session state diff（这轮相比上轮改了什么）20.6.3 多 Agent 调试检查清单
观察 trace 时重点看：
- 初始事件由哪个代理创建
- 经理是否正确委派
- 子代理是否接收了完整上下文
- 工具调用名称是否正确
- 工具参数是否从用户消息中正确提取
- 工具返回是否符合结构
- 哪个事件被标记为 final response
- session state 是否按预期更新
- 每个代理的 token 消耗占比
- 哪一步延迟最长20.6.4 用 verbose 输出学习
学习多 Agent 系统时，强烈建议打开 verbose 模式，看每个事件的产生过程。verbose 输出噪声多，但能让你看到：
- 经理怎么决定调谁
- 子代理怎么理解任务
- 工具调用参数怎么来的
- 最终答案怎么整合的
第 22 章 Google ADK 实战会讲怎么用 ADK 的 verbose 模式调试多 Agent 系统。
20.7 反模式
反模式 1：盲目上多 Agent
"我听说多 Agent 很强，所以我把一个简单的客服 Agent 拆成了 5 个代理。"
如果单 Agent + 几个好工具能搞定，不要拆。多 Agent 的协调成本和调试成本远超你的想象。
判断：先单 Agent 跑，跑不通再考虑拆。
反模式 2：每个代理一个模型
"我用 GPT-4o 做研究，Claude 做写作，Gemini 做审核，组合最强模型。"
不同模型的 prompt 风格、工具调用格式、输出格式都不一样。混用会让系统不稳定，调试地狱。
判断：同一系统优先用同一家模型。需要混用时，加一层适配器统一接口。
反模式 3：经理代理配一堆工具
"经理代理有 20 个工具，可以自己干活也可以委派。"
经理代理应该只协调，不执行。给它工具会让它忍不住自己干，失去协调角色。
判断：经理代理的工具集应该是"委派给谁"的元操作，不是具体业务工具。
反模式 4：让 Agent 直接共享 context
"我把所有代理的 messages 都合并到一起，这样它们都能看到全部历史。"
这是上下文污染的极端版本。token 爆炸、注意力稀释、prompt injection 风险全暴增。
判断：Agent 之间通过结构化消息传递，不共享 context。第 5 章 Context Engineering 详细讲过这个原则。
反模式 5：全连接进生产
"我看 AutoGen 群聊很有趣，把客服系统做成全连接。"
全连接在生产环境的成本/收益比通常很差。Anthropic 博客明确说多 Agent token 是普通聊天 15 倍，全连接会更糟。
判断：生产用线性或单层层级。全连接只用于研究实验。
前人智慧 / Prior Art
本章把多 Agent 通信模式拆成四种（线性 / 单层层级 / 深层级 / 全连接），这个分类不是本教程原创，它来自多篇论文和工程博客的共同归纳。
Anthropic Multi-agent Research System 的工程经验
Anthropic Multi-agent Research System 博客是本章最重要的参考。博客里的关键经验：
- Orchestrator-Worker 模式：对应本章 20.3.2 单层层级。Anthropic 自己的研究系统用这个模式，orchestrator 拆任务分派给 worker。
- Subagent 隔离：每个 subagent 在独立 context 里跑，主 orchestrator 只拿结论。这是本章 20.4.3 "避免上下文污染"的来源。
- Token 成本 15 倍：多 Agent 系统比单 Agent 贵 15 倍。本章 20.1.3 "代价"部分引用了这个数据。
- Evolution：从单 Agent 到 subagent 到多 Agent，是渐进演化，不是一步到位。这支撑了本章 20.7 反模式 1 "不要盲目上多 Agent"。
AutoGen 的群聊模式
AutoGen 是 Microsoft 的多 Agent 框架，最有名的功能是 GroupChat（群聊）。群聊就是本章 20.3.4 的全连接模式。
AutoGen 的贡献是证明了全连接模式可以工作：在创意任务、设计评审、辩论场景下，多 Agent 自由讨论能产生意外价值。但 AutoGen 文档也明确警告：群聊在生产环境的成本不可控，需要严格的终止条件和预算限制。
本章 20.3.4 "全连接只用于研究实验"的判断，和 AutoGen 文档一致。
CrewAI 的角色扮演
CrewAI 把多 Agent 拆成"角色扮演"：每个 Agent 有 role / goal / backstory。这个设计来自组织行为学的"角色理论"。
CrewAI 的工程贡献是让角色定义成为一等公民：
researcher = Agent(
role="Senior Research Analyst",
goal="Uncover cutting-edge developments in AI",
backstory="You are a meticulous researcher with 10 years of experience...",
tools=[search_tool, scrape_tool],
)这种写法对应本章 20.2 的"角色分工设计"。role / goal / backstory 让 LLM 更容易进入角色，输出更稳定。
LangGraph 的图式编排
LangGraph 把多 Agent 系统建模成"图"：节点是 Agent，边是消息流。这个抽象比"角色扮演"更通用，可以表达任意通信模式。
LangGraph 的工程贡献是让通信模式成为显式图结构：
- 线性 = 链状图
- 单层层级 = 星形图
- 深层级 = 树形图
- 全连接 = 完全图
本章 20.3 的四种模式，在 LangGraph 里都是不同的图拓扑。LangGraph 的好处是图可视化、可持久化、可断点续跑。
Andrew Ng Agentic AI 课程的通信模式分类 07-09
本章内容主要整理自吴恩达 Agentic AI 课程 Module 5（Bilibili BV1DfrdByE2H，p29-p30）。课程的贡献是把多 Agent 通信模式归纳成四种，并给出选型建议：
- 线性：流程清晰、调试简单、延迟可控
- 经理协调：任务复杂、需要统一分派和整合
- 深层级：存在复杂子任务，需要专业下级代理
- 全连接：探索性强、能容忍不可预测性
课程的关键判断："越自由的通信模式，越可能产生复杂协作，但越难保证稳定、可解释和可复现"。这正是本章 20.3.5 对比表"可控性"那一列的来源。
课程还提到一个工程经验：多 Agent 系统的难点不只是创建角色，而是让角色之间可靠协作。本章 20.4 通信协议设计、20.6 调试方法，都是为了让协作"可靠"。
MetaGPT 的 SOP（标准作业程序）
MetaGPT 论文（Hong et al., 2023）提出把多 Agent 系统建模成"标准作业程序"（SOP）。每个 Agent 有明确角色（产品经理 / 架构师 / 工程师 / QA），按 SOP 流程协作。
MetaGPT 的工程贡献是把人类组织的 SOP 编码到 Agent 系统：
- 产品经理 Agent 写 PRD
- 架构师 Agent 设计系统
- 工程师 Agent 写代码
- QA Agent 测试
这种结构对应本章 20.3.1 线性模式 + 20.3.2 单层层级的组合。MetaGPT 在软件工程任务上比 ReAct 提升明显，关键就在于 SOP 让协作有序。
ChatDev 的瀑布模型
ChatDev 论文（Qian et al., 2023）把软件开发拆成多个 Agent 角色，按瀑布模型协作：需求 -> 设计 -> 编码 -> 测试 -> 文档。
ChatDev 的贡献是证明了多 Agent 系统可以完成端到端软件工程任务。它用线性模式 + 角色分工，让多个 Agent 协作写出一个能跑的小游戏。这是本章 20.3.1 线性模式的典型应用。
多 Agent 系统的"通信开销"研究
Liu et al. 2024 研究了多 Agent 系统的通信开销。结论：
- 通信开销随 Agent 数量呈 O(N²) 增长（全连接模式）
- 层级模式可以降到 O(N log N)
- 但层级模式的延迟更高（消息要经过中间层）
这个研究支撑了本章 20.3.5 对比表的"成本"列：全连接成本极高，层级次之，线性最低。
多 Agent 协作模式与组织行为学的对应
本章四种通信模式，都能在人类组织里找到对应：
| 通信模式 | 人类组织对应 | 适合 |
|---|---|---|
| 线性 | 流水线 / 生产线 | 标准化任务 |
| 单层层级 | 经理 + 团队 | 大多数复杂任务 |
| 深层级 | 多层管理 | 大型组织 |
| 全连接 | 头脑风暴 / 圆桌讨论 | 创意任务 |
这种对应不是巧合。多 Agent 系统本质是"模拟人类团队协作"，所以人类组织的经验直接适用。第 8 章 8.5 节"越权执行"的防御（白名单 / Hook / 审计）也是来自组织管理的"权限分级"思想。
20.8 小结
- 多 Agent 系统适合任务真的需要多个技能角色、工具数量爆炸、单 Agent context 污染严重的场景。否则优先用单 Agent + Subagent 隔离。
- 四种通信模式：线性（流程固定）/ 单层层级（大多数复杂任务）/ 深层级（大型专门任务，≤3 层）/ 全连接（只用于研究实验）。
- 通信协议要显式：经理给子代理的消息包含任务 / 背景 / 输入 / 期望输出 / 完成标准 / 限制；子代理回传包含状态 / 摘要 / 产物 / 不确定点 / 建议。
- 多 Agent 系统必须看 trace，不能只看最终答案。trace 应记录每个代理的消息进出、工具调用、状态变化、token 消耗、延迟。
- 反模式：盲目上多 Agent / 每代理一个模型 / 经理配一堆工具 / 共享 context / 全连接进生产。
下一章我们讲 Agent 知识图谱--当任务需要跨数据源关联、复杂关系推理时，怎么用领域图 + 词汇图 + 主题图三层结构组织知识，以及怎么用多 Agent 系统构建这种图谱。
happy ending, love you.