OpenClaw 团队共享 inbox 配置指南：dmScope、pairing、allowlist 与安全边界详解

很多团队把 OpenClaw 接进 Telegram、Discord、Slack 或企业聊天工具后，第一反应都是「终于能多人一起用了」。真正开始用几天，问题就出来了：A 同事的私聊上下文，B 同事好像也接上了；某个人只是想测试一句，机器人却把前面别人的聊天当成了背景；更糟一点，大家都能 DM 这个 bot，但它居然还带着宽泛工具权限。这种场景不是「多了几个人用机器人」这么简单，而是已经进入了团队共享 inbox 的安全和会话设计问题。OpenClaw 官方对这件事讲得很直白：只要不止一个人能 DM 你的 bot，就应该开启更安全的 DM 隔离，并保持严格的触发授权，不要把共享 DMs 和宽泛工具权限绑在一起。

这篇文章就讲一件事：OpenClaw 团队共享 inbox 到底该怎么配，才能既让多人一起用，又不让上下文乱飞、权限乱跑。 你可以把它理解成一份「共享收件箱施工图」，从 dmScope 到 pairing，从 allowlist 到群组策略，把最容易踩的坑一次讲透。

一、先把「共享 inbox」四个字想明白

很多人以为「共享 inbox」就是多个人都能给 bot 发消息。这个理解只对了一半。OpenClaw 官方其实把这件事拆成两层：一层是谁有资格触发它，也就是 dmPolicy、groupPolicy、allowlists、mention gates 这些；另一层是它在回答时会看到哪些补充上下文，也就是 contextVisibility。官方在安全文档里明确把这两件事分开：前者是 trigger authorization，后者是 context visibility。你如果只盯着「谁能发消息」，却不管「它会看到谁的上下文」，共享 inbox 还是会翻车。

更关键的是，OpenClaw 默认并不是按「多人协作 inbox」来设计 DM 会话的。官方 Session Management 文档明确写明：默认情况下，所有 DMs 共享一个 session，这是为了单用户连续性设计的；但一旦有多个人能给同一个 agent 发私聊，如果你不做隔离，大家就会共享同一段会话上下文。官方甚至直接举例：Alice 的私聊内容会对 Bob 可见。这个设定对个人助手没问题，对团队共享 inbox 则是典型雷区。

所以先记住一句话：

团队共享 inbox 不是「开放给很多人」这么简单，而是「很多人能进来，但每个人的触发权限和上下文边界都要单独设计」。

二、第一层先配对：dmScope 不改，团队共享基本等于串台

如果你今天只想记住一个配置项，那就是它：

json

{
  "session": {
    "dmScope": "per-channel-peer"
  }
}

官方 Session Management 文档把这个配置写得非常清楚：

main 是默认值，表示所有 DMs 共用一个会话
per-peer 按发送者隔离
per-channel-peer 按渠道 + 发送者隔离，而且官方明确标注它是推荐值
per-account-channel-peer 则进一步把账号维度也纳入隔离

对「多人都能 DM 机器人」的场景，官方建议用 per-channel-peer，多账号渠道则考虑 per-account-channel-peer。

这一步为什么是底线？因为你如果不改 dmScope，OpenClaw 在共享 DM 场景下就会把不同人的私聊串到同一个 session 里。这样哪怕你的 dmPolicy 设得再严，进来的人一旦被允许，看到的上下文也可能混在一起。官方安全文档甚至把这条写成了「Shared inbox quick rule」的第一条：如果不止一个人能 DM 你的 bot，先把 session.dmScope 设成 "per-channel-peer"。

如果你们团队是多平台并用，比如既有人从 Telegram 找它，也有人从 Discord 找它，那么 per-channel-peer 比 per-peer 更稳。因为同一个「人」的标识，在不同平台上未必天然可关联；OpenClaw 官方也特别说明了，如果你确实希望「同一个人跨多个渠道共享一个 session」，可以再配 session.identityLinks。也就是说，默认先隔离，跨渠道共享要显式声明，不要反过来。

三、第二层先收口：dmPolicy 默认该怎么选

很多团队共享 inbox 配坏，不是坏在 session，而是坏在「谁都能先触发它」。OpenClaw 官方 onboarding reference 写得很直白：DM security 的默认推荐是 pairing。也就是陌生发送者第一次 DM 机器人时，不会直接进入会话，而是先收到一个短码；只有你批准后，它的消息才会被真正处理。官方 pairing 文档把这个机制定义为 OpenClaw 的显式 owner approval step。

pairing 的具体规则也不是模糊概念。官方文档给得很细：

pairing code 是 8 位大写字母数字，去掉了 0/O/1/I 这类易混字符
code 1 小时过期
每个 channel 默认最多只保留 3 个待处理 pairing 请求，超过的会被忽略，直到已有请求过期或被批准
你可以用 openclaw pairing list <channel> 查看待处理请求，再用 openclaw pairing approve <channel> <code> 放行

