王海（化名）是一家中型 SaaS 公司的后端工程师。团队采用 monorepo 结构，每到周五晚上，积压的 PR 少则七八个，多则十几个。手动 review 耗时耗力，完全丢给 AI review 工具又担心质量。

他尝试的解法：用 Claude Code Routines 配置了一个每周五 20:00 自动运行的代码审查 routine。Claude 会主动拉取本周所有未合并的 PR，按模块分类，生成结构化 review 报告推送到 Slack。第二天早上，他只需要花 20 分钟过一遍 AI 的报告，重点关注高风险变更。

这不是科幻场景——这是 Claude Code Routines 已经支持的真实能力。

背景：Claude Code 不只是交互式工具

Claude Code 最早以"终端里的 AI 搭档"定位——你提需求，它在本地仓库里翻代码、写文件、跑测试。但这套模式的本质还是被动响应：你在，它才动。

2026 年 4 月 14 日，Anthropic 正式发布 Routines 功能（官方文档，HN 热度 700+），将 Claude Code 的能力边界从"交互式"扩展到"自动化"。你可以定义一组任务，让它按时间表、按 GitHub 事件、或按 API 调用触发，在 Anthropic 托管的云端基础设施上自动执行——不需要保持终端打开。

框架核心拆解

触发模型：三种自动化路径

Routines 支持三种触发机制，覆盖了开发者日常中最常见的自动化场景：

① 定时触发（Cron）

triggers:
  - type: schedule
    cron: "0 9 * * 1-5"   # 每周一至周五 9:00 AM UTC

适用于：每日 standup 报告生成、代码质量巡检、定时数据拉取。

② GitHub 事件触发

triggers:
  - type: github
    events:
      - pull_request.opened
      - pull_request.merged
      - issue.comment

适用于：PR 自动 review、issue 分类、release note 生成。

③ API 调用触发

triggers:
  - type: api
    auth:
      type: bearer_token
    secret: $ROUTINES_API_SECRET

适用于：与内部平台集成、webhook 驱动的工作流、CI/CD pipeline 串联。

Routine 执行单元：Task + Tool

每个 Routine 由一个或多个 Task 组成，Task 定义"做什么"，Tool 定义"用什么工具做"。

routines:
  - name: daily-code-review
    trigger:
      type: schedule
      cron: "0 20 * * 5"
    tasks:
      - name: fetch-open-prs
        tool: github
        action: list_prs
        params:
          state: open
          base: main
      - name: review-each-pr
        tool: claude_code
        action: review_code
        context:
          pr_data: "${fetch-open-prs.output}"
        config:
          model: claude-sonnet-4-20250514
          max_tokens: 8000
      - name: post-to-slack
        tool: slack
        action: send_message
        params:
          channel: "#engineering"
          message: "${review-each-pr.output}"

云端执行架构

Routines 运行在 Anthropic 托管的基础设施上，不依赖本地终端：

%%{init: {'theme': 'neutral'}}%%
flowchart TB
    subgraph Triggers
        Cron["Cron Scheduler"]
        GH["GitHub Webhooks"]
        API["API / Webhook Endpoint"]
    end

    subgraph RoutineEngine
        Parser["YAML Parser"]
        Executor["Task Executor"]
        ContextMgr["Context Manager"]
    end

    subgraph Tools
        GitHub["GitHub API Tool"]
        ClaudeCode["Claude Code Tool"]
        Slack["Slack API Tool"]
        Custom["Custom API Tool"]
    end

    Cron --> Parser
    GH --> Parser
    API --> Parser
    Parser --> Executor
    Executor --> ContextMgr
    Executor --> GitHub
    Executor --> ClaudeCode
    Executor --> Slack
    Executor --> Custom

    ContextMgr --> Output["Structured Output<br/>/ Slack / File"]

关键优势：上下文持久化——同一 Routine 的多次执行可以访问历史状态，实现增量分析而非每次从零开始。

与传统 CI/CD 的区别

