★ FEATURED ARTICLE 最近朋友圈里被Loop Engineering刷屏的频率有点高。我一开始看到这个词脑子里的画面是某个机械厂又出了新循环泵直到跟着几个开源项目跑了一遍才确认这说的是AI Agent圈子里的一套工程方法让大模型在一个闭环里反复干活生成、评估、修正、再生成直到输出达到验收标准。它要解决的问题很直接LLM单次生成的结果往往只有六十分但经过几轮刻意设计的迭代能稳定提到八十分甚至九十分。这篇文章就围绕这个思路展开帮你把Loop Engineering从概念落到一个能跑的项目里。适合谁适合被不稳定的模型输出折磨过、想做自动化内容生产、正在研究Agent落地的开发者不管你是调OpenAI API、本地模型还是正在选型框架这套思路都能直接用。1. 先搞清楚Loop Engineering到底是什么1.1 从一个坏例子说起你肯定遇到过这种情况让LLM直接写一份行业分析报告它写出来的东西框架齐全但细看全是正确的废话。数据是编的观点是通用的结论是应持续关注市场动态。你再让它改一遍它又把整篇文章重写了一遍上次写对的地方也一起改了结果还是一样烂。这不是模型能力不够而是调用方式太粗糙。就像你让一个新员工直接写终稿他当然只能写出一版他觉得差不多的东西但如果流程变成先写初稿再由另一个资深编辑挑毛病打印批注拿回去改一稿、二稿、三稿每轮都只对着具体问题改质量就会完全不同。Loop Engineering就是把后者的流程固化到代码里。1.2 循环骨架Generate - Evaluate - Feedback - Refine任何Loop项目不管表面多复杂底层都是一个四步循环Generate按当前状态生成一版输出Evaluate用某种评估方式给这版输出打分或找问题Feedback把评估结果整理成结构化的修改意见Refine带着修改意见重新生成进入下一轮终止条件通常是两个一是评估分数达到预设阈值二是到达最大迭代次数。这个骨架之所以有效是因为它把不可控的模型随机性变成了可控的工程流程。单次生成是随机的但每一轮迭代都是朝着明确标准收敛的。这本质上和软件工程里的CI/CD反馈闭环一样先跑测试测不过就报错改完再跑直到绿灯。1.3 Loop和ReAct、Plan-and-Execute到底有什么不同刚接触这个概念的读者容易把几个术语搞混我简单区分一下ReAct是思考-行动-观察循环重点是让模型决定是否调用工具、根据观察结果调整下一步动作。它解决的是多步推理和工具使用问题。Plan-and-Execute是先规划再执行把大任务拆成多个子任务逐个干完。它解决的是复杂任务分解问题。Loop Engineering的核心是评估-修正循环它不一定需要外部工具关键是有一个评审环节把输出质量往上顶。实际项目里三者经常混着用外层用Plan调度中间用ReAct决定调什么工具最后每个产出物再套一个Loop做质量收敛。这篇文章先聚焦Loop本身因为它是这三者里最好复现、也最容易被忽视的一环。2. 设计一个Loop动手前必须想清楚五件事2.1 验收标准必须可机器判断Loop能不能收敛一多半取决于初始定义。如果你告诉模型写一份好报告这个好没法被程序判断循环就失去了目标。我见过太多失败案例评估器给不出明确分数循环只是在一遍遍重写Token烧了不少最后结果和第一版区别不大。所以第一步是把好拆成可检查的条目。比如一份报告可以拆成必须包含四个章节、每个章节必须有三个以上事实性观点、SWOT里的优势和前面竞品对比的数据要能对上、总字数在800到1200之间。这些条件有的能靠规则代码判断比如字数、章节标题有的需要模型评分比如逻辑一致性。不管用哪种方式目标都是让程序能够明确回答这版过没过。2.2 评估器从哪来规则、模型、外部验证评估器是Loop的裁判选对了事半功倍。我常用的几种方式评估方式适用场景优点缺点纯规则检查格式、字段、字数、关键内容存在性稳定可靠几乎没有成本无法评估语义质量LLM-as-a-judge语义质量、逻辑、一致性灵活能理解上下文有偏见偶尔瞎打分外部工具验证代码运行、数据查询、API返回客观性强最可信实现成本高人工在环高风险决策、创意类任务最准确慢不适合大规模我的原则是能用规则判断的项绝不让模型判断LLM判断只负责语义层面的评分。规则负责卡住底线模型负责给出天花板两者结合才靠谱。2.3 修正指令必须结构化不能把评估结果糊成一团很多新手第二步就翻车把评估结果拼成一段话丢给模型比如报告有些地方不够具体请修改。这种反馈等于没反馈模型不知道改哪只能全篇重写于是陷入越改越差的循环。正确做法是把评估结果结构化。一个典型的反馈块长这样评审结果总分 72/100 1. [结构完整性] 缺少市场概况章节标题疑似直接跳到了竞品对比。 2. [数据具体性] 第二段提到市场份额逐年增长但没有给出具体百分比或区间。 3. [逻辑一致性] SWOT中的优势提到技术领先但竞品对比表里没有对应技术项。 4. [可执行性] 结论建议只有一句话缺少下一步行动与时间节点。模型拿到这个反馈才知道自己具体错在哪。我建议在Evaluation的Prompt里就规定输出必须是编号列表每条都要对应到原文中的具体位置而不是笼统的内容可以更丰富。2.4 终止条件和预算别让循环变成吞金兽Loop最大的风险是停不下来。模型可能在一个问题上纠结十几轮每一轮都在重复相似的修改分数却始终在同一个区间震荡。所以循环必须同时具备三个护栏分数阈值、最大迭代次数、单轮上下文上限。比如设定分数85分或者迭代超过4轮就停止。并且要记住一个原则如果达到最大迭代还是没达标不要把最后一版作为结果应该保留历史所有版本里分数最高的一版。我后面会专门讲怎么实现这个最优版本保留逻辑。2.5 状态和记忆别让每轮都从零开始如果每一轮都把原报告修改意见传给模型让它重写这是一种常见但低效的做法模型为了满足新意见往往会破坏已经写对的部分。更好的做法是让模型在原文基础上做局部修订或者使用diff式修改。最简单的实现方式是在Refine Prompt里明确写保留原文中未提及问题的部分只修改评审指出的内容。即使这样模型有时仍会大动干戈。所以更稳妥的方案是改动前先让模型回答你计划修改哪些句子、新增哪些内容再让它输出最终版本。这相当于多了一次规划成本但能显著减少误删。3. 保姆级实战从零搭一个报告生成Loop3.1 项目场景与目标定义为了让你能照着抄我选一个典型场景自动生成一份《智能手环竞品分析报告》。这个任务足够简单不需要调用外部数据库但又包含了结构化、语义质量、逻辑一致性等多个评估维度非常适合演示Loop的完整逻辑。目标拆分如下必须包含四个章节市场概况、竞品矩阵对比、SWOT分析、结论与建议每章不能低于150字必须包含至少六个具体品牌名称且每个品牌有至少一个具体产品型号报告总字数控制在800到1500字结论建议必须和SWOT里的分析点有映射关系前三条可以靠代码规则检测后两条交给LLM裁判。3.2 技术选型为什么我不用Agent框架提到做Agent大家第一反应是LangChain或者LlamaIndex。但我建议第一个Loop项目不用任何框架因为Loop的结构太简单了框架反而会把核心逻辑埋在一堆抽象类里。我见过不少新手在LangChain里翻遍了AgentExecutor源码都找不到自定义评估器的位置浪费时间。这里直接用Python写一个裸循环只依赖OpenAI的SDK或者任何兼容OpenAI接口的API。核心逻辑不超过一百行所有评估和修正逻辑都摆在明面上哪里有问题一眼就能看到。如果你用的是国产模型或本地模型只要API兼容OpenAI格式代码完全不用改只换base_url和model_name即可。3.3 核心代码一步步写给你看先定义三个Prompt模板。第一个是初始生成指令INITIAL_PROMPT 你是一名资深的智能硬件行业分析师。请撰写一份《智能手环竞品分析报告》要求 1. 包含市场概况、竞品矩阵对比、SWOT分析、结论与建议四个章节 2. 至少提到6个真实品牌每个品牌要有具体产品型号 3. 市场概况部分给出可量化的数据哪怕是合理估算也要有具体数字 4. 结论建议必须与SWOT分析中的要点一一对应 5. 全文800-1500字Markdown格式输出。 第二个是评估Prompt这里的关键是要求模型输出严格JSONEVALUATE_PROMPT 你是一名严格的报告评审编辑。请对下面这份《智能手环竞品分析报告》进行评分满分100分。 评分规则 - 结构完整性0-30分四个章节是否都存在且内容充实 - 数据具体性0-30分是否包含具体品牌、型号、市场规模数字 - 逻辑一致性0-20分SWOT分析是否与竞品对比数据呼应 - 可执行性0-20分结论与建议是否具体、可落地 如果某项有缺陷必须在problems里用【原文摘录】→【问题描述】的格式写清楚。 只输出一个JSON对象不要输出任何其他文字 {score: 分数, problems: [问题1, 问题2, ...]} 报告内容 {content} 注意这里有个细节评分规则里我明确要求problems要引用原文而不是泛泛而谈。这能大幅提升修正指令的准确度。第三个是修正Prompt要求模型有针对性修改REFINE_PROMPT 你正在修改下面这份竞品分析报告。这是当前版本 {content} 评审人提出了以下问题 {problems} 修改要求 1. 只修改被上述问题点名的内容未点名的地方一律保留原文 2. 每个问题都必须解决不能跳过 3. 不要为了凑字数新增无关内容 4. 保持完整报告结构Markdown格式800-1500字。 请直接输出修改后的完整报告不要添加任何解释。 接下来是主循环逻辑。这里比大多数教程多做一件事保留每一轮的分数列表并且始终持有历史最高分版本防止最后输出反而变差import json from openai import OpenAI client OpenAI() MODEL gpt-4o-mini def chat(prompt: str) - str: resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.4, ) return resp.choices[0].message.content def generate_report(prompt: str) - str: return chat(prompt) def evaluate_report(content: str) - dict: raw chat(EVALUATE_PROMPT.format(contentcontent)) # 防止模型在JSON外面包了markdown代码块 raw raw.strip().strip(json).strip().strip() return json.loads(raw) def run_loop(max_iter: int 5, score_threshold: float 85) - dict: content generate_report(INITIAL_PROMPT) best {score: 0, content: content, round: 0} history [] for i in range(1, max_iter 1): eval_result evaluate_report(content) score eval_result[score] problems eval_result.get(problems, []) history.append({round: i, score: score, problems: problems}) print(f第 {i} 轮评分: {score}) if score best[score]: best {score: score, content: content, round: i} if score score_threshold: print(f达到目标分数 {score_threshold}循环结束。) return {best: best, history: history, final: content} if not problems: problems [报告质量仍需提升请从整体逻辑和数据具体性方面改进。] refine_prompt REFINE_PROMPT.format(contentcontent, problems\n.join(problems)) content generate_report(refine_prompt) print(f已达到最大迭代次数 {max_iter}返回历史最优版本。) return {best: best, history: history, final: content} if __name__ __main__: result run_loop() print(最优版本在第, result[best][round], 轮分数, result[best][score]) print(result[best][content])这段代码里我刻意处理了几个坑一是评估返回的JSON可能被模型包裹在Markdown代码块里所以做了strip处理二是当problems为空但分数又不达标时给一句兜底反馈避免修正在无目标情况下乱跑三是历史最高分版本保存在best里不会因为最后一轮变差而丢失成果。3.4 运行结果与关键参数调优我用gpt-4o-mini为例跑了一轮记录如下轮次分数主要问题168品牌数量不足6个市场概况缺具体市场规模数据结论与SWOT对应关系弱279市场概况有了数据但竞品对比表混入了两款非手环产品建议部分仍偏笼统386符合全部规则进入阈值循环结束最终报告达到了阈值总共消耗不到50万Token含返工成本大约一块钱人民币出头。对一个自动写报告的流程来说非常划算。几个可以调的参数temperature我建议0.3到0.5。太高模型会随机引入新错误太低则修改空间有限。max_iter一般3到5轮就够超过5轮还没收敛的大概率是评估器或Prompt出了问题继续跑只是烧钱。score_threshold取决于你对质量的容忍度。产线自动化建议85分起步人工再筛查。3.5 把OpenAI换成本地模型的三种改法很多读者没条件调海外API或者对数据隐私有要求。替换方式非常简单方式一Ollama本地部署模型选qwen2.5:14b或command-r这类指令跟随强的模型然后设置client的base_url为http://localhost:11434/v1方式二使用国内云厂商的OpenAI兼容端点只改base_url和api_key两行方式三如果你用的模型不支持OpenAI接口但提供原生SDK那么只需重写chat函数把请求方式换掉逻辑不动。本地模型通常跑出来的初始分数比gpt-4o低一些但Loop的价值在这个场景反而更明显小模型经过几轮修正后往往能追上甚至超过不经Loop的大模型单次输出。这说明评估-修正循环有时候比模型本身的能力更重要。4. 常见问题与排查技巧实录4.1 分数一直不涨循环在原地打转这是Loop项目里最普遍的问题。原因通常有三个评估器给出的问题是模糊的、修正Prompt没有要求针对问题改、模型每次都在重写而不是修订。我的检查顺序是先看评估器输出的问题列表是否都指向原文中的具体句子如果全是内容不够丰富逻辑不够清晰这类空话那就是评估器本身偷懒了。解决办法是在评估Prompt里强制要求每条问题必须包含原文摘录并对摘录有具体批评。另外把temperature降到0.2再跑一轮如果分数立刻上涨说明之前的震荡是采样随机性造成的。4.2 越改越差分数在65和80之间反复横跳这种情况通常发生在第二或第三轮模型这轮改好了A问题却把B部分原本正确的数据写错了。我处理的方式是引入版本比较在refine前让模型先列出我计划修改的三个点确认它没有动其他地方的意图再让它输出完整版。虽然多花一点Token但能显著减少误伤。另一种更彻底的做法是把报告拆成段落级小块分别走Loop。比如市场概况、竞品对比、SWOT各作为一个独立单元改动只发生在对应块内块与块之间用固定模板拼接。这个方案效果最好但工程复杂度高一些。4.3 Token成本爆炸比直接调用贵了十几倍很多人第一次跑Loop都会惊到明明只有四轮Token消耗却顶得上单次调用十几次。原因是每一轮Refine都把完整历史报告拼进了Prompt报告越长每轮消耗越大轮数一多费用自然指数增长。对策有三个方向一是限制单轮内容长度报告保持在1000字以内二是用变更片段替代完整重写只让模型输出需要修改的段落三是给历史加摘要每轮只保留上一轮的分数、问题列表和当前全文不要传对话历史。实操下来第三点最直接能砍掉一半以上的Token。4.4 LLM当裁判的舔狗效应评分虚高如果你直接用LLM既当选手又当裁判你会发现分数普遍比真实质量高20%左右。这是因为同一个LLM在读到一份看起来挺完整的报告时很容易给好评。我试过把同一份质量很差的报告让gpt-4o自评它能打到83分但人工看只有65分。解决方法一是把评估器的temperature设为0强制稳定二是在评估Prompt里加入你必须找到至少3个问题否则视为本次检查失败的约束三是用两个不同系统提示词的评估器交叉打分取低值。最后一种方式尤其有效但会增加一倍评估成本不需要在每轮都用可以在最后两轮做最终验收。4.5 到最大迭代次数还没达标怎么保住成果如果到达设定的max_iter时分数仍不达标很多粗心的实现会直接返回最后一版但最后一版往往不是最优版本。正确做法是像我在代码里做的那样始终维护一个best变量记录历史最高分数对应的内容。最后返回best而不是final。同时把history结构打印出来方便排查哪一轮分数下跌、下跌原因是什么。我自己的项目里甚至会再补一个人工介入逻辑当连续两轮分数没有提升时提前终止循环并触发人工评审通知。与其空转不如让流程停下来。5. 进阶玩法把Loop从脚本变成系统5.1 多候选并行让循环同时跑多份既然单次生成是随机的那我们可以把Loop和Beam Search的思路结合同一份初稿任务并行跑三到五个独立Loop每个Loop有自己的随机种子和变化空间。最终汇总时从所有版本里选分数最高的那个。这样做能把单次碰运气的依赖摊薄效果比单路跑更多轮更稳。代价是并行调用会同时拉高Token成本和API并发。建议只对最终交付物使用这个策略比如对外发布的报告、上生产的代码而日常草稿单路Loop就够了。5.2 把Loop嵌入更大的PipelineLoop不应该是一个孤立脚本它更像是流水线上的一道质检工序。比如一个自动调研Agent的完整流程是先遍历网页抓资料然后把抓取结果合成报告再做一轮Loop质检通过后推送渠道发布。Loop在这一步的作用就是把半成品打磨成可交付品。因为Loop的接口足够简单传内容返回最优结果它可以被任意上层系统调用。我现在的做法是把Loop封成一个通用函数库内部配置化评估模板、阈值、最大轮次都由配置文件传入业务系统只负责调函数、拿结果。5.3 人在环不是所有环节都适合机器打分对于风险高或创意类的任务AI裁判的置信度可能不够。这种情况下Loop可以跑两轮机器修正之后把评估结果、修改建议、当前版本一并打包发送给人工审批。人工既可以直接修改报告也可以补充几条机器没发现的问题再丢回Loop继续迭代。这个人工在环设计既保留了机器循环的高效率又给了人类把守最后一道门的机会。实现上并不复杂在循环内判断如果分数超过某个阈值比如70但没到最终阈值比如90就暂停并发送人工评审通知人工反馈作为下一轮评估结果注入循环。5.4 可观测性每一轮轨迹都要能复盘最后一条经验Loop项目上线前必须把每一轮的输入输出、评分、问题列表、Token消耗完整记录下来。不要只记最终结果因为你排查线上问题时靠的是中间轨迹而不是最终输出。我一般把历史记录结构化存储每次迭代生成一条记录包含轮次、分数、修改摘要、Token数、耗时再附带一个content_diff记录这轮相比上一轮改了什么。有了这些数据你可以轻松回答三个问题哪一轮分数最高、哪一轮费用最高、哪个评估维度一直不达标。这三个问题基本决定了一个Loop系统能不能持续优化。我自己做到现在的体会是Loop Engineering不是银弹它的价值不取决于循环本身而取决于你设置的评估器敏感不敏感、修正指令具体不具体。同一个循环骨架评估器写得敷衍跑十轮也就是原地踏步评估器写得严格两三轮就能把质量拉上去。如果你正准备搭第一个Loop项目我的建议是先把场景缩小到结果能被明确检查的任务比如数据清洗、报告补全、代码单测修复先把闭环跑通再考虑扩展到更复杂的Agent系统。这套功夫值得花时间练。
阅读完成 · 觉得有帮助？
