Agent自进化飞轮：评测→记忆→落地→控制的完整工程闭环

当Agent系统上线运行半年后，我们往往会面临一个尴尬的现实：它依然在重复犯同样的错误，依然在走同样的弯路，依然像个新手一样处理曾经见过的场景。线上流量喂了无数，数据却一点经验都没攒下来。问题的根源不在于底层模型的能力不足，而在于缺乏一条从"做过"到"记住"再到"变好"的完整闭环。

自进化的三层架构：改什么决定进化的持久性

基于对学界前沿研究与业界验证实践的深度梳理，本文提炼出一套包含评测、记忆、落地、控制四个环节的Agent自进化方法论。这不是一个单点优化方案，而是一个经过验证的完整工程闭环——每个环节承担特定职责，环节之间通过数据通路紧密咬合，形成持续转动的飞轮效应。

第一齿：评测——整个飞轮的信号源

在展开四齿飞轮之前，首先需要明确"自进化"的具体内涵。根据改动对象的层次不同，自进化可分为三层。第一层是Artifacts迭代——改输出产物本身，如让Agent多次自我纠错后输出更好的代码或方案，但任务结束后Agent本身没有任何改变，下次遇到同类问题依然从零开始。第二层是Harness自改进——改Agent的配套系统，包括记忆、Skill文件、Prompt、工具配置等，这些改动持久化到文件或数据库，跨会话生效，改一次后续所有任务都受益。第三层是Model进化——通过Agent RL、自对弈微调等将经验写入模型权重，持久性最强但成本最高，目前仍处于研究阶段。 对于绝大多数团队而言，Harness层是当前最具性价比的进化方向。改完Skill或Prompt立即生效，不需要重训模型；改错了可以一键回滚，不会造成不可逆损害。实践数据表明，通过Harness层进化，迭代次数可减少70%，Token消耗可降低80%以上。

第二齿：记忆——核心是治理而非存储

评测系统是自进化飞轮的"眼睛"，负责感知系统哪里存在问题。在传统开发模式中，评测仅承担"质量门控"的单一职责——上线前跑一轮，达标就放行。但在自进化场景下，评测需要承担三重职责：方向指引告诉系统"下一步该往哪改"，质量门控验证"改了是否真的更好"，经验筛选判断"这次执行的经验值不值得沉淀"。 评测系统面临七大核心挑战，其中最致命的是弱评估器问题。使用LLM给LLM打分时，评估器可能存在系统性偏差——偏好长文本、偏好特定格式、偏好表面正确性。这种偏差不是随机噪声，而是系统性的：错误正反馈会让Agent"自信地学到错误经验"，相当于加速驶向悬崖。因此，评测的可信度必须优先于系统的复杂度——一个简单但评测可信的系统，远好于一个复杂但评测失真的系统。 评测体系的工程化建设需要回答四个核心问题：用什么手段评、评测集怎么管理、评完怎么处理结果、怎么确保评测器本身可信。手段上应遵循"能用规则就不用LLM"的原则，将LLM Judge留给真正需要的开放式任务；评测集管理推荐采用train/val/test三分法，严格职责分离防止过拟合；评测的终点不是打分而是诊断

第四齿：控制——人是正确性的保障

第四齿：控制——人是正确性的保障而非效率瓶颈 控制机制是飞轮的"方向盘和刹车"，确保进化方向不跑偏。完全自主的进化可能持续偏离正轨，完全人工驱动又效率太低。正确的做法是按场景分级自主、渐进放权、动态升降级——Agent在稳定领域高度自主，在新领域和高风险操作必须有人参与。 无论系统进化到什么程度，五个关键节点永远不能交给Agent：规则级记忆写入前（影响面是全局的，一条错误规则进入后可能长期不被发现）、Prompt/Skill更新的最终确认（特别是涉及安全边界和权限控制的改动）、评测发现回归时的决策（涉及业务影响面的判断）、新领域冷启动时的初始经验种子（飞轮无法自动转起来的第一圈）、安全边界的设定与调整（不能让Agent自己决定自己的权限边界）。 审核疲劳是落地中最常见的失败模式——什么都弹审核，人三天后直接通过，比没有审核更危险，因为它给了"有人审了"的虚假安全感。解法是在自动化门控层过滤掉95%的低质变体，让人只审"机器判断不了、需要人类语义理解"的最后环节；同时采用批量异步审核而非逐条实时弹窗，减少对人类工作的打断。

如有侵权，请联系删除。