关键洞察：工程化落地的三个建议

1. Routine 不等于 Script——设计好上下文边界

Routines 的强大之处在于 Claude 对代码库的语义理解，但这也意味着每次执行都在消耗 token。不要让一个 Routine 试图做所有事情。

推荐做法：按职责拆分多个小 Routine，通过 Slack 消息或文件作为它们之间的数据传递媒介。比如 daily-pr-fetcher 只负责拉取数据写入 pr-summary.json，pr-reviewer 读取该文件做 review。

2. API 触发模式下的安全性配置

Routines 的 API 触发支持 Bearer Token 认证，但这意味着你的 $ROUTINES_API_SECRET 需要安全存储。

# 推荐：通过环境变量注入，不写在 YAML 里
claude routines create --name my-routine --env ROUTINES_API_SECRET

如果与 GitHub Actions 集成，推荐使用 GitHub Apps 而非 Personal Access Token，避免 token 泄露导致仓库权限被滥用。

3. 定时任务的时区陷阱

cron: "0 9 * * *" 默认是 UTC，而大多数团队的作息是 UTC+8（北京时间）。如果希望"每天早上 9 点"运行，需要写成 cron: "0 1 * * *"（UTC 1:00 = 北京时间 9:00）。Anthropic 文档明确建议在 cron 表达式旁加上注释说明对应的本地时间。

信源引用

• Claude Code Routines 官方文档（HN 热度 700+，本文核心信源）
• GitHub: anthropics/claude-code（Stars 114k+，最新提交 2026-04-16）
• HN Discussion: Claude Code Routines

总结

Claude Code Routines 代表了 AI 编程助手从"被动工具"向"主动自动化同事"的进化。对于工程团队而言，它的最大价值不是替代人类，而是接管那些结构清晰、重复性强、但需要代码语义理解的工作——定时 code review、release note 生成、依赖安全巡检……

关键落地原则：保持 Routine 职责单一、善用 API 触发时的安全配置、注意时区换算。如果你在团队中承担着大量"每天都要做但不需要深度思考"的工作，Routines 值得投入 1-2 小时认真配置。

去年年底，某中型技术团队上线了一套"AI 自动编程流水线"——基于 GPT-4 和代码仓库，每天自动完成 Issue 分解、代码编写和 PR 提交。前三天一切顺利，团队颇有成就感。

第四天早上，他们发现：Agent 在凌晨 3:17 因为一次 API 超时陷入死循环，在 Slack 群里疯狂刷屏了 400 多条错误日志，但没有任何机制让它停下来。值班工程师被叫醒后花了 2 小时才手动终止进程、清空状态、重置上下文。

这不是某家公司的个别故障。当我们把 LLM 放进一个需要长时间运行的自动化流水线时，几乎必然遇到三个结构性难题：LLM 无状态、任务周期远超单次调用时长、API 不稳定。而大多数团队用来解决这些问题的方案，要么过度依赖人工盯守，要么干脆祈祷 API 别出问题。

OpenClaw¹ 试图回答一个更根本的问题：如果把 AI Agent 当作一台计算机而不是聊天机器人来设计，这些问题是否可以被工程化地解决？

为什么说"AI 编程助手"这个定位错了

在深入 OpenClaw 的架构之前，需要先纠正一个常见的理解偏差。

当我们用"AI 编程助手"来描述 Claude Code、Copilot Workspace 这类产品时，隐含的假设是：人类的每一次操作，都是一次独立的、完整的会话。用户给一个指令，AI 给一个回复，结束。

但一旦你开始构建自动化流水线，这个模型立刻崩塌——因为流水线的核心特征是：异步性（任务可能跨越数小时甚至数天）、容错性（中途可能有 API 超时、网络抖动、模型幻觉）和状态持久性（下一轮执行必须知道上一轮做到哪了）。

OpenClaw 的核心洞察是：LLM 本身是一个无状态的"CPU"，而不是一个有记忆的"服务器"。 因此，要构建长期运转的 AI 流水线，必须给它配上一块"硬盘"——也就是持久化的状态文件。

