Loop Engineering：让 AI 从回答问题走向持续执行

过去几年，人和AI协作的方式一直在悄悄升级。

一开始，大家关注的是Prompt Engineering：怎么把问题问清楚，怎么让模型给出更准确的答案。后来任务复杂起来，焦点转移到了Context Engineering：怎么让模型看到正确的信息，记住项目背景、用户偏好和历史决策。再往后，AI不再只是生成文本，它能调用工具、读写文件、执行命令、访问外部系统了，于是Harness Engineering变得重要：怎么给AI搭建一个安全、可靠、可观测的工具环境。

但当AI真正开始承担工程任务时，一个更本质的问题浮现了出来：

• 测试失败后，它能不能自己分析原因、修改代码、再次验证？
• CI还没跑完时，它能不能等待一段时间后恢复任务？
• 研究一个复杂问题时，它能不能不断搜索、排除、归纳、交叉验证？
• 做长期维护时，它能不能定期检查状态，并在发现异常时自动响应？
• 如果任务进入高风险区域，它能不能知道该停下来交给人？

这些问题已经远远超出了单次提示词、上下文组织或工具调用的范畴。它们指向的是一个更外层的工程问题：如何设计AI的持续执行循环。

这就是我们今天要聊的——Loop Engineering（循环工程）。

2. 什么是 Loop Engineering？

简单说，Loop Engineering 是一种设计AI自主迭代执行模式的工程方法论。

它关注的不是“某一次AI调用是否足够聪明”，而是一个AI系统能否在明确目标、有限资源和安全边界内，持续完成以下动作：

观察状态 → 规划下一步 → 执行动作 → 验证结果 → 更新状态 → 判断是否继续

一个成熟的Loop Engineering系统，通常包含七个关键要素：

所以，Loop Engineering 不是让AI无限自动运行，而是让AI在可控边界内持续推进任务。

一句话概括：它是给AI装上“方向盘”和“刹车”，而不是让它撒开腿乱跑。

3. 与其他 AI 工程方法论的区别

Loop Engineering 并不是要取代Prompt Engineering、Context Engineering或Harness Engineering。它更像是站在它们之上的一层，把单次能力组织成持续执行的系统。

它们的关系可以理解为：

Loop Engineering
    └── Harness Engineering
        └── Context Engineering
            └── Prompt Engineering

3.1 Prompt Engineering：优化一次调用

Prompt Engineering 关心的是如何让模型在一次调用中更准确地理解任务。典型问题包括：角色怎么设定？任务怎么描述？输出格式怎么约束？是否需要示例？是否需要分步推理？

请你作为资深代码审查专家，审查下面这段代码，并按“问题 / 风险 / 建议”输出。

它解决的是“这一问怎么问得更好”。

3.2 Context Engineering：管理模型的视野

Context Engineering 关心的是模型应该看到哪些信息。典型问题包括：哪些文件、日志、文档、历史决策需要放进上下文？哪些信息应该检索，哪些应该摘要？上下文窗口有限时，哪些内容优先保留？多轮对话后，如何避免关键信息丢失？

加载项目 README、相关源码、最近一次失败的测试日志、团队编码规范和历史修复记录。

它解决的是“AI应该基于什么信息判断”。

3.3 Harness Engineering：给 AI 配工具和边界

Harness Engineering 关心的是AI能调用什么工具，以及这些工具是否安全可靠。典型问题包括：AI能不能读写文件？能不能运行测试？能不能访问数据库、浏览器、GitHub、CI？工具权限如何限制？工具失败时如何处理？调用过程如何审计？

tools = [{"name": "read_file", "parameters": {"path": "string"}},{"name": "run_tests", "parameters": {"scope": "string"}},{"name": "create_pr_comment", "parameters": {"body": "string"}},]

它解决的是“AI能不能安全地行动”。

3.4 Loop Engineering：把能力组织成闭环

Loop Engineering 关心的是AI如何在多轮反馈中持续推进任务。典型问题包括：第一轮做什么？失败后如何调整策略？哪些结果需要写入状态？如何判断下一轮是否还有价值？什么时候停止？什么时候必须请人确认？

const MAX_ATTEMPTS = 5
for (let attempt = 1; attempt <= MAX_ATTEMPTS; attempt++) {
    const result = await runTests()
    if (result.passed) {
        await report("测试通过，任务完成")
        break
    }
    const diagnosis = await analyzeFailures(result.failures)
    await applyFix(diagnosis)
    if (attempt === MAX_ATTEMPTS) {
        await escalate("连续修复失败，需要人工介入")
    }
}

它解决的是“AI如何持续、稳定、可控地做事”。

4. Loop Engineering 的优势

Loop Engineering 的价值，不在于让AI显得更“自动”，而在于让AI的自动化具备工程上的可控性。

4.1 适合长周期任务

很多真实任务无法一次完成。它们需要搜索、执行、等待、验证、修复、总结和恢复。Loop Engineering 通过状态管理和检查点，让任务可以跨时间窗口推进。

4.2 能处理反馈和失败

