Channels 解决的是「外部事件如何主动进入当前会话」这个长期被忽略的问题：把 CI 告警、即时通讯消息、监控 Webhook 推进正在运行的 Claude Code 终端，而不是新开一个云端会话或用定时器轮询。把它和已有的「轮询 / 新建会话 / 远程控制」三套路放在一起比较，才能看出 Channels 的真实定位。
一、Channels 是什么、解决什么问题
Channels 是 Claude Code v2.1.80 起的实验特性，本质是一个特殊的 MCP server，会把外部平台的消息、告警、回调「推」进当前正在运行的本地会话。官方首批支持 Telegram、Discord、iMessage 三类即时通讯平台，并附带一个 fakechat 本地演示插件用于入门。
| 接入方式 | 工作方式 | 上下文是否连续 | 典型场景 |
|---|---|---|---|
| Channels（事件推送） | 外部消息主动推进当前会话 | 完全连续 | CI 失败、聊天桥、监控告警 |
| 轮询（/loop / /schedule） | 客户端按时间间隔检查 | 连续 | 无外部事件源、需要主动询问 |
| 新建云端会话 | 拉起全新的隔离会话 | 不连续 | 异步派发的独立任务 |
| 远程控制（Remote Control） | 从另一设备继续控制当前会话 | 完全连续 | 人在异地继续本地操作 |
最关键的一行：Channels 让「事件」找到「会话」，而不是「会话」去「拉事件」。这一字之差，是它和轮询式集成的根本分野。
二、与「轮询式」集成的核心区别
2.1 触发方向：拉 vs 推
轮询式集成（如 /loop 5m 或 CronCreate）的工作模型是：客户端按设定的时间间隔去询问「事情发生了吗」。这种方式在「我不知道何时会出事」的场景里会浪费大量空转。Channels 反过来——事件源主动把消息推过来，时延基本与平台通知一致。
2.2 上下文与身份
轮询与新建会话都从「当下这一刻」开始，但二者的上下文连续性不同：
- 轮询（在当前会话内）保留完整的文件状态、对话历史与工具权限；只是「等一会儿再问一次」；
- 新建云端会话会克隆仓库到一个干净的沙箱，丢失前序对话记忆，需要从零开始；
- Channels 接收事件时，消息会作为
<channel source="...">进入当前会话，文件、工具、记忆全部保留。
2.3 权限与可见性
Channels 接收事件后，Claude 仍按当前会话的工具权限运行；若事件触发的操作需要审批，v2.1.100 起的「Permission Relay」会把审批请求转发回 channel 平台（如 Telegram），让人在手机上点头或拒绝。这把「人必须在终端前」的限制又松绑了一步。
三、与「新建会话式」集成的核心区别
「新建云端会话」一类集成（典型如 claude code on the web、Slack 中的 @Claude）每次都从一份克隆的沙箱起步。Channels 的设计哲学是「我有一个跑着的会话，请把外面的事告诉我」——它不复制、不隔离、不另起炉灶。
一个工程上的取舍：如果你派给 Claude 的任务自带完整上下文（比如修一个独立 bug、写一段独立脚本），新建云端会话更合适；如果你希望 Claude 在你长跑任务的过程中持续接收外部信号，Channels 是更顺手的工具。
四、Channels 的配置与边界
4.1 启动与运行模式
Channels 的启动必须在会话开始时显式声明：
claude --channels plugin:telegram@claude-plugins-official
# 多 channel 并行
claude --channels plugin:telegram@claude-plugins-official \
plugin:discord@claude-plugins-official这一行既是「启用」也是「权限边界」——即便 .mcp.json 里写了 channel server，不加 --channels 也不会主动推送。
4.2 安全模型
所有 channel 都默认带 sender allowlist，陌生发送者的消息会被静默丢弃。Telegram 与 Discord 还需要一次性的「pairing code」流程：bot 给出配对码，用户在 Claude Code 内用 /telegram:access pair <code> 确认，再用 policy allowlist 锁定到具体账号。
4.3 生命周期与排队
Channels 仅在会话打开期间有效。终端关闭时，外部消息不会被排队或回放——这与「always-on 任务队列」是不同的设计取舍。要保证长期在线，可以在后台进程或 tmux/screen 中持续运行 Claude Code。
五、选型决策：什么时候用哪一路
5.1 三步选型法
- 外部系统是否会「主动发事件」？是 → 优先 Channels；否 → 考虑轮询；
- 是否要求 Claude 在当前会话上下文中继续？否 → 用云端会话更省心；是 → Channels 是首选；
- 是否需要「人不在终端前也能审批权限」？是 → Channels + Permission Relay。
5.2 一个对比示例
| 场景 | 推荐方式 |
|---|---|
| CI 失败后让 Claude 自动分析 | Channels（推 webhook） |
| 没人触发、定期自检 PR 状态 | 轮询（/loop 或 CronCreate） |
| 让团队成员在 Slack 里给 Claude 派活 | Slack 内 @Claude（新建云端会话） |
| 出差时让手机继续指挥本地会话 | Remote Control + Channels 二者皆可 |
到这里，Channels 与轮询、新建会话、远程控制的差异就清晰了：它不是「另一种自动化」，而是「事件找到会话」这一新原语。
常见问题（FAQ）
Q1：Channels 与 /loop 能否同时使用？
可以，前者处理外部推送，后者处理「无事件源时的定时检查」，职责互不重叠。
Q2：Channel 消息在会话关闭后会补发吗？
不会，事件只在会话打开时送达；离线期间的消息不会回放。
Q3：自定义 channel plugin 怎么接入？
需用 claude --channels plugin:my-channel --dangerously-load-development-channels 绕过市场校验，仅供本地调试。
