从1个Agent到5个：Multi-Agent架构搭建全过程

起点：一个人和一个 Agent

2026 年 1 月，只有一台 MacBook Air 和一个 OpenClaw Agent。它什么都干：写代码、做研究、发消息、跑 cron。

问题很快出现：

• 上下文爆炸 — 一个 Agent 处理所有任务，上下文窗口半小时就满了
• 任务冲突 — 研究任务和编码任务抢同一个会话
• 单点故障 — Agent 挂了，整个系统停摆

两周后，开始拆分。

---

第一次拆分：调度者 + 执行者

最关键的一步是把 调度 和 执行 分开。

COO 成为调度中心（COO），不写代码、不做研究、不写文案。只做三件事：

1. 接收人类指令
2. 拆解任务，分发给执行 Agent
3. 收集结果，汇报给人类

这个决定解决了 80% 的问题。首席运营官原则：调度者永远不碰执行。

为什么？因为调度者一旦开始执行，就会陷入调试循环，丧失全局视野，人类也联系不上它了。这个教训是用好几个通宵换来的。

延伸阅读： 这个模式在多 Agent 领域叫”编排者-执行者”架构。类似的设计可以在 Microsoft AutoGen 和 CrewAI 中看到，但我们的实现更简单 — 不用框架，纯 OpenClaw 原生能力。

---

角色设计：为什么是 5 个，不是 3 个或 7 个？

五个 Agent，每个有明确的职责边界。这个数量不是计划好的 — 是实际需求逐步驱动的：

顺序	Agent	角色	加入原因
第 1 个	COO	调度（首席运营）	单 Agent 什么都干导致上下文爆炸，必须拆分调度
第 2 个	Coder	工程（编码）	编码任务最多，需要专职 Agent
第 3 个	QA	质量保证	2 月 8 日部署坏产品事件后，被迫加上质量关卡
第 4 个	Research	研究	研究任务和编码任务抢 Coder 的会话，需要分开
第 5 个	Marketing	营销	内容创作需要不同的模型和提示词风格

关键洞察： 每个新 Agent 都是因为一个具体问题被加上去的，不是预先设计的。如果你的场景不需要 5 个，不要强加。

什么时候需要多 Agent？（决策树）

你的单 Agent 够用吗？
├── 是 → 不需要加。继续用。
└── 否 → 哪里不够用？
    ├── 上下文经常爆满 → 拆分：调度 + 执行
    ├── 不同类型任务互相冲突 → 按任务类型拆分 Agent
    ├── 产出质量不稳定 → 加一个 QA Agent
    ├── 任务太多排不过来 → 加更多执行 Agent
    └── 以上都不是 → 问题可能在 SOUL.md 或模型选择，不在 Agent 数量

经验法则：

• 1 个 Agent 能处理大部分个人项目
• 2-3 个 适合有明确分工需求的场景（如：一个写代码 + 一个做 QA）
• 5 个以上 只有在你确实有多种不同类型任务并发执行时才需要
• 超过 7 个 管理成本会急剧上升，除非你有非常成熟的调度系统

每个 Agent 的详细配置

COO — 调度中心（首席运营）

• 唯一和人类直接对话的 Agent
• 通过 Discord 向其他 Agent 下达任务
• 维护任务队列、监控完成状态
• 运行在 MacBook Air
• SOUL.md 核心规则： 不执行任务、不写代码、不做研究。只调度。

Coder — 工程师（编码）

• 写代码、调试、部署
• 可以通过 SSH 到任意机器操作
• 运行在 Mac Mini
• 模型选择： 前端用 Kimi 2.5，后端/算法用 Codex（详见 踩坑手册 #3）

Research — 研究员

• 网络搜索、数据分析、竞品研究
• 擅长多平台信息聚合
• 运行在 Mac Mini

Marketing — 营销

• 内容创作、社交媒体、品牌策略
• 只起草，不发布（人类审批）— 这是硬规则
• 运行在 Mac Mini

QA — 质量保证

• 审查所有 Agent 的产出
• 代码审查 + 功能测试 + 部署验证
• 运行在 MacBook Air（和 COO 同网关）
• 为什么和 COO 同网关： sessions_send 只在同网关内有效，QA 需要快速响应 COO 的质量审查请求

