Claude Code Routines：从工具到队友的主动 Agent 模式¶
Ch09.055 Claude Code Routines：从工具到队友的主动 Agent 模式¶
📊 Level ⭐⭐ | 9.5KB |
entities/claude-code-routines-proactive-agent.md
背景案例：Sarah 的文档困境¶
Claude Code 团队每周合并 PR 增长 200%，但负责两个产品文档的工程师 Sarah 工作量也跟着涨——每次代码更新，她需要手动对比变更并逐条补文档。Routines 上线后，她搭了两个 routine： 1. 每周定时：对比主分支最新变更和文档仓库，有差异就开 PR 2. 事件触发：GitHub 有新 issue 时立刻响应，判断是否是文档问题，是则自动处理
以前在 Claude Code 上跑定时任务的三道坎¶
- 在哪跑：本机跑关机就断，自己搭主机/持久化/鉴权，工作量比提示词本身还大
- 什么时候触发：cron 或 webhook 都要写 boilerplate，维护一个小系统
- 怎么知道它在干什么：headless session 是黑盒，看不见过程，无法中途插手，无法恢复中断 session
Routines 的三个能力¶
1. 始终在线（云端基础设施）¶
session 跑在 Claude Code 自己的基础设施上，不挂在用户电脑上，关机不影响。Anthropic 负责云端那些事。
2. 灵活触发方式¶
- 定时触发：每周一 10 点准时跑
- 事件触发：PR 合并、issue 被打开、或自定义 webhook 消息
- 两种可以组合用
3. 非黑盒（透明可干预）¶
每次跑起来本质就是一个普通的 Claude Code session：
- 随时去 claude.ai 上看它在干什么
- 中途插话调整方向
- 接着上次没完成的继续聊
- 不用守着，随时可以管 See also Claude Code Architecture
设计 Routine 需想清楚的三件事¶
Trigger（触发时机）¶
什么事件让 routine 开始跑？是每隔多久跑一次，还是某件事发生了才跑？两种可组合。
Context（可用信息）¶
Claude 需要访问哪些信息？要连哪些仓库？要不要接 Google Drive 里的营销材料？需不需要在完成后发 Slack 通知？上下文的天花板，就是 Claude 能做到的天花板。
Steerability（引导质量）¶
怎么保证输出质量？两种方式：
- agent-on-agent review：一个 routine 生成 PR，另一个 routine 在 PR 创建时触发，负责留 review 意见
- 人工介入：不满意就直接在 session 里继续说
- 建议在发布前验证输出，比如把文档页面真的渲染出来看看对不对
使用方式¶
然后用自然语言描述任务，Claude 反问触发时间和通知偏好，回答完 routine 就创建好了。场景示例¶
部署验证器¶
每次 CD 流水线部署完 → webhook 触发 → Claude 检查监控数据（Datadog、Grafana）→ 异常则报警/严重时回滚。建议节奏：一开始只让分析和建议，不让直接操作；观察几次后觉得判断靠谱，再慢慢放权。
Maya 的类比：就像新人员工入职前三个月不会第一周就让他独立上线代码——先让他看监控，观察他的判断跟你的判断有没有偏差。区别在于：实习者在成长，Claude 没有。被改变的那个人始终是你。
值班事件处理器¶
接 PagerDuty 或 GitHub issues，让 Claude 先做一轮初步分析，判断问题来源，给出 go/no-go 建议，再推给人做最终判断。处理的是"拿到报警到搞清楚发生了什么"的那段时间，不是最终决策。
积压工单清理¶
每周跑一次，扫 GitHub issues 或 Slack 频道里堆着的反馈，按优先级排序，为重要条目开 PR。Product Manager 也很适用。
实时介入演示（关键点）¶
演示中 Maya 创建了一个 issue，新的 session 立刻跑起来——但发现已有另一个 PR 在处理同样问题。她直接在 session 里告诉 Claude 停下来——Claude 停了。
核心洞察：不是不得不盯着它，而是随时可以去管它。这才是 Routines 作为 teammate 而非 tool 的本质区别。
深度分析¶
从工具到队友的范式转变¶
Routines 的本质不是功能叠加，而是人机协作模式的根本转变。传统 CLI 工具是"你问它答"的同步交互，Agent 是"你设定目标它执行"的异步委托，而 Routines 则更进一步——它在你没有主动发起对话时就能感知环境变化并自主行动。这意味着人类从"任务发起者"变成了"任务的最终审核者"，而非过程中的参与者。
三道坎的解决对应关系¶
Sarah 面临的三个障碍——在哪跑、什么时候触发、如何观察——恰好对应 Routines 的三个核心能力： - 云端基础设施 → 解决"在哪跑"（不依赖本地机器） - 定时+事件双触发 → 解决"什么时候触发"（不需要自己搭 cron/webhook） - 透明 session → 解决"如何观察"（不是 headless 黑盒）
这种一一对应不是巧合，而是产品设计刻意对齐用户痛点的结果。
Context 天花板悖论¶
文档强调"上下文的天花板就是 Claude 能做到的天花板"——这个说法在技术上是正确的，但在实践中有微妙之处。Claude 能访问的信息量不等于它真正能有效利用的信息量。当 Context 过大时，Claude 需要花更多 token 做检索和推理，实际能力反而可能下降。这提示我们：建 routine 时不仅要问"Claude 需要访问什么"，更要问"Claude 真正需要关注什么"。
Steerability 的两种路径对比¶
| 路径 | agent-on-agent review | 人工介入 |
|---|---|---|
| 实时性 | 下一个触发事件时 | 随时 |
| 规模化 | 可以同时跑多个 | 受限于人的时间 |
| 质量稳定性 | 取决于 reviewer 的 prompt 质量 | 取决于人的投入程度 |
| 适用场景 | 输出需要结构化验证时 | 输出需要主观判断时 |
两种路径不是互斥的——最佳实践是先用人工介入建立 baseline，再用 agent-on-agent review 规模化。
部署验证器的放权节奏¶
Maya 的"新员工"类比揭示了一个关键洞察：Agent 的可信赖程度不随时间增长。人类实习生三个月后会显著进步，Claude 不会。这意味着"先观察再放权"的策略不会自然收敛到"完全放手"——你永远需要在某个 level 上保持监督。正确的提问不是"我能不能放权"，而是"我愿意承担多大半径的失控"。
实时介入的认知意义¶
演示中最容易被忽视的细节不是"Claude 停了"，而是"Maya 能在 session 过程中直接说停"。这意味着 Routines 本质上是一个可中断的长期任务而非"一旦启动就自主跑到结束的自动化脚本"。这个设计选择让人始终处于"可以选择介入"而非"必须时刻监视"的状态——这是从 tool mindset 到 teammate mindset 的核心区别。
实践启示¶
1. 从"正确答案明确"的场景开始。 Sarah 的文档同步是个好起点——对不对容易发现，错了也容易回滚。适合作为第一个 Routines。
2. 区分"流程固定但判断微妙"的任务。 这类任务 Routines 能做，但需要想清楚哪些判断可以交出去、哪些不愿意。先观察再放权。
3. agent-on-agent review 是质量门禁的好思路。 一个 routine 生成内容，另一个 routine 在触发事件时做 review，两者形成制衡。
4. Context 边界决定能力边界。 建 routine 时先列 Claude 需要访问哪些系统和数据，这些就是上下文的天花板。
5. 不要把 Routines 当成"让它自己跑到结束的脚本"——它是一个可以随时介入的长期 session。设计时默认你会中途管它，而不是默认它会自己搞定一切。
6. 评估要不要放权时，问的不是"它够不够靠谱"，而是"我愿意承担多大半径的失控"。 这个半径会随着你对输出的观察而收缩或扩展，但永远不会归零。
7. Context 不是越大越好。 过大的上下文会增加 Claude 的推理负担，在设计 routine 时要做信息筛选而非简单堆叠。
参考链接¶
- Code with Claude 大会：https://www.youtube.com/watch?v=eSP7PLTXNy8