企业官网建设流程全解析

评估跑完看到分数掉下去的那一瞬间，我第一反应也是怀疑模型。重新对版本、查权重、跑微基准，模型一点没变，但 Agent 的表现就是肉眼可见地变笨了。这种事我遇到过不止一次，后来慢慢想明白：评估结果下降，问题多半不在模型，而在它的“反馈回路”坏了。

这里的“反馈回路”不是某个单一模块，而是一整条链路——工具返回怎么被解析、记忆库怎么被写入和检索、评估集怎么被更新、自校正循环怎么决定重试还是停止。任何一个环节被污染、被截断、被误读，Agent 就会在闭环里沿着错误方向越跑越偏。这篇内容就是围绕这个判断展开的：为什么说模型经常是被冤枉的，反馈回路到底坏在哪几种典型的位置，以及怎么用一套可复现的排查流程找出真凶。适合正在做 Agent 开发、Agent 评测、或者准备把 Agent 接入生产环境的同学参考。

1. 变笨的真相：评估分下降不等于模型质量下降

1.1 模型没换，Agent 却“降智”了

很多人面对“评估分数下降”的第一反应是：模型是不是更新后变笨了？这也是我踩过的第一个坑。

我做过一个企业内部的数据分析 Agent，五月份第一次正式跑评估，得分 78，两周后同一套评估跑出来只有 63。当时的第一直觉就是去查模型版本、查是不是最近换过 prompt 模板、查为什么 temperature 被改掉了。结果模型版本没有变，prompt 模板在老版本仓库里能找到 commit，temperature 也一直是 0.2。于是我又怀疑是评测代码写错了，重新拉分支跑了好几次，还是 63 分。

后来才发现问题根本不在模型，而在 Agent 跑任务时调用的一个数据查询工具，它某个字段返回值类型从布尔改成了字符串，下游所有校验逻辑全部失效。Agent 拿到的“事实”虽然是错的，但模型本身并不知情——它只是在错误输入的基础上做了最合理的推理。这就是典型的“模型没变，Agent 却降智”的场景。

类似的情况还包括：工具返回被截断、记忆库里写入了错误经验、评估集悄悄换了一批样本、judge 模型的评分标准变了。这些变量看起来都不属于“模型能力”，但它们共同决定了你在评估报告里看到的那个数字。

一句话总结我的经验：Agent 的能力不是“模型权重”这一个变量能解释的，而是模型、上下文、工具反馈、记忆、评估信号共同作用的结果。把 Agent 当成一个黑盒来调，永远只能在表象上打转。

1.2 反馈回路：被低估的系统属性

先给一个直白的定义。Agent 要完成复杂任务，靠的不是一次模型调用，而是多轮循环：感知（observation）、推理（planning）、行动（action）、接收结果（feedback），然后再进入下一轮感知。这个循环中间所有用来“校正下一步行动”的信号，我统称为反馈回路。

你可以把 Agent 想象成一个开车的人。模型是他的大脑，负责思考怎么操作；反馈回路则是他的眼睛、耳朵和导航系统。大脑再聪明，如果眼睛看到的红绿灯是错乱的，导航报的路线是过期的，那车一定开不到目的地。更麻烦的是，当反馈信号自洽地出现错误时，大脑还会在错误前提下推导出一套“看起来合理”的连续动作。

在系统里，反馈回路包含这些关键子环节：

• 工具调用后的返回结果，如何被解析、截断、标准化
• 错误处理与重试机制，如何决定是否重新尝试、保留哪些上下文
• 记忆库的写入审核、检索排序、过期淘汰
• 评估集版本管理、judge 模型的一致性
• 自校正循环中，模型对上一轮输出的“反思”是否被当作有效反馈

任何一个子环节出问题，都会让 Agent 的“下一步决策”建立在错误信息之上。所以当你看到评估分数下降时，不要先急着把锅甩给模型，先想想这条回路里有没有哪个环节开始喂给模型错误的数据了。

