Loop Engineering：当 AI 编程从"写提示词"进化到"设计循环"
从一次性提示到智能闭环，AI 编程的下一场范式革命。
从"提示词工程师"到"循环设计师"
先讲个真实经历。前段时间我想让大模型帮我重构一个几百行的老模块，我花了整整一个下午打磨提示词：贴上下文、写清约束、举正反例、甚至把代码风格指南都塞了进去。提示词写得堪称艺术品。结果呢？模型一口气吐出一大段代码，看起来漂亮极了，一跑——五个测试挂了三个。
我改了改提示词，再来一次。又挂了两个，而且这次还引入了一个新 bug。
那一刻我突然意识到一件事：问题不在提示词，而在我用它的方式。 我在用一个"发射后不管"的姿势，去完成一件本质上需要"反复试错、边做边验证"的工作。这就好比让一个工程师闭着眼睛写完整个功能，中途不许编译、不许跑测试、不许看报错——写完直接交付。再厉害的工程师也扛不住。
最近在深度使用各种大模型和 Agent 工具时，我越来越明显地感觉到：单纯写好提示词的时代正在过去。取而代之的，是一个全新的范式——Loop Engineering（循环工程）。
你还停留在"给我写一段代码"这样的单次指令上吗？真正的顶级玩家，已经不再纠结"这句提示词怎么措辞更好"，而是开始设计 AI 的运行循环：让 AI 自己规划、执行、验证、迭代、纠错，形成一个闭环系统，像工程师设计软件架构一样，去设计 AI 的思考与行动流程。
一句话概括这个转变：
Prompt Engineering 优化的是"一次对话说什么"，Loop Engineering 优化的是"整个系统如何持续逼近正确答案"。
前者关心措辞，后者关心控制。这篇文章，我们就来深入聊聊这个从"Prompt Engineering"到"Loop Engineering"的进化——不只是讲概念，还会拆架构、看真实案例、上手写代码、聊清楚坑在哪。
为什么"写提示词"不够了？
传统提示工程（Prompt Engineering）本质上是一次性输入输出（One-shot / Open-loop）：
- 你扔一个超级详细的 Prompt
- AI 给你一个答案
- 结束
这个模式在"翻译一句话""改写一段文案""解释一个概念"这类闭合、短程、可一眼验证的任务上非常好用。但一旦任务变长、变复杂、变得需要和外部环境交互，它的天花板就暴露无遗：
- 幻觉（Hallucination）无法自愈：模型编造了一个不存在的 API、一个错误的数字，它自己完全意识不到，因为没有任何机制去"对答案"。
- 复杂任务容易半途而废：让它做一个 10 步的任务，它常常在第 6 步就"觉得差不多了"，提前收尾。上下文越长，注意力越涣散。
- 缺乏自我纠正机制：一次生成就是终点。哪怕答案离谱，也没有第二次机会。人类写代码是"写—跑—看报错—改"，而一次性 Prompt 砍掉了后面三步。
- 无法处理动态环境：真实任务里，文件内容会变、接口会返回意外结果、测试会失败。静态提示词无法对"运行时才知道的信息"做出反应。
想象一下，让 AI 帮你开发一个完整的产品功能。只给它一个 Prompt，它很可能写出 bug 满满的代码，然后一脸自信地"交作业"。它不是不够聪明，而是你没给它验证和重试的机会。
这里有个关键洞察值得记住：
一次性 Prompt 的能力上限 ≈ 模型在"第一次尝试"上的能力。而 Loop 的能力上限 ≈ 模型在"多次尝试 + 反馈"下的能力——后者往往高出一大截。
学术界早有量化：在 SWE-bench（真实 GitHub issue 修复基准）这类任务上，同一个模型，"单次生成补丁"的通过率和"允许它跑测试、看报错、迭代修复"的通过率能差出好几倍。模型没变，变的是你把它放进了一个循环里。
而 Loop Engineering 的核心就是：把 AI 从一个"应答机"变成一个带反馈的智能体（Agent），让它在循环中不断验证、纠错、进化输出。
换个脑子：从"开环控制"到"闭环控制"
如果你有一点控制论或者自动化的背景，这个转变会瞬间通透。
- 一次性 Prompt = 开环控制（Open Loop）：像老式定时浇水器，到点就浇，不管土壤是干是湿。指令发出去就结束，不看结果。
- Loop Engineering = 闭环控制（Closed Loop）：像恒温空调，装了个温度传感器，实测温度和目标温度一比对，就自动调节。有反馈、有对比、有调节。
闭环控制里有三个不可或缺的角色，套到 AI 循环上就是：
| 控制论概念 | AI 循环里的对应 | 作用 |
|---|---|---|
| 执行器（Actuator） | Executor（写代码、调工具） | 对环境施加动作 |
| 传感器（Sensor） | Verifier（跑测试、查结果） | 观测环境的真实状态 |
| 反馈调节（Feedback） | Critic / Reflector | 用"实际 vs 目标"的差距去修正下一步 |
所以 Loop Engineering 真正的门槛，从来不是"怎么写好那句 Prompt"，而是——
你能不能给这个系统装上一个可靠的"传感器"（验证器），以及一条把误差反馈回去的"回路"？
这句话记住了，你就理解了这篇文章一半的内容。下面我们把这个闭环拆开看。
Loop Engineering 的核心架构
一个典型的 Loop Engineering 系统通常包含以下组件。你可以把它们想象成一支小型工程团队里的不同角色：
Planner（规划器）：任务的"项目经理"。把一个模糊的大目标（"做一个用户登录系统"）分解成有序的、可执行的子任务（设计数据表 → 写注册接口 → 写登录接口 → 写测试）。好的 Planner 会显式产出一份计划清单，而不是闷头就干。
Executor（执行器）：真正"干活"的手。调用工具、写代码、执行命令、查询数据库、发起网络请求。这是循环里唯一能真正改变外部世界状态的组件。
Verifier（验证器）：整个循环的灵魂。运行测试、检查输出、比对预期。它是那个能告诉系统"你做的到底对不对"的传感器。没有可靠的 Verifier，循环就是在空转——甚至会越转越糟。 后面会专门讲为什么它这么重要。
Critic / Reflector（批评者 / 反思器）：当验证失败时，负责分析"为什么错了"，并把教训转化成下一轮的具体改进建议。它是"我上次为什么摔倒"到"这次怎么绕开"之间的那座桥。这一步是 Reflexion 等方法的核心。
Memory（记忆模块）：记录历史迭代——试过哪些方案、踩过哪些坑、得到过哪些中间结论。防止 Agent 犯"金鱼记忆"式的错误：转了三圈又回到第一圈的错误方案。分短期记忆（本次任务的上下文）和长期记忆（跨任务沉淀的经验）。
Orchestrator（协调器）：循环的"总调度"。决定下一步该谁上场、循环要不要继续、什么时候该果断停下。它掌管着最关键的两个开关：退出条件和熔断机制。
它们之间的数据流大致长这样：
┌───────────────────────────────────────────────┐
│ │
▼ │
[Planner] ──计划──▶ [Executor] ──动作──▶ [ 环 境 ] │
│ │
观测 │
▼ │
[Verifier] │
通过? │
┌────┴────┐ │
是 │ │ 否 │
▼ ▼ │
[ 输出 ] [Critic]──反馈──┘
▲
│
[Memory 记录/回溯]这个循环可以是固定次数（"最多重试 5 次"），也可以是直到满足退出条件（如"所有测试通过"或"验证器打分 ≥ 95"），还可以是两者的组合（"跑到通过为止，但最多 10 轮，超了就上报人类"）。
这里藏着 Loop Engineering 最核心的工程判断：退出条件的设计，比循环体本身还重要。 退出条件太松，循环停不下来烧钱；太紧，还没收敛就放弃。这是"设计循环"这门手艺里最见功力的地方。
四种经典循环范式（附适用场景）
"循环"不是只有一种长法。工业界和学术界这几年沉淀出了几种经典范式，理解它们，你才知道面对一个新任务该"设计成什么形状的循环"。
1. ReAct（Reason + Act）—— 最基础的思考-行动循环
模型交替进行"推理（Thought）"和"行动（Action）"，每次行动后拿到"观察（Observation）"，再据此推理下一步。这是绝大多数 Agent 的地基。
Thought: 我需要知道这个函数在哪里被调用
Action: grep "login()" src/
Observation: 在 auth.py:42 和 views.py:88 被调用
Thought: 那我改函数签名时这两处都要同步改...适用：需要边探索边决策、单步就能验证的通用任务。
2. Plan-and-Execute（先规划后执行）—— 应对长程任务
先让模型一次性想清楚完整计划，再逐步执行。好处是全局视野强、不容易"走一步看一步走偏"；代价是计划可能与现实脱节，所以通常配合"执行中允许重新规划（Replan）"。
适用：步骤多、依赖关系复杂、需要全局统筹的任务（如"从零搭一个 CRUD 服务"）。
3. Reflexion（反思式循环）—— 让失败变成养料
在 ReAct 基础上加一层：失败后不是直接重试，而是先用语言总结这次为什么失败，把这段反思写进记忆，作为下一次尝试的额外上下文。相当于给 Agent 装了个"复盘本"。实践证明，这一层反思能显著提升多轮任务的成功率。
适用：允许多次尝试、且"从错误中学习"能带来明显增益的任务（调试、解题、写作打磨）。
4. Tree / Graph Search（树 / 图搜索式循环）—— 不撞南墙不回头？不，能回头
前面几种都是"线性"往前走。而树搜索（如 Tree of Thoughts、LATS）允许同时探索多个分支、给每个分支打分、砍掉差的、回溯到更好的节点继续。它把"循环"升级成了"带评估的搜索"。代价是成本高得多。
适用：解空间大、一条路走到黑风险高、值得"多花钱买正确率"的高价值任务。
一句话选型： 简单交互用 ReAct；长任务用 Plan-and-Execute；要从失败里学东西用 Reflexion；解空间大且值钱，才上 Tree Search。
真实案例：从 Prompt 到 Loop 的进化
案例 1：代码生成与调试
- Prompt 时代："帮我写一个用户登录系统" → 一段代码，可能能跑，可能不能，你自己去调。
- Loop 时代：
- Planner 拆解：设计用户表 → 密码哈希 → 注册接口 → 登录接口 → 单元测试
- Executor 生成初始代码 + 一套测试
- Verifier 自动运行单元测试
- Critic 分析失败用例：
test_login_wrong_password挂了，因为没处理密码错误分支 - Executor 针对性修复 bug 并重新测试
- 循环 3–5 次，直到所有测试通过才收工
注意第 4 步——它不是重写一遍，而是读懂了具体是哪个测试、因为什么原因失败，然后做精准修复。这就是有 Verifier 反馈和没有的天壤之别。
案例 2：研究与报告写作
传统方式：让 AI 一次性写 5000 字报告 → 大概率数据错误、引用虚构、逻辑跳跃，读起来头头是道，一核实全是坑。
Loop 方式，把它拆成一条流水线：
搜索最新文献 → 提取关键事实（带来源）→ 生成大纲 → 分章节撰写草稿 → 逐条交叉验证事实（每个数字都回去核对来源） → 润色逻辑与过渡 → 生成最终版本
同样，魔法发生在那个"交叉验证事实"的环节——它是这条循环里的 Verifier。
案例 3：这不是未来，是你正在用的工具
别以为 Loop Engineering 是实验室里的概念。你天天用的工具，底层就是它：
- Claude Code / Cursor Agent 模式：你说一句"修复这个 bug"，它自己去读文件、改代码、跑测试、看报错、再改——你看到的每一次"自动重试"，都是一次循环迭代。
- Devin、OpenHands 等自主编程 Agent：在 SWE-bench 这类真实 issue 修复基准上刷分，靠的就是"生成补丁 → 跑测试 → 根据失败迭代"的闭环，而非一次生成。
- Deep Research 类功能（各家都有）：本质是"搜索 → 阅读 → 判断信息够不够 → 不够就换关键词再搜 → 综合成报告"的多轮循环。
当你理解了循环，你就从这些工具的"用户"，升级成了能看懂它们、甚至自己搭一个的"设计者"。
主流框架与工具推荐
目前支持 Loop Engineering 的优秀框架不少，但它们的定位差别很大，别拿到手就乱用：
| 框架 | 定位 | 优点 | 适合场景 |
|---|---|---|---|
| LangGraph（LangChain 生态） | 状态机 / 图式循环编排 | 循环、分支、回溯控制力最强，可视化调试友好 | 需要精细控制流程的复杂 Agent |
| CrewAI | 多 Agent 角色协作 | 上手快，"团队分工"的心智模型直观 | 多角色协作型项目（研究员+写手+审校） |
| AutoGen（Microsoft） | Agent 间对话式循环 | 多 Agent 对话、代码执行能力强 | 需要 Agent 相互讨论、纠错的任务 |
| MetaGPT / BabyAGI | 经典自主循环 Agent | 理念先驱，适合学习循环思想 | 研究、原型、理解范式演进 |
| OpenAI Swarm / Agents SDK | 轻量级多 Agent 编排 | 极简、透明、易上手 | 小而清晰的多 Agent 编排 |
选型建议：别一上来就上重型多 Agent 框架。 大量真实任务，一个设计良好的单 Agent 循环就足够，而且更容易调试、更省钱。先从简单循环起步，只有当单循环真的扛不住时，再考虑拆成多 Agent。
事实上，你完全可以用 Python + 大模型 API 快速搭一个简单的 ReAct Loop（Reason + Act），把上面所有概念串起来。下面这段比原来的伪代码更接近真实骨架，注意看几个工程护栏（我用注释标出来了）：
def run_loop(task, max_iters=8, target_score=0.95):
"""一个带验证、反思、熔断的最小可用循环骨架。"""
memory = Memory() # 记忆：存历史尝试与反思
plan = llm.plan(task) # 规划：先拆解任务
memory.add("plan", plan)
for step in range(max_iters): # ← 护栏1：硬性迭代上限，防止无限循环
# 1. Reason：结合任务、计划、历史记忆，想下一步做什么
thought = llm.think(task, plan, memory.recall())
action = parse_action(thought)
# 2. Act：执行动作（写代码 / 调工具 / 查数据）
observation = execute_action(action) # ← 护栏2：危险动作应在此做白名单/沙箱校验
memory.add("observation", observation)
# 3. Verify：用"传感器"检查真实结果，拿到一个客观分数
result = verifier.check(observation, task)
if result.score >= target_score: # ← 退出条件：达标就走，绝不恋战
return result.output
# 4. Reflect：没达标 → 反思为什么失败，把教训写进记忆，供下一轮参考
reflection = llm.reflect(action, result.feedback)
memory.add("reflection", reflection)
# 护栏3：耗尽预算仍未收敛 → 果断上报人类，而不是假装成功或死循环
return escalate_to_human(task, memory)短短二十几行，Planner / Executor / Verifier / Reflector / Memory / Orchestrator 六大件全齐了。这段代码里最重要的不是那几行 llm.xxx() 调用，而是那三个"护栏"和那一行退出条件——它们才是"工程"二字的分量所在。
Loop Engineering 的优势
- 可靠性大幅提升：通过多次验证与纠错，把"一次蒙对"变成"逼近正确"，错误率显著降低。
- 能啃复杂任务：把超级复杂的目标拆成可执行、可验证的小步，逐个击破。
- 自主性更强：AI 能自我驱动、自我纠错，不需要人类盯着每一步。
- 可解释、可调试：每一轮的思考、动作、观察、反思都有记录，出问题时能顺着日志回溯，而不是对着一个黑箱结果干瞪眼。
- 可扩展：想加新能力？给循环挂一个新工具或新 Agent 即可，架构不用推倒重来。
挑战与未来方向：坑在哪，怎么填
当然，Loop Engineering 不是万能药。它面临几个真实的挑战——但每个都有对应的缓解思路，我一并写出来：
成本问题：多次循环 = 更多 Token = 更多钱和延迟。
- 缓解：设合理的迭代上限；用小模型跑简单步骤、大模型只在关键步骤上场（模型分级）；缓存中间结果；能一次性解决的任务就别硬套循环。
循环收敛：怎么防止无限循环、原地打转，或者越改越糟（退化）？
- 缓解：硬性
max_iters熔断；检测"连续 N 轮没进步就停"；给每轮打分并要求分数单调改善，否则回滚。
- 缓解：硬性
状态与上下文管理：长循环下，历史越堆越多，上下文窗口会爆。
- 缓解：定期对记忆做摘要压缩；只保留"结论 + 未解决项"，丢弃冗余过程；用外部存储（向量库 / 文件）做长期记忆，而非全塞进 Prompt。
安全控制：Agent 自主执行意味着它可能删错文件、跑危险命令、调用不该调的接口。
- 缓解：动作白名单 + 沙箱执行；高风险操作（删除、付款、发布）设人类审批关卡（Human-in-the-loop）；最小权限原则。
【最容易被忽视的坑】验证器本身不可靠：如果 Verifier 判断错了，整个闭环就会自信地奔向错误答案——错误的反馈比没有反馈更危险。
- 缓解：优先用客观、可执行的验证（单元测试、编译、类型检查、断言），少依赖"让另一个 LLM 打个分"这种主观验证；关键任务用多个验证器交叉确认。
关于第 5 点我想多说一句，因为它是新手最容易栽的地方：很多人以为 Loop Engineering 的难点在"怎么让 AI 循环起来"，其实真正的难点在"怎么让 AI 知道自己做对了没有"。 一个任务如果你都没法写出"怎么算成功"的可执行判据，那它大概率还不适合交给自主循环——这不是模型的问题，是任务定义的问题。
什么时候不该用循环？（一个反直觉的提醒）
聊了这么多循环的好，得泼一盆冷水：循环有成本，不是所有任务都配得上一个循环。
在这些情况下，老老实实用一次性 Prompt 反而更好：
- 任务简单、一眼能判断对错（翻译、改写、格式转换）——套循环纯属浪费钱和时间。
- 写不出客观的成功判据——没有可靠 Verifier 的循环，是在空转，甚至有害。
- 对延迟极其敏感的实时场景——循环的多轮往返扛不住。
- 一次性的探索性提问——你要的是灵感，不是收敛。
Loop Engineering 的成熟标志，恰恰是知道什么时候不用它。 拿着锤子看什么都像钉子，是入门者的通病。真正的循环设计师，会先问一句："这个任务，值得为它设计一个闭环吗？"
写在最后
AI 编程的进化路径，正在越来越清晰地显现：
Prompt Engineering → Chain Engineering → Agent Engineering → Loop Engineering
- Prompt：优化"这一句话怎么说"
- Chain：把多步串起来（还是单向的）
- Agent：给它工具，让它能行动
- Loop：给它反馈，让它能自我修正、持续逼近正确
我们正在从"告诉 AI 做什么"，进化到"设计 AI 如何持续思考和改进"。前者是把 AI 当工具，后者是把 AI 当系统来设计——这是一次心智模型的彻底跃迁。
而这里面最反常识、也最值钱的一句话，我想留到最后送给你：
当你不再纠结"这句提示词怎么写更好"，而开始琢磨"这个系统该装一个什么样的反馈回路"时，你就已经从 Prompt Engineer，变成 Loop Engineer 了。