上线半年的Agent还在犯老错？缺的是这条飞轮

你的Agent上线半年了，回头看看——它比第一天聪明了吗？它可能还在犯三个月前就犯过的错，还在重复三个月前走过的弯路，还在对三个月前就见过的场景表现得像个新手。半年的线上流量喂过去，它一点经验都没攒下来。

问题不在模型不够强。问题在于，没有人给它搭一条从"做过"到"记住"到"变好"的路。

最近几个月，一个普遍且致命的现象是：评测、记忆、Self-Improve这三件事，在大多数团队里是被拆散着做的。评测团队搭了一套评分系统，跑完打个分就结束了——分数去了周报，没有去到Prompt或Skill的改进链路里。记忆团队做了一套向量检索，存了一堆对话历史，但召回的东西噪声太高，Agent反而被干扰，最后记忆模块被默默关掉。Self-Improve团队在探索Skill自动生成，但生成出来的Skill质量参差不齐，没有评测来筛选好坏，没有版本管理来回滚出错的。

每个团队都在认真地做自己那一块。但飞轮没有转起来。

四个齿，缺一个都转不动

这三件事不是三个独立的功能点，它们是同一个闭环的不同环节。评测是闭环的"眼睛"，感知哪里有问题；记忆是闭环的"大脑"，积累可复用的经验；Self-Improve是闭环的"手脚"，把经验变成实际的改进；人机协作是闭环的"方向盘和刹车"，确保进化方向不跑偏。拆开来做，每一块都能说"我做了"，但合在一起却不产生复利——因为环节之间的数据通路是断的。

自进化的瓶颈不是任何一个技术点，而是环节之间的衔接。评测信号必须能流进记忆和Skill更新；更新后必须能被评测验证；验证结果必须能反哺下一轮进化。这条链路断了任何一环，飞轮都转不起来。

另一个容易被忽略的判断是：评测的可信度，大于系统的复杂度。一个简单但评测可信的系统，远好于一个复杂但评测失真的系统。错误的正反馈会让Agent加速开往悬崖。

自进化改的到底是什么

"自进化"这个词被用得很滥。有人拿Self-Refine（让Agent多改几版输出）叫自进化，有人拿Agent RL（训模型权重）叫自进化。它们是完全不同的东西，可以分成三层。

第一层是Artifacts迭代，改输出产物。代码写了三版越来越好、方案改了几稿越来越靠谱，但任务结束，Agent本身没有任何改变。下次遇到同类问题，它不会比这次更快。这不是进化，这是打草稿。这一层已经成熟，不是讨论重点。

第二层是Harness自改进，改Agent的配套系统。记忆、Skill文件、Prompt、工具配置、工作流——这些改动持久化到文件或数据库，跨会话生效。改一次，后续所有任务都受益。这是当前最具性价比的进化方向。

第三层是Model进化，改模型参数本身。通过Agent RL、自对弈微调将经验写入权重，持久性最强，但成本最高、风险最大，目前仍在研究阶段，距离生产落地还有距离。

为什么Harness层是主战场？四个字：即时、可控。改完Skill或Prompt立刻生效，不需要重训模型；改错了一键回滚，不会造成不可逆的损害。已有落地案例通过Harness层进化，迭代次数减少70%、Token消耗降低80%+；在Agent Memory场景中Token节省超60%——这些收益全部来自"改配套系统"，一个模型参数都没动。

举个具体的例子。假设你的Agent在处理"日期格式转换"时经常出错。Artifacts层的做法是让Agent在本次任务中多试几次、自我纠错，这次做对了，但下次遇到同样的问题它不会更快。Harness层的做法是写一条Skill——"遇到日期格式转换时，先识别源格式再用对应的转换函数"——持久化保存，下次遇到直接follow这条Skill，不再犯错。Model层则是用大量正确样本微调模型，成本最高，也最根本。对绝大多数团队来说，写一条Skill就能解决问题，不需要微调模型。

评测的三重职责，和七个绕不开的难题

