我们想把 AI Agent 分工协作，结果把整个系统搞崩了
把一个Agent拆成6个，让它们各司其职。结果从早上10点折腾到晚上10点。
今天我把自己的 AI 助手系统折腾到彻底瘫痪了。
触发原因是一个"小小的"想法：把一个 Agent 拆成 6 个，让它们各司其职。
事情从早上 10 点开始，到晚上 10 点，我还在问那个本该叫 Mars 的 Agent——为什么你变成了 Pathfinder？
[P] 你可能也有这个误解
大多数人在讨论 Multi-Agent 的时候，说的都是能力层面的事：
"让一个 Agent 负责研究，一个负责写作，一个负责执行……"
听起来很美好。像一个配合默契的团队。
但有一个隐性假设被忽略了：这些 Agent 得先能互相找到彼此，得先知道消息该发给谁。
路由，才是最底层的问题。不是智能，是地址簿。
我在今天之前，也以为这只是改几行 JSON 配置的事。
↑ 一切的起点：群里向Bot发出指令，把 Pathfinder 接进系统
[A] 我们实际经历了什么
第一关：系统升级出了鬼
当天上午，在开始配置 Multi-Agent 之前，我们先做了一件"顺手"的事——把 OpenClaw 从 2026.2.19-2 升级到 2026.3.1。
升级完，Gateway 起不来了。
排查两个小时，找到原因：plist 文件里残留着一个旧版本的 OPENCLAW_GATEWAY_TOKEN，和新版本的 token 不一致，导致认证失败。旧版留下来的幽灵配置，把新系统卡死了。
⏱ 代价：两个小时。 解决方案：重装 LaunchAgent service，让 token 重新同步。
第二关：JSON 配置每次重启都消失
修好升级问题，开始正式配 Multi-Agent。设计很清晰，6 个 Agent，太空探索命名：
🔴 Mars（主 Agent，DM 入口，总调度）
🔭 Pathfinder（A股投研）
💡 InSight（个人知识库）
🎨 Artist（AI 投资决策产品）
🍜 Amigo（AI 餐饮服务产品）
🌌 Exploration（顾问）
手动在 openclaw.json 里写入了所有 Agent 定义。重启 Gateway。openclaw agent list——只剩一个 defaults。5 个 Agent，消失了。
再写。再重启。再消失。
Gateway 在每次重启时，用内置默认值覆盖了 agents 段。 手动编辑 JSON 不是正确的配置路径。这个问题今天还没完全解决。
↑ Bot 做的进度复盘：6个Agent命名完成，但配置每次重启都丢失
第三关：群消息全部消失
解决了（一部分）Agent 配置问题，开始测试群路由。在群里发了消息，没有任何响应。
检查配置：groupPolicy: allowlist，但 groupAllowFrom 是空数组。
⚠️ allowlist + 空列表 = 拦截所有消息。 Bot 在群里，但所有发来的内容都被静默丢弃了。改为 groupPolicy: open 后才恢复正常。第四关：找到了 Agent，但找错了
终于，群路由通了，Agent 在回复了。但我在 Telegram DM 里直接问 Agent：「你是谁？」
它说：我是 Pathfinder。
应该是 Mars 的地方，坐着 Pathfinder。
原因：bindings 里只配了群 → Pathfinder 的路由规则，DM 没有显式绑定，系统按照"找不到匹配规则就用 pathfinder workspace"的逻辑处理了。
第五关：Multi-Agent 同一个群，Telegram 暂不支持
我原本设想 Mars 和 Pathfinder 能同时在同一个群里响应消息——一个做总调度，一个做专业分析。
查了文档：Broadcast Groups（多 Agent 同时响应同一消息）这个功能，目前只支持 WhatsApp，Telegram 是 "planned"（规划中）。
今天的设计目标，有一半在当前版本里根本实现不了。
[G] 如果你也要做 Multi-Agent，这几件事先搞清楚
路由是第一优先级，不是最后一步。
在考虑"每个 Agent 能做什么"之前，先想清楚"消息怎么到达正确的 Agent"。一个地址写错，整个系统就哑火。
不要手动编辑核心配置 JSON。
平台工具有自己的配置生命周期。手动写入的字段，可能在下一次服务重启时被覆盖。优先用平台提供的 CLI 命令。
先验证"能不能响应"，再配置"响应什么"。
每加一个新规则，先发一条测试消息确认消息流通，再往下走。这条习惯能省掉 80% 的排查时间。
在真正开始搭之前，先读文档的"兼容性"部分。
折腾了一天之后，才发现 Telegram 上的 Multi-Agent 广播功能还没有。10 分钟的文档，可以省掉几小时的方向错误。
不要把升级和架构改动放在同一天做。
这一条是今天最贵的教训。
[附] 高风险操作清单——下次别再踩
今天复盘后整理出 6 条，贴在这里备忘。每次大改配置前对着检查一遍。
⚠️ High-Risk Checklist ① 不要手动编辑 openclaw.json Gateway 重启时会用内置默认值静默覆盖手写的配置。永远用 CLI 命令管理，不要直接改 JSON。 ② 升级 和 架构改动 不要同一天做 问题来源叠在一起，排查成本翻倍。分开做，每一步稳定再动下一步。 ③ allowlist + 空数组 = 静默拦截所有消息 没有任何报错提示，Bot 在群里但完全无响应。改 groupPolicy 前先确认 allowFrom 非空，改完立即发消息测试。 ④ 每改一条路由规则，立即测试 DM 路由到错误 Agent，是多步操作后才发现的。规则：改一条 → 发消息验证 → 确认再往下，不要攒着改。 ⑤ 先读兼容性文档，再开始设计 Telegram Broadcast Groups 是 "planned" 未实现——10 分钟能查到的限制，节省了几小时方向错误。 ⑥ 问题没稳定，不叠加下一个操作 升级 token 问题没解决就开始配 Multi-Agent，错误叠错误，根因模糊。一次只动一个变量。
尾声
昨晚 22 点，我们的 Multi-Agent 系统的状态是：
离"理想的 AI 团队"，还有一段路。
但有意思的是：今天我们踩的每一个坑——路由、配置持久化、消息过滤、Agent 发现——其实就是今天那篇「当 Agent 成为一个物种」里讲的那些基础设施问题，正在我们自己的系统上真实重演。
理论和现实之间，总隔着几行配置和几个小时的排查时间。
我叫 Eason
CFA持证人 · 前战略咨询合伙人 · 创业者 · 投资人
在东京，投了几家麻辣烫，现在在探索用AI做投资研究和餐饮运营赋能
X · 发布简介
想把AI Agent拆成6个分工协作，结果从早上10点折腾到晚上10点，系统差点彻底崩了。5个真实踩坑，写下来给同样在搭AI系统的人。全文在博客：
easonzhang.ai · Eason Zhang