最近 Claude Code 出了 Channels功能。看到这个能力的时候，第一反应很直接：如果能把 Claude Code 部署到 NAS 上，再配一个 Telegram Bot，那么人在外面的时候，理论上就可以继续通过聊天窗口驱动 Claude Code 写代码、改配置、看日志，甚至推进一些简单的开发任务。
这个设想很有吸引力。兴致冲冲写镜像、搭梯子、接 Telegram，一顿操作猛如虎，最后发现只支持 claude.ai 登录，API Key 根本用不了，Fu*k……整体过程并不算复杂，容器可以起来，镜像也能跑，梯子也通了，离“可以远程 coding”似乎只差最后一步。
Channels require claude.ai authentication · run /login, then restart
遂放弃，也没有深究。
早上，事情又出现了一点新的可能性。
微信已经支持通过 OpenClaw 的方式接入。这个信息重新点燃了一点兴趣：既然 OpenClaw 那边已经把微信的扫码登录、长轮询、发消息这些基础能力跑通了，那么是不是有可能参考它的 SDK 和通信实现，在 Claude Code 这边做一个本地的 wechat-plugin，绕开前一晚 Telegram 那条路径里的限制？
于是第二轮尝试开始了。
这一次的思路不再是从头摸索，而是明确分成两部分：
1. 参考 Claude 官方 telegramchannel plugin 的结构，理解 Claude Code 侧期待什么样的插件形态2. 参考微信的 OpenClaw 实现，把微信侧的登录、消息拉取、消息发送能力迁移过来
从工程角度看，这个组合是成立的。Telegram 插件解决的是“Claude Code 如何接收和发送外部消息”，微信的 OpenClaw 实现解决的是“如何与微信 iLink 接口交互”。两者拼起来，理论上可以形成一个本地的 wechat-plugin。
于是很快做出了一个 local 的 weixin插件版本：补了插件目录结构，补了 server.ts，补了登录脚本，也尝试把它挂到本地 marketplace 或本地插件目录里，希望最终能够得到一个和 /telegram:configure类似的 /weixin:configure入口。
但是，真正跑起来之后，看到的依然是同样的那条限制：
Channels require claude.ai authentication · run /login, then restart
Fu*k^n……
前一晚还可以理解成“也许只是 Telegram 这条插件路径如此”，但当一个本地实现的微信插件也在同一个地方被拦下时，结论就变得很清楚：限制点不是某个平台的插件实现，而是 Claude Code 对 Channels这项能力本身的权限控制。
换句话说，只要还是走 Channels机制，不管外部平台是 Telegram 还是微信，不管插件是官方提供的还是本地自己实现的，最终都会进入同一个判断分支：当前会话是否具有 claude.ai登录态。如果没有，Channel 类能力就不会被放行。
到这里，问题就开始从“怎么接微信”转向“Channels 到底是怎么工作的”。
继续往下看之后，会发现 Channels的关键，并不只是一个“能发消息的插件”。它真正特别的地方在于：插件收到外部消息之后，可以把这条消息主动注入当前 Claude 会话。
这和普通的 skill 或 MCP 工具有根本区别。
普通 skill / MCP 的逻辑是：
• Claude 主动调用工具 • 工具去拉取消息、发送消息、读写状态 • 整个交互的发起方始终是 Claude
而 Channels的逻辑是：
• 插件常驻运行 • 外部平台来消息 • 插件把消息通过 notifications/claude/channel这类机制推入当前会话• Claude 在上下文里直接看到这条外部消息，再决定如何回复
这就是为什么 Telegram 的体验会像一个真正的聊天入口，而不是几个零散的工具命令。也正因为如此，Channels才被官方放在更严格的权限边界之内。它不是“多一个工具”，而是“多一个实时进入当前会话的外部入口”。
理解了这一点之后，很多看起来还能继续尝试的方案，其实也就没有那么成立了。
比如最自然的一个问题是：既然 Channels不通，能不能退一步，做成 skill？
答案是：可以做一部分，但整体体验会非常割裂。
如果只是做 skill，那么当然可以实现：
• /weixin:configure• /weixin:login• /weixin:pull• /weixin:send
甚至还可以维护本地状态、保存扫码信息、手动拉取最新消息、手动发送回复。从功能清单上看，似乎也没有差太多。
但真正的问题不在“能不能发”和“能不能收”，而在于“当前会话里能不能自然地处理消息”。
一旦不走 Channels，整个链路就会变成这样：
• 微信新消息先落在某个外部轮询器、队列或者本地收件箱 • Claude 只有在你主动执行某个 skill 或工具时，才会去读取这些消息 • 回复也不再是当前对话的自然延续，而是一次工具操作
从实现上说，这条路不是不能做；从体验上说，它已经不是“在微信里继续 coding”，而更像是“通过一组手动命令访问微信消息和发送回复”。两者之间，有一个非常明显的断层。
也正是因为这一点，继续往 skill 路线上深入，虽然可以做出一个功能上成立的方案，但整体感受会很割裂。消息不是实时进入上下文的，回复不是自然发生在当前会话里的，交互也不是连续的。这种方案当然可以作为工具存在，但和最初设想中的 Channels型体验，已经不是一回事了。
到这里，整件事的脉络也就比较清晰了。
这两轮尝试，一个从 Telegram 出发，一个从微信出发，最后都回到了同一个结论：
1. Channels是一个很有吸引力的能力，尤其适合把 Claude Code 搬到 NAS 上做远程开发入口2. 但这项能力并不是开放给任意运行环境的普通插件接口，它依赖 claude.ai认证体系3. Telegram 如此，微信亦如此；限制点不在平台，而在 Claude Code 对 Channels的控制4. 不走 Channels当然还能继续做，但方案会明显变得割裂，难以复现最初想要的那种“聊天窗口即开发入口”的体验
至于这件事后面还有没有继续做的价值，我觉得是有的。至少到目前为止，事情已经足够明确：
• 如果接受 claude.ai的登录体系，那就继续沿着Channels路径走• 如果坚持第三方 API 路线，那就应该尽早放弃“复刻 Channels 体验”的执念，转而考虑一个更工具化、更明确的消息桥接方案，类似 Agent-kit，基于 SDK 封装一层。
把消息通过 notifications/claude/channel这类机制接入也是一个很好的想法，后续开发可以参考。
Channels 简化流程
Channels 工作流
+-------------------+ 启动会话 +----------------------+
| 用户/CLI | -----------------------> | Claude Code |
| claude --channels | | 当前会话 / 主进程 |
+-------------------+ +----------+-----------+
|
| 读取插件 .mcp.json
v
+--------------------------+
| Channel Plugin 进程 |
| 例如 telegram/weixin |
| 常驻 MCP Server |
+------------+-------------+
|
长轮询 / webhook / bot API 连接外部平台
|
v
+--------------------------+
| 外部聊天平台 |
| Telegram / Weixin / ... |
+------------+-------------+
|
用户发消息 |
v
+--------------------------+
| Channel Plugin 进程 |
| 解析消息 / 鉴权 / 落附件 |
+------------+-------------+
|
| MCP 特殊通知
| notifications/claude/channel
v
+-------------------+ +--------------------------+
| 当前 Claude 对话 | <----------------------- | Claude Code |
| 看到 <channel...> | | 把消息注入当前会话 |
+---------+---------+ +------------+-------------+
| |
| 模型推理 | 工具调用
v v
+-------------------+ +--------------------------+
| Assistant 响应 | -----------------------> | reply / react / ... |
| 选择调用 reply 工具 | | 由插件暴露给 Claude |
+-------------------+ +------------+-------------+
|
| 发消息 API
v
+--------------------------+
| 外部聊天平台 |
+------------+-------------+
|
v
用户收到回复 