7.5 多 Agent 协作
AutoGen / CrewAI / LangGraph 多 Agent 框架；角色分工模式（debate、group chat、hierarchical）；何时不该用多 Agent
为什么要"多"Agent
单 Agent 已经能用 ReAct + 工具 + 记忆解决很多问题，为什么还要搞多 Agent？几种典型动机：
- 专业化分工：不同 agent 有不同的 system prompt / 工具集 / 模型，各自专精某一环节（PM、架构师、程序员、测试员）
- 辩论式提升：多个 agent 独立给答案，再辩论/投票，能减少幻觉（Du et al., ICML 2024 证明这种"心智社会"方法显著提升事实性）
- 并行加速：可分解的子任务让多个 agent 并行跑
- 责任隔离：把有风险的动作（删文件、花钱）交给专门的审批 agent
- 涌现行为：Park 等人的 Generative Agents（UIST 2023）用 25 个 agent 在沙盒中自主组织了一场"情人节派对"，整个流程完全没有显式编程——这是多 agent 独有的涌现现象
但同时必须清醒地认识到：多 agent 并不是"越多越好"。每多一个 agent，token 成本线性增长，错误概率可能乘性放大。
三大主流框架
AutoGen：以"对话"为核心
Microsoft Research 2023 年推出的 AutoGen 把多 agent 协作抽象为可对话的 agent（Conversable Agent）之间的消息传递。核心概念：
- Conversable Agent：能发送/接收消息的 agent，可配置 LLM、工具、人类输入
- UserProxyAgent：代表人类的 agent，可以执行代码、触发工具
- AssistantAgent：LLM 驱动的 agent
- GroupChat：多 agent 的群聊，由 GroupChatManager 决定谁下一个发言
from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager
planner = AssistantAgent("planner", system_message="你负责拆解任务")
coder = AssistantAgent("coder", system_message="你负责写 Python 代码")
critic = AssistantAgent("critic", system_message="你负责审查代码")
user = UserProxyAgent("user", code_execution_config={"work_dir": "ws"})
groupchat = GroupChat(agents=[user, planner, coder, critic], max_round=10)
manager = GroupChatManager(groupchat=groupchat)
user.initiate_chat(manager, message="写一个爬取 arxiv 摘要的脚本")2026 年 4 月，Microsoft 把 AutoGen 与 Semantic Kernel 统一为 Agent Framework 1.0，从"以对话为中心"转向"基于图的编排"。
CrewAI：以"角色+团队"为核心
João Moura 在 2023 年 11 月发布的 CrewAI 走组织架构路线：Agent 有明确 role / goal / backstory，组织成 Crew，执行 Process。
from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="研究员",
goal="找到最新的 agent 论文",
backstory="你是一位资深 NLP 研究员..."
)
writer = Agent(
role="科技作家",
goal="把研究成果写成通俗易懂的总结",
backstory="..."
)
task1 = Task(description="调研 2024 年 agent 领域 top 5 论文", agent=researcher)
task2 = Task(description="写一篇 800 字的总结", agent=writer)
crew = Crew(agents=[researcher, writer], tasks=[task1, task2], process=Process.sequential)
result = crew.kickoff()CrewAI 特别强调自主的 agent 间任务委托——一个 agent 可以把自己搞不定的事主动交给另一个 agent。
LangGraph：以"图"为核心
LangChain 2024 年推出的 LangGraph 把 agent 工作流建模为有向图：节点是计算步骤（LLM 调用、工具调用、人类介入），边是状态转移，一切都围绕一个可持久化的 State 对象。
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
messages: list
next: str
def researcher_node(state): ...
def writer_node(state): ...
def router(state): return state["next"]
workflow = StateGraph(AgentState)
workflow.add_node("researcher", researcher_node)
workflow.add_node("writer", writer_node)
workflow.add_conditional_edges("researcher", router, {
"writer": "writer", "end": END
})
workflow.set_entry_point("researcher")
app = workflow.compile()LangGraph 的优势：对执行顺序、并行化、错误恢复、状态持久化有显式控制，非常适合生产环境。2025 年 LangChain B 轮融资 1.25 亿美元，部分原因就是 LangGraph 在 Klarna、Replit、LinkedIn 的规模化部署。
其他重要框架
- MetaGPT（Hong et al., ICLR 2024 Oral）：把人类软件公司的 SOPs（标准操作程序） 编码进 agent 工作流（PM → 架构师 → 工程师 → QA），中间产出 PRD、设计文档、代码、测试
- CAMEL（Li et al., NeurIPS 2023）：用角色扮演 prompt 让两个 agent（AI User + AI Assistant）自动协作，开创了多 agent 数据合成范式
- ChatDev（Qian et al., ACL 2024）：用"聊天链"把软件开发原子阶段串起来，用"communicative dehallucination"减少代码错误
角色分工的典型模式
Debate（辩论）
多个 agent 独立给答案，再互相反驳、投票/裁判决出最优。Du 等人（ICML 2024）证明 debate 在数学推理、事实问答上显著优于单 agent CoT，且效果随 agent 数量和辩论轮数单调提升。适用场景：需要事实准确性或多视角的任务。
Group Chat（群聊）
所有 agent 共享消息历史，由 manager（可以是另一个 LLM 也可以是简单规则）决定下一个发言者。AutoGen 的核心范式。适用场景：任务边界不清晰、需要动态分工的场景。
Hierarchical（分层/编排）
一个 orchestrator（协调者）把任务分配给多个 worker，worker 完成后汇报结果。HuggingGPT（Shen et al., NeurIPS 2023）是经典案例——ChatGPT 作为 orchestrator，HuggingFace 上的专家模型作为 worker。适用场景：任务可以清晰拆解、有明确主次关系的场景。
Role-play（角色扮演）
每个 agent 有固定 persona（CEO、程序员、测试员）。MetaGPT、ChatDev 的范式。适用场景：任务流程已被人类实践充分结构化（如软件开发 SOP）。
何时不该用多 Agent
这是本节最重要的部分。LangChain 的 Harrison Chase 在 2024-2025 年反复强调一个趋势：从完全自主的 AutoGPT 式"广泛 agent"，转向垂直、范围狭窄、高度可控的专用 agent。多 agent 系统在以下场景不应使用：
| 不该用多 Agent 的场景 | 为什么 | 替代方案 |
|---|---|---|
| 任务路径可预测 | 多 agent 引入随机性，不如直接写代码 | 纯代码 pipeline |
| 单个强 LLM 已能胜任 | GPT-4 / Claude 3.5 本身已经很强 | 单 agent + 工具 |
| 对延迟敏感 | 每次 agent 通信都多一次 LLM 调用 | 单 agent + 并行工具 |
| 预算紧张 | 多 agent 的 token 成本线性/乘性增长 | 单 agent |
| 没有清晰角色边界 | 角色模糊会导致"agent 扯皮" | 先把流程拆清楚再说 |
| 调试困难不容忍 | 多 agent 轨迹交错，调试是地狱 | 单 agent 或显式 LangGraph |
Anthropic 的经验：2024 年底的一份内部指南建议——先用单 agent 写到不够用再加第二个。绝大多数"看起来像多 agent"的任务，其实是"一个 agent + 一组工具"就能解决。多 agent 的真正价值体现在辩论式提升事实性和涌现式社会行为上，不要为了"架构看起来酷"而堆 agent。
判断一条 checklist：
先问：这件事单 agent 能做完吗？
如果能——别加第二个。
再问：多 agent 的价值来自什么？
是辩论（提升准确率）？是并行（提升速度）？是专业化（不同模型）？是 HIL 审批（安全）？没有清晰答案就不要上。
最后问：调试和可观测性怎么办？
多 agent 的失败往往在 agent 间消息流。提前设计好 trace、log、replay。
本节小结
- AutoGen 以"对话"为核心，CrewAI 以"角色团队"为核心，LangGraph 以"图"为核心
- 四种角色分工模式：Debate、Group Chat、Hierarchical、Role-play——各有适用场景
- τ-bench、AgentBench 等基准告诉我们：多 agent 系统的可靠性仍然是开放问题
- 反直觉的真理：大多数实际任务用单 agent + 一组好工具就够了，不要为"架构 fancy"而堆 agent
- 2024–2026 年的行业趋势：从广泛自主 agent 收敛到垂直、高度可控的 vertical agent