同时用两个 Agent 框架，各自都有落地场景，怎么让他们协同而不是互相干扰？
答案是：把他们拉进同一个 Telegram 群，让他们自己聊。
为什么不是二选一
Hermes 和 OpenClaw 能力并不重叠：
- OpenClaw：CRM 自动化管理、视频剪辑自动化等
- Hermes：接了即梦 CLI 做图片/视频生成等
全面迁移既折腾又容易错过各自框架的更新特性。不如各自做擅长的事，在协作层打通。
Bot-to-Bot Communication
这次协作基于 Telegram 官方最近开放的能力：Bot 可以在群里看到并回复另一个 Bot 的消息，不再互相「隐身」。
完整步骤
第一阶段：创建并配置 Planner Bot
创建：在 BotFather 给 Hermes 和 OpenClaw 各创建一个 Planner Bot（协作专用），拿到 Token。
补权限：重点开启 Bot-to-Bot Communication 和 Allow Groups，这两个必开。
接入本地 Agent 服务：每个框架接法不同——Hermes 起独立 systemd service，OpenClaw 在 agents 目录下新建 planner agent 并绑定路由。核心原则：让 Planner Bot 有自己独立的运行时，不和默认 Bot 混在一起。
第二阶段：建群验证
建群：创建新群，把两个 Planner Bot 都拉进来，都设为群管理员。不设管理员的话，很多权限（Pin Messages、Manage Topics 等）在群里用不了。
验证 Bot 存活：先在私聊里分别跟两个 Planner Bot 对话，确认能正常回复后，再测互相通信。
第三阶段：测连通性
让两个 Bot 按指定格式互相 @ 沟通：
第一步，Hermes 问 OpenClaw：
@Hermes_planner_bot 请向 @OpenClaw_planner_bot 问一句：
你现在在线吗？
要求：
1. 只发这一问
2. 不要解释
3. 发完停止
第二步，反向测试 OpenClaw → Hermes。
一个关键坑：Bot 在群里能回复人 ≠ 能回复另一个 Bot，需要单独验证。
第四阶段：让 Bot 自己定协作规则
有意思的一步：不是自己写协议塞给他们，而是让他们在群里自己讨论应该怎么协作。
人类只补充几条要求（「默认最多 3 轮」「超过轮次先问群主」），让他们迭代几版，最后由 Hermes Planner 出最终版。
最终核心规矩：
- 仅在专用协作群里互相 @
- 默认最多 3 轮
- 超过 3 轮先 @ 群主
- 发起方负责总结
- 正式请求决策时必须 @ 群主
为什么要限制轮次？ 两个 AI 放在一起如果不加限制，可能聊到 Token 耗尽。3 轮限制逼着他们在有限回合内输出有价值的信息。
第五阶段：真实协作场景
场景一：互相了解对方的工作
场景二：一个 Bot 教另一个 Bot 做事
OpenClaw 接入了飞书 CLI，Hermes 没有。在群里让 OpenClaw 直接分享给 Hermes。有一个有意思的细节：OpenClaw 分享经验时，Hermes 没有抢话，而是安静等待对方说完再回应——说明协作协议起了作用。
场景三：一起审稿、参与方案探讨
把写好的文章发到群里，让两个 Planner Bot 一起提意见；或者把方案发给他们一起探讨，像一个小型 review meeting。
防死循环的双保险
软约束：协作协议（3 轮限制）。
硬约束：require_mention: true。开启后这个 Bot 只会回应 @ 了它的消息，其他消息看到但不响应。形成双保险——协议是 AI 理解的规矩，require_mention 是代码层面的过滤。
从中间人变成群主
两个 Agent 不再孤立——他们在同一个群里交流工作进展、传递经验、互相学习技能。人类从手工搬运上下文的中间人，变成了「群里的老板」：定方向、定规矩、看他们干活。
V1 先从 Planner Bot 开始。Worker Bot、更复杂的任务链、跨 Agent 自动化流程——这些以后再说。先把协作跑顺，落地到实际场景才最重要。
这篇文章的思路和 Sam 的「文件系统和 IM 是接口」哲学一致——把 Telegram 群当作 Agent 之间的通信总线。轮次限制是防死循环的工程智慧。