这就是 OpenClaw 的架构起点。

离散状态机：把连续任务切成互不干扰的阶段

OpenClaw 采用了离散状态机（Discrete State Machine）的设计思想。简单来说：它不要求 AI 在一次调用中完成整个复杂任务，而是把任务切分成多个阶段（Phase），每个阶段都有明确的输入文件、输出交付物和状态转移条件。

stateDiagram-v2
    [*] --> Idle: 项目初始化
    Idle --> Phase1_Architecting: 启动架构设计
    Phase1_Architecting --> Phase1_Architecting: 执行中
    Phase1_Architecting --> Waiting_HITL: 架构文档生成完毕
    Phase1_Architecting --> SelfHeal: 超时/崩溃检测
    Waiting_HITL --> Phase2_Coding: 人类批准
    Waiting_HITL --> [*]: 人类拒绝
    SelfHeal --> Phase1_Architecting: 重试
    SelfHeal --> Phase1_Architecting: 跳过（已完成）
    Phase2_Coding --> Phase2_Coding: 执行中
    Phase2_Coding --> Waiting_HITL: 危险操作需确认
    Phase2_Coding --> Phase3_Testing: 编码完成
    Phase3_Testing --> Phase3_Testing: 执行中
    Phase3_Testing --> [*]: 测试通过/终止

每一轮调度（通常是 Cron 触发），Agent 醒来后第一件事不是"直接干活"，而是读取状态文件，确定自己处于哪个 Phase、上一轮完成了什么、接下来该做什么。

状态文件：Agent 的"硬盘"

状态文件是整个架构的支柱，本质上是一个 JSON 结构体：

{
  "project_id": "backend-api-v3",
  "current_phase": 2,
  "phase_status": "in_progress",
  "last_active_time": "2026-04-09T03:17:42Z",
  "target_deliverable": "src/handlers/auth.go",
  "heartbeat_interval_minutes": 20,
  "retry_count": 0
}

这个文件存在项目根目录，是整个流水线的 Single Source of Truth。Agent 每次苏醒，第一条指令永远是：读取这个文件。

这种设计有几个关键优势：

• 崩溃透明：如果 Agent 崩溃，状态文件不受影响。下一轮醒来，它从状态文件恢复，理论上可以从断点继续
• 多 Agent 协作：不同阶段的 Agent 可以是不同的模型（Phase 1 用 GPT-4o 做架构，Phase 2 用 Claude 3.7 Sonnet 写代码），只要它们都遵守同一个状态文件协议
• 人类介入点清晰：只有状态转为 waiting 时才需要人类干预，其余时间 Agent 完全自主

自愈机制：Agent 崩溃了怎么办？

仅有状态文件还不够。在真实环境中，Agent 可能因为各种原因中途"死亡"：API 超时、模型生成超长上下文导致的 OOM、或陷入无限循环。

OpenClaw 的解决方案是双重校验自愈：

1. 心跳超时检测：每次苏醒时，比较 last_active_time 与当前时间。如果差距超过 heartbeat_interval_minutes（通常设为 20 分钟），判定上一轮 Agent 已经死亡。

2. 交付物校验：死亡后，不直接重试，而是先检查 target_deliverable 对应的物理文件是否已经存在且内容完整。如果存在，说明上一轮其实已经完成了工作，只是没来得及写回状态文件——此时系统自我修正，将状态推进到下一 Phase。

3. 真重试：如果物理文件不存在，说明任务确实中途失败，此时刷新时间戳，重新执行当前 Phase。

这套逻辑的核心是：不要相信 AI 的自我报告，要相信物理文件的存在。文件是客观存在的，AI 的上下文是主观的、可能被污染的。

HITL 的正确姿势：只在拐点介入

Human-in-the-Loop（人类介入）是大多数 AI 自动化系统设计失败的重灾区。两种极端都不好：

