我把 Agent 自进化飞轮拆成了四件事：评测、记忆、落地、控制

最近一段时间，我一直在研究一个词：Agent 自进化。

起因很实际。我在复盘几个 Agent 项目时发现一个普遍现象：评测、记忆、Self-Improve 这三件事，几乎每个团队都在做，但都是拆散了做的——

• 评测团队搭了一套评分系统，跑完打个分就结束，分数去了周报，没有流进 Prompt 或 Skill 的改进链路；
• 记忆团队做了一套向量检索，存了一堆对话历史，但召回噪声太高，Agent 反而被干扰，最后记忆模块被默默关掉；
• Self-Improve 团队在探索 Skill 自动生成，但生成的 Skill 质量参差不齐，没有评测筛选好坏，也没有版本管理来回滚。

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

我后来把这件事想明白了：这三件事不是三个独立的功能点，它们是同一个闭环的不同环节——评测是闭环的「眼睛」，记忆是闭环的「大脑」，落地（Self-Improve）是闭环的「手脚」，人机协作是闭环的「方向盘和刹车」。拆开来做，每一块都能说「我做了」，但合在一起不产生复利，因为环节之间的数据通路是断的。

这篇笔记，是我最近把 Agent 自进化方法论完整梳理了一遍之后，用第一人称写下来的理解与实践清单。

先对齐：自进化改的到底是什么？

在聊「怎么搭」之前，必须先对齐「改什么」。因为「自进化」这个词被用得很滥：有人拿 Self-Refine（让 Agent 多改几版输出）叫自进化，有人拿 Agent RL（训模型权重）叫自进化——它们是完全不同的东西。区别在于改什么，这决定了「进化」的持久性和价值：

为什么 Harness 层是主战场？四个字：即时、可控。改完 Skill/Prompt 立刻生效，不需要重训模型；改错了一键回滚，不会造成不可逆损害。这里有一组我核对过的实测数据，全部来自「改配套系统」，一个模型参数都没动：

• 某云服务团队的 EvoLoop 实践：迭代次数减少 70%、Token 消耗降低 84%、修复解决率从 29.5% 提升到 89.8%；
• 某云数据库团队开源的 Agent Memory 项目：Token 节省 61%，通过率从 33% 提升到 50%。

我的判断很直接：对绝大多数团队来说，写一条 Skill（Harness 层）就能解决问题——不需要微调模型。

齿一：信号（评测）——飞轮的第一齿

一个看不见自己缺陷的系统，不可能进化。评测在自进化系统里至少承担三重职责：方向指引（告诉系统哪里有问题）、质量门控（改了是否更好）、经验筛选（这次执行值不值得沉淀）。传统评测只承担「质量门控」一个职责，而自进化多了两个全新角色——这意味着评测信号会直接流入记忆和 Skill 更新链路，影响 Agent 的长期行为。

最致命的坑：弱评估器

用 LLM 给 LLM 打分，听起来优雅，但评估器自身可能有系统性偏差：偏好长文本（详细但冗余的答案得高分）、偏好特定格式（有编号列表比段落式得高分）、偏好表面正确性（引用了数据但数据是编造的也得高分）。

这种偏差的可怕之处在于：它不是随机噪声，而是系统性的。一旦评估器偏好长文本，Agent 会在多轮进化中「学会」把答案写得越来越长——不是因为长更好，而是因为长能骗过评估器。错误的正反馈比没有反馈更可怕——它让 Agent「自信地学到错误经验」，相当于加速开往悬崖。

我在公开研究里也找到了印证：2026 年顶会上有一篇论文专门研究 LLM 评估器的自偏好问题——让模型评估自己的输出会显著高估质量。所以「评估模型 ≠ 生成模型」这条铁律不是洁癖，是保命。

评测体系的七个难题

实践中评测面临的是一个结构性的精度 × 成本 × 覆盖面三难困境，展开成七个具体难题：

