AI Loop在Calude code中的实现本文可作为第十四章 14.15 节的扩展内容为什么 Agent 总在关键时刻停下来等你你让 Claude Code 修一批测试它把第一个测试文件改好了然后停下来问“要继续修下一个吗”你说继续它改了第二个又停下来。这不是 Bug是设计——传统的 AI 编码助手默认每完成一步就等待确认。这个设计很安全但把自主 Agent的承诺砍掉了一大半。你变成了一个人肉进度条每隔几分钟点一次继续。更麻烦的是每次重启对话Agent 都忘了上一轮做了什么又得从零开始解释现状。一个本来应该自动完成的 20 个文件的迁移任务你可能花了两小时在键盘前守着。这是 2024 年前大多数 AI Agent 工具的通病任务粒度和人工干预频率不匹配。Claude Code 在 2025 年推出的/loop和/goal命令直接在工具层面解决了这个问题。Agent Loop六步闭环模型在介绍具体命令之前先理解 Agent Loop 的理论模型。它是所有自主 Agent 的执行骨架┌─────────────────────────────────────────────────────────┐ │ Agent Loop │ │ │ │ ┌────────┐ ┌─────────┐ ┌────────┐ │ │ │ Goal │───▶│ Context │───▶│ Plan │ │ │ └────────┘ └─────────┘ └────────┘ │ │ ▲ │ │ │ │ ▼ │ │ ┌────────┐ ┌─────────┐ ┌────────┐ │ │ │ Loop? │◀───│Evaluate │◀───│ Action │ │ │ └────────┘ └─────────┘ └────────┘ │ │ │ │ │ │ │ └─── 目标已达成 → 退出 │ │ └──────── 未达成 → 下一轮 │ └─────────────────────────────────────────────────────────┘六个步骤的含义步骤内容关键问题Goal定义终态不是步骤完成长什么样Context收集当前状态现在离目标有多远Plan决定下一步操作这一轮做什么Action执行操作写文件、运行命令、调 APIEvaluate检查是否达成目标Goal 满足了吗Loop决定继续还是退出未达成则回到 Context这个模型的关键在于Goal 是整个闭环的锚点。传统 AI 助手没有持久的 Goal每一步都是独立的所以需要人来充当记忆和导航。Loop 模式把 Goal 保留在 Agent 的运行上下文中让它自己知道什么时候该停。/goal定义可验证的终态/goal命令告诉 Claude Code 你最终要达到的状态不是要做的事情。错误写法描述过程/goal 重构用户服务模块这个目标Claude 无法验证——重构到什么程度算完成什么叫做好的重构Agent 无从判断要么提前宣告完成要么永远跑下去。正确写法描述可检验的终态/goal src/services/user/ 目录下所有 TypeScript 文件通过 ESLint 检查 且单元测试覆盖率不低于 80%所有测试绿灯这个目标有三个清晰的检验点ESLint 通过、覆盖率 ≥ 80%、测试全绿。Claude Code 在每轮结束后可以用命令直接验证知道自己是否做完。好目标的三个标准可执行验证有命令可以跑跑出来有明确的 pass/fail有边界明确哪些文件、哪些范围不是整个项目原子化一个目标只描述一件事别把修 bug 写文档 更新测试塞进一个 goal# 好的 goal具体、可验证/goal /src/api/ 下所有端点的响应结构与 openapi.yaml 中的定义完全一致 使用 openapi-validator--strict验证零错误# 不好的 goal抽象、模糊/goal 代码质量提升做好文档/loop让 Agent 持续迭代/loop命令改变 Claude Code 的默认行为完成一轮后自动开始下一轮而不是停下来等待。基本语法# 按时间间隔循环/loop every 5m# 按条件退出/loop until: all tests pass# 两者结合推荐/loop every 5m until: all tests pass# 限制最大轮次防止失控消耗/loop max:10until: migration completeLoop 和反复手动运行的区别这不只是省了几次敲回车。手动重启 Claude Code 时上下文断裂了。新对话里 Agent 不知道上一轮尝试了什么、为什么失败、哪些方向已经走不通。它会重新推理很可能踩同一个坑。Loop 模式下整个执行历史保留在对话上下文中。如果上一轮某个测试因为缺少 mock 数据而失败这一轮 Agent 知道要先补 mock不会重复尝试同一个没用的修法。这个区别在长任务上体现得非常明显。一个有 50 个测试要修的任务手动重启方式可能每次修2-3个就忘了前面发生了什么而 Loop 方式通常能连续推进直到碰到真正需要人介入的问题。完整案例自动修复 CI 失败这是一个在实际工程中高频出现的场景你推了一批代码CI 跑红了但你有其他事情要处理想让 Agent 后台帮你修。场景设定项目有一个 GitHub Actions 流水线包含三个 joblintESLint 检查testJest 单元测试43 个用例type-checkTypeScript 类型检查当前状态lint过了test有 7 个失败type-check有 3 个错误。第一步设置 Goal/goal GitHub Actions 上 main 分支最新 commit 的三个 joblint、test、type-check 全部通过本地运行npmrun ci 也全绿注意这个 goal 同时包含远端 CI和本地命令的验证避免 Agent 修了本地但忘了推送或推送后又引入新问题。第二步给 Agent 必要的上下文在启动 loop 前先把关键信息告诉 Agent省得它第一轮浪费时间探索目前 CI 状态 - lint: pass - test: 7 failures失败详情在 CI log 里链接[你的 CI URL] - type-check: 3 errors 本地运行命令 - npm run test → 跑测试 - npm run type-check → 跑类型检查 - npm run ci → 跑全套 git push 到 main 会触发 CI。第三步启动 Loop/loop every 3m until:npmrun ci exits with code03 分钟间隔是这样算的一轮 Agent 操作读 log → 修代码 → 跑本地测试大约需要 1-2 分钟加上 CI 触发到出结果的时间约 2 分钟间隔定 3 分钟刚好留一点余量不会让两轮重叠。Loop 执行过程典型流程第 1 轮第 0-3 分钟Agent 读取失败的测试 log → 发现 7 个测试失败分为两类 - 3 个mock 数据格式与新接口不匹配 - 4 个异步函数未正确 await → 修复 mock 数据格式 → 修复 4 个 await 问题 → 本地跑 npm run test全绿 → 本地跑 npm run ci全绿 → git push → 等待 CI第 2 轮第 3-6 分钟读取 CI 结果test passtype-check 仍有 2 个 error → 发现 type-check 的错误是第一轮改动引入的新类型问题 → 修复类型定义 → 本地 npm run ci全绿 → git push第 3 轮第 6-9 分钟读取 CI 结果三个 job 全绿 → 验证本地 npm run ci 退出码为 0 → Goal 满足Loop 自动退出 → 输出摘要修复了 7 个测试失败 2 个类型错误共 3 轮迭代整个过程你不需要守在键盘旁9 分钟后回来看结果就好。关键Goal 的保护机制注意 goal 里写的是三个 job全部通过。如果只写测试通过Agent 可能修了测试但忽略了 type-check 的新错误错误地认为 goal 已达成然后退出。Goal 越精确Loop 越可靠。三个高频工程场景场景一文档自动补全/goal src/ 目录下所有导出函数和类都有 JSDoc 注释 注释中的参数类型与实际函数签名一致 使用 typedoc--strict编译零错误 /loop until: typedoc--strictexits0Agent 会逐文件扫描补缺失的注释修错误的类型描述直到 typedoc 不报错为止。场景二依赖安全审计/goal package.json 中没有npmaudit 报告的 high 或 critical 级别漏洞 /loop every 30m这里没有until条件意味着循环不会自动退出——每 30 分钟检查一次发现新漏洞就修作为开发阶段的持续监控 Agent 使用。记得离开前手动停止。场景三大规模代码迁移从旧的设计系统迁移到新的 token/goal src/components/ 下所有组件不包含任何importfrom../design-system/legacy 改用importfrom../design-system/v2 且npmrun build 编译零错误 /loop max:20until: migration completemax: 20加了一个安全阀最多跑 20 轮防止 Agent 陷入死循环消耗大量 token。如果 20 轮内没完成会停下来报告当前进度让你判断是继续还是需要人工介入。工程陷阱三种最常见的失控情况陷阱一目标描述模糊导致提前退出症状Agent 声称完成了但你一看代码只改了一小部分。根因目标里有主观词Agent 的判断标准和你不一样。# 有问题Agent 可能认为基本完成就算满足/goal 代码看起来比较规范没有明显的 code smell# 正确所有检查点都是命令可以验证的/goal eslint src/ --max-warnings0命令零输出 jest--coverage报告 branches ≥85%陷阱二循环间隔太短耗尽 Rate Limit症状运行十几分钟后 API 开始返回 429 错误Loop 中断。根因每轮 Agent 消耗大量 token加上循环频率太高超出 API 速率限制。规避方法间隔设置为单轮实际耗时的 1.5 倍以上启动 loop 前用/compact压缩对话历史减少每轮的 context token 消耗用/cost命令监控实时消耗发现异常立即暂停# 先压缩历史再启动长时间 loop/compact /loop every 10m until: all migrationsdone陷阱三目标范围太宽让 Agent 越界症状Agent 在修 A 的时候顺手改了 B结果 B 原来能过的测试挂了。根因Goal 没有明确边界Agent 在推进过程中做了善意的额外工作。# 有问题没有限定范围/goal 所有测试通过代码质量好# 正确明确文件范围和禁止区域/goal src/services/payment/ 目录下的7个失败测试全部通过 且不修改 src/services/payment/ 以外的任何文件 其他测试的通过率不能下降在 Goal 里加上不修改 X 之外的文件是一个非常有效的约束可以把 Agent 的行动范围锁定在安全区域内。与 AgentLoop 内核的关系你可能记得第 14.3 节讲过 Claude Code 内部有一个AgentLoop——那是引擎层的单轮执行机制处理工具调用、流式输出、轮次限制。/loop命令是在这个引擎之上工作的调度层它以固定间隔或条件触发新一轮的AgentLoop执行在轮次之间维护 Goal 状态和历史上下文。┌─────────────────────────────────────────┐ │ /loop 调度层你配置的 Goal 间隔 │ │ │ │ ┌─────────────────────────────────┐ │ │ │ AgentLoop 内核单轮执行 │ │ │ │ 工具调用 → 流式输出 → 轮次控制 │ │ │ └─────────────────────────────────┘ │ │ ↕ 轮次间传递上下文 │ │ ┌─────────────────────────────────┐ │ │ │ AgentLoop 内核下一轮执行 │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘所以/loop并不改变 AgentLoop 的内部逻辑而是给它套了一个自动重启 目标检验的外壳。工程小结/goal的核心价值把完成的定义从你的脑子里搬到 Agent 的运行上下文里让 Agent 自己知道什么时候该停。目标必须可以被命令验证不能有主观词。/loop的核心价值保留跨轮上下文避免手动重启导致的信息断裂。Agent 记得上轮失败的原因不会重复踩坑。两者结合的最佳实践# 标准姿势压缩历史 → 提供上下文 → 设定目标 → 启动循环/compact# [粘贴关键上下文文件结构、CI 日志、已知约束]/goal[可验证的终态描述包含检验命令]/loop every[单轮耗时的1.5倍]max:20until:[验证命令]exits0什么任务适合 Loop迭代型需要多次尝试、可验证型有命令可检查、有明确边界型影响范围可控。什么任务不适合 Loop需要人来判断质量的设计类任务、涉及外部系统权限的操作、会影响生产环境的变更。