Loop 循环工程和实践

资料来源https://www.runoob.com/ai-agent/loop-engineering.html

那些奇怪的工程概念和区别

工程阶段	核心思想	关注点	输入内容	AI 能力	人的角色	典型场景
Prompt Engineering（提示词工程）	通过设计提示词获得更好的输出	怎么问问题	Prompt / 指令	单轮生成	提问者	聊天、写作、代码生成
Context Engineering（上下文工程）	组织并提供完整背景信息	给 AI 什么信息	知识库、历史记录、约束条件、上下文	上下文理解	信息组织者	RAG、AI 搜索、代码助手
Harness Engineering（编排工程）	连接模型、工具、数据形成工作流	如何调用能力	上下文 + API + 工具链	执行任务	系统设计者	Agent、自动化流程、多工具协同
Loop Engineering（循环工程）	构建目标驱动的自主闭环系统	如何持续完成目标	目标、状态、记忆、验证机制	规划 → 执行 → 验证 → 修复 → 持续运行	规则制定者	Claude Code、AI 编程、自动运营、AI 员工

什么是循环工程

Loop Engineering 是设计、运营和持续改进反馈循环的工程实践，这些循环使 AI 编程 Agent 能够自主完成规划、执行代码修改、观察结果并在多轮迭代中完成任务。

用一句话概括：

Loop Engineering 是把你从"提示 Agent 的人"变成"设计提示 Agent 的系统"的工程师。

我的理解：设定目标和你想要的结果，通过不断编写->review->编写……（Agent）

直到达到你设定的目标

需要注意的是这和在Claude code中的/loop指令并不相同

/loop是执行重复操作的指令

/goal才是常见的循环工程执行

一个 Loop 是一个递归目标系统：你定义一个目的，Agent 不断迭代，直到工作真正完成。

每个 Agent 在执行任务时已经内置了一个"内循环"：感知（Perceive）→ 推理（Reason）→ 行动（Act）→ 观察（Observe），然后再次循环。

Loop Engineering 工作在这个内循环的上一层：

层级	谁在驱动	做什么
内循环（Agent 内置）	Agent 自身	读文件 → 修改代码 → 运行测试 → 读错误 → 再修改
外循环（你来设计）	你设计的系统	按计划发现任务 → 分派 Agent → 验证结果 → 记录状态 → 开启下一轮

构建你的Loop

简单实践

任务越窄，Agent 越清楚哪些文件重要、哪些验证信号相关。

不好的任务定义	好的任务定义
"优化仪表盘性能"	"将仪表盘首次加载时间减少 30%，方法是推迟非关键图表加载，同时保持现有过滤器正常工作"
"修复 checkout 问题"	"修复 test/checkout/tax.spec.ts 中失败的税额计算测试"
"改进设置页面"	"修复账户删除按钮在移动端（375px 宽度）被截断的布局问题"

明确的结束条件

就像写循环一样，要有条件的结束，不然就会不断的执行下去，依赖你手动结束

# 差：没有验证条件，Agent 不知道何时停止
/goal "Fix the auth bug"

# 好：有具体的验证命令和成功标准
/goal "Fix the session leak causing flaky tests in test/auth/login.spec.ts.
       Success condition: run 'pnpm test test/auth/login.spec.ts' 5 times
       consecutively with zero failures. Do not touch other test files."

保险机制

在 Loop 能够自动开 PR 之前，先让它只写文件、不做任何外部操作，你来审查 diff 再决定是否提交。

# 这是推荐的第一个 Loop：
# - 只读操作（读 CI 日志、读 Issues）
# - 只写 TODO.md（不触碰其他文件）
# - 不开 PR、不合并代码
# - 你每天早上看一眼 TODO.md，手动决定下一步

/loop "Read yesterday's CI failure logs and GitHub Issues labeled 'bug'.
       Categorize findings by likely cause.
       Write a summary with prioritized action items to TODO.md.
       Do NOT edit any source files. Do NOT open any PRs." \
       --schedule "0 8 * * 1-5"

自主性的提升

阶段	Loop 能做的事	人类做的事
阶段 1（只读）	发现问题、分类任务、写状态文件	审查 TODO.md，手动决定处理顺序
阶段 2（草稿）	起草修复方案、运行测试、写入分支	审查 diff，手动执行 git push
阶段 3（半自动）	开 Draft PR，运行 CI，通知 Slack	审查 PR，手动点击 Merge
阶段 4（全自动）	制作者 + 检查者双 Agent，CI 通过后自动合并	异常时人工介入，定期审计合并历史

Loop的风险

• 人工的代码审查是必不可少的
• Loop产出的代码速度极快，可以无时不刻的生成代码。生成的代码越多，项目中你实际理解的部分就越低，这是整个vibe coding面临的共性问题。唯一的办法就是永远不要去放弃理解代码，理解生成的代码。这对我们代码的review，和保持技术是必不可少的
• 当Loop自动运行的时候，接受返回的任何结果都是容易的。也就是我们常说的Yes工程师，但这也是最危险的

常见的问题和应对

故障模式	表现	根本原因	解决方法
空转（Thrashing）	Agent 反复修改代码，但没有收敛	目标不清晰，或验证信号有噪声，或每次修改范围太大	缩小目标范围，减少每次 diff 的大小，使用更可靠的验证命令
过拟合测试	所有测试通过，但功能实际上是错的	测试覆盖太窄，没有验证真实用户场景	结合自动测试和人工验收检查，增加端到端测试
上下文漂移	Agent 基于过期的假设持续工作，忽略新出现的变化	没有在关键观察后刷新上下文	在重要观察后重新收集上下文，不把初始计划视为神圣
不安全的自主	Agent 在没有授权的情况下执行破坏性操作	权限范围过宽，没有明确的停止条件	最小权限原则，高风险操作必须人工审批，设置明确的停止规则

最佳实践

以下是构建可靠 Loop 的核心原则，每条都对应一类常见的失败。

原则	具体做法
从窄任务开始	每次只定义一个有明确边界的目标，宽泛的目标让 Agent 无法判断哪些文件、哪些验证信号是相关的
告诉 Agent 如何验证	在指令中直接写明验证命令（<font style="color:rgb(51, 51, 51);">pnpm test test/auth</font> ）、验收场景或 API 端点，让"完成"可测量
偏好小的可逆变更	要求 Agent 做最小的连贯修改，运行验证后再扩展；大范围推测性重写难以判断是哪个假设出了问题
尊重现有代码模式	让 Agent 先检查相邻的实现，复用现有组件，遵循现有命名，避免引入不必要的新抽象
人类保持判断席位	Agent 处理证据收集和机械性修复；产品判断、架构决策、最终 Review 保留给人类
沉淀可复用 Loop	当某个 Loop 跑得好的时候，把它固化为 Skill 文件或标准化的触发器，降低未来的重复成本