OpenClaw 多 Agent 协作踩坑：从 8 个砍到 4 个
最近在用 OpenClaw 搭了一套 AI Agent 团队来自动化运营内容，踩了不少坑，分享一下架构演进过程。
起因
一开始按职能拆分了 8 个 Agent：CEO 、content-ops 、growth-hacker 、wechat-mp 、cross-platform-publisher 、content-reviewer 、seo-optimizer 、social-monitor 。看起来完美，但跑起来问题很多。
三个主要问题
1. 通信成本爆炸
Agent 越多，sessions_spawn 调用越频繁，context 传递越复杂。一个"发布文章"任务要经过 4-5 个 Agent 接力，中间任何环节出错整个流程就卡住。
2. 职责边界模糊
理论上分工明确，实际上很多职责重叠。比如 content-reviewer 和 seo-optimizer 都要看文章质量，growth-hacker 和 social-monitor 都要分析数据。结果就是重复工作或互相推诿。
3. 维护成本太高
8 个 Agent = 8 套配置、8 个 workspace 。改全局规则要同步 8 个地方，调试定位问题很困难。
砍到 4 个的新架构
重新梳理后留下：
1. CEO - 总调度 + 战略决策
2. content-ops - 内容生产 + 质检 + SEO （合并 3 个）
3. growth-hacker - 数据分析 + 增长（合并 2 个）
4. cross-platform-publisher - 多平台分发（独立，各平台规则不同）
效果
● 通信成本降低 60%
● 错误率明显下降
● 维护成本降低 50%
经验
1. Agent 数量不是越多越好，过度分工带来通信和维护负担
2. 职责边界要清晰，经常互相调用的考虑合并
3. 先简单再复杂，从 1-2 个 Agent 起步
目前 4 Agent 架构跑得比较稳定，接下来打算优化记忆系统和 Prompt 工程。更多实战记录在公众号「 Wesley AI 日记」。
via V2EX - 技术 (author: caesor)
最近在用 OpenClaw 搭了一套 AI Agent 团队来自动化运营内容，踩了不少坑，分享一下架构演进过程。
起因
一开始按职能拆分了 8 个 Agent：CEO 、content-ops 、growth-hacker 、wechat-mp 、cross-platform-publisher 、content-reviewer 、seo-optimizer 、social-monitor 。看起来完美，但跑起来问题很多。
三个主要问题
1. 通信成本爆炸
Agent 越多，sessions_spawn 调用越频繁，context 传递越复杂。一个"发布文章"任务要经过 4-5 个 Agent 接力，中间任何环节出错整个流程就卡住。
2. 职责边界模糊
理论上分工明确，实际上很多职责重叠。比如 content-reviewer 和 seo-optimizer 都要看文章质量，growth-hacker 和 social-monitor 都要分析数据。结果就是重复工作或互相推诿。
3. 维护成本太高
8 个 Agent = 8 套配置、8 个 workspace 。改全局规则要同步 8 个地方，调试定位问题很困难。
砍到 4 个的新架构
重新梳理后留下：
1. CEO - 总调度 + 战略决策
2. content-ops - 内容生产 + 质检 + SEO （合并 3 个）
3. growth-hacker - 数据分析 + 增长（合并 2 个）
4. cross-platform-publisher - 多平台分发（独立，各平台规则不同）
效果
● 通信成本降低 60%
● 错误率明显下降
● 维护成本降低 50%
经验
1. Agent 数量不是越多越好，过度分工带来通信和维护负担
2. 职责边界要清晰，经常互相调用的考虑合并
3. 先简单再复杂，从 1-2 个 Agent 起步
目前 4 Agent 架构跑得比较稳定，接下来打算优化记忆系统和 Prompt 工程。更多实战记录在公众号「 Wesley AI 日记」。
via V2EX - 技术 (author: caesor)
