循环工程：从写提示词到设计自主执行闭环

一、从一次问答到多轮协作

在智能体和大模型应用的早期，人们与模型的交互方式非常简单：输入一句指令，获得一个结果。比如要求模型总结一篇文章，或者帮助定位一段代码中的错误。这种模式本质上是“一问一答”，模型只负责根据当前输入生成输出，不关心任务是否真正完成，也不主动验证结果是否可用。

但这种交互方式很快暴露出问题。用户说“总结这篇文章”，却可能得到篇幅过长、语气随意、信息密度不足的结果。用户说“修复这个 bug”，模型可能只给出一个看起来合理但未经过验证的修改建议。原因在于，简单提示词往往只表达了“做什么”，却没有清晰定义“做到什么程度才算完成”。

于是，提示词工程开始受到重视。人们不再只描述任务，而是明确输出格式、限定上下文、指定验证标准，并补充失败时的处理方式。这种改进明显提升了单次回答的质量，也让模型输出更稳定、更可控。

然而，现实中的很多开发任务并不是一次回答就能结束的。例如修复一个隐藏较深的缺陷，往往需要读取日志、复现问题、修改代码、运行测试、根据测试结果继续调整。模型可能在第一步给出合理猜测，但如果没有后续验证与反馈，它很难独立完成整个闭环。

二、人在循环中的局限

为了让智能体完成更复杂的任务，早期实践中普遍采用“人在循环中”的模式。也就是说，模型负责提出建议或执行动作，人类负责审查结果、补充信息、纠正错误，然后让模型继续工作。

这种模式在一定程度上解决了模型能力不足的问题。例如在代码修复场景中，开发者可以先让模型分析报错信息并给出修改方案，然后人工检查修改是否合理，再执行测试。如果测试失败，就把新的报错信息重新交给模型，进入下一轮处理。

但这种协作方式高度依赖人的参与。人需要持续关注任务进展，及时理解模型输出，并判断何时继续、何时停止。对于单个任务来说，这也许可以接受；但当开发者需要同时处理多个任务，或者希望利用夜间、周末等时间运行自动化流程时，这种依赖就变得非常吃力。

更关键的是，人在循环中容易成为系统吞吐量的瓶颈。模型可以快速生成多个候选方案，但等待人类确认、修改和反馈的过程会迅速拉低整体效率。于是，一个自然的想法出现了：能不能让模型围绕目标持续执行、检查、修正，直到任务完成？

三、循环工程的核心思想

循环工程正是在这一背景下提出的。它不是单纯优化某一条提示词，而是设计一个可重复执行的工作循环，让智能体在循环中不断感知环境、采取行动、评估结果、调整策略，直到满足退出条件。

从表面看，循环工程仍然以提示词为基础。毕竟模型每一次执行都需要具体指令，但两者关注的重点完全不同。提示词工程关注的是“如何让模型在单次回答中表现更好”，而循环工程关注的是“如何组织多个步骤，使系统在没有人工干预的情况下稳定推进”。

举例来说，一个面向代码修复的循环可能包含以下步骤：读取错误信息；定位相关代码；生成修改方案；运行测试；如果测试通过则结束，否则把新的失败信息作为输入，重新进入分析阶段。这个循环可以由一个外层控制逻辑驱动，也可以完全交给具备工具调用能力的智能体自行执行。

在这个意义上，开发者的工作重心发生了变化。过去，开发者主要思考如何把需求写得足够清楚；现在，开发者更需要考虑循环如何启动、每一步依赖什么信息、失败后如何恢复、什么条件下可以安全退出。

四、循环的基本结构

一个最小化的执行循环通常包含四个阶段：观察、决策、执行、验证。

观察阶段负责收集任务所需的信息，比如读取报错日志、查看文件内容、获取测试结果。决策阶段根据观察结果确定下一步动作，比如是否修改配置、调整实现逻辑、补充测试用例。执行阶段真正调用工具或修改文件。验证阶段检查执行结果是否满足预期，例如运行测试、检查输出格式、确认错误是否消失。

如果验证通过，循环可以终止；如果验证失败，则带着新的信息回到观察阶段，进入下一轮迭代。这种结构看似简单，但要稳定运行并不容易。

例如，当模型多次修改仍然无法通过测试时，循环可能会陷入无限重试。又如，模型可能在验证失败后反复生成相似方案，导致资源被持续消耗。因此，循环工程还需要考虑最大迭代次数、失败熔断条件、结果回滚策略以及上下文压缩机制。

五、循环工程的六大组件

为了让循环设计更加系统化，行业里已经有人尝试将其拆解为更明确的组成部分。虽然不同实践者的划分方式略有差异，但通常可以归纳为以下六个方面。

第一是目标定义。循环必须围绕明确目标展开，例如“让所有单元测试通过”“将错误率降低到某个阈值以下”。目标越具体，循环的退出条件就越清晰。

第二是上下文管理。循环中的每一步都需要足够的信息，但上下文过长会降低模型效率。因此需要设计信息筛选、压缩和更新机制，让模型始终基于关键信息做决策。