1. 弱评估器（最致命，见上）；
2. 评什么维度——Agent 输出是「推理过程 + 工具调用序列 + 中间结果 + 最终答案」的组合体，只评最终答案会漏掉「虚假通过」（过程中幻觉但答案碰巧对了）、工具冗余（做对了但消耗 5 倍 Token）等问题；
3. 评什么粒度——粗粒度便宜但只说「错了」不说「错在哪」，细粒度精确但成本指数级增长。建议日常用粗粒度快速筛选，对失败 case 再用细粒度深度归因；
4. 开放式任务难量化——写作、策略规划这类任务没有确定性对错标准。方向性建议：用偏好排序代替绝对打分（「A 和 B 哪个更好」比「A 几分」稳定），或 AI 初筛 + 人复核流水线；
5. 评测集漂移——业务在变但评测集半年不更新，Agent 在旧集上「刷出高分」，线上体验却在下降。而且没人会在评测全绿的时候怀疑评测本身有问题；
6. 预算公平性——很多「进化」的提升可能只是 Best-of-N 多花了钱。真正的进化是：相同 Token 预算下，Agent 也比之前做得更好。新方案耗 3 倍 Token 才比旧方案好 10%，这不是进化，是用钱砸分；
7. 评测成本——一轮完整评测可能几百次 LLM 调用，每次改动都跑全量吃不消。解法是分层评测：每次改动跑轻量级回归，定期跑全量。

怎么搭一套可信的评测体系

我的经验是四件事：

第一，评测手段分层组合，把成本花在刀刃上。底层用规则/自动化校验（代码能跑、测试通过、SQL 结果匹配）——零成本、100% 客观，但大多数团队没有充分利用，很多本可以用规则校验的维度却在用 LLM Judge 浪费钱；中间层用 LLM-as-Judge + 对照实验，记住几条铁律：生成模型和评估模型必须分离、评估 temperature 设为 0（可复现）、输出必须结构化（Pydantic/JSON Schema）、分维度独立评估；顶层用人工抽样 + 元评测集（几十条「绝对正确/绝对错误」的极端样本，定期检查评估器是否还认得）。

第二，评测集要工程化管理——train/val/test 三分法，严格职责分离。train 集只用于诊断（暴露给 LLM 没问题）；val 集只用于筛选候选，绝不暴露给生成修复方案的 LLM——否则 LLM 会「记住」val 集的答案；test 集只用于最终验证，独立把关。三者互不泄漏，且都要定期更新防漂移。比例建议 train 50-60% / val 20-30% / test 15-20%，按问题类型分层抽样。

第三，评测的终点不是打分，是诊断归因。分数告诉你「60 分」，但不告诉你为什么。评完必须按失败类型分组、分析失败模式、定位根因，然后分流：系统性问题 → 触发 Skill/Prompt 更新并写入 Playbook；偶发个例 → 写入记忆作为反例；能力缺失 → 触发工具补充；回归问题 → 立即回滚、人工排查。归因的粒度决定修复的精度——「这个 Skill 不好」只能大面积重写，「参数提取阶段的正则漏了 YYYY-MM-DD 格式」才能精准修复。

第四，评估器本身也需要被评测。人工抽样比对、元评测集校验、校准告警、分维度交叉验证，四管齐下。

Skill 评测的特殊性：证明 Skill 「真的有用」比想象中难

Skill 是 Harness 层进化的核心产出物，但很多 Skill 看似有效，实际上只是和模型能力碰巧重叠。至少要过四层验证：

1. 对照实验——有 Skill 和无 Skill 两组对照。无 Skill 也能做对？那 Skill 贡献为零，只是浪费上下文；
2. 难度校准——case 太简单看不出差异，要设计有难度梯度的 case，让模型处在「无 Skill 时能做对一部分」的水平；
3. 轨迹追踪——运行时真的调用 Skill 了吗？常见假象：Skill 在上下文里，Agent 却靠自身能力做对了，Skill 只占位没被使用；
4. 路径验证——结果对了但路径对吗？绕过了 Skill 的关键校验步骤，这次碰巧对，下次就会翻车。

