OpenClaw 社区渠道完整性评估：Mattermost、LINE、IRC、Nextcloud Talk、Nostr、Twitch、Tlon 与 Synology Chat 的八通道全景

2026-09-07 18:05:08作者：滕妙奇

OpenClaw 用统一的“Completeness（完整性）”评分框架衡量每个渠道表面对操作者承诺的能力是否闭环。本篇以 taxonomy.yaml 中 community-channels 表面的完整性评估 rubric 为主体，完整覆盖该表面下的 Mattermost、LINE、IRC、Nextcloud Talk、Nostr、Twitch、Tlon、Synology Chat 八个渠道，并逐条展开其在「渠道搭建与运维、访问与身份、会话路由与投递、媒体与富内容」四个评分维度上的具体能力、配置参数与实现依据，帮助你在评估或接入这些社区渠道时快速判断其能力边界与成熟度。

一、评估对象：community-channels 表面与 rubric 定位

这份 rubric 位于 .agents/skills/claw-score/references/completeness/mattermost-line-irc-nextcloud-talk-nostr-twitch-tlon-synology-chat.md，是 claw-score 技能在“为类别分配 Completeness 分数”时使用的标准文档。该技能管理三个权威文件：

taxonomy.yaml —— 手编的 source of truth，定义表面（surface）、类别、特性、coverageIds 与 completeness-instruction 路径；
qa/maturity-scores.yaml —— 提交版本，聚合 Quality、Completeness 与 LTS 评审状态；
QA 场景元数据 qa/scenarios/index.yaml，以及由 pnpm maturity:render 生成的 docs/maturity/scorecard.md 与 docs/maturity/taxonomy.md。

在 taxonomy.yaml 中，该表面的四个类别均挂载 community-channels.* 命名空间的 coverageIds（channel-setup-and-operations、access-and-identity、conversation-routing-and-delivery、media-and-rich-content），并在 YAML 中通过 completeness_instructions 字段指回本 rubric。按 SKILL.md 的默认完整性流程，Completeness 度量的是“预期的操作者可见工作流是否完整暴露给用户”，覆盖搭建、正常使用、状态检查、恢复与关键生命周期变体——而不是测试广度（那是 Coverage）或实现质量（那是 Quality）。

分数带（bands）为：Clawesome（95-100）、Stable（80-95）、Beta（70-80）、Alpha（50-70）、Experimental（0-50）。当类别支持完整工作流时应给高分；只有 happy path、重要变体缺失或恢复路径缺位时应降分。

二、四个评分维度与能力清单总览

rubric 的 Category Scope 部分为每个类别列出了跨八个渠道的能力清单，这里完整继承并归纳如下（原文档中各类别条目高度重叠，说明这些渠道共享同一套渠道生命周期模型）：

类别	覆盖的关键能力（原文档清单归纳）
Channel Setup and Operations	Mattermost bot 账号 + WebSocket 入站监听 + 出站投递；LINE Messaging API webhook 搭建、签名入站事件、富 LINE 载荷；Nextcloud Talk bot 安装、Webhook 接入、出站 markdown/text；Synology Chat 出入站 webhook 搭建、token 校验、出站文本；IRC 服务器/nick/TLS/NickServ 搭建、原始 IRC 收发、Probe/status；Twitch bot 账号、Twitch IRC 监听/客户端生命周期、message 工具发送；Nostr 密钥配置、NIP-04 加密 DM 收发、Profile 导入/发布；Tlon/Urbit ship URL/code 配置、Urbit API 认证/会话、富文本转换
Access and Identity	上述全部渠道的身份与访问控制面（DM 策略、allowlist、mention gating、账号隔离）
Conversation Routing and Delivery	会话路由、线程/回复投递、群聊 mention 门控、出站消息与目标寻址
Media and Rich Content	LINE 富载荷、Nextcloud Talk 出站 markdown/text、Synology 出站文本、Nostr 密钥/NIP-04/Profile、Tlon 富文本转换与媒体投递

下面按渠道逐一展开这四个维度的实际落地形态，所有配置项与行为均取自仓库渠道文档，可直接用于实操与评分取证。

三、Mattermost：WebSocket 全链路 + 原生斜杠命令

Mattermost 是 downloadable 插件（@openclaw/mattermost），基于 bot token + WebSocket 事件，支持频道、私有频道、群 DM 与 DM，见 docs/channels/mattermost.md。

Channel Setup and Operations。 安装后创建 bot 账号并拷贝 bot token 与 base URL（尾随 /api/v4 会被自动剥离）：

