Anthropic 在 2026 年 4 月推出的 Claude Code Routines 是一个已保存的 Claude Code 配置：一个 prompt、一个或多个代码库和连接器，打包后在 Anthropic 管理的云基础设施上自动运行。官方文档列出三种触发类型：定时执行、API（带有 bearer token 的 HTTP POST）和 GitHub 事件。相比之下，GitHub Actions 在 GitHub 托管的 runner 上执行你编写的脚本。两者都可以按计划运行 AI 代理。它们不是同一回事，选错了会让你花钱或花大量时间调试 YAML。本文介绍了决策思路，展示了博客队列 worker 的具体实现，并涵盖故障恢复。
选择云 Routines、本地计划任务、Session 循环或 GitHub Actions
存在四种托管方式，各有区别。
云 Routines 在 Anthropic 基础设施上运行，不受你的笔记本是否开启的影响。根据官方文档，每个 routine 可以有定时触发器、API 触发器或 GitHub 事件触发器，也可以将三者组合在一个 routine 上。权衡之处在于：每次执行都会进行全新克隆，因此本地文件不可用。
本地计划任务在你的计算机上运行。它们拥有完整访问权限，包括本地文件系统、本地数据库和 .env 文件。如果计算机关闭，任务就不会运行。就这么简单。
Session 范围的定时调度（CronCreate、CronList、CronDelete 工具）仅在打开的 CLI session 内运行。这些是 session 调度工具，不是云 routines API。Session 结束时它们就消失了。
GitHub Actions 带 cron 触发器是一个 YAML 工作流文件，GitHub 在托管 runner 上执行。公开代码库免费，私有代码库成本低，行为确定，与代码库深度集成。如果你已经使用 GitHub，额外开销最小；如果不是，成本会相对较高。
那么：如何选择呢？
- 任务无论你的计算机是否开启都要运行，并且需要真正的 AI 推理（总结、起草、分类）？选云 Routine。
- 任务需要你的本地
.env、本地数据库或本地工具？选本地计划任务。 - 任务是 CI/CD 管道、PR 事件处理器或调用 API 并发送到 Slack 的确定性脚本？GitHub Actions，可能配合简短的 Python 脚本，无需 LLM。
- 任务是探索性的且仅存在于你已在运行的单个 session 中？选 Session 循环。
AI Magicx 的分析说得很清楚：如果你的 routine 是"调用 API、转换、发送到 Slack"，用 10 行 Python 脚本的 GitHub Actions 成本更低更简单。当工作真正受益于 Claude 的推理能力时——比如决定报告什么、撰写叙述、审查质量——Routines 才是正确选择。
按平台分类的持久化、本地文件和凭证
这是运维容易出错的地方。下表使用官方文档和社区研究的信息，而非声称的测试结果。
| 主机 | 本地文件 | .env | 凭证 | 笔记本关闭后仍然存在 |
|---|---|---|---|---|
| Cloud Routine | 否（全新克隆） | 否 | Routine 环境变量 | 是 |
| 桌面计划任务 | 是 | 是 | 本地配置 | 否 |
会话循环（CronCreate） | 是（会话范围） | 是 | 会话范围 | 否 |
| GitHub Actions | 仅限仓库文件 | 否 | GitHub Secrets | 是 |
Shareuhack 的 2026 年总结指出了一个值得引用的特定问题：
"每次 Cloud Routine 执行都会在 Anthropic 的云环境中进行全新克隆，无法访问您的本地 .env.local、本地数据库或其他本地状态。"
还有一点：Cloud Routine 中的网络访问默认设置为"受信"，某些 API 会直接拒绝此类请求。如果您访问 ClickUp 或其他拒绝受信模式请求的 API，请在 Routine 的环境设置中切换到"完全"网络访问。这存在较小的安全折衷，需要根据您仓库的敏感性来权衡。
对于 GitHub Actions，Secrets 存放在仓库的 Secrets 设置中，并在运行时作为环境变量注入。基于 Claude Agent SDK 构建的 anthropics/claude-code-action@v1 操作会自动获取这些 Secrets。您可以通过 claude_args 输入传递 --model、--max-turns 和 --allowedTools，以控制代理实际可以执行的操作。
阅读当前博客队列 Worker
博客队列 Worker 是一个 Routine（或等效的计划任务），它从队列中选择一篇文章、生成内容并标记为完成。这是目前的结构，明确说明了代码实际做的事和您可能假设的事之间的区别。
条件声明：Worker 在选择文章前检查该文章是否已被认领。这至少在理想情况下可以防止两个执行同时抓取同一项。目前代码缺少的是陈旧认领恢复。如果 Worker 在运行中途宕机且文章标记为"进行中"，该文章将保持认领状态，直到有人手动重置。不要将此描述为确切一次传递或保证每天一篇文章；这两个声明都超出了代码支持的范围。
工作流程图大致如下：
- 获取队列，筛选
status = queued的项目 - 认领第一个可用的帖子（设置
status = in_progress，写入时间戳） - 根据已认领帖子的元数据运行生成提示词
- 成功时：设置
status = published，写入输出路径 - 失败时：增加 retry_count，重置 status = queued（如果还有重试次数）或设置
status = failed
第 5 步是大多数团队投入不足的地方。重试逻辑需要存在于例程提示词或包装脚本中，因为云基础设施本身不会重新运行以错误状态退出的例程。
如果你在构建这样的内容管道并希望由我们处理代理层，我们在 agentic engineering 所做的工作涵盖的正是这个模式。
安排定期任务并处理重试
通过 CLI 安排例程需要 Claude Code v2.1.225 或更高版本。在 v2.1.211 之前，CLI 对没有计划触发器的例程报告虚拟的下次运行时间（第 1 年）。如果你在阅读旧日志，值得了解这一点。
仅具有 API 或 GitHub 事件触发器的例程没有下次运行时间。CLI 不显示任何内容。这是正确的行为，不是错误。
对于重试处理，你有两个选项：
- 在提示词内重试。编写提示词以重新尝试失败的步骤最多 N 次，然后再将任务标记为失败。Claude 的推理能力可以区分暂时性网络错误和真实的内容问题。
- 通过单独的计划例程重试。一个轻量级的"重新入队"例程每小时运行一次，扫描
status = queued和retry_count < 3的帖子，并通过其 API 触发器（向每个例程端点发送 POST 请求，附带持证令牌）重新触发主工作程序。
第二种模式在规模化时更清晰。它将重试策略与生成提示词解耦，你可以调整重试限制而无需触及主例程。
日运行上限和共享订阅使用情况是团队的真实限制，正如 Arcade 的企业文章所指出的那样。他们的建议是：将工作批处理到单一的日常"元编排器"例程中，并仅为高优先级事件保留实时触发器。
对于内容管道的 SEO 关键词检索方面，我们在 DataForSEO + Claude Code 中记录的自动化堆栈会单独处理，值得在你设计队列架构之前阅读。
检测卡住的认领并验证已发布的输出
过期的认领是基于队列的管道的沉默杀手。一个已处于 in_progress 状态六小时的帖子几乎肯定是卡住了，而不是在运行。
检测例程可以很简单：
- 查询
status = in_progress且claimed_at < now() - 2 hours的帖子 - 将这些帖子重置为
status = queued，清除工作程序标识符，记录重置 - 如果重置计数超过阈值，通过 Slack 或 webhook 发送告警
将其作为独立的低频例程运行（每两小时一次就可以），而不要烤进主 worker。关注点分离在这里很重要：主 worker 不应该负责清理自己的残留。
验证已发布的输出是个不同的问题。"已发布"作为状态标志意味着数据库被写入了。这并不意味着文章在网站上正确出现、通过了可读性检查，或被索引了。验证步骤应该：
- 获取实时 URL 并确认它返回 200
- 根据定义的阈值检查字数或轻量级质量信号（选择你自己的数字，并将其标记为团队启发式方法，而非通用标准）
- 如果检查失败，将状态恢复为 queued，递增 retry_count，并设置
verification_failed标志
我们在 AI Content Humanizer Pipeline 中描述的人性化管道运行类似的发布后验证步骤，如果你在构建该层，值得交叉参考。
运营成本和所有权
这就是"例程更简单"这一说法遇到摩擦的地方。
Cloud Routines 在 Anthropic 的基础设施上运行，消耗 Claude Code 会话限制的方式与交互式会话相同。研究预览明确指出：例程会消耗你的限制。对于每天运行三四个例程的小型独立开发者来说，这可能没问题。对于每天批量运行 20+ 次的团队，你会触发上限，需要围绕它进行架构设计。
GitHub Actions 对公开仓库免费，对私有仓库按分钟计费。通过 anthropics/claude-code-action@v1 在 Actions 内运行的 Claude Code 代理仍然消耗 API 令牌（按你的 Anthropic API 费率计费），但你完全控制运行器、超时和重试逻辑。这种所有权才是重点。
实际的所有权划分：
- 例程拥有：需要 Claude 推理的判断密集型任务、必须无人值守运行且无基础设施开销的任务、GitHub 触发的 PR 审查，以及 Sentry/日志分类。
- GitHub Actions 拥有：CI/CD 管道、PR 事件处理和安装流程、确定性的构建-测试-部署序列，以及任何 10 行 Python 脚本确实能完成工作的任务。
两者互不替代。Shareuhack 的文章框架得很好："最优组合让 GitHub Actions 处理 CI/CD，而例程处理推理密集型部分。"这个框架是正确的，这是值得书签的决策边界。
FAQ
Cloud Routine 能写回我的仓库吗？
能。例程连接到一个或多个仓库，它们可以通过连接的仓库推送提交和打开拉取请求。它们无法做的是访问仅存在于你本地机器上的文件。例程需要的任何东西都必须在仓库中，或在例程的云环境设置中配置为环境变量。
如果 Cloud Routine 在运行中途触发速率限制会怎样？
例程本身不会在速率限制错误时自动重试。如果它以错误退出，它会保持失败状态，直到下一次计划运行或你通过 API 端点手动触发它。在提示中构建重试逻辑（检测速率限制响应、等待、重新尝试）或使用独立的重新入队例程都是合理的缓解措施。
GitHub App 安装与 CLI 网络设置命令是分开的吗？
是的，这会让人困惑。在 CLI 中运行 /web-setup 授予例程的克隆访问权限，但不会安装 GitHub App。GitHub 事件触发的 webhook 递送需要单独的 GitHub App 安装。例程设置流程会指导你完成这一步，但这两个步骤是独立的。
研究预览期间 Routines 中的 GitHub 事件触发器有速率限制吗？
根据官方例程文档，在研究预览期间，GitHub webhook 事件受限于每个例程和每个账户的小时上限。超出上限的事件会被丢弃，直到时间窗口重置。如果你预期 PR 活动会出现突发，请相应地做好计划。
我可以在 GitHub Actions 工作流中通过 `anthropics/claude-code-action` 使用技能吗？
可以。prompt 输入接受类似 /skill-name 的技能调用。你需要在该操作前添加一个 actions/checkout 步骤，以便运行器上存在 .claude/skills/ 中的技能文件。技能和命令在 Claude Code 中是不同的概念；在混淆两者之前，请查看官方技能文档。
上面所有内容中最重要的警告：Cloud Routines 会耗尽你的 Claude Code 会话限额，就像交互式会话一样，而且当前的队列工作器没有内置的过期声明恢复机制。在发布到生产环境之前，你需要为两者都做好设计准备。