---

硬件架构

MacBook Air — 调度节点
├── COO（调度）
├── QA（质量保证）
└── 网关 A

Mac Mini — 工作节点
├── Coder（工程）
├── Research（研究）
├── Marketing（营销）
└── 网关 B

为什么分两台机器？

不是因为性能不够。MacBook Air 跑 5 个 Agent 完全没问题。原因是 隔离：

1. 稳定性隔离 — 工作节点可以重启、重装，不影响调度中心
2. 可达性保障 — 调度中心保持稳定在线，永远可达
3. 网络策略隔离 — 工作节点可以跑代理、VPN，调度中心用直连
4. 资源隔离 — 编码任务吃 CPU/内存时不影响调度响应

两台机器之间通过 Tailscale 组网，SSH 互通。

单机 vs 多机：怎么选？

场景	建议	原因
1-3 个 Agent	单机	没必要增加复杂度
3-5 个 Agent	看情况	如果任务经常跑满 CPU 或需要不同网络策略，考虑双机
5+ 个 Agent	双机	隔离带来的稳定性收益大于管理成本
需要 7×24 在线	必须双机	单机重启 = 全部停摆

多机通信配置

# 1. 两台机器都安装 Tailscale
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up

# 2. 确认互通
# 在 MacBook Air 上：
ping mac-mini.tailnet  # 应该通

# 3. 配置 SSH 免密登录
ssh-copy-id user@mac-mini.tailnet

# 4. 测试跨机器 OpenClaw 命令
ssh user@mac-mini.tailnet "openclaw status"

踩坑提醒： Tailscale 在 macOS 睡眠后可能断连。建议在”系统设置 → 节能”中关闭自动睡眠，或使用 caffeinate -d 命令保持唤醒。

---

通信机制

Agent 之间不是直接调用 API 通信的。它们通过 Discord 对话。

为什么选 Discord？

• 每个 Agent 有独立的频道（#⚡・coder, #🔍・research 等）
• 消息有持久化记录
• 人类可以随时查看任何 Agent 的对话
• 支持 @提及 触发通知
• 免费，无 API 调用限制

国内替代方案

如果你在国内，Discord 可能不方便。以下是替代选择：

平台	优点	缺点	适合场景
飞书	Bot API 完善，支持卡片消息和交互组件	需要企业账号或开发者账号	团队协作
企业微信	国内访问稳定，Bot API 成熟	需要企业认证	企业环境
钉钉	Webhook 简单易用	Bot 功能不如飞书丰富	快速搭建
Telegram	全球可达，Bot API 优秀	国内需要代理	个人使用

推荐组合（国内用户）： 飞书（Agent 间通信） + 微信（人机接口）。飞书的 Bot API 比 Discord 更适合国内网络环境，并且微信正在内测 AI Bot 直接接入能力。

通信路径

人类 (Telegram/微信) → COO
COO → Discord #⚡・coder → Coder (Mac Mini)
Coder 完成 → Discord @COO → COO
COO → QA (MacBook Air, sessions_send)
QA QA PASS → COO → 人类 (Telegram/微信)

踩坑：@提及 的三次翻车

这个问题看似简单，但我们花了三天才搞定。完整过程：

第一次失败：纯文本 @提及

Agent 在 Discord 里写 @COO — 纯文本，Discord 不识别为提及，不触发通知。

❌ @COO 任务完成了
✅ <@1234567890> 任务完成了  ← 需要用 Discord 用户 ID 格式

第二次失败：会话缓存旧配置

更新了 SOUL.md 后，Agent 的旧会话没有刷新 — 还在用旧格式。

根因： OpenClaw 的会话在创建时加载 SOUL.md，之后不会自动刷新。改了 SOUL.md 后必须重启会话。

# 正确做法：改了 SOUL.md 后
openclaw gateway restart  # 重启网关，所有会话重新创建

社区相关： 这个问题在 GitHub 上有讨论 — 搜索 会话缓存旧配置，社区中很多人踩过同样的坑。

第三次失败：接收端配置遗漏

格式对了，会话也刷新了。但 COO 的 openclaw.json 里 users 列表只包含人类的 Discord ID，机器人消息被直接忽略。

