单智能体与多智能体

先说结论

单智能体是一个核心 Agent 统一负责规划、工具调用和结果整合；多智能体则把任务拆给多个角色化 Agent，通过 supervisor、handoff 或 group chat 完成协作。

为什么我会单独记这一篇

随着任务变复杂，一个 Agent 往往会遇到：

1. 上下文过载。
2. 角色混杂，既要规划又要执行又要评审。
3. 工具和权限边界不清。

多智能体的目标，是把复杂任务拆成更清晰的角色和责任边界；但它的代价是更高的协调复杂度。

核心机制

单智能体常见范式

• ReAct
• Plan-and-Execute
• Tool-augmented reasoning

多智能体常见协作模式

• Supervisor：总控 Agent 分发任务，子 Agent 执行。
• Handoff：当前 Agent 把控制权交给下一个专家 Agent。
• Group chat：多个 Agent 在共享会话里协商。
• Map-reduce：并行解决子问题后再汇总。

关键对比

设计时真正要权衡什么

• 简单性 vs 专家分工：任务不复杂时，单智能体往往更优。
• 统一上下文 vs 分治协作：统一更简单，分治更可扩展。
• 单一权限域 vs 多角色分权：后者更安全，但编排更复杂。

容易踩的坑

• 任务规模不大却硬上多智能体，复杂度高于收益。
• 子 Agent 权限重叠，角色区分只停留在 prompt 名字上。
• 多 Agent 共享过多上下文，导致互相污染。
• handoff 协议不清楚，导致状态丢失。
• group chat 讨论很多，但没有明确终止条件和最终签发者。

工程落地时我会怎么做

• 默认从单智能体开始，只有在明显需要专家分工、并行执行或差异化权限时再升多智能体。
• 多智能体一定要定义清楚：谁路由、谁能调哪些工具、谁负责最终结果、什么条件终止。
• 更推荐 supervisor 或 handoff，不建议直接把无约束 group chat 上线。
• 共享状态要结构化，不能只靠自然语言转述。
• 对每个 Agent 建立清晰权限边界和 token 预算。

如果要对外讲，可以怎么概括

“单智能体和多智能体不是谁更高级，而是谁更匹配任务。大多数任务单智能体就够了，因为它更简单、更便宜、更好调。只有当任务天然存在专家分工、可并行子任务或者权限差异时，多智能体才真正有收益。否则很容易出现‘大家都在说，没人真正做事’。”

最后记几条

1. 默认先从单智能体开始。
2. 多智能体的收益来自角色边界和并行能力。
3. 多智能体的代价是协调和可观测性复杂度。
4. supervisor 与 handoff 往往比开放 group chat 更实用。
5. 多智能体一定要有结构化共享状态。

参考资料

• LangChain multi-agent
• LangGraph multi-agent
• AutoGen docs
• AutoGen AgentChat
• AutoGen Teams
• CrewAI docs
• CrewAI Crews
• CrewAI Flows

延伸阅读

• 大模型总索引