齿二：记忆（积累）——把信号「记住」

评测给了信号，但信号会随风消散——除非有一个系统把它「记住」。而记忆系统最反直觉的一点是：记忆做不好，比没有记忆更差。多个团队在尝试加长期记忆后，因为检索噪声过高，最终降级回无状态模式——记忆模块被默默关掉。

所以最重要的认知转变是：把记忆系统当作一个「治理系统」而非「存储系统」来设计。就像代码仓库——Git 的价值不在于「能存代码」，而在于版本控制、分支管理、冲突解决这些治理能力。存得多不如治得好。

写入：Agent 不是录音机，而是策展人

• 正信号触发写入：只有收到明确的正信号（用户确认 / 评测通过 / 任务成功）才写入长期记忆，没有信号的中间过程默认不存；
• 失败也有价值，但存法不同：失败任务提取经验后标记为「反例/陷阱」——「这条路走不通，因为 XX 原因」。一个明确的反例比一个模糊的正例更有价值；
• 三层晋升机制：先用低门槛解决「忘记记录」，再通过门槛层层筛选把有价值内容往上升级，越往上质量越高、噪声越少；
• 非对称淘汰设计：好经验强化速度（+0.05）远慢于坏经验淘汰速度（-0.12），淘汰是强化的 2.4 倍。逻辑：一条错误记忆的伤害 > 一条正确记忆的收益。宁可慢一点积累好经验，也不能让坏经验扩散。

存储：分层架构 + 生命周期管理

分层架构已经是业界共识：开源的 Hermes Agent、某云数据库团队开源的 Agent Memory 等都在验证。其中一个很值得参考的划分是：L0 原始对话 → L1 原子事实 → L2 场景块 → L3 用户画像，核心是「默认 L3，按需钻取 L1/L0」。分层让存储有结构、召回有层次，而不是什么都存一个池子全凭向量相似度。

生命周期管理上，四条必须做：版本控制（每条记忆带版本号 + 来源标记）、演化能力（记忆沿时间线更新/合并/分裂/衰减）、主动遗忘（TTL / 频率衰减 / 负反馈标记）、冲突解决（后入优先 + 人工仲裁高冲突项 + 乐观锁防并发）。一句话：「团队记忆首先是一套治理系统」——没有治理，错误信息传播的带宽也会提高。

读取：渐进披露 + 严格预算

记忆注入不能撑爆上下文。我遵循的模型是「从粗到细、按需钻取」：

• Step 1：默认只注入顶层（Persona + Skill 前言，约 500-800 token）；
• Step 2：任务到来时按需检索中层——三路并行（语义向量 + 全文关键词 + 精确匹配），融合排序取 Top-K；
• Step 3：只有执行中遇到困惑或需要证据时，才通过 node_id 回溯到原始对话。

严格预算：Skill ≤ 2000 token、Facts ≤ 800、Profile ≤ 500，单条 ≤ 200 token（强制精炼），最多注入 6 条（少而精），再按任务复杂度动态调整（Pain-aware）。

两个值得关注的新方向：一是 Anthropic Dreaming（2026.5） 把记忆建模为文件系统，让 Agent 用 Bash/grep 检索管理——Agent 本就擅长操作文件，ls/grep/cat 是它最自然的交互方式，比硬造专用 API 更有效；二是 符号化压缩——用 Mermaid 编码任务状态，Agent 在符号图上推理、需要时通过 node_id 检索，实测 Token 节省 61%、通过率从 33% 提升到 50%。

齿三：落地——从「知道问题」到「产出修复」有多远

评测发现了问题，记忆积累了经验，但从「知道」到「改好」之间，有一个比想象中大得多的 gap。

自动化 ≠ 全自动