传统的单次调用很难处理失败反馈。Loop Engineering 把失败视为循环的一部分：失败不是终点，而是下一轮诊断和调整的输入。

4.3 能把工具调用变成工作流

单独的工具调用只是动作，循环设计才能把动作组织成流程。比如“运行测试”和“修改代码”只是工具能力，“测试-诊断-修复-验证”才是可执行工作流。

4.4 更容易控制风险

好的循环会显式设计权限边界、终止条件、人类确认点和审计记录。它不是让AI随便跑，而是让AI在被设计好的轨道中行动。

4.5 可复用、可调优

一旦某类循环被验证有效，就可以沉淀成模板。例如测试-修复循环、监控-响应循环、研究-收敛循环，都可以在不同项目中复用和改进。

5. 适合 Loop Engineering 的场景

5.1 场景一：测试-修复循环

这是最典型的工程场景。

运行测试 → 分析失败 → 修改代码 → 再次测试 → 通过或升级给人类

适合： 修复单元测试失败、迁移框架版本、修改API后更新调用方、自动处理lint/类型错误和构建错误。

关键设计： 每轮只修复一类问题；设置最大尝试次数；保留失败日志和修复记录；测试不通过时不要扩大修改范围。

5.2 场景二：监控-响应循环

适合运维、安全、数据质量和业务巡检。

检查状态 → 发现异常 → 分类分级 → 自动处理或通知人类 → 记录结果

适合： 服务健康检查、数据管道巡检、依赖过期提醒、安全告警初筛、每日构建状态汇总。

关键设计： 告警必须分级；自动修复只覆盖低风险动作；高风险动作必须升级给人；每次处理都要留下审计记录。

5.3 场景三：研究-收敛循环

适合信息量大、不确定性高的问题。

广度搜索 → 识别线索 → 深入分析 → 交叉验证 → 输出结论

适合： 理解大型代码库、调研技术方案、梳理复杂bug的根因、整理文档/论文或网页资料。

关键设计： 记录已排除路径，避免反复搜索；区分事实、推断和观点；对关键信息做交叉验证；在不确定时明确标注。

5.4 场景四：长周期开发循环

适合一个需求需要多阶段推进的情况。

拆解任务 → 实现阶段目标 → 验证结果 → 更新计划 → 继续下一阶段

适合： 从需求到实现的完整功能开发、大规模重构、文档系统建设、多模块迁移、自动化PR准备。

关键设计： 每阶段都要有可验证交付物；阶段之间要写入检查点；计划可以更新，但更新原因要记录；上下文压缩前必须留下恢复摘要。

6. 如何构建自己的 Loop Engineering？

构建Loop Engineering不需要一开始就做复杂系统。最好的方式是从一个小而清晰的循环开始，把目标、工具、状态、验证和终止条件设计清楚。

6.1 第一步：定义目标和成功标准

先不要急着写prompt或接工具。先回答两个问题：这个循环要持续完成什么任务？什么结果算成功？

坏的目标： 帮我优化项目。

好的目标： 持续运行测试并修复失败，直到核心测试全部通过，或连续3次修复失败后交给人工处理。

目标要尽量满足三个条件：可观察（系统能知道当前状态）、可验证（系统能判断是否达成）、可收束（系统知道什么时候停止）。

6.2 第二步：选择循环类型

根据任务特征选择触发方式。

loop: type: event-driven trigger: ci_failed goal: "分析 CI 失败并尝试修复"

6.3 第三步：设计单轮迭代流程

把一轮循环拆成固定阶段。最常用的结构是：

Observe → Plan → Act → Verify → Record → Decide

对应到代码任务，可以是：

读取失败日志 → 制定修复计划 → 修改代码 → 运行测试 → 记录结果 → 判断是否继续

可以写成一个简单模板：

iteration:
  observe:
    - read_test_log
    - inspect_changed_files
  plan:
    - identify_root_cause
    - choose_fix_scope
  act:
    - edit_files
  verify:
    - run_unit_tests
    - run_typecheck
  record:
    - sa ve_attempt_summary
  decide:
    - continue_if_tests_fail_and_attempts_left
    - stop_if_tests_pass
    - escalate_if_risk_high

这一步的关键是：不要让AI每轮都“自由发挥”。自由判断可以有，但循环骨架要稳定。

6.4 第四步：准备上下文

Loop Engineering不是孤立存在的，它需要Context Engineering支撑。每一轮至少要提供这些上下文：当前目标、成功标准、当前状态、最近一次执行结果、已尝试过的方法、明确禁止的动作、需要遵守的项目规范。

推荐为循环维护一个状态文件：

goal: "修复核心测试失败"
success_criteria:
  - "npm test 通过"
  - "npm run typecheck 通过"
attempts: 2
last_result: "仍有3个测试失败"
tried:
  - "修复用户状态初始化"
  - "调整mock数据结构"
next_plan: "检查权限判断分支"
blocked:
  - "不能修改公开API"

6.5 第五步：配置工具和权限

Loop Engineering需要Harness Engineering支撑。你要明确AI可以调用哪些工具，以及每个工具的权限边界。

