基于LSTM的时间序列预测实战：从数据处理到设备寿命预测
2026/10/1 17:28:11
多 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 确实搞不定：
- 职责太杂：一个 Agent 又当"研究员"又当"写码的"又当"审查的"，提示词会互相打架（第 53 节会讲提示是"一个角色一个使命"）；
- 上下文打架：单个 Agent 想把"查 100 个文件 + 综合写报告"塞进一个上下文，很快撑爆（第 22 节讲过窗口是命门）；
- 性能问题：串行慢，多个无依赖的子任务本可并行跑（第 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 那一大坨。为什么？
- 防污染：子 Agent A 读到的无关内容，不该影响 B 的判断；
- 省成本：每个子 Agent 只带自己那份精简上下文，token 总账更划算（第 13 节成本）；
- 保证专注：隔离的上下文让子 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 更需要智慧。
小结
- 多 Agent 解决三件事：职责太杂、上下文打架、串行慢——不是为多而多。
- agent-as-tool 是统一抽象：Agent 也是工具，父 Agent 调用子 Agent 和调用函数一样自然。
- 三种拓扑：router（分叉分发）/ pipeline（阶段流水）/ swarm（动态协作），匹配任务来选择。
- 上下文隔离是纪律：各持独立上下文、交换摘要而非全量，保专注省成本。
- 选型看两问：任务复杂到要分工吗？子任务怎么连（并行/串行/分叉）？
- 单 Agent 常常更好：只在"并行收益 > 额外调用成本"时才上编排。
下节预告
六层架构走完五层，还剩最后一块——也是最"工程味"的一块：可观测性。为什么每次模型调用都要留痕？怎么用一句话提示词分析调用速度、token 与耗时的关系？这节讲调用留痕与量化分析，也是整个理论区的收官章（附第二部分自测清单）。
如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！
本系列持续更新中，关注不迷路~