如果说 Routines 是把 Claude Code 包装成定时任务,那 Dispatch 是把它变成一个可以随时调用的后台工作进程,而 Channels 是监听这个工作进程实时发生了什么的消息通道。三者组合,是将 Claude Code 嵌入生产流水线的核心基础设施。
Dispatch:程序化触发 Claude Code
什么是 Dispatch?
Dispatch 让你通过 API 发送任务给 Claude Code——它接收、执行、返回结果。没有人需要盯着终端。
这是一个重要的架构转变:
之前(对话模式):
你输入 → Claude 回复 → 你看 → 你输入...
现在(Dispatch 模式):
你发任务 → Claude 执行 → 结果推回来
这更接近调用 Lambda 函数或后台 Job Worker——只不过这个 Worker 能推理、编辑文件、执行命令。
Dispatch 能做什么?
- 每次 PR 创建时触发代码审查
- 测试套件失败时启动调试 Agent
- 按计划运行文档生成任务
- 把 Claude Code 串联进更大的流水线作为处理步骤
Dispatch 和 Routines 的关系
| Routines | Dispatch | |
|---|---|---|
| 触发方式 | 定时/GitHub/API | 纯 API(程序化) |
| 配置方式 | 保存的 Prompt 模板 | 每次调用传入任务 |
| 适合场景 | 重复性、标准化任务 | 动态任务,每次内容不同 |
| 状态可见性 | Web 界面查看运行记录 | Channels 实时流式输出 |
实际上,Routines 的 API 触发器本质上就是一种 Dispatch——区别在于任务 Prompt 是否预先保存。
Channels:实时监听运行中的 Agent
什么是 Channels?
Channels 是 Claude Code 运行 Session 的结构化事件流。当 Claude Code 执行后台任务时,你可以订阅这个流,实时知道它在做什么。
它解决了什么问题:
之前:启动 Claude Code 任务,只能等着看结果,像个黑盒子。
现在:实时流式事件,像日志一样流出来,可以接入告警、看板或下游触发器。
Channels 暴露的事件类型
| 事件 | 含义 |
|---|---|
| Status updates | Agent 当前在做什么 |
| File change events | 哪些文件被读取或修改 |
| Tool calls | 调用了哪些命令或函数 |
| Completion signals | 任务完成,以及是否成功 |
| Error events | 出错的位置和原因 |
实际应用
# 示例:监听 Claude Code Session 的 Channels 事件
import anthropic
import json
client = anthropic.Anthropic()
# 假设 session_id 来自 Dispatch 的响应
session_id = "session_01HJKLMNOPQRSTUVWXYZ"
# 订阅 Session 的事件流
with client.claude_code.sessions.stream(session_id) as stream:
for event in stream:
if event.type == "file_change":
print(f"文件变更: {event.path} ({event.action})")
elif event.type == "tool_call":
print(f"工具调用: {event.tool_name}")
elif event.type == "completion":
print(f"任务完成: {'成功' if event.success else '失败'}")
break
elif event.type == "error":
print(f"错误: {event.message}")
break完整生产工作流示例
示例 1:PR 自动审查流水线
触发点:GitHub PR 创建 Webhook
# webhook_handler.py
from fastapi import FastAPI, Request
import httpx, os
app = FastAPI()
ROUTINE_ENDPOINT = "https://api.anthropic.com/v1/claude_code/routines/trig_xxxxx/fire"
API_TOKEN = os.environ["ROUTINE_TOKEN"]
@app.post("/webhook/github")
async def handle_pr(request: Request):
payload = await request.json()
if payload.get("action") != "opened":
return {"status": "skipped"}
pr = payload["pull_request"]
# 触发 Routine,传入 PR 上下文
async with httpx.AsyncClient() as client:
resp = await client.post(
ROUTINE_ENDPOINT,
headers={
"Authorization": f"Bearer {API_TOKEN}",
"anthropic-beta": "experimental-cc-routine-2026-04-01",
"anthropic-version": "2023-06-01",
},
json={
"text": f"PR #{pr['number']}: {pr['title']}\\nURL: {pr['html_url']}\\n作者: {pr['user']['login']}"
}
)
data = resp.json()
return {
"status": "triggered",
"session_url": data["claude_code_session_url"]
}示例 2:告警驱动的自动修复
触发点:Sentry / PagerDuty 告警
# 告警系统调用的脚本
ALERT_BODY="$1"
ROUTINE_ENDPOINT="https://api.anthropic.com/v1/claude_code/routines/trig_yyyyy/fire"
curl -X POST "$ROUTINE_ENDPOINT" \
-H "Authorization: Bearer ${ROUTINE_TOKEN}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"text\": \"$ALERT_BODY\"}"对应 Routine 的 Prompt:
你收到了一个生产告警。
告警内容:
{{text}}
请:
1. 分析堆栈跟踪,找到根本原因
2. 在相关代码中定位问题所在
3. 创建一个包含修复方案的 PR 草稿
4. 在 PR 描述里说明:根本原因、修复方案、测试建议
5. 不要直接合并——创建 PR 供人工审查
如果无法确定根本原因,说明你的分析过程和需要更多信息的地方。
示例 3:CI/CD 后部署验证
# GitHub Actions workflow
name: Post-Deploy Verification
on:
deployment_status:
jobs:
verify:
if: github.event.deployment_status.state == 'success'
runs-on: ubuntu-latest
steps:
- name: Trigger verification routine
run: |
RESPONSE=$(curl -s -X POST \
"${{ secrets.ROUTINE_ENDPOINT }}" \
-H "Authorization: Bearer ${{ secrets.ROUTINE_TOKEN }}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"text\": \"部署 ${{ github.sha }} 到 ${{ github.event.deployment.environment }} 成功\"}")
SESSION_URL=$(echo $RESPONSE | jq -r '.claude_code_session_url')
echo "验证会话: $SESSION_URL"
echo "SESSION_URL=$SESSION_URL" >> $GITHUB_OUTPUTAuto Mode:让 Dispatch 真正能用
为什么 Dispatch 需要 Auto Mode?
默认的 Claude Code 每次要做有影响的操作(运行命令、修改文件、网络请求)都会暂停请求确认。交互式使用时这合理。但后台任务(Dispatch Job)根本没有人在看——没人能回答确认请求,任务就卡死了。
Auto Mode 关闭这些暂停,Claude Code 自主决策、执行、继续。
何时使用 Auto Mode
合适的环境:
- 隔离的容器,只挂载了特定 Repo
- 无生产凭证的沙箱环境
- 有 Channels 监控、有回滚机制的环境
不合适的环境:
- 有生产凭证的机器
- 能直接访问生产数据库的环境
- 没有任何监控的黑盒
原则:Auto Mode + 受限环境 + Channels 监控 = 安全高效的自主执行
Auto Mode + hard_deny(Week 19 新功能)
可以在 Auto Mode 下设置永远不执行的操作:
{
"autoMode": {
"hard_deny": [
"Bash(rm -rf /)",
"Bash(curl * | bash)",
"Write(.env.production)",
"Write(secrets/**)"
]
}
}hard_deny 不可被 allow 覆盖,提供绝对的安全底线。
Remote Control:从任何地方监控 Session
什么是 Remote Control?
Remote Control 让你从不同的终端或机器连接到正在运行的 Claude Code Session。
解决的问题:
之前:Claude Code 是本地工具,必须守着那台机器的终端。
现在:
- 在服务器上启动长时间任务,从笔记本监控
- 团队 Lead 可以查看 Agent 在做什么
- 可以随时接管任务继续手动操作
使用场景
# 在远端服务器启动任务
ssh my-server
claude -p "对整个 src 目录进行依赖升级,从 Node 18 迁移到 Node 22 语法"
# 在本地笔记本监控
# 通过 Web 界面查看:claude.ai/code/sessions
# 或通过 Desktop App 的 Remote Sessions 面板Remote Control + Channels 的组合
远端 Claude Code 运行 → Channels 事件流 → 本地监控脚本 → 告警/日志/触发下游
这是把 Claude Code 真正变成基础设施组件的关键组合——可观测、可接管、可集成。
工作流组合模式
模式 1:完整的 PR 生命周期自动化
PR 创建
→ GitHub 触发器 → Routine 运行代码审查 → 发布审查评论
→ 开发者修复后同步 PR
→ GitHub 触发器(push 事件)→ Routine 重新审查 → 更新评论
→ 全部通过 → Routine 触发自动合并检查
模式 2:监控驱动的自愈
生产告警触发
→ API Dispatch → Routine 分析 + 创建修复 PR
→ Channels 事件流 → 通知 On-call
→ On-call Review PR → 合并
→ CD 流水线部署 → API Dispatch → Routine 验证部署
模式 3:每日维护流水线
每天 02:00(Schedule 触发)
→ Routine A:依赖安全扫描 → 创建升级 PR
→ Routine B:文档漂移检测 → 创建文档更新 PR
→ Routine C:Issue 分类和标签 → 发 Slack 摘要
所有 Routine 并发运行(每个独立 Session),早上上班时团队看到 3 个已处理好的 PR 和 Slack 摘要。
来源:Claude Code Q1 2026 功能解读 | Claude Code Routines 官方文档 | 整理:ClaudeEagle