多 Agent 系统实战：从单体到协作的架构演进

上周在调试一个内容生成系统时遇到个问题：让一个 Agent 同时负责市场调研、内容创作、多平台发布，结果它经常在执行到第三步时"失忆"，把前面分析的数据全忘了。上下文窗口撑爆了，工具调用也开始出现幻觉。

这不是模型能力的问题，而是架构设计的问题。单体 Agent 处理长链路任务，就像让一个人同时当产品经理、开发、测试和运维，最后只会把自己搞崩溃。

后来我把这个系统拆成了 5 个独立的 Agent，每个专注一件事，通过异步消息协作。整个流程的稳定性提升了一个量级，成本还降了 60%。

今天就把这套多 Agent 架构的设计逻辑、通信机制和配置细节全部拆开讲清楚。

单体 Agent 的三个致命问题

在讨论多 Agent 之前，先看看单体架构到底卡在哪。

问题一：上下文爆炸

一个 Agent 要处理完整业务流程，需要在上下文里塞入：

  • 业务背景和需求描述
  • 中间步骤的数据（调研结果、分析报告）
  • 各个平台的发布规则
  • 历史对话记录

Claude 3.5 的 200K 上下文看起来很大，但实际跑长链路任务时，到第 5-6 轮对话就开始丢信息了。模型会"选择性遗忘"前面的关键数据，导致后续决策出错。

问题二：工具幻觉

给单个 Agent 配 20+ 个工具，它会开始"创造性发挥"：

  • 调用不存在的工具参数
  • 混淆功能相似的工具
  • 在不该用工具的时候强行调用

这不是模型的 bug，而是认知负载过高的必然结果。人类工程师也做不到同时精通 20 个 API 而不出错。

问题三：任务串行执行

单体 Agent 只能一件事一件事做。即使有些任务完全独立（比如同时生成小红书文案和 TikTok 脚本），也得排队等待。整个流程的耗时是所有子任务的总和。

这三个问题的本质是：我们把复杂系统的复杂度全部压在了一个执行单元上。

多 Agent 架构的核心优势

拆分成多个 Agent 后，每个问题都有了对应的解法。

职责隔离 = 上下文瘦身

每个 Agent 只需要关心自己职责范围内的信息：

  • 市场分析 Agent 只需要竞品数据和分析框架
  • 内容创作 Agent 只需要分析结论和写作规范
  • 发布 Agent 只需要内容和平台 API

单个 Agent 的上下文从 50K 降到 5K，模型的"记忆力"和决策质量都会显著提升。

工具分组 = 消除幻觉

每个 Agent 只配 3-5 个工具，功能边界清晰：

  • 分析 Agent：网页抓取、数据提取、报告生成
  • 创作 Agent：模板渲染、内容优化、格式转换
  • 发布 Agent：平台 API、状态检查、错误重试

工具数量少了，模型就不会"选择困难"，调用准确率能从 70% 提升到 95%+。

并行执行 = 时间压缩

多个 Agent 可以同时工作。一个协调者 Agent 接到任务后，可以并发调用：

  • 让 Agent A 去抓取竞品数据
  • 让 Agent B 去分析用户评论
  • 让 Agent C 去查历史爆款案例

三个任务同时跑，总耗时取决于最慢的那个，而不是三者之和。

设计原则：按职能拆分，不是按平台

这是多 Agent 设计最容易踩的坑：按业务平台划分 Agent。

很多人的第一反应是：

  • 小红书 Agent
  • TikTok Agent
  • 知乎 Agent
  • 公众号 Agent

看起来很直观，但实际跑起来会发现：

  • 每个 Agent 都要重复实现"内容策略"逻辑
  • 品牌调性在不同平台不一致
  • 修改一个策略要改 4 份代码

更好的设计是按职能（Role）拆分：

协调者 (Coordinator)
  ├─ 策略规划 Agent：负责选题、定位、核心观点
  ├─ 内容创作 Agent：负责文案生成和优化
  └─ 平台适配 Agent：负责格式转换和发布

策略规划 Agent 输出的是"这篇内容要讲什么、给谁看、核心卖点是什么"，这些信息对所有平台都通用。

平台适配 Agent 只负责把通用内容转成各平台的格式：

  • 小红书：加 Emoji、拆段落、配图
  • TikTok：生成脚本、分镜、字幕
  • 知乎：长文格式、添加引用、优化排版

这样的设计有两个好处：

  1. 品牌调性统一，所有平台的内容都基于同一个策略
  2. 新增平台只需要加一个适配器，不用重新训练整套逻辑

判断标准：如果两个 Agent 需要共享超过 50% 的上下文信息，它们应该合并。

Agent 间通信：中心化调度 vs 点对点协作

多 Agent 系统的核心是通信机制。主流有两种模式：

模式一：中心化调度（推荐用于业务流程）

有一个 Coordinator Agent 负责任务分发和结果汇总：

用户 → Coordinator
         ├─ 调用 Agent A（传入任务 + 上下文）
         ├─ 调用 Agent B（传入任务 + 上下文）
         └─ 汇总结果 → 返回用户