{
  channels: {
    mattermost: {
      enabled: true,
      botToken: "mm-token",
      baseUrl: "https://chat.example.com",
      dmPolicy: "pairing",
    },
  },
}

非交互式等价命令为 openclaw channels add --channel mattermost --bot-token <token> --http-url https://chat.example.com。自托管私有/LAN/tailnet 地址时，出站 API 请求经过 SSRF guard（默认拦截内网 IP），需以 channels.mattermost.network.dangerouslyAllowPrivateNetwork: true 显式开启。

原生斜杠命令是 opt-in：启用后 OpenClaw 会在 bot 加入的每个 team 上注册 /oc_status、/oc_model、/oc_models、/oc_new、/oc_help、/oc_think、/oc_reasoning、/oc_verbose、/oc_queue 等 oc_* 命令，并在 gateway HTTP 服务器上接收回调 POST（callbackPath 默认 /api/channels/mattermost/command）。回调通过注册时 Mattermost 返回的 per-command token 校验，OpenClaw 在接受每个回调前会刷新命令注册状态，旧 token 会失败关闭（fail closed）。可达性检查：对回调地址发 GET 应得到 405 Method Not Allowed 而非 404。

Access and Identity。 DM 默认 dmPolicy: "pairing"（未知发件人收到配对码，用 openclaw pairing approve mattermost <CODE> 批准）；群聊默认 groupPolicy: "allowlist"（mention-gated），allowFrom/groupAllowFrom 支持 accessGroup:<name> 静态访问组。@username 匹配仅在 dangerouslyAllowNameMatching: true 时启用。

Conversation Routing and Delivery。 chatmode 控制频道行为：oncall（默认，仅 @mention 响应）、onmessage、onchar（前缀触发，默认 [">", "!"]）。线程参与：bot 在某个频道线程中回复过之后，该线程后续消息无需再次 mention 即可继续（记忆 7 天并跨重启持久化），可用 implicitMentions.threadParticipation: false 关闭。replyToMode（off | first | all | batched）控制是否开线程；出站目标格式为 channel:<id>、#channel-name、user:<id>/mattermost:<id>、@username，裸 ID 有歧义时按 user-first 解析。DM 直连通道创建失败默认指数退避重试（dmChannelRetry：maxRetries 3、initialDelayMs 1000、maxDelayMs 10000、timeoutMs 30000）。

Media and Rich Content。 每条出站消息至多一个附件；mediaMaxMb 限制收发大小，未配置时入站保留 8 MiB 默认。流式预览默认 partial 模式（编辑同一草稿 post 后原位定稿）。交互按钮基于语义 presentation 载荷渲染为 Mattermost 交互按钮，点击回调使用 HMAC-SHA256 校验（密钥由 bot token 派生），外部脚本直连 API 时须遵循“attachments 放 props.attachments、action id 仅字母数字、context 递归排序键 + 紧凑 JSON 签名”等规则。

四、LINE：签名 webhook 与持久化入站队列

LINE 通过 LINE Messaging API 连接，插件运行在 Gateway 上作为 webhook receiver，支持 DM、群聊、媒体、位置、Flex 消息、模板消息与 quick replies；不支持 reactions 与线程，见 docs/channels/line.md。

Channel Setup and Operations。 在 LINE Developers Console 创建 Messaging API 渠道，拿到 Channel access token 与 Channel secret，启用 webhook 并指向 https://gateway-host/line/webhook（HTTPS 必需）。Gateway 会应答 LINE 的签名验证请求（events 为空的 POST）；签名校验是 body 依赖的（对原始 body 做 HMAC），因此 OpenClaw 在验证前施加严格的 pre-auth body 限制（64 KB）与读超时，且只处理经校验的原始请求字节。

LINE 的入站持久化是该渠道最重的工程细节：事件只有在 durable 入队后才应答 200（响应头带 x-openclaw-delivery-accepted: durable，供反向代理区分 durable 接受与普通 200）。按会话 lane（group:<id>/room:<id>/user:<id>）串行化投递，全局 8 并发上限；失败按指数退避重试（1 秒起步、8 次后 dead-letter，retry-limit-exceeded）；invalid-event、delivery-side-effects-committed、authentication-failed 三类失败不重试直接死信；5 分钟 stall watchdog 回收卡死投递；每次入队前剪除 30 天以上及超额（每类每账号 4096 条）的完成/失败记录，构成重复抑制窗口。

