从“能跑通”到“能自愈”智能体开发真正的分水岭在哪最近和不少做 Agent 项目的团队交流大家普遍有一个同感做一个能在演示环境里跑通的智能体很容易做一个能在生产环境里稳定工作的智能体很难。难的不是调用大模型也不是写几个工具函数而是让系统在没有人盯着的情况下持续输出正确结果并在出错时自动修正。很多人把问题归结为“模型不够聪明”于是不断换更强的底座模型。但更常见的原因藏在工程侧你的 Agent 本质上是“一次性问答脚本”而不是一个“自主驱动的闭环系统”。它没有对自身输出的评价能力没有失败后的重试策略也没有把业务反馈回流到下一轮决策的通道。换句话说它缺少的是一个贯穿感知、决策、行动、反馈的循环回路。这正是我想在这篇文章里展开的核心概念循环工程。它不是某个工具的某个功能而是智能体从 demo 走向生产时需要重新建立的工程思维方式。我会先用通俗的语言讲清楚循环工程和闭环系统的设计要点再给出一套可直接运行的 Python 示例演示一个带自动评估和自动修正的 Agent 闭环流程最后补充常见坑位和生产落地的工程建议。1. 这篇文章真正要解决的问题如果用一个问题概括这篇文章的主题那就是为什么很多 Agent 只跑一次效果好跑一百次就崩以及怎么把“稳定性”设计进系统里。传统开发里我们习惯用“输入 → 处理 → 输出”的线性模型思考问题。大多数 Agent demo 也是这样用户提问LLM 推理工具返回结果LLM 汇总输出。整条链路没有反馈回路系统无法判断自己“做得好不好”更无法在下一次做得更好。这会导致三类典型问题错误会被放大而不是被修正。LLM 第一次调用生成了一段不够准确的 SQL系统直接把 SQL 丢给数据库去执行报错了也不重试或者重试时用同一个错误上下文继续生成大概率还是同样错。没有量化评估手段。你只能说“感觉这个 Agent 还行”但说不清它在 1000 条测试数据上的准确率、召回率、失败率和平均修正次数。没有度量就没有优化方向。业务反馈无法回流。Agent 在线上建议了错误的库存调拨业务人员手工纠正之后系统毫无感知明天还会犯同样的错。循环工程要解决的就是把单向的“输入 → 输出”变成双向的“输出 → 评估 → 反馈 → 再输出”。这听起来像控制论里的老话题但放到大模型驱动的智能体时代它有了新的实现方式和新的工程难点。这篇文章最适合三类读者阅读正在做 Agent 应用开发但发现系统在真实场景中不稳定的人想从可视化平台如 Dify、Coze 等转向代码级控制或想理解平台内部闭环原理的人负责 AI 应用架构设计需要为团队制定 Agent 工程规范的工程师。读完这篇文章你会得到一套判断标准和一套可落地的代码骨架而不是一堆浮在表面的趋势名词。2. 循环工程概念、本质与定位2.1 什么是循环工程循环工程的英文直译是 Iterative Engineering或者更贴近本文语境的说法是 Loop Engineering。它强调的不是“写一个循环”而是围绕智能体生命周期建立持续反馈与自我修正机制的设计方法。和传统软件工程相比循环工程的核心差异在于传统软件的行为是可预期的代码写死逻辑测试断言输入输出而智能体的行为是概率性的同样的提示词可能产出不完全一样的结果同一个工具可能在不同语境下被调用得对错不一。因此我们不能再只依赖“上线前测试”必须在运行时建立持续校准机制。可以把智能体想象成一个刚入职的员工。传统软件是一台设定好程序的生产机器而智能体更像一个需要带教、反馈和复盘的新人。你要给他工作目标观察他的产出指出问题再让他重做。循环工程就是为智能体设计这套“带教机制”。2.2 循环工程、提示词工程与 Agent 工程的区别很多人容易把循环工程和提示词工程混为一谈这里用一个表格做区分工程类型关注核心主要手段典型产出提示词工程让模型更准确地理解指令编写和优化提示词更好的单次输出Agent 工程让模型学会调用工具、拆解任务工具注册、任务编排、上下文管理能完成多步任务的智能体循环工程让智能体具备自我评估和自我修正能力评估器、反馈通道、重试策略、记忆更新稳定、可演进的生产级智能体提示词工程解决的是“把话说清楚”Agent 工程解决的是“把任务拆明白”循环工程解决的是“把系统做稳定”。三者层层递进缺一不可。很多项目在提示词工程上下足了功夫也顺利接上了工具调用却依然不稳定大概率是缺了循环工程这一层。2.3 为什么现在才强调循环工程过去两轮 AI 浪潮里基于规则的客服机器人也有反馈机制比如用户点了“不满意”就转人工。但那时规则是人工编写的语义理解能力弱反馈只能做到按钮级别。大模型出现后智能体拥有了开放式的语言理解和生成能力工具调用的边界被大大扩展——它可以写代码、查数据库、操作 API、生成文档。这意味着一个出错动作的影响范围远大于传统规则机器人。与此同时模型的概率性输出特征没有消失。能力越强可以做错的事就越多。所以不是循环工程突然出现了而是智能体的能力边界扩大之后没有循环工程的项目开始大面积失控循环工程才被迫成为显性话题。市面上主流的智能体开发平台无论是开源的 Dify还是国内开发者常用的 Coze扣子、AgentScope 等本质上都在帮开发者把“模型调用、工具编排、流程控制”这层做简单。但平台越简单越容易让人忽略底层其实仍需要“评估与反馈”的设计。如果不在工作流中显式加入评测和纠错节点可视化拖拽出来的 Agent 同样会在复杂场景里翻车。3. 自主驱动闭环系统的核心模块理解了循环工程的概念下面把“自主驱动的 AI 闭环系统”拆开看它到底由哪些模块组成。一个经典的闭环智能体通常包含四个核心模块3.1 状态感知模块系统要能感知当前环境的状态包括用户输入、工具返回结果、外部系统状态、历史对话记录等。没有感知后面的一切决策都是盲目的。实际工程中状态感知往往不是简单地把全部上下文塞进提示词而是要做筛选和结构化。比如一个客服智能体需要从用户消息中提取意图、槽位、情绪倾向一个数据分析智能体需要了解当前数据库里有哪些表、表结构是什么、用户权限到什么级别。这里容易被忽视的是工具返回状态的感知。很多 Agent 调用外部 API 后完全不检查 HTTP 状态码和返回体中的错误信息直接把结果扔给 LLM。结果就是 LLM 一本正经地根据错误页面“编”出一个答案。状态感知模块必须把工具调用的成功、失败、超时、部分成功等状态显式地暴露给决策模块。3.2 决策与行动模块这是 Agent 的主体负责根据当前状态决定下一步动作。它可能是单次 LLM 调用也可能是一个多轮任务规划器。在多智能体场景中还涉及任务的分配与协作。决策模块的设计重点是“动作空间的定义”。所谓动作空间就是系统允许智能体执行的所有原子操作比如生成回复、执行 SQL、调用外部 API、读取本地文件等。动作空间定义得越清晰模型越不容易行为越界。3.3 自动评估模块评估模块是闭环系统和普通 Agent 的最大区别。它在每次行动完成后对行动结果进行量化打分并生成修正建议。评估器的实现方式有很多种规则评估器检查输出是否包含某个关键字段、是否超过长度限制、是否通过正则校验。适合有客观标准的结果如 JSON 格式是否正确。模型评估器用一个 LLM 扮演评估者根据评分标准给输出打分。适合主观质量评估如文案是否符合品牌语气。工具评估器通过实际执行来验证结果。比如生成的 SQL 是否能在测试库跑通生成的代码是否通过单测生成的回答是否能被检索到证据。人工评估器把结果推送给人类审核人工裁决。适合高风险场景不追求全自动闭环。3.4 反馈演进模块评估产生分数和修正意见之后系统需要把这些信号回流到决策模块或记忆模块。修正意见用于当前这一轮的自我纠错而长期信号比如某个任务反复失败、某类用户的投诉率升高则需要沉淀到长时记忆或离线训练数据中让 Agent 在未来的会话中也表现得更好。反馈演进是很多项目做得最薄弱的一环。大家愿意花钱做实时反馈却很少沉淀下来形成评测集和样例库。而恰恰是这些被沉淀下来的数据才是智能体持续进化的燃料。4. 自主驱动闭环系统的架构设计与技术选型下面从架构层面看一个可实现的闭环系统。我不会绑定某个具体平台而是给出一个通用分层你在 Dify、Coze 上配置 Agent或者从零用代码写 Agent都可以按这个层次来思考。4.1 分层架构一个闭环智能体系统我习惯分为五层接入层负责接收用户请求处理对话上下文做基础的输入校验和敏感信息过滤。决策层调用 LLM 进行任务规划决定调用哪个工具、生成什么内容。行动层实际执行工具调用包括函数插件、API 调用、数据库操作、代码执行。评估层对行动结果进行评估输出质量分数与修正建议。记忆层负责短期上下文、长期记忆、向量检索库的读写与更新。闭环的关键在于评估层的输出要能返回给决策层驱动下一轮决策。如果评估层只输出一个分数却没有任何动作那不叫闭环只叫“监控”。4.2 技术选型的几个关键选择工作流编排纯代码Python/TypeScript适合复杂逻辑和高定制需求可视化平台适合快速验证和轻量业务。两者并不冲突很多团队先用可视化平台搭原型再把核心链路迁移到代码。记忆存储短上下文直接拼进提示词长期记忆通常用向量数据库保存每次检索相关片段注入上下文。选择向量库时除了检索质量还要关注权限隔离和元数据过滤能力。评估器实现规则优先模型兜底。能用规则判断的就不要用模型成本和稳定性都更优。异步与重试闭环系统天然需要重试机制。要注意设置最大重试次数和超时时间避免在错误路径上无限循环。4.3 单 Agent 与多 Agent 的闭环差异单 Agent 闭环相对简单一个 LLM 承担决策一个评估器校验输出循环往复直到满意或多轮失败。多 Agent 场景下闭环逻辑更复杂。每个子 Agent 有自己的输入输出子 Agent 之间可能有依赖关系。此时评估层既要评估每个子 Agent 的产出还要评估整体任务的完成度。A2AAgent to Agent协议、消息队列等基础设施会变得更加重要。不过我建议刚开始做闭环的团队不要直接上多 Agent先在一个单 Agent 上把闭环跑通再逐步扩展。5. 完整示例一个带自动评估与自我修正的闭环智能体下面进入实践环节。我会用一个最小但完整的 Python 示例演示循环工程的核心逻辑。场景设计假设我们要做一个“周报生成智能体”输入几条工作内容智能体输出一段结构化周报。这个场景不复杂但足以展示闭环的四个模块。为方便读者直接运行示例中不依赖真实大模型 API而是用模拟 LLM 和模拟评估器。如果你有 OpenAI 兼容的模型 API可以把对应函数替换为真实调用。5.1 整体结构loop_engineering_demo/ ├── main.py # 主流程闭环控制逻辑 ├── evaluator.py # 评估器 ├── llm.py # LLM 接口默认 Mock 实现 └── memory.py # 简单记忆存储5.2 模拟 LLM 接口# 文件路径loop_engineering_demo/llm.py class LLMClient: 统一的 LLM 调用接口。 真实场景中把 generate 方法替换为对 OpenAI / 国内大模型 API 的 HTTP 调用即可。 def __init__(self, max_calls: int 100): self.max_calls max_calls self.call_count 0 def generate(self, system_prompt: str, user_prompt: str) - str: 模拟模型生成。第一次生成缺少关键指标第二次开始会参考评估反馈。 真实接入时这里应调用模型 API response openai.ChatCompletion.create( modelyour-model-name, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], ) return response[choices][0][message][content] self.call_count 1 if 看到反馈 in user_prompt: # 模拟模型根据反馈修正补充缺少的指标 return ( 周报\n 1. 数据看板开发完成用户活跃度看板包括 DAU 趋势、留存漏斗。\n 2. 智能体评估模块完成自动评分器准确率达到 92%。\n 关键指标本周迭代完成度 85%线上问题 0 个。\n ) # 第一次生成缺少关键指标 return ( 周报\n 1. 数据看板开发完成用户活跃度看板包括 DAU 趋势、留存漏斗。\n 2. 智能体评估模块完成自动评分器准确率达到 92%。\n )这个 Mock 实现的关键是第一次生成不包含“关键指标”评估器会判定不合格并把修正建议拼入下一次调用的 user_prompt 中第二次调用看到反馈后生成了包含关键指标的完整周报。这样闭环流程就能演示出来。5.3 评估器# 文件路径loop_engineering_demo/evaluator.py from typing import Tuple class Evaluator: 评估器检查输出质量返回是否通过、分数、修正建议。 这是闭环系统里最重要的裁判角色。 REQUIRED_KEYWORDS [关键指标, 周报] MAX_LINES 8 def evaluate(self, output: str) - Tuple[bool, float, str]: score 100.0 suggestions [] # 规则1必须包含标题“周报” if 周报 not in output: score - 30 suggestions.append(请以“周报”作为标题。) # 规则2必须包含关键指标 if 关键指标 not in output: score - 40 suggestions.append(请补充本周关键指标例如迭代完成度、线上问题数、性能数据。) # 规则3行数不能过长 lines output.strip().splitlines() if len(lines) self.MAX_LINES: score - 10 suggestions.append(f请精简内容控制在 {self.MAX_LINES} 行以内。) passed score 80 correction ; .join(suggestions) if suggestions else return passed, score, correction评估器用了最简单的规则逻辑包含三个硬性检查项。真实场景中这里的规则可以换成模型评估器让 LLM 按 5 个维度打分并输出 json 格式的修正建议。5.4 闭环主流程# 文件路径loop_engineering_demo/main.py from evaluator import Evaluator from llm import LLMClient def run_closed_loop(max_attempts: int 3): 闭环主流程 1. 根据原始输入生成内容 2. 评估器打分 3. 不达标则把修正建议反馈给模型重新生成 4. 达到最大尝试次数后停止返回最终结果 client LLMClient() evaluator Evaluator() system_prompt 你是一名研发团队负责人请根据工作内容生成一段简洁的周报。 user_prompt ( 本周完成的工作有\n - 数据看板开发\n - 智能体评估模块\n ) attempts [] final_output final_passed False for attempt in range(1, max_attempts 1): print(f 第 {attempt} 次生成 ) output client.generate(system_prompt, user_prompt) passed, score, correction evaluator.evaluate(output) record { attempt: attempt, output: output, score: score, passed: passed, correction: correction, } attempts.append(record) print(f输出内容\n{output}) print(f评估得分{score}) print(f是否通过{passed}) if correction: print(f修正建议{correction}) if passed: final_output output final_passed True print(评估通过闭环结束。) break # 不通过把修正建议拼入下一轮生成指令形成闭环 user_prompt ( user_prompt f\n\n上一版本的评估结果得分 {score}修正建议{correction}\n 看到反馈后请重新生成一版周报。 ) else: final_output attempts[-1][output] final_passed False print(f已尝试 {max_attempts} 次仍未通过结束闭环。) return { final_output: final_output, final_passed: final_passed, attempts: attempts, model_call_count: client.call_count, } if __name__ __main__: result run_closed_loop(max_attempts3) print(\n########## 闭环运行摘要 ##########) print(f模型总调用次数{result[model_call_count]}) print(f最终是否通过评估{result[final_passed]}) for record in result[attempts]: print(f第 {record[attempt]} 次得分{record[score]})5.5 真实模型接入片段上面的 Mock 实现用于本地演示逻辑。真实场景中你需要把LLMClient.generate替换为模型 API 调用。下面是一个兼容 OpenAI 接口的调用示例注意这里只是片段完整代码属于你的项目# 文件路径你的项目中替换 llm.py 的 generate 方法 import os import openai client openai.OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), # 例如国内模型服务商提供的 OpenAI 兼容地址 ) def generate(self, system_prompt: str, user_prompt: str) - str: resp client.chat.completions.create( modelos.getenv(LLM_MODEL_NAME), messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature0.7, ) return resp.choices[0].message.content6. 运行结果与效果验证6.1 运行方式在loop_engineering_demo目录下执行python main.py6.2 预期输出正常情况下你会看到类似下面的日志 第 1 次生成 输出内容 周报 1. 数据看板开发完成用户活跃度看板包括 DAU 趋势、留存漏斗。 2. 智能体评估模块完成自动评分器准确率达到 92%。 评估得分60.0 是否通过False 修正建议请补充本周关键指标例如迭代完成度、线上问题数、性能数据。 第 2 次生成 输出内容 周报 1. 数据看板开发完成用户活跃度看板包括 DAU 趋势、留存漏斗。 2. 智能体评估模块完成自动评分器准确率达到 92%。 关键指标本周迭代完成度 85%线上问题 0 个。 评估得分100.0 是否通过True 评估通过闭环结束。 ########## 闭环运行摘要 ########## 模型总调用次数2 最终是否通过评估True 第 1 次得分60.0 第 2 次得分100.06.3 如何判断闭环生效判断闭环系统是否真正工作有三个标准第一次失败后是否产生了有效的修正指令。修正指令必须具体、可执行而不是“请优化一下”。示例中“请补充本周关键指标”是具体的第二次生成的输出是否解决了修正指令提出的问题。如果模型看到反馈后仍输出同样内容说明反馈链路断了运行摘要里的轨迹信息是否完整。每轮尝试的得分、修正建议、最终结果都应被记录方便事后分析。如果你把示例中evaluator.py里的score 80改成score 100并且把max_attempts调成 1会看到闭环在第一次失败后直接停止。这个对比能帮你直观理解“重试次数”和“评估门槛”对闭环效果的影响。7. 常见问题与排查方法闭环系统虽然原理不复杂但在实际项目中踩坑的点非常多。下面列几个最典型的问题。问题现象可能原因排查方式解决方案模型反复重试却一直在同一个问题上失败修正建议不够具体或评估器在钻规则空子打印每一轮的修正建议看是否每次都一样细化修正建议增加示例性反馈如果同一问题出现 2 次以上考虑切换到人工介入评估器给模型打分很高但人工看质量很差评估器规则过于简单或模型评估器被“自圆其说”带偏随机抽 20 条高分输出做人工复核统计偏差增加规则检查项模型评估器采用独立提示词并要求先引用原文再打分工具调用报错但 Agent 没感知继续胡说工具异常信息没有结构化回传给 LLM查看工具调用日志确认错误信息是否进入 prompts在工具调用层捕获异常统一改写为“工具失败 原因摘要 可选重试”闭环日志太长根本无法定位问题每轮都把完整上下文塞给模型日志没有分层检查日志记录结构按 attempt_id 记录输入、输出、评估结果输出关键指标用结构化字段而非纯文本重试次数多导致成本飙升没有控制最大重试次数且每次重试都全量调用大模型查看模型调用计费和调用日志设置max_attempts对简单校验流程使用规则评估器不必每次都调大模型系统在评估器认为成功后仍然产生劣质业务结果评估器只评“文本质量”没有评“业务效果”检查线上指标与评估分数的相关性引入业务结果反馈例如用户点击率、人工纠错率、工单是否解决这里要特别强调一个问题评估器和模型用同一个大模型容易产生“自己评自己”的偏差。如果主模型和评估模型是同一个主模型生成的错误会被评估模型以同样的知识偏见放过。更稳妥的做法是使用不同的模型做评估或者使用“规则 模型”混合评估器。8. 最佳实践与工程建议8.1 先定义成功标准再写 Agent 逻辑很多团队先写代码后补评估这是本末倒置。正确顺序是明确 Agent 在什么场景下算是“完成得好”把好结果量化成可检查的指标再开始写 Agent 的决策逻辑。以周报生成为例好结果的定义是包含本周工作、包含关键指标、不超长、语气简洁。把这个定义翻译成规则就是示例中evaluator.py里的三个检查项。8.2 规则优先模型兜底能用规则判断的不要用模型。规则的优点是稳定、便宜、可解释。只有当规则无法覆盖开放性问题时才引入模型评估器。比如 SQL 是否正确直接去测试库执行最可靠回答是否专业才需要模型评估。8.3 设置控制参数避免闭环失控自主驱动不等于无限循环。生产环境中必须设置硬性边界# 文件路径config.yaml loop: max_attempts: 3 # 最大生成尝试次数 timeout_seconds: 60 # 单次循环超时 escalation_after_fail: true # 失败后是否转人工这样即使模型一直不达标系统也会在规定次数后停止并把任务转交给人工处理而不是无限烧钱。8.4 为每一步留下溯源日志闭环系统的可观测性比传统系统更重要因为每一次输出都叠加了模型的不确定性。建议为每轮尝试记录以下字段attempt_id、task_idprompt 版本号模型名称和参数生成内容摘要评估器类型、评估分数、修正建议循环终止原因通过、超时或达到最大次数记录这些日志不仅用于排错也是后续建设评测集的素材。8.5 沉淀评测集与回归测试和传统软件有单元测试一样智能体也需要回归测试。每次修复一个 bug都应该往评测集里加入一条对应的用例。评测集应该包含正常输入happy path边界输入空输入、超长输入、多语言混合对抗输入诱导性提示、越权请求历史失败用例每次修改 Agent 逻辑后跑一遍评测集对比综合通过率和平均修正次数以此量化“改进是否带来了真正的提升”。8.6 关于可视化平台与代码实现的取舍Dify、Coze 等平台可以帮助你快速搭建带工具调用和工作流节点的 Agent它们内置了一些循环能力比如条件分支、重试节点。对于验证业务逻辑平台足够高效。但平台上对评估器的定制能力、对循环控制细粒度的掌控通常不如代码灵活。我的建议是分阶段走先用可视化平台把业务闭环跑通验证“循环设计是否合理”再根据业务复杂度决定是否迁移到代码实现。关键是无论用什么平台你都要清楚自己的评估器是什么、反馈信号是什么、终止条件是什么。这些是平台给不了你的。8.7 安全与权限边界闭环系统拥有“自主行动”和“反复重试”的能力这意味着它造成错误影响的可能性比普通 Agent 更大。生产环境必须遵循最小权限原则数据库账号只授予所需表的 SELECT 权限必要时单独为 Agent 建立只读账号涉及写操作、删除操作、资金操作等高风险行为必须设置为人工审批后再执行工具调用全部要记录操作人、操作内容、时间戳便于审计追踪。如果 Agent 的闭环过程中包含数据库写操作强烈建议先在测试环境验证、配置自动备份与回滚方案再考虑灰度上线。不要一开始就让生产库暴露在自主循环的决策空间里。9. 总结与后续学习方向这篇文章想传达的核心判断是智能体的生产级能力不只看模型有多聪明更看系统有没有建立“输出 → 评估 → 反馈 → 调整”的循环回路。你可以将其视为“循环工程”。它和提示词工程、Agent 工程不是替代关系而是在它们之上补上了“稳定性和演进能力”这一层。值得记住的三个要点闭环的设计从评估器开始而不是从模型调用开始。先想清楚什么算“好”再讨论怎么生成闭环必须设置边界。最大重试次数、超时、人工介入、权限隔离是生产级系统的标配闭环产生的数据要沉淀下来它们是评测集和记忆系统的源头。下一步你可以沿着这几个方向继续深入把示例中的规则评估器替换成模型评估器实现一个基于评分标准的多维度打分器在闭环流程中加入向量记忆让 Agent 在做同类任务时参考历史成功案例尝试多智能体协作使用 A2A 协议或消息队列组织多个子 Agent并为整体任务增加评估层建设一个智能体评测集把线上失败样例持续回流形成 Agent 的回归测试体系。如果这篇文章对你有所启发建议先花一晚上把这个最小闭环示例跑通再修改评估规则换成你自己的业务场景。亲手调一遍理解会远比读文章深刻。技术上真正重要的事往往不是某个炫酷模型而是把系统做得稳定、可观测、可演进的那部分工程。