什么是循环工程？

循环工程是一套设计智能体式工作流（或称循环）的实践，通过迭代方式引导 AI 智能体，以尽可能少的人工干预完成用户自定义目标。智能体循环无需每一步都依靠人类输入提示词，它让智能体可以自主完成行动、观测结果、做出决策并持续迭代，直至任务完成。

对开发者而言，循环工程重塑了其工作角色：不再是手动给 AI 智能体编写提示词，转而去设计能够完成提示、校验、引导智能体的自动化系统。在设计良好的循环中，智能体可以完成推理、执行动作、复盘自身行为结果，并据此调整后续行动。

循环工程是一项新兴的智能体工程实践，是众多 AI 代码智能体（例如 IBM Bob、Claude Code、OpenAI Codex）的底层支撑技术。循环工程对整套执行系统进行优化，让智能体能够在极少人工监管下处理复杂多步骤问题。

提示工程 是为 AI 模型创建最有效、最优化的指令的实践。循环工程所设计的自动化系统可实现自我提示，并对自身输出成果开展评估，直至达成设定目标。

提示工程模式下，由人工编写提示词、评估输出结果，并在每个阶段手动生成后续提示词。循环工程创建了高度自动化的系统，系统会不断改进自身的内部提示，以达到最佳结果。提示链遵循固定死板的流程结构，而执行循环具备动态、灵活的特性。

提示工程适用于一次性交互或单次模型调用。循环工程更适合长时间运行的智能体，用于处理自主代码生成、软件维护或多步骤任务执行这类工作流。

智能体循环通常遵循以下标准模式：

1. 目标
   
   
2. 行动
   
   
3. 观察
   
   
4. 调整

递归目标会在智能体循环的每一轮迭代中进行校验，既保证智能体不偏离任务方向，同时避免无效迭代，控制词元开销。递归目标为 AI 智能体提供了明确的目标，包括明确且可验证的停止标准。这些任务应具体，范围适当，并尽可能分解为可测试的子任务。

“让我的网站加载更快”属于模糊描述；而“当代码通过全部单元测试且满足既定需求时停止迭代”，可为智能体提供可衡量的目标以及明确的终止条件。

智能体会结合自身目标与当前进度进行研判，再采取行动，进一步向目标推进。操作可能包括生成代码、运行单元测试或修复错误。

智能体系统评估行动的结果。通过自动化代码生成，智能体可能会运行持续集成 (CI) 测试，观察生成的代码是否通过或失败。

系统基于观测结果评估反馈信息，对执行策略做出必要调整，之后再重新启动智能体循环。

设计优良的循环可在极少人工监管下运行，同时保持高效、可靠与边界可控。这类流程运行高效，能够控制词元开销，在合适时机终止，并产出可靠结果。相比之下，设计不佳的循环效率低下，会因反复失败尝试、无效工作或是错误推理造成词元浪费。

开发人员在设计能够输出良好结果的循环时，通常会纳入以下要素：

• 自动化或调度
  
  
• 钩子
  
  
• 上下文工程
  
  
• 工具访问
  
  
• 工作树
  
  
• 技能
  
  
• 子智能体
  
  
• 核心主干

重复是循环提示与一次性提示的区别。根据所使用代码助手的不同，循环可通过自动化机制或任务调度来实现。二者均可设定循环的执行节奏，定义循环需要执行的操作以及执行频次。例如，开发人员经常使用 GitHub Actions 来安排或触发智能体循环。

Linux、macOS 这类基于 Unix 的系统，通过名为 cron 作业的时间驱动调度程序实现任务自动化。

与定时自动化不同，钩子是由生成代码、编辑文件、调用工具或完成任务等事件触发的指令。钩子可以发生在关联事件之前或之后。

开发人员大多将钩子用于安全与质量管控，例如执行策略约束、校验输出结果以及自动触发工作流。例如，可使用提交前钩子，在代码变更提交至代码仓库之前，依据规范对代码进行检查。

钩子可让循环中的智能体移除治理和质量检查等任务，从而降低词元成本和算力使用量。

循环的每一轮都会生成被称作上下文的数据，这些数据会输入到后续循环当中。现代 AI 智能体与大语言模型 (LLM) 具备很大的上下文窗口，意味着用户可以一次性输入海量数据。但提供过多上下文会降低内容相关性、推高成本，还会让模型更难识别最重要的信息。

