今天任何一个开发者，不需要从头搭建调度器和评估框架，就能直接用 /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、/schedule（routines），以及更进一步的 Dynamic Workflows。这篇文章从"loop 到底是什么"讲起，一路讲到底层运行机制，再到你今天就能上手的具体代码。

01、什么是 Loop？

FOUNDATION · 先回到最基础的循环

智能体循环的五个步骤

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 解决"怎么让任务反复自己跑起来，不用每次手动重发"。它按固定时间间隔重新执行同一个 prompt：

CMD/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 个机器编写的 PR

03、底层机制：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 上下文。StopPreToolUse

04、实现：动手搭一个 Loop

IMPLEMENTATION · 从命令到代码

STEP 01命令行组合：/loop + /goal

不写一行代码，直接组合命令就能跑起基础 loop：

claude 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 写代码。下面是"修复失败测试"的核心实现（TypeScript）：

typescript

for 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 实践，需要在外面再包一层判定逻辑：生成 → 独立评估 → 未通过则带着反馈重跑。

typescript

while (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 报告、跑定时的代码迁移任务。