# Claude Code Routines 是什么？2026 年该选它，还是选 /loop、桌面定时任务和 GitHub Actions

> Claude Code Routines 真正新增的不是“又一种定时任务”，而是一条云端持久化自动化路线。本文会先帮你判断这条工作流到底该交给 Routines、桌面定时任务、`/loop` 还是 GitHub Actions，再补上当前触发、认证和 preview 边界。

- URL: https://blog.laozhang.ai/zh/posts/routines-in-claude-code
- Published: 2026-04-16
- Updated: 2026-04-16
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: Claude Code
- Tags: Claude Code, Routines, GitHub Actions, 开发工具, 自动化

---
Claude Code 现在已经有四条不同的自动化路线，第一件事不是研究 trigger 语法，而是先判断 **runtime 到底该归谁管**。Routines 是云端那条：你的电脑关了以后，它仍然可以在 Anthropic 管理的 cloud clone 里继续跑。Desktop scheduled tasks 留在你的机器上，`/loop` 留在当前会话里，GitHub Actions 则留在 CI。

这样看，判断其实比“新功能发布”听上去简单得多。工作流需要离开你的电脑继续跑，而且能接受在云端 repo clone 里执行，就看 Routines；工作流依赖本地文件、本地应用或本地浏览器，就留给桌面定时任务；只要开着 Claude Code 会话就够的短轮询工作，交给 `/loop`；真正属于仓库 CI、审计日志和策略检查的自动化，还是交给 GitHub Actions。只要工作必须依赖你的机器、依赖一个开着的对话，或者本来就该由 CI 拥有，Routines 就不是正确 owner。

Anthropic 在 2026 年 4 月 14 日把 Routines 作为 research preview 推出来，但这条时间线真正重要的地方，不是“它刚发布”，而是当前合同还比较收敛。Routines 现在支持 schedule、API 和 GitHub 三类 trigger，不过 CLI 里的 `/schedule` 只负责创建定时型 routine；API route 走的也不是普通 Anthropic API key 鉴权，而是每个 routine 自己的 bearer token。

> 证据说明：本文基于 Anthropic 当前的 routines、scheduled tasks、`/fire` 文档和 2026 年 4 月 16 日仍可见的公开材料核对。涉及 daily caps、beta header、preview 状态的内容都应按日期理解。

## 最快的判断方法

先别想 prompt、cron 或 webhook payload。先判断这项工作应该由哪一类 runtime 拥有。

| 你的工作流需要…… | 更适合的 owner | 为什么它更对 | 为什么不是 Routines |
| --- | --- | --- | --- |
| 电脑关掉后还要继续跑 | **Routines** | Anthropic 会在云端 clone 里唤醒这条工作流，可由 schedule、API 或 GitHub event 触发 | 如果工作依赖本地状态，云端 clone 本来就看不到 |
| 直接访问本地文件、本地应用或本地浏览器 | **Desktop scheduled tasks** | 依赖就在机器上，任务就该留在机器上 | 云端 routine 拿不到同一份本地环境 |
| 当前 Claude Code 会话里的短轮询或 watch 工作 | **`/loop`** | 足够轻，能跑到分钟级，而且不需要另起云端 surface | 它本来就是 session-scoped，循环七天后会失效 |
| 归属于仓库 CI、构建、策略检查和审计日志的自动化 | **GitHub Actions** | 工作流天然属于 repo 和 CI 历史 | Routines 不是“更新版 GitHub Actions”，只是另一种执行面 |

把这张表记住，后面的大部分细节都会自然落位。你真正要避免的错误，不是“不会配置”，而是把工作交给了错误的 owner。

## Routines 真正拥有的是什么

