今天任何一个开发者不需要从头搭建调度器和评估框架就能直接用 /loop、/goal、/schedule 组合出一个属于自己的自动化工作流——从盯 PR、修 CI到批量处理 bug 报告、跑定时的代码迁移任务。Claude Code 负责人 Boris Cherny 说的一句话我已经不再手动 prompt Claude我的工作是写 loop这句话在 2026 年 6 月点燃了整个 AI 开发者社区。几乎同一时间开发者 Peter Steinberger 喊出了类似观点Google 工程师 Addy Osmani 把这个正在发生的转变提炼成了一个词——loop engineering循环工程。这不是凭空造词。从 2024 到 2026 年AI 辅助编程经历了一条清晰的演进路径Prompt Engineering精心打磨一句提示词让模型一次给出好答案。Context Engineering不只调提示词还精心组织喂给模型的上下文。Harness Engineering设计工具、权限、框架把模型套进一个可靠的执行环境里。Loop Engineering不再手动触发每一步而是设计一个自己生成任务、自己执行、自己检查、自己决定要不要继续的系统。每一层都比前一层更进一步地把人从每一步都要盯着的位置上挪开。Anthropic 没有把这仅仅当流行语看待而是把它做成了 Claude Code 的原生功能——/loop、/goal、/scheduleroutines以及更进一步的 Dynamic Workflows。这篇文章从loop 到底是什么讲起一路讲到底层运行机制再到你今天就能上手的具体代码。01、什么是 LoopFOUNDATION · 先回到最基础的循环智能体循环的五个步骤Claude Code以及 Claude Agent SDK本身就是一个循环驱动的系统。这个循环叫agentic loop智能体循环是所有更高级 loop 形态的地基。不管是让 Claude 列文件还是重构整个鉴权模块底层跑的都是同一套循环1 .接收 prompt连同系统提示词、工具定义、对话历史一起。2.评估并响应判断下一步可能输出文本、请求工具调用或两者都有。3.执行工具每个被请求的工具被实际执行结果反馈给 Claude 做下一步判断。4.重复一次完整的评估 执行工具算一个turn轮次直到输出不再包含工具调用为止。5.返回结果循环终止输出最终文本、token 用量、花费和会话 ID。举个例子让 Claude修复 auth.ts 里失败的测试一次完整会话大致长这样Turn 1调用 Bash 跑 npm test拿到三个失败用例。Turn 2调用 Read 读取 auth.ts 和 auth.test.ts。Turn 3调用 Edit 修改代码重跑测试三个用例全部通过。最终轮输出纯文本不再调用工具——已修复 auth 的 bug三个测试都通过了。这就是一次完整的、4 个 turn 构成的 agentic loop。它已经具备自动重试直到成功的雏形——但仍是手动触发的你发一次 prompt循环跑一次结束后需要再发下一个 prompt。这正是 loop engineering 想打破的边界。手动 loop 的天花板在 loop engineering 兴起前资深开发者早就在用土办法突破边界——业内戏称Ralph loop一个粗暴的 bash 脚本循环里反复喂同一个 prompt直到某个条件满足才退出。它的痛点很直白没有停止条件纯靠死循环 人盯着要么提前退出留半成品要么无限空转烧 token。自己给自己打分不可靠让同一个模型既写代码又判断够不够好几乎总是倾向于我觉得可以了。没有持久化记忆每次循环从零开始不记得上一轮学到了什么。人工调度要靠人决定什么时候跑、跑多久、跑完了怎么办。Anthropic 的工程团队把这些土办法原生化成了产品功能——这就是接下来要讲的/loop、/goal和 Dynamic Workflows。02、原理Loop 是如何被升级的PRINCIPLE · 几层新原语loop engineering 不是发明了全新技术而是在原有 agentic loop 之上叠加了几层新的原语primitive。从轮次驱动到目标驱动/goal最原始的循环是轮次驱动——发一句话跑几轮工具调用给答案结束。/goal 把它升级成目标驱动不再关心跑几轮而是定义一个完成的判定标准。运行机制1.给出一个可验证的成功条件比如所有测试通过lint 无报错。2.Claude 执行任务每次它认为可以停下来时交给一个独立的评估模型去核验。3.没满足就打回去继续跑满足了才真正终止给出目标达成的总结。核心设计生成者与评估者分离让模型给自己刚写完的代码打分它几乎总是手下留情——它已经相信自己做对了。训练一个独立的、带着怀疑态度检查结果的评估者比让生成者自我批判容易得多。Anthropic 内部用 Fable 5 做实验也发现独立上下文窗口里运行的 verifier 子 agent表现持续优于自我反思式的自我审查。确定性的判定标准测试通过数量、分数阈值比你觉得好不好这种模糊标准有效得多——它把什么算完成这件事从模型的主观判断变成了可以被独立系统核验的客观事实。从目标驱动到时间驱动/loop/goal 解决怎么判断该不该停/loop 解决怎么让任务反复自己跑起来不用每次手动重发。它按固定时间间隔重新执行同一个 promptCMD/loop 5m check my PR, address review comments, fix failing CI意思是每 5 分钟重新检查一次 PR、处理评审意见、修复失败的 CI。它运行在本机上关掉就停止——这是它和云端方案最大的区别。适合场景输入会变化、但任务本身不变的重复性工作。从本地到云端/schedule 与 Routines/loop 有个明显局限——得开着机器。/schedule 把循环挪到云端变成routine例行任务触发方式是事件或调度触发且全程无人值守最适合成规模、定义清晰的重复性工作流bug 分诊、依赖升级、代码迁移常规简单任务可以路由给更小更快的模型只在关键节点才调用最强模型。CMD/schedule daily 9:00 triage new bug reports更进一步Dynamic Workflows在单一 agent 循环之上Claude 还能自己编写编排脚本并行运行多个子 agent几种常见模式fan-out 与合并大任务拆成多份并行处理再汇总结果。分类并执行先判断任务属于哪一类再分派对应处理逻辑。对抗式验证一部分子 agent 专门挑另一部分产出的毛病而不是自我审查。生成并过滤 · 锦标赛式选优产出多个候选逐层淘汰选出最优解。这里最值得注意的仍是对抗式验证——它是生成者与评估者分离这个原则从单个 loop 内部扩展到了多 agent 协作的架构层面。据公开报道Stripe 内部用类似编排方式每周合并超过 1300 个机器编写的 PR03、底层机制Loop 到底怎么跑MECHANISM · Agent SDK 运行时要真正理解、乃至自己动手搭建 loop得理解 Claude Agent SDK 的运行时机制——这些机制是所有 loop 的执行基础。消息类型循环的心跳循环运行时会不断产生一串消息每种类型代表循环所处的阶段类型含义SystemMessage会话生命周期事件init / 压缩边界AssistantMessage每次响应后产生含文本和工具调用UserMessage工具执行完毕后产生携带返回结果StreamEvent流式模式下的实时增量ResultMessage循环结束标志含最终结果与 subtype判断一个 loop 该不该继续、该往哪调整靠的正是解析这些消息而不是靠猜。上下文窗口与自动压缩Loop 跑得越久上下文积累越多且不会在轮次之间重置。接近上限时 SDK 会自动压缩compaction把较早历史总结成摘要保留最近对话和关键决策。踩坑提示 压缩会用摘要替换早期指令长期有效的规则要写进 CLAUDE.md每次请求都会重新注入不要只写在最初 prompt 里。控制循环的三个旋钮参数作用max_turns限制工具调用最大轮次防无限循环max_budget_usd限制花费上限超过就停止effort控制推理深度平衡成本与质量没设这些限制的循环遇到开放式任务可能无限跑下去持续消耗 token 和费用。工具执行与权限控制只读工具Read、Glob、Grep可并发执行会修改状态的工具Edit、Write、Bash按顺序执行避免冲突。权限模式上acceptEditsbypassPermissionsHooks插入你自己的检查点Hooks 是在循环特定节点触发的回调跑在你自己的进程里不占用 agent 上下文。StopPreToolUse04、实现动手搭一个 LoopIMPLEMENTATION · 从命令到代码STEP 01命令行组合/loop /goal不写一行代码直接组合命令就能跑起基础 loopclaude code/goal all tests pass, lint is clean, and PR has no unresolved comments /loop 10m check the PR, address new review comments, fix failing CI第一条设定什么算完成第二条让 Claude 每 10 分钟检查一次 PR 状态。/goal 判定条件达成时循环会给出总结并停止没达成就继续跑下一轮。STEP 02用 Agent SDK 写自定义循环需要更细粒度控制时直接用 Agent SDK 写代码。下面是修复失败测试的核心实现TypeScripttypescriptfor await (const msg of query({ prompt: 修复 auth 模块测试失败, options: { allowedTools: [Read,Edit,Bash], maxTurns: 30, effort: high } })) { if (msg.type result) { console.log(msg.subtype, msg.result); } }这段代码已经具备轮次上限、推理强度、工具自动批准等基础设施是一个完整的turn-based loop实现。STEP 03加上生成者/评估者分离要升级成真正的 loop engineering 实践需要在外面再包一层判定逻辑生成 → 独立评估 → 未通过则带着反馈重跑。typescriptwhile (attempt MAX_ATTEMPTS) { const result await runGenerator(task); const done await isDone(result); if (done) break; task withFeedback(task, result); } async function isDone(state) { const test await sh(npm test --json); return test.allPassed; }关键原则isDone 永远不能是同一个正在写代码的 agent 自我报告我觉得可以了它应该是独立的、可核验的逻辑跑测试的脚本、专门挑刺的另一个 agent或调用外部服务做检查。判定越客观量化loop 就越可靠。STEP 04用 CLAUDE.md 沉淀记忆长时间运行的 loop 最容易踩的坑是每一轮都从零开始。把稳定规则写进项目的 CLAUDE.md它会在每次请求中被重新注入不会被压缩掉markdown# 总结时请保留 - 当前任务目标和验收标准 - 已读过 / 改过的文件路径 - 测试结果和报错信息STEP 05引入对抗式验证复杂任务里单个 agent 既生成又不自我评审还不够可靠可以引入专门的审查 agent一个负责修复代码只读权限的另一个专门带着怀疑态度找问题——生成和评审彻底分离谁也不给自己打分。这正是 Dynamic Workflows对抗式验证模式的简化版。05、代价与风险RISK · Loop 不是免费午餐任何把人从每一步都要看位置上挪开的技术都会带来新的隐性成本。业内已经总结出几类常见风险验证债务loop 跑得越快、产出越多实际审查产出的精力就越跟不上欠下的审查债会越积越多。理解力衰退代码大量由 agent 生成、人只负责设计 loop 时对代码库细节的掌握会逐渐变浅。认知交出把判断什么算做完的权力完全交给自动化标准后人容易停止主动思考。Token 爆炸没设好轮次和预算上限的 loop可能在没注意时持续消耗 token产生意料之外的费用。这几类风险恰恰对应前面讲的每个设计原则确定性停止条件对应token 爆炸独立评估者对应认知交出CLAUDE.md 记忆机制部分缓解验证债务。生成本身正在变得几乎免费稀缺的是判断力写在最后SUMMARY · 从盯梢到系统从手动一句一句 prompt到自动重复执行的 /loop再到有明确终止条件的 /goal再到能跑在云端的 routine最后到多 agent 互相审查的 Dynamic Workflows——这条演进路径的本质是把持续性和判断力这两件事从依赖人工盯梢一步步变成了系统里可配置、可复用的原语。决定 loop 好不好用的不是 prompt 写得多精妙而是你能不能设计出一个足够客观的完成标准今天任何一个开发者不需要从头搭建调度器和评估框架就能直接用 /loop、/goal、/schedule 组合出一个属于自己的自动化工作流——从盯 PR、修 CI到批量处理 bug 报告、跑定时的代码迁移任务。