常见工具包括：文件读取和编辑工具、测试运行工具、构建和类型检查工具、搜索工具、浏览器或API工具、任务状态记录工具、通知或评论工具。

工具权限应该按风险分层：

最重要的原则： 循环可以自动推进，但高风险动作不能自动越权。

6.6 第六步：设计验证机制

没有验证机制，循环就会变成“做了很多事但不知道有没有用”。

验证步骤要写进循环，而不是留给人类事后检查。

6.7 第七步：设置终止条件

终止条件是Loop Engineering的安全阀。

常见终止条件包括：

• 成功：目标达成，例如测试通过。
• 失败：达到最大尝试次数。
• 预算：token、时间、成本或工具调用次数用尽。
• 风险：需要高风险操作。
• 阻塞：缺少权限、依赖不可用、信息不足。
• 人工中断：用户明确停止。

stop_conditions:
  success:
    - "all_tests_passed"
  failure:
    - "attempts >= 5"
    - "same_error_repeated >= 3"
  budget:
    - "remaining_tokens < 50000"
  escalation:
    - "requires_production_access"
    - "requires_destructive_change"

一个优秀的循环不是永远运行，而是能清楚地解释“为什么继续”和“为什么停止”。

6.8 第八步：设计人机交互点

人类不应该被迫参与每一步，但也不能完全被排除在外。

适合AI自动处理： 收集信息、运行测试、生成候选方案、修改低风险文件、生成总结。

必须请求人类确认： 删除或覆盖重要数据、修改安全策略、发布到生产环境、合并或部署代码、在多个业务取舍中做最终选择。

一个实用原则是： “风险越大，越要让人参与”。

6.9 第九步：记录日志和检查点

循环要能被追踪、恢复和复盘。每轮至少记录：本轮目标、执行动作、工具调用结果、验证结果、判断依据、下一步计划、是否需要人工介入。

推荐每轮结束都生成一段简短摘要：

第3轮：修复权限判断分支后，单元测试从5个失败减少到1个失败。剩余问题集中在admin用户mock数据缺少role字段。下一轮计划：修正mock数据并重新运行user-service测试。

这样即使上下文被压缩、会话被中断，循环也能恢复。

7. 一个最小可用的 Loop Engineering 模板

下面是一个可以直接改造的最小模板：

name: test-fix-loop
goal: "持续修复测试失败，直到测试通过或达到最大尝试次数"

trigger:
  type: manual

state:
  attempts: 0
  max_attempts: 5
  tried: []
  last_result: null

context:
  include:
    - project_readme
    - failing_test_log
    - related_source_files
    - coding_standards

tools:
  allowed:
    - read_file
    - edit_file
    - search_code
    - run_tests
  requires_confirmation:
    - delete_file
    - publish_release
    - merge_pr

iteration:
  - observe: "读取失败日志和相关代码"
  - plan: "识别最可能根因，限定本轮修改范围"
  - act: "实施最小修复"
  - verify: "运行相关测试"
  - record: "记录本轮尝试、结果和下一步"
  - decide: "通过则结束；失败且未超限则继续；超限则升级"

stop_conditions:
  success:
    - "tests_passed"
  failure:
    - "attempts >= max_attempts"
    - "same_failure_repeated >= 3"
  escalation:
    - "requires_destructive_action"
    - "requires_business_decision"

这个模板虽然简单，但已经覆盖了Loop Engineering的核心：目标、触发、状态、上下文、工具、迭代、验证和终止。

8. 常见错误

8.1 把循环做成无限重试

如果每一轮没有引入新信息、新策略或更小的问题范围，重复执行只会浪费资源。

8.2 只设计行动，不设计验证

“修改了代码”不等于“修好了问题”。验证必须是循环的一部分。

8.3 没有状态文件

长任务跨上下文窗口时，很容易丢失“已经试过什么”“为什么这么做”“下一步是什么”。

8.4 权限边界太宽

自动化越强，越需要明确哪些动作必须人工确认。

8.5 没有失败出口

好的循环不怕失败，怕的是失败后还假装可以继续。

9. 总结

AI工程正在从“如何得到一个好回答”，走向“如何让AI可靠地完成一段工作”。

Prompt Engineering、Context Engineering和Harness Engineering分别解决了表达、视野和行动能力的问题；Loop Engineering则进一步解决持续执行的问题。

它的核心不是无限自动化，而是一个有反馈、有状态、有边界、有终止条件的执行闭环。

真正成熟的Loop Engineering，应该让AI做到四件事：

• 知道目标是什么。
• 知道下一步为什么值得做。
• 知道做完后如何验证。
• 知道什么时候必须停下来交给人。

当AI从“会回答”变成“能持续推进”，工程方法论也必须从prompt走向loop。这就是Loop Engineering的意义所在。

10. 参考资源

• AI coding agent 与长期任务执行实践
• MCP（Model Context Protocol）相关规范
• Tool / Function calling 与 agent runtime 设计实践
• CI/CD、任务调度、可观测性和工作流编排中的成熟工程模式