多 Agent 编排：进程调度的艺术

一个 Agent 是一把好手，多个 Agent 是"军队"。但军队要有纪律、有分工、有调度。这一节讲 router、pipeline、swarm 三种编排拓扑，以及最重要的判断力：什么时候该上多个 Agent，什么时候一个更好。

本文导航

• 从单个 Agent 到多个 Agent
• agent-as-tool：编排的基本单元
• 三种编排拓扑：router / pipeline / swarm
• 子 Agent 的上下文隔离
• 选型决策树：用几个 Agent 更好
• 什么时候一个 Agent 比多个更好
• 小结
• 下节预告

---

第 24 节。六层架构第五层：多 Agent 编排。前面五节素材我们有了：单个 Agent 的心脏（第 4 章）、双手（21）、眼与记忆（22）、缰绳（23）。现在问题来了——如果任务太复杂，一个 Agent 忙不过来怎么办？

这时候你可能想：那就派两个、三个、十个 Agent 一起上。但多 Agent 不是"堆人数"，盲目上会陷入混乱。这节把"编队"讲清楚：基本单元、三种队形、隔离纪律、选型智慧。

从单个 Agent 到多个 Agent

先说清楚：为什么需要多个 Agent？ 不是每个任务都需要，但有几种情况单 Agent 确实搞不定：

1. 职责太杂：一个 Agent 又当"研究员"又当"写码的"又当"审查的"，提示词会互相打架（第 53 节会讲提示是"一个角色一个使命"）；
2. 上下文打架：单个 Agent 想把"查 100 个文件 + 综合写报告"塞进一个上下文，很快撑爆（第 22 节讲过窗口是命门）；
3. 性能问题：串行慢，多个无依赖的子任务本可并行跑（第 56 节会用 asyncio 并行）。

多 Agent 的核心思想：把一个复杂任务，拆给多个各有专长、各持小上下文的 Agent，最后聚合结果。 它对应第 7 节 Karpathy 类比里的"进程调度"——每个 Agent 像一个进程，编排器是操作系统。

agent-as-tool：编排的基本单元

多 Agent 是怎么"互相对话"的？先介绍一个超重要的抽象：agent-as-tool（把 Agent 当工具用）。

在外部看来，一个 Agent 和前面第 21 节的工具长得一模一样——有名字、有描述、有输入参数、有输出。它就是个"更聪明的工具"：你给它一个子任务，它内部跑自己的循环（可能还调小工具），然后吐出一个结果给你。

# agent-as-tool 的抽象：Agent 也是工具
sub_agent = Agent(
    name="code_reviewer",           # 名字，像工具名
    system="你是代码审查专家…",      # 自己的系统提示（独立人格）
    tools=[read_file, grep],        # 只给它审查需要的精简工具
    max_iters=10,                   # 自己的循环上限
)
result = sub_agent.run("审查 app/main.py 的安全问题")  # 像调用工具一样调用

这个抽象极其强大，因为它让"编排"变得统一：无论是调用一个函数工具，还是调用一个子 Agent，父 Agent 的代码一模一样——都是"工具是士兵，Agent 是军官，两者同框编队"。后面第 12 章 v0.7《agent-as-tool》会把它实现透，包括子 Agent 独立上下文、工具子集、结果摘要回传。

三种编排拓扑：router / pipeline / swarm

有了"Agent 也是工具"这个单元，就可以搭各种队形。三种主流拓扑，各有适用场景：

拓扑	特点	像什么	适用场景
Router 路由	一个路由器按任务类型，分发给最适合的 Agent	客服转接	任务类型多种多样、每种有专门 Agent
Pipeline 流水线	前一个 Agent 的输出是下一个的输入，串成链	工厂流水线	任务有明确阶段依赖（清洗→分析→报告）
Swarm 群蜂	一个总控 Agent 灵活分派多个子 Agent，允许互动	团队协作	复杂、需实时分工协作的任务