1.3 无状态调用与有状态闭环的差异

为什么“单测模型没问题，放到 Agent 评估里就崩了”？这其实是因为我们习惯性地把 Agent 当成了一个普通 API 调用。

普通模型调用是无状态的：你发一个 prompt，模型返回一个回答，一次交互结束，不存在“下一步要用到上一步的结果”这回事。因此，只要你固定 prompt 和参数，模型输出基本是稳定可复现的。

Agent 则不同，它是典型的有状态闭环。每一轮行动的结果会变成下一轮推理的输入，循环次数多了之后，任何一个环节的微小偏差都会被放大。下面这张对比表能更直白地说明差别：

这也是为什么“模型 benchmark 分数”和“Agent 评估分数”往往是两套不同的指标。前者测的是模型本身，后者测的是整个系统的稳态能力。一个反馈回路有问题的 Agent 框架，配上再强的模型也可能跑出让人无语的效果。我自己见过同一个模型在两个 Agent 框架里跑出完全不同的评估分，就是因为一个框架对工具返回做了标准化、错误信息隔离很干净，另一个框架则直接把原始报错拼进上下文当业务数据喂给模型。

2. 反馈回路最常见的五种“坏法”

2.1 eval 集漂移：评估器自己在退化

先泼一盆冷水：有时候 Agent 根本没变笨，是评测标准变了。我见过不少团队花了很大力气优化 Agent，结果评估分数不升反降，最后才发现是 eval 集被人动过。

eval 集漂移通常有两种来源。第一种是数据集本身被替换或扩充——有人加了新样本、改了标注答案、或者换掉了部分 case，但这些变更没有经过评审，也没有跟历史分数做对齐。先从 72 分涨到 78 分，只是新样本更容易得分；后来又跌回 65 分，也不是 Agent 退步，而是混合样本难度上升了。第二种是 judge 模型（LLM-as-judge）的评分标准变了。比如你把 judge 的 prompt 从“检查是否包含关键点”改成了“检查逻辑是否完整、表述是否严谨”，标准一旦更严格，全体分数立刻下降三五个点。

这种问题最坑的地方在于：分数是连续评估出来的，没人会注意到 eval 集本身变了。所以我的建议是，给 eval 集加版本锚定：每次跑评估，必须记录 eval_set_hash、judge_version、model_version、prompt_hash 这四样东西。如果 hash 变了，评估报告新旧之间就没有直接可比性。另外建议定期跑一组“judge 一致性测试”——取 30 到 50 条固定样本，让同一个 judge 模型跑两次，算一下输出的一致性。一致率低于 0.8 的时候，评估结果就要打问号。

2.2 记忆回流把噪声当经验

记忆库是 Agent 的长期经验库，也是反馈回路里最容易沉积垃圾的地方。很多人设计记忆系统的时候，只关注“写入什么内容”，却忽略了“怎么判断一条经验是否真的成功”。

我接触过的很多 Agent 框架，判断任务成功的标准非常粗糙。常见写法是“用户最后一条消息是否表达了满意”，甚至直接看“流程是否走到最后一步”。这种标准在 demo 阶段够用，但到了真实环境就会污染记忆库。举个例子：Agent 调用 SQL 查询超时，被 exception 打断，但代码流程末尾有一个“生成执行计划”的环节，这个环节跑完后，系统就把整个会话标记为“成功案例”，写进了长期记忆。下一次 Agent 遇到类似查询，检索到这个“成功案例”后，会直接模仿那条失败路径，把超时当成正常流程的必经阶段。模型没有变，是记忆库里的经验变成了反经验。

记忆回流的另一个隐藏问题是新旧记忆冲突。旧经验可能是三个月前的过期信息，新经验才是当前环境的正确结论，但系统没有冲突处理策略，检索时默认保留旧记忆。这就相当于一个人脑子里同时装着“红灯可以走”和“红灯不能走”两条规则，而他每次都提取出旧的那条。别小看这个问题，它会让 Agent 的表现呈现一种“时好时坏”的随机退化，非常难定位。

