Claude Code Routines 是什么？AI Agent 定时任务与自动触发指南
Claude Code Routines 的关键，不是“又多了一个定时器”，而是把 AI Agent 从“等人类发起对话”变成“在世界变化或时间到点时自动运行”。这才是本质变化。Cron 也不只是排程语法，它让 Agent 变成可以运行在业务节奏里的操作系统。
截至 2026 年 4 月 15 日，Anthropic 将 Claude Code routines 作为 Claude Code on the web 的 research preview 功能提供。你可以把 routine 理解为一种云端保存的 Claude Code 配置：它包含 prompt、repositories、environment、connectors，以及能够自动触发新运行的 triggers。想看最准确的 UI 步骤和当前限制，建议先读官方 Claude Code routines 文档 (opens in a new tab)。这篇文章则负责把它讲透：routines 到底是什么、为什么重要，以及它和 Codex app Automations、OpenClaw cron jobs 有什么差别。
如果你想先补一下 AI coding 的整体背景，可以先看 AI Coding 主题页、并行代码 Agent 说明 和 Codex 使用指南。
快速回答：Claude Code Routines 是什么
Claude Code routines 本质上是 会自动启动的云端 Claude Code 会话。
你不用每次都手动打开 Claude，再说“帮我 review 开着的 PR”或者“看看生产告警”，而是一次性定义好工作，再挂上一个或多个 trigger：
- 定时计划
- API 调用
- GitHub 事件
所以 routines 不只是一个计时器。它更像是触发真实 coding agent session 的一层机制。
| 你需要的能力 | 更适合的选择 | 原因 |
|---|---|---|
| 即使笔记本合上也能继续运行的云端 Agent | Claude Code routines | Anthropic 在自家云基础设施里执行 session |
| 在你的 coding desktop app 里跑的定期后台任务 | Codex app Automations | 适合那些最终要进入 review queue 的重复工作 |
| 想自己掌握精确 cron、heartbeat、hooks 和 webhook 分发的自托管 Agent | OpenClaw | 如果你要自己控制自动化栈，它的能力最完整 |
重点不是品牌名，而是从 chat-first agent 转向 time-triggered / event-triggered agent。
Routines 解决什么问题
很多 AI Agent 到现在还是反应式循环：
- 人发现问题
- 人打开 Agent
- 人描述问题
- 人等待结果
这适合一次性任务，但不适合重复工作。
重复工作通常有这些特征：
- 很琐碎
- 容易忘
- 一旦漏掉就很重要
- 用 policy 描述，比每天重新解释更清楚
这就是为什么 cron 对 Agent 很重要。真正的价值不在于“任务每天早上跑一次”，而在于：
- 工作变得 可依赖
- trigger 变得 显式
- Agent 可以 不用等人记得再去执行
- 结果可以在运行后再 review，而不是运行前手动发起
对 AI Agent 来说，这是一种很大的实用升级。它把 Agent 从 assistant 模式推向 operations 模式。
Claude Code Routines 的工作方式
Anthropic 当前文档里把 routine 描述为一种保存好的 Claude Code 设置，由下面几部分组成：
- 一个 prompt
- 一个或多个 repositories
- 一个 environment
- 可选的 connectors
- 一个或多个 triggers
实际运行不是一个玩具式 task runner，而是完整的 Claude Code 云端会话。
这意味着 routine 可以：
- clone repositories
- 执行 shell 命令
- 使用 repo 里提交的 skills
- 通过 connector 调用 Slack 或 Linear 之类的连接服务
- 打开一个之后还能检查的 session
更实用的理解方式是：
routine 是一个带 trigger 的可复用 agent runbook
在实践里怎么创建 routine
Anthropic 目前说明，所有 routine surface 都会写入同一个 cloud account，所以你从 web 或 CLI 创建的 routine 最终都会出现在同一处。
你可以通过这些方式创建：
- web UI
- Desktop app 里的 remote task
- CLI 的
/schedule
最短的 CLI 例子是：
/schedule daily PR review at 9am这个入口很有用，因为它降低了最常见场景的门槛：重复性定时工作。
不过，当前文档也有一个重要限制：
- CLI 只能创建 scheduled routines
- API 和 GitHub triggers 仍然需要在 web UI 里添加
Anthropic 还说明，每个 routine 属于个人账户，不会自动和团队共享。
三种 trigger 类型
1. Schedule trigger
这是大多数人最先想到的：按固定周期反复执行。
官方文档说 routines 支持这些预设 schedule：
- hourly
- daily
- weekdays
- weekly
如果需要自定义间隔，Anthropic 说可以在 CLI 里用 /schedule update 设置 cron expression。当前最小间隔是 1 小时，所以它不是为每分钟轮询设计的。
运维上有两个细节很重要：
- 时间要用你的 本地时区
- Anthropic 会应用 consistent stagger，所以任务可能会晚几分钟开始
也就是说，它确实是 cron 风格的自动化，但上面还叠了一层 agent-aware 的调度规则。
2. API trigger
到了这里，routine 就不再像普通定时任务了。
Anthropic 还允许 routine 暴露一个专用的、带认证的 HTTP endpoint。当外部系统向这个 endpoint 发送 POST 请求时，Claude 会启动一个新的 run，并且可以通过 text 字段接收额外的自由格式上下文。
这意味着你可以把 routine 接到这些系统上：
- deployment pipeline
- error alerting
- internal tools
- 另一个系统里的手动按钮
这很重要，因为它让 Agent 不只是对时间做出反应，也能对 外部状态变化 做出反应。
3. GitHub trigger
Anthropic 的文档还允许 routine 从 GitHub 事件启动。按当前文档，支持的事件类型是 pull request 和 release，并且可以按 author、title、base branch、labels、draft state、merge state，以及是否来自 fork 等字段过滤。
这会把 Claude 变成一种 repository-native 的自动化层：
- PR 打开
- Claude 进行 review
- 发布新的 release
- Claude 执行验证或 backport 逻辑
这和“打开聊天窗口然后请它 review”是完全不同的操作模型。
为什么它比普通 cron job 更有意思
普通 cron job 擅长一件事：在已知时间启动代码。
Agent routine 更激进。它把这些东西绑在一起：
- 一个 schedule 或 event
- repository context
- tools 和 connectors
- 定义成功条件的 prompt
- 之后还能检查的输出面
所以 cron expression 只是整个栈里的一个部分。
这个类别之所以值得关注，更深层的原因是它能支持这些工作：
- 早上自动做 PR review，不需要谁先想起来
- 每晚在 merged code 之后检查 docs drift
- release 完成后自动跟进部署
- 每周做 backlog triage，并给出 labels、summary 和 ownership 建议
这些事情过去用 shell script 也能做。但到了 agent routine 里，你可以把更多非结构化推理直接交给这个定时运行。
Claude Code Routines 与 Codex app Automations 的区别
这里开始进入有意思的比较。
OpenAI 在 2026 年 2 月 2 日 的 Codex app 公告里说，app 支持 Automations，可以把 instructions 和可选 skills 组合起来按 schedule 运行。OpenAI 将它们描述为后台工作，完成后会进入 review queue；同时也表示，后续版本还在建设 cloud-based triggers。
所以 Codex app Automations 和 Claude routines 很接近，但并不完全一样。
从目前公开定位来看，Codex 更像：
- scheduled background work
- review-oriented handoff
- desktop-app-centered orchestration
而 Claude routines 已经更明确地被定义为：
- cloud sessions
- multi-trigger automations
- API-callable runs
- GitHub-event-aware runs
所以最干净的比较方式是：
| 维度 | Claude Code routines | Codex app Automations |
|---|---|---|
| 运行位置 | Cloud | 以 App 为中心的 scheduled background work |
| trigger 模型 | Schedule、API、GitHub | 现在以 Schedule 为主，trigger 叙事还在扩展 |
| 主要输出形态 | 一个之后还能检查的新 Claude Code session | App 里的 review queue 和后续工作流 |
| 最适合的场景 | 不需要人盯着的云端自动化 | 在 Codex 控制平面里跑的重复工作 |
如果你重度使用 Codex，真正值得注意的不是 Claude “赢了”没有，而是整个市场都在朝同一个方向收敛：Agent 必须可调度。
为什么 OpenClaw 用户这么在意 cron jobs
OpenClaw 是一个很好的对照物，因为它把调度当成第一等的系统能力，而不是藏在某个 UI 后面的附属功能。
官方 OpenClaw 文档把更完整的自动化栈描述为：
- cron：精确调度和一次性提醒
- heartbeat：大致周期性的检查，并保留完整 session context
- hooks：事件驱动脚本
- standing orders：持续性的操作权限
这也是 OpenClaw 受到很多自治导向用户关注的原因。
OpenClaw 的文档尤其明确地区分了这两种情况：
- 如果 timing 必须精确，或者工作应该独立运行，用 cron
- 如果 timing 只需要大致准确，而且 Agent 应该使用完整的 main-session context，用 heartbeat
这不只是实现细节，而是一种很强的自动化设计模式。
为什么这很重要
很多人说自己想要“agent cron jobs”，但实际上他们要的是两种不同的东西：
- 精确的 scheduled execution
- 持续存在的周期性 awareness
OpenClaw 把这两件事拆得很清楚。
Claude routines 目前主要覆盖的是第一类：在云端通过显式 schedule 或 event-triggered run 来执行。
Codex app Automations 现在也主要处在“scheduled work”这一路线上。
OpenClaw 则进一步把多层自动化逻辑直接暴露出来，这也是很多自治优先用户喜欢它的原因。
为什么 cron jobs 决定 AI Agent 的未来
如果一个 Agent 只能等人发起请求，它就仍然只是一个反应式工具。
如果它能够：
- 每天早上运行
- PR 打开时运行
- 部署完成时运行
- 告警触发时运行
- 每周维护窗口开始时运行
那它就成了系统运行节奏的一部分。
这才是 routines 和自动化框架的真正意义。它们让你能定义：
- Agent 什么时候醒来
- 它接收什么上下文
- 它拥有什么权限
- 结果应该送到哪里
一旦这四件事稳定下来，Agent 就会变得更适合承担重复性工作。
常见误区
1. 把 scheduling 当成 autonomy
cron trigger 只解决“什么时候运行”，并不解决正确性、权限范围或 review 质量。
2. 写得太模糊
“检查一下仓库并帮忙处理”不是自动化 prompt，而是在制造漂移。
3. 忽略运行时边界
云端 routines、桌面任务和自托管调度器并不等价。该选谁，取决于任务是否需要：
- 本地文件
- 云端可用性
- 事件集成
- 严格审计
4. 忘记失败处理
好的自动化会提前定义：如果没有可报告内容、需要处理的数据太多，或者外部系统不可用，该怎么办。
这个类别该怎么理解
如果你想要一个简单框架，可以直接用这套：
- 需要一个能按 schedule、API call 或支持的 GitHub events 唤醒的云端 Agent，就选 Claude Code routines
- 想在 coding app 内做持续的、以 review 为导向的重复工作，就选 Codex app Automations
- 想要最明确的自托管自动化 surface，并且把 cron、heartbeat、hooks 和持续权限当成不同积木来管理，就选 OpenClaw
这就是这个功能类别真正重要的原因。它并不只是 cron 语法，而是在回答一个更大的问题：AI Agent 是继续困在聊天窗口里，还是能够成为可靠的后台工人。
数据分析和 notebook 场景里的补充理解
如果你正在做数据分析、特征工程、建模或 notebook 调试，另一个更关键的问题往往不是“Agent 会不会写 notebook 代码”，而是“它到底依据什么反馈信号工作”。通用 code agent 默认承接的通常还是 software developer 的工作心智：更关注代码能不能运行、单元格能不能执行、构建能不能通过，而不会天然把“这个分析结论是否站得住”“这个特征是否真的提升了指标”“这些中间结果是否偏离真实数据”当成首要验收标准。
所以，单纯给 Claude 或 Codex 接一层 notebook skills 或 notebook MCP，通常还不够。那更像是给一个以构建成功为主要反馈的 Agent 补 notebook 工具，它当然能把 notebook 跑起来，但不一定能把数据科学任务做得更好。
在 RunCell (opens in a new tab) 里使用 Codex，变化更接近“换了一套工作环境和验收回路”。一方面，它会把 Agent 的注意力从“代码是否执行成功”拉向“结果是否由真实数据支撑、实验目标是否达成”，思路会更接近 scientist；另一方面，它提供的 notebook 辅助能力能让 Codex 直接理解 Jupyter 内核状态、变量实时值、DataFrame 内容和执行结果，很多判断不再依赖静态代码猜测，而是建立在更接近 ground truth 的运行上下文上。
如果你想先看这种工作方式，可以再读这篇 Jupyter AI Agent 将 Jupyter Notebook 变成数据科学“副驾驶”。
下面这个简短 demo 能更直观看到这种差别：
App 里的行内评论能显著缩短反馈闭环。
最佳实践
1. 先从小任务开始，逐级放大
不要一上来就给大任务。建议按这个阶梯来：
- 只做调研
- 单文件改动
- 小 bug 修复
- 修复 + 测试
- 多文件改动
- subagents + automation
这样可以更早暴露仓库约束，减少后期返工。
2. 先收紧权限和沙箱，再按需放开
Codex 官方实践建议先使用更保守的默认设置，再根据实际需要逐步放宽。这样失败成本更低。
尤其是在共享仓库或接近生产环境的场景里，一定要把人工审查保留在流程内。
3. 持久规则放在配置里，不要每次都塞进 prompt
如果 prompt 里塞太多固定规则，任务重点会被稀释。更稳妥的分工是：AGENTS.md 放长期规则，skills 放可复用流程，automations 处理定时任务。
Codex 的 skill 以 SKILL.md 为中心，再配合 references 和可选脚本，很适合沉淀重复性的 review 和发布流程。
4. 同仓库并行线程，优先用 worktree
同一个仓库里多线程并行时，worktree 可以明显降低冲突。Codex App 的 worktree 机制允许你在不污染当前工作区的前提下并行推进任务。
典型场景包括：
- 一条线程修 bug，另一条线程改文档
- 后台任务持续运行，同时手工任务继续推进
- 在不污染主工作区的情况下验证独立改动
如果没有 worktree 纪律，重叠文件改动会很快变得难以审查和合并。
5. 不要“全盘接收”，只挑选可解释的改动
不要把 Codex 输出当成自动合并输入。用 stage、revert、inline comment 逐步收敛补丁，结果通常会更稳定。
长期有效的操作模型不是 autopilot，而是“高速草稿伙伴 + 验证伙伴”。
谁更适合这样使用 Codex
新手
先用解释和修复型任务，不要一上来就追求全自动生成：
- “这个函数在做什么？”
- “这个报错的根因是什么？”
- “给我一个最小且安全的修复方案。”
这样既能学到东西，也能推进工作。
独立开发者
Codex 很适合独立项目：规划、改动、测试、审查可以放在同一个闭环里。需要并行探索或多视角 review 时，subagents 尤其有用。
团队
团队场景下，稳定性更多取决于共享规范，而不是个人 prompt 技巧。优先建设 AGENTS.md、review 机制、worktree 纪律和可复用 skills。
哪类人不太适合这套用法？
如果目标是“模糊指令一扔，结果直接全接收”，这套流程并不合适。Codex 在“意图清晰 + 差分审查 + 规则迭代”的模式下效果最好。
FAQ
Codex 对新手友好吗？
友好。建议从代码解释、小修复和调试支持开始，而不是直接让它做大规模自治实现。
应该先用 CLI 还是 App？
终端工作流优先选 CLI；更看重差分可视化和并行任务管理选 App。拿不准时，先用 CLI 建立基本闭环，再扩展到 App。
什么时候适合用 subagents？
当任务可以按视角拆分时最合适，例如探索、审查和方案比较。强耦合的单线程改动，不建议强行并行化。
AGENTS.md 和 skills 应该怎么分工？
AGENTS.md 负责仓库级规则和协作约定，skills 负责可复用的任务流程。前者是“长期规范”，后者是“可执行手册”。
Codex 的改动可以不审查直接接收吗？
不建议。相关测试和 diff review 应该是必经门槛。Codex 可以很快，但最终采纳仍然需要人工决策。
相关阅读
- AI Coding 主题页
- Codex 使用指南
- 并行代码 Agent 说明
- 用 Claude Agent SDK 构建 Claude Code 风格 Agent
- OpenClaw vs ZeroClaw vs Pi Agent vs Nanobot