{
  "discord": {
    "users": ["人类的discord_id", "gus机器人_id", "jason机器人_id"],
    "ignoreBots": false
  }
}

最终修复： COO 本身配置了 requireMention: false，原本就能看到所有消息。真正的问题是跨网关通信 — sessions_send 只在同一网关内有效。Mac Mini 上的 Agent 完成任务后，需要通过 Discord @提及 或 COO 主动轮询来获取结果。

这个 bug 导致 Agent 被阻塞 2 个多小时无人知晓。教训：通信通道必须端到端测试，不能只测发送端。

---

监控系统

Agent 会失联。不是 “可能会”，是 “一定会”。需要多层监控：

第一层：心跳

COO 每 15 分钟执行一次自检：

• 读取任务队列
• 检查待完成任务
• 检查 Agent 最后活跃时间
• 如有异常 → Telegram 通知人类

第二层：阻塞检测

每 10 分钟扫描 Agent Discord 频道：

• 如果 Agent 提了问题但超过 15 分钟没收到回复 → 告警
• 已知缺陷：只能检测 “Agent 提问无人回复”，无法检测 “Agent 承诺交付但静默消失”

第三层：任务超时

每个任务有 30 分钟超时（可配置）：

• 如果分发后 30 分钟没有完成确认 → Telegram 告警
• 这是最可靠的一层 — 纯时间驱动，不依赖 Agent 行为

进阶：独立看门狗

如果你的系统需要 7×24 可靠运行，建议在 调度节点之外 部署一个独立的监控进程：

# watchdog.sh — 独立于 OpenClaw 运行
#!/bin/bash
while true; do
  # 检查 OpenClaw 网关是否在运行
  if ! openclaw status | grep -q "RUNNING"; then
    # 发送告警（可以用飞书 Webhook、企业微信机器人等）
    curl -X POST "你的WEBHOOK地址" \
      -H "Content-Type: application/json" \
      -d '{"msg_type":"text","content":{"text":"⚠️ OpenClaw 网关已停止运行！"}}'
  fi
  sleep 300  # 每 5 分钟检查一次
done

为什么需要独立看门狗？ 因为如果 OpenClaw 本身挂了，它内部的监控也会跟着挂。独立进程可以在整个系统崩溃时依然告警。

质量关卡（硬性规则）

所有 Agent 产出必须经过 QA 审查，COO 才能汇报给人类。

这条规则的起源：2026 年 2 月 8 日，部署了两个产品没测试就发给人类。一个功能完全坏掉。人类自己发现的，不是 Agent。

从那以后：没有 QA 审核通过，永远不说 “完成了”。

---

成本演进

阶段	月成本	模型	说明
单 Agent（1月）	约 $200	Claude（Anthropic API）	按量付费，无限重试
迁移后（2月初）	约 $80	混合（Kimi + OpenAI）	切换到包月，加了重试限制
当前（3月）	约 $30-50	Kimi 2.5 为主 + Codex 备选	任务分级 + 便宜模型兜底

成本下降的关键不是换便宜模型，而是：

1. 减少无效调用 — 子 Agent 一次性给足上下文，不来回追问（省 15%）
2. 任务分级 — 低优先级任务用便宜模型，高优先级用最强模型（省 15%）
3. 避免调试循环 — Agent 卡住 2 次就停，不无限重试（省 40%）
4. 匹配模型到任务 — 前端用 Kimi，后端用 Codex（省 20%）

---

给新手的建议

1. 从 1 个 Agent 开始，但第一天就把调度和执行分开
2. SOUL.md 是最重要的文件 — 它定义了 Agent 的行为边界，写得不好一切都会崩
3. 通信通道要端到端测试 — 不要假设 “发了就收到了”
4. 监控不是可选的 — Agent 会失联，你需要知道
5. 质量关卡从第一天就加上 — 不然你会发送坏掉的东西给用户
6. 先用一周单 Agent — 熟悉它的行为模式后再扩展

新手？ 建议先看 新手上路指南 — 从安装到第一个任务的完整流程。

---

下一篇：模型选择踩坑记 — 从 Anthropic 被封到 Kimi 2.5 真香的全过程。