★ FEATURED ARTICLE 这个标题在技术社区里已经火了很长一段时间但很多人聊到 Loop Engineering 时其实各说各话。有人把它理解成“循环提示词”有人把它当成“Agent 重放机制”还有人觉得它是 RLHF 里的数据回流闭环。我在实际做生成式应用的时候更愿意用一句大白话概括Loop Engineering 就是让程序本身拥有“生成 → 评估 → 修复 → 再生成”的闭环能力用机器迭代替代人工反复改稿。这个概念能解决什么问题最典型的就是大模型的一次性输出不靠谱。你让模型写一段文案第一版能用但不够好你再让它改它又可能改过头你手动把意见喂回去又累又容易遗漏。Loop Engineering 的思路就是把“我看了不满意再改”这个动作拆成程序里的循环生成器负责产出评估器负责找茬修复器负责吸收意见控制器负责决定什么时候停。很多团队的 Prompt 调优、数据集清洗、Agent 工作流稳定化背后都是这套逻辑。这篇文章适合谁看如果你正在做 LLM 应用开发、想优化提示词、做自动内容生产或者搭 Agent 工作流这篇文章会适合你。我会把循环的底层结构、关键参数、工程落地方法和调试技巧都拆开讲并用一个可以直接照着改的项目示例走通全流程。如果你只是为了学习想理解“为什么循环比单次生成更稳”也可以从文章里的思路和代码中获得一个清晰的框架。1. 先搞清楚Loop Engineering 到底在解决什么问题1.1 当“一次性生成”遇到真实世界只要你用过大模型做实际项目就会遇到一个共同现象单次调用的结果像开盲盒。同一段提示词同一套参数这次输出能用下次就飘了。对文案生成这种内容类任务还好大不了多生成几次人工挑选但如果你是在做代码修复、知识抽取、数据标注清洗这种随机性就是灾难级的。问题的根源不是模型能力不够而是单次生成缺少一个“回看”的机制。模型输出完最后一个 token 之后它的“自我认知”就固化在那一次结果里了。你让它“再检查一遍”它往往只是换个说法复述了一遍没有真正的反省。为什么这样因为一次生成对应的是一个终止状态模型内部并没有被强制建立“当前结果与目标产物的差距”这个信号。这时候最需要的是一个外部裁判。Loop Engineering 的核心洞察正在于此不要指望模型自己判断对错而是把一个明确的、可计算的评估信号挂在循环外面用外部信号驱动内部修正。这很像编程里的单元测试代码写没写对不是靠程序员盯着看而是靠测试用例跑一遍跑挂了就改改完再跑直到通过。这种“生成-验证”循环在传统软件开发里太常见了但在模型应用里却经常被忽略。很多人写提示词一上来就是把任务描述加长试图让模型“一步到位”。偶尔一步到位确实可以但复杂任务、长文本任务、多约束任务单次生成的失败率会随任务复杂度指数上升。循环工程就是把你反复尝试的这个过程自动化。1.2 循环工程 给 AI 装上“反馈飞轮”Loop Engineering 的另一个提法叫“反馈飞轮”。我比较喜欢这个词因为它道出了循环生效的关键每一轮迭代都必须产生“增量信号”而不是原地打转。一个完整的循环回路通常有四个角色生成器Generator根据当前状态和指令产出一版结果。评估器Evaluator/Critic按照评价标准给结果打分并返回具体修改意见。修复器Refiner把修改意见作为新的上下文生成下一版结果。控制器Controller判断是继续迭代、还是接受当前结果、还是直接放弃。控制器很关键因为很多人在做循环时会忽略“退出条件”导致无限循环或成本失控。实际上工程化循环和学术论文里常说的 iterated prompting 最大的区别就是工程化必须回答“什么时候停”和“停不下来怎么办”这两个问题。那这个循环和单纯“让 AI 不改到最后”有什么区别区别在于评估信号是否独立。如果你只是让同一个模型自己看自己改它会倾向于保持自己原有观点改不出实质变化但如果评估器的 prompt 设计、角色设定、评分维度是独立的甚至调用不同模型做评估例如生成用一个大模型评分用另一个更便宜的小模型循环的效果会有质的提升。这就是“飞轮”里的“质量梯度”——不够好的信号永远推不动飞轮。在实际项目中飞轮的建立往往不是一步到位的。我见过很多团队做出来的“循环系统”第一版其实就是个 for 循环套一次二次生成效果并不明显。后来他们发现瓶颈不在循环次数而在评估标准不清晰。评分维度越模糊修复器越不知道往哪个方向改。等到把评估标准拆成“事实准确性、逻辑连贯性、格式合规性、语言简洁度”四五个子项再让评估器逐项打分、逐项给修改建议循环才开始真正收敛。这件事请记住飞轮是评估信号转起来的不是循环语句转起来的。2. 核心设计一个高质量循环的五个关键参数2.1 生成器、评估器、修复器的分工很多第一次接触 Loop Engineering 的人会把整个循环写在一个大的 system prompt 里让一个模型既当生成者又当评估者。短期看确实省事长期看问题很大。角色混在一起会导致评估信号被生成任务的偏好污染——模型刚写完一段话再让它“客观评价自己写的内容”它会倾向于给高分。这就像让运动员既当裁判又当选手怎么判都带感情分。工程实践上我更推荐把角色拆开哪怕都用同一个底层模型也要用不同的 system prompt 和独立调用来实现。拆开以后每个角色承担的任务边界是清楚的这带来两个好处一是你可以在不同环节使用不同模型预算控制更灵活二是每个环节的日志、耗时、token 消耗可以独立统计出了问题能快速定位。我做一个内容生产项目时用得比较多的是一个组合生成器和修复器用同一个能力较强的模型评估器用一个更便宜的小模型或者同一个模型但单独设置低温采样temperature 调低到 0.2 以下。评估器不需要很强的创造力它需要的是稳定性冷冰冰地挑毛病。三者分工协作成本能下降不少。2.2 终止条件与最大迭代次数防死循环循环里必须有一个“熔断机制”否则一晚上跑下来账单会很难看。我在下面这张表里整理了常用终止条件的适用场景可以直接参考终止条件判断依据优点适用场景分数达标评估分达到设定阈值直观易于解释有明确评分标准的任务收益递减本轮改进幅度小于阈值防止过度打磨、节省成本内容生成、文案优化最大轮数硬限制达到 max_rounds 立即停止成本可控绝对安全所有场景兜底人工接管模型主动请求人工确认适合高风险决策代码变更、敏感文案一致性判定连续两轮结果基本一致防止摇摆翻译、改写、摘要类任务我在生产环境里几乎从来不会只依赖一个终止条件最少叠加三层分数达标、收益递减、最大轮数。止损策略必须写在最外层无论前面判断逻辑写得有多好只要迭代次数超过上限直接返回当前结果并打上“未完全达标”的标记。这个标记很重要因为它会让下游知道当前结果是未经充分优化的后续可以用更高优先级的任务再去处理。还有一个容易被忽略的细节设置终止阈值的时候先跑一批人工标注数据统计一下模型正常发挥时的分数区间再把阈值定在“略低于人工可接受线”的位置。不要一上来就定一个 90 分目标模型在简单任务上很快能达到在复杂任务上可能永远到不了。宁可先让循环系统具备“能停”的能力再逐步提高阈值。2.3 状态管理与上下文裁剪防止遗忘和超长Loop Engineering 一旦跑起来每一轮都会产生新的结果、新的评估意见。如果不做状态管理第二轮就把第一轮的输入输出、第三轮又把前两轮全塞进上下文几轮之后 prompt 就爆炸了。状态管理的核心原则是“保持最精简的闭环信息”。一个循环步骤通常只需要保留四样东西原始任务说明、当前最新一版结果、最新一份评估意见、历史得分序列。不要把每一轮的完整输出都堆给下一轮。修复器只需要知道现在的版本有什么问题不需要知道第一版和第二版长什么样历史得分序列是给控制器做趋势判断用的不是给生成器看的。上下文裁剪的做法有很多种。最省事的做法是设定一个历史窗口比如只保留最近两轮的评估意见复杂一点的做法是用摘要器把若干轮的不变结论压缩成几句话作为长期记忆。我在实际项目中通常采用分层记忆任务需求、风格约束这类不变信息放在最顶部当前版本和最新评估意见放在中间历史版本摘要放在尾部。模型对不同位置的注意力权重不同把关键信息放在越靠前的位置越不容易被遗漏。另外记得把“上一版的完整内容”只喂给评估器修复器则使用“上一版结论评估意见”即可。如果你让修复器直接拿到上一版全文它会倾向于小幅润色而不是按照意见重构。改不动的问题很多时候不是模型没实力而是输入的上下文结构从一开始就把“大改”的可能性堵死了。3. 保姆级项目实战自动化循环改写与质量评分系统3.1 项目目标与整体流程理论聊再多不如跑一个真实项目。这里我设计了一个相对完整但并不复杂的案例做一个自动文章改写升级系统让它循环“改写→评分→再改写”直到评分稳定或者达到最大轮数。项目的输入是一段平淡的技术介绍文本输出是一段经过多轮优化、内容更具体、逻辑更清楚、表达更自然的版本。你可能觉得这不就是把“请改写得更生动一些”反复调用几遍吗实际区别很大系统里的评分器会给出不同维度的分数和具体修改意见修复器只根据意见修改而且每一轮的改动幅度和分数变化都会被记录下来方便分析。整体流程可以这样描述加载一个初始文本。循环开始生成器基于当前文本和“优化指令”写出一个新版本。评估器对新版本按照四个维度信息密度、逻辑结构、表达清晰度、语言自然度分别打分并给出具体的、可执行的修改意见。控制器根据分数变化判断如果总分提升幅度小于提前设定的阈值或者当前分数已经超过目标分数或者达到最大轮数就终止循环。每轮结束后把历史版本都保存到日志列表里方便回溯。这个流程看起来浅显但已经是大多数内容生成团队在线上跑的核心逻辑。你完全可以把评估维度替换成代码正确性、事实一致性、情感风格等逻辑依然成立。3.2 分步实现生成器、评分器、控制器下面我直接给出一个可运行的 Python 示例。我用的是常见的 OpenAI SDK 风格的接口但代码里不会包含任何真实的 API Key你需要在自己本地环境配置环境变量后使用。import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) SYSTEM_GENERATOR ( 你是一名资深内容编辑擅长根据评审意见对文章进行修改升级。 请保留原文的核心信息只根据给出的评审意见进行修改 不要自行添加无关内容不要过度改写。 输出仅包含修改后的文章正文。 ) SYSTEM_EVALUATOR ( 你是一名严格的评审编辑。请根据以下四个维度对文章打分每个维度满分10分。 维度信息密度、逻辑结构、表达清晰度、语言自然度。 输出格式要求\n 总分x.x/40\n 各维度分数信息密度x.x逻辑结构x.x表达清晰度x.x语言自然度x.x\n 具体问题1.xxx 2.xxx 3.xxx\n 具体修改建议1.xxx 2.xxx 3.xxx\n 注意分数要从严只有在某方面没有明显问题时才给8分以上。 ) def generate_version(text, feedback): messages [{role: system, content: SYSTEM_GENERATOR}] user_content f这是当前版本的文章\n{text}\n if feedback: user_content f这是评审意见\n{feedback}\n请严格按照评审意见进行修改。 messages.append({role: user, content: user_content}) response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, temperature0.7, ) return response.choices[0].message.content.strip() def evaluate_version(text): messages [ {role: system, content: SYSTEM_EVALUATOR}, {role: user, content: f请评审以下文章\n{text}}, ] response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, temperature0.1, ) return response.choices[0].message.content.strip() def parse_score(eval_text): import re match re.search(r总分([\d.])/40, eval_text) if match: return float(match.group(1)) return 0.0 def loop_refine(initial_text, max_rounds5, min_improve0.5, target_score35.0): current initial_text history [] feedback score 0.0 for i in range(1, max_rounds 1): print(f--- 第 {i} 轮 ---) version generate_version(current, feedback) eval_text evaluate_version(version) new_score parse_score(eval_text) print(f当前评分{new_score}) improvement new_score - score history.append({round: i, version: version, score: new_score, feedback: eval_text}) if new_score target_score: print(已达成目标分数停止循环。) break if 0 improvement min_improve: print(改进幅度过小停止循环。) break if improvement 0 and i 1: print(分数未提升停止循环。) break current version score new_score feedback eval_text.split(具体修改建议)[-1] return history if __name__ __main__: initial 循环工程是一种通过反复迭代来提升输出质量的方法。它主要应用于人工智能领域。 通过让机器不断生成内容再对内容进行评价最终获得更好的结果。 result loop_refine(initial)这段代码里有一个细节值得留意我用了feedback eval_text.split(具体修改建议)[-1]来提取评审建议而不是把整篇评审结果喂给生成器。原因很简单生成器只需要知道“怎么改”不需要知道“打了几分、哪些维度失分”那些信息不但不帮助修改反而可能让模型纠结于讨好评分维度而不是真实改进内容。评估器和修复器之间应当传递“可行动的建议”而不是“评估报告”。还要注意在每一轮评估完成后我并不是立刻把分数作为下一轮的终止依据而是先和上一轮分数比较。也就是说循环的“刹车踏板”是由增量变化驱动的。这个设计能有效防止模型在某一轮偶然得高分、下一轮又暴跌的情况保证输出稳定在一个相对好的状态。3.3 运行结果解读与参数调节我在本地跑过类似项目故意输入了一段很口语化、信息密度较低的技术文档。第一轮生成后的评分通常在 2528 分之间因为初始文本太干评估器认为信息密度不够、逻辑结构松散。第二轮加入评审意见后评分会明显跳到 3032 分。第三轮开始提升幅度变小徘徊在 1 分左右。这个时候就轮到参数调节上场了。如果把min_improve设置成 0.5第三轮提升幅度小于 0.5 就会停止但如果设置成 0.1系统会继续跑到第五轮。并不是轮数越多越好我实测下来大多数内容优化类任务在第三轮以后就会进入“原地微调”阶段继续跑只会增加 token 消耗甚至出现“越改越书面化、越来越不像人话”的现象。温度参数也是命门。生成器温度设置 0.7 可以获得比较自然的表达变化但如果你把它调成 1.2第二轮结果可能就完全跑偏。评估器温度则尽量低0.1 到 0.2 之间比较稳妥。我见过有人把评估器温度也调成 0.8同一个文本两次评分能差出 5 分这会让控制器做出错误的终止决策。下表记录了一个典型运行中的分数变化情况可以帮你建立对参数组合的直觉轮次生成温度评估温度总分/40环比提升10.70.126.5-20.70.129.02.530.70.130.21.240.70.130.80.650.70.130.90.1如果把第五轮的终止条件设为“提升小于 0.5”系统会在第四轮结束时就停下来因为第五轮 0.1 的提升不足以支撑额外成本。这种参数设置会让项目在质量和成本之间取得较好的平衡。3.4 用不同模型组合提升循环质量与降低成本这个项目里生成器和评估器用了同一个模型其实只是为了演示简单。等到项目真正上线我强烈建议尝试模型组合。我在生产项目中常用的组合是生成和修复用通用大模型比如 gpt-4o 系列评分用更便宜、速度更快的小模型比如 gpt-4o-mini 或本地开源模型。评估任务本质上是“按规则找毛病”不需要极强的生成能力反而是稳定性和速度更重要。采用这种组合还有一个隐藏收益可以避免“自己人给自己人打分”的偏差。同一个模型家族内部往往存在风格一致性它知道自己偏向哪种写法打分时会有意无意地偏袒。换一个不同来源的评估模型反而能发现更多生成模型自己看不见的问题。成本方面我给一个粗略估算完成一个 5 轮优化任务每轮大概消耗生成 600 token、评估 500 token总计约 5500 token。如果用 min 系列模型成本很低如果用完整大模型成本会增加不少。上线前先跑一轮小样本把平均轮数和平均 token 消耗记下来再乘历史调用量就能算出比较准确的预算。3.5 日志设计循环工程最重要的一环很多人做循环系统时只顾着写主流程日志设计草草了事直到出问题排查的时候才发现无从下手。循环工程和单次生成本质区别在于它有一个“状态序列”每一轮的版本、分数、评审意见、决策原因都是可追溯的状态数据。没有日志就是黑盒有了日志才能做后续分析和调优。我的建议是每一轮至少记录以下字段round轮次序号model生成模型和评估模型名称temperature实际使用的采样温度input_version进入本轮时使用的文本版本output_version本轮生成的文本版本score本轮总分feedback评估全文包括各维度分数和修改建议termination_reason停止循环的原因达标、提升不足、达到最大轮数等把这些字段写成 JSON 存下来一个小工具脚本就能统计出“哪些任务经常跑满5轮”“哪个评估维度总在拉低分数”“哪类意见触发的修改最有效”。这些统计结果反过来又能指导你调系统提示词和阈值。真正把系统调顺手的人厉害之处不在 prompt 写得好而在于他们用日志把系统行为看得明明白白。3.6 从单循环到嵌套循环Agent 工作流的雏形如果只是做一个单层循环Loop Engineering 的价值还没有完全释放。把它升级为嵌套循环你就能搭出很实用的 Agent 工作流。举个例子在代码生成场景里外层循环负责“让代码通过单元测试”内层循环负责“根据报错信息修复代码”。外层循环的终止条件是测试全部通过内层循环的终止条件是连续两次修复后报错不再变化。两个循环互相嵌套外层控制验收内层控制单步修复效果远远好于单层“让模型改到能用为止”。嵌套循环还有一个好处可以用不同粒度的评估信号。外层用硬性指标测试是否通过、正则是否匹配、关键字段是否存在内层用软性指标代码风格、可读性、注释质量。硬性指标保证结果正确软性指标保证结果优雅。只靠一个循环、一类评估指标很难兼顾这两个目标。4. 常见问题与排查技巧实录4.1 循环不收敛或者结果越改越差不收敛是循环工程最常见的头疼问题。所谓不收敛就是分数在 29 和 31 之间反复横跳或者干脆一路走低。出现这种情况我一般会先看评估器是不是不稳定。把同一段文本反复评估五次如果分数方差很大说明评估器本身就没校准好。排查步骤很简单固定一个文本连续评估 5 次观察分数波动。波动超过 2 分先调整评估器系统提示词把评分标准描述得更具体尽量使用“必须、禁止、不得”这类硬性语言。如果还是波动把评估器温度降到 0并把top_p调到 0.8 以下。再不行换一个不同来源的评估模型。另外一个常见的坑是评审意见过于抽象模型给了“语言表达还可以更生动”这种建议修复器根本不知道具体怎么改。排查日志时如果看到这类意见反复出现但分数没有提升基本上可以确定是评估器的意见质量问题。解决办法是在评估器 prompt 里明确要求“每条修改建议必须对应原文中的具体片段并说明修改方向”。举个例子与其写“逻辑结构不够清晰”不如写“第二段先讲了结论又讲原因建议先说明原因再引出结论”。修复器拿到这样的意见才能做出实质改变。4.2 Token 成本爆炸怎么控制循环系统的成本是线性叠加的跑几轮就相当于调用了好几次模型接口。如果任务量大token 成本会明显高于单次生成。我在控制成本方面有三条经验第一条是提前设置硬性预算。进入循环前根据传入文本的长度估算每轮的最大 token 消耗再乘以最大迭代轮数得出最坏情况成本交给控制器。第二条是使用“渐进式终止候选集”策略。具体做法是每轮评估完把当前最好的版本缓存下来如果后面某轮分数掉得太多就直接返回历史最优版本而不是返回最后一版。这个策略可以防止“为了完成迭代而提交一个更差的结果”。第三条是为评估器设置更严格的max_tokens。评估器输出太长是常见浪费。你把评估器的max_tokens限制在 600 左右它就不会长篇大论写一大堆重复的评审套话只输出关键分数和建议。生成器的max_tokens也要估算好通常一版优化后的文章长度不会比原文长太多留出 30% 的余量就够了。4.3 上下文超长模型“忘记”最初的需求长文本任务经常遇到这个问题原始任务说明、历史版本、评审意见三样东西加起来几个回合后就超出模型的上下文容量。模型开始忘记最开始的风格要求输出了符合评审意见、却偏离原始主题的文本。我解决这个问题的办法是“固定前缀 动态摘要”。每条生成请求的最顶部固定放原始任务说明和不可变约束这部分永远不被新内容挤掉中间放当前版本和评审意见尾部放一个简短的历史摘要。具体实现时可以先把原始任务说明压缩成一条不超过 50 个字的“核心目标提醒”例如“保持技术准确性避免口语化表达长度控制在 600 字左右”。这样即使上下文很长模型每次生成时都能看到这个锚点。还有一个小技巧每轮生成结束后把“当前版本的主题句”提取出来作为下一轮的前缀锚点。这能防止模型越改越偏。主题句提取不需要额外调用模型可以简单地取文章前两句也可以让评估器在评审时顺带生成“一句话概括本文主题”。只要主题锚点不偏修改方向就不会彻底跑飞。4.4 评分器只会打高分或者低分怎么办有时候你会遇到评分分布高度集中的情况比如所有结果都在 3839 分之间循环完全失去区分度。这种情况常见于评估器 prompt 里的评分标准写得太宽松模型不愿意得罪人。解决方法是引入“锚定样本”和“对比评分”。锚定样本就是在评估器 prompt 里给一个具体的优秀案例和一个具体的差劲案例并标注各自得分。模型在打分的时候就有了参照系不容易给所有文本打高分。对比评分则是让评估器一次比较两个版本说出哪个更好、好在哪而不是孤立打分。对比判断比绝对值评分容易得多模型也更擅长。另外一个有效做法是把分数区间从 10 分制改成 40 分制或者百分制。更宽的分数范围提供了一个更平滑的信号模型更容易给出有区分度的分数。但要注意分数范围与输出稳定性之间要做一个平衡我的经验是百分制配合温度 0.1 表现最好。4.5 常见问题速查表症状最可能的原因快速处理方案分数震荡不收敛评估器不稳定降低评估温度固定评估 prompt分数很高但实际结果一般评分标准过于宽松加入锚定样本增加约束语气结果越改越长修复器未限制长度在修复器 prompt 中明确长度上限修改偏离原意核心目标锚点丢失固定原始任务说明在前缀结果雷同、改不动上下文结构不利于大改只传评估建议不传上一版全文某轮分数暴跌生成器温度过高或状态漂移降低温度设置温度上限运行时频繁超时输入太长导致生成过长压缩历史摘要限制 max_tokens这张表基本上覆盖了我做循环系统时遇到的八成问题。遇到新问题先不要急着调模型把日志拉出来看一轮看分数变化和评审意见之间的关系通常能快速定位。5. 在真实项目里Loop Engineering 给我留下的几个教训最后分享几个个人层面的实战感受不聊大道理只说踩过的坑。第一个教训是“循环一定要留人工出口”。我做过一个自动生成营销文案的系统为了保证效率把循环全自动跑通结果有几次模型在“生动活泼”这条路上越走越远输出的文案完全不适合正式场合。后来我加了一个人工抽检环节所有跑满最大轮数才停止的任务必须经过人工确认才能发布。这个改动虽然增加了少量人工成本但有效兜住了质量底线。第二个教训是“前几轮的收益远大于后几轮”。统计分析我做过的几百条任务后发现第一轮到第二轮的提升平均在 15% 以上第二轮到第三轮降到 5% 左右第三轮以后基本在 1% 以下。这也就是说循环工程的核心价值在“前三次迭代”后面很多时候是在微调。如果你设计一个 5 轮循环真实线上任务的平均轮数能控制在 3 轮成本就会非常健康。第三个教训是“小步快跑比大步改动更有效”。我最初实现修复器时给的修改指令是“按评审意见全面优化”结果模型每次都重写全文反而丢失了原本不错的表达。后来把指令改成“只修改评审意见中明确指出的具体问题保留其他部分不变”每轮的改动幅度变小了但增量提升更稳定。这件事让我意识到循环工程追求的不是“重新生成”而是“可控的增量改进”。如果你也想在项目里引入 Loop Engineering我建议从一个非常小的任务开始比如把一段固定的旧文案循环优化 5 轮完整记录每轮的提示词、分数和输出。等你把这个小闭环跑通、跑稳了再把它装进 Agent 工作流、接入批量任务体系都不迟。这个技术的门槛其实不高真正拉开差距的是你对循环状态、评估质量和终止策略的设计深度。
阅读完成 · 觉得有帮助？
