年初我在调一个多步骤AI Agent的时候反复撞到同一堵墙单独的每一步提示词都写得很“对”但串起来之后输出质量就是忽上忽下同样的输入隔一天结果能差出一大截。调试到烦躁的时候我忽然意识到问题的关键不在于哪一句Prompt写得不好而在于整个流程里缺少一个最基础的东西——反馈回路。后来我去翻了翻社区里的讨论发现这个话题早就有了自己的名字Loop Engineering循环工程。简单说它就是把“输出—评估—修正—再输出”这条循环回路当成系统的一等公民来设计和工程化而不是靠运气去期待模型每次都对。这篇文章就是围绕Loop Engineering写的保姆级教程加一份完整的项目实战记录。我会先把这个概念拆明白讲清楚它和Prompt Engineering到底有什么区别然后给你一套可以直接照抄的循环设计参数表再手把手搭一个文档审校自动循环最后用一个代码审查项目演示怎么把它真正落地到工作流里。无论你是刚接触AI应用开发还是已经在用Agent做自动化这篇都能帮你少走不少弯路。1. 从一句提示词到一条反馈回路Loop Engineering到底在解决什么1.1 一次性提示词的天花板过去两年大多数人调AI的方式是这样的写一段很详细的提示词把背景、要求、格式都交代清楚然后调用一次大模型拿到结果。不满意那就改提示词再调用一次。本质上这是一个线性的试错过程每一次调用之间没有记忆、没有状态、没有结构化反馈。它解决的问题是“给定足够清晰的指令模型能不能给出合格答案”。但真实世界的任务绝大多数不是单次问答而是多步骤、多约束、需要反复校验的工程任务。比如写一份技术方案你需要先出框架再填细节再检查逻辑漏洞再核对术语一致性。再比如修一段代码你先得定位问题再修改再跑测试验证再排查新引入的错误。这类任务有一个共同特点完成质量不取决于单次输出的上限而取决于迭代修正的下限。换句话说Prompt Engineering考的是“如何让模型第一次就答好”而Loop Engineering考的是“如何设计一套机制让模型即使第一次答得不够好也能快速收敛到足够好的答案”。这两种思路没有优劣之分但如果你正在构建AI Agent、自动化流水线或者任何涉及多步骤决策的系统只盯着单次提示词你会很快撞到天花板。1.2 循环的最小单元生成、评估、修正、控制一个最基本的Loop Engineering系统拆到不能再拆就是四个角色在循环里各司其职。角色职责类比生成器Generator产生当前版本的输出可能是文档、代码、方案炒菜的厨师评估器Evaluator按既定标准检查输出质量找出问题和不达标项尝菜的老饕修正器Refiner根据评估结果修改输出生成新版本听到反馈后调整火候的厨师控制器Controller维护循环状态决定是否继续迭代记录历史决定“这道菜能不能上桌”的店主用一句话概括生成器负责“写”评估器负责“骂”修正器负责“改”控制器负责“什么时候停”。这四个角色在代码层面不一定是四个独立的模型调用有时候生成器和修正器可以用同一个模型加不同后缀的提示词来实现评估器和控制器也可以合并成一个带逻辑判断的函数。但无论怎么合并这四个职能必须都存在缺一个循环就会崩塌。最小循环的流程长这样# 一个极简的Loop Engineering骨架 def run_loop(generate, evaluate, refine, should_stop, max_rounds3): result generate() history [] for round_index in range(max_rounds): evaluation evaluate(result) history.append(evaluation) if should_stop(evaluation): break result refine(result, evaluation) return result, history代码里最关键的参数是max_rounds和should_stop。前者是刹车后者是方向盘。很多新手搭循环只知道“能转起来”却不知道这两个参数才是决定系统会不会原地空转、会不会成本爆炸的核心。后面我会专门展开讲。1.3 为什么这个概念最近频繁被提起Loop Engineering之所以在最近几个月突然热起来背景是AI应用的形态变了。早期的大模型应用是“问答型”用户问一个问题模型回一段话对话结束。而现在的AI应用是“任务完成型”用户丢进来一个目标系统要自己规划、执行、验证、纠错直到任务真正落地。Agent就是这样它本质上不是一个聪明的提示词写手而是一台装了方向盘的循环机器。如果你用过Claude Code或者Cursor的Agent模式你会发现它们做事的风格不是一次性甩给你一大段结果而是会先列出计划然后一步一步执行并且在执行过程中不断检查前面的产出发现问题就回头修。这背后的机制就是Loop Engineering。虽然这些产品的内部实现不叫这个名字但它们把“迭代—反馈—修正”显式化成了流程的一部分而不是靠每一次随机发挥。所以我的判断是未来一两年的AI应用开发写提示词的能力会被逐渐工具化真正拉开差距的是谁能在自己的系统里设计出更高效的循环结构。这也是我写这篇文章的初衷——把那些散落在工程实践里的循环设计套路整理成一套能直接上手的方法论。2. 动手搭循环之前先把这五个参数想清楚2.1 循环类型是“反思自己”还是“验证结果”还是“分工协作”不是所有循环长得一样。第一个要决策的是你的场景适合哪种循环结构。最常见的三种类型分别是反思循环、验证循环和分解循环。反思循环Reflection Loop是让模型自己批评自己的输出典型做法是“请你重新审视上面这段内容找出逻辑漏洞然后修改”。实现成本最低一个模型就能跑但天花板也最低因为评估器和生成器共享同一套知识盲区模型很难发现它自己都不知道的错误。适合用来优化表达、格式、连贯性这类表层问题。验证循环Verification Loop是用外部工具或规则来当评估器而不是让模型自己当裁判。典型做法是“跑一遍测试用例”“执行一次代码检查工具”“用正则校验格式”。这是最可靠的结构因为评估标准是客观的不存在模型自嗨的问题。代价是需要额外开发成本你得先有那个能验证的“尺子”。分解循环Decomposition Loop针对超长、超复杂的任务把一个巨型任务拆成若干小任务每个小任务独立执行和验证再汇总结果。这其实是一种嵌套循环外层拆任务、内层做验证或反思。适合方案设计、大型文档创作、复杂系统迁移这类一次搞不定的活。选型的核心原则很简单能用外部工具验证的绝对不要依赖模型自我批评。我自己见过太多人试图让模型检查代码逻辑漏洞结果模型自信满满地指出一个根本不是问题的问题还煞有介事地改出一段更烂的代码。究其原因就是评估器不靠谱。2.2 最大迭代深度先给循环装一个刹车第二个要决策的是最大迭代次数。这个参数看似简单却是整个系统最重要的成本控制器。每次循环都会产生至少两次模型调用一次生成、一次评估如果循环跑了N轮成本就是单次调用的2N倍甚至更高因为修正器往往还需要重新生成上下文。所以最大迭代深度直接决定了你的系统烧钱速度。我的经验值是面向文本质量的任务文档、文案、结构化内容默认设3轮面向代码验证的任务有测试当评估器默认设5轮面向纯探索性的任务头脑风暴、竞品分析直接不设循环。为什么文档类控制在3轮因为根据我实测文本类任务大多数能在2轮内收敛跑到第4轮基本就开始“为改而改”——模型为了响应批评意见会把本来没问题的段落也重构一遍。设置最大深度之外还应该在每一轮里做一个成本预估打印。养成习惯后你很快会对“一轮循环究竟消耗多少token”建立直觉。例如一次文档审校循环输入一个3000字的初稿每轮评估约消耗2000 token修正约消耗3500 token三轮下来总消耗接近2万token。没有这个直觉之前很容易写出一个跑一次就要5万token的“豪华循环”。2.3 评估标准把“质量不错”翻译成可执行检查清单评估器是整个循环里决定生死的一环但也是最常被糊弄的一环。很多人的评估提示词长这样“请检查这段文字的质量指出错误并打分。”这个指令等于没写。因为“质量”“错误”这些词太抽象模型只能凭感觉输出一个看起来合理的评分而你根本不知道它依据什么。评估标准必须拆成可逐项判断的检查项每一项都要能用“是/否”或者“通过/不通过”来回答。我常用的一种做法是给评估器一张结构化的检查卡检查维度 1. 事实准确性文中是否存在明显的逻辑矛盾、事实错误逐条列出 2. 完整性是否遗漏了任务要求中的任何必填模块 3. 格式合规标题层级、列表、代码块是否符合规范 4. 冗余度是否存在可删除的重复表述章节 5. 一致性术语使用前后是否一致 输出格式要求 { verdict: pass 或 fail, failed_items: [检查项1, 检查项3], issues: [具体问题描述1, 具体问题描述3] }当你把评估维度具象化成一张表评估器的输出就变成可编程的数据了控制器才能判断“到底要不要继续迭代”。同时我发现给评估器提供“在哪里判断”的锚点比让它自由寻找更高效比如“重点检查第2节的技术参数与第4节的复用方案是否冲突”能显著降低误报率。2.4 状态容器循环之间共享什么、遗忘什么第三个常见错误是每一轮循环都“失忆”。生成器产出了新一版内容但下一轮的评估器不记得上一轮的问题清单修正器也不记得自己上一轮做过哪些修改。结果就是同一个问题修了又犯犯了又修无限打转。设计循环时你必须在状态容器里至少存四样东西当前最新版本结果、累计发现的问题列表、已经尝试过的修复方向、每一轮的评估明细。这四样信息能让修正器知道“哪些坑已经踩过了”从而避免重复劳动。不过状态也不是存得越多越好。上下文长度有限如果每轮都把之前所有版本的全文带进去第3轮开始上下文就会爆炸。我建议只保留当前版本、上一轮问题清单、以及历代问题摘要可以用模型把已解决的历史问题压缩成一行摘要。这相当于给循环加了一个“遗忘机制”只记住关键的增量信息。2.5 终止和升级路径循环到底是全自动还是半自动最后一个要决策的是循环的终点。是让控制器在评估全通过时自动结束还是在达到最大迭代次数后交给人工兜底我的建议是任何面向生产场景的循环都必须设计“升级路径”当循环无法收敛也就是评估始终不通过但迭代次数已用完时系统应该把当前版本、问题清单、循环历史打包交给人类而不是默默输出一个次品。这种设计带来的最大好处是安全可控。“全自动循环”是理想态但现实里总有评估器漏判的角落保留一个最终人工判断节点既是对系统负责也让使用的人对AI产出建立信任门槛。3. 保姆级实操从零构建一个文档审校自动循环3.1 场景设定与循环设计拿一个真实的场景来练手自动审校一份技术方案文档。假设你刚用AI起草了一篇3000字的架构设计文档里面覆盖了系统模块划分、数据流、部署方案、风险控制四个部分。你的目标是让循环自动把这份初稿打磨到可以直接提交评审的程度。先用前面五个参数设计一下这个系统循环类型反思循环为主因为文档质量没有外部工具能客观验证最大迭代深度3轮评估标准五维检查卡准确性、完整性、格式、冗余、一致性状态容器保留当前版本 本轮问题清单 已修复摘要终止条件五项检查全部通过或者第3轮结束3.2 构造评估清单和修正提示词评估器的提示词模板我建议写成这种结构化格式你是一名资深文档评审。以下是一份技术方案文档请按下列检查项严格评审。 文档内容 {{DOCUMENT}} 检查项 1. factual_accuracy文档内部是否存在逻辑矛盾或不严谨表述 2. completeness是否缺少必要章节或内容覆盖 3. format_compliance标题层级、段落结构是否清晰 4. conciseness是否存在冗余重复内容 5. consistency术语文档中使用是否统一 输出要求 - 对每个检查项给出 pass 或 fail - fail 的检查项必须列出具体的原文摘录和修改意见 - 结果以 JSON 格式返回注意“必须列出具体的原文摘录和修改意见”这句话。它非常重要逼着评估器给出可执行的反馈而不是空泛地说“需要提高表达质量”。修正器的提示词则要携带状态容器里的历史信息你是文档修订专家。请根据评审意见修改文档遵守以下规则 1. 只修改评审意见中指出的问题不要动其他内容 2. 如果某个修改会导致前后冲突必须同步修改相关位置 3. 上一轮已经尝试过的修复方向见下不要再重复尝试 4. 修改完成后用一句话列出你改了哪些位置 评审意见 {{EVALUATION_RESULT}} 已尝试修复方向 {{HISTORY_SUMMARY}} 待修改文档 {{DOCUMENT}}3.3 循环主逻辑代码实现下面是一个可以直接跑的Python骨架。为了让代码不依赖具体模型服务商我用call_llm()函数占位你接OpenAI、Anthropic还是本地模型都行。import copy from typing import Dict, List, Callable # 假设你封装了统一的LLM调用接口 call_llm Callable[[List[Dict]], str] class DocumentReviewLoop: def __init__(self, generate, evaluate, refine): self.generate generate self.evaluate evaluate self.refine refine self.state { current: None, # 当前版本 all_issues: [], # 累计问题 fix_attemps: [], # 已尝试修复方向压缩摘要 } def run(self, seed_document: str, max_rounds: int 3): self.state[current] seed_document for i in range(1, max_rounds 1): print(f--- 第{i}轮评审 ---) # 1. 评估当前版本 eval_result self.evaluate( self.state[current], self.state[all_issues], ) self.state[all_issues].append( {round: i, issues: eval_result[issues]} ) # 2. 终止条件没有失败项提前停 if not eval_result[failed_items]: print(评估全部通过提前退出) break if i max_rounds: print(达到最大迭代轮数交给人工) break # 3. 修正当前版本 new_doc self.refine( self.state[current], eval_result, self.state[fix_attemps], ) # 4. 记录修复摘要用于下一轮的“别重复尝试” fix_summary summarize_changes(new_doc, self.state[current]) self.state[fix_attemps].append(fix_summary) self.state[current] new_doc return self.state[current], self.state[all_issues]代码里有一个容易被忽略的细节在终止判定时我用的是“没有失败项”而不是“评分达到多少分”。理由很简单评分是连续值边界模糊而“是否有失败项”是离散值边界清晰。控制器拿到离散值才能做布尔判断这是工程上的刚需。3.4 实测效果与调优记录我拿一份真实的架构文档跑了一遍初稿约3200字。第一轮评估五项检查里fail了三项完整性缺了部署方案的故障回退机制、一致性上有两三处用了不同术语、冗余度有一段两段重了。修正器改完后第二轮评估变成了只fail一项第三轮全部通过循环在第3轮自然收敛。整个流程耗时约40秒消耗约1.8万token。过程中发现了一个很典型的调优点第一轮修正后修正器为了补全“部署故障回退机制”新增了一段和原有高可用章节重叠度极高的内容反而触发了冗余度检查。这让我意识到修正器的指令里必须加一条“如果新旧内容重叠优先把重叠部分合并”否则循环会在“补全”和“去重”之间来回拉锯。加完这条之后第二轮就开始收敛了。4. 项目实战把Loop Engineering嵌进代码审查全流程4.1 项目背景PR质检为什么需要循环而不是单次审查文档审校只是热身真正让Loop Engineering发挥价值的是代码审查。在一家做数据服务的小团队里我曾经搭过一个AI PR审查助手。在动手之前我观察了团队小一个月每个人的PR都要过一遍人工Review成本高效率低另一边代码里的低级问题没加空指针保护、日志关键字段缺失、API版本没更新其实高度同质化用规则就能查出来但规则引擎可扩展性差。问题是如果只用AI单次审查效果很一般。我测试过直接把diff丢给模型让它提意见它会提一些“提高代码可读性”“简化逻辑结构”这种不痛不痒的废话真正关键的“此处漏了判空”反而漏掉。原因很清晰一次性的模型调用缺乏自我校验它不会发现自己的审查漏项。用Loop Engineering的思路重新设计后系统变成了分析diff → 生成审查意见 → 用规则和测试验证这些意见的真实性 → 让模型基于验证结果补充第二轮更深入的分析。每一轮的评估器都是客观外部工具代码规则文件、编译结果、单元测试而不是模型的自我感觉。这正是前面提到的验证循环。4.2 架构设计分析、建议、验证、再分析的闭环整个系统的流程是这样的抓取差异通过Git API读取PR的diff第一轮分析模型读取diff和仓库规则文档输出初步审查意见规则验证每条审查意见会映射到仓库规则文件里的具体条目不能映射的直接丢弃测试验证对于涉及修复建议的意见生成对应的代码改动草案跑一次单元测试和静态检查工具第二轮分析把测试结果、静态检查输出、规则匹配结果一起打包给模型让它输出最终审查报告收敛判定如果二轮分析没有新增超过阈值的新问题结束否则再补一轮这套架构和文档审校的最大区别是评估器不再是一句“请检查质量”而是真的跑了一次工具链用机器可验证的结果来筛选AI的幻觉意见。4.3 关键实现diff处理、审查循环、测试门禁def run_pr_review_loop(diff_text, repo_rules, working_dir): # 第一轮生成初步意见 prelim_issues agent_analyze(diff_text, repo_rules) # 用规则文件过滤保留能落到具体规则的结论 filtered [i for i in prelim_issues if rule_match(i, repo_rules)] # 对每个意见尝试生成补丁草稿并跑测试 verified [] for issue in filtered: patch_file generate_patch(issue, diff_text, working_dir) test_result run_tests(patch_file, working_dir) linter_output run_linter(patch_file, working_dir) if test_result.passed and not has_critical_lint(linter_output): verified.append({**issue, test_pass: True}) else: # 涉及测试失败的意见单独标记交给二轮分析判断 verified.append({**issue, test_pass: False, reason: test_result.summary}) # 第二轮把工具链输出打包给模型输出最终报告 final_report agent_final_report(diff_text, verified, linter_summary, test_summary) return final_report这段代码的精髓是test_pass这个字段。有了它审查报告自动分成两级已通过工具验证的确凿问题和模型推断但工具未证实的问题。人看报告的时候优先级一目了然。测试门禁拦截掉的不只是模型幻觉也拦截住了那些“看似合理、实则危险”的批量修改建议。4.4 实测效果与上线数据系统上线跑了约三周我把数据整理了一下指标上线前纯人工Review上线后Loop系统 人工单个PR平均审查时间约45分钟约8分钟含人工复核漏掉的中低级问题基线降低约55%模型幻觉性建议无对比过滤掉约80%上线期间新增的缺陷逃逸率约9%约4%其中幻觉性建议的过滤率是最让我满意的。没有规则匹配和第二轮测试验证这两道关卡时模型十条建议里大概有两三条是错的用Loop结构把工具结果喂回模型之后错误建议被自己的修正流程推翻了最终到达人眼的报告已经全部经过验证。这验证了一个观点评价循环的优劣不要看它“提出了多少问题”要看它“提出的问题里有多少经得起验证”。经不起验证的问题提得再多反而会让工程师对系统失去信任。5. 我在实际项目中踩过的坑和最终的收敛法则5.1 自我强化的死循环输出越来越长、越来越离谱第一次跑文档审校循环的时候我碰到的现象是每一轮修正文档都会变长从3200字一路长到5700字。原因是修正器看到评估意见后本能地用“补充内容”来响应批评——你说我不完整那我把能想到的都写进去你说我术语不一致我把每个术语都解释一遍。结果第2轮之后文档出现了大量重复。而评估器的检查项里没有“字数失控”这一项于是它并没有发现新引入的问题循环就在这种虚假的“改善”里继续空转。这个坑的根因是评估器只检查它被要求检查的东西不会主动发现新问题。我后来在系统里加了一条硬约束“如果本次修改后文档长度超过上一轮的1.2倍视为修改失败回滚到上一版。”这就是用外部规则给循环套了一个方向盘。从此之后文本类的循环再没出现过长度失控。5.2 成本失控一次循环烧掉几十万token另一个项目里我犯过一个更大的错误把一个PPT大纲生成任务做成了循环结构每轮循环都要求“重新生成完整大纲”而不是“基于差异修改”。加上评估器要求读一遍完整大纲3轮循环下来输入输出token消耗超过了10万。而事实上同一个任务设计成增量修改之后3轮消耗只有1.2万token左右成本相差8倍。教训有两条。第一条是修正器必须尽量基于差异做增量修改而不是每次都整体重写第二条是评估器不要重复读取完整上下文可以让控制器把复杂评估拆成多个小评估器分别检查不同部分。模型API按token计费节约token就是节约成本。我后来所有循环系统的评估器都设计成“只针对问题段做上下文切片”效果极其明显。5.3 评估器偏差AI给AI打分的不确定还有一次我在评估器里写了“请根据经验判断该方案是否可行”结果同一个方案在不同轮次里分别拿到了8分和3分。问题不在于模型不稳定而在于“可行性”这个概念本身就是主观的。没有把“可行”细化成“有先例、有数据支撑、有预算、排期在两个月内”这些子问题之前任何打分都是噪声。后来我把这类主观评估全部强制转向“存在性判断”一个方案是否提及了客户确认、是否包含回滚预案、是否列出技术预研步骤。存在性比优劣性更容易判定循环的收敛速度也快得多。把主观问题客观化是我在设计Loop时最常用的一条方法论。5.4 我沉淀下来的四条收敛法则实战踩过这些坑之后我把Loop Engineering里“让循环能收敛”的经验压缩成四条规则外部先于自我能用工具、测试、规则引擎当评估器的永远不要让模型自我评估兜底工具不会幻觉增量优先于重写修正器只改被指出的问题不能借解题之机重写全文否则每次循环都在引入新变量离散优于连续评估器输出尽量用“通过/不通过”的检查项而不是凭空打分连续值会让控制器的条件判断失灵刹车必须存在任何循环都要有最大迭代深度和人工升级路径两者是系统安全的最后兜底这四条法则对文本任务、代码任务、Agent任务都适用。你现在再回去看那些做得好的AI Agent产品会发现它们的内部循环无一例外都遵守了这几条。最后再分享一点实际体会Loop Engineering不是银弹它不会让一个平庸的提示词变成爆款生成器它真正解决的是系统稳定性问题。它把人类做事时那种“做完检查、发现问题、回头修改”的自然过程显式地变成机器可以执行的空间。我强烈建议你从一个小任务开始练手比如给文档加个自动审校循环跑通第一个闭环之后再往复杂场景扩展。循环的设计思路一旦上手你再回头调那些Agent应用时思路会完全不一样。