2.3 工具反馈被截断或误读

工具反馈是 Agent 在真实世界中获取信息的主要通道，也是最容易被结构性问题击穿的环节。最常见的坑是截断。

搜索、数据库查询、文件读取这类工具经常返回超长内容。Agent 的上下文窗口有限，系统只能截断，但很多工具返回格式里根本没有“是否截断”这个标志位。Agent 拿到的是一份“印刷到一半的报表”，它不知道后面还有数据，于是基于残缺信息给出结论。乍一看回答得很有逻辑，管理员一看结果却是错的。更隐蔽的是，Agent 还会因为看到的数据“自洽”而产生高置信度，不会主动去质疑数据完整性。

另一个经典问题是错误信息被当成业务数据。比如 HTTP 返回 403，解析层只提取 body 里的某个字段，Agent 看到的是“success: false”，但它不知道这个 false 代表的是“权限不足”，还是“数据为空”。有些解析逻辑还会把状态码字段跟业务字段混在一起，Agent 拿到的所谓“结果”实际上是错误码。这种情况下模型再聪明也没办法纠正，因为它连自己拿到的是错误信息都不知道。

工具反馈出问题，评估分往往呈现“全样本轻微下跌”的趋势，而不是某一类任务崩盘。判断依据也很简单：在 trace 日志里看模型每轮行动的上下文，如果发现工具返回内容里没有任何“truncated”标记、错误信息没有被隔离，那基本可以断定是这一环坏了。

2.4 自校正循环的“复读机效应”

给 Agent 加上“自我反思”“自我纠错”能力是现在的主流做法，但自校正循环设计不好，反而会放大错误。

问题集中在反馈缺失的情况。反思模块的输入是当前上下文和模型上一轮的回答，它需要判断“上一轮哪里不对，下一步怎么改”。如果 Agent 手里没有客观依据——比如没有工具返回结果、没有用户澄清、没有外部校验信号——它就只能基于上一轮的错误输出继续推理。于是反思循环变成一个“复读机”：模型把自己的错误答案当作输入，重新生成一遍，可能还会加上更多看似合理的细节，让错误看起来更严重。

具体表现是：同一个任务，第一次回答有 60% 的正确率，重试一次后变成 50%，再重试一次变成 40%。每一轮都在往上下文里叠加上一轮的错误信息，模型的注意力被大量相关但不正确的中间内容占满，纠错能力反而下降了。

这类问题的修复不在模型，而在循环的终止条件。后面第四章会细讲怎么做，这里先记住一个原则：自校正循环必须设置“收敛条件”，不能给模型无限次重试的机会。没有收敛条件的反思，本质上是对错误信号的反复放大。

2.5 奖励信号噪声：偏好采集与评估者不一致

最后一种情况比较特殊，它确实会让你看到“模型的权重前后不一致”，但根源还是反馈回路的问题。

如果一个 Agent 系统接入了在线学习或偏好优化管道，比如根据用户点赞、点击、收藏等行为生成偏好数据，然后定期微调模型权重，那么反馈信号的噪声就会直接影响模型更新。用户点“赞”并不一定代表回答是真正正确的，可能只是语气好；用户没点也不代表回答错了，可能只是懒得操作。把这些噪声信号当成奖励回传，模型更新方向就会被带偏。表现就是某一版本模型权重更新后，所有任务评分齐跌，跟某个时间点强相关。

对大多数不自己训练模型的 Agent 开发者来说，遇到这种“变笨”要做的不是去调模型权重，而是先分清这个锅属于“权重更新”还是“奖励管道”。如果模型版本明确没动过，但所有任务都变差了，且跟一次偏好数据回流的时间点吻合，那基本可以判定是奖励信号出了问题。这种场景下，需要在偏好采集层加噪声过滤、做人工抽检，甚至暂时剔除某些高噪声信号源。

