Multi-Agent 系统：让 AI 团队协作

L4-04 单 Agent 已经能干很多事。 但还有问题：

• 任务太复杂——一个 Agent 上下文不够
• 需要不同视角——一个 Agent 容易”路径依赖”
• 不同能力——一个 Agent 全才不如多个专才

Multi-Agent 系统——让多个 Agent 协作 完成任务。 2024-2026 年最火的 LLM 工程方向之一。

几种 Multi-Agent 模式

模式 1：流水线（Pipeline）

Agent A → Agent B → Agent C —— 串行：

"写一份关于电动汽车市场的报告"
   ↓
Researcher Agent: 上网搜集数据 → 整理材料
   ↓
Analyst Agent: 分析趋势 + 关键洞察
   ↓
Writer Agent: 把材料 + 洞察写成报告
   ↓
Editor Agent: 修改润色 + 检查事实
   ↓
最终报告

好处：每个 Agent 专精一件事——质量更高。 坏处：串行——慢。

模式 2：辩论（Debate）

多个 Agent 互相质疑：

任务：评估某个商业决策的好坏

Agent A (支持派): "这个决策好，因为 X, Y, Z"
Agent B (反对派): "不对，A 的 X 论据有问题，因为..."
Agent A: "你说的对，但 Y 仍然成立..."
... 多轮辩论 ...
Agent C (法官): 综合判断

研究证明：辩论让答案质量显著提升—— 模型互相挑错，减少幻觉。

模式 3：团队（Team）

像真实公司——角色分工 + 项目经理协调：

                   ┌─ Project Manager ─┐
                   ↓                    ↓
   Frontend Agent      Backend Agent      DevOps Agent
        ↓                    ↓                    ↓
     代码 A               代码 B              部署脚本
                   合并 + 测试
                       ↓
                   交付结果

好处：可扩展、模拟真实组织。 坏处：协调复杂、状态管理难。

模式 4：群体（Swarm）

OpenAI 2024 提出的 Swarm—— 轻量级 Agent 协作框架：

• Agent 之间可以 handoff（转交任务）
• 每个 Agent 有特定专长
• 无中心协调——分布式决策

# OpenAI Swarm 示例
def transfer_to_billing():
    return billing_agent

def transfer_to_tech_support():
    return tech_support_agent

main_agent = Agent(
    name="Customer Service",
    instructions="Help users. Hand off to billing or tech support as needed.",
    functions=[transfer_to_billing, transfer_to_tech_support],
)

billing_agent = Agent(name="Billing", instructions="Help with billing")
tech_support_agent = Agent(name="Tech Support", instructions="Help with technical issues")

用户问”我账单有问题” → main_agent 自动 transfer 到 billing_agent。

主流框架

AutoGen（Microsoft）

最早大规模 Multi-Agent 框架—— 对话式 + 灵活：

from autogen import AssistantAgent, UserProxyAgent

# 定义不同 Agent
researcher = AssistantAgent(
    name="researcher",
    system_message="You research topics thoroughly.",
)

writer = AssistantAgent(
    name="writer",
    system_message="You write polished content.",
)

user_proxy = UserProxyAgent(
    name="user_proxy",
    human_input_mode="NEVER",  # 不需要人类干预
)

# 让他们协作
user_proxy.initiate_chat(
    researcher,
    message="Research the EV market in 2026."
)

# researcher 完成后 → handoff 给 writer

特色：灵活 + 易用。

CrewAI

更结构化——像真实”团队”：

from crewai import Agent, Task, Crew

researcher = Agent(
    role='Senior Researcher',
    goal='Uncover insights about EV market',
    tools=[web_search_tool],
)

writer = Agent(
    role='Tech Writer',
    goal='Write engaging articles',
    tools=[],
)

task1 = Task(
    description='Research the latest EV market trends.',
    agent=researcher,
)

task2 = Task(
    description='Write a 1000-word article based on research.',
    agent=writer,
)

crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
result = crew.kickoff()

特色：角色清晰、易于扩展。

LangGraph

基于 LangChain—— 用”图”建模 Agent 流程：

from langgraph.graph import StateGraph

workflow = StateGraph(MyState)
workflow.add_node("research", research_node)
workflow.add_node("write", write_node)
workflow.add_node("edit", edit_node)

workflow.add_edge("research", "write")
workflow.add_edge("write", "edit")