![Claude Code Routines、桌面定时任务、/loop 与 GitHub Actions 的运行时归属图](https://blog.laozhang.ai/posts/zh/routines-in-claude-code/img/cloud-runtime-map.jpg)

很多人第一次听到 “automation” 会下意识把几条路线的差别理解成 trigger 类型不同。真正更早的差别，其实是 **运行位置和 ownership 不同**。Anthropic 当前对 routines 的定义，本质上是一份保存下来的 Claude Code 工作流配置：包含 prompt、一个或多个仓库、连接器和执行环境，然后由 Anthropic 管理的云端基础设施自动唤起。

这件事的第一层后果，是 routine 不是“远程控制你当前这台电脑上的 Claude Code 会话”。它更像一条新的云端执行面。Anthropic 当前文档写得很明确：仓库会为每次 run 重新 clone，默认从默认分支起步，触发外部系统动作时也会表现为你自己的 `claude.ai` 账户，而不是某个抽象的团队机器人。

第二层后果，是 routines 拥有的环境比多数本地 Claude Code 工作流更完整，也更受约束。Anthropic 现在给 routines 提供 cloud environments，用来处理网络访问、环境变量和 setup scripts。正因为这样，它非常适合“电脑离开后继续跑”的工作；也正因为这样，只要你的任务依赖本地浏览器 profile、桌面软件、挂载盘或机器上的私有凭据路径，这条路线就会立刻变得别扭。

第三层后果，是 routines 默认不是无限制的云端 shell。Anthropic 目前仍把 push 行为默认约束在 `claude/` 前缀分支，除非你明确给仓库开启 unrestricted branch pushes。这个边界很重要，因为它说明 routines 设计出来是一个 **受约束的云端自动化 surface**，不是本地 scheduler、桌面自动化和 CI 的统一区替代品。

## 什么场景更适合 Routines

![Claude Code Routines 适用场景矩阵](https://blog.laozhang.ai/posts/zh/routines-in-claude-code/img/workflow-fit.jpg)

只要“电脑必须一直开着”开始变得不可接受，Routines 的价值就会明显上升。比如每天早上检查一个仓库的 stale issues、看看新 PR、总结下一步动作；又或者定期扫 docs drift、做 backlog triage；再或者由 GitHub 事件把一条云端 Claude Code 工作流唤醒。这类工作的共同点，不是 prompt 很复杂，而是 **它们确实值得拥有一条独立的云端持久化路线**。

Anthropic 在 launch 材料里举的很多例子也是这一类：issue triage、研究型任务、反复发生的 repo 工作。真正让 routines 合理的，不是“它比较新”，而是你终于不需要把一整套长时、异步、能离线继续推进的 repo 工作绑在一台开着的笔记本上。

当另一个系统需要远程唤醒固定工作流时，Routines 也会变得更顺手。这里有个常见误区：很多人会把 API trigger 理解成“从代码里调 Claude”。更准确的心智模型是：“用一个小 payload 去唤醒一条已经配置好的云端工作流”。这比普通 API 调用窄，但对稳定流程来说反而更干净。

同样重要的是反面判断。Routines 不是所有 recurring job 的默认答案。如果一项工作只有在你正开着 Claude Code 会话时才有意义，或者它天然需要本地状态，那多加一层云端 surface 只会增加复杂度，并不会解决真正的约束。

## 什么时候该改选桌面定时任务、`/loop` 或 GitHub Actions

拒绝 Routines 往往才是更正确的决定，所以另外三条路线不能被写成脚注。

### Desktop scheduled tasks：本地依赖就留在本地

只要工作流依赖本地文件、本地应用或本地浏览器 profile，路线判断通常在你研究 trigger 之前就已经结束了。任务应该留在机器上。Desktop scheduled tasks 的价值，正是在于它能看到 routines 的 cloud clone 根本看不到的那份本地状态。

这条路线也覆盖了 routines 做不到的另一类需求：**低于一小时的本地执行节奏**。如果你既需要本地依赖，又需要更密的本地定时，不要勉强把它塞进 routines。

### `/loop`：它是 live session 工具，不是云端持久化工具

`/loop` 比 routines 轻得多，因为它的职责本来就更窄。Anthropic 当前的 scheduled tasks 文档把它写成 session-scoped scheduling：循环任务可以分钟级运行，但七天后会过期。这让它非常适合放在一个正在进行中的 Claude Code 会话里做 watch、轮询和短时重复动作。

很多人会把 `/loop` 和 routines 想成“同一件事的两个成熟度版本”，这是错觉。`/loop` 的 owner 仍然是你眼前这个打开着的会话；Routines 的 owner 则是一条独立的云端执行面。只要你需要的是 unattended persistence，而不是 live session 里的重复动作，二者就不是同一个问题。

如果你真正遇到的问题不是无人值守，而是长本地编码会话里的授权疲劳，更接近的兄弟页其实是 [Claude Code Auto Mode](https://blog.laozhang.ai/zh/posts/claude-code-auto-mode)，不是 routines。Auto Mode 改的是本地工作流里的 approval 行为；Routines 改的是工作跑在哪里。

### GitHub Actions：属于 CI 的，就继续留在 CI

GitHub Actions 应该被当成一条严肃的 sibling route，而不是一个“旧时代残留品”。如果自动化本身就属于仓库策略、构建流程、测试 gate、定期 CI 维护，或者你需要 repo 原生的审计日志和权限边界，那么 GitHub Actions 的合同仍然更干净。

Routines 当然也可以被 GitHub event 唤醒，但那不等于它天然比 GitHub Actions 高级。正确的判断方式是：GitHub 事件到底只是一个 wake-up signal，还是这项 workflow 本来就属于 CI。如果是后者，那就别把它硬搬去 routines。

如果你最终决定把工作留在本地而不是搬进云端，接下来更值得看的往往不是“更深一层的 routines 教程”，而是 [Claude Code 最值得先接的 MCP Servers](https://blog.laozhang.ai/zh/posts/claude-code-best-mcp-servers)。很多时候，问题真正缺的不是调度，而是工具接入。

## 当前边界：preview、认证和频率限制

![Claude Code Routines 当前 preview、认证和运行边界图](https://blog.laozhang.ai/posts/zh/routines-in-claude-code/img/current-boundaries.jpg)

Routines 已经是真实可用的，但当前合同仍然值得认真看。Anthropic 当前 launch 材料写的是：截至 2026 年 4 月 16 日，research preview 阶段的 included routine runs 为 Pro 5 次/天、Max 15 次/天、Team 或 Enterprise 25 次/天。同时，routine runs 仍然从同一份 Claude Code 订阅 usage pool 里消耗。你不需要把这件事写成 headline，但它会直接影响你先把哪类工作交给 routines。

认证模型同样容易被误判。Anthropic 当前 [`/fire` 文档](https://platform.claude.com/docs/en/api/claude-code/routines-fire) 说明得很清楚：API trigger 走的是 **per-routine bearer token**，并且当前还需要 `anthropic-beta: experimental-cc-routine-2026-04-01` 这个 beta header。它不是“把普通 Anthropic API key 换个入口继续用”那么简单。

触发配置也有一层很容易踩空的边界。Routines 现在支持 schedule、API 和 GitHub trigger，而且同一个 routine 可以组合多种 trigger；但 CLI 本身没那么宽，`claude --schedule` 只负责定时型 routine，API 和 GitHub trigger 仍然要去 web editor 里配置。这个信息应该放在路线判断之后，而不是让它抢走第一屏。

还有一个对 route choice 影响很大的硬边界：**cloud routines 最低只支持一小时间隔**。如果你要分钟级轮询，routines 其实已经出局了。要么留在 `/loop`，要么把任务放到本地，或者明确交给 CI。

如果你想继续看更完整的套餐和 usage 语境，可以直接读 [Claude Code 定价指南](https://blog.laozhang.ai/zh/posts/claude-code-pricing-guide)。对当前这篇路线判断页来说，更重要的是先看清这些边界会不会改变 owner 选择。

## 第一个 routine，最安全的做法是什么

最好的第一个 routine，最好无聊一点。范围要小，小到你能很快判断它到底有没有价值；同时又要足够安全，错了也不会在三个系统里留下大面积清理工作。

一个很稳的起点，是“每天早上做一次单仓库 triage”：

1. 先只给它一个仓库，不要一上来就五个。
2. 第一天先只开 schedule trigger，不要同时把 API、GitHub 和 schedule 全堆进去。
3. 让它看 stale issues、open PR 和 failing checks，然后吐出一段简短总结，或者一份限定分支范围的 draft action list。
4. push 先留在默认的分支边界里，不要一开始就放大写权限。

这个起点的好处，在于它正好验证 routines 真正应该验证的东西：当你离开电脑后，云端持久化工作流能不能继续做出有用的 repo 工作。它不依赖本地机器，也不假装 CI 应该立刻退场。

反过来看，最糟糕的第一个 routine 往往也很像一个模板：仓库太多、trigger 太多、写权限太大，而且默认假设“既然叫 automation，就该统一到一条 surface 上”。先用一个边界清楚的 workflow 让这条路线证明自己，通常比一上来搭一整套自动化体系更稳。

## FAQ

### Routines 和 `/schedule`、scheduled tasks 是一回事吗？

不是。现在更大的产品表面叫 `routines`，里面同时包含 schedule、API 和 GitHub 三类 trigger。CLI 的 `--schedule` 只负责创建定时型 routine，不代表整条 surface 只有定时这一种形态。

### 什么时候该选 Desktop scheduled tasks？

当任务依赖本地文件、本地应用、本地浏览器，或者你明确需要低于一小时的本地执行节奏时，就选 Desktop scheduled tasks。只要机器本身是依赖，owner 就应该留在机器上。

### 什么时候 `/loop` 已经够了？

当工作本来就属于当前 Claude Code 会话，而且你只需要短时重复动作时，`/loop` 已经够了。它可以分钟级运行，但会话结束或七天失效这个边界也要一起接受。

### Routines 会不会取代 GitHub Actions？

不会。只要 workflow 本来就属于 CI、仓库策略、构建和审计日志，GitHub Actions 仍然是更干净的 owner。Routines 是一条 sibling route，不是自动升级路径。

### Routine API trigger 怎么鉴权？

Anthropic 当前文档写的是：routine API trigger 使用 per-routine bearer token，并且现在仍需要 `anthropic-beta: experimental-cc-routine-2026-04-01` header。它不是普通 Anthropic API key 集成的另一种写法。

### 当前 daily routine-run limits 是多少？

截至 2026 年 4 月 16 日，Anthropic 当前 launch 材料列的是 Pro 5 次/天、Max 15 次/天、Team 或 Enterprise 25 次/天。请把这组数字按 research preview 的日期事实来理解，不要当成永远不变的合同。

## 真正要问的，是 runtime 该归谁

Routines 值得学，不是因为它突然让 Claude Code 拥有了“更厉害的定时任务”，而是因为它把 **云端持久化自动化** 这条路线单独拿出来了。只要你的工作应该在 cloud clone 里继续跑，它就是一条很清楚的新路。

但这不意味着所有 recurring workflow 都该往这条路上迁。只要任务属于你的机器、属于当前 live session，或者本来就属于 CI，另外三条路线就更自然。把问题这么看，Routines 就不再像一个模糊的新词，而更像 Claude Code 自动化栈里边界清楚的一条分支。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-04-16。

- [/fire 文档](https://platform.claude.com/docs/en/api/claude-code/routines-fire) (platform.claude.com)