五种坏法对应的症状差异很明显，放在一起对照更直观：

3. 排查实操：从“怀疑模型”到“定位回路”的完整方法

3.1 先把模型层洗干净

排查的第一步不是翻代码，而是先把模型层洗干净。目的只有一个：确认模型本身没有真正退化，把注意力从“模型问题”上移开。

做法其实很机械。对 API 模型，锚定 model version 和所有推理参数，包括 temperature、top_p、max_tokens、frequency_penalty，甚至连是否使用缓存、是否启用结构化输出都要记录下来。对本地模型，记录权重文件的 sha256 和加载时的 revision，确保跑评估用的就是你想用的那个权重。

在这个前提下，挑 20 到 50 条微基准样本，覆盖推理、代码、数学、指令遵循四个维度。每条样本都不能依赖工具、不能依赖记忆、不能走 Agent 循环，就是“prompt 进去，答案出来”的裸模型测试。如果模型版本没有变，参数没有动，微基准分数跟之前一致，那就可以下结论：模型层没有问题，可以继续往回路里查了。

这一步看起来耗时，但价值很大。我见过团队花了三天排查 Agent 的 eval 逻辑，最后发现是某个同事在部署时临时改了模型推理参数，导致整体输出风格变化。白白浪费了时间。

3.2 Golden set 回归：锁定行为基线

模型层确认没问题之后，下一步是建立行为基线。做法是选 50 到 100 条带客观判定标准的历史样本，组成 golden set。为什么强调“客观判定”？因为太依赖 LLM-as-judge 的话，你排查问题的时候还得同时排查 judge，问题半径一下就扩大了一倍。优先用那些有标准答案、可程序化判对的样本，比如 SQL 执行结果对比、实体抽取的 F1、代码单测通过率。

跑 golden set 的核心方法是双版本对照：老版本 Agent 代码冻结一份，新版本代码跑一遍，两者都用同一个 eval 集、同一个模型版本、同一套 prompt。只改一个变量，这是定位问题的铁律。如果你同时改了解析层 schema、记忆库写入策略和 prompt 模板，结果是哪一个改动引起的变化根本分不清。

实际操作中我会并行跑三轮取均值，因为 Agent 带随机性，单次跑分不能代表真实水平。如果老版本和新版本在 golden set 上的分数都明显下降，问题大概率出在公共依赖上，比如模型参数、eval 集本身、judge 配置；如果只有新版本下降，问题就锁定在版本间的代码差异里。

3.3 链路审计：用 trace 慢回放定位污染点

双层下探完成之后，真正花时间的环节是链路审计。核心思路很简单：不要只看最终输出，把 Agent 跑任务时每一步的输入输出都记录下来，然后人工回放，找出“哪一步上下文里混入了不该有的内容”。

需要重点记录的 trace 字段包括：

• 每一步 tool_call 的输入参数、返回结果的完整原文和截断状态
• 记忆库每次读取命中的条目 ID、写入候选的内容和成功判定依据
• 每次自校正的触发原因、重试后输出和上一轮输出的相似度
• judge 模型对每条样本的打分明细和评分依据
• 上下文拼接顺序，尤其是工具返回内容被插入的位置

我用过几种现成的 trace 工具，LangSmith、Langfuse、Arize 都支持类似的能力；如果项目处于自建框架阶段，最简单的做法是给每个环节打结构化日志，按会话 ID 汇总成 JSON lines 文件，再用脚本做离线回放。排查的时候打开一条失败样本，一步步往下走，重点看模型每一轮 action 前的上下文里有没有下面这些问题：上一个工具调用已经被截断了但 Agent 没有感知、某条记忆内容明显与当前任务无关但被排到了检索结果最前面、错误信息被当作业务数据拼到了推理上下文中。

链路审计最大的好处是能一次性抓多个问题。我一次排查里经常同时发现工具 schema 变更没同步、错误信息隔离失效、记忆写入审核形同虚设三个问题，这在只看最终分数的评估报告里是不可能发现的。