很多人对「自进化」的想象是 Agent 自己发现问题、自己改、自己上线——全程无人。这在当前阶段是危险的幻想：LLM 生成的修复质量不可控（它看不到代码背后的历史决策和业务约束）；单点修复缺乏全局视角（改了 Skill A 可能悄悄破坏 Skill B）；「总结经验→生成 Skill」本身需要专门优化（有研究证明训练过的小模型策展人优于冻结的大模型策展人）。

我的观点：自动化覆盖「生成候选 → 评测验证 → 门控筛选」链路，但关键决策必须有人把关。不是效率妥协，是正确性保障。

完整链路有八个环节

从「评测发现问题」到「改进真正生效」，我拆出了八个环节，断了任何一环进化就停滞：① 诊断归因 → ② 信号汇聚 → ③ 生成候选 → ④ 独立评测 → ⑤ 安全门控 → ⑥ 灰度发布 → ⑦ 监控回流 → ⑧ 经验沉淀。

几个关键细节：

• 信号汇聚要三路：本轮评测诊断 + 历史 Playbook + 外部知识（Auto-Research）。只看单一信号容易陷入局部最优，有一组内部实践验证过：系统自己发现的两条有效方向都不在初始配置里；
• 生成候选用 Diff 模式：只输出需要修改的部分，而不是全文重写——全文重写风险极大，容易覆盖无关的正确逻辑，改动也无法 review；
• 独立评测：每个候选必须在隔离环境验证，多个候选不能在同一环境跑，避免互相干扰；
• 安全门控分五层：语法检查 → 回归检测 → 统计显著性 → Playbook 一致性 → 人工确认。前四层全自动过滤 95% 低质变体，人只审「大概率有效」的少量候选；
• 灰度 + 自动回滚：10% 流量 × 7 天观测期，监控成功率、Token 消耗、延迟、用户反馈。任何一项 P0 级退化 → 一键回滚，不需要等人判断——自动回滚是灰度机制的灵魂；
• 回流机制：灰度期间新积累的失败样本自动进入下一轮进化的种子池。上线不是终点，而是下一轮进化的起点；
• 版本化一切：Skill / Prompt / 记忆的每次变更必须有版本号、变更日志、来源标记、关联评测结果。这是自进化系统的生存基础设施——因为系统在持续修改自己，修改不可追溯不可回滚，出了问题就是灾难。

Dreaming：异步的「做梦」式进化

前面讲的都是同步进化——评测发现问题立即修复。但有一类问题是同步进化抓不到的：跨会话的系统性模式。比如 Agent 过去 100 次会话里，有 30 次在「时间格式转换」上出小问题，每次都不完全相同，单看都是「偶发个例」，合在一起却是系统性短板。

Anthropic Dreaming 机制就是解决这个的：一个专职的异步进程，在空闲时像「睡觉做梦」一样定期审阅一批历史会话轨迹，寻找反复出现的失败模式、低效模式（任务成功但走了很多弯路）、知识缺口（反复需要查外部资料的领域），输出结构化修订建议。最终决定由人完成——Dreaming 只负责发现和建议，不直接修改。同步评测像「每次作业批改」，Dreaming 像「期中总结」——退一步看全貌。

齿四：控制——人不是效率的瓶颈，是正确性的保障

完全自主的进化可能跑偏，完全人工驱动又太慢。关键是找到平衡点。

分级自主，渐进放权

按场景分级自主：Agent 在稳定领域高度自主（Level 3），在新领域和高风险操作必须有人。升级条件：通过率持续 > 95%、连续 N 周期无回归；降级触发：出现 P0 回归 → 自动降回 Level 1 直到修复。不可逆红线：安全边界 / 拒答逻辑 / 付费相关变更永远不能 Level 3。

