Anthropic 内部维护 Routines 共创建 388 个 PR，其中 180 个经过 Claude Code Review 和人工审查后合并。两者相除是 46.4%。这组数据证明定时 Coding Agent 能持续产出可合并变更，但它无法直接表示模型成功率。其余 208 个 PR 混合了等待、重复、范围不符、CI 失败、审查拒绝和 Agent 失败等未知状态。
生产系统应该使用带明确退出原因的审查漏斗。
证据核验日期：2026 年 8 月 19 日。388 和 180 来自 Boris Cherny 的公开说明；工作流行为以当前 Claude Code 官方文档为准。
阅读时间：约 8 分钟 · 全文约 2900 字
核心结论
- Claude Code Routines 是由定时、API 或 GitHub 事件触发的自主云端 session，目前仍处于 research preview。
- 绿色运行状态只代表 session 正常启动并退出，没有基础设施错误。Anthropic 文档明确说明，它不代表分配的任务成功。
180 merged / 388 opened = 46.4%把生产产出、排队状态和拒绝原因混进同一分母，无法单独测量模型质量。- 从触发到合并后未被回滚，至少需要九个阶段。每一层都要统计数量、耗时和退出原因。
- Claude Code Review 属于 best-effort，默认返回 neutral check。团队希望审查结果成为合并门时，需要额外 CI 或人工批准。
46.4% 的分母里有什么
Boris Cherny 披露，Anthropic 连续数周在 iOS、Android、桌面端、Web、CLI 和 Agent SDK 上运行每日 Claude Code Routines。任务包括 crash fuzzing、重复代码合并、死代码删除和抽象层清理。
这些 Routines 共创建 388 个 PR，其中 180 个通过自动 Claude Code Review 与人工审查后合并。
因此，46.4% 是一个有效的观察比例：
报告时已合并 PR / 全部已创建 PR
= 180 / 388
= 46.39%
它的分母并非已经关闭的 PR。公开资料没有说明其余 208 个 PR 中有多少仍在等待、已经被替代、属于重复工作、遭到拒绝或存在技术错误。首次 CI 通过率、审查轮次、合并后缺陷和回滚率也没有披露。
反过来把 53.6% 称为失败率同样有问题。重复维护 PR 可能说明 Routine 缺少共享状态；正确 PR 可能因为 reviewer 过载而排队；其他变更先合并后，原任务可能已经过期。这些属于工作流流失，未必是编码失败。
Run 健康与任务成功属于不同状态
Anthropic Routines 文档直接说明：绿色状态表示 session 正常启动并退出，没有基础设施错误。网络请求被拦、connector 缺失和任务级失败只会出现在运行记录中，不会改变这个绿色状态。
至少要分开三个结果：
| 状态 | 回答的问题 |
|---|---|
| 基础设施完成 | 云端 session 是否正常启动并退出 |
| 任务完成 | Routine 是否产出 prompt 定义的结果 |
| 业务验收 | 仓库和 reviewer 是否接受变更，变更上线后是否稳定 |
合并成一个 success 字段后，系统会失去改进方向。基础设施错误需要修平台，无产物运行需要改任务发现，CI 失败需要加强本地验收，审查拒绝则可能来自代码质量、重复工作、架构分歧或优先级变化。
九阶段审查漏斗
每一阶段记录数量、转化率、排队时间和退出原因：
- Triggered runs：定时、API 或 GitHub 事件已经触发。
- Infrastructure-complete runs：session 没有平台级错误并正常退出。
- Acceptance-complete runs：仓库指定的命令和产物检查通过。
- PRs opened：存在可审查 diff、范围说明和验证证据。
- CI-passing PRs：测试、lint、类型、安全扫描和策略检查通过。
- Machine-review-cleared PRs：自动审查没有留下超过团队阈值的未解决问题。
- Human-approved PRs：责任 reviewer 接受范围和设计。
- Merged PRs：变更进入目标分支。
- 7 天或 30 天后未回滚：变更通过生产反馈。
第一张有用图表是一条旁边带退出原因分布的漏斗，而非一个头条比例。
改模型前，先给 208 个 PR 分类
给每个退出项分配互斥的主原因，必要时再加辅助标签：
| 退出原因 | 优先控制手段 |
|---|---|
| 没有可执行工作 | 改进发现查询与任务资格 |
| 重复或已被替代 | 增加仓库级任务领取与去重状态 |
| 范围不符 | 收紧目标文件、owner 和变更预算 |
| 环境或 connector 失败 | 修复 setup、权限或网络策略 |
| 验收命令失败 | 改进实现闭环或任务选择 |
| 自动审查拒绝 | 把 finding 回灌当前或下一次运行 |
| 人工拒绝：正确性 | 加强测试与任务上下文 |
| 人工拒绝：设计 | 转入讨论或设计任务 |
| 等待人工审查 | 增加审查能力或降低到达速率 |
| 合并前已经过期 | 缩短周期并在审查时重新核验 |
| 合并后回滚 | 将逃逸失败加入回归测试 |
这套分类可以避免常见误判：最大流失来自排队、任务过期或仓库合同缺失时，团队却去升级模型。
Agent PR 的独立研究支持这种拆分。一项 2026 年研究分析了 9799 个经过人工审查的 Agent PR。被拒 PR 中，只有 35.7% 能明确归因于 Agent 失败；31.2% 涉及工作流约束，另有 33.1% 缺少可观察的决策理由。缺少拒绝原因本身就是测量失败。
验收标准必须可执行
Routine prompt 需要定义仓库里的完成状态，并用命令与硬限制补充自然语言：
eligible scope: packages/parser/**
required evidence: 修改前测试失败，修改后测试通过
required checks: unit, typecheck, lint, security policy
change budget: 未经任务账本批准，最多修改 5 个文件
output: draft PR，包含摘要、风险、测试证据和回滚说明
forbidden: merge、推送保护分支、未经审批增加依赖
Claude Code Routines 在运行中没有 approval prompt，可以使用选定仓库、环境变量、网络访问和 connectors。通过已连接身份执行的动作会显示为用户本人。最小权限和外部验收合同因此比超长 prompt 更重要。
跨运行状态应保存在 session 之外。每次触发都会创建新 session，可用 issue、仓库文件或持久任务账本记录已领取任务、历史尝试、已知失败和审查结果。下一次运行先读取这些状态，再决定是否创建新变更。
自动审查是信号，合并权在外部
Anthropic Code Review 使用多个 Agent 检查、验证、去重并对 finding 排序。官方文档同时说明，它属于 best-effort，失败后不会自动重试，并默认返回 neutral GitHub check。neutral check 不会自动阻断 branch protection。
团队希望高严重性 finding 阻断合并时，需要额外 CI 读取结构化结果并让 gate 失败。Anthropic 产品说明也明确保留了人的最终批准权。
由此可以形成清晰的控制模型：
- Routine 提议变更。
- 验收命令生成确定性证据。
- 自动审查补充发现缺陷。
- CI 执行机器可读策略。
- 人对范围与设计负责。
- 合并后监控判断结果能否长期成立。
Ramp 的 Codex 工作流已经展示生成量提高后审查成为瓶颈。审查漏斗让这个瓶颈变得可测量。AI Agent 规则为什么需要提交门控则提供执行层。
支持决策的仪表盘
至少报告：
- 首次验收通过率；
- 每个基础设施完成 run 的 PR 创建率；
- 首次 CI 通过率；
- 按严重性统计的自动审查 finding 率；
- 人工触达率与审查轮次；
- 排队时长中位数与 p95；
- 已关闭 PR 的合并率；
- 重复与过期比例；
- 7 天和 30 天回滚率；
- 每个未回滚合并消耗的算力与 reviewer 分钟。
所有数据按 Routine、仓库、任务类型、模型和 prompt 版本拆分。总体均值可能掩盖一个表现优秀的死代码 Routine 和一个风险很高的抽象重构 Routine。
目标也不应是最大化 merge rate。一个只创建琐碎、必然合并变更的 Routine 可以轻易刷高比例。更好的目标是在风险预算内，用更少算力与审查注意力产出更多有价值、未被回滚的变更。
常见问题
Claude Code Routines 是什么？
它是保存在云端的 Claude Code 配置，包含 prompt、仓库、环境和可选 connectors。定时、API 或 GitHub 事件会启动新的自主 session。
绿色运行状态是否代表任务成功？
绿色只表示 session 正常启动并退出，没有基础设施错误。任务是否成功需要读取运行记录和显式验收证据。
46.4% 是否是 Claude Code 成功率？
它是报告时全部已创建 PR 中已经合并的比例。缺少其余 PR 的状态和退出原因时，这个数字无法单独表示模型准确率或最终关闭 PR 的接受率。
Routine 是否应该自动合并 PR？
按风险分配权限。低风险、测试充分的变更可以经过确定性检查和策略门后自动推进。架构、安全、依赖和高爆炸半径变更应保留可问责的人工批准。
最重要的漏斗指标是什么？
先看数量最大的退出类别及其排队时间。它会指出当前瓶颈位于任务选择、执行、CI、自动审查、人工审查还是合并后质量。