入门系列里，我们做的都是"单个 Agent"——一个大模型，手里握着几个工具，自己决定怎么用。工具少的时候它很聪明。但当任务越来越复杂、工具越来越多，你会发现它开始"变笨"。这一篇用大白话讲清：为什么一个 Agent 会扛不住，以及"多智能体"是怎么分工解决的。 这篇几乎不涉及代码，重在把思路讲透，下一篇再动手用 LangGraph 搭。

单个 Agent 是怎么"变笨"的

想象你招了一个全能员工，让他一个人干客服、财务、销售、运维四份工作。刚开始还行，业务一多就乱套了：他记不清每件事的规矩、常常用错流程、你也搞不清他到底哪一步出的错。

单个 Agent 塞太多东西时，会遇到一模一样的问题：

工具一多就选错。 Agent 靠工具的"说明书"来判断该调哪个。工具只有三五个时清清楚楚；一旦堆到二三十个，好几个功能还相似（比如「查订单」「查物流」「查售后进度」），它就开始纠结、选错，甚至该调工具时不调、不该调时乱调。

一个提示词想管所有事，就谁也管不好。 你想让它既是专业严谨的财务、又是热情亲切的客服，还得懂技术排障——这些要求塞进同一段系统提示词，往往互相打架，最后哪个角色都演不到位。

上下文越堆越长、越乱。 一个 Agent 全程处理所有环节，对话历史里混着各种主题的中间结果，又长又杂，既烧 token 又容易让模型"跑偏"。

出了问题难排查。 所有逻辑糊在一个 Agent 里，它某一步答错了，你很难定位到底是"检索错了"还是"工具用错了"还是"理解偏了"。

多智能体：把"全能员工"换成"专业团队"

解决思路和公司管理一模一样：别让一个人身兼数职，拆成一个各有专长的团队，每人只管自己擅长的那摊。

举个具体的例子——做一个"差旅助手"。单个 Agent 版本要同时会：查航班、订酒店、查天气、算预算、报销……工具二十来个，一团乱。拆成团队后就清爽了：

• 机票专员：只管航班查询和改签，工具就那么两三个，说明书清清楚楚。
• 酒店专员：只管住宿。
• 报销专员：只管预算和发票。
• 再加一个主管：它自己不干具体活，只负责"听懂用户要什么，然后派活给对的专员，最后把结果汇总"。

每个专员的提示词专注、工具精简，自然做得又准又稳；主管负责调度。这就是最常用的多智能体模式——主管-专员模式（Supervisor）。

另一种常见模式：流水线

除了"主管派活"，还有一种是流水线（Pipeline）——几个 Agent 像工厂流水线一样依次接力，前一个的产出是后一个的输入。

比如做一个"自动写周报"的应用：收集专员先从各处拉取本周数据 →分析专员把数据总结成要点 →润色专员把要点写成通顺的周报。每个环节各司其职、顺序固定。主管模式适合"不确定要调谁、动态决策"的场景，流水线适合"步骤固定、按顺序走"的场景。

重要提醒：别为了拆而拆

多智能体很强，但它不是越多越好。拆成多个 Agent 会带来新的复杂度：Agent 之间要传递信息、要协调、整体延迟更高、也更难调试。

一个务实的判断标准：如果单个 Agent 配好工具、写好提示词就能稳定完成，就别拆。 只有当你明显感到"工具太多它选不清""几种角色/职责互相打架""流程复杂到一个 Agent 扛不动"时，再考虑拆分。工程上永远优先选更简单的方案，多智能体是"确实需要了"才上的重武器。

小结

记住这条主线：任务简单 → 单 Agent；任务复杂到一个 Agent 又选错工具、又演不好多重角色 → 拆成多智能体团队。 最常用的两种协作方式是主管-专员（动态派活）和流水线（固定接力）。而拆分本身有成本，别过度设计。

道理讲透了，下一篇我们动手：用 LangGraph 把"主管 + 几个专员"真正搭出来，跑一个能协作的多智能体。