为什么完全放手是危险的？Anthropic 在 2026 年 6 月的《When AI builds itself》报告里专门警告：AI 在自主迭代修改自身配置时，可能导致行为发生隐蔽且累积的偏移——即使每次单独改动看起来合理，累积起来可能已经偏离初始意图。在 Harness 层同样成立——而且由于飞轮在自动转，一个错误被放大的速度和飞轮转动的速度成正比。报告发布后媒体都在讨论「人类可能失去控制」，但我觉得更实际的解读是：失控不是「AI 觉醒」，而是工程上没给飞轮装刹车。

五个必须有人的关键节点

无论 Level 多高，这五个节点永远不能交给 Agent——这是系统设计上的刚性约束：

1. 规则级记忆写入前——规则级记忆会被无条件遵循、影响面全局，一条错误规则进入集群记忆后可能长期不被发现；
2. Prompt/Skill 更新的最终确认——特别是涉及安全边界、拒答逻辑、权限控制的改动。Agent 不应该有能力修改自己的安全约束，就像程序不应该有权限修改自己的权限配置文件；
3. 评测发现回归时的决策——回滚到哪个版本？修复优先级多高？这需要人来判断业务影响面；
4. 新领域冷启动时的初始经验种子——没有历史数据的新场景，飞轮无法自动转起来，需要人提供第一批评测 case、初始 Skill、安全边界。这是「手推飞轮第一圈」的动作；
5. 安全边界的设定与调整——Agent 能改什么不能改什么，这条线必须人画。让 Agent 自己决定权限边界，就会出现报告里警告的「隐蔽且累积的偏移」。

审核疲劳：落地中最常见的失败模式

理想：关键节点有人审。现实：什么都弹审核，人三天后不看直接通过——比没有审核更危险，因为它给了「有人审了」的虚假安全感。

解法三层：层级一，自动化前四层门控，把 95% 的低质变体在到人之前过滤掉；层级二，批量异步审核而非逐条实时弹窗——攒一批（一天或一个迭代周期的产出）一次性呈现，附上评测数据、影响面、代表性输入输出对比和 AI 推荐理由，让人做「这 5 个候选哪些能上」的选择题，而不是「这个改你批不批」的填空题；层级三，渐进放权 + 自动降级——稳定运行 3 个月可升级为事后抽检，一出现回归立刻自动降回，让审核制度本身也能进化。

对齐漂移：进化方向如何与人类意图对齐

最后一个更深层的问题：Agent 的进化方向如何确保和人的长期意图一致？举例：你希望 Agent「回答准确且简洁」，但评测信号无意中奖励了「详细」——多轮进化后，Agent 越来越啰嗦，每一步看起来都在「变好」（评测分确实在涨），但累积起来方向偏了。

技术门控抓不住这种漂移，因为门控检查的是「这次改动有没有引入回归」（局部视角），不检查「这次改动是否让整体方向偏了一小步」（全局视角）。每一步都能通过门控，但步步偏移。我常用的一个类比：你在迷雾中走路，每一步都检查了「这一步有没有掉进坑里」（门控通过），但没人检查「这一百步加在一起，你还朝着目的地在走吗？」——可能你已经偏了 90 度。

三层防护：① 定期方向性审计（每月半天，人工审查进化轨迹与初始意图是否一致，最关键）；② 方向性约束指标（监控平均输出长度、工具调用次数、拒答率，超出阈值告警）；③ 评测集显式包含「意图对齐」维度（有几个 case 专门检查简洁性、格式规范性、语气合适度——把抽象的「意图」具象化为可评测的维度）。

飞轮怎么咬合起来

前四章分别讲了信号、积累、落地、控制。但拆开来做每一块都能说「我做了」，关键是它们怎么咬合成一个持续转动的飞轮。

四条关键数据通路

