BotOf TechAI / IoT / Full-Stack / 植物养护
返回首页Claude Code 的 loop、Routines 和生产化 Agent：别把循环误会成自动驾驶

Claude Code 的 loop、Routines 和生产化 Agent：别把循环误会成自动驾驶

·5 分钟阅读·
Claude CodeAgentWorkflowArchitecture

这两天很多人把 Claude Code 的 /loop、Routines、scheduled tasks 混在一起讲，像是 Claude Code 已经可以完全自己跑业务了。

我觉得要先降一点温：loop 是循环，不是自动驾驶；Routines 是托管运行，不是生产系统；真正能进生产的，是围绕 Agent 的 harness。

这三个概念不分清，最后很容易做出一个看起来会跑、但出错无法恢复的自动化脚本。

三种“循环”不是一回事

能力运行位置触发方式适合场景风险
/loop当前 CLI session重复执行同一 prompt快速 polling、等 CI、观察某个状态没有生产级状态管理
Desktop scheduled tasks本机本地计划任务需要访问本机文件和工具的重复任务电脑关机或环境变化会影响
RoutinesAnthropic 托管云环境schedule、API、GitHub event夜间 PR review、告警 triage、docs drift、部署验证无交互审批，权限要提前收紧
Production harness自建系统队列、事件、webhook、人类指令多仓库、多角色、长期运行的工程流水线需要真正的软件工程治理

官方文档对 /loop 的描述很克制：在 CLI session 里重复一个 prompt，适合 quick polling。它不是队列系统，也不是工作流引擎。

Routines 更进一步：把 prompt、repositories、connectors 和 triggers 存成配置，跑在 Anthropic-managed cloud infrastructure 上。它可以按时间跑，可以被 API 调起，也可以监听 GitHub 事件。但文档也说得很清楚：Routines 仍在 research preview，行为和 API surface 可能变化。

loop 的真实用法：把等待变成主动检查

/loop 最适合的不是“每小时帮我维护一个项目”，而是这种短周期场景：

  • 等 CI 跑完，失败就总结日志；
  • 等本地 dev server 启动，成功后跑冒烟检查；
  • 观察某个文件或接口输出，直到状态稳定；
  • 轮询部署结果，发现错误时停下来要求人确认；
  • 重复执行一个检查清单，直到满足退出条件。

它的关键不是循环次数，而是退出条件。

好的 loop prompt坏的 loop prompt
每 2 分钟检查 CI，最多 5 次；失败时只总结日志，不改代码一直检查 CI，直到成功
如果接口连续 3 次返回 200，就停止并报告帮我盯着服务
如果发现新错误，先停下来问我，不要自动部署有问题就修
只读日志，不运行写入命令看看线上怎么样

loop 没有明确边界，就会变成“一个不断放大错误的 while true”。

Routines 的价值：把重复工作变成云端 session

Routines 真正有意思的地方，是它把 Agent 从“我正在终端里盯着它”变成“我给它一个可重复配置，它按触发条件自己开 session”。

它适合那些“重复、结果清楚、风险可控”的工作：

场景Routine 可以做人类仍要做
夜间 PR review按团队 checklist 留评论和总结判断设计取舍
告警 triage读取 alert、关联 commit、开 draft PR决定是否合并
部署验证跑 smoke check、查日志、发 go/no-go决定是否回滚
文档漂移扫 merged PR，开 docs update PR审稿
SDK port监听一个语言仓库变更，开另一个语言的同步 PR处理语义差异

它不适合“没有退出标准、没有权限边界、会直接影响客户”的事情。

Routines 最容易踩的坑

官方文档里有几句很关键：Routine 运行时没有 permission-mode picker，也没有 approval prompts；它能访问什么，取决于你选了哪些 repositories、环境网络、环境变量和 connectors。

这意味着配置阶段就是安全阶段。运行时你没法指望它每次都问你。

风险具体表现处理方式
权限过大默认包含不需要的 connector创建 Routine 时移除无关连接
网络过宽云环境能访问不该访问的服务用 environment 控制网络白名单
写入不可控能 push 到非 claude/ 前缀分支默认只允许 Agent 自己的分支
成功假象run list 是绿色，但任务其实没做完必须打开 transcript 看真实结果
事件风暴GitHub event 太多，重复开 session用 filter 限制 PR、label、branch