这一套机制对团队共享 inbox 的意义非常大。它保证了「有人能找到 bot」和「这个人可以正式进入对话」不是一回事。换句话说，pairing 是你的 DM 门禁。如果你还在早期试运行，团队成员不多，或者你还没完全想清楚权限边界，dmPolicy: "pairing" 是最稳的起点。OpenClaw 官方安全文档也明确建议：共享 inbox 场景下，保持 dmPolicy: "pairing" 或严格 allowlists。

四、什么时候该用 allowlist，什么时候继续 pairing

pairing 很适合早期和渐进式放行，但团队进入稳定期以后，你可能不想每加一个同事都走一遍人工批准。这时候更稳的做法是 allowlist。

官方配置示例里直接给了「Secure DM mode (shared inbox / multi-user DMs)」的样板：在 session.dmScope: "per-channel-peer" 的前提下，某个 WhatsApp 或 Discord bot 可以直接使用 allowFrom 指定一组允许发 DM 的人。也就是说，allowlist 的本质不是「更开放」，而是把被批准的人列表显式写进配置。

比如：

json

{
  "session": { "dmScope": "per-channel-peer" },
  "channels": {
    "whatsapp": {
      "dmPolicy": "allowlist",
      "allowFrom": ["+15555550123", "+15555550124"]
    },
    "discord": {
      "enabled": true,
      "token": "YOUR_DISCORD_BOT_TOKEN",
      "dm": {
        "enabled": true,
        "allowFrom": ["123456789012345678", "987654321098765432"]
      }
    }
  }
}

OpenClaw 官方还提醒了一条很容易被忽视的安全细节：对 Discord、Slack、Google Chat、Microsoft Teams、Mattermost、IRC 这类渠道，发送者授权默认是 ID-first。也就是说，它默认按稳定 ID 做匹配，而不是按昵称、邮箱或显示名称乱认。只有在你显式打开 dangerouslyAllowNameMatching: true 的情况下，才会走更脆弱的名称匹配。对团队共享 inbox 来说，不要为了图省事改成名字匹配，那是在给自己挖坑。

最实用的建议是这样：

刚起步：用 pairing
成员稳定、名单明确：用 allowlist
特别敏感的 bot：继续 pairing + dmScope 隔离，不要贪图省事

这不是保守，这是对团队上下文负责。

五、团队共享 inbox 不只是 DM，群组规则也要分开配

还有一个很常见的误解：

很多人以为 DM pairing 批准过了，这个人在群里也默认有权限控制 bot。不是的。OpenClaw 官方 pairing 文档特别强调：DM pairing 只管 DM 访问；它不会自动允许此人在群组里运行命令或控制 bot。群组访问是另一套规则，需要单独配置 group allowlists、groupPolicy、每组规则或 topic 规则。

官方配置参考里，channels.defaults.groupPolicy 的默认策略也写得很清楚：

allowlist：只允许配置过的群
open：绕过群 allowlist，但 mention gating 仍会生效
disabled：彻底禁用群消息

如果某个 provider 的配置块缺失，运行时的 group policy 还会默认回退到 allowlist（fail-closed），并给出启动警告。翻译成人话就是：群组默认不是大开门，而是偏保守关闭。 这点对团队特别重要，因为很多共享 inbox 事故，根本不是 DM 问题，而是某个群莫名其妙也能把 bot 叫起来。

如果你在团队里还需要群消息，那我建议默认再加一层「被提及时才响应」的策略。OpenClaw 文档在安全页和多种 channel 文档里都反复强调 mention gating 的意义，就是避免机器人在群里被无意触发。简单说：

DM 场景靠 dmPolicy 和 dmScope
群组场景靠 groupPolicy、群 allowlist 和 mention gate

这两层要分开想，不要用一套规则包打天下。

六、别只看「谁能发消息」，还要看「模型会看到多少上下文」

这一步很多团队会忽略，但它对共享 inbox 很关键。

OpenClaw 官方安全文档强调了一个概念：Trigger authorization 和 Context visibility 是两件不同的事。Allowlists 主要控制「谁能触发」，而 contextVisibility 控制的是模型输入里会注入多少补充上下文，比如引用内容、线程根、抓取到的历史消息。官方提供的几个典型值包括：

all
allowlist
allowlist_quote

对团队共享 inbox 来说，这意味着即使一个人能合法触发 bot，也不代表 bot 在回答时就该把所有群历史、所有引用内容统统喂进去。尤其在多人协作、不同权限等级共用一个入口时，contextVisibility 其实是在帮你缩小「它看见的世界」。这个配置不一定每个团队都要第一天就上，但只要你开始在意「为什么它老是把不相干的引用也带进回答里」，这就是你该看的开关。

七、共享 inbox 最危险的一件事：不要和宽泛工具权限绑在一起