大多数团队把评测当作"上线前打个分"——跑一轮，看个数字，报告一下。在自进化系统中，评测承担的角色远不止于此，它至少有三重职责：方向指引，告诉系统哪里有问题，决定进化朝什么方向走；质量门控，更新Skill或Prompt前验证改了是否更好，防止退化；经验筛选，判断一次执行结果是值得沉淀的好经验，还是应该丢弃的坏经验。

传统评测只需要承担质量门控一个职责——上线前跑一轮，达标就放行，不达标就打回。但自进化场景下，评测多了两个全新角色，评测信号会直接流入记忆和Skill更新链路，影响Agent的长期行为。传统评测打错分顶多是"这次上线了一个不够好的版本"；自进化评测打错分是"Agent学到了错误经验并持续污染后续所有任务"。

评测系统面临一个结构性的精度、成本、覆盖面三难困境——精度高则成本高，成本低则覆盖窄，覆盖广则精度和成本都难控。没有银弹，只能分层组合。在这个三难困境之下，实践中会碰到七个具体难题，按最致命到最常见的顺序排列：

1. 弱评估器——用LLM给LLM打分，评估器自身可能有系统性偏差：偏好长文本、偏好特定格式、偏好表面正确性。这种偏差不是随机噪声，而是系统性的。一旦评估器有偏好长文本的偏差，Agent会在多轮进化中"学会"把答案写得越来越长，不是因为长更好，而是因为长能骗过评估器。
2. 评什么维度——Agent的输出是"推理过程+工具调用序列+中间结果+最终答案"的组合体。只看最终答案会漏掉大量问题：过程中产生了幻觉但碰巧最终答案对了，这种"虚假通过"下次大概率会翻车；工具调用冗余，做对了但消耗了5倍Token；推理链有错误但因为模型记忆力强"记住"了正确答案，换个问法就垮。
3. 评什么粒度——评整个任务成功或失败，便宜，但只知道错了不知道错在哪；评到每个step、tool call、决策节点，精确，但成本指数级增长，实测一轮完整的细粒度评测需要几百到上千次LLM调用。建议日常用粗粒度做快速筛选，对失败的case再用细粒度做深度归因。
4. 开放式任务难量化——编程任务可以跑测试、SQL可以对比结果，但写作、策略规划、方案设计这类任务怎么评？人工审查是最终权威，但不可扩展；纯LLM Judge又有弱评估器偏差。这也是为什么当前最成功的自进化案例大多出现在编码和确定性任务领域。
5. 评测集漂移——业务在变、用户需求在变、环境在变，但评测集往往半年不更新。Agent在旧集上刷出高分，你看着报告觉得一切很好，但线上用户的真实体验可能在持续下降。隐蔽性在于：没人会在评测全绿的时候去怀疑评测本身有问题。
6. 预算公平性——很多"自动进化"的性能提升，可能仅仅来自多花了计算预算，比如多次采样然后择优，或者让Agent重试几次取最好的。这种提升一旦关掉额外预算就打回原形。真正的进化应该是：在相同的Token预算下，Agent也比之前做得更好。
7. 评测成本——一轮完整评测可能需要几百次LLM调用。每次Skill或Prompt修改都跑全量，Token成本很快失控；但不跑又怕引入回归。解法是分层评测：每次改动跑轻量级回归，定期跑全量评测。

前四个难题的共性是，它们都在问评测信号本身是否可信。弱评估器、维度缺失、粒度不对、标准缺失，本质上都是信号质量问题。后三个难题则是另一类问题：信号的新鲜度和成本。

对开放式场景，一个方向性建议是：用偏好排序代替绝对打分，让评估器比较"A和B哪个更好"而非"A几分"，排序比打分更稳定；或者采用AI初筛加人复核的流水线，AI先过滤明显不合格的，人只审有争议的10-20%。

记忆系统的核心同样不是存储能力，而是治理能力。存得多不如治得好——版本控制、主动遗忘、冲突解决、来源溯源，这些"不性感"的治理能力才是决定记忆系统到底帮忙还是添乱的关键。

把这四个环节当作一个完整的工程系统来看，各自的核心矛盾是什么、应该怎么建设、有哪些坑必须避开，最重要的是它们之间怎么咬合起来形成一个持续转动的飞轮——这才是自进化真正要解决的问题。