在本地运行 AI 代理时，远程聊天入口是一个非常实用的功能。平时可以通过本机终端或网页后台操作，外出时则可以通过手机聊天软件临时发送指令，让 AI 代理执行查询、检查服务状态、处理项目任务，甚至进行一定程度的自动化操作。
不过，聊天软件本身并不是完全透明的通道。不同平台对机器人消息、官方账号、Webhook、API 调用方式都有不同限制。一次 OpenClaw 更新后的排查，正好暴露了 LINE 通道和 Telegram 通道之间的差异。
一、现象：后台能看到回复，但手机 LINE 收不到
OpenClaw 更新后，LINE 聊天通道出现了一个看起来比较奇怪的现象：
用户从 LINE 发送消息后，OpenClaw 能收到消息；网页管理后台也能看到 OpenClaw 生成了回复；但是手机 LINE 端却看不到回复内容。
从表面上看，这很容易让人怀疑是 OpenClaw 更新导致 LINE 插件异常，或者 Gateway、Webhook、认证密钥、KWallet、systemd 服务出了问题。尤其是在更新软件之后出现问题，人会自然地把故障和更新动作联系起来。
但进一步排查后，情况并不是这样。
OpenClaw 的通道状态显示，LINE 通道仍然处于 enabled、configured、running、works 等状态，说明通道本身并没有完全离线。问题集中在外发投递队列中：最近几条外发消息卡在 delivery queue，状态为 pending 或 failed，错误类似 partial delivery failure。也就是说，OpenClaw 内部已经完成了消息处理，但真正发送到 LINE 手机端的最后一步没有成功。
这种现象可以概括为：
- OpenClaw 入站接收正常；
- OpenClaw 内部会话和网页后台显示正常；
- 失败发生在 OpenClaw 向 LINE 发送回复的外发阶段；
- LINE 手机端收不到消息，并不代表 OpenClaw 没有生成回复。
二、真正根因：LINE 官方账号免费消息额度用尽
进一步查看 LINE Official Account 后台后，问题基本定性。后台显示：
Messages sent this month
Free messages sent: 200 / 200
这意味着当前 LINE 官方账号本月免费消息额度已经全部用完。
对于 LINE Official Account 的免费方案来说，每月可发送消息数量有限。达到上限后，继续通过 Messaging API 外发消息时，平台会拒绝发送。因此就会出现一种非常容易误判的状态：
OpenClaw 已经生成回复，网页后台也能看到回复，但 LINE 手机端收不到。
这并不是手机端缓存问题，也不是 LINE 登录异常，更不是 OpenClaw 完全坏掉。它只是说明消息已经被平台的月度额度限制拦截。
还有一个关键点：OpenClaw 的 LINE 外发路径里出现了 push message 相关迹象，而 LINE 的 push、broadcast、multicast 等类型通常会计入发送数量。相对而言，reply message 在某些场景下不计入同类发送额度，但这取决于 OpenClaw 插件是否实际使用了这种方式。当前观察到的行为更像是通过外发队列或 push 路径返回消息，因此会受到免费额度限制。
最终结论是：
OpenClaw 更新只是时间上碰巧接近问题暴露点，真正根因是 LINE 官方账号本月免费发送额度已经达到 200/200，导致后续回复无法送达手机端。
三、为什么 Telegram 更适合作为远程入口
在明确 LINE 限制后，远程聊天入口需要重新评估。OpenClaw 本体并没有每月 200 条这种限制，本机 TUI 和网页后台都可以继续正常使用。真正受限的是 LINE 官方账号的免费发送额度。
Telegram 则更适合作为个人远程控制入口，原因主要有三点。
第一，Telegram Bot 通常没有 LINE 这种每月 200 条免费消息的硬限制。它主要限制的是发送频率，而不是每月总量。对于个人私聊使用场景来说，一般远远达不到频率上限。
第二，Telegram Bot 默认可以使用 polling 模式。也就是说，OpenClaw Gateway 主动连接 Telegram API 拉取消息，不需要像 LINE webhook 那样依赖外部平台回调本机地址。这对本地运行的 AI 代理非常友好，通常不需要额外开放公网端口。
第三，Telegram Bot 的配置流程相对简单。只需要通过 BotFather 创建机器人，获取 bot token，然后用 OpenClaw 官方 CLI 添加 Telegram 通道即可。
因此，更合理的结构是：
本机 TUI / Web 后台：主入口
Telegram Bot：远程入口
LINE：备用或暂时停用
这样既保留了手机远程操作能力，又避免被 LINE 免费消息额度卡住。
四、Telegram Bot 的命名与隐私
创建 Telegram Bot 时，需要设置两个名字：
一个是显示名，例如：
Helper
另一个是公开 username，例如：
@xxxx_bot
这里需要注意：Telegram bot 的 username 是公开可见的。只要别人看到这个 bot、相关截图、转发消息或群聊记录，就可能看到这个 username。
因此，bot username 不适合使用过于个人化的信息，例如真实姓名、常用网名、住址相关词、服务器名、具体项目名等。比较稳妥的方式是使用中性、低辨识度的名称，例如：
private_helper_bot
local_helper_bot
quiet_helper_bot
desk_helper_bot
显示名可以稍微直观一些，方便自己识别；username 则应尽量低调，避免把 bot 和个人身份、服务器、项目直接绑定。
五、添加 Telegram 通道的安全操作流程
拿到 BotFather 生成的 token 后，不应该把 token 发到聊天软件、公开文档或截图中。这个 token 基本等同于 bot 的密码，泄露后别人可能控制这个 bot。
比较安全的做法是在本机终端中使用静默输入：
read -s TG_TOKEN
粘贴 token 后按回车。终端不会显示 token，这是正常现象。
然后使用 OpenClaw 官方 CLI 添加 Telegram 通道：
openclaw channels add --channel telegram --token "$TG_TOKEN"
添加成功后清除环境变量：
unset TG_TOKEN
这种方式比直接把 token 写在命令行里更安全，因为它可以减少 token 留在 shell history 中的风险。
添加完成后，如果 OpenClaw Gateway 是用户级 systemd 服务，可以重启服务：
systemctl --user restart openclaw-gateway.service
然后检查服务状态：
systemctl --user status openclaw-gateway.service --no-pager
openclaw channels status --channel telegram --probe
正常情况下，可以看到类似状态：
Telegram default: enabled, configured, running, mode:polling, bot:@example_bot, token:config, works
其中几个字段比较关键：
- enabled：通道已启用；
- configured：配置存在；
- running：通道运行中；
- mode:polling：使用轮询模式，不依赖公网 webhook；
- token:config：token 已被配置；
- works：Telegram token 和 bot 基本可用。
如果状态中出现 disconnected，也不一定代表失败。对于 Telegram polling 通道来说，刚启动时可能暂时显示 disconnected，只要 token 有效、works 正常，并且后续能收到消息，就不需要过度处理。
六、首次私聊需要 pairing 授权
Telegram Bot 添加完成后，需要在手机 Telegram 中打开刚创建的 bot，点击 Start，然后发送一条测试消息，例如：
你好，测试 OpenClaw Telegram 通道
第一次发送消息后，OpenClaw 可能不会立即正常回复，而是进入 pairing 授权流程。这是合理的安全设计，因为 OpenClaw 不应该让任何找到 bot 的人都能直接控制本机 AI 代理。
此时需要回到本机终端查看待批准请求：
openclaw pairing list telegram
如果出现配对码，例如：
ABCD1234
则批准该请求：
openclaw pairing approve telegram ABCD1234
批准后，再回到 Telegram 给 bot 发送测试消息：
现在能回复吗？
如果一切正常，OpenClaw 就可以通过 Telegram 正常回复。
七、如何查看已授权对象
OpenClaw 中的“授权”要分清楚两类：
第一类是真正的设备或节点授权，例如 Web UI、远程节点或其他设备。这类授权应该使用：
openclaw devices list
如果需要机器可读输出，可以使用：
openclaw devices list --json
第二类是 Telegram、LINE 这类聊天通道的私聊授权。openclaw pairing list telegram 主要用于查看当前待批准的 pairing 请求，而不是列出所有已经批准过的聊天用户。
已经批准过的 Telegram 私聊用户，通常会记录在 credentials 目录下的 allowFrom 文件中，例如：
cat ~/.openclaw/credentials/telegram-allowFrom.json
如果安装了 jq，可以更清楚地查看：
jq . ~/.openclaw/credentials/telegram-allowFrom.json
还可以检查当前命令 owner：
openclaw config get commands.ownerAllowFrom
这很重要。对于具有本机执行、SSH、服务器管理、自动化操作能力的 AI 代理来说，谁被授权为 owner，谁就可能拥有更高权限。Telegram bot 不应该开放给所有人。
八、不要把 Telegram Bot 设成公开控制入口
Telegram Bot 的安全边界必须明确。最危险的配置是让任何人都可以和 bot 私聊并触发 OpenClaw 操作。
类似下面这种开放策略应避免使用：
dmPolicy: open
allowFrom: ["*"]
如果 bot 被设置成公开可用，任何知道 bot username 的人都可能向它发送消息。对于普通聊天机器人来说，这也许只是骚扰风险；但对于连接了本机执行、SSH、服务检查、项目操作能力的 OpenClaw 来说，这可能直接变成系统安全风险。
更稳妥的方式是：
- 使用 pairing 模式；
- 只批准自己的 Telegram 账号；
- 必要时固定 allowlist；
- 不把 bot username 公开；
- 不把 token 写进博客、截图、日志或群聊；
- 不把 OpenClaw 远程入口做成公开服务。
九、LINE 与 Telegram 的定位差异
经过这次排查，可以比较清晰地看出 LINE 和 Telegram 作为 OpenClaw 远程入口的差异。
LINE 的优点是日常使用方便，尤其在日本环境中非常普及。但如果使用 LINE Official Account 免费方案，就会受到月度消息额度限制。对于频繁对话的 AI 代理来说，200 条消息很容易被耗尽。一旦额度用完，就会出现后台正常、手机端收不到回复的情况。
Telegram 的优点是 Bot API 更适合个人自动化和远程控制。它通常没有 LINE 这种月度免费消息总量限制，而且 polling 模式不需要额外开放公网端口。对于单人私聊 AI 代理来说，Telegram 更接近“足够自由”的远程入口。
但 Telegram 也不是完全没有限制。它仍然有频率限制，也仍然要受后端模型额度、API 计费、本机资源、OpenClaw 权限边界等因素影响。所谓“不限制聊天数量”，更准确地说，是“不再受 LINE 官方账号每月 200 条免费消息这种硬限制”。
十、最终结构建议
这次迁移后的推荐结构是：
本机终端 TUI：日常主入口
OpenClaw Web 后台：状态查看和管理
Telegram Bot：远程临时入口
LINE：备用或停用
这样的结构更符合本地 AI 代理的实际使用方式。
本机终端仍然是最可靠、最直接的入口；网页后台适合查看状态、检查会话和诊断问题；Telegram 则承担手机远程触发任务的角色。LINE 如果继续使用，需要接受免费额度限制，或者调整为低频备用通道。
十一、这次排查带来的经验
这次问题看似是软件更新导致的通道异常，但真正根因并不在 OpenClaw 更新本身，而在外部平台的消息额度限制。
排查这类问题时，不能只看“更新之后坏了”这个时间顺序，还要分层判断：
OpenClaw 是否收到消息？
OpenClaw 是否生成回复？
网页后台是否显示回复？
外发队列是否成功？
聊天平台是否拒绝发送？
平台额度是否用尽？
如果每一层都分开检查，就能避免把平台限制误判为本机服务故障。
最终结论可以概括为：
LINE 通道的问题，本质是官方账号免费消息额度用尽；Telegram 更适合作为 OpenClaw 的个人远程聊天入口；添加 Telegram 通道时，应使用官方 CLI、保护 bot token、启用 pairing 或 allowlist，并避免把 AI 代理开放给陌生人。