• 通路一：评测 → 记忆——评测产出「好经验」信号，触发记忆写入。断了：Agent 做对了但不会记住，下次从零开始；
• 通路二：评测 → 落地——评测产出「问题/差距」信号，驱动修复方案生成。断了：Agent 知道自己有问题但不会去改；
• 通路三：落地 → 控制 → 生效——修复方案经过门控和人工确认后灰度上线。断了：修复方案永远停在「候选」状态；
• 通路四：生效 → 下一轮评测（回流）——更新后的表现被下一轮评测捕获，新失败回流为种子。这条通路是飞轮持续转动的关键——没有它，进化是一次性的。

大多数团队的问题恰恰在于：每个组件内部做得还行，但组件之间的「箭头」没有自动化。

启动与持续

飞轮有一个冷酷的物理特性：静止的飞轮需要很大的力才能推动第一圈，但一旦转起来，维持转动的力就小得多。

启动能量（人工推力，不能省）：高质量的初始评测集（值得花 1-2 周精心设计）、人工注入的第一批 Skill / 记忆、清晰的安全边界。持续动力（自动回流）：线上新失败样本自动回流为种子、成功经验按晋升规则自动升级为 Skill、异步 Dreaming 持续发现跨会话模式、Auto-Research 引入外部知识防止方向枯竭。

什么场景最容易跑通？

观察已跑通完整闭环的案例，它们共享两个特征：

• 特征一：评测信号来自真实业务指标，而非人工构造。有的用真实 CTR 和拒审率，有的用真实工单修复成功率。真实指标天然不存在评测集漂移——业务在变，指标跟着变；
• 特征二：闭环链路短、反馈延迟低。有一组实践是 5 轮迭代内就能看到显著提升——如果系统要跑 20 轮才见效，团队大概率早就失去耐心了。

从零到一：四阶段落地路线

核心建议：先跑通 Phase 1。一个能手动转一圈的粗糙飞轮，好过一个精美但静止的蓝图。很多团队的错误是 Phase 1 还没验证就开始搭 Phase 3 的基础设施，最后发现闭环本身就没跑通。Phase 1 的目的不是自动化，而是验证闭环是否成立——如果手动都跑不通，自动化只会更快地暴露问题。

最后：三条原则收束

把整个飞轮压缩成三条原则，也是我以后做任何 Agent 项目都会先对照的 checklist：

1. 评测的可信度 > 系统的复杂度。在搭任何自动化之前，先确保评测信号是准的。评测不可信的系统，自动化程度越高，犯错速度越快。先把「眼睛」擦亮，再让「手脚」动起来；
2. 记忆系统是治理问题，不是存储问题。向量库不是记忆系统。版本控制、主动遗忘、冲突解决、来源溯源、晋升门控——这些「不性感」的治理能力才决定记忆系统是帮忙还是添乱。存 100 条低质记忆不如治理好 10 条高质量记忆；
3. 闭环的价值在于环节之间的衔接，而非单个环节的先进性。评测信号必须能自动流进记忆和 Skill 更新链路；更新后必须能被评测自动验证；验证结果必须能自动反哺下一轮进化。这些环节之间的「箭头」，才是飞轮能不能转的决定因素。

自进化不是一个功能，是一种系统设计范式。它的核心不是「让 Agent 自动变聪明」，而是搭建一套工程闭环，让每一次执行都不白费、每一个教训都不白吃、每一次改进都经过验证。这件事最难的部分，不是任何一个技术环节，而是让四个齿轮咬合在一起，持续地转。

我自己的下一步计划也列在这里，算是立个 flag：

• 先给我手头的 Agent 项目补一套可信的评测集（三分法 + 元评测集），哪怕先手动跑；
• 把记忆模块从「什么都能存」改成「策展式写入 + 分层存储」；
• 所有 Skill 变更强制走 Diff + 版本化 + 灰度，绝不让自动修改直接全量生效；
• 给飞轮装好刹车：五个刚性人审节点 + 每月一次方向性审计。

如果你也在搭 Agent 自进化，欢迎在 GitHub 上和我交流。代码会继续变化，方法论也会继续迭代——但先把四个齿轮咬合上，让飞轮转起来，这个方向不会错。