Skip to main content

Multi-Agent：多智能体协作

Multi-Agent 系统由多个分工协作的 Agent 共同完成任务，通过拆分任务与隔离上下文解决单 Agent 系统难以处理的复杂问题。

为什么需要 Multi-Agent？​

单 Agent 的局限​

单 Agent = 一个人干所有事

问题：
- 注意力分散，什么都会一点但都不精
- 上下文太长，容易混淆和遗忘
- 不同任务需要不同的 prompt 和工具
- 一个环节出错容易影响全局

Multi-Agent 的优势​

多 Agent = 一个团队协作

优势：
- 角色分工，每个 Agent 在自己领域更专业
- 上下文隔离，避免信息相互干扰
- 可以并行处理，提升效率
- 某 Agent 出错，其他可以纠正

典型协作模式​

模式 1：层级式（Hierarchical）​

         🎯 协调者（Coordinator）
        /       |        \
   👨‍💻 开发    🧪 测试    📝 文档
     Agent    Agent    Agent

特点：

  • 有明确的上下级关系
  • 协调者分配任务，汇总结果
  • 执行 Agent 专注各自任务

适用场景：有明确流程的复杂任务，如软件开发项目。

模式 2：轮值式（Round-Robin）​

产品 Agent → 设计 Agent → 开发 Agent → 测试 Agent
     ↓                                      ↑
     └──────────────────────────────────────┘

特点：

  • 按固定顺序轮流工作
  • 每个 Agent 完成自己那部分后交给下一个
  • 清晰的工作流

适用场景：流水线式的任务，如内容生产流程。

模式 3：自由讨论式（Debate）​

    观点 A Agent   ←→   观点 B Agent
          \               /
           \             /
            主持人 Agent

特点：

  • 多个 Agent 持不同观点辩论
  • 从多个角度分析问题
  • 最后综合得出结论

适用场景：需要批判性思维的任务，如方案评审、风险评估。

模式 4：自治团队（Autonomous Team）​

产品   设计   开发   测试
  ↕     ↕      ↕     ↕
大家自行协作，没人发号施令

特点：

  • Agent 之间平等协作
  • 自主决定做什么、跟谁协作
  • 最灵活也最难实现

适用场景：探索性强、没有固定流程的任务。

经典 Multi-Agent 架构​

AutoGPT 式：单一 Agent + 工具​

虽然是单 Agent，但可以看作是"自我协作"：
- 规划者角色
- 执行者角色
- 批判者角色
都在同一个 Agent 的不同阶段体现。

CrewAI：角色 + 任务 + 流程​

from crewai import Agent, Task, Crew

# 定义角色
researcher = Agent(
    role='研究员',
    goal='收集和分析信息',
    backstory='你是一位资深市场研究员...'
)

writer = Agent(
    role='作家',
    goal='撰写高质量报告',
    backstory='你是一位专业技术作家...'
)

# 定义任务
research_task = Task(
    description='调研 AI Agent 最新发展',
    agent=researcher
)

write_task = Task(
    description='根据调研结果写报告',
    agent=writer
)

# 组建团队执行
crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task])
crew.kickoff()

Devin 式：软件工程 Agent 团队​

产品经理 Agent → 理解需求，写 PRD
  ↓
架构师 Agent → 设计系统架构
  ↓
程序员 Agent → 写代码
  ↓
测试 Agent → 测代码
  ↓
运维 Agent → 部署上线

角色设计的艺术​

好的角色定义要素​

agent_definition = {
    # 1. 明确的角色定位
    "role": "资深后端工程师",
    
    # 2. 清晰的目标
    "goal": "编写高质量、可维护的 Python 代码",
    
    # 3. 背景故事（建立人设）
    "backstory": """
        你有 10 年 Python 开发经验，是 PEP 8 的坚定拥护者。
        你注重代码质量，写的代码自带文档和测试。
        你讨厌重复造轮子，优先使用成熟的开源库。
    """,
    
    # 4. 专属的工具集
    "tools": [read_file, write_file, run_tests],
    
    # 5. 工作方式约束
    "rules": [
        "写代码前先想清楚设计",
        "每个函数都要有文档字符串",
        "修改代码后必须跑测试"
    ]
}

常见的反模式​

❌ 角色定义太模糊：

"role": "助手",
"goal": "帮助用户"
→ 什么都能做，但什么都做不好

❌ 角色重叠太严重：

Agent A：写代码 + 测代码
Agent B：测代码 + 写文档
→ 分工不清晰，协作效率低

❌ 角色太多太细：

10 人的团队做一个简单任务
→ 沟通成本 > 分工带来的收益

Multi-Agent 的通信机制​

消息总线模式​

所有 Agent 连接到同一个消息总线：

Agent A 发布消息 → 总线 → 关心这个消息的 Agent 接收

优点：解耦，灵活扩展 缺点：消息太多容易混乱

点对点直接通信​

Agent A 直接发消息给 Agent B：

