返回实战列表
进阶 26 分钟阅读

多智能体协作实战

学习如何在复杂任务里划分角色、组织交付边界，并让多个 Agent 的协作真正带来收益而不是额外混乱。

C
ClawList Team
· 发布于 2025-03-08 · 更新于 2026-03-24

为什么你不应该太早上多智能体？

“多智能体”听起来很强，但它不是默认更优的方案。很多团队的问题并不是缺少第二个 Agent，而是：

  • 单 Agent 的职责都还没定义清楚
  • 输入输出格式不稳定
  • skills 边界模糊
  • 缺少任务追踪与失败处理

如果这些问题还在，多智能体往往只会把混乱扩散到更多角色。

什么时候多智能体才值得？

以下几类任务更适合考虑多智能体：

  • 明显存在角色分工，如研究、起草、审核
  • 子任务可以并行
  • 每个角色需要不同的上下文与行为约束
  • 结果需要交叉检查，而不是一次生成就结束

如果任务本质上只是“一个人顺着做完就好”，那你很可能还不需要团队结构。

前置准备

在进入多智能体前，建议你已经具备：

  • 一个稳定的单 Agent 任务闭环
  • 至少一组明确的 tools / skills
  • 可观察的任务状态（日志、步骤、失败原因）
  • 基本的输入输出格式约定

如果这些前置条件都没有，多智能体会很难调试。

一个实用的最小团队结构

大多数内容型或工程型任务，先从 3 个角色起步就够了：

┌─────────────────────────────────────┐
│           Orchestrator              │
│           任务协调与验收             │
└──────────────┬──────────────────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
    ▼          ▼          ▼
┌─────────┐ ┌─────────┐ ┌──────────┐
│Research │ │Writer   │ │Reviewer  │
│收集信息 │ │生产草稿 │ │发现问题  │
└─────────┘ └─────────┘ └──────────┘

这个结构之所以常见，是因为它很好地映射了真实工作流：

  • 协调者负责任务拆解和验收
  • 执行者负责产出
  • 审核者负责发现问题和回退

角色边界怎么定义才不会打架？

角色定义最怕“都能做一点”。

更好的做法是明确三件事：

1. 每个角色负责什么结果

2. 每个角色不能做什么

3. 交接物必须长什么样

例如：

| 角色 | 应负责 | 不应负责 | 交付物 | |------|--------|----------|--------| | Orchestrator | 拆任务、排顺序、验收 | 亲自完成全部细节 | 任务计划、合并结论 | | Researcher | 收集事实、整理输入 | 直接定稿 | 结构化调研结果 | | Writer | 生成草稿或代码 | 自己宣布“已经没问题” | 初稿 | | Reviewer | 发现问题、提出修正意见 | 取代 writer 完成全部重写 | 审核反馈 |

一个更可信的实现方式

下面的代码是架构示意，用来说明多智能体系统应该如何组织角色和工作流，并不表示你的运行时一定存在完全一致的 AgentTeam 或 OrchestratorAgent 类。

const team = {
  orchestrator: 'content-team-lead',
  agents: ['researcher', 'writer', 'reviewer'],
  workflow: [
    'research -> structured findings',
    'write -> draft output',
    'review -> feedback',
    'revise if needed',
  ],
};

真正落地时，你至少要明确：

  • 任务由谁启动
  • 中间产物存在哪里
  • 谁决定继续下一步
  • 谁负责失败重试

任务交接如何设计？

很多多智能体系统失败，不是因为角色设错，而是因为交接物太模糊。

建议每一步都输出结构化结果，例如：

  • 研究阶段输出：结论、证据、风险、待确认项
  • 写作阶段输出：正文草稿、假设、引用来源
  • 审核阶段输出：问题清单、严重程度、修复建议

交接物越稳定，团队越容易扩展。

两种常见通信模式

1. 消息传递

适合严格顺序流程：

  • 上一步完成
  • 发送结果给下一角色
  • 下一角色继续处理

优点是清晰，缺点是上下文共享能力弱。

2. 共享状态 / 共享记忆

适合多个 Agent 需要共同访问任务状态的场景。

你可以把共享层理解为：

  • 任务板
  • 结构化缓存
  • 文档仓库
  • 状态数据库

但请注意：共享得越多，冲突与污染也越容易出现。

多智能体里最常见的 5 个坑

1. 角色分工只是名字不同，实际能力没区别

如果 researcher、writer、reviewer 看到的是同一上下文、用的是同一规则、输出也没区别，那你只是在复制同一个 Agent。

2. orchestrator 过度中心化

如果协调者要亲自处理每个细节，那它就不再是协调者，而成了单点瓶颈。

3. reviewer 只能说“不错”，不能指出可执行修改

审核角色的价值不在礼貌评价，而在明确指出：

  • 哪错了
  • 为什么错
  • 应该怎么改

4. 缺少失败回退路径

当 research 结果为空、writer 草稿质量太差、review 发现严重问题时，系统要不要回退？回退给谁？最多几次？这些都要提前定义。

5. 任务成本失控

每多一个角色，就多一轮调用、多一轮上下文传递、多一轮失败面。多智能体提升质量的同时，也会提升成本。

一个落地时可用的检查清单

在你决定把单 Agent 升级成多 Agent 前，先确认：

  • [ ] 单 Agent 版本已经稳定可跑
  • [ ] 每个角色都有明确职责与禁止事项
  • [ ] 每一步都有结构化交付物
  • [ ] 存在失败回退与重试策略
  • [ ] 团队带来的收益大于额外成本

下一步读什么？