graph = workflow.compile()
result = graph.invoke(initial_state)

特色：复杂状态机、可视化。

MetaGPT

“AI 软件公司” ——

• CEO / CTO / PM / 工程师 等角色
• 完整软件开发流程
• 一句话生成完整 app

不太适合生产，但研究 + demo 价值大。

工程挑战

Multi-Agent 系统在生产中问题极多：

问题 1：成本爆炸

每个 Agent 调用 LLM—— 10 个 Agent ≠ 10× 成本—— 更可能是 30-100× 成本（互相通信、状态传递）。

应对：

• 限制总 token / 步数
• 用小模型做 secondary Agent
• 缓存共享状态

问题 2：错误累积

Agent A 错 5% → Agent B 错 5% → Agent C 错 5% → 总错误率 ~ 15%（独立）或更糟（相关错误）。

应对：

• 每步加 validation
• 关键 Agent 用强模型
• 设置 escape hatch（让用户介入）

问题 3：协调难

谁该做什么？什么时候停止？ 最常见的失败：

• 死循环（A 问 B, B 问 A）
• 任务 stuck（没人接锅）
• “互相 PUA”（互相否定，没结论）

应对：

• 明确角色 + 边界
• Time-out 机制
• 中央”项目经理” Agent

问题 4：上下文管理

10 个 Agent 共享状态—— 上下文几十万 token 普通——

• 显存压力
• 推理慢
• 注意力涣散

应对：

• 阶段性总结
• 关键事实存向量库
• 不同 Agent 看不同子集

问题 5：调试难

单 Agent 失败容易看出—— 多 Agent 失败极难定位：

• 哪个 Agent 错了？
• 错在第几步？
• 是 prompt 问题还是 LLM 问题？

应对：

• 完整日志（每个 Agent 每步）
• 可视化工具（LangSmith / Phoenix）
• 单元测试每个 Agent

一个真实案例

某团队做”AI 软件工程师”产品—— 3 代演化：

v1：单 Agent

一个 LLM 收到任务、生成代码、跑测试、修改。

问题：

• 复杂任务（>500 行代码）经常崩
• 不会规划
• 不会自我检查

v2：Pipeline

Architect → Coder → Tester → Reviewer

改进：

• 100% 项目成功率上升 60% → 85%
• 但每个任务成本 5×
• 运行时间 3×

v3：自适应 Multi-Agent

简单任务：直接单 Agent 中等任务：Pipeline 复杂任务：完整团队 + 监督 Agent

最终：成本仅 2×，成功率 90%+。

关键洞察：Multi-Agent 不是”越多越好”—— 根据任务复杂度自适应选择。

一些前沿

Agent-to-Agent 协议

各家 Agent 框架互不相通：

• AutoGen 的 Agent
• CrewAI 的 Agent
• LangGraph 的 Agent
• …都不能直接互通

类似早期”互联网”前的 LAN 时代—— 协议标准化是 Agent 时代下一个关键。

MCP（L4-07）解决了”Agent ↔ Tool”—— 还需要 “Agent ↔ Agent” 协议。

Multi-Agent RL

让 Agent 通过强化学习互相提升：

• 一个 Agent 出题
• 一个 Agent 解题
• 互相反馈 → 都变强

类似 AlphaGo 的”self-play”—— 应用到 LLM Agent 上。

Hierarchical Agent

层级 Agent：

• 高层 Agent 规划
• 中层 Agent 协调
• 底层 Agent 执行

模拟人类组织结构。

经济学：Agent 市场

未来——

• 各种 Agent 在”市场”上提供服务
• 用户的”个人 Agent” 雇佣其它 Agent 做事
• 价格由能力 + 信誉决定

听起来科幻——但早期产品（如 a16z 的 Agent 创业公司） 已经在试。

实战建议

起步

不要一上来就 Multi-Agent：

1. 先做单 Agent
2. 不行 → Pipeline
3. 仍不行 → 真正 Multi-Agent

Multi-Agent 复杂度是单 Agent 的 5-10×。

选框架

场景	推荐
简单顺序流程	AutoGen / Swarm
复杂状态机	LangGraph
角色明确分工	CrewAI
自定义协议	自己写

别忘了

• 监控 每个 Agent 的成本和延迟
• 设置上限（防止失控）
• 日志 每一步
• 测试 边界场景

下一篇推荐：L4-11 MCP 工具开发 或 L4-12 LLM 成本优化。