很多 Agent 出问题并不是模型太笨。更常见的情况是模型外面的那套系统太薄了。任务一开始就说不清楚。工具调用失败了Agent 没有停下来判断原因只是换个说法继续试。上一轮已经走不通的路径下一轮又绕回去。它忘了刚刚发生过什么也不知道什么样的结果才算交付。最后生成一段看起来挺完整的话就当自己做完了。如果你写过稍微复杂一点的 Agent这种场景应该不陌生。它不是完全不会干活甚至有时表现还不错。但一到真实任务里错误会沿着流程滚下去。哪里错了为什么错下一步该换什么策略系统并没有认真处理。这篇文章想讨论的就是这个问题。要让 Agent 真的变好不能只盯着 Prompt、工具数量或者自主权。Prompt 能改善单轮输出工具能扩展可做的事自主权能减少人工干预但这些都没有自动带来“学习”。Agent 能不能从一次尝试里拿到信号并把这个信号用到下一次决策里才是更底层的工程问题。这个问题可以叫 Loop Engineering中文可以理解成“反馈闭环工程”。它关心的不是模型某一轮回答有多漂亮而是系统在失败、偏差、不确定、工具异常、人工修正之后怎么观察、评估、记录、调整、重试、升级或者停止。我更愿意把它看成 Agent 工程里最容易被低估的一层。一、先把“自我改进”说清楚很多人听到 self-improving agent会想到一个能自动训练自己、自动升级、越跑越聪明的系统。这个想象很有吸引力但放到大多数工程场景里反而容易误导人。真实产品里的“自我改进”通常没有那么神秘。基座模型不一定变参数不一定更新甚至 Prompt 也可以暂时不改。变化发生在模型外面系统开始利用上一轮留下的反馈信号让下一轮少犯同样的错。这些信号可能很普通重试时补上了更准确的上下文evaluator 指出输出没有满足要求系统记住了上一轮失败原因工具调用参数被纠正输出结果被打分reviewer 给了修改意见规则或约束被更新成功路径被保存下来下次复用所以一个更实用的定义是一个自我改进 Agent是一个能够使用历史尝试中的反馈信号让下一次行动更接近目标的系统。这里有个分界线很重要。自我改进通常不是 model evolution而是 loop evolution。模型本身可以没变。变的是它周围那套流程怎么判断成败怎么给失败分类怎么选择下一步怎么保存有用经验什么时候停什么时候让人接管。这听起来没有“模型自己进化”那么炫但更接近我们现在能做、也应该先做的东西。二、很多 Agent 只是在继续不是在变好现在不少 Agent 系统流程大概是这样读取任务思考调用工具继续下一步这个循环能让系统动起来但它不一定能让系统变好。问题通常不在“能不能继续”而在继续之前有没有吸收上一轮的结果。很多系统缺少这些东西明确的成功标准失败分类带状态的重试对失败路径的记忆不同尝试之间的比较输出评估升级给人的规则少了这些Agent 看起来在自动化其实只是一直往前滚。Raw iteration 是“再来一次”。Intelligent iteration 是“我知道上一次为什么不够好所以这一次换一种走法”。差别就在这里。一次失败没有改变下一次动作一次人工纠正没有进入记忆一次工具错误没有改变工具策略。这样的系统就算跑十轮也只是把 token 消耗得更快。Loop Engineering 处理的就是这个断点上一轮发生了什么怎样影响下一轮。三、Loop Engineering 属于架构层Prompt 告诉模型这一轮要做什么。Loop Engineering 处理的是另一件事模型试过之后系统怎么办。这两个问题不在同一层。Prompt 是单轮指令Loop 是多轮行为结构。一个好的 Prompt 可能让某一轮输出更稳一个好的 Loop 才能让连续尝试有方向。真正做系统时我们要回答的问题会很具体工具调用失败后是马上重试还是先诊断原因什么时候继续用原工具什么时候换工具一个任务最多试几轮哪些信息进入长期记忆哪些只留在当前上下文哪些结果必须自动评估什么情况下不该让 Agent 继续而该让人接手用什么指标判断系统确实比以前好了这些问题很难靠“把 Prompt 写得更有力”解决。它们需要流程、状态、评估、日志和边界。可以先看一个简化版结构。反馈闭环工程在智能体系统中的位置这张图里我最在意的是 evaluator 和 memory。没有 evaluator系统不知道自己做得对不对。没有 memory系统就算知道错了也很难把这个错误变成下一轮策略。很多普通 Agent 只是在 Prompt 和 Tool 之间来回跳。一个做过闭环设计的 Agent会把观察、评估、记忆和修正都放进流程里。四、一个可用闭环长什么样最小可用的 Agent 闭环可以写成这样目标 ↓ 计划 ↓ 行动 ↓ 观察结果 ↓ 评估质量 ↓ 存储信号 ↓ 重试 / 修订 / 升级 / 完成这不是为了画图好看。每一步都有具体工作。观察结果不只是看模型生成了什么。还要看工具返回了什么接口有没有报错测试有没有通过用户有没有拒绝输出有没有满足约束。评估质量是把“产出了东西”和“产出了可用的东西”分开。一个答案看起来完整不代表它准确、合规、可执行也不代表它真的能交付。存储信号不是把所有历史塞回上下文。更好的做法是提取下一轮能用的信息把噪音丢掉。重试、修订、升级、完成也不是同一个动作。缺上下文时去补资料工具用错时修参数风险太高时找人不要把所有失败都交给“再生成一次”。展开后决策路径大概是这样一次失败后智能体如何分流重试判断一个重试有没有意义可以问一个很简单的问题下一轮到底变了什么可能变的是上下文、工具、任务边界、输出格式、验证规则、策略路径也可能是加入了人工输入。如果什么都没变只是又跑一遍那就不是改进。举个很小的例子。代码 Agent 第一次改完后测试失败第二次如果只是让模型“再修一下”意义不大。更像闭环的做法是先读失败日志判断失败属于类型错误、接口签名变化、断言预期不对还是测试环境问题。分类之后下一轮才知道该改代码、改测试、补依赖还是停下来问人。五、五个构建模块要让 Agent 具备自我改进能力至少要有五个模块。名字听起来都不新但很多系统恰好缺的就是这些老实东西。1. 清晰的成功标准系统如果不知道什么叫“好”就没法朝那个方向调整。成功标准可以很具体输出必须符合指定格式答案达到某个正确性阈值结论有来源支撑工具返回指定字段代码通过测试用户或 reviewer 批准任务达到某个业务分数成功标准越具体Agent 越容易修正自己。如果目标只是“写得好一点”“研究一下”“做个可用版本”系统就很难知道下一轮该优化什么。工程上能用 schema 检查就用 schema能跑测试就跑测试能写成字段要求就别只靠模型感觉。2. 评估层评估层用来判断一次尝试是否有效。它可以包含规则检查schema validation单元测试LLM-as-judge检索 grounding 检查业务逻辑校验人工 review不同任务适合不同评估方式。代码 Agent 最自然的 evaluator 是测试、类型检查和 lint。文档抽取 Agent 可以用 schema 和字段完整性。研究 Agent 可以用来源数量、引用质量和证据覆盖率。客服 Agent 可以用政策匹配和风险等级。评估层把“模型生成了一个结果”变成“系统知道这个结果能不能用”。没有这层Agent 就只能凭语气结束任务。它可能把格式错误的 JSON 当成最终输出也可能把没有证据的结论写得很自信。3. 反馈记忆自我改进需要记忆但不是越多越好。把完整对话、完整日志、完整工具输出都塞回上下文听起来省事实际常常把模型带偏。好的 feedback memory 应该短、准、可执行。它可以记录上一轮失败原因上一次工具错误已经证明有效的路径已经证明无效、不要重复的策略用户明确偏好reviewer 给过的修正意见对前几轮尝试的压缩总结原则很简单只保存能帮下一轮做决定的信息。例如上一轮失败检索结果只覆盖博客观点没有找到一手文档。 有效部分问题拆分和术语定义是准确的。 避免重复不要继续泛搜“AI agent loop”结果噪音太大。 下一步优先检索论文、框架文档和开源实现补齐工程示例。这类 memory block 比十几轮原始聊天记录有用得多。4. 策略修正评估失败之后Agent 必须决定下一轮怎么变。可能的动作包括换一个工具缩小任务范围向用户提问重新检索信息从行动模式切到解释模式调整输出格式添加验证规则升级给人这一步才是系统变得 adaptive 的地方。如果 evaluator 只说“失败了”却没有把失败转成可执行的下一步那么评估没有真的进入闭环。一个有用的 evaluator不只是打分还要给 next step。5. 边界和停止条件自我改进不等于放任系统一直跑。没有边界的循环通常只会变贵、变慢、变难控制。它不一定更聪明。至少要提前定义最大重试次数最大成本最大延迟破坏性操作的人工确认低置信度阈值高风险任务升级规则任务放弃条件有边界的闭环比无约束的自主性更有用。如果一个 Agent 不知道什么时候停它还不算可靠。六、反馈信号从哪里来Loop Engineering 里最容易被草草带过的是 feedback signal。信号选错了系统会朝奇怪的方向优化。只奖励“回答更长”它就会越来越啰嗦。只奖励“用户不追问”它可能变得更自信但不一定更准确。只看“工具调用成功率”它可能开始避开必要但复杂的工具。比较稳的反馈来源可以分成四类。1. 确定性信号确定性信号最硬也最适合优先使用。比如测试通过或失败schema 验证通过或失败API 返回 success 或 error输出是否包含必需字段policy rule 是否满足文件是否生成数据库写入是否成功这类信号稳定、便宜、可重复。只要能用就不要先急着上复杂判断。2. 工作流信号工作流信号不一定直接判断答案质量但能反映系统运行状态。比如重试次数工具调用延迟失败发生在哪一步置信度阈值是否被触发人工升级频率某个工具路径是否经常失败某类任务是否总是在同一阶段卡住这些信号更适合做系统调优。它们会告诉你问题可能不在模型输出而在任务拆分、工具选择、检索策略或停止条件。3. 人工信号人工反馈不能被当成临时补丁。它可以是点赞 / 点踩修改后的正确版本draft 被接受还是拒绝reviewer 的批注手动覆盖系统决策的记录用户反复强调的偏好很多团队让人类 review 结果却没有把 review 结果写回系统。这样一来人工反馈只是在救火并没有变成学习材料。如果人总是在改同一个问题而系统从不吸收这件事Agent 就谈不上自我改进。4. 对比信号对比信号来自不同尝试之间的差异。比如A 版本和 B 版本输出质量对比不同检索策略的结果对比不同工具路径的成功率对比多轮运行后的分数变化使用 memory 前后的成功率变化这类信号能帮助系统选择更好的 workflow而不只是选一个更顺眼的答案。比较强的 Agent不会只依赖一种反馈。确定性信号、工作流信号、人工信号和对比信号混在一起闭环才不容易跑偏。这里还有一个容易忽略的点信号本身也要被审查。比如用户点踩不一定说明答案错了可能是语气不合适也可能是用户预期变了。测试失败通常更硬但也可能是测试本身过期。好的闭环不会把所有反馈都当真理它会给不同信号不同权重。七、别只改答案要改流程弱一点的实现会在输出不满意时让模型“再写一版”。更成熟的实现会检查整个流程哪里出了问题。研究 Agent 输出不可靠时不只是让它“更准确地回答”。它应该判断是不是来源不够是不是只有二手材料是不是缺反方证据是不是引用不足是不是应该先补背景再综合代码 Agent 测试没过时也不该只说“修复代码”。它应该读取错误日志判断是类型问题、接口变更、断言失败还是环境问题再做最小修改然后重新跑测试。文档抽取 Agent 字段缺失时不是简单再抽一遍。它应该看缺失字段的位置、判断 OCR 有没有问题、必要时对低置信度字段发起人工确认。成熟的 Agent 会改自己的工作路径改它检索什么改它用什么工具改它执行步骤的顺序改它记住什么改它忽略什么改它是否更早追问用户改它是否更早停止这就是 process-level self-correction。Agent 只有开始修正工作路径而不是只重写最终文本才更接近生产系统里的“自我改进”。八、能配合闭环工作的 Prompt 模板Prompt 仍然有用。只是它应该服务于 loop而不是假装自己能替代 loop。下面这些模板不是万能咒语它们的作用是让模型在闭环里扮演更清楚的角色。模板 1评估感知的行动提示词你正在一个有边界的工作流中执行任务。 你的目标不是只生成一个答案而是生成一个能够通过评估的结果。 如果信息缺失请提出问题或检索信息。 如果结果不确定不要自信地结束任务。 如果上一轮尝试失败不要在上下文没有变化的情况下重复同一种策略。这个模板提醒模型通过评估比“看起来完成”更重要。模板 2失败诊断提示词上一轮尝试失败了。 请把失败原因归入下面类别之一 - 缺少上下文 - 工具使用错误 - 错误假设 - 输出不完整 - 格式或 schema 失败 - 规则或权限冲突 然后提出一个最小的下一步修改让下一轮成功概率更高。这个模板把失败变成分类问题避免模型泛泛地“再试试”。模板 3基于反馈的修订提示词请根据 evaluator 的反馈修订下一轮尝试。 不要重复已经失败的推理路径。 优先选择更窄、更有证据支撑的方案。 如果需要请先检索更多上下文再给出答案。它适合放在 evaluator 后面把评估结果转成下一轮策略。模板 4反馈记忆压缩提示词请把上一轮尝试总结成一个简短的记忆块供下一轮使用。 只包含 - 什么失败了 - 什么有效 - 什么应该避免 - 下一步应该尝试什么 控制在 120 字以内。这个模板用来处理 memory 污染。它强迫系统只留下行动相关的信息而不是把所有历史都丢回上下文。九、一个 Python 风格的最小闭环下面是一个极简伪代码。它不是完整实现只是把闭环结构写清楚。MAX_ATTEMPTS 4 memory [] for attempt in range(MAX_ATTEMPTS): context build_context( tasktask, memorymemory, ) plan agent.plan(context) result agent.act(plan) evaluation evaluator.check( tasktask, resultresult, ) if evaluation.passed: return { 「status」: 「success」, 「result」: result, 「attempt」: attempt 1, } failure_summary agent.summarize_failure( resultresult, evaluationevaluation, ) memory.append({ 「attempt」: attempt 1, 「failure」: failure_summary, 「suggested_fix」: evaluation.next_step, }) if evaluation.requires_human: return { 「status」: 「escalated」, 「reason」: evaluation.reason, 「attempt」: attempt 1, 「memory」: memory, } return { 「status」: 「failed」, 「reason」: 「max_attempts_reached」, 「memory」: memory, }这段代码里有几个点值得留意。第一attempt 有上限。系统不会无限循环。第二每一轮都基于 memory 构造上下文。上一轮失败不会被忘掉也不会原封不动塞回来。第三evaluator 是独立模块。Agent 不能只靠自己宣布成功。第四失败后会生成 failure_summary并保存 suggested_fix。系统记住的是下一步能用的信号不是原始噪音。第五如果 evaluator 判断需要人工介入流程会升级而不是硬撑。真实系统会比这复杂但骨架差不多尝试、评估、记忆、修正、重试或升级。十、不同 Agent 该怎么用这套东西Loop Engineering 不只适用于一种 Agent。只要第一次成功率不稳定或者任务结果需要验证就值得设计闭环。1. Coding Agent代码 Agent 特别适合做闭环因为它有天然 evaluator。它可以运行测试读取错误日志定位失败文件修改代码重新运行测试对比修改前后的结果只在验证通过后交付一个可靠的 Coding Agent不应该在“写完代码”时结束而应该在“验证通过”时结束。再往前走一步它还应该记住哪些修复路径已经失败避免在同一个测试错误上反复改无关代码。2. Support Agent客服或支持类 Agent 的风险是生成一段很礼貌、很完整但事实不可靠的回复。它的 loop 可以包括检索政策文档草拟回复检查是否有来源支撑判断是否涉及退款、隐私、合规等高风险场景高风险时交给人工审批记录人工修正这里的目标不是让回复更漂亮而是让它更符合政策、更可追溯也更少误导用户。3. Research Agent研究 Agent 容易踩三个坑证据不足、来源噪音、过早综合。它的 loop 可以包括收集多个来源判断来源类型和可信度识别证据缺口继续检索缺口区分事实、推测和观点只在证据足够时综合一个好的 Research Agent应该知道什么时候不该总结。材料不够时先补证据不要急着写一份看起来完整的结论。4. Document Extraction Agent文档抽取任务通常有明确 schema因此很适合做 evaluator。它可以解析文件抽取字段校验 schema标记低置信度字段对模糊字段重新读取局部区域必要时升级人工确认这类 Agent 的难点不是一次性抽得多漂亮而是能不能识别哪些字段不可靠并对不可靠字段采取不同动作。5. Operational Workflow Agent操作型工作流 Agent 会调用 API、写数据库、改配置、触发流程。这里尤其需要边界。它可以调用 API检查返回结果处理部分失败避免重复提交在危险操作前请求确认把异常路由给人这类 Agent 的 Loop Engineering 里幂等性、审计日志、权限边界和人工接管都不能省。否则所谓“自我改进”很可能变成“自我放大错误”。十一、看起来像闭环其实不是错误 1把重试当成改进重试本身没什么价值。改变后的重试才有价值。如果每一轮都用同样上下文、同样工具、同样策略、同样停止条件那它只是重复执行。下一轮必须有差异才有机会变好。错误 2存太多 memory不是所有历史都有帮助。太多 memory 会污染上下文让模型注意到无关细节。应该保存压缩后的、可执行的经验而不是原始 transcript 堆积。错误 3跳过 evaluator没有检查Agent 就不知道自己有没有做对。这是最常见的结构性问题。很多系统一直让模型继续生成却没有机制判断结果是否更接近目标。错误 4没有停止条件无约束的 Agent 不会自动变高级。它通常只是更贵、更慢、更难控制。错误 5忽略人工反馈如果人类一直在修正同一个问题而系统从不吸收这个信号Agent 就没有真的学习。人工反馈不应该只留在聊天记录里。它可以进入 memory、规则、评估标准或者策略调整。错误 6所有任务共用一个大循环不同任务需要不同 loop。客服 Agent 和代码 Agent 不该共用同一套失败分类。研究 Agent 和文档抽取 Agent 也不该共用同一套 evaluator。Loop Engineering 要贴着任务设计而不是做一个万能大循环。十二、推荐的构建顺序如果要从零构建一个自我改进 Agent不要一开始就追求复杂自治。按下面这个顺序会稳一点。Step 1定义成功标准先回答什么结果算好这个问题答不清楚后面的“改进”就没有方向。Step 2定义失败类型再回答这个 Agent 通常会因为什么失败失败分类越具体重试策略越容易设计。Step 3先构建 evaluator不要先急着堆 Agent 能力。先让系统知道如何判断成功和失败。一个能力普通但有 evaluator 的 Agent很多时候比一个能力很强但没有 evaluator 的 Agent 更可靠。Step 4设计 memory 规则决定什么应该持久化什么只保留在当前上下文。原则还是那句只保存对下一轮决策有帮助的信息。Step 5定义重试策略每次失败后下一轮改变什么补上下文、换工具、缩小任务、修格式、请求人工还是直接停止这些最好提前写清楚。Step 6添加升级逻辑什么时候应该让人介入高风险、低置信度、连续失败、权限不足、破坏性操作都应该有明确规则。Step 7记录关键日志看不见就改不了。至少要记录失败阶段、失败类型、重试次数、采取的修正、最终状态、人工是否介入。Step 8闭环稳定后再优化核心循环没跑稳时不要急着上复杂工具、多 Agent 协作或华丽 Prompt。先让最小闭环跑通再扩展能力。十三、上线前自检表在把一个 Agent 称为 self-improving 之前可以先用这张表过一遍。一个智能体是否真的具备自我改进闭环换成问题清单Agent 是否知道什么叫成功它是否评估每一次尝试它是否保存来自失败的有用教训它是否会基于反馈改变下一步策略它是否避免盲目重复同一条失败路径它是否知道什么时候停止它是否知道什么时候升级给人你是否能衡量它是不是真的变好了如果大多数答案是否定的这个系统大概率还不是自我改进 Agent。它只是 iterative agent。结语下一步发生什么才是杠杆未来的 Agent 当然会继续吃到模型能力、长上下文和工具生态的红利。但这些东西不自动带来可靠性。我现在越来越觉得生产级 Agent 的差距很大一部分会体现在 loop 上。它是不是能观察结果是不是能评估质量是不是能记住失败是不是能换策略是不是知道停手。这些听起来不如“更强模型”刺激却更像工程。Loop Engineering 把 Agent 从一次性生成器改造成一个能在真实条件下观察、评估、适应、记忆、重试和升级的系统。这不是魔法。只是把“做完之后怎么办”这件事设计清楚。所以当我们想构建更强 Agent 时不妨少问一句“怎么让它行动”多问一句它行动之后怎么从发生的事情里学习学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。