循环工程：从提示词到自主任务闭环

一、为什么会出现“循环工程”

过去两年，大多数人与大模型协作的方式可以概括为“提示—回复—再提示”。开发者精心组织一段上下文，把需求、约束和期望输出交代清楚，发送给模型，等待结果，再根据结果继续输入下一轮指令。这种模式中，人始终是流程的推动者：每一步做什么、下一步怎么走，都由人来决定。

这种方式的优势是可控、直观。但问题也很明显：当任务规模变大、步骤变多、依赖关系变复杂时，人的输入速度、注意力持续时间和手工组织上下文的能力，会成为整个流程的瓶颈。与此同时，大模型单次会话的持续运行能力已经显著增强，可以在较长时间内保持任务上下文，并基于中间结果自主判断下一步操作。继续依赖人工逐条编写提示词，不仅效率下降，也很难充分发挥模型的能力。

行业思路因此发生变化：与其不断优化单条提示词，不如设计一套小的自动化系统，让模型在目标约束下自主完成“发现问题—分配任务—执行—检查—记录—再决策”的循环。这便是循环工程的核心思想：设定一个最终目标，让模型持续迭代运行，直到任务完成或达到退出条件。

二、循环工程与提示工程的区别

提示工程关注的是单次输入的质量：如何描述任务、如何提供示例、如何约束输出格式、如何控制语气和结构。它优化的是“一次交互”的效果。

循环工程优化的是“一组交互的可持续性”。它更接近软件系统中的控制流设计：需要定义循环的入口、迭代条件、退出条件、状态保存、异常处理和人工介入点。一个循环可能内部包含几十次模型调用，每次调用只负责一个相对小的子任务，但整个循环的目标是完成一个较大任务。

可以这样理解：提示工程解决“怎么问”，循环工程解决“怎么让模型持续干下去”。后者依赖于前者，但不止于前者。

三、一个可运行循环的核心组成部分

一个稳定、可落地的循环系统通常包含六个模块：

1. 目标定义模块

循环必须有一个明确的最终目标。目标不能太模糊，否则模型会在迭代中逐渐偏离方向。有效的目标定义通常包含以下要素：

• 最终交付物是什么；
• 完成标准是什么；
• 哪些内容是明确不在范围内的；
• 优先级与约束条件。

例如，目标是“分析一份日志文件并输出故障根因”，完成标准可以包括“必须列出时间线、定位到具体服务、给出至少一个可验证的假设”。目标越清晰，循环越不容易失控。

2. 任务分解模块

模型需要把大目标拆解为可执行的子任务。好的任务分解应满足几个条件：子任务之间依赖关系清晰；每个子任务都有可检查的输出；子任务的粒度适中，太大则单次调用不稳定，太小则循环轮次过多。

实现上，可以让模型在每轮迭代中输出结构化的任务列表，例如：

{
  "current_task": "提取错误日志中的时间戳与堆栈信息",
  "next_tasks": [
    "按服务聚合错误类型",
    "检索对应时间段内的发布记录"
  ],
  "dependencies": []
}

这种结构化输出便于后续模块判断进度。

3. 执行模块

执行模块负责真正调用模型完成单个子任务。它与普通提示词的最大区别在于：输入不再是“从零开始的需求描述”，而是前面环节已经整理好的上下文、约束与当前任务描述。

执行模块的输入通常由三部分组成：

• 全局目标与约束；
• 已完成任务的结果摘要；
• 当前要执行的子任务说明。

这样每一轮执行都能保持对全局目标的理解，同时不被过多历史细节干扰。

4. 自检与评估模块

循环能否稳定运行，很大程度上取决于模型是否具备“检查自己产出”的能力。自检模块的作用是对执行结果进行质量判断，并输出明确的检查结论。

常见检查维度包括：

• 是否满足当前子任务的完成条件；
• 输出是否符合预期格式；
• 是否存在明显遗漏或错误；
• 是否与全局目标产生冲突。

可以要求模型输出类似下面的结构：

