从单 Agent 到多 Agent 团队：四个设计决策与它们的落地代价

最近在梳理多智能体（Multi-Agent）平台的落地路径，把 EduSwarm 这类"AI 教师团队"的设计读了一遍，并结合自己的实践做了一次复盘。多 Agent 不是把模型复制几份就完事，它更像组织设计：先拆角色，再定流程，最后配信号。下面是我认为最关键的四个决策，以及它们各自的代价。

一、单 Agent 的天花板在哪

单 Agent 做"大而全"的提示词，早期迭代很快，但很快会撞到三堵墙：一是提示词越长，指令之间越容易互相稀释，模型会在"既要严谨又要活泼"里摇摆；二是不同任务需要不同上下文，混在一个会话里互相污染；三是无法并行，一个复杂任务只能串行推进，延迟随步骤线性增长。

多 Agent 的收益，本质来自"上下文分片 + 并行 + 职责约束"，而不是来自"更多模型调用"。

二、决策一：按职责拆角色，一个 Agent 只做一件事

把"备课"拆成课件制作、出题、批改、学情分析等专职角色，每个角色只拿自己需要的那部分上下文（比如学情分析师只看成绩分布，不看课件排版）。好处很直接：提示词更短更聚焦，输出质量稳定，失败时能定位到具体角色。

代价是拆分的粒度很难一次定对。拆太细，角色之间要靠大量传参衔接，链条一长，任何一环输出格式漂移都会让下游崩；拆太粗，又退化成单 Agent。实践中的经验是：以"可独立验收的交付物"为边界，一个角色对应一种可以被人检查的产物（课件、习题、批改报告），而不是按"思考步骤"拆。

三、决策二：有明确的调度者，而不是让 Agent 自由对话

让多个 Agent 互相自由讨论，看起来很"智能"，实际最容易失控：容易发散、重复劳动、责任不清。更稳的做法是设一个 LEADER 角色负责三件事——把任务分解成子任务、按依赖顺序分派、对结果做质量把关与兜底。

代价是 LEADER 会成为瓶颈与单点：它的分解能力决定了整体上限。所以 LEADER 的提示词里必须写清"何时自己直接做、何时才组队"。这一点在实际产品里甚至需要写进用户引导：简单任务（“生成一份课件并入库”）由主智能体一步完成，只有明确要求"组建队伍完成以上任务"时才拉团队。否则每次小任务都走一遍团队协作，延迟和成本都会翻倍。

四、决策三：知识库按角色隔离，不做全局共享池

所有 Agent 共享一个知识库看起来省事，但会带来检索污染：出题 Agent 检索到的是课件排版规范，批改 Agent 检索到的是出题技巧。按角色隔离知识库，让每个角色只看到自己领域的资料，命中率和稳定性都会明显提升。

代价是维护成本转移到了人身上：知识要按角色归位，新增角色要配新的知识集。这是一笔"一次投入、长期受益"的成本，前期容易被忽略。

五、决策四：把能力封装成可挂载的 SKILL

把"生成课件"“判题”"导出报告"这类能力封装成独立 SKILL（指令 + 脚本 + 资源），Agent 按需动态加载，而不是把全部工具塞进系统提示。这样上下文只在使用时占用，能力可以独立版本化，同一个 SKILL 也能被多个角色复用。

代价是多了一层间接：SKILL 的元信息（名称、描述、使用场景）必须写得准确，否则模型认不出该在什么时候调用它；排查问题时也要多查一层——是 Agent 没选对 SKILL，还是 SKILL 自身执行失败。

六、真实存在的代价清单

• 协调开销：角色越多，消息传递、格式对齐、重试的成本越高，端到端延迟往往比单 Agent 更差。
• 调试难度：失败可能是分解错、分派错、执行错、汇总错，需要链路级可观测（每一步的输入输出都要能回放）。
• 评测困难：多 Agent 的输出是概率叠加，同一任务多次运行结果不同，必须用"可验收的交付物 + 检查项"来评测，而不是比对文本相似度。
• 成本：并行意味着同时占用配额，token 消耗会成倍上升。

七、什么时候不该上多 Agent

如果一个任务能在单次调用里用清晰指令完成，且产物体量小、不需要多种专业视角，那么单 Agent 加一个好的工具集就够了。判断标准可以简化成一句：任务是否天然包含"不同专业视角 + 可分离的中间产物"。是，就值得拆；不是，拆了只会增加失败面。

八、小结

多 Agent 的正确姿势不是"让 AI 们开会"，而是把人的组织经验翻译成工程约束：职责边界清晰、调度者明确、上下文隔离、能力可插拔。真正的难点不在模型能力，而在边界划分和可观测性——前者决定系统能不能成，后者决定它坏了你能不能修。