OpenClaw多Agent到底是利器还是噱头?系列一:6 个 Agent 运转半个月 VS 全团队瘫痪

网上关于多 Agent 的评价，分裂到离谱。

一边是：

“多 Agent 体验太好了，14个 Agent 成本降68%，效率翻 3 倍。”“一个 AI 小团队 24/7 运转，这才是未来。”

另一边是：

“syncing state between two minds is extremely expensive and slow.” —— Hacker News 高赞评论，1000+ upvote

还有更狠的：

McKinsey 最新报告：88%的企业 AI 项目失败。多 Agent 只会放大这个问题。

同一个东西，评价两极分化到这种程度。

到底谁在说谎？

我花了几天时间，扒了中英文社区大量真实案例，从海外内容创作者到阿里内部技术大佬。看完之后，我发现真相远没有”好用”或”不行”这么简单。

故事得从一个最炸裂的案例说起。

一个阿里大佬的 6 Agent 实战

有位叫岚遥的技术大佬，在阿里内部分享了他的 OpenClaw 实战。

他搭建了一套 7×24 自动运转的 AI 系统，包含 6 个专业Agent：

Zoe（大龙虾）：CTO / 首席编排者，负责技术方案设计、任务编排、系统运维。每天 3 次巡检，检查所有 Agent 的执行状态。

AI哨兵（ainews）：情报中枢，每天从 100+ 信息源（GitHub Trending、arXiv、RSS、HackerNews 等）采集信息，产出晨报、午间论文解读、晚间趋势分析。

交易蜘蛛（Trading）：量化分析师，21个 cron 任务，20个原子量化工具，覆盖 A 股全时段 + 美股 + 大宗商品。

Macro（首席经济学家）：提供宏观→传导→国内→市场四层映射因子包，供 Trading 直接引用。

内容蜘蛛（Content）：内容策略师，从 54 个平台热榜抓取素材，走 Research→Ideate→Write→Reflect 四阶段流水线。

管家蜘蛛（Butler）：生活管家，深度集成 Apple 生态，喝水提醒、日程规划、健康检查。

外加 6 个 ACP 编码专家（Claude Code、Codex、Gemini 等），最大 6 并发，负责所有代码实现。

数据更炸裂：

52 个 cron 定时任务，从凌晨 3 点的自动备份到 23:45 的全团队反思
118 个 Skills（33个全局共享 + 85 个 Agent 专属）
29 个注册 LLM 模型，每天几千次 LLM 调用
半个月自动恢复 23 次（是的，系统会自己修复问题）

这还不算最神奇的。

最神奇的是 Agent 会自己进化：

Agent 自己设计通信协议——两个 Agent “收到/确认”刷了十几轮后，Zoe自主诊断根因，设计了三态协议（request→ confirmed → final → 静默），全团队次日自动共享。
Agent 自研 Skill 并发布到 ClawHub——Content 发现 AI 味太重，自己调研 7 个”去 AI 味”工具，编写Skill，发布到 ClawHub。
军工策略纠正→ Agent 自主提炼条件单模板→ 写入MEMORY.md，三周后遇到类似场景自动引用。

看到这里，你可能会说：这不就是利器吗？

然后，就是三个事故。

P0 事故：全团队瘫痪 8 小时

ainews 的 session 因为连续处理新闻和论文，累积到了235K tokens。

Gateway 启动时对所有 session 做compaction，这个 session 永远超时→ crash → macOS 守护进程每秒重启→ 无限循环。

所有Agent全部离线。

修复需要四层：手动清理膨胀 session → 调整 ThrottleInterval → 修改 idleMinutes → 调整 exec 安全模式。

这不是某一个参数的问题，是四个独立的防线全部缺失。

P1 事故：3500 字报告被”智能压缩”到 800 字

交易蜘蛛的收盘速报包含完整的数据表格、资金流向、个股评分。

OpenClaw 在文本超过限制时自动做 content compaction——框架认为”帮你优化了”。

结果：数据表格被”智能压缩”掉了。

在数据密集场景下，AI的”智能”是灾难。

P2 事故：规则失效

当 SOUL.md 里堆满了各种操作规范，当 session 膨胀到几万tokens，Agent开始”选择性遵守”规则。

管家蜘蛛越界做投资分析。交易蜘蛛忽略数据验证规则。

不是模型变笨了，而是关键信息被噪声淹没了。

最戳心的几句话

岚遥在分享里说了三句话，每一句都值得反复咀嚼：

“多模型fallback环境下，规则措辞必须面向最弱的模型。显式>隐式，硬规则>软建议。”

“不要让分析Agent直接编码。早期我额外设了coding、architect、PM三个技术角色，结果发现这几个角色基本没什么实际产出——它们的能力和Zoe + ACP编码专家的组合高度重叠，反而增加了通信复杂度和调试成本。后来全砍了。”

“复杂度随人数快速上升。3个Agent = 3对交互关系，6个= 15对。整个系统从零到6个Agent稳定运行，花了大约半个月的下班时间——每加一个新Agent都需要半天到一天的调试。”

注意第二句。

他自己砍掉了3个Agent角色。

不是别人建议的，是他跑完之后自己得出的结论：那些角色”基本没什么实际产出”。

回到最初的问题

有效果这么炸裂的实践，为什么另一方面还有这么多人在吐槽？

为什么会有人说”同步两个心智的状态极其昂贵和缓慢”？

为什么 McKinsey 说 88% 的 AI 项目会失败？

下集预告：我深度分析了多个 OpenClaw 多 Agent 真实案例，发现了些被所有人忽略的问题。

这是「OpenClaw多 Agent 到底是利器还是噱头？」系列第 1 集，共 3 集。关注公众号，不错过下一集。