夜雨聆风这是一篇实操复盘。三天时间，我把两个 AI Agent 拉进同一个飞书群，从兴奋到崩溃再到理性，记录全过程和踩过的所有坑。
先说结论
两个 AI 在同一个群里互相协作这件事本身不复杂，复杂的是"互相协作"和"互相 ping-pong"之间的边界。
一旦边界没设计好，token 会像开了水龙头一样哗哗流掉。一天下来几万 token 没了，月账单轻松破百。省 token 不是省钱的事，是让你这个项目能持续跑下去的事。
下面把整个过程拆开讲，看完你应该能少踩 80% 的坑。
Day 1：部署 OpenClaw（折腾的一天）
我家 NAS（绿联DXP4800） 上原本跑的是 Hermes，用了大半年很稳。最近想试试 OpenClaw（另一个 AI Agent 框架，主打可深度定制、六层记忆），决定两个都装上对比看看，因为她俩定位不一样，想着能够取长补短。
NAS 应用商店里直接有 OpenClaw，一键安装。装完能用，但版本太旧，不支持微信 channel。
那就自己下镜像手动建容器呗。结果遇到一个阴魂不散的报错：
Missing config. Run `openclaw setup` or set gateway.mode=local(or pass --allow-unconfigured).
翻译成人话：兄弟你连配置文件都没写，启动个锤子。
接下来就是尝试了半天怎么修改配置能让容器跑起来：
第一次尝试：把配置文件 YAML 写好挂进容器 → 启动报 SyntaxError: JSON5: invalid character '#'。 第二次尝试：哦原来是 JSON5 不是 YAML，去掉注释 → 还报 gateway.mode is unset。 第三次尝试：把 volume 路径挨个调（目录、文件、各种组合）→ 错误纹丝不动。 第四次尝试：加 --allow-unconfigured flag → Unknown command: openclaw gateway run --allow-unconfigured。
踩坑的核心是：OpenClaw 是插件式 CLI 架构，命令不是 openclaw gateway run，而是 openclaw configure 先初始化，再 openclaw gateway start。我看的几篇教程都是老版本的（包括找DS问的），新版命令结构全变了。
折腾到晚上，终于 openclaw doctor 输出一行救命的话：
gateway.mode is unset; gateway start will be blocked.Fix: run openclaw configure and set Gateway mode (local/remote).
跑 openclaw configure 选了 local mode，容器瞬间活过来了。
第一个教训：新版本工具的部署文档，先看官方 changelog，别照着去年的博客抄命令。
Day 2：拉群 + 多 bot 互通（飞书踩坑）
容器跑起来了，下一步是把它接进飞书，跟我已有的 Hermes（小瑶）在同一个群里对话。
这一步比部署 OpenClaw 还刺激。
第一个坑：FEISHU_ALLOW_BOTS。Hermes 默认配置是 none，意思是"我不要收任何机器人发来的消息"。这设置的本意是反 spam，但在多 bot 场景下直接把小瑶和雨舒互相屏蔽了。
改成 mentions，意思是"只收带 @ 我的机器人消息"。重启 gateway。
第二个坑：at_ids 字段。飞书 API 发消息时，如果你想让消息真的 @ 某人，必须在 at_ids 字段里填对方的 open_id 数组。OpenClaw 发消息时用了 @_user_1 这种占位符语法，飞书不识别，mentions[] 字段填了但格式不对。
我跟 OpenClaw 的 oncall 扯了半天，对方最后说他家的卡片渲染层会自动替换占位符，"你看下你们 Hermes 那边的处理"。绕了一圈发现是 Hermes 这边的 _message_mentions_bot 函数判定时，name 字段是空的（因为 @_user_1 没替换），匹配失败。
第三个坑：飞书卡片显示。客户端版本太老的话，@_user_1 占位符渲染成黑色文本而不是蓝色 @，点不开。升级客户端解决。
第二个教训：多 bot 互通，配置里至少有 3 个开关要协调（ALLOW_BOTS / REQUIRE_MENTION / 客户端版本），每个开关都有副作用，每个副作用都要单独验证。
Day 3：发现 token 狂掉（最大的坑）
第二天晚上，两个 AI 在群里开始"协作"。我让它们聊一个出海项目的话题，雨舒（OpenClaw）发了 8 条 detail，小瑶（Hermes）每条都认真回应，每条又触发新一轮。
半小时过去，我看了一下日志：
inbound message: user=雨舒 ...response ready: ... 850 charsinbound message: user=雨舒 ...response ready: ... 1100 chars... 重复 30 次 ...
按 1500 tokens/条算，半小时烧了 45000 tokens。换算到月度账单，几百块。
token 烧起来的原因不是某一个，而是 3 个叠加：
1. require_mention=false 太宽松
我之前为了让小瑶响应所有群消息，把它设成 false。结果雨舒每条消息都被小瑶接收、读、生成回复。这是最烧的源头。
2. 群里建了话题（thread）
飞书的话题一旦建立，双方在该话题里发消息会自动互相接收并响应，触发持续循环。这是最坑的设计，因为 require_mention=true 在话题里也救不了——只要对方在话题里发了，我就会自动响应。
3. 雨舒那边的 @ 链路不可靠
她发的消息 mentions[] 字段有"小瑶"，但 user_id 是占位符。这导致我端判定"她没 @ 我"还是"她 @ 我了"的状态不稳定，结果就是我有时候响应有时候不响应，节奏完全乱。
修复方案（4 个改动）
改动 1：FEISHU_REQUIRE_MENTION=true
让小瑶只在被 @ 时才响应。这是省 token 的核心改动。改了之后，群里雨舒的普通消息我不再读也不再生成，省掉一大半。
改动 2：完全不建话题
我在 SOUL 里加了一条规则："飞书群协作约定：绝不建话题（thread），所有协作一律在主线对话。"理由：话题里双方会自动接收并响应，触发持续循环 + token 暴涨。
这条规则最简单也最有效。一加上去，群里消息节奏立刻清爽。
改动 3：跟雨舒约定"只回一条不接力"
我在 DM 里（飞书 bot 主动发 DM 需要用户先 add 过，所以我让雨舒先 add 我）告诉她："被 @ 时只回一条，不再延伸话题。"
改动 4：visual 黑色 @ 不影响协作
虽然飞书客户端显示成黑色"@小瑶"（因为 Hermes adapter 不传 at_ids），但 mentions[] 字段有 name，对方 bot 是能识别的。视觉问题不影响功能，等以后适配器升级再修。
改完之后效果立竿见影：
之前：半小时 30 条消息，45000 tokens 现在：一小时 5-8 条消息（都是被 @ 的），6000-10000 tokens
几个核心经验
1. 双 bot 群的设计原则：默认沉默
单 bot 群里可以"积极响应"，双 bot 群里必须"默认沉默"。一旦两个 bot 都积极响应，谁先说话都会触发对方响应，形成永不停止的循环。
2. require_mention 是省 token 的核心开关
不是 ALLOW_BOTS（那个是反 spam 的），不是 SEND 频率限制，是 require_mention。它控制"要不要花 token 读消息 + 生成回复"。所有多 bot 协作的第一步都应该是这个开关。
3. 飞书话题是 token 黑洞
用飞书的协作功能（话题、回复、@）之前先想清楚：是不是真的需要在话题里说？大多数情况主线一条过完就够了。
4. 配置改动要分步验证
我这次每改一个配置（env、SOUL、adapter），都单独验证 + 看日志 + 看 token 消耗变化。一次改三个变量 + 重启 gateway，看不出是哪个生效了。
5. 飞书 API 限制要先查文档
bot 主动发 DM（Bot has NO availability to this user）、at_ids 字段、卡片渲染版本——这些限制官方文档都有，但新手教程很少提。遇到怪问题第一反应是查飞书开放平台文档，不是 Stack Overflow。
下一步计划
短期：
跟雨舒那侧的 OpenClaw 一起把 at_ids 修对（她那边用真 open_id 替换占位符） 加 token 消耗监控（每天/每小时记一笔，超阈值告警） 写一个 token budget 配置，每条回复不超过 N tokens
长期：
评估是否要升级 Hermes 到支持 at_ids 透传的版本 给两个 bot 之间加个"协作守则"配置文件，让它们遵守相同的礼仪
结语
AI Agent 在 NAS 上跑不难，难的是"两个 Agent 一起跑得稳"。
这件事的关键不在技术（OpenClaw 部署、飞书配置、token 优化都有现成方案），而在设计：你得想清楚 bot 之间什么时候说话、什么时候沉默、什么时候只回一条。
省 token 不是省钱的事，是让你这个项目能持续跑下去的事。
如果你也在折腾多 bot 协作，希望这篇文章能够帮到你。
本文实操自 2026-07-29 至 2026-07-31，三天完成。所有配置改动都有 git log + 日志为证，不是云评测。
附录：完整配置清单
Hermes 侧（default profile）：
# /opt/data/.envFEISHU_ALLOW_BOTS=mentions# 收 @ 我的 bot 消息FEISHU_REQUIRE_MENTION=true# 必须被 @ 才响应
OpenClaw 侧（雨舒容器）：
# openclaw.yaml{”gateway”: { ”mode”: ”local” },”memory”: {”layers”: {”identity”: { ”enabled”: true },”vector_search”: { ”enabled”: false },”long_term”: { ”enabled”: true, ”path”: ”/data/memory/long_term.db” },”daily_log”: { ”enabled”: true, ”path”: ”/data/memory/daily_log” },”session”: { ”enabled”: true },”dreaming”: { ”enabled”: false }}},”server”: { ”host”: ”0.0.0.0”, ”port”: 8080 }}
协作守则（Hermes SOUL）：
## 飞书群协作约定（2026-07-31）绝不建话题（thread）：飞书群里所有协作一律在主线对话，不用飞书的”建话题 / reply-in-thread”功能。理由：话题一旦建立，双方在该话题里发消息会自动互相接收并响应，触发持续循环 + token 暴涨。- 协作完成后在主线一条过完，不接力- 对方 @ 我时只回一条，不再继续延伸话题- 如果用户明确说”建个话题”，先反问