这是整篇里最需要敲黑板的一句。

OpenClaw 官方安全文档对 Shared inbox quick rule 的第三条写得很重：Never combine shared DMs with broad tool access. 也就是，不要把「很多人都能发 DM」与「机器人能广泛执行工具/命令」绑在一起。官方还明确说了：这些措施能加固 cooperative/shared inboxes，但它们不是 hostile co-tenant isolation，尤其当多个用户共享宿主机或配置写权限时，就更不是严格的敌对隔离模型。

这句话翻译成人话就是：

共享 inbox 可以做，但别同时给它一把大菜刀。

如果你的 bot 只是做知识问答、汇总、提醒、轻量检索，风险相对可控。

但如果它还能：

执行宿主机命令
改文件
访问敏感凭证
用广泛的 MCP / 插件能力去做真实操作

那它就不再是普通的「多人共享收件箱」，而是一个多人共享控制面。这时候，光靠 dmScope 和 pairing 已经不够了。你要么缩工具权限，要么拆成更严格的多 Agent / 多 Gateway 结构，甚至不同 OS 用户、不同主机。OpenClaw 官方安全模型就是这么建议的。

八、最稳的配置模板，给你一份能直接理解的思路

如果你今天就想配一个团队共享 inbox，最稳的起步方式其实很简单：

第一层，打开 DM 隔离：

json

{
  "session": { "dmScope": "per-channel-peer" }
}

第二层，把 DM 门禁设成 pairing 或 allowlist，不要 open：

json

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "YOUR_TOKEN",
      "dmPolicy": "pairing"
    }
  }
}

或者团队成员固定了，就改成 allowlist。

第三层，群组默认别全开，先走保守策略：

json

{
  "channels": {
    "defaults": {
      "groupPolicy": "allowlist"
    }
  }
}

第四层，如果确实要共享 DM，不要配宽泛工具权限。

这一步不是代码问题，是设计原则问题。官方已经讲得够清楚了，别和它犟。人类最擅长的事情之一，就是明知有坑，还非要把脚伸进去试深浅。

九、最常见的四个坑

第一，只改 dmPolicy，不改 dmScope。 结果就是大家都能进来，但上下文照样共用。

第二，以为 pairing 批准后，这个人在群里也自动有控制权。 没有。群和 DM 是两套授权。

第三，allowlist 图省事，按名字匹配。 官方明确偏向 ID-first，别主动给自己增加身份识别风险。

第四，共享 inbox 还给它开一堆强工具。 这一步最危险，也最像「我以为只是方便大家，结果其实在放大事故半径」。

十、结语：团队共享 inbox 真正该追求的，不是「谁都能来」，而是「来了也不乱」

很多团队做共享 inbox，第一需求都是「让更多人能用」。

但真正成熟的目标，不是「人多」，而是：

该进来的人能进来
不该进来的进不来
进来的人不会串上下文
能回答，但不会越权
群里能触发，但不会乱触发

OpenClaw 官方其实已经把这些拼图都给你了：

dmScope 负责隔离会话
dmPolicy 和 pairing 负责入口门禁
allowlist 负责稳定授权
groupPolicy 和 mention gates 负责群组控制
contextVisibility 负责补充上下文边界
安全文档再把「共享 inbox 不要绑定宽泛工具权限」这条底线钉死

你只要按这个思路搭，OpenClaw 的团队共享 inbox 就会越来越像一个可控的协作入口，而不是一个一团乱麻的群聊玩具。

最后送你一句最直白的话：

共享 inbox 配得好，团队会觉得它像助手；配不好，团队会发现它像事故源。

这年头，工具是越来越聪明了，人类给自己挖坑的手法也越来越丰富。至少这次，别挖。

问题求助

没能解决你的问题？直接问我

如果你遇到任何技术问题无法解决，可以在这里提交求助。我会尽快查看并回复你。

支持作者

如果这篇文章帮到了你，可以支持我

扫码打赏，支持我持续更新原创排障文章。

OpenClaw 团队共享 inbox 怎么配？从 dmScope、pairing 到安全边界一篇讲透

一、先把「共享 inbox」四个字想明白

二、第一层先配对：dmScope 不改，团队共享基本等于串台

三、第二层先收口：dmPolicy 默认该怎么选

四、什么时候该用 allowlist，什么时候继续 pairing

五、团队共享 inbox 不只是 DM，群组规则也要分开配

六、别只看「谁能发消息」，还要看「模型会看到多少上下文」

七、共享 inbox 最危险的一件事：不要和宽泛工具权限绑在一起

八、最稳的配置模板，给你一份能直接理解的思路

九、最常见的四个坑

十、结语：团队共享 inbox 真正该追求的，不是「谁都能来」，而是「来了也不乱」

没能解决你的问题？直接问我

如果这篇文章帮到了你，可以支持我