• 过度 HITL：每次代码生成都要人审批，导致人类产生通知疲劳，最终变成无脑点"通过"
• 零 HITL：完全自主运行，结果失控时没有任何安全网

OpenClaw 的原则是：只在架构拐点请求介入，日常执行保持绝对静默。

具体判断标准：

当触发必须挂起的情况时，Agent 向人类发送消息的方式也很有讲究。OpenClaw 建议所有通知必须带上身份前缀，例如：

[backend-api-v3 流水线 · Phase 2 待审核]
架构设计已生成，请确认后我将继续执行编码任务。

这看起来是小事，但在团队同时跑多个 AI 自动化任务时，带身份前缀的消息能极大降低认知负担，让工程师一眼看出这条消息来自哪个项目、哪个阶段。

角色解耦：为什么不能让一个 Agent 从头写到尾

传统的"单一 Agent 全流程"有一个根本问题：不同的任务需要完全不同的思维模式。

• 架构设计阶段需要发散性思维，要把问题展开，考虑多种路径
• 编码阶段需要收敛性思维，要根据既定架构死磕实现，处理各种边界情况
• 测试阶段需要"挑刺"心态，要主动寻找漏洞和安全问题

把这三种思维塞进一个 System Prompt，让同一个 Agent 在同一个会话里完成所有工作，结果通常是每个阶段都做得"还行"但都不够好——模型会在发散和收敛之间反复横跳。

OpenClaw 的解法是通过 Phase 动态切换 Agent 的"角色面具"：

• Phase 1（架构师）：被配置为发散型 Prompt，输出 Markdown 架构文档
• Phase 2（工程师）：被配置为收敛型 Prompt，严格按照架构文档执行代码实现
• Phase 3（QA）：被配置为对抗型 Prompt，专注于寻找漏洞和边界 case

阶段之间的交接通过物理文件完成，而不是上下文记忆——Phase 1 的输出文件是 Phase 2 的输入文件，Phase 2 的输出文件是 Phase 3 的输入文件。这种"物理交接"保证了信息传递的零损耗。

实时性与稳定性的取舍

OpenClaw 的架构本质上是在做一个取舍：用实时性换稳定性。

传统的 LLM 调用是同步的：我发一个请求，等一个回复，完成。但 OpenClaw 把这个过程变成了异步的：发起任务 → 等待状态转移 → 检查交付物 → 继续或终止。

这意味着：

• 好处：可以 7x24 小时运行，中途崩溃可以恢复，不需要人工盯守
• 代价：单次任务完成的周期变长（从分钟级变成小时级甚至天级）

对于需要快速反馈的场景（如 IDE 内实时补全），这显然不是正确的方案。但对于后台自动化流水线（CI/CD、数据管道、报告生成、代码审查），这个取舍是值得的。

给工程师的实践建议

如果你想在自己的团队里引入类似的架构，有几个关键点需要注意：

1. 从单文件状态机开始 不需要上来就搞一整套复杂的多 Phase 系统。从最简单的开始：在项目根目录放一个 pipeline_state.json，每次 Cron 触发时读取它、判断该做什么、执行、覆写状态。最小化可行系统跑通后，再逐步增加 Phase。

2. 心跳间隔要足够长但不能太长 设得太短（如 5 分钟）会导致误判——LLM 生成本身就可能花 5-10 分钟。设得太长（如 2 小时）会导致问题发现太晚，损失太大。20-30 分钟是一个经过验证的合理起始值。

3. 交付物校验要定义清晰 “文件存在"不等于"工作完成”。你需要定义清楚每个 Phase 的完成标准——是文件存在就够了，还是需要文件通过 lint/编译/测试？标准越清晰，自愈判断越准确。

4. 日志要写入状态文件 每次状态转移时，把转移原因（成功完成/超时重试/HITL 批准）写入状态文件的 history 字段。这个日志是事后排查问题的唯一依据。

¹ OpenClaw GitHub: https://github.com/openclaw/openclaw | 353k stars, 活跃维护中