后端第十六课：Multi-Agent 多智能体（让多个 Agent 分工协作）

后端第十六课Multi-Agent 多智能体让多个 Agent 分工协作 我是 Yulia一线 AI 应用开发工程师4 年工程经验在职做大模型应用落地。只写一件事——把最新 AI 技术讲成人话 给你能直接上手用的代码真实可验证不搬运不注水。有用就点个关注持续更新大模型应用的前沿实战。 本文是《后端开发从入门到靠谱》系列第 16 篇。前面我们把单 Agent 做明白了工具、记忆、上下文工程但真实项目里一个 Agent 单打独斗常常不够——上下文会爆、职责会乱、错误会传染。这一课讲Multi-Agent 多智能体把一个大任务拆给多个 Agent 分工协作。一个 Agent 很强但让它一个人写代码、查资料、审代码、跑测试、改 bug……上下文越塞越多最终看花眼、顾此失彼。这就像一个人既要当经理又要当员工——累且容易出错。多智能体Multi-Agent的思路很简单别让一个 Agent 干所有事让多个 Agent 各司其职、互相协作。读完你会拿到一个直觉模型多智能体 一家公司有经理、有员工各司其职为什么需要多智能体单 Agent 的三大硬伤三种协作模式编排者-执行者 / 交接Handoff/ 路由Router底层原理每个子 Agent 有独立的上下文窗口——这是它不串味、不爆仓的根因一个完整实现编排者 多个执行者的代码骨架逐行讲解多智能体的常见坑状态共享、通信开销、无限递归先看全景图多智能体协作的样子用户任务编排者 Agent执行者 写代码执行者 查资料执行者 审代码汇总结果一、为什么需要多智能体单 Agent 的三大硬伤先搞清楚为什么否则容易为了多而多。上下文爆仓单 Agent 干长任务所有中间过程都堆进一个上下文窗口撞上第十四课讲的 O(n²) 注意力墙职责混乱一个 Agent 既要写代码又要审代码、既要查资料又要下结论prompt 里塞满矛盾指令容易顾此失彼错误传染一个环节出错整个上下文被污染后面全跑偏且很难定位。单 Agent上下文爆仓职责混乱错误传染多智能体的解法把任务拆开每个 Agent 只干一件小事、只在自己的上下文里思考最后汇总。二、底层原理每个子 Agent 有独立的上下文窗口这是多智能体为什么有效的根因也是面试最该讲清的一点。回忆第十四课上下文是有限的注意力预算塞得越多越笨。多智能体的核心价值就在于——每个子 Agent 有自己干净的上下文窗口只放 高层规划只放 专注任务1主 Agent 上下文子 Agent 上下文1子 Agent 上下文2子 Agent 可以各自深入探索几万 token但只把浓缩后的结果通常几千 token 的摘要返回给主 Agent。详细的中间过程隔离在子 Agent 内部主 Agent 只看到结论——这样主 Agent 的上下文永远干净不会看花眼。这正是第十四课子智能体sub-agent“那一招的完整展开它不只是绕过上下文限制”更是关注点分离separation of concerns——让每个 Agent 专注自己那一小块。三、三种协作模式多智能体不是随便堆几个 Agent而是有几种经典的协作结构协作模式编排者 执行者一个规划 多个执行交接 Handoff任务转给下一位路由 Router按类型分流3.1 编排者-执行者Orchestrator-Worker最主流的模式一个编排者 Agent负责拆解任务、分配、汇总多个执行者 Agent各干一件事。适合任务能清晰拆成几个子任务如做一个功能→ 写代码 写测试 写文档。3.2 交接Handoff一个 Agent 把任务直接交给另一个 Agent 接手像转接客服。适合不同专长接力如通用客服 → 技术客服、“销售 → 售后”。3.3 路由Router一个路由 Agent先判断任务类型再分流到对应的专职 Agent。适合入口统一、分支清晰的场景如知识库问答 → RAG Agent / 写代码 → 代码 Agent。四、完整实现编排者 执行者用最主流的编排者-执行者模式写一个最小骨架逐行讲解deforchestrator(task:str):编排者拆任务 → 分配 → 汇总plancall_llm(f把这个任务拆成子任务列出子任务列表\n{task})sub_tasksparse_subtasks(plan)# 拆成 [子任务1, 子任务2, ...]results[]forsubinsub_tasks:# 逐个分配resultworker(sub,role执行者)# 每个子任务交给独立的执行者results.append(result)# 汇总所有子结果生成最终答案finalcall_llm(f根据这些子结果回答原始任务\n{task}\n\n子结果\n{results})returnfinaldefworker(sub_task:str,role:str)-str:执行者在自己的独立上下文里干一件小事返回浓缩结果# 关键这里是一个干净的上下文只包含这一个子任务resultcall_llm(f你是{role}专注完成下面这一件事完成后返回简洁的结果摘要\n{sub_task})returnresult逐行讲清三个关键设计编排者负责拆和汇它只做高层规划拆任务、汇总结果不深入细节——所以它的上下文很干净执行者负责干每个子任务在一个独立的worker调用里完成上下文只装这一件事不互相污染执行者返回摘要而非全过程worker让执行者返回简洁的结果摘要这样主 Agent 拿到的永远是浓缩结论而不是几万 token 的中间过程。五、多智能体的进阶状态共享与通信真实的多智能体系统还要解决两个问题5.1 状态怎么共享多个 Agent 需要共享进展到哪了比如代码已经写完了该测试了。通常用一个共享状态图状态、共享内存、消息队列state{status:待开始,artifacts:{}}# 共享状态defworker(sub_task:str,state:dict):resultcall_llm(f当前状态{state}\n完成{sub_task})state[artifacts][sub_task]result# 写回共享状态returnresult关键共享状态要少而精只放关键结论和状态别放全过程否则又回到上下文爆仓的老路。5.2 怎么通信Agent 之间通信有两条路通过编排者中转星型所有结果都汇总到编排者由它分配——简单、可控但编排者成瓶颈直接通信网状Agent 之间直接传递消息——灵活但容易失控消息乱飞。生产上星型更常见可控、易调试。网状只在对时效要求高的场景用。六、常见坑与避坑指南坑原因解决方案无限递归Agent 之间来回踢皮球设最大轮数 编排者强制收敛上下文照样爆主 Agent 塞进所有子结果子 Agent 只回浓缩摘要状态不一致共享状态没同步状态集中管理 版本控制拆任务拆太碎子任务过细通信开销超过收益只在确实能拆分时才用多智能体通信开销大Agent 之间来回传太多星型拓扑 减少不必要的往返重要提醒多智能体不是银弹。如果单 Agent 能搞定就别上多智能体——多一个 Agent 就多一层通信开销、多一个出错点。Anthropic 的建议始终是先做能跑通的最简方案。七、什么时候用单 Agent什么时候用多 Agent场景用哪种单一职责、流程短单 Agent长任务、上下文会爆多智能体子 Agent 隔离上下文需要并行探索多线研究多智能体并行子 Agent需要多种专长接力多智能体交接/路由判断标准任务能不能清晰拆成多个相对独立、可并行、各有专长的子任务能 → 多智能体不能 → 单 Agent。总结一张图带走这课的核心一句话串起来多智能体 一家公司编排者是经理拆任务、汇总执行者是员工各干一件事。为什么有效每个子 Agent 有独立的上下文窗口关注点分离——主 Agent 只看到浓缩结论不看花眼。三种模式编排者-执行者最主流、交接转接专长、路由按类型分流。关键设计执行者只回摘要不回全过程状态共享要少而精通信用星型拓扑可控。别滥用单 Agent 能搞定就别上多智能体——多一层 Agent 多一层开销和出错点。三个立即可用的行动把上一课写代码的任务拆成写代码 写测试 审代码三个子任务用编排者-执行者模式跑一遍观察执行者返回的内容——强制它只回摘要看看主 Agent 的上下文是不是干净多了给你的多智能体系统加一个最大轮数限制防止 Agent 之间无限踢皮球。如果这篇对你有帮助点个赞、收藏一下下一篇我们讲Agent 安全与护栏——多智能体系统越大越要考虑防越权、防注入、防失控。关注我我会持续更新 AI 应用开发的前沿实战陪你从单 Agent 一路进阶到多智能体系统。你在做多智能体时是不是遇到过Agent 之间来回踢皮球、任务推不下去的情况你是怎么收敛的评论区聊聊我挨个回。本文多智能体模式参考主流 Agent 框架LangGraph 等的通用设计具体编排方式可替换以官方文档为准评论区提醒我。