{
  "status": "pass",
  "issues": [],
  "confidence": 0.9,
  "revised_plan": []
}

当状态为“fail”时，需要把问题反馈给执行模块，进行修正或重试。

5. 状态记录模块

长循环任务不能依赖模型自身的短期记忆。每一轮的关键信息必须被持久化：任务目标、已完成的子任务、当前进度、待处理事项、重要结论和失败记录。

状态记录可以采用文件、数据库或对象存储等通用存储方案。记录内容应尽量结构化，便于模型在下一次迭代中快速理解“现在到哪了”。例如：

[完成] 提取错误日志时间戳与堆栈信息
[完成] 按服务聚合错误类型
[进行中] 检索对应时间段内的发布记录
[待处理] 关联发布记录与错误爆发时间点

6. 调度与退出模块

调度模块决定下一步执行什么。它根据状态记录、依赖关系和优先级选择下一个任务。如果多个任务可并行，调度模块可以判断是否同时执行；如果存在依赖，则必须等待前序任务完成。

退出模块定义循环何时结束。可能的退出条件包括：

• 所有子任务均已完成并通过自检；
• 达到最大迭代轮数；
• 连续多次自检失败；
• 遇到必须人工决策的阻断点。

缺少退出条件的循环很容易陷入空转，消耗资源却不产生有效进展。

四、设计循环时的几个关键原则

1. 让每一步都可验证

循环中最危险的情况不是某一步出错，而是错误被传递到后续步骤。因此，每个子任务的输出都应具备可验证性。尽量要求模型输出结构化结果，而不是大段自由文本。结构化结果便于自动检查字段完整性、类型正确性和逻辑一致性。

2. 控制单轮复杂度

单轮任务越复杂，模型出错概率越高。把复杂任务拆成多个小步骤，每一步只处理一个明确问题，比让模型一次完成所有工作更可靠。代价是循环轮次增加，但稳定性通常显著提升。

3. 保持全局上下文的轻量更新

随着循环推进，历史记录会越来越大。如果把所有细节都塞进每一轮输入，既浪费资源，也容易淹没关键信息。更合理的做法是维护一个全局状态摘要，每一轮只把摘要和当前任务输入给模型，执行完成后再更新摘要。

4. 为人工介入预留位置

循环工程的目标不是完全无人参与，而是尽量减少不必要的人工操作。对于高风险决策、对外发布内容或涉及资源变更的操作，应设计人工确认节点。这样可以在自动化与可控性之间取得平衡。

五、循环工程的典型应用形态

循环工程并不是某一种固定软件，而是一种设计模式。它可以应用于多种场景：

• 自动化代码修改：让模型在代码库中定位问题、修改、运行测试、根据测试结果继续修复；
• 文档生成与校验：根据需求生成结构文档，再检查章节完整性、术语一致性和格式规范性；
• 日志分析与故障定位：从原始日志出发，逐步聚合、归因、生成时间线和结论；
• 数据处理流水线：对数据集执行清洗、转换、校验、导出等分步操作。

这些场景的共同点是：任务可以被拆解为多个有依赖关系的步骤，且每个步骤的输出可以被检查。循环工程提供了一套让模型在多步骤任务中保持方向感与连续性的方法。

六、从“写提示词”到“搭循环”

循环工程并不是要否定提示工程。恰恰相反，单个步骤的提示词质量仍然重要。但它把关注点从“一次好的问答”提升到“一个可持续推进的任务系统”。

对于开发者来说，这意味着一个新的工作方式：不再是逐条输入指令，而是花更多时间设计目标、约束、状态结构与退出条件。写完循环之后，真正的工作是观察系统运行、发现不稳定点、调整循环结构和自检规则。

当大模型具备更长的持续运行能力后，限制任务推进速度的往往不再是模型本身，而是我们设计的流程。循环工程的价值正在于此：它把人的角色从每一步的操作者，转变成整个循环的设计者和监督者，从而让模型在清晰的边界内自主完成任务。