上下文工程是指设计能够提供 AI 模型所需数据，同时最大限度减少冗余上下文的系统实践。应对策略包括：对历史循环迭代做摘要以实现上下文压缩，以及使用 Markdown 优化上下文结构化呈现。

循环架构工程师通常会使用 MCP（模型上下文协议）服务器，并搭配其他 API 与集成组件，让智能体能够借助连接器与工具执行自主操作。如果没有工具访问能力，智能体仅能够描述自身打算执行的操作，而无法对外部系统执行实际动作。

代码智能体借助工具执行代码、访问文件系统、在终端或 Shell 中运行命令、查询数据库以及执行测试。智能体支撑框架工程是一项新兴实践：围绕智能体设计完整的执行环境，以此构建具备持久运行能力、可自我修正的系统。

工作树支持分支，以便多个智能体可以并行工作而不会相互影响。Git 工作树允许多个工作目录分享单一仓库，可并行操作多个分支，且不会重复存储仓库历史记录。智能体不会执行分支合并操作，必须等到代码完成测试、经过人工评审，或是满足用户设定的其他判定条件之后才会执行合并。

技能包含针对单一重复工作流的具体项目知识。智能体在执行对应任务时会读取技能文件。部分代码助手将技能组织为文件夹形式，文件夹内包含 skill.md 文件，存放操作指令与元数据。与之相对，agents.md 这类项目级指令文件的作用范围覆盖整个代码仓库。

如果没有技能，用户就必须在每一次会话中附带项目上下文，或是交由智能体自行推断应当执行的任务，同时还要承担智能体推断出错的风险。技能可以作为插件在项目和代码仓库之间共享。

主智能体可以将任务委派给称为子智能体的专用智能体，由子智能体承担特定角色，例如调研、探索分析、代码实现或结果验证。优秀的循环架构工程会采用生成‑校验架构：由一个智能体对另一个智能体产出的代码开展核查，以此提升代码质量。

虽然子智能体会增加词元消耗，但配置具备独立指令的专用校验子智能体，相比让编码智能体自查自身产出代码，通常可以实现更高的质量保障。部分代码平台会使用独立子智能体，用于监控任务进度，并判断任务是否已满足终止条件。

循环架构包含主干：即持久化状态或记忆体，用于跟踪项目进度，避免重复出现同类错误。每完成一轮循环，智能体会将执行结果写入持久化状态、记忆存储或项目跟踪载体，例如 Markdown 文件、Linear 看板。主干负责保存状态与上下文，为后续迭代执行提供依据。

即便是最健壮、容错能力最强的循环架构，也依然需要人工参与。组织想要从 AI 中获取最大价值，应当利用 AI 加快软件交付，同时依靠人员把控质量、安全以及业务最终成果。

人在回路模式有助于规避自动代码生成中各类高风险隐患，例如未经验证的代码、理解负债、意图负债以及认知放弃。

校验子智能体本质上仍然只是智能体，所有交付上线的代码，最终责任由人类开发人员承担。有效的 AI 治理离不开人工监督：不仅要验证代码可正常运行，还必须确认代码不会泄露敏感数据、不违反各项适用法规。

系统的代码总量，与人类对代码的理解程度之间存在差距，该差距即为理解负债。随着智能体生成的代码越来越多，而人工审查不断减少，理解负债便会持续累积。

传统技术负债源于人为刻意走捷径，而理解负债属于被动产生的负债。智能体代码生成速度很快，理解负债会随之快速累积；并且往往不易察觉，因为代码可以通过自动化测试。倘若不加以缓解，组织通常会在开发人员需要排查生产故障、实施重大变更或处理突发事件时，才发现已经形成严重的理解负债。

意图负债指系统背后设计逻辑的具体说明出现缺失。开发人员的设计意图，若未在 agents.md、skill.md 这类文件中明确详尽记录，智能体很难可靠推断出真实意图。缺少这些信息，智能体可能会朝着错误的战略目标去优化行为；产出的代码修改虽然技术层面没有问题，却与项目目标背道而驰。

随着人类对 AI 的依赖程度加深，更容易出现认知投降现象：即将批判性思考工作完全外包给 AI。认知减负是人类对 AI 生成结果开展核验与监督；而认知投降，则代表人类彻底丧失控制权。

当开发人员不加质疑地接受循环生成的输出结果时，理解负债会快速加剧。