优点：高效，可控 缺点：耦合度高

共享工作区​

所有 Agent 读写同一个共享状态：

📁 共享工作区
  ├─ 📄 任务说明.md
  ├─ 📄 设计文档.md  
  ├─ 📁 代码/
  └─ 📄 测试结果.md

优点：简单直观，容易调试 缺点：需要解决并发写入问题

成本与收益的权衡​

Multi-Agent 的成本​

💸 Token 消耗：单 Agent 的 N 倍
⏱️ 时间成本：通信和协调的开销
🧠 复杂度：状态管理和调试困难

什么时候值得用 Multi-Agent？​

✅ 推荐使用：

  • 任务可以清晰拆分为多个独立子任务
  • 不同子任务需要完全不同的专业能力
  • 任务足够复杂，单 Agent 上下文装不下
  • 需要不同 Agent 相互验证和纠错

❌ 不推荐使用：

  • 简单任务，单 Agent 就能搞定
  • 任务之间高度依赖，难以拆分
  • 对成本和速度敏感的场景

渐进式升级路径​

Step 1: 单 Agent + 好的 prompt
  ↓ 不够用
Step 2: 单 Agent + 反思循环
  ↓ 不够用
Step 3: 简单双 Agent（编码者+评审者）
  ↓ 不够用
Step 4: Multi-Agent 系统

Anthropic 的多 Agent 实践教训​

在 Multi-Agent 这个问题上，Anthropic 是最有发言权的——他们既深度使用多 Agent，也踩过最大的坑。引用的 Anthropic 关键文章（Building effective agents）分享了三个反直觉的洞察。

血泪教训：数月投入退回单 Agent​

Anthropic 明确承认：

"我们曾投入数月时间去构建复杂的多 Agent 架构，但最终却发现退回单 Agent 架构 + 进一步优化提示词 + 优化工具描述，反而会达到更好的效果。"

这个反直觉的结论背后，是开发者们最容易犯的一个反模式——见下文。

反模式：按"职能"拆 Agent​

开发者们最常犯的错，就是按工作职能来拆分子 Agent：

❌ 反模式：
  Agent 1：写代码
  Agent 2：测代码
  Agent 3：review 代码

这种拆分的问题是什么？Anthropic 给出了非常具体的回答：

"Agent 之间大量的 tokens 都消耗在了解释上下文、解释彼此的工作上面。"

也就是说，子 Agent 之间的"沟通成本"远大于"分工收益"——一个 Agent 写完代码，要花大量 token 向 review Agent 解释"我为什么这么写、上下文是什么"；review Agent 看完又要花 token 回去解释"哪里有问题、为什么是问题"……

正确原则：按"信息域"拆​

Anthropic 提出的正确原则是：

"谁掌握信息，谁就把这一块负责到底。"

不是按"做什么工作"拆，而是按"掌握什么信息"拆。当一个 Agent 拥有完整的背景信息时，它能独立完成整个任务、效率最高；只有当任务的背景信息 / 上下文知识完全不同时，才考虑拆成不同的子 Agent。

拆法例子评价
❌ 按职能拆写代码 Agent ↔ 测代码 Agent 协作一次改动沟通成本 > 分工收益
✅ 按信息域拆让"读过整个项目代码的 Agent"独立完成改动上下文完整，效率最高

说白了就是团队合作，有的时候拉通对齐花的精力远比实际干活要更费劲。

真正适合多 Agent 的 3 个场景​

Anthropic 明确给出了多 Agent 真正优于单 Agent 的 3 个场景。这 3 个之外，应优先考虑优化单 Agent + prompt + 工具描述：

  1. 上下文爆炸 / 污染 — 任务天然产生超长上下文，多 Agent 隔离可避免单 Agent 注意力被稀释
  2. 任务天然可并行 — 多 Agent 并行推进可显著提速
  3. 拆分子 Agent 能改善工具决策 — 每个子 Agent 任务更聚焦、工具调用更准（典型场景：单 Agent 注册 50-100 个工具就调不准了，拆成几个子 Agent 分别管各自领域的工具）

一个实用的判断标准：如果你说不出属于这 3 种情况的哪一种，就先用单 Agent + 优化 prompt + 优化工具描述——Anthropic 用数月时间证明了这条路往往更优。

Multi-Agent 的未来​

从"工具"到"团队"​

现在的 Agent：你告诉它做什么，它帮你做
未来的 Agent 团队：你说"我想要 X"，团队自己：
  - 拆解任务
  - 分配工作
  - 协调进度
  - 解决问题
  - 交付成果

Agent 市场​

未来可能出现 Agent "人才市场"：
- 搜索和雇佣擅长特定任务的 Agent
- 按能力和表现评分
- 组建你的专属 AI 团队

Multi-Agent 不是简单的"更多 Agent"，而是"更好的分工"。就像人类团队一样，1+1 可能大于 2，也可能小于 1。

Last updated on by Kimi Gao