Access and Identity。 最小配置 channelAccessToken + channelSecret，DM 默认 pairing（openclaw pairing approve line <CODE>）。LINE ID 区分大小写且格式严格：用户 U+32 位 hex、群 C+32 位 hex、房间 R+32 位 hex。引用 bot 自己的消息视为提及（implicitMentions.quotedBot 可关）。

Media and Rich Content。 这是 rubric 中“Rich LINE payloads”的落点：buttons 块渲染为 Flex 控件，select 块渲染为 quick replies（单消息最多 13 个，跨块累计）；LINE 专属输出走 channelData.line（经 schema 校验），支持 location 与 media_player/event/agenda/device/appletv_remote 五类卡片；文本按 5000 字符分块，markdown 剥离、代码块与表格尽量转 Flex 卡片。出站媒体必须是公共 HTTPS URL（≤2000 字符），OpenClaw 会拒绝 loopback/link-local/私网目标。

五、IRC：经典频道、NickServ 与两层门控

docs/channels/irc.md 描述的 IRC 插件覆盖 rubric 中“IRC server/nick/TLS/NickServ setup、Raw IRC receive/send、Probe/status”三条能力。

Channel Setup and Operations。 最小配置：

{
  channels: {
    irc: {
      enabled: true,
      host: "irc.example.com",
      port: 6697,
      tls: true,
      nick: "openclaw-bot",
      channels: ["#openclaw"],
    },
  },
}

连接参数表（默认值）：port TLS 时 6697 / 明文 6667；tls 默认 true；username 回退 nick 再回退 openclaw；realname 默认 OpenClaw；password/passwordFile 为服务器密码（文件须为普通文件）。多账号支持 accounts/defaultAccount；hybrid 重载模式下增改非默认命名账号只重启该账号。入站持久化方面，每条被接受的 PRIVMSG 先写入 durable ingress 队列；由于 IRC 无重放 ID，本地 ID 仅在当前 TCP 连接内稳定，队列保护的是“接受到派发”窗口，无法恢复断连期间错过的消息。

Access and Identity。 IRC 有两道独立门：频道准入（groupPolicy + groups）与发件人准入（groupAllowFrom/groups["#channel"].allowFrom）。常见陷阱是 allowFrom 只管 DM 不管频道。allowlist 条目应使用稳定身份 nick!user@host；裸 nick 匹配仅在 dangerouslyAllowNameMatching: true 时启用。公共频道建议叠加 tools/toolsBySender 工具策略（后者按键值 id:、channel: 等显式前缀匹配，首个命中生效，"*" 为通配回退）。

Conversation Routing and Delivery。 mention gating 默认开启，日志中出现 missing-mention 即此原因；requireMention: false 可放开。出站文本把 Markdown 转为纯文本（保留代码内容与链接目的地），渲染后再按 textChunkLimit/streaming.chunkMode 切分，socket 层再强制 IRC 行大小上限。CLI 直发：openclaw message send --channel irc --target '#openclaw' --message 'Hello'。

NickServ。 设置密码后连接时默认执行 IDENTIFY：

{
  channels: {
    irc: {
      nickserv: {
        enabled: true,
        service: "NickServ",
        password: "your-nickserv-password",
      },
    },
  },
}

register: true（需 registerEmail）用于一次性注册，注册完成建议关闭。环境变量支持 IRC_HOST、IRC_PORT、IRC_TLS、IRC_NICK、IRC_USERNAME、IRC_REALNAME、IRC_PASSWORD、IRC_CHANNELS、IRC_NICKSERV_PASSWORD、IRC_NICKSERV_REGISTER_EMAIL（仅默认账号；IRC_HOST 不能来自 workspace .env）。

六、Nextcloud Talk：Talk webhook bot 与 HMAC 签名

Nextcloud Talk 是 downloadable 插件 @openclaw/nextcloud-talk，通过 Talk webhook bot 连接自托管 Nextcloud；支持 DM、房间、reactions 与 markdown 消息，媒体以 URL 形式出站，见 docs/channels/nextcloud-talk.md。

Channel Setup and Operations。 服务端用 occ 安装 bot：

./occ talk:bot:install "OpenClaw" "<shared-secret>" "<webhook-url>" --feature webhook --feature response --feature reaction