第三是动作空间。这部分定义了模型可以执行哪些操作，比如读取文件、运行命令、修改代码、发送通知。动作空间过大容易导致误操作，过小则无法完成任务。

第四是验证与反馈机制。模型执行动作后，必须有自动化手段判断结果是否有效。测试用例、静态检查、规则引擎都可以作为验证组件。

第五是恢复与回滚策略。当某一步失败或循环进入错误路径时，系统需要知道如何回到安全状态，而不是让错误不断累积。

第六是停止条件。除了任务完成之外，循环还需要设置最大步数、超时时间、重复模式检测等保护机制，避免系统空转。

这六个组件共同构成一个完整的循环执行框架。它们不是彼此独立的功能模块，而是需要在设计阶段统一考虑。例如，验证机制与停止条件必须配合，才能避免模型在接近成功时被过早终止，或在明显失败时继续消耗资源。

六、从提示词工程到循环工程的转变

提示词工程让模型输出更符合预期，循环工程则让模型能够完成需要多步骤、多反馈的实际任务。前者解决的是表达问题，后者解决的是流程问题。

以自动修复代码为例，提示词工程可能关心如何描述 bug、如何限定修改范围、如何要求模型给出可验证的结果。而循环工程关心的是：模型第一轮失败后，是否还能获取新的错误信息；连续失败三次后是否应该回滚；哪些测试失败可以自动重试，哪些失败必须暂停等待人工介入。

这种能力对于一些需要长期运行、批量处理、阶段性验证的任务尤其重要。例如批量迁移代码、生成文档、处理数据清洗任务，都可以从一次性提示词升级为带有反馈与验证的循环流程。

对于企业开发者来说，循环工程的价值还体现在稳定性与可复用性上。一个设计良好的循环可以被保存为模板，在不同项目之间复用，甚至在团队内部形成标准化的执行规范。这样，团队不再依赖某个成员的个人提示词经验，而是可以围绕结构化循环进行协作和优化。

七、如何开始设计一个执行循环

如果开发者想从传统提示词转向循环工程，可以从一个简单的任务开始，逐步增加验证和恢复逻辑。

第一步是明确任务的完成标准。不要只写“修复这个问题”，而要写“在测试全部通过且无新增告警的前提下完成修复”。第二步是梳理任务所需的信息来源，比如代码仓库、测试命令、日志路径。第三步是定义模型可执行的动作，并限制其对关键文件的操作范围。第四步是增加验证步骤，让模型在修改后自动运行测试。第五步是设置保护条件，例如最多重试五次，超过后保留现场并输出失败摘要。

下面是一个概念性的循环示例，不依赖任何具体工具：

while not done and attempts < max_attempts:
    context = collect_info(error_log, test_output)
    patch = propose_fix(context)
    apply_patch(patch)
    result = run_tests()
    if result.passed:
        done = True
    else:
        error_log = result.new_error
        attempts += 1

这个示例只展示了基本结构。实际系统中还需要加入变更回滚、重复补丁检测、上下文摘要等机制，才能让循环在复杂环境中更健壮。

八、循环工程带来的新挑战

循环工程并不是万能方案，它同样引入了新的复杂度。首先是可观测性问题。当模型在没有人工干预的情况下运行数十个步骤后，开发者需要能够追踪每一步的输入、输出和决策依据，否则一旦出错很难定位原因。

其次是成本控制问题。多次迭代意味着多次模型调用和多次工具执行，如果循环设计不当，成本会迅速上升。因此需要在设计阶段加入预算上限和效率评估。

第三是安全性问题。允许模型自动修改代码、执行命令或操作数据时，必须具备严格的权限控制和审计能力。特别是在生产环境中，循环中的动作空间必须被限制在最小必要范围内。

第四是评估问题。单次回答质量可以通过人工打分或固定测试集衡量，而循环执行效果更依赖端到端指标，例如任务完成率、平均迭代次数、失败恢复率等。这对测试与评估体系提出了更高要求。

九、循环工程的适用场景

循环工程适合那些目标明确、验证方式可自动化、步骤可重复的任务。比如持续集成中的问题修复、批量测试用例生成、文档与代码一致性检查、数据管道中的异常重试等。

对于需要频繁进行创造性判断、缺少客观验证标准或者结果高度依赖个人偏好的任务，循环工程并不一定比人机协作更合适。因此，开发者需要根据任务特征选择是否引入循环，而不是在所有场景下都追求完全自动化。

未来，随着智能体工具调用能力、上下文管理能力和评估机制的持续演进，循环工程可能成为开发者日常工作中的基础范式。它并不意味着提示词工程不再重要，而是提示词会被嵌入到更大的执行结构中，成为循环中的关键组件之一。

从写提示词到设计循环，变化的不仅是技术手段，更是开发者组织自动化工作的方式。那些能够清晰定义目标、设计可靠验证机制、控制失败风险的团队，将更有可能把智能体真正纳入日常开发流程，而不仅仅停留在单次问答的效率提升上。