我的建议是：Routine 的 prompt 里必须写“什么算成功、什么算阻塞、什么不能做”。如果你写不清楚，就不该让它自动跑。

Medium 上的生产化经验：Agent 需要 harness

Medium 最近有几篇 Claude Code 相关长文很值得看。最有启发的是一个 production agent harness 的案例：作者把 Claude Code 放进一个多 Agent 工程流水线里，核心不是“模型更强”，而是 runtime scaffold。

这个 harness 包括：

  • 事件入口：Slack、MR、CI、告警；
  • 调度层：把任务分给不同 agent；
  • 状态层：记录任务、评论、失败、重试；
  • 自愈循环：CI 失败后能回到任务上下文；
  • 观测层：知道 Agent 做了什么；
  • 控制面：人能暂停、接管、审查。

这和官方 Routines 是互补关系。Routines 给你托管 session 和触发器；harness 解决“长期运行的软件系统应该如何可靠地活着”。

Recoverable，比 autonomous 更重要

另一篇 Medium 文章讲得更直接：Agent 一定会失败。真正的问题不是怎么让它永远不失败，而是怎么让失败可恢复。

这点非常实际。一个 Agent 如果只是读文件、改代码、跑测试，失败还好；一旦它开始碰真实系统，就会有非确定性：

  • 第三方 API 503；
  • 支付成功但库存没锁；
  • PR 已更新但本地还是旧分支；
  • CI 失败原因来自 flaky test；
  • 两个 Agent 改了同一处代码；
  • 用户中途改变需求。

所以 loop / routine / harness 都需要这几样东西：

机制为什么需要
幂等 key同一个动作重复执行不会产生两次副作用
补偿动作外部系统成功一半时能回滚或修正
状态机知道任务在哪一步失败
审计日志事后能还原 Agent 做过什么
人类接管点高风险或不确定时暂停
超时和预算防止无限循环烧 token 和 API

“能自己循环”只是第一步；“失败后不把系统弄坏”才是工程门槛。

多 Agent 协作：Git 可能是最低摩擦的消息总线

还有一篇 Medium 文章讨论 Claude Code 和 Codex 通过 Git 做实时对话。它用的是一个很有意思的思路：把 Agent 消息写成 append-only JSONL，放在 Git refs 里，通过 push/pull 传播。

这个方案不一定是最终形态，但它抓到了多 Agent 协作的一个关键点：Agent 之间的通信也要可审计、可合并、可复现。

通信方式优点缺点
直接聊天简单难审计，容易丢上下文
Slack / IM人类可见结构化弱，和代码状态脱节
数据库队列工程化强需要额外服务
Git append-only log和代码同源、可版本化实时性和协议能力有限

如果多个 Agent 都在一个仓库里工作，Git 作为通信底座并不荒唐。它至少能让每一次交接变成版本历史的一部分。

我会怎么落地

如果要在团队里用 Claude Code 做自动化，我会按四层推进：

  1. 先用 /loop 做短周期、只读或低风险轮询。
  2. 再用 Routines 做重复、边界清楚的云端任务。
  3. 再把高价值流程接入队列、状态机和审计。
  4. 最后才谈多 Agent 协作和跨仓库调度。
阶段可以自动化不该自动化
loop等 CI、查日志、跑只读检查自动合并、自动部署
Routine定时 review、docs drift、draft PR无审查地改生产配置
Harness多仓库工程流水线、告警修复草案没有状态机的真实副作用
Multi-agent分工探索、互审、跨模型验证多个 Agent 同时无锁写同一文件

我的判断

Claude Code 正在从“人盯着终端”走向“事件驱动的工程系统”。/loop 是最小循环，Routines 是托管循环，production harness 是能长期工作的系统。

不要把任何一个循环误会成自动驾驶。真正成熟的 Agent workflow，一定会长出队列、状态、幂等、补偿、审计和人类控制面。少了这些，自动化越强，事故半径越大。

来源

← 返回所有文章