Signal 渠道接入重点

在 OpenClaw 支持的聊天入口里，Signal 是一个很特别的渠道。它不像 Telegram 那样更偏 bot token，也不像 WhatsApp 那样更像 Web session，而是明确围绕 signal-cli 和账号设备模型工作。对中文用户来说，Signal 最大的吸引力通常是隐私，但也正因为它更“偏系统化”，接入与运维成本会比看上去更高。

Signal 在 OpenClaw 里是什么

官方当前把 Signal 定义为 signal-cli 集成：

• Gateway 通过 signal-cli 工作
• 通常走 HTTP JSON-RPC + SSE
• 默认 DM 策略是 pairing

这意味着它不是内建 SDK 式集成，而更像“OpenClaw 驱动一个外部渠道进程”。

为什么官方反复强调 dedicated number

Signal 文档里最关键的一点不是命令，而是号码模型。

官方明确建议：

• 最好给 bot 使用单独号码
• 不要直接拿你自己长期使用的个人主号来跑

原因很直接：

• Signal 的账号和设备关系更紧
• 注册或链接流程可能影响原有 app 会话
• 如果 bot 和你本人共用一个身份，loop protection 和行为边界都更容易出问题

所以 Signal 不是那种“顺手拿自己账号试试”的最佳渠道。

两条常见接入路径

1. Link 现有设备

适合：

• 你熟悉 Signal 账号和设备模型
• 你知道自己在管理什么

2. 用 SMS 注册 dedicated bot number

适合：

• 想把 bot 和个人主账号彻底隔离
• 长期运行、长期维护

官方也明确提醒，SMS 注册路径通常需要验证码、captcha 和更完整的账号准备流程。

为什么 Signal 更像“运维型渠道”

相比 Telegram，这里你需要额外考虑：

• signal-cli 的安装方式
• 账号注册或链接
• daemon 模式与 startup timeout
• 号码、UUID、allowFrom 的表达方式

所以它虽然隐私特征明显，但更适合“知道自己为什么要用它”的人，而不是纯粹第一天上手用来试水。

Pairing 在 Signal 里更重要

Signal 默认 DM 策略就是 pairing，这很合理。因为它本身更偏私人通信入口，一旦开放过宽，风险会非常直接。

官方当前的做法是：

• 未知发送者先拿到 pairing code
• 代码 1 小时过期
• 通过 openclaw pairing approve signal <CODE> 显式放行

也就是说，Signal 不是默认开放给所有人的入口。

群聊策略为什么要更保守

Signal 文档里同样区分了：

• dmPolicy
• groupPolicy
• groupAllowFrom

这意味着群聊和私聊不应共用一套入口规则。尤其在 Signal 这种更偏私密通信的渠道里，群组一旦开得过宽，问题会比 Telegram 群聊更难收拾。

Signal 的特殊点：号码与 UUID

Signal 允许通过：

• E.164 电话号码
• uuid:<id>

做 allowlist 和身份识别。对中文用户来说，这意味着它不像 Telegram 可以更直观地靠 username 思考，而是更接近“实名设备和通信身份”模型。

Signal 更适合什么场景

• 对隐私和通信边界敏感
• 想让 OpenClaw 进入更私密的个人/小团队通信流
• 能接受 signal-cli 和账号运维成本

如果你只是想“先有一个能聊的渠道”，Telegram 或 WebChat 往往更轻。

常见误区

1. 直接用个人主号跑 bot

短期看省事，长期最容易带来会话和身份混乱。

2. 只看 Signal 隐私，不看 signal-cli 运维

隐私是卖点，但 signal-cli 仍然是一层额外系统依赖。

3. 以为私密渠道就可以放宽配对

恰恰相反，它更应该保守。

更适合的接入顺序

1. 先跑通 Gateway 和最小聊天入口
2. 明确是否真的需要 Signal 这一类隐私通信渠道
3. 准备 dedicated number
4. 配好 signal-cli
5. 先私聊 pairing，再考虑群聊策略

下一步推荐

• 想理解整体渠道地图：看 OpenClaw 渠道能力概览
• 想看 pairing 细节：看 配对审批与设备授权管理
• 想理解长期运维：看 Gateway 运维与日常检查