3.4 写一个最小诊断脚本

下面这个脚本是我在排查中经常用到的“快照对照法”。它的逻辑很简单：每次评估前，把 Agent 的每一步输入、中间状态、上下文 hash 全部记录下来；下次评估后再跑一遍同样的样本，用 hash diff 找出“从哪里开始行为分叉”。

import hashlib import json from eval_harness import run_sample def snapshot(state: dict) -> str: """把一段链路状态做成 sha256，用于定位变化起点。""" serialized = json.dumps(state, sort_keys=True, ensure_ascii=False, default=str) return hashlib.sha256(serialized.encode()).hexdigest()[:16] def collect_trace(agent, sample): """跑单条样本，逐步记录各环节状态。""" trace = [] for step in run_sample(agent, sample, record_steps=True): state = { "step": step.name, "input_snapshot": snapshot(step.inputs), "output_snapshot": snapshot(step.outputs), "context_snippet": step.context_text[:500], } trace.append(state) return trace def compare_trace(old_trace, new_trace): """对比两次链路记录，输出第一个分叉步骤。""" if len(old_trace) != len(new_trace): return "trace 长度不一致，可能存在流程分支变化" for i, (old_step, new_step) in enumerate(zip(old_trace, new_trace)): if old_step["output_snapshot"] != new_step["output_snapshot"]: return { "first_divergence_step": old_step["step"], "old_output_hash": old_step["output_snapshot"], "new_output_hash": new_step["output_snapshot"], "new_context_snippet": new_step["context_snippet"], } return "trace 一致"

实际用的时候，我会把新老两个版本的 Agent 分别跑同一批样本，然后输出所有分叉点，优先处理最早出现分叉的那个环节。分叉点出现在工具返回里，就查工具解析层；分叉点出现在记忆命中内容里，就查记忆检索排序；分叉点出现在自校正后的输出里，就查反思循环的触发条件。这套脚本虽然简单，但能大幅缩短“乱猜”的时间。

4. 修复回路的工程化方案：从指标到机制的落地改造

4.1 评估集版本锚定与 judge 一致性

定位到问题之后，修复需要按工程化的方式来，不能只改一个点，要把回路里容易再次坏死的环节用机制卡住。先评估集这条线。

评估集版本锚定要做到三点：第一，eval 集本身放进版本管理，任何增删样本都要有 commit；第二，每次跑评估，结果文件里必须写清楚 eval_set_hash、judge_version、model_version、prompt_hash；第三，历史分数与当前分数只有在这四者都一致时才可比较。一次评估报告如果缺了这些元信息，那它就只是一堆没有对照意义的数字。

judge 一致性是另一个容易忽略的点。很多团队用 LLM-as-judge 做评分，却没有校验 judge 本身稳不稳定。建议定期跑一致性测试：固定 30 到 50 条样本，让同一个 judge 跑两次，算一致率。一致率低于 0.8 的时候，要么换更强的 judge 模型，要么简化评分 prompt，减少模糊指令。永远不要用一个明显弱于被测模型的模型来做裁判，否则你评估的根本不是 Agent，而是两个模型之间的理解偏差。

4.2 记忆回流的写入审核与淘汰

记忆库的修复是优先级最高的，因为污染一旦沉积，影响会随着时间扩散。核心思路是：写入审核、过期淘汰、冲突覆盖三个机制同时上。

写入审核解决“垃圾进”的问题。默认情况下，只有同时满足客观校验条件的经验才能进入长期记忆：任务有明确的完成标志、工具调用状态码为成功、关键中间产物存在。拿不到这些证据的会话，一律只保留在短期日志里，不进记忆库。下面是一个可以落地的配置参考：

memory_pipeline: write_audit: require_success_flag: true require_tool_ok: true require_objective_checked: true expire_after_days: 30 conflict_policy: strategy: newer_overrides_old_when_tool_evidence keep_both: false retrieval: diversify_by_source: true

