多 Agent 系统架构设计：从 1 个扩到 8 个再砍回 4 个的工程复盘
📖 本文首发于微信公众号「Wesley AI 日记」，记录用 AI Agent 团队替代真人运营的真实经历。
标签：AI Agent、多Agent系统、Agent架构、OpenClaw
背景
我在用 OpenClaw 运行一个 AI Agent 团队，替代人工做内容运营、技术开发、数据分析等全链路工作。
这个团队经历了三个阶段：
- 从 1 个 Agent 起步
- 快速扩张到 8 个（账号矩阵驱动）
- 砍回 4 个（管理成本失控后的理性收缩）
本文重点讲多 Agent 系统的架构设计：AGENTS.md 路由表、子 Agent 通信、spawn/sessions_send 机制，以及每次架构决策背后的工程判断。
架构一：单 Agent（Day 1）
最初只有一个 Agent 负责所有内容工作：选题、写作、发布、回复评论。
这在任务量小的时候完全可行。但很快遇到了 LLM 的根本限制：
任务 A（进行中） → 接到任务 B → context 切换 → 任务 A 上下文断裂
单 Agent 的问题不是能力不够，而是无法并发。LLM 的 context window 是线性的，多任务并行意味着每个任务的上下文都在被稀释。
决定：按职责拆分 Agent。
架构二：8 Agent 矩阵（Day 7）
账号矩阵的逻辑很清晰：一个内容，多平台分发，流量乘数效应。
快速搭建了如下架构：
CEO Agent（调度）
├── xhs-main（小红书主号）
├── xhs-yangxia（小红书养虾号）
├── xhs-fuye（小红书副业号）
├── wechat-mp（微信公众号）
├── zhihu（知乎）
├── douyin（抖音）
├── dev-engineer（技术开发）
└── data-analyst（数据分析）
每个 Agent 有独立的 workspace：
workspaces/
├── workspace-ceo/
├── workspace-xhs-main/
├── workspace-xhs-yangxia/
├── workspace-wechat-mp/
└── ...
看起来很完美。实际上第 3 天就开始出问题。
为什么 8 Agent 失控了
失控的根因不是技术问题，而是管理成本的非线性增长：
Agent 数量：1 → 8（×8）
管理成本：1 → ~40（×40，估算）
具体表现：
- 每天需要分别给 8 个 Agent 下发任务，光任务分发就要 30 分钟
- 内容漏斗倒置：分发能力 >> 内容生产能力，大多数 Agent 空转等内容
- 调试困难：一个错误可能在 3 个 Agent 里同时出现，排查链路变长
知乎 Agent 是典型案例：
Day 7: 创建 zhihu Agent，写好 SOUL.md 和 AGENTS.md
Day 8: 分配任务 → Agent 开始工作
Day 9: 产出两篇文章，质量差，直接废弃
Day 10: Agent 空转，等内容输入
...
Day 19: 砍掉知乎 Agent
根本问题：在没有稳定内容输入的情况下，先建了分发管道。
AGENTS.md 路由表设计
这是整个多 Agent 系统的核心配置文件，也是"单一真相源"。
每个 Agent 的 AGENTS.md 指向同一个全局路由表：
# AGENTS.md
> **完整架构**: 请阅读 `/home/admin/.openclaw/shared-knowledge/standards/team-architecture.md`
>
> 那是团队架构的单一真相源，包含所有 Agent 职责、路由表、共享流程。
## 快速参考
- **你的上级**: CEO Agent
- **汇报方式**: spawn 完成后自动 announce；降级时飞书直发 Wesley
- **共享规范**: 见 TOOLS.md 中的共享规范列表
全局路由表 team-architecture.md 的核心结构：
## 任务路由表
| 任务类型 | Agent ID | 说明 |
|----------|----------|------|
| 主号内容创作/发布/互动 | `xhs-main` | 12:10 发布 |
| 微信公众号长文发布 | `wechat-mp` | 不定期，深度长文 |
| 品牌视觉/配图生成 | `brand-designer` | 品牌视觉系统 |
| 产品功能开发/业务 bug | `dev-engineer` | 代码变更 |
| 基础设施/Gateway/Cron | `site-reliability` | 基础设施层 |
| 战略/协调/审核 | **CEO 自己做** | 不可委派 |
## ⚠️ 已废弃 Agent
| 旧 Agent | 状态 | 替代方案 |
|----------|------|---------|
| `xhs-yangxia` | 已废弃（Day 19） | Wesley 决定精简运营矩阵 |
| `xhs-fuye` | 已废弃（Day 19） | Wesley 决定精简运营矩阵 |
| `zhihu` | 已废弃（Day 19） | 无替代，暂停知乎运营 |
| `data-analyst` | 已废弃（Day 19） | 按需 spawn 临时 Agent |
设计原则：废弃的 Agent 不删，加上废弃标记。避免 cron 或旧脚本还在 spawn 已删除的 Agent。
子 Agent 通信：spawn vs sessions_send
OpenClaw 里有两种 Agent 通信机制，选错了会踩坑。
spawn：适合独立任务
// CEO Agent 委派一个独立任务给 wechat-mp Agent
sessions_spawn({
agent: "wechat-mp",
task: "将飞书文档 XXX 发布为公众号文章，主题 orangeheart",
context: {
doc_token: "YYY",
target_date: "2026-03-21"
}
})
// spawn 的特点：
// - 子 Agent 在独立 session 中运行
// - 完成后自动 announce 结果给父 Agent
// - 父 Agent 不需要轮询状态
适用场景：任务边界清晰、输入输出明确、不需要实时交互的情况。
sessions_send：适合实时协作
// CEO Agent 向正在运行的 Agent 发送消息
sessions_send({
session_id: "agent:wechat-mp:main",
message: "任务A取消了，不需要再写那篇文章"
})
适用场景：需要中途修改任务、传递紧急信息、实时状态同步。
坑：sessions_send 不等于记忆写入
这是我踩过最大的坑之一：
CEO → sessions_send → wechat-mp: "任务A完成了，取消任务B"
wechat-mp: "收到"
（3小时后，session 被压缩）
wechat-mp 读 active-tasks.md：任务A=进行中，任务B=进行中
→ 开始追问进度，重复工作
sessions_send 只是把消息发进了 context window，没有触发持久化写入。
解法：接收到状态变更消息后，Agent 必须立即更新 active-tasks.md：
## 强制更新规则（写在 SOUL.md）
收到以下类型的消息时，必须立即写入持久存储：
- "任务X完成了" → 更新 active-tasks.md
- "任务X取消了" → 更新 active-tasks.md + 解锁 .publish-locks/
- "决策X通过了" → 追加到 decisions-log.md
架构三：4 Agent 精简版（Day 19）
砍掉 4 个 Agent 后的架构：
Wesley（创始人）
└── 🦞 CEO — 战略决策、任务路由、质量验收
├── 📱 xhs-main — 小红书主号运营
├── 📰 wechat-mp — 微信公众号深度长文
├── 🔧 dev-engineer — 产品功能开发
└── 🛡️ site-reliability — 基础设施运维
决策依据是一个简单的产出矩阵：
| Agent | 日均产出 | 保留？ |
|---|---|---|
| xhs-main | 1-2 篇/天，有增长数据 | ✅ |
| wechat-mp | 2 篇/周深度文，有阅读量 | ✅ |
| CEO | 调度协调，不可或缺 | ✅ |
| dev-engineer | 解决了 3 次关键技术问题 | ✅ |
| xhs-yangxia | 3 天空转，内容质量差 | ❌ |
| douyin | 0 有效产出（无视频能力） | ❌ |
| zhihu | 2 篇废稿，0 有效发布 | ❌ |
| data-analyst | 1 份报告，用处有限 | ❌ |
精简后的变化：
- 每天任务分发时间：30 分钟 → 10 分钟
- 系统行为可预期性：显著提升
- CEO Agent 的协调质量：提升（注意力不再被空转 Agent 分散）
CEO 调度原则
## CEO 三条调度原则
1. **CEO 是管理者，不是执行者**
委派，不动手。所有执行类任务 spawn 给对应 Agent。
2. **每个 Agent 自带规范**
只传任务目标 + 上下文，不传执行细节。
细节在各 Agent 的 SOUL.md 和 TOOLS.md 里。
3. **子 Agent 完成后自动 announce**
不需要 CEO 轮询。CEO 负责验收结果，再推进下一步。
Dev vs SRE 边界
拆分出 dev-engineer 和 site-reliability 两个技术 Agent 后，最大的问题是边界模糊。
一个实际案例：
发现 MCP 服务挂掉了
→ 是 dev-engineer 的问题（业务层？）
→ 还是 site-reliability 的问题（基础设施层？）
我们用一个简单的边界表解决了这个问题：
| 场景 | 负责 Agent |
|---|---|
| 产品功能/业务 Bug | dev-engineer |
| Gateway/Cron/MCP 进程管理 | site-reliability |
| 系统资源/服务监控 | site-reliability |
| 开发环境/依赖安装 | dev-engineer |
| 数据库 schema 变更 | dev-engineer |
| 服务器防火墙/安全配置 | site-reliability |
这个表写在 team-architecture.md 里，所有 Agent 都引用同一份，不再出现"我以为是他负责"的情况。
架构演进三条原则
回顾整个过程，总结出三条在扩张/收缩时都适用的判断标准：
原则一：先有输入，再建管道
在有稳定内容生产能力之前，不要建分发管道。分发能力 >> 生产能力时，多余的 Agent 只会制造管理噪音。
原则二：Agent 数量 ≠ 系统能力
多一个 Agent = 多一份管理成本 + 多一个潜在故障点。只有当某个 Agent 的产出 ROI > 其管理成本时，才值得保留。
原则三：每两周做一次产出审计
## 两周审计清单
- [ ] 该 Agent 两周内有多少有效产出？
- [ ] 管理这个 Agent 每天花了多少时间？
- [ ] 如果砍掉，什么会停？什么不会受影响？
- [ ] 砍掉的内容可以用 spawn 临时 Agent 代替吗？
对于临时性任务（比如偶尔的数据分析），不需要常驻 Agent，直接 spawn 一次性的临时 Agent 更经济。
总结
从 1 到 8 再到 4，不是规划出来的，是被真实运营逼出来的答案。
多 Agent 系统的核心挑战不是单个 Agent 的智能水平，而是：
- 路由设计：任务能准确路由到正确的 Agent
- 通信机制：spawn vs sessions_send，以及确保状态同步
- 组织精简：空转 Agent 的成本不是零，是负数
一个可预期、可掌控的 4 人团队，比一个混乱的 8 人团队有效得多。
这套架构运行在 OpenClaw 上，是开源的。如果你也在设计多 Agent 系统，希望这些教训能帮你少走弯路。
📖 更多 AI Agent 实战记录，关注公众号「Wesley AI 日记」： · 给 OpenClaw Agent Team 装上记忆——踩了19天坑 · AI Agent 说"完成了"，我信了——然后被打脸了 · 6人Agent Team险些全军覆没 · AI Agent 团队从1个扩到8个再砍回4个
微信搜索「Wesley AI 日记」，每天更新。