--feature response 必须保留，否则出站回复 401。OpenClaw 侧最小配置为 baseUrl + botSecret（或环境变量 NEXTCLOUD_TALK_BOT_SECRET，仅默认账号），也可 openclaw channels add --channel nextcloud-talk --url <url> --token <secret>（nc-talk/nc 为渠道别名，支持 --secret-file 文件密钥）。webhook 请求以 bot secret 做 HMAC-SHA256 签名，无效签名被拒绝并限流；消息 webhook 仅在原始事件 durable 存储后才返回 200（带 x-openclaw-delivery-accepted: durable 标记），存储失败返回 500。

Access and Identity。 DM 默认 pairing（openclaw pairing approve nextcloud-talk <CODE>）；allowFrom 只匹配小写化的 Nextcloud 用户 ID，忽略显示名。房间（群）默认 groupPolicy: "allowlist" 且 mention-gated，按 room token 键控：

{
  channels: {
    "nextcloud-talk": {
      rooms: { "room-token": { requireMention: true } },
    },
  },
}

每个房间键支持 requireMention（默认 true）、enabled、allowFrom、tools、skills、systemPrompt。

Conversation Routing and Delivery 与 Media。 关键限制：bot 不能主动发起 DM（须用户先发消息）；webhook 载荷不区分 DM 与房间，需配置 apiUser+apiPassword 才启用房间类型查询（约 5 分钟缓存），否则一律按房间处理；出站媒体不支持上传，以 Attachment: <url> 行追加。配置参考含 webhookPort（默认 8788）、webhookHost（默认 0.0.0.0）、webhookPath（默认 /nextcloud-talk-webhook）、textChunkLimit（默认 4000 字符）、replyToMode（默认 all）、markdown.tables（off | bullets | code | block）、historyLimit/dmHistoryLimit 与私网 SSRF 开关 network.dangerouslyAllowPrivateNetwork。能力矩阵：DM/房间/reactions 支持，线程不支持，媒体 URL-only，无原生命令。

七、Nostr：NIP-04 加密 DM 与 Profile 发布

Nostr 插件 @openclaw/nostr 让 OpenClaw 通过 relay 收发 NIP-04 加密 DM；每 gateway 一个账号，仅 DM，见 docs/channels/nostr.md。这对应 rubric 中“Nostr key setup、NIP-04 encrypted DM receive/send、Profile import/publish”三条。

Channel Setup and Operations。 生成密钥对（如 nak key generate）后配置：

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
    },
  },
}

非交互式：openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY" --relay-urls "wss://relay.damus.io,wss://relay.primal.net"；--use-env 可把密钥留在环境变量中。配置参考：privateKey（nsec 或 64 位 hex，支持 secret 引用）、relays（默认 relay.damus.io 与 nos.lol，建议 2-3 个冗余）、dmPolicy（默认 pairing）、allowFrom（sender pubkeys）、profile（NIP-01 元数据）。

Profile import/publish。 profile 以 NIP-01 kind:0 事件发布，可在 Control UI（Channels → Nostr → Profile）管理或直接写配置（name、displayName、about、picture、banner、website、nip05、lud16）；URL 必须 https://，从 relay 导入时合并字段并保留本地覆盖。

Access and Identity 与安全顺序。 强制顺序值得注意：入站事件先验签（sender 策略与 NIP-04 解密之前），再执行 sender 策略，最后才解密——伪造事件被早期拒绝，未知发件人无法迫使完整加密计算。入站按全局与每发件人限流，超大载荷在解密前丢弃；配对回复不解密原文。协议支持：NIP-01、NIP-04 已支持，NIP-17（gift-wrapped DM）与 NIP-44 计划中。本地可用 docker run -p 7777:7777 ghcr.io/hoytech/strfry 起 relay 测试，重复回复在多 relay 下由事件 ID 去重。

八、Twitch：IRC 监听、客户端生命周期与 token 刷新

Twitch 插件（@openclaw/twitch）基于 Twurple 客户端走 Twitch chat (IRC) 接口，bot 以自有账号登录并加入一个配置频道，见 docs/channels/twitch.md。要求 OpenClaw 2026.4.10 或更新版本。

Channel Setup and Operations。 用 Twitch Token Generator 生成 Bot Token（scope chat:read+chat:write），最小配置：

{
  channels: {
    twitch: {
      enabled: true,
      username: "openclaw",
      accessToken: "oauth:abc123...",
      clientId: "xyz789...",
      channel: "yourchannel",
      allowFrom: ["123456789"],
    },
  },
}

