微信扫码
添加专属顾问
我要投稿
探索Claude Code的Channels功能,尝试绕过限制实现远程编程的曲折历程。核心内容: 1. 通过Telegram Bot实现远程编程的尝试与失败 2. 转向微信OpenClaw方案的二次尝试 3. 两次尝试都遇到的claude.ai认证限制问题
最近 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 那条路径里的限制?
于是第二轮尝试开始了。
这一次的思路不再是从头摸索,而是明确分成两部分:
telegramchannel plugin 的结构,理解 Claude Code 侧期待什么样的插件形态从工程角度看,这个组合是成立的。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 的逻辑是:
而 Channels的逻辑是:
notifications/claude/channel这类机制推入当前会话这就是为什么 Telegram 的体验会像一个真正的聊天入口,而不是几个零散的工具命令。也正因为如此,Channels才被官方放在更严格的权限边界之内。它不是“多一个工具”,而是“多一个实时进入当前会话的外部入口”。
理解了这一点之后,很多看起来还能继续尝试的方案,其实也就没有那么成立了。
比如最自然的一个问题是:既然 Channels不通,能不能退一步,做成 skill?
答案是:可以做一部分,但整体体验会非常割裂。
如果只是做 skill,那么当然可以实现:
/weixin:configure/weixin:login/weixin:pull/weixin:send甚至还可以维护本地状态、保存扫码信息、手动拉取最新消息、手动发送回复。从功能清单上看,似乎也没有差太多。
但真正的问题不在“能不能发”和“能不能收”,而在于“当前会话里能不能自然地处理消息”。
一旦不走 Channels,整个链路就会变成这样:
从实现上说,这条路不是不能做;从体验上说,它已经不是“在微信里继续 coding”,而更像是“通过一组手动命令访问微信消息和发送回复”。两者之间,有一个非常明显的断层。
也正是因为这一点,继续往 skill 路线上深入,虽然可以做出一个功能上成立的方案,但整体感受会很割裂。消息不是实时进入上下文的,回复不是自然发生在当前会话里的,交互也不是连续的。这种方案当然可以作为工具存在,但和最初设想中的 Channels型体验,已经不是一回事了。
到这里,整件事的脉络也就比较清晰了。
这两轮尝试,一个从 Telegram 出发,一个从微信出发,最后都回到了同一个结论:
Channels是一个很有吸引力的能力,尤其适合把 Claude Code 搬到 NAS 上做远程开发入口claude.ai认证体系Channels的控制Channels当然还能继续做,但方案会明显变得割裂,难以复现最初想要的那种“聊天窗口即开发入口”的体验至于这件事后面还有没有继续做的价值,我觉得是有的。至少到目前为止,事情已经足够明确:
claude.ai的登录体系,那就继续沿着 Channels路径走把消息通过 notifications/claude/channel这类机制接入也是一个很好的想法,后续开发可以参考。
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
用户收到回复
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-03-22
Google Gemini深度集成Workspace体验
2026-03-22
专访OpenAI首席科学家:我们离“AI自己做研究”有多远?
2026-03-21
编程选GPT-5.4,还是GPT-5.3-Codex?
2026-03-21
AI Coding前端实践后的复盘总结
2026-03-21
OpenAI 首席科学家:Codex 只是雏形,我们要造的是「全自动 AI 研究员」
2026-03-21
谷歌Stitch「氛围设计」干崩Figma 8.8%股价:十年经验,败给巨头一次更新(附实测)
2026-03-21
为什么 CLI 比 MCP 更适合 LLM
2026-03-21
渐进式披露(Progressive Disclosure):Agent 从 Demo 到企业级落地的 “救命架构”
2026-01-24
2026-01-10
2026-01-01
2026-01-26
2026-01-09
2026-01-09
2026-01-23
2025-12-30
2026-01-14
2026-01-21
2026-03-22
2026-03-21
2026-03-20
2026-03-19
2026-03-19
2026-03-19
2026-03-18
2026-03-17