过期淘汰针对的是“旧经验活着”的问题。记忆条目必须带时间戳、来源、任务类型三个字段。超过有效期、来源可信度下降、或者已经被新冲突条目覆盖，都要降低检索权重或直接删除。我在实际项目里会把过期淘汰做成一个定时的清理任务，每天早上跑一次，而不是等到检索时再去判断。

冲突覆盖解决“新旧矛盾”的问题。当两条记忆给出的结论冲突时，不能用“默认保留旧条目”这种懒策略，而是看哪一条有工具结果或客观数据作为支撑。有证据的新经验要能覆盖旧经验，否则旧经验会把 Agent 永远锁在过时的行为模式里。

4.3 工具输出标准化：错误信息与业务数据分离

工具反馈这一环的修复，核心是定义一套统一输出规范。所有工具返回必须过一个标准化层，输出结构固定，错误信息和业务数据严格隔离。下面是一个我常用的 schema：

{ "ok": true, "code": 0, "truncated": false, "data": { "result": "...", "metadata": {} }, "error": { "type": "", "message": "" } }

规则就四条。第一，ok和code永远是最外层字段，用布尔和整数，不做字符串混淆；第二，truncated字段必须存在，当返回内容超过可消费 token 预算时由标准化层主动置为 true，同时保留真实长度信息，让 Agent 知道“数据不完整”；第三，错误信息永远放在error对象里，业务数据放在data里，两者不允许混用；第四，Agent 的 prompt 模板只消费data字段，除非ok为 false 时才会读到error。

这套标准化看起来简单，但它解决的是我在案例里提到的最隐蔽问题：Agent 不是不会推理，而是它根本不知道“数据不完整”这个前提。只要truncated标志位写得足够显眼，Agent 就有机会主动发起二次查询或者缩小范围，而不是基于残缺数据自信地输出错误结论。

4.4 自校正循环的收敛控制

自校正循环的修复思路是给“反思”套上缰绳。三个机制配合使用：

最大尝试次数。每个任务最多允许反思 2 到 3 轮，超过就停止或转人工。不要相信模型能无限自我优化，绝大多数真实场景里，第 4 轮反思的边际收益是负的。

重复检测。每轮反思输出之前，先跟上一轮输出算一下 embedding 相似度。相似度超过 0.9，说明模型在“复读”而没有产生新信息，此时强制终止本轮反思。这个机制能直接解决复读机效应，因为在上下文没有新增反馈的情况下，模型根本没有新的依据来产生新答案。

失败尝试隔离。重试时不能直接把上一轮的错误中间结果一股脑留在上下文里，建议把上一轮的输出压缩成一个简短摘要，再进入下一轮推理。否则的话，每一轮反思都在把错误细节继续喂给下一轮，上下文噪声越来越重，模型被错误信息包围，很难跳出来。

我见过一个最典型的失败案例：Agent 第一轮调用工具失败，错误信息里包含了超长的堆栈；自校正模块把完整堆栈留在上下文里继续让模型推理，模型开始分析堆栈里的变量值，试图“修复”一个根本不需要修复的问题。最后第三次回答比第一次还差。失败尝试隔离，就是为了防止这种“越修越坏”的循环。

4.5 回路健康度指标与告警

修复机制落地后，必须配上监控。反馈回路本身也应该有一套健康度指标，不能等到评估分数掉下来才去排查。下面是几个我认为最值得监控的指标：

这些指标配上简单的告警规则，就已经足够兜住大多数“Agent 变笨”的场景了。当然，最核心的其实不是某一条指标，而是建立一种纪律：任何评估分变化都要先查指标，再对比版本差异，而不是看一眼分数就怀疑模型。

5. 实战复盘与避坑清单

5.1 一起“降智”事件的处理经过

说一个比较完整的复盘案例，把这个流程串起来。

