上一篇我们聊了什么是 Loop Engineering这篇讲更硬的事怎么真正把一个 Agentic Loop 跑起来以及更重要的——怎么让它在该停下来的时候停下来。先说一个真实的事故现场有人用 Claude Code 跑了一个自动修复所有 failing test的循环睡前启动早上起来看账单——$400。循环一直在跑测试一直没全过模型一直在重试。这不是极端案例是一个已知的失败模式。Agentic Loop 和普通的 AI 对话有本质区别你发一条消息AI 回一条消息完事了。但 Agentic Loop 里模型执行一个动作观察结果决定下一步然后继续跑。一个循环可以跑几十轮、几百轮。没有提前设计好验证机制、花费上限和停止条件你就距离一个失控进程只差一个边缘情况。先搞明白循环到底是怎么工作的Claude Code 是 Anthropic 出的命令行 AI 编程工具能读文件、写代码、执行 shell 命令、跑测试在任务结束前自主迭代。这让它在真正的自主任务上非常有用——但也意味着模型手上有真实的工具、能造成真实的后果。一个 Agentic Loop 本质上是三个阶段的循环计划Plan→ 行动Act→ 观察Observe→ 再计划 → ...模型评估任务、决定下一步做什么执行一个动作写代码、跑命令、读文件读取这个动作的结果并更新计划——直到任务完成或者某个东西把循环停下来。关键在后半句某个东西把循环停下来——这件事很少自动发生。没有明确的停止条件只要任务感觉还没完成Claude Code 就会继续计划和行动直到撞上 API 的硬限制。循环为什么会跑飞几个最常见的原因每一个都有对应的设计缺陷成功条件模糊模型不知道做完了是什么样子就会一直试新方法级联失败一个测试失败触发代码修改修改导致另一个测试挂再触发另一次修改……像多米诺骨牌任务范围太广重构整个代码库没有自然的终点缺少错误预算模型不知道什么时候应该停下来求助而不是继续重试这些问题全都可以通过在启动循环之前做出正确的设计决定来解决。第一步在开跑之前把任务范围定清楚所有 Agentic Loop 的成本控制里最有效的一招是把任务定义好。这听起来很废话但绝大多数 loop 跑飞的问题都能追溯到模糊或开放式的指令。写出一个具体的成功条件在启动 Claude Code 之前先把完成了是什么样子写下来。不是修复 bug而是所有 /tests/unit/ 下的测试用 exit code 0 通过且没有在 /src/ 目录外创建新文件。一个合格的成功条件有三个属性可观察Observable可以用程序检查不需要主观判断二元的Binary通过或失败不是大部分完成了有边界的Bounded描述一个有限的结果而不是一个持续的过程如果你没办法这样定义成功条件说明这个任务还没定义到足以自主执行的程度。把大任务拆成子任务长循环比短循环难控制得多。与其一次性把多步骤任务扔给 Claude Code不如拆成独立的子任务每个子任务单独跑一个循环验证通过了才继续下一个。这种检查点继续模式意味着步骤 3 失败了不会白白消耗步骤 4 到 10 的所有 token。第二步把验证机制嵌入每一轮迭代验证是区分受控 Agentic Loop和黑盒的关键。你需要在每一轮迭代中知道进展是否在发生Agent 是否在走正确的方向三个层级的验证动作级验证Action verification每次单个动作写文件、执行命令之后检查这个动作是否成功。Claude Code 通常会自动观察 stdout/stderr 的输出但你可以加显式检查——比如断言文件在 Agent 声称写完之后确实存在或者命令确实返回了 exit code 0。迭代级验证Iteration verification每轮循环结束时跑一个轻量级检查看整体任务是不是在逼近完成。对代码任务来说可以是跑一个特定的测试文件对数据任务来说可以是检查行数或 schema 的有效性。终止验证Terminal verification在接受循环完成之前跑你事先定义的完整成功条件。这是你的最后一道门。用外部脚本验证不要只靠模型自己判断一个常见错误让 Agent 用自己的判断来验证自己的工作。模型可能会说我认为任务已完成但其实没完成——不是它在撒谎而是它真的看不出问题所在。在可能的情况下用一个 Agent 可以调用的外部脚本或测试套件。Agent 报告脚本说了什么而不是它觉得怎么样。这让验证锚定在客观输出上。一个具体示例如果 Claude Code 在写 Python 函数在 system prompt 里加这句话After every code change, run python -m pytest tests/test_function.py -vand report the exact output. Do not proceed to the next step until all tests pass.这样模型被要求用测试输出来支撑它的判断而不是自我评估。限制重试深度一个动作失败了Agent 应该重试——但不能无限重试。给每个动作设一个最大重试次数通常 2~3 次。如果 Agent 3 次都没成功它应该停下来、把失败暴露出来而不是继续迭代。这对 shell 命令和 API 调用尤其重要——反复失败往往说明是系统性问题环境错误、凭证不对、逻辑有缺陷更多的重试解决不了根本问题。第三步设置花费上限和 Token 预算Token 成本是 Agentic Loop 里最可量化的风险好消息是它也是最可控的。跑之前先估算成本Claude 的 API 定价是公开且可预测的。跑循环之前先估算一下预期的成本区间估计这个任务应该需要多少轮迭代乘以每轮的预期 token 数量输入 输出应用你选择的模型的当前费率这个计算做完之后就有了一条基准线。如果实际成本远超预期说明循环设计哪里出了问题。在 Prompt 里设置硬性 Token 限制Claude Code 支持 --max-turns 参数限制一个 session 跑的最大 agentic turn 数。一定要用。这是最简单的硬性终止机制claude --max-turns 25 Fix all failing tests in /tests/unit/把这个数字设得比预期的 turn 数稍微高一点给 Agent 留出工作空间同时防止失控执行。分层使用不同规格的模型不是每一步都需要用最贵的模型。Claude Haiku 比 Claude Sonnet 便宜得多对于读文件、检查 diff、跑一个已知命令这类常规动作较小的模型通常完全够用。考虑这样的分层策略计划和观察步骤用更轻量的模型核心生成或推理步骤才用更强的模型这可以在不明显影响输出质量的情况下把每轮成本降低 60~80%。基于成本实时停止对于在生产环境或自动化管道里运行的循环把成本追踪接入你的循环控制器。常见做法是通过 API 响应元数据统计 token累积一个实时的总计如果总花费超过阈值就停止循环这和 --max-turns 是不同的维度——基于成本的停止处理的是每轮超出预期的贵而不只是轮数太多。第四步把停止条件写清楚停止条件是你的循环在每轮迭代结束时检查的退出条件。它们应该在循环开始之前就定好而不是运行到一半才临时加。停止条件的三个类别成功停止任务完成了终止验证通过Agent 返回成功信号循环干净地退出。失败停止任务无法以当前形式完成。触发条件某个特定动作的重试次数超过限制遇到不可恢复的错误文件找不到、环境损坏Agent 明确表示它卡住了预算停止资源耗尽。触发条件Turn 数超过 --max-turnsToken 花费超过成本阈值运行时间超过时间限制每个循环都应该有三类中各至少一个条件。缺了失败停止循环可能在一个损坏的状态里持续挣扎缺了预算停止缓慢的失败会变成一个昂贵的失败。把停止条件写进 System Prompt不要只靠代码层面的控制。把停止条件显式地写进给 Claude Code 的指令里你最多有 20 次机会来完成这个任务。 如果所有测试通过返回 TASK_COMPLETE 并停止。 如果你遇到了一个在 3 次重试后无法解决的错误返回 TASK_FAILED: [原因] 并停止。 不要在 /src/ 或 /tests/ 目录外创建新文件。显式的指令给了模型判断什么时候该停止继续尝试、什么时候该升级所需要的上下文。处理部分完成的情况有些任务在循环触达停止条件时可能已经完成了 80%。提前决定怎么处理这种情况Agent 应该提交部分工作吗应该回滚吗应该留下一份详细的已完成什么、什么被阻塞的摘要吗最坏的结果是一个循环停在中途留下一个前后不一致的代码库而且没有任何记录说明发生了什么。无论循环是通过成功还是失败退出都应该内置一个清理和总结步骤确保它一定会跑。三种效果最好的 Loop 模式理解了核心组件之后有几种在 Claude Code 里普遍适用的 loop 模式值得记下来。测试驱动循环Test-Driven Loop编程任务最干净的模式在启动 Agent 之前写好测试或提供已有的测试Agent 写代码或修改代码Agent 在每次修改后跑测试测试通过或重试上限触发时循环退出测试套件同时充当验证机制和成功条件。Agent 永远不需要判断自己的输出——测试替它判断。Diff 评审循环Diff-Review Loop对于风险更高的变更在循环里加一个人工审核检查点Agent 提出一个变更生成一个 diff人类评审并批准或拒绝批准后Agent 应用变更并验证循环继续推进到下一个任务这会让速度变慢但在关键决策路径上保留了人类。适合生产代码、数据库迁移、或者任何一个错误代价很高的任务。检查点摘要循环Checkpoint-and-Summarize Loop对于更长的任务定期生成检查点Agent 完成一个子任务Agent 写一份结构化的摘要说明做了什么、接下来是什么控制器把这份摘要保存到文件如果循环被中断可以从最后一个检查点恢复这让长循环变得可恢复并且给你留下一份 Agent 做了什么、为什么这么做的审计轨迹。常见错误和对应的修法把最容易踩的坑列出来逐条对应修法比较容易记错误一启动时没有成功条件修法在写 prompt 之前先写成功条件。如果你没法用一句话定义它就把任务范围缩小。错误二没有硬性的 turn 上限修法在自主任务上运行 Claude Code 时始终传 --max-turns。从保守的值开始15~20 轮只有当数据表明任务确实需要更多时才增加。错误三信任模型的自我评估修法用外部测试、脚本或验证器来确认任务完成。模型说的我认为做完了是一个信号不是验证。错误四每一步都用最贵的模型修法审计你的循环识别出那些不需要强推理的步骤把它们切到 Claude Haiku 或类似的轻量模型。错误五没有失败处理修法把显式的失败状态写进你的指令里。告诉 Agent 卡住了是什么样子以及遇到这种情况该做什么。错误六让 Agent 在循环运行中修改自己的停止条件修法把停止逻辑放在你的控制器代码或 system prompt 里不要放在 Agent 在循环中可以编辑的地方。从 Loop 到 PIV一个值得记住的执行框架在实战中有一个具体的循环结构被越来越多的团队采用——PIV 循环Plan-Implement-Verify它是上面讲的计划—执行—验证模式在工程实践中的具体化PlanAgent 读取任务比如一张 Jira ticket审查代码库里的相关部分在动文件之前先写出一份书面计划ImplementAgent 按照计划做出变更VerifyAgent 跑测试、检查验收标准、报告结果这三步对应三个关键保障Plan 阶段的人工审批门防止 Agent 实现了错的东西、Implement 阶段的范围限制只动该动的文件、Verify 阶段的外部验证测试说了算不是 Agent 自己说了算。更快的循环并不总是更好的循环。带人工审查的慢循环远好过快速跑完然后需要大规模回滚的循环。一个更大的视角Loop Engineering 的成熟度阶梯从单次 prompt 到真正生产级的自主 loop有一条路要走第一阶段交互式对话你一句它一句 ↓第二阶段有限自主用 --max-turns 跑一个受控任务 ↓第三阶段验证驱动每轮迭代有外部测试确认进度 ↓第四阶段自动化调度配合 cron 或 webhook循环定期自动触发 ↓第五阶段多 Agent 协作一个 Orchestrator 拆任务、多个 Executor 并行跑、一个 Reviewer 检查输出大多数人现在在第二阶段的入口。第三阶段是真正实用的起点——有了验证机制你才有信心让循环在无监督的情况下运行更长时间。之后的阶段需要更多基础设施投入但回报是让 AI 在你睡觉的时候替你干活这件事真正成为现实。最后这件事的真正难点不是技术搭一个能跑的 Agentic Loop 并不难真正难的是让它在该停的时候停、在失败的时候不悄悄留下一堆烂摊子。这需要你在启动循环之前就想清楚几件事我怎么知道它做完了我怎么知道它卡住了如果它跑得太久或太贵谁来喊停如果它只做完了一半我的系统处于什么状态这四个问题的答案就是你循环设计的基础。把它们写进 system prompt、写进控制脚本、写进 --max-turns 参数——然后你才有资格去睡觉不用担心早上醒来看到那张账单。更多transformerVITswin tranformer 参考头条号人工智能研究所 v号人工智能研究Suo, 启示AI科技动画详解transformer 在线视频教程