Loop Engineering 实战从 Prompt 技巧到可验证的 AI Agent 工作闭环文章目录Loop Engineering 实战从 Prompt 技巧到可验证的 AI Agent 工作闭环一、问题背景为什么只会写 Prompt 已经不够了二、分析什么是 Loop Engineering三、一个合格 Loop 的五个组成部分1. Trigger什么时候启动2. Context每一轮读什么3. Action这一轮允许做什么4. Verification如何判断做得对5. Stop Rule什么时候停止四、可复现最小实验自动修复一个测试失败1. 项目结构2. Loop 控制器代码3. 本地验证结果五、把最小实验扩展到真实 Coding Agent六、Loop Engineering 和 Agent Harness 的关系七、生产环境必须补上的安全边界1. 文件边界2. Diff 边界3. 成本边界4. 人工升级边界八、如何判断一个 Loop 是否合格九、常见误区误区 1Loop Engineering 等于让 AI 自动改代码误区 2多跑几轮就是 Loop误区 3测试通过就一定可以合并误区 4上下文越多越好十、结论参考资料一、问题背景为什么只会写 Prompt 已经不够了过去两年很多 AI 编程实践都围绕 Prompt 展开怎么把需求写清楚怎么补充上下文怎么让模型先分析再写代码怎么约束输出格式怎么让模型少犯明显错误。这些能力仍然重要但它们默认了一个前提人始终站在循环中心。例如让 AI 修复一个测试失败的问题时传统流程通常是人复制失败日志给 AIAI 给出修改建议人判断是否合理人应用修改人重新跑测试失败后再把新日志发给 AI人决定继续、回滚或停止。当任务很小这种方式可以接受。但当任务变成“持续扫描 PR”“每天修复文档失效链接”“自动补测试”“根据 CI 失败生成修复建议”时瓶颈不再是某一轮 Prompt 写得好不好而是谁来触发下一轮每一轮读取哪些上下文允许 Agent 做哪些动作如何判断动作是成功还是失败什么时候必须停止并交给人。这就是 Loop Engineering 要解决的问题。二、分析什么是 Loop EngineeringLoop Engineering 可以定义为为 AI Agent 设计一个可持续运行、可验证、可停止的工作闭环而不是依赖人一轮一轮手动提示。它关注的不是“让 AI 多跑几轮”而是把多轮工作背后的控制逻辑显式设计出来。一个最小 Loop 可以表示为Trigger 触发 ↓ Context 读取上下文 ↓ Action 执行动作 ↓ Verification 验证结果 ↓ Decision 判断继续、重试、升级或停止Prompt Engineering 关注单次交互质量Loop Engineering 关注系统闭环质量。前者决定“这一轮答得怎么样”后者决定“整个任务会不会失控、能不能复现、什么时候结束”。三、一个合格 Loop 的五个组成部分1. Trigger什么时候启动Loop 不能随便启动它必须有明确触发条件。常见触发方式包括触发方式示例风险定时触发每天 9 点检查项目状态可能处理过期上下文事件触发PR 创建后自动 Review可能在权限不足时误操作状态触发CI 失败后进入修复流程可能反复处理同一个失败人工触发开发者输入目标后启动依赖人的目标描述质量一个没有 Trigger 的 Agent 只是聊天窗口有了 Trigger它才开始像一个工程系统。2. Context每一轮读什么Agent 每次行动前都需要知道当前状态但上下文不是越多越好。CI 修复类 Loop 通常需要读取失败日志相关测试文件相关源码最近一次改动项目运行命令上一次 Loop 的执行记录。不应该默认读取与当前失败无关的全仓库文件历史很久的旧日志包含密钥或账号的配置未经确认的大型二进制文件。上下文选择错误会带来两个问题一是模型被噪声干扰二是敏感信息被带入不该进入的执行链路。3. Action这一轮允许做什么Action 是 Agent 真正执行的部分但它不等于“自动改代码”。成熟的 Loop 应该把动作分级动作级别允许行为是否需要人工确认只读读取日志、总结问题、生成报告通常不需要低风险写入修改测试、文档、局部代码视项目规则决定中风险写入改业务逻辑、改依赖、改构建配置建议需要高风险操作删除文件、改权限、改数据库、发布上线必须需要如果一个 Loop 没有动作边界就很容易从“自动辅助”变成“自动破坏”。4. Verification如何判断做得对Verification 是 Loop Engineering 的质量上限。常见验证器包括单元测试是否通过类型检查是否通过Lint 是否通过构建是否成功Diff 是否超出范围是否修改了禁止目录是否引入敏感信息输出是否回答了原始目标。没有 Verification 的 Loop本质上只是“让 AI 自动跑”。它可能完成任务也可能把错误自动放大。5. Stop Rule什么时候停止Loop 最危险的地方不是做不了事而是停不下来。建议至少设计以下停止条件目标完成停止测试通过停止达到最大迭代次数停止连续失败 N 次停止修改范围超过阈值停止触及高风险文件停止成本超过预算停止验证结果无法解释停止并交给人。Stop Rule 不是附加功能而是安全边界。四、可复现最小实验自动修复一个测试失败下面用一个最小 Python 示例验证 Loop 控制器的核心逻辑。这个示例不模拟完整大模型能力只验证四件事能读取失败状态能执行一次最小修复能重新运行验证能在验证通过后停止。1. 项目结构loop_demo_project/ calculator.py test_calculator.py loop_demo.py初始代码故意写错# calculator.pydefadd(a,b):returna-b测试用例# test_calculator.pyfromcalculatorimportadddeftest_add():assertadd(2,3)52. Loop 控制器代码importpathlibimportsubprocessimportsys ROOTpathlib.Path(__file__).parent/loop_demo_projectSRCROOT/calculator.pyTESTROOT/test_calculator.pyMAX_ATTEMPTS3defprepare_project()-None:ROOT.mkdir(exist_okTrue)SRC.write_text(def add(a, b):\n return a - b\n,encodingutf-8,)TEST.write_text(from calculator import add\n\ndef test_add():\n assert add(2, 3) 5\n,encodingutf-8,)defrun_tests()-subprocess.CompletedProcess[str]:returnsubprocess.run([sys.executable,-m,pytest,-q],cwdROOT,textTrue,capture_outputTrue,)defapply_minimal_fix()-None:contentSRC.read_text(encodingutf-8)SRC.write_text(content.replace(return a - b,return a b),encodingutf-8)defmain()-int:prepare_project()forattemptinrange(1,MAX_ATTEMPTS1):resultrun_tests()print(f[attempt{attempt}] exit_code{result.returncode})print(result.stdout.strip())ifresult.returncode0:print(STOP: verification passed)return0ifattempt1:print(ACTION: apply minimal fix to calculator.add)apply_minimal_fix()else:print(STOP: failed after retry, escalate to human)return1print(STOP: max attempts reached)return1if__name____main__:raiseSystemExit(main())3. 本地验证结果执行命令python work/loop_demo.py实际输出[attempt 1] exit_code1 F [100%] FAILURES __________________________________ test_add ___________________________________ def test_add(): assert add(2, 3) 5 E assert -1 5 E where -1 add(2, 3) test_calculator.py:4: AssertionError short test summary info FAILED test_calculator.py::test_add - assert -1 5 1 failed in 0.12s ACTION: apply minimal fix to calculator.add [attempt 2] exit_code0 . [100%] 1 passed in 0.01s STOP: verification passed这个实验能说明三个关键点Loop 不是无限重试而是在MAX_ATTEMPTS内运行Action 不是随意改动而是一次可解释的最小修改Stop Rule 由测试结果触发而不是由模型自称“已经修好”触发。五、把最小实验扩展到真实 Coding Agent真实项目里apply_minimal_fix()不会是简单字符串替换而是调用 Coding Agent 生成补丁。但控制器的骨架不应该变读取失败日志 ↓ 定位相关文件 ↓ 生成候选修复 ↓ 应用最小补丁 ↓ 运行验证命令 ↓ 检查 Diff 范围 ↓ 通过则总结失败则重试或升级推荐把真实 Loop 拆成三层层级职责不应该做的事控制层决定触发、上下文、重试、停止直接相信模型结论Agent 层生成分析、补丁、说明绕过验证器直接提交验证层运行测试、检查 Diff、安全扫描用主观判断替代命令结果这样设计的好处是即使 Agent 生成了错误补丁验证层也能拦住即使验证失败控制层也能限制重试次数并升级给人。六、Loop Engineering 和 Agent Harness 的关系可以把 Agent Harness 理解为承载 Agent 的运行外壳把 Loop Engineering 理解为这个外壳里的控制策略。Agent Harness 常见能力包括工具调用文件读写Shell 执行浏览器操作权限控制日志记录人工确认。Loop Engineering 关注的是什么时候调用这些能力每次调用前后如何记录状态什么结果算成功什么风险必须中断哪些情况交给人。两者关系可以概括为Harness 提供能力Loop 决定能力如何被组织成可靠流程。七、生产环境必须补上的安全边界如果要把 Loop 放进真实研发流程至少要补上以下边界。1. 文件边界明确允许修改和禁止修改的路径。示例allow:-src/**-tests/**-docs/**deny:-.env-secrets/**-migrations/**-infra/**如果 Loop 触及deny路径应立即停止并请求人工确认。2. Diff 边界限制单轮改动范围。例如单轮修改不超过 5 个文件单轮新增代码不超过 300 行不允许删除测试不允许修改锁文件除非任务明确要求。Diff 边界可以避免 Agent 为了修一个小问题引入大面积不确定改动。3. 成本边界长期运行的 Loop 必须限制成本最大迭代次数最大运行时间最大 Token 消耗最大工具调用次数失败后冷却时间。没有成本边界的 Loop 很容易在同一个问题上反复消耗资源。4. 人工升级边界以下情况建议直接交给人测试失败原因不稳定修复需要改业务规则需要删除数据或迁移数据库需要改认证、支付、权限、加密逻辑Agent 给出的解释和测试结果不一致连续两轮修改没有缩小失败范围。人工升级不是 Loop 失败而是工程系统的一部分。八、如何判断一个 Loop 是否合格可以用下面这张表做评审检查项合格标准Trigger启动条件明确不会无意义反复触发Context只读取任务相关信息敏感信息有过滤Action动作有权限分级高风险操作需确认Verification有命令、测试、Diff 或规则验证Stop Rule有完成、失败、超时、成本和风险停止条件Record每轮有日志能复盘为什么继续或停止Escalation无法判断时能交给人而不是继续猜如果一个 Agent 流程只能回答“它做了什么”但回答不了“为什么继续、为什么停止、凭什么判断成功”它还不能算成熟的 Loop。九、常见误区误区 1Loop Engineering 等于让 AI 自动改代码不是。自动改代码只是 Action 的一种。很多高价值 Loop 只做只读分析例如每天总结失败 CI、给 PR 标注风险、扫描文档过期链接。误区 2多跑几轮就是 Loop不是。没有验证器和停止规则的多轮执行只是重复调用模型。误区 3测试通过就一定可以合并不是。测试通过只能证明已覆盖场景没有失败还需要检查 Diff、风险路径、需求一致性和人工审核规则。误区 4上下文越多越好不是。上下文越多噪声、过期信息和敏感信息进入决策链路的概率越高。十、结论Prompt Engineering 仍然重要但它解决的是单轮表达问题。Coding Agent 真正进入研发流程后更关键的是 Loop Engineering用 Trigger 管理启动用 Context 管理输入用 Action 管理能力用 Verification 管理正确性用 Stop Rule 管理风险用 Record 和 Escalation 管理复盘与人工接管。未来 AI 工程能力的分水岭不只是“谁更会写 Prompt”而是谁能把 AI 组织进一个可验证、可停止、可复盘的工程闭环。不要把 Loop 设计成失控的自动化。一个好的 Loop 应该像一个谨慎的初级工程师能做小步修改能跑验证知道何时停下也知道什么时候必须请人判断。参考资料Python 官方文档subprocess.run用于说明示例中如何调用外部测试命令并读取退出码。pytest 官方文档Get Started用于说明示例中pytest -q这类最小测试验证方式。感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
【Loop Engineering】当我们不再手写 Prompt，而是设计 AI 的工作闭环
Loop Engineering 实战从 Prompt 技巧到可验证的 AI Agent 工作闭环文章目录Loop Engineering 实战从 Prompt 技巧到可验证的 AI Agent 工作闭环一、问题背景为什么只会写 Prompt 已经不够了二、分析什么是 Loop Engineering三、一个合格 Loop 的五个组成部分1. Trigger什么时候启动2. Context每一轮读什么3. Action这一轮允许做什么4. Verification如何判断做得对5. Stop Rule什么时候停止四、可复现最小实验自动修复一个测试失败1. 项目结构2. Loop 控制器代码3. 本地验证结果五、把最小实验扩展到真实 Coding Agent六、Loop Engineering 和 Agent Harness 的关系七、生产环境必须补上的安全边界1. 文件边界2. Diff 边界3. 成本边界4. 人工升级边界八、如何判断一个 Loop 是否合格九、常见误区误区 1Loop Engineering 等于让 AI 自动改代码误区 2多跑几轮就是 Loop误区 3测试通过就一定可以合并误区 4上下文越多越好十、结论参考资料一、问题背景为什么只会写 Prompt 已经不够了过去两年很多 AI 编程实践都围绕 Prompt 展开怎么把需求写清楚怎么补充上下文怎么让模型先分析再写代码怎么约束输出格式怎么让模型少犯明显错误。这些能力仍然重要但它们默认了一个前提人始终站在循环中心。例如让 AI 修复一个测试失败的问题时传统流程通常是人复制失败日志给 AIAI 给出修改建议人判断是否合理人应用修改人重新跑测试失败后再把新日志发给 AI人决定继续、回滚或停止。当任务很小这种方式可以接受。但当任务变成“持续扫描 PR”“每天修复文档失效链接”“自动补测试”“根据 CI 失败生成修复建议”时瓶颈不再是某一轮 Prompt 写得好不好而是谁来触发下一轮每一轮读取哪些上下文允许 Agent 做哪些动作如何判断动作是成功还是失败什么时候必须停止并交给人。这就是 Loop Engineering 要解决的问题。二、分析什么是 Loop EngineeringLoop Engineering 可以定义为为 AI Agent 设计一个可持续运行、可验证、可停止的工作闭环而不是依赖人一轮一轮手动提示。它关注的不是“让 AI 多跑几轮”而是把多轮工作背后的控制逻辑显式设计出来。一个最小 Loop 可以表示为Trigger 触发 ↓ Context 读取上下文 ↓ Action 执行动作 ↓ Verification 验证结果 ↓ Decision 判断继续、重试、升级或停止Prompt Engineering 关注单次交互质量Loop Engineering 关注系统闭环质量。前者决定“这一轮答得怎么样”后者决定“整个任务会不会失控、能不能复现、什么时候结束”。三、一个合格 Loop 的五个组成部分1. Trigger什么时候启动Loop 不能随便启动它必须有明确触发条件。常见触发方式包括触发方式示例风险定时触发每天 9 点检查项目状态可能处理过期上下文事件触发PR 创建后自动 Review可能在权限不足时误操作状态触发CI 失败后进入修复流程可能反复处理同一个失败人工触发开发者输入目标后启动依赖人的目标描述质量一个没有 Trigger 的 Agent 只是聊天窗口有了 Trigger它才开始像一个工程系统。2. Context每一轮读什么Agent 每次行动前都需要知道当前状态但上下文不是越多越好。CI 修复类 Loop 通常需要读取失败日志相关测试文件相关源码最近一次改动项目运行命令上一次 Loop 的执行记录。不应该默认读取与当前失败无关的全仓库文件历史很久的旧日志包含密钥或账号的配置未经确认的大型二进制文件。上下文选择错误会带来两个问题一是模型被噪声干扰二是敏感信息被带入不该进入的执行链路。3. Action这一轮允许做什么Action 是 Agent 真正执行的部分但它不等于“自动改代码”。成熟的 Loop 应该把动作分级动作级别允许行为是否需要人工确认只读读取日志、总结问题、生成报告通常不需要低风险写入修改测试、文档、局部代码视项目规则决定中风险写入改业务逻辑、改依赖、改构建配置建议需要高风险操作删除文件、改权限、改数据库、发布上线必须需要如果一个 Loop 没有动作边界就很容易从“自动辅助”变成“自动破坏”。4. Verification如何判断做得对Verification 是 Loop Engineering 的质量上限。常见验证器包括单元测试是否通过类型检查是否通过Lint 是否通过构建是否成功Diff 是否超出范围是否修改了禁止目录是否引入敏感信息输出是否回答了原始目标。没有 Verification 的 Loop本质上只是“让 AI 自动跑”。它可能完成任务也可能把错误自动放大。5. Stop Rule什么时候停止Loop 最危险的地方不是做不了事而是停不下来。建议至少设计以下停止条件目标完成停止测试通过停止达到最大迭代次数停止连续失败 N 次停止修改范围超过阈值停止触及高风险文件停止成本超过预算停止验证结果无法解释停止并交给人。Stop Rule 不是附加功能而是安全边界。四、可复现最小实验自动修复一个测试失败下面用一个最小 Python 示例验证 Loop 控制器的核心逻辑。这个示例不模拟完整大模型能力只验证四件事能读取失败状态能执行一次最小修复能重新运行验证能在验证通过后停止。1. 项目结构loop_demo_project/ calculator.py test_calculator.py loop_demo.py初始代码故意写错# calculator.pydefadd(a,b):returna-b测试用例# test_calculator.pyfromcalculatorimportadddeftest_add():assertadd(2,3)52. Loop 控制器代码importpathlibimportsubprocessimportsys ROOTpathlib.Path(__file__).parent/loop_demo_projectSRCROOT/calculator.pyTESTROOT/test_calculator.pyMAX_ATTEMPTS3defprepare_project()-None:ROOT.mkdir(exist_okTrue)SRC.write_text(def add(a, b):\n return a - b\n,encodingutf-8,)TEST.write_text(from calculator import add\n\ndef test_add():\n assert add(2, 3) 5\n,encodingutf-8,)defrun_tests()-subprocess.CompletedProcess[str]:returnsubprocess.run([sys.executable,-m,pytest,-q],cwdROOT,textTrue,capture_outputTrue,)defapply_minimal_fix()-None:contentSRC.read_text(encodingutf-8)SRC.write_text(content.replace(return a - b,return a b),encodingutf-8)defmain()-int:prepare_project()forattemptinrange(1,MAX_ATTEMPTS1):resultrun_tests()print(f[attempt{attempt}] exit_code{result.returncode})print(result.stdout.strip())ifresult.returncode0:print(STOP: verification passed)return0ifattempt1:print(ACTION: apply minimal fix to calculator.add)apply_minimal_fix()else:print(STOP: failed after retry, escalate to human)return1print(STOP: max attempts reached)return1if__name____main__:raiseSystemExit(main())3. 本地验证结果执行命令python work/loop_demo.py实际输出[attempt 1] exit_code1 F [100%] FAILURES __________________________________ test_add ___________________________________ def test_add(): assert add(2, 3) 5 E assert -1 5 E where -1 add(2, 3) test_calculator.py:4: AssertionError short test summary info FAILED test_calculator.py::test_add - assert -1 5 1 failed in 0.12s ACTION: apply minimal fix to calculator.add [attempt 2] exit_code0 . [100%] 1 passed in 0.01s STOP: verification passed这个实验能说明三个关键点Loop 不是无限重试而是在MAX_ATTEMPTS内运行Action 不是随意改动而是一次可解释的最小修改Stop Rule 由测试结果触发而不是由模型自称“已经修好”触发。五、把最小实验扩展到真实 Coding Agent真实项目里apply_minimal_fix()不会是简单字符串替换而是调用 Coding Agent 生成补丁。但控制器的骨架不应该变读取失败日志 ↓ 定位相关文件 ↓ 生成候选修复 ↓ 应用最小补丁 ↓ 运行验证命令 ↓ 检查 Diff 范围 ↓ 通过则总结失败则重试或升级推荐把真实 Loop 拆成三层层级职责不应该做的事控制层决定触发、上下文、重试、停止直接相信模型结论Agent 层生成分析、补丁、说明绕过验证器直接提交验证层运行测试、检查 Diff、安全扫描用主观判断替代命令结果这样设计的好处是即使 Agent 生成了错误补丁验证层也能拦住即使验证失败控制层也能限制重试次数并升级给人。六、Loop Engineering 和 Agent Harness 的关系可以把 Agent Harness 理解为承载 Agent 的运行外壳把 Loop Engineering 理解为这个外壳里的控制策略。Agent Harness 常见能力包括工具调用文件读写Shell 执行浏览器操作权限控制日志记录人工确认。Loop Engineering 关注的是什么时候调用这些能力每次调用前后如何记录状态什么结果算成功什么风险必须中断哪些情况交给人。两者关系可以概括为Harness 提供能力Loop 决定能力如何被组织成可靠流程。七、生产环境必须补上的安全边界如果要把 Loop 放进真实研发流程至少要补上以下边界。1. 文件边界明确允许修改和禁止修改的路径。示例allow:-src/**-tests/**-docs/**deny:-.env-secrets/**-migrations/**-infra/**如果 Loop 触及deny路径应立即停止并请求人工确认。2. Diff 边界限制单轮改动范围。例如单轮修改不超过 5 个文件单轮新增代码不超过 300 行不允许删除测试不允许修改锁文件除非任务明确要求。Diff 边界可以避免 Agent 为了修一个小问题引入大面积不确定改动。3. 成本边界长期运行的 Loop 必须限制成本最大迭代次数最大运行时间最大 Token 消耗最大工具调用次数失败后冷却时间。没有成本边界的 Loop 很容易在同一个问题上反复消耗资源。4. 人工升级边界以下情况建议直接交给人测试失败原因不稳定修复需要改业务规则需要删除数据或迁移数据库需要改认证、支付、权限、加密逻辑Agent 给出的解释和测试结果不一致连续两轮修改没有缩小失败范围。人工升级不是 Loop 失败而是工程系统的一部分。八、如何判断一个 Loop 是否合格可以用下面这张表做评审检查项合格标准Trigger启动条件明确不会无意义反复触发Context只读取任务相关信息敏感信息有过滤Action动作有权限分级高风险操作需确认Verification有命令、测试、Diff 或规则验证Stop Rule有完成、失败、超时、成本和风险停止条件Record每轮有日志能复盘为什么继续或停止Escalation无法判断时能交给人而不是继续猜如果一个 Agent 流程只能回答“它做了什么”但回答不了“为什么继续、为什么停止、凭什么判断成功”它还不能算成熟的 Loop。九、常见误区误区 1Loop Engineering 等于让 AI 自动改代码不是。自动改代码只是 Action 的一种。很多高价值 Loop 只做只读分析例如每天总结失败 CI、给 PR 标注风险、扫描文档过期链接。误区 2多跑几轮就是 Loop不是。没有验证器和停止规则的多轮执行只是重复调用模型。误区 3测试通过就一定可以合并不是。测试通过只能证明已覆盖场景没有失败还需要检查 Diff、风险路径、需求一致性和人工审核规则。误区 4上下文越多越好不是。上下文越多噪声、过期信息和敏感信息进入决策链路的概率越高。十、结论Prompt Engineering 仍然重要但它解决的是单轮表达问题。Coding Agent 真正进入研发流程后更关键的是 Loop Engineering用 Trigger 管理启动用 Context 管理输入用 Action 管理能力用 Verification 管理正确性用 Stop Rule 管理风险用 Record 和 Escalation 管理复盘与人工接管。未来 AI 工程能力的分水岭不只是“谁更会写 Prompt”而是谁能把 AI 组织进一个可验证、可停止、可复盘的工程闭环。不要把 Loop 设计成失控的自动化。一个好的 Loop 应该像一个谨慎的初级工程师能做小步修改能跑验证知道何时停下也知道什么时候必须请人判断。参考资料Python 官方文档subprocess.run用于说明示例中如何调用外部测试命令并读取退出码。pytest 官方文档Get Started用于说明示例中pytest -q这类最小测试验证方式。感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
