Anthropic 总算把 Loop 讲清楚了

📅 2026/7/17 3:59:53
Anthropic 总算把 Loop 讲清楚了
从运行结果看任务已经结束。可鼠标移到合并按钮附近大家还是会慢下来发布说明里是否有默认行为变化现有测试能不能覆盖认证和数据库链路如果上线后出问题回退点在哪里Anthropic 这篇文章里我更看重的是它把 Loop 从一个有点泛的概念拆成了四种清楚的工作方式。6 月 30 日Claude Code 团队在 Getting started with loops 里给出一个很朴素的定义Agent 重复执行一轮轮工作直到满足停止条件。回合式由人推动下一轮目标式让完成条件决定停不停定时式按固定时间再次启动主动式则接过一段持续到来的工作。这些做法都可以叫 Loop差别主要在于人把哪一步交给了系统。想象一下周一早上仓库里多了一张 PR。Agent 在夜里完成了依赖升级修改版本号、更新锁文件、跑完测试还把改动范围和验证结果整理进摘要。CI 是绿的。从运行结果看任务已经结束。可鼠标移到合并按钮附近大家还是会慢下来发布说明里是否有默认行为变化现有测试能不能覆盖认证和数据库链路如果上线后出问题回退点在哪里这张 PR 看起来已经完成团队却还不能放心合并。多跑几轮不难难的是留下足够证据让接手的人能快速复核也清楚出问题怎么退。四类 Loop差别在谁推动下一轮四类 Loop 最简单的区别是谁推动下一轮以及人把哪部分控制权交了出去。Loop 类型怎么运行Claude Code 里的对应能力回合式 Turn-based用户的提示启动一轮Claude 认为完成或需要更多上下文时停下人检查结果并决定下一轮普通提示 Skills 自检目标式 Goal-based人手动启动目标目标达成或到达最大轮次时停下/goal定时式 Time-based按约定间隔再次运行人取消或 PR 合并、队列清空等外部工作完成时停下/loop、/schedule主动式 Proactive由事件或时间触发无需人实时在场单个任务达成目标后退出Routine 本身持续到人关闭/schedule/goal Skills Dynamic Workflows Auto mode图 1四类 Loop 的触发方式与控制权对比这里有两个容易混在一起的细节。/loop 跑在本机电脑停了循环也就停了需要放到云端持续运行时可以用仍处于 research preview 的 /schedule 创建 Routine。主动式也不是某个单独指令。它更像一组能力的组合定时或事件负责发现工作/goal 定义单次任务怎样才算完成Skills 记录验证方法Dynamic Workflowsresearch preview组织多个 Agent 协作Auto mode 让 Routine 在无人实时在场时不会因每次权限确认而停下。这四类能力可以组合也不是从低到高的成熟度阶梯。官方的建议很克制先用最简单的方案确实需要时再增加复杂度。依赖升级完全可以停在回合式Agent 查版本、改代码、跑测试人决定是否继续。只有当检查标准稳定、停止条件可验证、权限边界也清楚时目标式、定时式和主动式才会带来额外价值。Loop 越往后人盯得越少团队越要把目标、预算、权限和例外处理留在手里。长任务不能只靠聊天记录一条 Loop 跑几个小时甚至跨过多次定时唤醒聊天记录就不再是可靠的工作账本。接手的人需要知道当前做到哪里、哪些检查已经通过、还有什么没有验证。我习惯把现场压成一条短链目标 → 当前状态 → 已做动作 → 证据 → 权限边界 → 待人决策放到团队流程里这些信息会分别落在会话内的工作回路、会话外的状态与证据以及最后的人工接手点。图 2一条 Loop 如何把执行、状态、证据和人工接手连起来依赖升级的任务卡不必很长大致写到下面这个程度就够用SPEC只升级依赖 X公共 API、认证和数据库行为不变最多 5 轮 STATE当前版本、候选版本、已尝试路径、失败原因和下一步 EVIDENCE测试命令与退出码、依赖树 Diff、发布说明中的风险项 IMPACT可能受影响的服务、用户路径和运行环境 PERMISSION可写独立分支和草稿 PR不自动合并不改生产配置 HANDOFF为什么停止哪些风险未覆盖需要谁做什么决定这不是 Claude Code 的官方格式。对应信息可以落在 Issue 字段、状态文件、CI、PR 模板和 Runbook 里不需要另造一套平台。检查标准也不宜凭空编。我的做法是抽几张近期的依赖升级 PR看 Reviewer 先读什么、搜索哪些调用点、为什么拒绝改动最后靠什么证据合并。重复出现的动作写进 Skill 或脚本个人偏好先留在人工评审里。第一版 Skill 不用写很多。测试命令、退出码、必须查看的 Diff以及命令无法执行时怎样记录阻塞比“仔细检查兼容性”更能约束 Agent 的行为。第二天接手时我一般先看状态和证据再看 Diff 与未决项自然语言总结放到最后。如果只剩一句“已经完成”复核成本只是从夜里的 Agent 转到了早上的工程师。返工原因还需要写回系统。某类 PR 如果总因许可证、默认配置或公共接口变化被拒绝这些信息应进入下一版规格、Skill 或检查脚本。否则 Loop 只是更快地重复同一种返工。CI 绿了还不能直接合并一张 PR 全绿只能说明已配置的检查通过了。Claude Routines 目前仍处于 research preview行为、限制和 API 仍可能变化。官方文档还专门提醒运行列表里的绿色状态只说明会话启动并退出时没有基础设施错误不代表提示里的业务任务已经成功。/goal 也有类似边界。它会在每轮结束后调用一个独立评估器检查目标但评估器不会自己运行命令也不会独立读取文件。它只能看到 Claude 已经放进对话记录里的证据。对依赖升级来说我更希望拿到一份可以直接复核的证据包• 跑过哪些单元测试、集成测试、构建和静态检查退出码是什么• 服务能否启动认证、数据库或关键调用链路有没有做过最小烟雾测试• 公共 API、依赖树、默认配置和发布说明里有哪些需要重点看的 Diff• 哪些环境没有跑哪些路径还没覆盖出问题时准备怎样回退。CI 往往只覆盖第一项。后面几项没有单独准备绿色状态仍可能漏掉默认行为变化、运行环境差异和公共契约破坏。再加一个 Reviewer通常能补一个新视角执行者和审查者分开也比自写自审稳。但两个 Agent 仍可能读到同一份错误规格也可能一起漏掉真实用户场景。多一个 Reviewer 能降低偏差证据仍然少不了。团队最终接收的是一组能复核、能说明边界的结果。放多少权先看错误能扩散多远四类 Loop 没有高低之分。产品方向、架构取舍和核心不变量需要人持续补上下文有些任务长期留在回合式交互里反而更合适。放权时我先看副作用。Worktree 隔离文件改动Sandbox 限制进程能访问什么权限和 Hook 决定哪些动作可以执行Checkpoint 主要负责撤回本地编辑。它们管的是不同边界数据库、外部系统和远端写入仍要单独准备回滚。无人值守时我还会多看一条组合风险不可信外部输入、敏感数据和对外写操作最好不要同时出现在同一个会话里。依赖发布说明、Issue、网页和外部日志都可能包含不可信输入。如果同一个 Agent 还能读取云凭据、生产日志或客户数据并且可以 push、发消息、写数据库几项普通能力就连成了一条完整风险路径。更实在的处理是拿掉其中一项能力或者把读取、修改和发布拆到隔离环境与人工闸门两侧。实际推进时我通常先让 Loop 只读运行观察它的判断和证据。稳定后再开放独立分支与草稿 PR。自动合并、生产写入和客户外发放得更晚必要时一直留在人手里。Armin Ronacher 对 Loop 的谨慎也来自这里。他认可代码迁移、性能实验、安全扫描和研究因为这些任务通常有机械验证或者产物不需要长期维护。到了核心代码局部防御和补丁可能在循环里一层层累积系统看起来更稳人却越来越难解释它为什么这样设计。模型能做多少是一回事。团队愿意交出多少权主要还是看错误会扩散多远出问题后能不能恢复。第一条 Loop可以这样试起点可以很小。文档漂移、CI 失败分类、依赖升级预检查和发版前核验都比生产配置修改更容易看清收益与风险。试跑时每一步都先看证据质量和接手成本再决定要不要往前放权。图 3从人工复盘、影子运行到有限自动化的试跑流程先拿几次真实任务复盘人工流程把稳定出现的检查写进 Skill。少写“仔细检查”这类空话直接给命令、退出码、需要查看的 Diff以及无法验证时怎样记录阻塞。确定性检查能脚本化就不必让模型反复判断。接着跑一段影子模式。Agent 读取相同输入并给出结果人工仍按原流程处理。这个阶段重点看有效发现、误报和漏报也看 Reviewer 要花多久才能接收一份结果。结果稳定后再允许它在独立 Worktree 里生成 Diff 或草稿 PR。团队熟悉了失败方式、成本和停止原因再加入 /goal、定时触发或有界写入。合并、外发和生产动作可以继续留给人。目标仍在频繁变化、验收主要依赖业务取舍或者会修改生产数据和客户状态的任务我暂时不会放到长期无人值守里。这条边界很难一次写准影子运行正好用来暴露缺口。如果 Agent 忙了一夜工程师第二天还要花一上午还原它做过什么自动化只是把工作换了一个地方堆起来。一条 Loop最后还是要有人接手Anthropic 这次把 Loop 讲清楚了。四种类型的触发方式不同人交出去的控制权也不同。Agent 可以替人推进下一轮、按时再检查甚至主动接过一段工作。团队仍要决定什么证据算通过哪些权限不能放遇到例外时由谁接手。回到开头那张依赖升级 PR。我宁可它停在草稿状态也希望它把改动、证据、未覆盖风险和回退方式留清楚。到这里我会把成熟的 Loop 理解成一份可运行的交接协议。该继续时继续证据不足或超出权限时把问题交还给人。第二天接手的人能在几分钟内决定继续、合并还是停止这条 Loop 才算进入了团队流程。参考资料• Claude BlogLoop engineering: Getting started with loopshttps://claude.com/blog/getting-started-with-loops• Claude Code DocsKeep Claude working toward a goalhttps://code.claude.com/docs/en/goal• Claude Code DocsAutomate work with routineshttps://code.claude.com/docs/en/routines• Addy OsmaniLoop Engineeringhttps://addyosmani.com/blog/loop-engineering/• Armin RonacherThe Coming Loophttps://lucumr.pocoo.org/2026/6/23/the-coming-loop/• Andrew NgThree Key Loops for Building Great Softwarehttps://www.deeplearning.ai/the-batch/three-key-loops-for-building-great-software• LangChainThe Art of Loop Engineeringhttps://www.langchain.com/blog/the-art-of-loop-engineering