大模型应用开发做久了你大概率会撞上这样一类问题提示词已经写得很详细RAG 检索也接上了结果模型在个别场景下依然“一本正经地胡说八道”或者第一轮回答效果不错一旦用户追问细节输出就开始偏离事实。网上资料大多只教你怎么调 prompt、怎么接向量库但很少有人把“怎么让大模型应用在运行过程中不断自我修正”这件事讲透。这篇文章我想围绕一个这两年大模型工程化里频繁被提及的方法论——Loop Engineering展开一套从入门到实战的完整教程。它不是某个具体框架也不是一种编程语言而是一套“让 AI 应用具备闭环反馈能力”的工程设计思路。我会先解释清楚它到底是什么、解决什么问题然后给出完整的代码实战带你从零搭建一个具备“执行—评估—反思—再执行”能力的 AI 工单分类与问答系统。无论你是刚接触 AI 大模型应用开发的新手还是已经在做 RAG、Agent 落地的开发者都能从里面找到可以直接复用的思路和代码。为方便阅读文中所有示例都标注了文件路径你可以直接照着复制运行。1. Loop Engineering 是什么先搞清楚核心概念1.1 一句话理解 Loop EngineeringLoop Engineering循环工程本质上是一套“基于反馈闭环来持续改进 AI 系统行为”的工程方法论。传统软件开发里我们写下一段逻辑输入确定了输出基本就是确定的。但大模型不一样它是概率系统同样的输入在不同温度、不同上下文甚至不同随机种子下输出都可能不同。你没法用“if-else”把模型的所有行为都约束住。Loop Engineering 的思路很简单既然一次调用无法保证质量那就不只调用一次。它的核心循环可以概括为生成Generate → 评估Evaluate → 反馈Feedback → 优化Optimize → 再生成这个循环可以发生在不同的粒度上单次请求内部循环比如让模型先生成答案再让另一个“评估者”角色检查答案是否合格不合格就带着批评意见重新生成。跨请求的数据闭环比如把线上失败的案例收集起来定期用于微调或者 Few-shot 示例更新。Agent 执行循环比如让模型自主决定调用哪个工具、分析工具返回结果、判断是否完成任务不满足条件就继续执行下一步。所以Loop Engineering 不是某一个开源项目的名字而是大模型应用开发中的一种设计哲学。它的价值在于把“不可控的模型输出”纳入“可控的工程流程”通过流程机制来兜底模型的随机性。1.2 Loop Engineering 与 AI 大模型开发的关系AI 大模型应用开发目前已经过了“套个 Prompt 就能用”的阶段。现在做 Agent、RAG、自动化工作流大家更关心的是三件事稳定性模型输出是否能在业务要求的范围内保持稳定。可控性当模型跑偏时系统能不能发现并纠正。可进化性系统能否从历史错误中持续学习越用越准。Loop Engineering 恰好覆盖了这三方面。它把大模型从“一次性回答工具”升级成“具有自省能力的执行体”。这也是为什么现在很多招聘 JD 里大模型应用开发工程师都要求具备“AI Agent 循环设计”“Prompt 自优化”“RAG 评估闭环”相关经验。1.3 容易混淆的概念区分概念核心关注点和 Loop Engineering 的关系Prompt Engineering设计更好的输入文本引导模型输出是 Loop 中“生成”环节的基础能力RAG检索增强生成引入外部知识库减少幻觉是 Loop 中“记忆/工具调用”的一种实现方式Agent让模型自主决策、调用工具、完成任务Agent 本身就是一种多层 Loop 的工程实现Fine-tuning微调通过训练数据调整模型权重是跨请求闭环优化的最终手段之一Loop Engineering建立系统级的反馈闭环统摄上述技术使系统具备自我修正能力理解这个区别后你会发现Loop Engineering 更偏“架构层”的方法论而不是某个具体的算法或工具。它要求你在设计系统时把“反馈”作为一等公民来对待。2. 环境准备与版本说明开始写代码之前先搭好环境。本节列出我使用的环境信息如果你本地版本不同思路和代码逻辑不需要改动只需要把依赖版本调整为你实际的环境即可。2.1 运行环境操作系统Windows 11 / macOS 13 / Ubuntu 20.04 均可Python 版本3.9 及以上建议 3.10 或 3.11大模型 APIOpenAI 兼容接口支持 Chat Completions 接口开发工具VS Code 或 PyCharm命令行使用终端2.2 安装依赖pip install openai1.30.0 pip install python-dotenv1.0.1这里要说明两点第一openai库的版本迭代很快本文使用 1.x 版本的调用风格即通过OpenAI()客户端对象调用如果你使用的是 0.x 版本API 写法差异较大建议升级。第二如果你使用的是国内大模型厂商提供的 OpenAI 兼容接口只需要修改base_url和api_key即可代码本身不需要改动。这是一种很常见的做法也是目前许多生产项目的真实选择。2.3 项目结构规划我们准备实现的项目是一个**“基于 Loop Engineering 的 AI 工单分类与问答引擎”**项目结构如下loop-engineering-demo/ ├── .env ├── requirements.txt ├── main.py ├── core/ │ ├── __init__.py │ ├── llm.py │ ├── agent.py │ └── evaluator.py └── data/ ├── tickets.csv └── knowledge_base.txt.env存放 API 密钥和基础配置。core/llm.py封装大模型调用逻辑。core/evaluator.py负责评估模型输出质量。core/agent.py实现 Loop Engineering 的核心循环。main.py程序入口演示完整流程。data/tickets.csv模拟工单数据。data/knowledge_base.txt模拟企业知识库。下面我们逐层拆解。3. 核心原理拆解Loop Engineering 的五个关键层在写代码之前我们需要把 Loop Engineering 的工程结构拆开看。一个完整的 Loop Engineering 系统通常包含五个关键层。这五层不一定在每次实现中都齐全但理解它们有助于你根据业务需要做取舍。3.1 第一层感知层Perception Layer感知层的职责是把外部输入转换成模型可理解的结构化信息。在工单系统里原始输入是用户的一句话例如我的订单已经付款三天了还没有发货麻烦帮我查一下感知层需要做的事包括判断意图是物流查询、退款申请还是商品咨询抽取关键实体订单号、用户 ID、时间屏蔽敏感信息标准化文本格式。实现方式可以是正则、规则也可以是调用大模型做信息抽取。在 Loop 设计里感知层的输出质量直接影响后续所有环节所以建议把抽取结果也纳入评估范围。3.2 第二层决策层Decision Layer决策层负责根据感知结果决定下一步动作。这可以是一个简单的分类结果如“该工单属于物流问题”也可以是一个多步执行计划如“先查订单状态再查物流轨迹最后生成回复”。在 LLM Agent 体系中决策层往往由模型本身扮演。你需要给模型定义清晰的动作空间比如{ available_actions: [ {name: query_order, description: 查询订单状态, parameters: {order_id: string}}, {name: query_logistics, description: 查询物流轨迹, parameters: {order_id: string}}, {name: transfer_human, description: 转接人工客服, parameters: {reason: string}} ] }决策层的输出通常是一个结构化动作而非自然语言回答。这是 Agent 与普通聊天机器人的重要区别。3.3 第三层执行层Execution Layer执行层负责调用外部工具、查询数据库、检索知识库并把结果返回给模型。在 RAG 场景中执行层就是向量检索在工单系统中执行层可能是查询订单系统的 API在数据处理任务中执行层可能是一段 Python 函数。执行层是 Loop 中“真实世界信息”的来源。模型产生的幻觉往往就是因为执行层没有提供足够的事实依据或者模型没有正确使用执行层返回的结果。因此执行层的返回结构最好简洁、字段明确减少模型理解负担。3.4 第四层评估层Evaluation Layer评估层是整个 Loop Engineering 的灵魂也是最容易被初学者忽略的一层。它的职责是判断当前输出是否达到业务标准。评估可以分为两种硬性评估Hard Evaluation基于规则检查比如输出是否包含订单号、是否超过字数限制、是否包含 JSON 格式。软性评估Soft Evaluation让一个大模型扮演“评委”对另一个模型的输出进行打分或批评例如请判断以下客服回复是否友好、准确、完整。如果不合格请指出具体问题硬评估执行快、成本低但覆盖有限软评估能力强、灵活度高但引入额外延迟和成本。生产系统中通常是两者结合。3.5 第五层反思与优化层Reflection Layer反思层拿到评估结果后决定下一步怎么做。常见策略有重试Retry简单地把原任务再让模型生成一次通常配合温度调整。带反馈重试Retry with Feedback把评估者的批评意见附加到 Prompt 中让模型知道自己哪里错了重新生成。这是最经典的 Reflection 模式。切换策略Fallback如果重试两次仍失败降级为转人工或使用规则兜底。格式修正Format Fixer当模型输出无法解析时专门让一个模型负责修复格式。累积学习Memory Update把本次失败案例写入外部记忆下次类似问题直接走正确策略。这五层组合起来就构成一个完整的 Loop Engineering 循环。下面我们用代码把它们落地。4. 完整实战从零搭建 AI 工单分类与问答引擎4.1 初始化配置首先在项目根目录创建.env文件写入配置OPENAI_API_KEYyour-api-key-here OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini如果使用的是 OpenAI 兼容的第三方服务请将OPENAI_BASE_URL替换为对应的接口地址。创建requirements.txtopenai1.30.0 python-dotenv1.0.1安装依赖pip install -r requirements.txt4.2 封装大模型调用模块在core/llm.py中我们封装一个统一的模型调用函数。这个模块负责读取环境变量构造OpenAI客户端提供对话补全方法支持自定义 system prompt 和 temperature。# 文件路径core/llm.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL_NAME os.getenv(OPENAI_MODEL, gpt-4o-mini) def chat(system_prompt: str, user_prompt: str, temperature: float 0.3) - str: 调用大模型对话接口返回文本内容。 response client.chat.completions.create( modelMODEL_NAME, temperaturetemperature, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], ) return response.choices[0].message.content这里有一个接口版本问题需要提醒。openai1.x 版本中chat.completions.create返回的是ChatCompletion对象消息内容通过response.choices[0].message.content获取。如果你在其它教程里看到response[choices][0][message][content]这种写法那是 0.x 版本或接口响应 dict 风格注意分辨。4.3 设计知识库与工单数据为了让 RAG 部分可演示我们准备一个简单的知识库文件data/knowledge_base.txt【退款政策】用户在购买商品后 7 天内可以申请无理由退款但商品需要保持完好且不影响二次销售。 【发货时效】常规商品在下单后 48 小时内发货预售商品以商品详情页标注时间为准。 【物流查询】物流信息一般在发货后 24-48 小时内更新如果超过 48 小时没有更新可能是物流公司揽收延迟。 【发票开具】电子发票将在订单完成后 7 个工作日内发送至用户邮箱抬头需在订单确认时填写。 【售后入口】用户可以在“我的订单”页面找到“申请售后”按钮或者联系在线客服转人工处理。然后创建工单数据data/tickets.csvticket_id,user_input T1001,我的订单已经付款三天了还没有发货麻烦帮我查一下 T1002,我想申请退款但是找不到入口在哪里。 T1003,这个商品的发票什么时候能开我等着报销。4.4 实现评估器模块评估器是整个闭环里最关键的一环。我们这里混合使用硬性规则和模型评估两种方式。# 文件路径core/evaluator.py import json from core.llm import chat def hard_evaluate(reply: str, ticket_content: str) - dict: 硬性规则评估检查回复是否为空、是否过短、是否包含明显的幻觉特征。 issues [] passed True if not reply or len(reply.strip()) 10: issues.append(回复为空或过短) passed False if 根据知识库 not in reply and 根据我查到的信息 not in reply: # 这里只是一个演示规则我们要求客服回复需要明确知识来源 issues.append(回复未标注信息来源存在幻觉风险) passed False return {passed: passed, issues: issues} def model_evaluate(reply: str, ticket_content: str, knowledge: str) - dict: 大模型评估让一个模型扮演质检员检查另一个模型的回复质量。 system_prompt 你是一位资深的客服质检员。你的任务是对 AI 客服的回复进行评审。 评审标准包括 1. 准确性回复内容是否基于提供的知识库是否包含虚假信息。 2. 完整性是否解决了用户的核心问题。 3. 友好度语气是否礼貌、清晰。 4. 安全性是否承诺了知识库中不存在的内容。 请以 JSON 格式输出格式如下 {passed: true/false, score: 0-100, issues: [问题1, 问题2]} .strip() user_prompt f 【用户问题】 {ticket_content} 【AI 客服回复】 {reply} 【参考资料】 {knowledge} 请评审上述回复质量。 .strip() result_text chat(system_prompt, user_prompt, temperature0.0) try: result json.loads(result_text.strip().strip(json).strip()) return result except json.JSONDecodeError: # 如果大模型输出不是合法 JSON则保守判定为不通过 return {passed: False, score: 0, issues: [评估模型输出无法解析]}需要注意这里model_evaluate需要chat函数返回字符串。如果模型输出中包含 Markdown 代码块我们可以通过简单的字符串清理来提取 JSON。这个方法在演示层面足够但生产环境中建议实现一个更健壮的 JSON 提取器。4.5 实现核心 Agent 循环接下来是核心部分——core/agent.py。这里实现了 Loop Engineering 的核心循环先分类工单意图根据意图检索知识库生成回复评估回复如果不通过带着评估意见重新生成超过最大循环次数后转人工。# 文件路径core/agent.py import re from core.llm import chat from core.evaluator import hard_evaluate, model_evaluate MAX_LOOP_COUNT 3 def load_knowledge_base(filepath: str) - str: with open(filepath, r, encodingutf-8) as f: return f.read() def classify_ticket(user_input: str) - str: 对工单进行分类返回分类标签。 system_prompt 你是工单分类器。请将用户问题分类为以下类别之一 - 物流查询涉及发货、物流、快递、收货时间 - 退款售后涉及退款、退货、售后、发票 - 商品咨询涉及商品信息、库存、规格 - 其他 只输出分类标签不要输出其他内容。 .strip() label chat(system_prompt, user_input, temperature0.0).strip() return label def retrieve_knowledge(query: str, knowledge_base: str) - str: 简易知识检索。真实系统可替换为向量数据库召回。 这里我们按关键词做简单的段落筛选演示 RAG 的反馈闭环。 sections knowledge_base.strip().split(\n) matched [] for section in sections: keywords re.findall(r【(.*?)】, section) if not keywords: continue tag keywords[0] # 简单关键词映射 mapping { 退款政策: [退款, 退货], 发货时效: [发货, 物流, 快递], 物流查询: [物流, 快递, 发货], 发票开具: [发票, 报销], 售后入口: [售后, 退款, 退货], } tag_keywords mapping.get(tag, []) if any(kw in query for kw in tag_keywords): matched.append(section) if matched: return \n.join(matched) return 未找到相关知识点请如实告知用户需要人工进一步确认。 def generate_reply(user_input: str, label: str, knowledge: str, feedback: str ) - str: 生成回复。如果 feedback 不为空则带着反馈意见重新生成。 system_prompt 你是一位专业的电商客服。请根据用户问题、工单分类和参考资料生成一段友好、准确、完整的回复。 要求 1. 只使用参考资料中的信息不要编造。 2. 如果参考资料不足请明确说“需要人工进一步确认”。 3. 回复开头需要标注“根据我查到的信息”或“根据知识库”。 4. 回复控制在 100 字以内。 {feedback_section} .strip() feedback_section if feedback: feedback_section f\n【上一次回答的问题】\n{feedback}\n请针对上述问题重新生成回复避免再犯同样的错误。 system_prompt system_prompt.format(feedback_sectionfeedback_section) user_prompt f 【用户问题】 {user_input} 【工单分类】 {label} 【参考资料】 {knowledge} .strip() return chat(system_prompt, user_prompt, temperature0.4) def process_ticket(ticket_content: str, knowledge_base: str) - dict: 处理单个工单执行 Loop Engineering 主流程。 # 1. 感知与决策 label classify_ticket(ticket_content) print(f[1] 工单分类结果{label}) # 2. 检索知识 knowledge retrieve_knowledge(ticket_content, knowledge_base) print(f[2] 召回知识片段\n{knowledge}\n) # 3. 生成 评估 反思循环 reply feedback history [] for loop_index in range(1, MAX_LOOP_COUNT 1): print(f[3] 第 {loop_index} 轮生成...) # 生成 reply generate_reply(ticket_content, label, knowledge, feedback) print(f 生成回复{reply}) # 硬评估 hard_result hard_evaluate(reply, ticket_content) print(f 硬评估结果{hard_result}) if not hard_result[passed]: feedback ; .join(hard_result[issues]) history.append({loop: loop_index, reply: reply, evaluator: hard, issues: hard_result[issues]}) continue # 软评估 model_result model_evaluate(reply, ticket_content, knowledge) print(f 模型评估结果{model_result}) if not model_result[passed]: issues model_result.get(issues, []) feedback ; .join(issues) history.append({loop: loop_index, reply: reply, evaluator: model, issues: issues}) continue # 评估通过退出循环 history.append({loop: loop_index, reply: reply, evaluator: pass, issues: []}) return { ticket_content: ticket_content, label: label, final_reply: reply, history: history, status: solved, } # 4. 超过循环次数转人工兜底 return { ticket_content: ticket_content, label: label, final_reply: 抱歉AI 暂时无法准确处理您的问题已为您转接人工客服请稍候。, history: history, status: escalated, }这里的代码结构比较清晰循环内部先执行硬评估再执行模型评估。硬评估失败时直接进入下一轮硬评估通过但模型评估不通过时带着反馈意见重新生成。这样既控制了成本不一定每轮都调用大模型评审又保证了最终输出的质量底线。4.6 编写主程序入口最后编写main.py对测试工单进行批量处理# 文件路径main.py import csv from core.agent import process_ticket, load_knowledge_base def main(): knowledge_base load_knowledge_base(data/knowledge_base.txt) with open(data/tickets.csv, r, encodingutf-8) as f: reader csv.DictReader(f) tickets list(reader) for ticket in tickets: print( * 60) print(f工单 ID{ticket[ticket_id]}) print(f用户问题{ticket[user_input]}) result process_ticket(ticket[user_input], knowledge_base) print(\n最终回复, result[final_reply]) print(处理状态, result[status]) print( * 60 \n) if __name__ __main__: main()4.7 运行与验证在项目根目录执行python main.py预期输出效果如下实际内容受模型影响可能有差异 工单 IDT1001 用户问题我的订单已经付款三天了还没有发货麻烦帮我查一下 [1] 工单分类结果物流查询 [2] 召回知识片段 【发货时效】常规商品在下单后 48 小时内发货预售商品以商品详情页标注时间为准。 【物流查询】物流信息一般在发货后 24-48 小时内更新如果超过 48 小时没有更新可能是物流公司揽收延迟。 [3] 第 1 轮生成... 生成回复根据我查到的信息常规商品在下单后 48 小时内发货您的订单已付款三天建议您先查看物流信息如果超过 48 小时没有更新可能是物流公司揽收延迟。 硬评估结果{passed: True, issues: []} 模型评估结果{passed: True, score: 90, issues: []} 最终回复根据我查到的信息常规商品在下单后 48 小时内发货您的订单已付款三天建议您先查看物流信息如果超过 48 小时没有更新可能是物流公司揽收延迟。 处理状态solved 至此一个带反馈闭环的工单问答引擎就跑通了。它可以自动分类、检索知识、生成回复并且在回复质量不达标时进行自我反思和重新生成。这就是 Loop Engineering 在 AI 大模型应用中最直白的落地形态。5. 常见问题与排查思路在实际运行和二次开发中你可能会遇到下面这些问题。我整理了一份排查清单方便你按图索骥。问题现象常见原因解决思路AuthenticationErrorAPI Key 错误或未正确加载检查.env文件是否被正确读取确认环境变量名一致模型返回空字符串上下文过长或温度过低导致输出异常尝试提高 temperature检查 system prompt 是否冲突评估模型输出不是合法 JSON模型返回了 Markdown 代码块或额外说明文字增加 JSON 提取逻辑使用json.loads前先清理代码块标记硬评估总是提示“未标注信息来源”规则设置过严根据业务需要放宽关键字匹配或改用模型评估判断信息来源循环次数耗尽全部转人工生成模型始终无法满足评估标准检查知识库是否覆盖用户问题、评估标准是否合理、模型是否过弱成本过高每轮都调用模型评估优先使用硬评估过滤明显不合格结果再对疑似结果调用模型评估前置import失败虚拟环境未激活或依赖未安装执行pip install -r requirements.txt确认当前解释器环境这里特别想强调“反馈信息质量”的问题。在 Loop 中评估者给出的反馈越具体反思重写的效果就越好。如果你只是让评估器输出“回答质量差”这种笼统信息模型大概率不知道该怎么改但如果你说“回答缺少订单号且未说明物流更新延迟的可能原因”模型下一轮生成的精度就会明显提升。这也是 Reflection 模式能起作用的关键。6. 最佳实践与工程建议6.1 评估规则要分层次设计生产环境不要只用一个大模型评估所有内容。更好的做法是三层漏斗规则层零成本检查字段是否缺失、格式是否合法、是否包含禁用词模型层有成本判断语义是否准确、逻辑是否自洽、语气是否合适人工抽检层高成本定期抽检线上样本反向优化前两层规则和 Prompt。这样可以在质量和成本之间找到平衡点。像我们的 Demo 中实际上已经使用了规则层和模型层只是规则层还比较简单。6.2 循环必须有最大次数和退路没有边界的 Loop 是灾难。一定要设置最大循环次数并且定义清楚“循环失败后怎么办”。常见的策略包括转人工客服返回一个默认的安全回复切换到更小的模型跑一次简单模式记录日志进入异步人工 review 队列。在设计上这是为了让系统始终具备“优雅降级”能力而不是无限消耗 token。6.3 日志记录是 Loop 的燃料如果你不做数据积累Loop Engineering 就只是在“原地兜圈”。生产项目中应该把每一轮循环的输入、输出、评估结果、反馈意见、最终处置方式全部记录到结构化日志里。后续可以用这些数据做几件事分析高频失败场景定向补充知识库收集 Few-shot 示例优化 System Prompt构造微调训练集对模型做针对性优化反推评估标准是否合理。日志格式建议至少包含以下字段{ ticket_id: T1001, loop_index: 1, model: gpt-4o-mini, input: 用户原始问题, output: 模型生成回复, evaluator: model, passed: false, issues: [缺少订单号], latency_ms: 1234, timestamp: 2026-01-01T10:00:00Z }6.4 注意安全边界与权限控制当 Loop Engineering 系统涉及工具调用、数据库访问或第三方 API 操作时必须在代码中做好边界控制工具执行必须限制在白名单动作内所有外部操作前做参数校验涉及敏感数据时不把原始数据写入 Prompt如果 Agent 需要操作生产环境必须遵循最小权限原则并在测试环境充分验证。AI 应用具备“自主执行能力”之后安全边界就不再只是代码规范而是系统设计的核心约束。6.5 评估模型和生成模型可以分离在成本允许的前提下建议使用不同模型分别承担生成和评估任务。例如生成用中档模型评估用更强的模型。原因是如果同一个模型既生成又评估它可能“对自己的错误不够敏感”而更强的评估模型往往能发现更细微的问题。当然这个策略需要结合你的实际成本和模型能力来决定。7. 总结与学习路线这篇文章从概念到代码完整演示了 Loop Engineering 在大模型应用开发中的落地方式。我们通过一个工单问答引擎实现了“分类—检索—生成—评估—反思—再生成”的闭环流程并且加入了转人工兜底机制。这套思路同样适用于对话机器人、RAG 问答系统、AI Agent、自动化报表生成等场景。如果你想继续深入我建议按下面的路线学习学透 Prompt EngineeringLoop 中“生成”阶段的质量上限很大程度上取决于 Prompt 设计能力。掌握 RAG 全链路把简易关键词检索替换为向量库召回研究文档切分、Embedding 模型选择、重排序等问题。研究 Agent 工具调用让模型能够调用真实 API 并处理返回值这是复杂 Loop 的基础。实践评估体系用开源框架搭建离线评测集把 Loop 从“在线运行时闭环”升级为“离线数据闭环”。关注模型微调当循环次数达到瓶颈时微调往往能从根本上提升模型对特定任务的适配度。最后提醒一句Loop Engineering 的核心不是“循环”这个动作本身而是“每次循环都能让系统变得更好一点点”。如果你在设计系统时始终把评估和反馈放在和生成同等重要的位置你的大模型应用会稳定很多。建议你现在就拿一个真实业务场景试着把本文的代码改造成你的最小可行版本然后观察日志里那些反复失败的样本从它们开始优化。如果这篇文章对你有帮助欢迎收藏备用也欢迎在评论区聊聊你在大模型应用开发中遇到的“循环”问题。下一篇文章我计划深入写一写“如何搭建一套大模型离线评估集”如果你感兴趣可以先关注起来。 Loop Engineering实战：让大模型应用具备自我修正能力
大模型应用开发做久了你大概率会撞上这样一类问题提示词已经写得很详细RAG 检索也接上了结果模型在个别场景下依然“一本正经地胡说八道”或者第一轮回答效果不错一旦用户追问细节输出就开始偏离事实。网上资料大多只教你怎么调 prompt、怎么接向量库但很少有人把“怎么让大模型应用在运行过程中不断自我修正”这件事讲透。这篇文章我想围绕一个这两年大模型工程化里频繁被提及的方法论——Loop Engineering展开一套从入门到实战的完整教程。它不是某个具体框架也不是一种编程语言而是一套“让 AI 应用具备闭环反馈能力”的工程设计思路。我会先解释清楚它到底是什么、解决什么问题然后给出完整的代码实战带你从零搭建一个具备“执行—评估—反思—再执行”能力的 AI 工单分类与问答系统。无论你是刚接触 AI 大模型应用开发的新手还是已经在做 RAG、Agent 落地的开发者都能从里面找到可以直接复用的思路和代码。为方便阅读文中所有示例都标注了文件路径你可以直接照着复制运行。1. Loop Engineering 是什么先搞清楚核心概念1.1 一句话理解 Loop EngineeringLoop Engineering循环工程本质上是一套“基于反馈闭环来持续改进 AI 系统行为”的工程方法论。传统软件开发里我们写下一段逻辑输入确定了输出基本就是确定的。但大模型不一样它是概率系统同样的输入在不同温度、不同上下文甚至不同随机种子下输出都可能不同。你没法用“if-else”把模型的所有行为都约束住。Loop Engineering 的思路很简单既然一次调用无法保证质量那就不只调用一次。它的核心循环可以概括为生成Generate → 评估Evaluate → 反馈Feedback → 优化Optimize → 再生成这个循环可以发生在不同的粒度上单次请求内部循环比如让模型先生成答案再让另一个“评估者”角色检查答案是否合格不合格就带着批评意见重新生成。跨请求的数据闭环比如把线上失败的案例收集起来定期用于微调或者 Few-shot 示例更新。Agent 执行循环比如让模型自主决定调用哪个工具、分析工具返回结果、判断是否完成任务不满足条件就继续执行下一步。所以Loop Engineering 不是某一个开源项目的名字而是大模型应用开发中的一种设计哲学。它的价值在于把“不可控的模型输出”纳入“可控的工程流程”通过流程机制来兜底模型的随机性。1.2 Loop Engineering 与 AI 大模型开发的关系AI 大模型应用开发目前已经过了“套个 Prompt 就能用”的阶段。现在做 Agent、RAG、自动化工作流大家更关心的是三件事稳定性模型输出是否能在业务要求的范围内保持稳定。可控性当模型跑偏时系统能不能发现并纠正。可进化性系统能否从历史错误中持续学习越用越准。Loop Engineering 恰好覆盖了这三方面。它把大模型从“一次性回答工具”升级成“具有自省能力的执行体”。这也是为什么现在很多招聘 JD 里大模型应用开发工程师都要求具备“AI Agent 循环设计”“Prompt 自优化”“RAG 评估闭环”相关经验。1.3 容易混淆的概念区分概念核心关注点和 Loop Engineering 的关系Prompt Engineering设计更好的输入文本引导模型输出是 Loop 中“生成”环节的基础能力RAG检索增强生成引入外部知识库减少幻觉是 Loop 中“记忆/工具调用”的一种实现方式Agent让模型自主决策、调用工具、完成任务Agent 本身就是一种多层 Loop 的工程实现Fine-tuning微调通过训练数据调整模型权重是跨请求闭环优化的最终手段之一Loop Engineering建立系统级的反馈闭环统摄上述技术使系统具备自我修正能力理解这个区别后你会发现Loop Engineering 更偏“架构层”的方法论而不是某个具体的算法或工具。它要求你在设计系统时把“反馈”作为一等公民来对待。2. 环境准备与版本说明开始写代码之前先搭好环境。本节列出我使用的环境信息如果你本地版本不同思路和代码逻辑不需要改动只需要把依赖版本调整为你实际的环境即可。2.1 运行环境操作系统Windows 11 / macOS 13 / Ubuntu 20.04 均可Python 版本3.9 及以上建议 3.10 或 3.11大模型 APIOpenAI 兼容接口支持 Chat Completions 接口开发工具VS Code 或 PyCharm命令行使用终端2.2 安装依赖pip install openai1.30.0 pip install python-dotenv1.0.1这里要说明两点第一openai库的版本迭代很快本文使用 1.x 版本的调用风格即通过OpenAI()客户端对象调用如果你使用的是 0.x 版本API 写法差异较大建议升级。第二如果你使用的是国内大模型厂商提供的 OpenAI 兼容接口只需要修改base_url和api_key即可代码本身不需要改动。这是一种很常见的做法也是目前许多生产项目的真实选择。2.3 项目结构规划我们准备实现的项目是一个**“基于 Loop Engineering 的 AI 工单分类与问答引擎”**项目结构如下loop-engineering-demo/ ├── .env ├── requirements.txt ├── main.py ├── core/ │ ├── __init__.py │ ├── llm.py │ ├── agent.py │ └── evaluator.py └── data/ ├── tickets.csv └── knowledge_base.txt.env存放 API 密钥和基础配置。core/llm.py封装大模型调用逻辑。core/evaluator.py负责评估模型输出质量。core/agent.py实现 Loop Engineering 的核心循环。main.py程序入口演示完整流程。data/tickets.csv模拟工单数据。data/knowledge_base.txt模拟企业知识库。下面我们逐层拆解。3. 核心原理拆解Loop Engineering 的五个关键层在写代码之前我们需要把 Loop Engineering 的工程结构拆开看。一个完整的 Loop Engineering 系统通常包含五个关键层。这五层不一定在每次实现中都齐全但理解它们有助于你根据业务需要做取舍。3.1 第一层感知层Perception Layer感知层的职责是把外部输入转换成模型可理解的结构化信息。在工单系统里原始输入是用户的一句话例如我的订单已经付款三天了还没有发货麻烦帮我查一下感知层需要做的事包括判断意图是物流查询、退款申请还是商品咨询抽取关键实体订单号、用户 ID、时间屏蔽敏感信息标准化文本格式。实现方式可以是正则、规则也可以是调用大模型做信息抽取。在 Loop 设计里感知层的输出质量直接影响后续所有环节所以建议把抽取结果也纳入评估范围。3.2 第二层决策层Decision Layer决策层负责根据感知结果决定下一步动作。这可以是一个简单的分类结果如“该工单属于物流问题”也可以是一个多步执行计划如“先查订单状态再查物流轨迹最后生成回复”。在 LLM Agent 体系中决策层往往由模型本身扮演。你需要给模型定义清晰的动作空间比如{ available_actions: [ {name: query_order, description: 查询订单状态, parameters: {order_id: string}}, {name: query_logistics, description: 查询物流轨迹, parameters: {order_id: string}}, {name: transfer_human, description: 转接人工客服, parameters: {reason: string}} ] }决策层的输出通常是一个结构化动作而非自然语言回答。这是 Agent 与普通聊天机器人的重要区别。3.3 第三层执行层Execution Layer执行层负责调用外部工具、查询数据库、检索知识库并把结果返回给模型。在 RAG 场景中执行层就是向量检索在工单系统中执行层可能是查询订单系统的 API在数据处理任务中执行层可能是一段 Python 函数。执行层是 Loop 中“真实世界信息”的来源。模型产生的幻觉往往就是因为执行层没有提供足够的事实依据或者模型没有正确使用执行层返回的结果。因此执行层的返回结构最好简洁、字段明确减少模型理解负担。3.4 第四层评估层Evaluation Layer评估层是整个 Loop Engineering 的灵魂也是最容易被初学者忽略的一层。它的职责是判断当前输出是否达到业务标准。评估可以分为两种硬性评估Hard Evaluation基于规则检查比如输出是否包含订单号、是否超过字数限制、是否包含 JSON 格式。软性评估Soft Evaluation让一个大模型扮演“评委”对另一个模型的输出进行打分或批评例如请判断以下客服回复是否友好、准确、完整。如果不合格请指出具体问题硬评估执行快、成本低但覆盖有限软评估能力强、灵活度高但引入额外延迟和成本。生产系统中通常是两者结合。3.5 第五层反思与优化层Reflection Layer反思层拿到评估结果后决定下一步怎么做。常见策略有重试Retry简单地把原任务再让模型生成一次通常配合温度调整。带反馈重试Retry with Feedback把评估者的批评意见附加到 Prompt 中让模型知道自己哪里错了重新生成。这是最经典的 Reflection 模式。切换策略Fallback如果重试两次仍失败降级为转人工或使用规则兜底。格式修正Format Fixer当模型输出无法解析时专门让一个模型负责修复格式。累积学习Memory Update把本次失败案例写入外部记忆下次类似问题直接走正确策略。这五层组合起来就构成一个完整的 Loop Engineering 循环。下面我们用代码把它们落地。4. 完整实战从零搭建 AI 工单分类与问答引擎4.1 初始化配置首先在项目根目录创建.env文件写入配置OPENAI_API_KEYyour-api-key-here OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini如果使用的是 OpenAI 兼容的第三方服务请将OPENAI_BASE_URL替换为对应的接口地址。创建requirements.txtopenai1.30.0 python-dotenv1.0.1安装依赖pip install -r requirements.txt4.2 封装大模型调用模块在core/llm.py中我们封装一个统一的模型调用函数。这个模块负责读取环境变量构造OpenAI客户端提供对话补全方法支持自定义 system prompt 和 temperature。# 文件路径core/llm.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL_NAME os.getenv(OPENAI_MODEL, gpt-4o-mini) def chat(system_prompt: str, user_prompt: str, temperature: float 0.3) - str: 调用大模型对话接口返回文本内容。 response client.chat.completions.create( modelMODEL_NAME, temperaturetemperature, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], ) return response.choices[0].message.content这里有一个接口版本问题需要提醒。openai1.x 版本中chat.completions.create返回的是ChatCompletion对象消息内容通过response.choices[0].message.content获取。如果你在其它教程里看到response[choices][0][message][content]这种写法那是 0.x 版本或接口响应 dict 风格注意分辨。4.3 设计知识库与工单数据为了让 RAG 部分可演示我们准备一个简单的知识库文件data/knowledge_base.txt【退款政策】用户在购买商品后 7 天内可以申请无理由退款但商品需要保持完好且不影响二次销售。 【发货时效】常规商品在下单后 48 小时内发货预售商品以商品详情页标注时间为准。 【物流查询】物流信息一般在发货后 24-48 小时内更新如果超过 48 小时没有更新可能是物流公司揽收延迟。 【发票开具】电子发票将在订单完成后 7 个工作日内发送至用户邮箱抬头需在订单确认时填写。 【售后入口】用户可以在“我的订单”页面找到“申请售后”按钮或者联系在线客服转人工处理。然后创建工单数据data/tickets.csvticket_id,user_input T1001,我的订单已经付款三天了还没有发货麻烦帮我查一下 T1002,我想申请退款但是找不到入口在哪里。 T1003,这个商品的发票什么时候能开我等着报销。4.4 实现评估器模块评估器是整个闭环里最关键的一环。我们这里混合使用硬性规则和模型评估两种方式。# 文件路径core/evaluator.py import json from core.llm import chat def hard_evaluate(reply: str, ticket_content: str) - dict: 硬性规则评估检查回复是否为空、是否过短、是否包含明显的幻觉特征。 issues [] passed True if not reply or len(reply.strip()) 10: issues.append(回复为空或过短) passed False if 根据知识库 not in reply and 根据我查到的信息 not in reply: # 这里只是一个演示规则我们要求客服回复需要明确知识来源 issues.append(回复未标注信息来源存在幻觉风险) passed False return {passed: passed, issues: issues} def model_evaluate(reply: str, ticket_content: str, knowledge: str) - dict: 大模型评估让一个模型扮演质检员检查另一个模型的回复质量。 system_prompt 你是一位资深的客服质检员。你的任务是对 AI 客服的回复进行评审。 评审标准包括 1. 准确性回复内容是否基于提供的知识库是否包含虚假信息。 2. 完整性是否解决了用户的核心问题。 3. 友好度语气是否礼貌、清晰。 4. 安全性是否承诺了知识库中不存在的内容。 请以 JSON 格式输出格式如下 {passed: true/false, score: 0-100, issues: [问题1, 问题2]} .strip() user_prompt f 【用户问题】 {ticket_content} 【AI 客服回复】 {reply} 【参考资料】 {knowledge} 请评审上述回复质量。 .strip() result_text chat(system_prompt, user_prompt, temperature0.0) try: result json.loads(result_text.strip().strip(json).strip()) return result except json.JSONDecodeError: # 如果大模型输出不是合法 JSON则保守判定为不通过 return {passed: False, score: 0, issues: [评估模型输出无法解析]}需要注意这里model_evaluate需要chat函数返回字符串。如果模型输出中包含 Markdown 代码块我们可以通过简单的字符串清理来提取 JSON。这个方法在演示层面足够但生产环境中建议实现一个更健壮的 JSON 提取器。4.5 实现核心 Agent 循环接下来是核心部分——core/agent.py。这里实现了 Loop Engineering 的核心循环先分类工单意图根据意图检索知识库生成回复评估回复如果不通过带着评估意见重新生成超过最大循环次数后转人工。# 文件路径core/agent.py import re from core.llm import chat from core.evaluator import hard_evaluate, model_evaluate MAX_LOOP_COUNT 3 def load_knowledge_base(filepath: str) - str: with open(filepath, r, encodingutf-8) as f: return f.read() def classify_ticket(user_input: str) - str: 对工单进行分类返回分类标签。 system_prompt 你是工单分类器。请将用户问题分类为以下类别之一 - 物流查询涉及发货、物流、快递、收货时间 - 退款售后涉及退款、退货、售后、发票 - 商品咨询涉及商品信息、库存、规格 - 其他 只输出分类标签不要输出其他内容。 .strip() label chat(system_prompt, user_input, temperature0.0).strip() return label def retrieve_knowledge(query: str, knowledge_base: str) - str: 简易知识检索。真实系统可替换为向量数据库召回。 这里我们按关键词做简单的段落筛选演示 RAG 的反馈闭环。 sections knowledge_base.strip().split(\n) matched [] for section in sections: keywords re.findall(r【(.*?)】, section) if not keywords: continue tag keywords[0] # 简单关键词映射 mapping { 退款政策: [退款, 退货], 发货时效: [发货, 物流, 快递], 物流查询: [物流, 快递, 发货], 发票开具: [发票, 报销], 售后入口: [售后, 退款, 退货], } tag_keywords mapping.get(tag, []) if any(kw in query for kw in tag_keywords): matched.append(section) if matched: return \n.join(matched) return 未找到相关知识点请如实告知用户需要人工进一步确认。 def generate_reply(user_input: str, label: str, knowledge: str, feedback: str ) - str: 生成回复。如果 feedback 不为空则带着反馈意见重新生成。 system_prompt 你是一位专业的电商客服。请根据用户问题、工单分类和参考资料生成一段友好、准确、完整的回复。 要求 1. 只使用参考资料中的信息不要编造。 2. 如果参考资料不足请明确说“需要人工进一步确认”。 3. 回复开头需要标注“根据我查到的信息”或“根据知识库”。 4. 回复控制在 100 字以内。 {feedback_section} .strip() feedback_section if feedback: feedback_section f\n【上一次回答的问题】\n{feedback}\n请针对上述问题重新生成回复避免再犯同样的错误。 system_prompt system_prompt.format(feedback_sectionfeedback_section) user_prompt f 【用户问题】 {user_input} 【工单分类】 {label} 【参考资料】 {knowledge} .strip() return chat(system_prompt, user_prompt, temperature0.4) def process_ticket(ticket_content: str, knowledge_base: str) - dict: 处理单个工单执行 Loop Engineering 主流程。 # 1. 感知与决策 label classify_ticket(ticket_content) print(f[1] 工单分类结果{label}) # 2. 检索知识 knowledge retrieve_knowledge(ticket_content, knowledge_base) print(f[2] 召回知识片段\n{knowledge}\n) # 3. 生成 评估 反思循环 reply feedback history [] for loop_index in range(1, MAX_LOOP_COUNT 1): print(f[3] 第 {loop_index} 轮生成...) # 生成 reply generate_reply(ticket_content, label, knowledge, feedback) print(f 生成回复{reply}) # 硬评估 hard_result hard_evaluate(reply, ticket_content) print(f 硬评估结果{hard_result}) if not hard_result[passed]: feedback ; .join(hard_result[issues]) history.append({loop: loop_index, reply: reply, evaluator: hard, issues: hard_result[issues]}) continue # 软评估 model_result model_evaluate(reply, ticket_content, knowledge) print(f 模型评估结果{model_result}) if not model_result[passed]: issues model_result.get(issues, []) feedback ; .join(issues) history.append({loop: loop_index, reply: reply, evaluator: model, issues: issues}) continue # 评估通过退出循环 history.append({loop: loop_index, reply: reply, evaluator: pass, issues: []}) return { ticket_content: ticket_content, label: label, final_reply: reply, history: history, status: solved, } # 4. 超过循环次数转人工兜底 return { ticket_content: ticket_content, label: label, final_reply: 抱歉AI 暂时无法准确处理您的问题已为您转接人工客服请稍候。, history: history, status: escalated, }这里的代码结构比较清晰循环内部先执行硬评估再执行模型评估。硬评估失败时直接进入下一轮硬评估通过但模型评估不通过时带着反馈意见重新生成。这样既控制了成本不一定每轮都调用大模型评审又保证了最终输出的质量底线。4.6 编写主程序入口最后编写main.py对测试工单进行批量处理# 文件路径main.py import csv from core.agent import process_ticket, load_knowledge_base def main(): knowledge_base load_knowledge_base(data/knowledge_base.txt) with open(data/tickets.csv, r, encodingutf-8) as f: reader csv.DictReader(f) tickets list(reader) for ticket in tickets: print( * 60) print(f工单 ID{ticket[ticket_id]}) print(f用户问题{ticket[user_input]}) result process_ticket(ticket[user_input], knowledge_base) print(\n最终回复, result[final_reply]) print(处理状态, result[status]) print( * 60 \n) if __name__ __main__: main()4.7 运行与验证在项目根目录执行python main.py预期输出效果如下实际内容受模型影响可能有差异 工单 IDT1001 用户问题我的订单已经付款三天了还没有发货麻烦帮我查一下 [1] 工单分类结果物流查询 [2] 召回知识片段 【发货时效】常规商品在下单后 48 小时内发货预售商品以商品详情页标注时间为准。 【物流查询】物流信息一般在发货后 24-48 小时内更新如果超过 48 小时没有更新可能是物流公司揽收延迟。 [3] 第 1 轮生成... 生成回复根据我查到的信息常规商品在下单后 48 小时内发货您的订单已付款三天建议您先查看物流信息如果超过 48 小时没有更新可能是物流公司揽收延迟。 硬评估结果{passed: True, issues: []} 模型评估结果{passed: True, score: 90, issues: []} 最终回复根据我查到的信息常规商品在下单后 48 小时内发货您的订单已付款三天建议您先查看物流信息如果超过 48 小时没有更新可能是物流公司揽收延迟。 处理状态solved 至此一个带反馈闭环的工单问答引擎就跑通了。它可以自动分类、检索知识、生成回复并且在回复质量不达标时进行自我反思和重新生成。这就是 Loop Engineering 在 AI 大模型应用中最直白的落地形态。5. 常见问题与排查思路在实际运行和二次开发中你可能会遇到下面这些问题。我整理了一份排查清单方便你按图索骥。问题现象常见原因解决思路AuthenticationErrorAPI Key 错误或未正确加载检查.env文件是否被正确读取确认环境变量名一致模型返回空字符串上下文过长或温度过低导致输出异常尝试提高 temperature检查 system prompt 是否冲突评估模型输出不是合法 JSON模型返回了 Markdown 代码块或额外说明文字增加 JSON 提取逻辑使用json.loads前先清理代码块标记硬评估总是提示“未标注信息来源”规则设置过严根据业务需要放宽关键字匹配或改用模型评估判断信息来源循环次数耗尽全部转人工生成模型始终无法满足评估标准检查知识库是否覆盖用户问题、评估标准是否合理、模型是否过弱成本过高每轮都调用模型评估优先使用硬评估过滤明显不合格结果再对疑似结果调用模型评估前置import失败虚拟环境未激活或依赖未安装执行pip install -r requirements.txt确认当前解释器环境这里特别想强调“反馈信息质量”的问题。在 Loop 中评估者给出的反馈越具体反思重写的效果就越好。如果你只是让评估器输出“回答质量差”这种笼统信息模型大概率不知道该怎么改但如果你说“回答缺少订单号且未说明物流更新延迟的可能原因”模型下一轮生成的精度就会明显提升。这也是 Reflection 模式能起作用的关键。6. 最佳实践与工程建议6.1 评估规则要分层次设计生产环境不要只用一个大模型评估所有内容。更好的做法是三层漏斗规则层零成本检查字段是否缺失、格式是否合法、是否包含禁用词模型层有成本判断语义是否准确、逻辑是否自洽、语气是否合适人工抽检层高成本定期抽检线上样本反向优化前两层规则和 Prompt。这样可以在质量和成本之间找到平衡点。像我们的 Demo 中实际上已经使用了规则层和模型层只是规则层还比较简单。6.2 循环必须有最大次数和退路没有边界的 Loop 是灾难。一定要设置最大循环次数并且定义清楚“循环失败后怎么办”。常见的策略包括转人工客服返回一个默认的安全回复切换到更小的模型跑一次简单模式记录日志进入异步人工 review 队列。在设计上这是为了让系统始终具备“优雅降级”能力而不是无限消耗 token。6.3 日志记录是 Loop 的燃料如果你不做数据积累Loop Engineering 就只是在“原地兜圈”。生产项目中应该把每一轮循环的输入、输出、评估结果、反馈意见、最终处置方式全部记录到结构化日志里。后续可以用这些数据做几件事分析高频失败场景定向补充知识库收集 Few-shot 示例优化 System Prompt构造微调训练集对模型做针对性优化反推评估标准是否合理。日志格式建议至少包含以下字段{ ticket_id: T1001, loop_index: 1, model: gpt-4o-mini, input: 用户原始问题, output: 模型生成回复, evaluator: model, passed: false, issues: [缺少订单号], latency_ms: 1234, timestamp: 2026-01-01T10:00:00Z }6.4 注意安全边界与权限控制当 Loop Engineering 系统涉及工具调用、数据库访问或第三方 API 操作时必须在代码中做好边界控制工具执行必须限制在白名单动作内所有外部操作前做参数校验涉及敏感数据时不把原始数据写入 Prompt如果 Agent 需要操作生产环境必须遵循最小权限原则并在测试环境充分验证。AI 应用具备“自主执行能力”之后安全边界就不再只是代码规范而是系统设计的核心约束。6.5 评估模型和生成模型可以分离在成本允许的前提下建议使用不同模型分别承担生成和评估任务。例如生成用中档模型评估用更强的模型。原因是如果同一个模型既生成又评估它可能“对自己的错误不够敏感”而更强的评估模型往往能发现更细微的问题。当然这个策略需要结合你的实际成本和模型能力来决定。7. 总结与学习路线这篇文章从概念到代码完整演示了 Loop Engineering 在大模型应用开发中的落地方式。我们通过一个工单问答引擎实现了“分类—检索—生成—评估—反思—再生成”的闭环流程并且加入了转人工兜底机制。这套思路同样适用于对话机器人、RAG 问答系统、AI Agent、自动化报表生成等场景。如果你想继续深入我建议按下面的路线学习学透 Prompt EngineeringLoop 中“生成”阶段的质量上限很大程度上取决于 Prompt 设计能力。掌握 RAG 全链路把简易关键词检索替换为向量库召回研究文档切分、Embedding 模型选择、重排序等问题。研究 Agent 工具调用让模型能够调用真实 API 并处理返回值这是复杂 Loop 的基础。实践评估体系用开源框架搭建离线评测集把 Loop 从“在线运行时闭环”升级为“离线数据闭环”。关注模型微调当循环次数达到瓶颈时微调往往能从根本上提升模型对特定任务的适配度。最后提醒一句Loop Engineering 的核心不是“循环”这个动作本身而是“每次循环都能让系统变得更好一点点”。如果你在设计系统时始终把评估和反馈放在和生成同等重要的位置你的大模型应用会稳定很多。建议你现在就拿一个真实业务场景试着把本文的代码改造成你的最小可行版本然后观察日志里那些反复失败的样本从它们开始优化。如果这篇文章对你有帮助欢迎收藏备用也欢迎在评论区聊聊你在大模型应用开发中遇到的“循环”问题。下一篇文章我计划深入写一写“如何搭建一套大模型离线评估集”如果你感兴趣可以先关注起来。