多 Agent 编排进程调度的艺术一个 Agent 是一把好手多个 Agent 是军队。但军队要有纪律、有分工、有调度。这一节讲 router、pipeline、swarm 三种编排拓扑以及最重要的判断力什么时候该上多个 Agent什么时候一个更好。本文导航从单个 Agent 到多个 Agentagent-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_agentAgent(namecode_reviewer,# 名字像工具名system你是代码审查专家…,# 自己的系统提示独立人格tools[read_file,grep],# 只给它审查需要的精简工具max_iters10,# 自己的循环上限)resultsub_agent.run(审查 app/main.py 的安全问题)# 像调用工具一样调用这个抽象极其强大因为它让编排变得统一无论是调用一个函数工具还是调用一个子 Agent父 Agent 的代码一模一样——都是工具是士兵Agent 是军官两者同框编队。后面第 12 章 v0.7《agent-as-tool》会把它实现透包括子 Agent 独立上下文、工具子集、结果摘要回传。三种编排拓扑router / pipeline / swarm有了Agent 也是工具这个单元就可以搭各种队形。三种主流拓扑各有适用场景Swarm 群蜂总控研究员写码者审查者Pipeline 流水线数据清洗 Agent分析 Agent写报告 AgentRouter 路由客服类技术类投诉类请求路由器客服 Agent技术 Agent投诉 Agent拓扑特点像什么适用场景Router 路由一个路由器按任务类型分发给最适合的 Agent客服转接任务类型多种多样、每种有专门 AgentPipeline 流水线前一个 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 与耗时的关系这节讲调用留痕与量化分析也是整个理论区的收官章附第二部分自测清单。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~