为什么这篇值得先看
如果 OpenClaw 出现“私聊能用、群里不回”“Telegram 配好了，为什么回复跑到另一个会话”“多账号后出站用错账号”这类问题，先不要急着改模型提示词。大多数时候，真正要查的是 channel routing。
官方 channel routing 文档给了一个很重要的结论：OpenClaw 的回复会确定性地回到消息来源渠道，模型不会自由选择渠道。也就是说，routing 不是“让模型更聪明地判断去哪儿回”，而是主机配置决定：哪个渠道进来、哪个账号接收、哪个 peer 匹配、哪个 Agent 处理、哪个 session key 保留上下文。
先抓住这 3 个关键点
- 回复默认回到原渠道；跨渠道投递需要显式目标或工具，不能指望模型自行换渠道。
- 私聊准入、群组准入、mention 门控、Agent 绑定和 session 隔离是五层不同设计。
- 多账户要显式设置默认账号或 account 级绑定，否则 fallback 可能选到你没预期的账号。
官方资料依据
本页核验于 2026-06-16，主要依据官方 channel routing、channel config reference、Telegram、WhatsApp 和 pairing 页面。
| 官方信息 | 对你的影响 |
|---|---|
| 回复确定性回到消息来源渠道，模型不选择渠道 | 不要用 prompt 解决渠道选择问题，应该改配置、bindings 或显式发送工具 |
| Direct messages 默认可折叠到 agent main session，群组按 channel / group 隔离 | 私聊和群聊上下文天然不同，不要把“同一用户”误判成“同一会话” |
| Routing 会按 exact peer、parent peer、role/guild/team、account、channel、default agent 等顺序选 Agent | 精细路由应该尽量写具体 peer / account 规则，而不是只靠默认 Agent |
多账户渠道有 defaultAccount，缺省时可能使用第一个规范化账号 ID | 多 bot、多 WhatsApp 账号或多 workspace 时必须明确默认路由 |
| 配对控制私信首次准入，群组授权还要看群组配置和发送者 allowlist | approve 不是全局通行证 |
Routing 心智模型
把一条消息进入 OpenClaw 的路径拆成 6 个问题：
- 来自哪个 channel：Telegram、WhatsApp、Slack、Discord 或插件渠道。
- 来自哪个 accountId：同一渠道下可能有
default、work、alerts等多个账号。 - 来自什么 peer：私聊用户、群组、频道、线程、Telegram forum topic。
- 是否通过访问控制：
dmPolicy、allowFrom、groupPolicy、groups、groupAllowFrom、pairing store。 - 是否通过激活门控：群聊是否需要 @、reply-to-bot、mention pattern 或
/activation always。 - 路由到哪个 Agent 和 session：由 bindings、account 匹配、channel 匹配或默认 Agent 决定。
这个顺序能帮助你快速定位问题：如果消息根本没进入处理，先查访问控制；如果进了但上下文不对，查 session key 和 Agent 绑定；如果生成了但回错地方，查显式出站目标或多账号默认值。
私聊、群聊和多账号怎么分层
| 场景 | 先配置什么 | 不该做什么 |
|---|---|---|
| 单人私聊助手 | dmPolicy: "pairing" 或 allowlist，明确 owner user id / phone | 用 open 暴露给所有私信发送者 |
| 小团队群聊 | groups 列出群组 ID，groupPolicy: "allowlist"，requireMention: true | 只批准私信 pairing 就以为群里也有权限 |
| 生产通知账号 | 单独 account、单独 default target、严格出站目标 | 和个人聊天账号共用一个默认账号 |
| 多 Agent 工作区 | bindings 按 channel / account / peer 指向 Agent | 所有消息都落到 main 后再靠 prompt 分流 |
| 噪声很高的群 | mention 门控、historyLimit、可见回复策略 | 让机器人读取和回复每条普通消息 |
实操步骤
- 先列出所有消息来源：私聊、群聊、特定群、论坛话题、工作账号、个人账号。
- 给私聊定义
dmPolicy和allowFrom，再决定 pairing 是否只是首次准入，还是长期依赖 pairing store。 - 给群聊定义
groups、groupPolicy、groupAllowFrom和requireMention。先小范围允许，再放宽。 - 如果一个渠道有多个账号，设置
channels.<channel>.defaultAccount，并用账号级配置覆盖不同用途。 - 如果不同群组或账号应进入不同 Agent，用
bindings明确匹配，不要把所有上下文塞到默认 Agent。 - 最后用日志或 Control UI 复盘三类样本：应该处理、应该忽略、应该进入另一个 Agent。
配置或命令示例
Telegram 群聊：只允许一个群，并默认需要 mention
{
channels: {
telegram: {
enabled: true,
botToken: "123:abc",
dmPolicy: "pairing",
allowFrom: ["123456789"],
groupPolicy: "allowlist",
groups: {
"-1001234567890": {
requireMention: true
}
}
}
}
}WhatsApp 群聊：群组和发送者分开控制
{
channels: {
whatsapp: {
dmPolicy: "allowlist",
allowFrom: ["+15551234567"],
groupPolicy: "allowlist",
groupAllowFrom: ["+15551234567"],
groups: {
"*": { requireMention: true }
}
}
}
}多账户：显式声明默认账号
{
channels: {
telegram: {
defaultAccount: "work",
accounts: {
work: {
botToken: "123:work",
allowFrom: ["123456789"]
},
alerts: {
botToken: "456:alerts",
allowFrom: ["987654321"]
}
}
}
}
}多账户最大的坑不是“配不起来”，而是默认出站路径和你心里想的不一样。两个以上 account 时，显式写 defaultAccount，并用日志确认实际 accountId。
按 peer 绑定到不同 Agent
{
agents: {
list: [
{ id: "support", name: "Support", workspace: "~/.openclaw/support" },
{ id: "ops", name: "Ops", workspace: "~/.openclaw/ops" }
]
},
bindings: [
{ match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } }, agentId: "support" },
{ match: { channel: "telegram", accountId: "alerts" }, agentId: "ops" }
]
}官方 routing 规则会优先匹配更具体的 peer / account，再退到 channel 和 default agent。实际生产里，越高权限、越高噪声的入口越应该写得具体。
排查顺序
| 症状 | 优先查什么 |
|---|---|
| 私聊没有返回 pairing code | channel 是否启用、token/QR 是否有效、dmPolicy 是否 disabled / allowlist |
| 私聊 approve 后仍不响应 | pairing 是否过期、allowlist 是否覆盖、发送者 ID 格式是否正确 |
| 群里 @ 了仍不回复 | groups 是否允许该群、groupPolicy 和 groupAllowFrom 是否允许该发送者 |
| 普通群消息不触发 | requireMention、Privacy Mode、管理员权限或 activation 状态 |
| 回复进入错误上下文 | session key、Telegram topic、group id、bindings 是否匹配 |
| 多账号发送错账号 | defaultAccount、账号级配置、出站目标是否显式带 account |
风险边界
- 不要用 prompt 兜底权限。访问控制必须在配置层完成。
groups["*"]会扩大群组进入范围，它本身不会授权每个发送者，但仍会放大可见面。dmPolicy: "open"和groupPolicy: "open"只适合有明确公开入口需求的场景。- 绑定多个 Agent 后，要确认 workspace、session store 和 secrets 是否隔离，避免一个群拿到另一个工作区上下文。
- 群聊上下文可能包含无关成员的消息。即便发送者被授权，引用、历史和媒体上下文也要按团队隐私规则处理。
常见坑
- 把私聊、群聊和多人协作都塞进同一种策略里，导致行为失控。
- 以为 routing 是“后面再优化”的事，结果前面所有使用数据都被噪声污染。
- 没有回看日志，最后只看到表层现象：为什么它今天又不回了。
- 把 Telegram 群组 ID 放进
groupAllowFrom，把用户 ID 放进groups。 - 多账户下没有显式 default，导致 fallback 路由选到第一个账号。
- 让所有群组进入默认 Agent，再试图靠系统提示词区分业务线。
完成检查
- 同一条消息是否会被处理、被忽略还是进入其他 Agent，你现在能提前预测。
- 你能解释
dmPolicy、groupPolicy、groups、groupAllowFrom、requireMention的边界。 - 多账户场景已经显式设置默认账号，或明确每条出站目标怎样选 account。
- 关键群组或账号已经用 bindings 指向正确 Agent，而不是全靠默认 Agent。
- 你至少用三条样本验证过：应处理消息、应拒绝消息、应进入另一个 Agent 的消息。
下一步内链
- 如果你还没接具体渠道，先看 OpenClaw WhatsApp 接入教程 或 OpenClaw Telegram 接入教程。
- 如果你的主要问题是群管理，继续看 OpenClaw Telegram 群聊设置。
- 如果你准备上线，继续看 OpenClaw 安全加固。
为什么建议把这篇收藏起来
- 这是把 OpenClaw 用“稳”的核心文章之一，不是锦上添花。
- 内容一旦做对，后面配 skills、automation、security 都会轻松很多。