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 真正拥有的是什么
很多人第一次听到 “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
只要“电脑必须一直开着”开始变得不可接受，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，不是 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。很多时候，问题真正缺的不是调度，而是工具接入。
当前边界：preview、认证和频率限制
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 文档 说明得很清楚：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 定价指南。对当前这篇路线判断页来说，更重要的是先看清这些边界会不会改变 owner 选择。
第一个 routine，最安全的做法是什么
最好的第一个 routine，最好无聊一点。范围要小，小到你能很快判断它到底有没有价值；同时又要足够安全，错了也不会在三个系统里留下大面积清理工作。
一个很稳的起点，是“每天早上做一次单仓库 triage”：
- 先只给它一个仓库，不要一上来就五个。
- 第一天先只开 schedule trigger，不要同时把 API、GitHub 和 schedule 全堆进去。
- 让它看 stale issues、open PR 和 failing checks，然后吐出一段简短总结，或者一份限定分支范围的 draft action list。
- 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 自动化栈里边界清楚的一条分支。