Channels 和云端会话、Remote Control 有什么区别？

方向和载体都不同：云端会话是在新的云沙箱里跑任务（从 GitHub 克隆）；Remote Control 是你从手机驱动本地会话；Channels 是外部事件被推进你已经开着的本地会话——文件已打开、调试上下文还在。官方对比表的定位一句话：Channels 填补的是「非 Claude 来源的事件进入进行中会话」这个空档。

人不在、终端关了还能收到事件吗？

不能——事件只在会话开着时到达。想要 always-on，官方建议把 Claude 跑在后台进程或常驻终端里。这也是它和 Routines 的分工：Routines 是云上按触发器新起会话，Channels 是本机现有会话收推送，两者互补不互替。

任何人给我的 bot 发消息都能指挥 Claude 吗？

默认不能，且官方流程强制你收紧：Telegram/Discord 配对后要执行 /telegram:access policy allowlist 锁定只有你的账号能发；iMessage 默认只放行你自己的 Apple ID（自聊免配置），放行他人要显式 /imessage:access allow +号码。构建自定义渠道时，发送者门禁（sender gating）是参考文档里的契约组成部分。

需要什么前置条件？

三条：Anthropic 认证（claude.ai 登录或 Console API key，Bedrock/Vertex/Foundry 不可用）；预构建插件是 Bun 脚本所以要装 Bun；Team/Enterprise 组织需管理员显式启用。研究预览阶段包含 Telegram、Discord、iMessage 三个官方插件，另有跑在 localhost 的 fakechat 演示渠道供零配置试玩。

Claude Code Channels 实战（2026）：把 Telegram、CI 告警推进正在跑的会话

它填的空档：事件找会话，而不是会话找事件

官方对比表把几个「连接外部」的功能摆在一起，Channels 的独特性一眼可见：

功能	做什么	适合
云端会话	在全新云沙箱跑任务（GitHub 克隆）	可自包含的异步委派
Claude in Slack	@Claude 提及即起一个网页会话	从团队对话现场发起任务
普通 MCP	Claude 任务中主动查询，无推送	按需读外部系统
Remote Control	你从 claude.ai / 手机驱动本地会话	离开工位时接管进行中会话
Channels	外部事件推进已运行的本地会话	CI / 告警 / 聊天到达调试现场

两个典型形态：

聊天桥：Telegram 里问「重构跑完了吗」，Claude 在你电脑上查完从同一个聊天回你——你在终端里能看到消息进来和工具调用确认，回复正文只出现在对方平台。
Webhook 接收器：CI 挂了、错误追踪器报警，事件直接落进你已经打开相关文件、还记得刚才在查什么的那个会话。

15 分钟接入 Telegram

# 1. BotFather 里 /newbot 建 bot，拿 token
# 2. Claude Code 里装插件（user 作用域）
/plugin install telegram@claude-plugins-official

# 3. 配 token（存到 ~/.claude/channels/telegram/.env）
/telegram:configure <token>

# 4. 重启并启用渠道
claude --channels plugin:telegram@claude-plugins-official

# 5. 给 bot 发任意消息拿配对码，回终端配对并锁门
/telegram:access pair <配对码>
/telegram:access policy allowlist

Discord 流程同构（开发者门户建 bot、开 Message Content Intent、OAuth2 邀进服务器）；iMessage 走的是另一条路：直接读 macOS 的 Messages 数据库、用 AppleScript 发回复——不需要任何 bot 或外部服务，代价是要给终端 Full Disk Access 权限，首次回复还会弹一次「控制 Messages」的自动化授权。自己给自己发消息免配置直达（self-chat 绕过门禁），放行别人要显式 /imessage:access allow +8613800138000。

不想动真平台先试手感：fakechat 官方演示渠道在 localhost 起一个聊天网页，零认证零外部依赖，浏览器里打字消息就进会话。

安全模型：门禁是契约的一部分

发送者门禁：配对 + allowlist 是官方流程的强制段落，不是可选项。bot 的 token 只该进 ~/.claude/channels/ 下的 .env 或环境变量，不进仓库。
权限照常：事件进来后 Claude 干活仍受会话的权限模式与规则约束——渠道只解决「消息怎么进来」，不放大「Claude 能干什么」。
组织管控：Team / Enterprise 默认关闭，需管理员显式启用。
自建渠道：channels-reference 定义了完整契约——能力声明、通知事件、回复工具、发送者门禁、权限转发，本质是一种带推送能力的 MCP 服务器；会写 MCP server 就会写 channel。

与调度体系拼成完整拼图

我们在定时任务一文讲过轮询三件套（/loop、Desktop 任务、Routines）。Channels 是它们的对偶：轮询是会话按时间找事件，渠道是事件按发生找会话。组合用法很自然——

白天开发：会话常开 + CI webhook 渠道，红了立刻在调试现场处理；
下班离场：手机 Telegram 问进度、派小活，工作仍跑在本机真实文件上；
无人值守：要新起会话的例行工作交给云端 Routines——两套各管一段。

上手清单

先 fakechat 跑通流程，再接真平台。
配对完成的第一动作永远是 policy allowlist。
iMessage 用户确认给对了 Full Disk Access（授权对象是启动 Bun 的那个终端 App）。
always-on 需求用常驻终端 / 后台进程跑 claude --channels，注意这会持续占一个会话。
CI / 告警接入优先做成只报事件的单向渠道，回复工具按需再开。

Channels 把 Claude Code 从「你去用它」变成「事情来找它」。从聊天桥开始体验最直观：第一次在通勤路上用 Telegram 让家里的电脑修完一个 bug，你对「AI 结对」的理解会更新一次。