username 是认证账号，channel 是加入的聊天室；每个账号条目恰好加入一个频道，多频道需多账号（channels.twitch.accounts + defaultAccount）。token 有无 oauth: 前缀均可（自动归一化）。Token 刷新：Token Generator 的 token 不可刷新；自建应用并配置 clientSecret+refreshToken 后插件会在过期前自动续签并记录每次刷新；缺 refreshToken 记录 token refresh disabled (no refresh token)。

Access and Identity。 allowFrom 是 Twitch 用户 ID 的硬 allowlist（用户名可变、ID 永久），设置后 allowedRoles 被忽略；角色可选 moderator、owner、vip、subscriber、all。requireMention 默认 true。

Conversation Routing and Delivery。 确定性路由：回复总是回到消息来源的 Twitch 频道，每个加入的频道映射到隔离的 group session key agent:<agentId>:twitch:group:<channel>。入站持久化：每条被接受的消息先 durable 入队并保留重启后的重试能力，用 Twitch message ID 抑制重复。agent 通过 message 工具 send action 发 #channel 目标消息。限制：单条 500 字符（按词边界分块）、Markdown 剥离（换行变空格）、无自带限流（由 Twurple 客户端处理 Twitch 限流）。

九、Tlon/Urbit：ship 认证、群授权与 Owner 审批流

Tlon 是内置（bundled）插件，连接你的 Urbit ship，支持 DM、群 mention、线程、富文本、图片上传/下载与 owner 审批体系；不支持 reactions 与 polls，见 docs/channels/tlon.md。对应 rubric 的“Tlon/Urbit ship URL/code setup、Urbit API auth/session、Rich text conversion”。

Channel Setup and Operations。

{
  channels: {
    tlon: {
      enabled: true,
      ship: "~sampel-palnet",
      url: "https://your-ship-host",
      code: "lidlut-tabwed-pillex-ridrup",
      ownerShip: "~your-main-ship",
    },
  },
}

等价 CLI：openclaw channels add --channel tlon --ship ~sampel-palnet --url https://... --code ...。私网/LAN ship 默认被 SSRF guard 拦截，需 network.dangerouslyAllowPrivateNetwork: true（旧扁平键 allowPrivateNetwork 已弃用，openclaw doctor --fix 自动迁移）。

Access and Identity 与 Owner 审批。 DM 由 dmAllowlist 控制（空 = 除 owner 外无人可 DM）；群授权默认 restricted，defaultAuthorizedShips 提供基线，authorization.channelRules 按频道 nest 覆盖（mode: "restricted"|"open" + allowedShips）。设置 ownerShip 后，未授权请求不被丢弃而是进入待审批队列并 DM owner，owner 用 approve/deny/block/unblock ~ship/blocked/pending 等回复处理。自动接受：autoAcceptDmInvites（针对 dmAllowlist）、autoAcceptGroupInvites+groupInviteAllowlist（空 allowlist 时 fail closed，非 owner 邀请全部拒绝）。

Conversation Routing and Delivery。 groupChannels 手动钉住频道，autoDiscoverChannels: true 时启动期 scrie 已加入群、监听新邀请、每 2 分钟复查。bot 在某线程回复过一次后，后续线程消息无需再次 mention（implicitMentions.threadParticipation: false 可关）。线程回复附带最近 10 条线程上下文；“summarize this channel”类请求触发内置历史摘要而非普通回复。配置还会镜像到 ship 的 %settings agent（desk moltbot、bucket tlon）实现热重载，无需重启 gateway。插件同时捆绑 tlon-skill，提供 Activity/Channels/Contacts/Groups/Hooks/Messages/DMs/Posts/Notebook/Settings 的 CLI 操作。出站目标：DM 用 ~sampel-palnet 或 dm/~sampel-palnet，群用 chat/~host-ship/channel 或 group:~host-ship/channel。媒体受 mediaMaxMb 约束（图片下载/上传存在 6 MiB 上限）。

十、Synology Chat：双向 webhook 对与出站托管附件

Synology Chat 通过 webhook 对连接：outgoing webhook 把入站 DM POST 给 Gateway，回复经 incoming webhook 回传；官方插件 @openclaw/synology-chat，仅支持 DM，支持文本与托管文件发送，见 docs/channels/synology-chat.md。

