症状：配置没问题，Bot 就是不理人

groupPolicy: open 配了，requireMention: false 也写了，反复检查 openclaw.json，没有拼写错误，没有格式问题。但 Bot 在群里就像聋了一样，完全不响应普通消息。重启了好几次，还是不行。

后来我换了个思路，不再盯着 OpenClaw 的配置文件看，而是从底层往上逐层排查，才发现问题根本不在 OpenClaw 这一层。

Telegram Bot 默认开启了 Privacy Mode，在这个模式下，Bot 只能收到三种消息：

  • 直接 @ 它的消息
  • 以 / 开头的命令
  • Bot 作为管理员的群组中的所有消息

也就是说，你在 OpenClaw 里配了 requireMention: false，但 Telegram 服务端压根不会把普通群消息推给你的 Bot。应用层配置正确，传输层把流量拦了。这跟微服务里路由规则写对了但网关防火墙没开是一个道理。

三层排查法：以后遇到「配置对但不生效」就用这个

我把这次的排查过程整理成了一个通用框架，以后遇到类似问题可以直接套：

第一层：应用层配置

  • openclaw.json 里的 groupPolicy: open 和 requireMention: false 是否正确
  • 用 openclaw config get channels.telegram 验证配置确实已加载

第二层：传输层权限

  • Telegram Bot 的 Privacy Mode 是否关闭
  • Bot 是否有读取群消息的权限
  • 这一层是绝大多数人忽略的地方

第三层：网络连通性

  • OpenClaw Gateway 是否正常运行
  • Telegram Webhook 或长连接是否建立成功
  • 发一条测试消息验证端到端链路

说实话这个框架不只是 OpenClaw 能用，K8s、消息队列、任何分布式系统的配置问题都可以按这个思路排查。

具体怎么修：两步操作

第一步：确认 OpenClaw 配置

编辑 ~/.openclaw/openclaw.json，确保群聊相关配置正确，然后执行：

openclaw gateway config.patch --file openclaw.json

第二步：关闭 Telegram Bot Privacy Mode

这是关键，很多人就是漏了这步：

  1. 在 Telegram 中找到 BotFather
  2. 发送 /mybots
  3. 选择你的 Bot → Bot Settings → Group Privacy
  4. 点击 Turn off
  5. 确认显示 Privacy mode is disabled

一个细节：Privacy Mode 关闭后立即生效，不需要重启 OpenClaw。因为 Telegram 用的是长连接推送架构，权限变更会实时同步。知道这一点挺有用的——以后判断哪些改动需要重启服务、哪些不需要，看它底层是推送还是轮询就行。

验证： 在群里发一条普通消息（不用 @ Bot），Bot 应该立刻响应。

如果还是不行，按三层排查法逐层检查：

  • 应用层：/status 看 OpenClaw 状态
  • 传输层：确认 Bot 没被踢出群、没被禁言
  • 网络层：检查 OpenClaw Gateway 日志，看有没有收到 Telegram 的推送

open 还是 allowlist：看你的场景

配 groupPolicy 时有两个选择，我也纠结过：

open 模式——所有群成员都能触发 Bot。方便，适合自己测试或小团队内部用，但任何人都能执行命令，有安全风险。

allowlist 模式——只有白名单用户能触发。安全，符合最小权限原则，但要维护用户白名单，管理成本高一些。

我自己的做法是：开发测试阶段用 open，快速迭代；一旦涉及生产环境或敏感操作，切到 allowlist 并配合 tools.elevated.allowedUsers 严格限制。没有哪个绝对更好，看场景。

生产环境别忘了这几件事

配置跑通之后容易觉得"搞定了"，但做 Agent 自动化，尤其是放到群里给别人用的，还得多想一步：

  • 定期跑一下安全审计：openclaw security audit，检查权限是否过度开放
  • 配置文件纳入 Git 管理：openclaw.json 每次改动都有 commit 记录，出问题能追溯
  • 准备回滚方案：如果 Privacy Mode 关了之后出现被恶意调用的情况，马上在 BotFather 重新开启 Privacy Mode，或者把 Bot 移出群，或者切到 allowlist 模式

这次排查让我意识到一个挺普遍的问题：搭 Agent 工作流的时候，我们容易只盯着应用层的配置文件，但实际上很多"配置对了但不生效"的坑都藏在更底层。养成分层排查的习惯，能省掉大量无效的反复检查时间。