优点：

  • 流程清晰，易于调试
  • Coordinator 可以做全局优化（比如根据负载动态分配任务）
  • 单点故障容易定位

缺点：

  • Coordinator 本身可能成为瓶颈
  • 增加了一层通信开销

模式二：点对点协作（适合探索性任务）

Agent 之间直接通信，没有中心节点：

Agent A → Agent B → Agent C
    ↓         ↓
Agent D ← Agent E

优点：

  • 灵活性高，Agent 可以动态决定下一步找谁
  • 没有单点瓶颈

缺点：

  • 容易形成循环调用
  • 调试困难，不知道任务卡在哪个环节
  • 需要复杂的状态管理机制

我的建议：业务系统用中心化，研究项目用点对点。

对于有明确流程的任务（内容生产、数据分析、自动化运营），中心化调度的可控性更重要。

对于开放式探索任务（科研、创意生成），点对点协作的灵活性更有价值。

OpenClaw 配置实战

下面用 OpenClaw 框架演示如何搭建一个多 Agent 系统。这套配置可以直接用于内容营销、电商运营等场景。

系统架构

我们设计 4 个 Agent：

  1. Coordinator（协调者）：唯一与用户交互的接口，负责任务拆解和结果汇总
  2. Analyst（分析师）：负责市场调研、竞品分析、用户洞察
  3. Creator（创作者）：负责内容生成和优化
  4. Publisher（发布者）：负责多平台适配和发布

目录结构

~/.openclaw/
├── openclaw.json           # 全局配置
├── skills/                 # 共享技能库
├── workspace-coordinator/  # 协调者工作区
├── workspace-analyst/      # 分析师工作区
├── workspace-creator/      # 创作者工作区
└── workspace-publisher/    # 发布者工作区

每个 Agent 有独立的工作区，避免状态污染。

核心配置文件

openclaw.json 负责三件事：通道配置、路由绑定、工具权限。

{
  "channels": {
    "feishu": {
      "enabled": true,
      "connectionMode": "websocket",
      "accounts": {
        "coordinator": { 
          "appId": "cli_xxx1", 
          "appSecret": "secret1" 
        },
        "analyst": { 
          "appId": "cli_xxx2", 
          "appSecret": "secret2" 
        },
        "creator": { 
          "appId": "cli_xxx3", 
          "appSecret": "secret3" 
        },
        "publisher": { 
          "appId": "cli_xxx4", 
          "appSecret": "secret4" 
        }
      }
    }
  },
  "bindings": [
    { 
      "agentId": "coordinator", 
      "match": { 
        "channel": "feishu", 
        "accountId": "coordinator" 
      } 
    },
    { 
      "agentId": "analyst", 
      "match": { 
        "channel": "feishu", 
        "accountId": "analyst" 
      } 
    },
    { 
      "agentId": "creator", 
      "match": { 
        "channel": "feishu", 
        "accountId": "creator" 
      } 
    },
    { 
      "agentId": "publisher", 
      "match": { 
        "channel": "feishu", 
        "accountId": "publisher" 
      } 
    }
  ],
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": [
        "coordinator", 
        "analyst", 
        "creator", 
        "publisher"
      ]
    }
  }
}

关键点解析：

  1. accounts 配置：每个 Agent 对应一个飞书应用，需要在飞书开放平台创建
  2. bindings 数组：将飞书账号路由到本地 Agent，实现消息精准投递
  3. agentToAgent 白名单：只有在白名单里的 Agent 才能互相调用，防止权限泄露

Agent 人设文件

每个 Agent 需要两个文件：SOUL.md（职责定义）和 AGENTS.md（通讯录）。

Coordinator 的 AGENTS.md：

# 团队通讯录

你是协调者，负责接收用户需求并分发任务。

## 团队成员

- **analyst**：市场分析专家，负责竞品调研和用户洞察
- **creator**：内容创作专家，负责文案生成和优化  
- **publisher**：发布专家，负责多平台适配和发布

## 工作流程

1. 接收用户需求，拆解成子任务
2. 使用 `sessions_send` 调用对应的 Agent
3. 汇总结果，返回给用户

## 纪律

- 禁止自己执行底层任务，必须委派
- 多个任务可以并发调用 `sessions_send`
- 必须等待所有子任务完成后再返回结果

Analyst 的 SOUL.md：

# 市场分析专家

## 核心职责

你负责市场调研和竞品分析，为内容创作提供数据支撑。

## 工作标准

- 必须提供具体数据，不要定性描述
- 引用来源必须可验证
- 分析结论要有明确的逻辑链条

## 工具清单

- web_search：搜索竞品信息
- web_fetch：抓取页面内容
- data_extract：提取结构化数据

## 输出格式

分析报告必须包含：
1. 核心发现（3-5 条）
2. 数据支撑（具体数字 + 来源）
3. 可操作建议

Creator 的 SOUL.md：

# 内容创作专家

## 核心职责

基于分析报告生成高质量内容，符合 SEO 和 GEO 标准。

## 创作原则