Channel Setup and Operations 与 token 校验。 在 Synology Chat 集成页创建 incoming webhook（拷贝 URL）与 outgoing webhook（设 secret token），把 outgoing webhook URL 指向 Gateway（默认 https://gateway-host/webhook/synology），并把这个公网 URL 记为 webhookUrl（供 NAS 拉取托管附件）。CLI：openclaw channels add --channel synology-chat --token <token> --url <incoming-webhook-url> --webhook-url <public-outgoing-webhook-url>。入站 token 依次从 body.token、?token=...、x-synology-token/x-webhook-token/x-openclaw-token/Authorization: Bearer 中接受；空或缺失 fail closed；载荷可为 form-urlencoded 或 JSON，token、user_id、text 必填。token 校验用常量时间比较，反复无效尝试会临时锁定来源 IP；入站文本按已知 prompt-injection 模式清洗并在 4000 字符处截断；每发件人限流 rateLimitPerMinute（默认 30）。

Access and Identity。 dmPolicy 支持 allowlist（默认）、open、disabled——没有 pairing 流程，发件人以数字 Synology 用户 ID 加入 allowedUserIds。allowlist 模式下空 allowlist 视为配置错误，webhook 路由不启动；open 需 allowedUserIds: ["*"] 才完全开放。回复接收方默认绑定稳定数字 user_id，dangerouslyAllowNameMatching: true 是 break-glass 的可变用户名回退。

Media and Rich Content（URL 媒体投递）。 出站文本按 2000 字符分块。附件走 OpenClaw 托管模式：源文件在受控出站媒体策略下加载、字节冻结在 plugin-scoped SQLite 中，NAS 只拿到带 10 分钟有效期的不透明 HTTPS capability URL（每账号至多 4 个并发附件响应、128 MB/分钟、停滞 2 分钟关闭；不宣告 byte-range）。安全头为 Content-Disposition: attachment、X-Content-Type-Options: nosniff、Cache-Control: no-store；声明或命名为 HTML/SVG/XML 的文件被拒绝，冻结字节若以 UTF-8/16/32 标记文档开头同样被拒。文件上限 32 MB。webhookUrl（公网回调，OpenClaw 绝不从 Host/X-Forwarded-* 推导）、webhookPath（Gateway 内部路由）、incomingUrl（反向，OpenClaw 回复用）三者角色不同；缺 webhookUrl 时收发文本正常，仅附件发送以可操作错误失败。多账号下每个启用账号须有独立 webhookPath（重复路径 fail closed 拒绝）。环境变量：SYNOLOGY_CHAT_TOKEN、SYNOLOGY_CHAT_INCOMING_URL、SYNOLOGY_NAS_HOST、SYNOLOGY_ALLOWED_USER_IDS、SYNOLOGY_RATE_LIMIT、OPENCLAW_BOT_NAME（配置值优先；后两项不能来自 workspace .env）。

十一、跨渠道共性：评估时的“能力闭环”检查点

把这八个渠道放回 rubric 的四个类别，可以看出 OpenClaw 社区渠道共享一套“能力闭环”模板，这也是 Completeness 评分时的通用核对点：

Setup：plugin 安装（openclaw plugins install 或内置）→ bot 账号/凭据 → 最小 JSON5 配置 → gateway 启动；每个渠道都有 openclaw channels add 非交互路径与仅默认账号生效的环境变量通道。
Identity/Access：DM 侧除 Synology（allowlist-only）与 Nostr/Tlon（allowlist/pairing）外普遍提供 pairing 默认；群/房间侧统一 groupPolicy（allowlist/open/disabled）+ 每群键控覆盖（requireMention、allowFrom、tools、skills、systemPrompt）；mutable 名称匹配一律由 dangerouslyAllowNameMatching 显式开启。
Routing/Delivery：入站持久化队列（LINE、IRC、Twitch、Tlon、Synology 均有 durable ingress 描述）+ mention gating + 线程/会话路由 + CLI/agent 双出站（openclaw message send 与 message 工具 send action）。
Media/Rich：各渠道媒体上限（mediaMaxMb）、markdown→平台格式转换（IRC 纯文本、Nextcloud markdown.tables、Twitch 剥离、Tlon 原生格式、LINE Flex/quick reply、Mattermost 交互按钮）。

若你要按 SKILL.md 刷新该表面的分数，流程是：读 taxonomy.yaml 中该表面条目 → 读本 rubric → 收集 docs/源码/测试/QA 场景的公开证据（优先 release profile 的 qa-evidence.json 工件）→ 仅依据公开或脱敏证据更新 qa/maturity-scores.yaml 的 Quality/Completeness/LTS 评审状态 → 用技能中的 node+tsx 校验命令验证 taxonomy 与成熟度 schema，必要时跑 pnpm openclaw qa coverage --json 与 pnpm check:docs。