背景是一个企业内部的数据分析 Agent，用于根据自然语言查询生成 SQL 并跑查询返回结果。团队每周跑一次评估，某次例行评估发现总分从 78 掉到 63，而且连续两周没恢复。第一周大家怀疑模型，检查之后发现模型版本没变，微基准分数稳定；又怀疑是数据源结构变化引起，排查后也没发现明显异常。

第二周开始做链路审计，回放了十条分数下降最明显的失败样本。发现一个共性现象：所有失败样本都涉及某个数据查询工具，这个工具返回了一串超过 token 预算的结果，被框架截断了，但截断代码没有设置任何截断标志位。Agent 拿到的是一份不完整的结果，并且完全不知情。它在不完整数据的基础上做了非常完整的分析，得出了非常错误的结论。

再往下挖，发现更隐蔽的连锁反应：同一批被截断的工具结果，也被错误地标记为“成功”，写进了记忆库。由于这些结果本身是残缺的，后续检索到它的 Agent 都可能被带偏。等于说，一次截断问题，同时破坏了工具反馈和记忆库两个环节。

修复方案是三管齐下。工具层做了输出标准化，加了truncated标志位，超长结果截断时强制提示模型；记忆库加了一条规则，工具返回truncated=true的会话不允许进长期记忆；评估集本身也顺手做了版本锚定，确保后续分数可比较。修复后下一周评估分数回升到 76，并且连续四次评估方差明显变小。那次之后，团队内部就定了一条规矩：任何降智事件，先查反馈回路的三个薄弱点——截断、记忆写入、eval 集漂移，然后才允许怀疑模型。

5.2 最小化自查清单

如果你正在被“Agent 变笨”折磨，按照下面这个清单过一遍，大多数问题能在半小时内定位到一个可疑环点：

• [ ] 模型版本和推理参数是否与历史基线完全一致？
• [ ] 微基准测试（不经过工具和记忆）分数是否稳定？
• [ ] 评估集 hash 和 judge 版本是否与上次完全一致？
• [ ] judge 一致性测试是否通过？
• [ ] 失败样本的工具返回里，有没有出现截断但 Agent 未感知的情况？
• [ ] 工具返回的 error 信息是否被误当成业务数据拼进了上下文？
• [ ] 最近有没有失败的会话被当作成功案例写入记忆库？
• [ ] 记忆库中是否出现了与新经验冲突且时效性不足的旧条目？
• [ ] 自校正循环是否出现了重试次数越多、结果越差的现象？
• [ ] 是否存在模型版本更新后所有样本齐跌，且与偏好数据回流时间点吻合的情况？

这套清单基本覆盖了前面提到的五种反馈回路故障模式。如果你的项目里有三个以上回答“是”，那问题大概率不在模型，而在回路里。

5.3 几条用代价换来的体会

写到这里，说几句真心话。

我踩过最大的坑，是把评估分数当成“模型成绩单”。实际上，评估分数更像“系统体检报告”——它反映的是模型、上下文、工具、记忆、eval 标准共同构成的整个闭环的健康度。模型只是一台发动机，反馈回路是方向盘、油表和导航，任何一个仪表坏了，车子的表现都会很糟糕。

我后来把团队的核心原则改成了一句话：任何一次 Agent 变笨，先查反馈回路，再查模型。这条原则看起来简单，但真正执行起来需要纪律——每次评估变化都要有可追踪的版本信息，每个工具返回都要有结构化格式，每条记忆写入都要有客观校验。这套基础设施的搭建成本不低，但如果你正在认真做 Agent 开发和评估，这笔钱迟早要花，晚花不如早花。

最后再分享一个小细节：排查反馈回路时，不要只盯着评估环境，线上环境的日志同样重要。我有一次在评估环境里怎么都复现不出来的降智问题，最后是在线上 trace 里看到工具返回内容比评估环境多了一段说明文字，导致解析结果不同。两个环境的工具版本一旦不一致，反馈回路的行为就会分叉。保持评估环境和生产环境的一致，和控制模型参数同等重要。