前几天刚做完一个Agent项目的季度评估，指标整体往下掉了一截：之前跑得好好的复盘类任务，准确率从88%掉到79%，执行链路也时不时卡住。团队第一反应是“模型不行了”，把底层模型版本、温度、上下文窗口全查了一遍，没有任何改动。后来逐层看日志才发现，真正的问题是反馈回路断了——Agent在执行过程中拿不到有效信号，做了错误判断，还继续沿着错误路线往下走。
这个现象其实很普遍。很多团队在开发Agent时，注意力全放在“换更强的模型”“调更长的上下文”“加更多的工具”，却忽略了一个关键事实：Agent的本质是一个闭环系统，模型只是闭环里的一个计算部件。闭环里反馈信号一旦丢失、失准或者延迟，再强的模型也会在长程任务中逐渐跑偏。
这篇文章想聊的，就是Agent“变笨”这件事背后的反馈回路问题：它到底是什么、为什么容易坏、怎么定位、怎么修复、怎么防止以后再坏。
1. 先别急着甩锅给模型：退化现场到底发生了什么
1.1 模型没变，Agent为什么“变笨”了
先界定一个概念。这里说的“变笨”，不是模型本身的推理能力下降，而是Agent在完成任务时的整体表现退化。模型是同一个模型，API没变，参数没调，但装在模型外面的系统——记忆、工具调用、上下文组装、结果校验——发生了变化。
我用一个生活类比来说明。一个人脑力没问题，但耳朵听不清指令，手也感知不到自己按没按对按钮，那他干活就会越来越差。你把责任归到“脑子不行”上，显然找错了方向。Agent框架里的“耳朵”和“手”就是反馈回路：工具调用的返回结果、环境状态的变化、用户的隐式信号、上下文里的历史信息。这些信号一旦传不到位，模型就会基于残缺信息做决策，而且每走一步都会把错误累积进去。
在实际评估中，我见到最多的退化模式有三种：
- 信号衰减：老版本里工具调用的返回会原样拼进上下文，后来做了格式化，把关键字段丢了，模型看不到“失败”标记。
- 上下文污染：随着对话变长，早期关键反馈被截断或挤出窗口，模型只记得最近几步的局部状态。
- 反馈失真：记忆模块把用户的一句随意吐槽写成了“用户偏好”，后续所有决策都被这条失真记忆带偏。
这三种模式的共性是：模型本身没有退步，而是它赖以决策的反馈数据出了质量问题。
1.2 反馈回路：Agent的闭环骨架
要理解反馈回路为什么重要，得先把Agent的工作方式拆开看。一个典型的Agent循环包含四个环节：
- 感知（Perception）：从用户输入、系统状态、工具返回结果中收集信息。
- 决策（Decision）：基于当前信息和历史记忆，规划下一步动作。
- 行动（Action）：执行工具调用或输出内容。
- 反思（Reflection）：根据行动的反馈结果调整下一步计划。
这四个环节连起来就是一个闭环。反馈回路指的就是从“行动”回到“感知”和“反思”的那条链路。它负责把执行结果、错误信息、环境变化传回给决策模块，让Agent能够修正行为。
如果这条链路是健康的，Agent每执行一步，就能获得更准确的信息，决策质量逐步提升；如果链路断了，Agent就是“开环”运行的——它只顾着按计划往下走，对现实世界中“这一步到底成没成功”毫无感知。开环运行时间一长，错误就会累积，表现自然越来越差。
这就解释了为什么评估时经常能看到这样的现象：单轮任务Agent表现得很好，一旦放到多步骤、长流程的真实场景里，就开始“变笨”。
1.3 最容易误判的一类退化场景
分享一个最近踩过的真实例子。我们的Agent里接了一个向量检索工具，用于从知识库中召回相关资料。调试版里，工具返回的JSON里有status字段，值为failed，同时error_code标识了原因。后来为了“优化token占用”，团队把返回结果截断，只保留前三条匹配项，status字段被切掉了。
结果就是：检索服务实际挂了，返回的是空列表，但Agent看到的是一个“合法的空结果”，于是正常进入下一步——“没有相关资料，基于常识回答”。连续几天评估里，凡是依赖知识库的问题，回答质量大幅下降。从模型角度看，它没有做错任何事；从系统角度看，它被蒙住了眼睛。
这让我意识到，评估Agent项目，不能只测“模型能力”，必须要测“反馈链路完整性”。很多时候指标掉点，根因都在链路而不在模型。
2. 拆开反馈回路，逐段体检：问题最容易藏在哪里
2.1 反馈信号采集：你根本没接到信号
反馈回路的第一段是信号采集。Agent依赖的外部信号主要来自三处：
- 工具调用的返回结果：数据库查询、API响应、文件操作结果。
- 环境状态变化：任务是否完成、资源是否释放、队列是否清空。
- 用户行为信号：用户的确认、打断、重复提问、二次修改。
大部分反馈回路问题，都出在“工具返回结果”没有被完整采集。常见原因有三个：
第一，工具封装时丢字段。就像刚才那个检索工具的例子，中间层为了省token或图方便，只保留了“看起来有用”的字段，把错误码、状态码、耗时信息全过滤掉了。第二，返回格式不稳定。有些工具正常时返回JSON，异常时返回纯文本报错，Agent面对两种格式，很容易把报错当成普通文本处理。第三，信号存在但没有被“翻译”。工具的返回结果里写着status: 500，但对模型来说只是一个数字，除非在Prompt里明确说明“状态码非200即为失败”，否则模型可能根本解读不出这层含义。
我现在的做法是：所有进入Agent上下文的外部反馈，必须经过一个统一的“信号标准化层”。工具返回统一转成结构化格式，至少包含状态、数据、错误码三段。无论工具本身返回什么，Agent看到的一定是标准化的反馈结构。
2.2 反馈的传递与上下文：信号被冲淡了
即使信号被正确采集了，还要保证它能有效抵达决策环节。这一段的常见问题是信号在传递过程中被稀释。
一个典型场景：系统Prompt里塞了太多内容。工具使用说明、安全规范、风格要求、示例对话，全堆在最前面。真正重要的实时反馈反而排在后面，模型在长上下文里注意力天然偏向前后两端，中间信息容易丢失。你把关键反馈放在“第1200个token”的位置上，模型可能压根没读到那里。
另一个典型场景是上下文窗口滚动。长任务执行到第20步时，第1步失败的教训早就被挤出了窗口。模型只看到第19步的局部信息，不知道前面已经错了19步。就好比别人只告诉你“你现在的位置不对”，但不说你从哪里走错的——你很难自己纠偏。
针对这个问题，不能只靠“加大上下文窗口”来解决。窗口再大也有上限，而且窗口越大、注意力就越分散。更有效的思路是关键反馈必须“置顶”：把当前最重要的状态摘要——比如“最近一次失败及原因”“当前任务的已完成/未完成清单”——单独放在上下文的最前面或独立字段里，确保模型每次决策时都能看到。
2.3 反馈的执行：Agent听到了但不改
反馈回路的最后一段是“修正”。信号采到了、也传到了，但Agent没有据此调整行为，这就涉及反思环节的设计问题。
很多Agent框架里都有“反思”这个动作，但实现得非常潦草——就是把历史对话原样丢给模型，让它“总结一下”。这种反思输出的内容，往往是空泛的“我需要更仔细”“我应该提供更准确的回答”，对后续行为没有任何约束力。
更麻烦的是，有些反思循环会把错误结论写进长期记忆。比如Agent在任务中遇到一次失败，反思时得出一条结论：“用户偏好简洁回答，不需要详细步骤。”但实际上用户只是因为当时赶时间才说了句“简单点”。这条被误解的反馈被写进长期记忆后，后续所有任务都会被它影响——这就是典型的失真反馈正循环：先有一个错误判断，然后所有后续决策都在强化这个错误判断。
要让反思真正起作用，得把它从“自由发挥”改成“结构化验证”。不要问“这次任务有什么可以总结的”，而要问“这次执行中，有哪些反馈信号与预期不一致？不一致的原因是什么？下次遇到同样信号时，应该采取什么不同行动？”同时，记忆写入必须经过校验，不能由反思环节直接落库。
3. 实操修复：把反馈回路重新“焊”回去
3.1 第一步：先做链路体检——日志与埋点
修复反馈回路的第一步，是先搞清楚回路断在哪里。我推荐的做法是给Agent运行链路做端到端埋点，不是简单记录日志，而是把每一步的“输入信号→决策→行动→反馈”完整打出来。
具体来说，每条Agent运行轨迹至少需要记录：
- 每轮模型调用的完整输入（Prompt里实际包含了哪些反馈信号）
- 每个工具调用的原始返回和标准化后的返回
- 模型决策的推理过程（如果有的话）
- 反思环节的输出和记忆写入的内容
有了这些记录，你才能回答三个关键问题：信号是否被采集？信号是否被传递？信号是否被采纳？
实操时，我习惯先跑一组已知会出错的测试用例，把这些用例的轨迹全部导出来，逐个环节去对。通常定位到具体断点，修复就完成了一半。
3.2 第二步：给工具反馈做“结构化改造”
链路体检做完之后，最值得优先修复的通常是工具反馈这一环。这里给出一套可以直接借鉴的改造方案。
在设计工具封装层时，统一约定如下返回结构：
{ "status": "success" | "failed", "data": {}, "error": { "code": "RETRIEVAL_EMPTY", "message": "No relevant chunks found" } }同时，在系统Prompt中明确告诉模型：
当你看到status为failed时，不要继续执行依赖该结果的后续动作。必须先处理错误：重试、换工具、或向用户说明当前无法获取信息。
这一步看起来简单，但实际上能解决大量“Agent在错误结果上继续推理”的问题。它还顺带解决了另一个隐患：Agent不会再把“查询无结果”和“查询失败”混为一谈，决策的鲁棒性会明显提升。
另外建议在工具层做一次结果校验。并不是所有返回都能靠模型解读，有些错误应该在工具层就被拦截。比如数据库连接失败，与其让模型处理连接超时的文本，不如直接捕获异常，返回标准化的“服务不可用”。反馈回路里的“反馈质量”，很大程度取决于你在哪个层级处理和格式化信号。
3.3 第三步：改造反思模板，让错误真正被看见
反思环节是反馈回路能否形成闭环的关键。自由式反思的效率实在太低，后来我把反思过程改成四段式结构，效果立竿见影。
四段式反思模板：
- 目标：本次任务要达成的最终结果是什么？
- 实际结果：当前实际获得的结果是什么？
- 差距分析：哪些反馈信号显示结果偏离了目标？偏离发生在哪一步？原始反馈是什么？
- 下轮修正：当你再次遇到同样的反馈信号时，具体应该采取什么不同行动？
写成Prompt就是这样的格式：
请基于本次执行轨迹进行结构化反思： - 本次目标：<从任务描述中提取> - 实际结果：<从执行轨迹中提取> - 反馈偏差：<对比目标与实际结果，列出所有异常信号> - 下一轮应对：<针对每个异常信号，给出一次具体的行动变更>注意第四步不要写“更仔细一些”这种话，必须落到具体行动上。比如“当retrieval返回空时，主动检查知识库索引状态，而不是直接生成回答”。这种具体的修正指令，模型在下一轮是真的能执行的。
3.4 第四步：记忆卫生——防止反馈失真
Agent的记忆系统是反馈回路里的“慢变量”，它不像单次工具返回那样显眼，但长期影响最大。记忆一旦写入了错误反馈，就像数据库里存了一条脏数据，后续每次查询都会被污染。
我做记忆管理时有几条原则：
- 记忆写入要带来源：每条长期记忆必须记录它来自哪次任务、哪个反馈信号，方便后续追溯。
- 定期清理置信度低的记忆：如果一条记忆长期没有被后续任务验证，就降低它的权重或直接归档。
- 区分“事实记忆”和“推断记忆”：“用户住在上海”是事实；“用户喜欢简短回复”是推断。推断记忆必须附带依据，且可以被后续反馈推翻。
这套做法解决了一个很隐蔽的问题：Agent在长程运行中会逐渐积累一堆“经验的错觉”。定期清理和标注来源，能有效防止反馈回路中的噪声被当成信号固化下来。
4. 防止再次退化：监控、回归与保险丝
4.1 建立“黄金回归集”，定期体检反馈链路
修复反馈回路不是一次性工作，关键是要建立一个能持续监测链路健康的机制。
我的做法是维护一个黄金回归集——一组覆盖核心场景的任务用例，每两周跑一次全量回归。每个用例不只是看最终答案对不对，还要检查执行轨迹里反馈链路的几个关键指标：
- 工具调用是否都返回了结构化结果？
- 是否存在“工具返回失败但Agent照常执行”的轨迹？
- 反思输出是否包含具体的行动修正，而不是空泛总结？
- 记忆写入是否都带来源标注？
回归集跑出来的结果，就是反馈回路的“体检单”。哪项指标异常，就能提前定位到链路的哪个环节。
这里特别提醒一下：评估的时候不要只看“准确率”这一个数字。准确率掉2个百分点可能根本体现不了反馈链路的问题，但“工具失败后继续执行”这种轨迹比例增加10%，就是非常危险的信号了。
4.2 给Agent加一条“够用就行”的保险丝
第二个防退化手段是给Agent的反馈回路设置熔断机制。
具体来说，在Agent框架里加一道监测：统计最近N次行动中“连续出现同类错误”的次数。如果某个工具连续3次返回失败，或者同一类反思偏差反复出现，就强制中断当前执行链路，切换到预设的降级策略。
降级策略可以是：放弃当前工具、改用备用工具、将任务回退到上一步人工确认、或者直接向用户说明“当前环境状态异常，建议稍后重试”。
这条“保险丝”的价值在于：它把一次性反馈异常升级为系统级事件，让问题在造成更大损失前暴露出来。很多Agent项目里的错误是渐进累积的，单次错误都能容忍，但累积到一定程度就崩了。熔断机制是提前打断这个累积过程。
4.3 反馈回路的演进节奏：别频繁改，但一定要改对
最后想聊一个节奏问题。反馈回路需要持续优化，但不能频繁变动，因为它直接影响Agent行为的稳定性。反馈格式一变，Agent的决策模式可能就要重新适配——这跟换个Prompt模板还不一样，它是系统性的改变。
根据我的经验，反馈回路的迭代节奏可以这样把握：
- 修复类改动（比如补充丢失的错误码）——发现即改，小步快跑。
- 结构类改动（比如改造工具返回格式、重构反思模板）——先在隔离环境验证一个周期，再灰度上线。
- 记忆策略改动（比如更换记忆写入校验逻辑）——建议用更长的观察周期，至少覆盖两类典型任务。
每次改完，黄金回归集必须全量重跑，对比反馈链路指标和最终效果。在这里“没有变化”有时候就是好结果——说明你的改动没有带来新的不稳定性。
个人实操中的几个小技巧
最后分享几个我自己在调试反馈回路时踩过坑之后沉淀下来的做法。
第一个是给反馈信号编号。在关键节点埋点时，给每条重要反馈一个固定编号，比如FDB-001表示工具调用失败，FDB-002表示结果为空。日志检索时直接按编号过滤，比搜关键词快得多，排查效率翻倍。
第二个是让Agent“说出”它看到的反馈。在Prompt里加一句“在决定下一步行动前，先简要说明你从当前工具返回中获取的关键状态”。强行让Agent把反馈解读过程暴露出来，能让我在日志里直接看到它是怎么理解反馈的。如果理解错了，Prompt或者工具格式就得调整。
第三个是把“反馈回路体检”排进迭代流程。每迭代两轮功能，就花半天时间专门检查反馈链路——不需要全面换血，只跑一遍黄金回归集加上抽样日志审查。这相当于给Agent做定期的“小保养”，比攒到季度评估再发现退化要省事得多。
Agent变笨不可怕，可怕的是只会怪模型。真正需要注意的是那条把行动结果传回决策中枢的回路——它比模型更脆弱，也更容易被改动无意间破坏。把这条回路看住，Agent的表现才稳得住。