三种拓扑的选择和任务性质强相关：任务"类型分叉"选 router，任务"阶段推进"选 pipeline，任务"动态协作"选 swarm。没有谁高级谁低级，匹配任务最重要。

子 Agent 的上下文隔离

多 Agent 里最容易被忽视、却最要命的纪律是：上下文隔离。

每个子 Agent 必须有自己的独立上下文（自己的 messages），绝不共享父 Agent 那一大坨。为什么？

1. 防污染：子 Agent A 读到的无关内容，不该影响 B 的判断；
2. 省成本：每个子 Agent 只带自己那份精简上下文，token 总账更划算（第 13 节成本）；
3. 保证专注：隔离的上下文让子 Agent “只见树木”，专注眼前任务（第 22 节讲过上下文=眼睛）。

协作时，父子之间交换的不是全部上下文，而是"结果摘要"：父 Agent 给子 Agent 的是"你要负责的子任务 + 相关小片段"，子 Agent 回传的是"我查到了什么"的精炼结论。交换摘要而非全量，是隔离纪律的核心——既保专注、又省成本、还不泄密。

选型决策树：用几个 Agent 更好

多 Agent 是有代价的：每个 Agent 都要自己的循环、自己的提示词、自己的多轮 API 调用（哪轮都花钱）。所以决定"用几个 Agent"是成本优化题，我总结成一张决策树：

任务复杂度高吗?（要多种角色 / 多种工具 / 上下文可能撑爆）
├── 否 → 单 Agent 就够了（省心省钱）
└── 是 → 子任务之间有没有依赖?
    ├── 无依赖(可并行) → 多个并行子 Agent (swarm/router)
    ├── 有先后依赖 → pipeline 流水线
    └── 有少量依赖但类型分叉 → router 路由分发

核心判断就两问：“任务复杂到需要分工吗？” + “子任务怎么连（并行/串行/分叉）？” 想清楚这两问，选型不会错。

什么时候一个 Agent 比多个更好

最后泼盆冷水——多 Agent 不是银弹，很多时候单 Agent 更好。我这个结论是从踩坑得来的：

场景	建议	原因
简单任务（改个 bug）	单 Agent	多 Agent 徒增开销+延迟
任务强耦合、难以拆分	单 Agent	拆分反而破坏上下文连贯
刚上手、调优成本高	单 Agent	先跑通一个，再谈编排
复杂但可并行	多 Agent	才值得上编排

那多一个 Agent 的代价到底多大？两个 Agent 的两轮循环 = 4 次调用；一个"一体 Agent"可能 3 次就干完。编排的价值是"用更多调用换更好的分工和并行"，只有当进步收益 > 额外成本时，多 Agent 才划算。这就是为什么我说"什么时候一个更好"同样重要——知道不用多 Agent，比会用多 Agent 更需要智慧。

---

小结

1. 多 Agent 解决三件事：职责太杂、上下文打架、串行慢——不是为多而多。
2. agent-as-tool 是统一抽象：Agent 也是工具，父 Agent 调用子 Agent 和调用函数一样自然。
3. 三种拓扑：router（分叉分发）/ pipeline（阶段流水）/ swarm（动态协作），匹配任务来选择。
4. 上下文隔离是纪律：各持独立上下文、交换摘要而非全量，保专注省成本。
5. 选型看两问：任务复杂到要分工吗？子任务怎么连（并行/串行/分叉）？
6. 单 Agent 常常更好：只在"并行收益 > 额外调用成本"时才上编排。

下节预告

六层架构走完五层，还剩最后一块——也是最"工程味"的一块：可观测性。为什么每次模型调用都要留痕？怎么用一句话提示词分析调用速度、token 与耗时的关系？这节讲调用留痕与量化分析，也是整个理论区的收官章（附第二部分自测清单）。

---

如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！
本系列持续更新中，关注不迷路~