- 开头用具体场景切入，不用"随着 XX"
- 每段 3-5 句话，节奏要快
- 技术观点要有立场，不要模棱两可
- 自然融入关键词，密度控制在 1-2%

## 禁止表达

- "强大的"、"优雅的"、"无缝的"
- "首先...其次...最后..."
- "总而言之"、"综上所述"

## 输出要求

- 标题控制在 30 字以内
- Meta Description 控制在 78 字以内
- 正文 2000-3000 字
- 代码示例必须可运行

启动系统

# 重启 OpenClaw 网关
openclaw gateway restart

# 在飞书创建群聊，拉入 4 个机器人
# @coordinator 发送任务

示例对话：

用户：@coordinator 分析一下 Rust 异步编程的市场需求，写一篇技术博客

Coordinator：
  → 调用 analyst：分析 Rust 异步编程的搜索趋势和竞品内容
  → 等待 analyst 返回报告
  → 调用 creator：基于报告生成博客文章
  → 返回最终内容给用户

整个流程在后台异步执行，用户只需要等待最终结果。

成本优化：分级模型策略

多 Agent 系统的成本主要来自模型调用。一个常见误区是：所有 Agent 都用最贵的模型。

实际上，不同 Agent 对模型能力的要求差异很大。

决策层 Agent（Coordinator）：必须用顶级模型

  • 需要理解复杂需求
  • 需要做全局规划和任务拆解
  • 需要处理异常情况

推荐：Claude 3.5 Sonnet、GPT-4、Gemini 1.5 Pro

执行层 Agent（Analyst、Publisher）：用性价比模型

  • 任务明确，输入输出格式固定
  • 主要是工具调用和数据处理
  • 对创造性要求不高

推荐：Claude 3.5 Haiku、GPT-4o mini、Gemini 2.0 Flash

实测数据（处理 100 个内容生成任务）：

配置方案总成本平均耗时成功率
全部用 Claude 3.5 Sonnet$453.2 分钟94%
分级策略$183.5 分钟93%
全部用 Haiku$84.1 分钟78%

分级策略的成本是顶配的 40%，性能只下降了 10%，成功率几乎没有影响。

配置方法：

在每个 Agent 的工作区配置文件中指定模型：

{
  "agentId": "coordinator",
  "model": {
    "provider": "anthropic",
    "name": "claude-3-5-sonnet-20241022"
  }
}

{
  "agentId": "analyst",
  "model": {
    "provider": "anthropic",
    "name": "claude-3-5-haiku-20241022"
  }
}

生产环境的三个坑

把多 Agent 系统跑起来容易，跑稳难。这里是我踩过的坑。

坑一：飞书 Bot-to-Bot 限制

飞书有个反循环机制：机器人 A 在群里 @机器人 B，B 的后台收不到推送。

这是为了防止两个机器人互相 @ 导致死循环，但对多 Agent 系统来说是个麻烦。

解决方案：明暗双轨

  • 暗线：用 sessions_send 走底层通信，Agent 之间直接传数据
  • 明线：在群里发文本消息，让用户看到进度
Coordinator 在群里发：
"正在调用分析师进行市场调研..."

同时在后台调用：
sessions_send(agent="analyst", task="...")

用户能看到进度，Agent 之间的数据传输不受影响。

坑二：Skill 加载优先级混乱

OpenClaw 的 Skill 有两个位置：

  • 全局：~/.openclaw/skills/
  • 本地：workspace-xxx/skills/

加载优先级是：本地 > 全局。

如果你在 Coordinator 的本地 skills 里放了一个图片生成工具，然后让 Creator 调用，Creator 会报错"找不到工具"。

正确做法：

  • 公共工具（图片生成、网页抓取）：放全局 skills
  • 私有工具（特定账号的 API）：放本地 skills

这样既能共享通用能力，又能防止 Agent 误用别人的凭证。

坑三：飞书权限的延迟生效

在飞书开放平台修改了应用权限（比如加了"获取群消息"权限），不会立即生效。

必须：

  1. 创建新版本
  2. 提交审核
  3. 发布上线

整个流程可能需要几分钟到几小时。如果你改完配置立刻测试，会发现"怎么还是不行"。

建议：

  • 初次配置时，把所有可能用到的权限都勾上
  • 测试前等待 5 分钟，确保权限生效
  • 用飞书的"版本管理"页面确认当前生效的版本

最小可行配置清单

如果你想快速搭建一个多 Agent 系统，这是最小化的步骤：

  1. 确定 3 个 Agent：1 个协调者 + 2 个执行者
  2. 在飞书开放平台创建 3 个应用，获取 appId 和 appSecret
  3. 创建 3 个独立的工作区目录
  4. 写 openclaw.json 配置路由和权限
  5. 给每个 Agent 写 SOUL.md 定义职责
  6. 给协调者写 AGENTS.md 列出团队成员
  7. 重启网关，拉机器人进群，发第一条测试消息

整个过程 1-2 小时能跑通。跑通之后再逐步优化：加更多 Agent、调整模型配置、补充 Skill。

多 Agent 系统的核心不是技术复杂度，而是架构设计。职责划分清楚了，配置只是体力活。