立场 ①
瓶颈不是任何技术点,而是环节之间的衔接。评测信号要流进记忆与 Skill 更新,更新要被评测验证,验证结果要反哺下一轮——断任何一环,飞轮都不转。
立场 ②
评测的可信度 > 系统的复杂度。简单但评测可信的系统,远好于复杂但评测失真的系统;错误的正反馈会让 Agent 加速开往悬崖。
立场 ③
记忆的核心不是存储能力,而是治理能力。版本控制、主动遗忘、冲突解决、来源溯源——这些"不性感"的能力决定记忆帮忙还是添乱。
§〇 · 先对齐概念
自进化改的到底是什么?
为什么是现在:2026 上半年,斯坦福 CS329A 开课、Anthropic 发布递归自改进报告与 Dreaming 机制、EvoAgentX 等框架出现——领域正从"能不能做"跨向"怎么做好"。
"自进化"被用得很滥:有人把 Self-Refine(多改几版输出)叫自进化,有人把 Agent RL(训权重)叫自进化。改什么,决定了"进化"的持久性和价值——原文分了三层:
为什么 Harness 层是主战场?四个字:即时、可控——改完 Skill/Prompt 立刻生效,不必重训;改错了一键回滚,无不可逆损害。落地数据也在佐证:已有案例靠 Harness 层进化,迭代次数 -70%、Token 消耗 -80%+;Agent Memory 场景 Token 节省超 60%——一个模型参数都没动。
一个例子看懂三层:Agent 总在"日期格式转换"上犯错——Artifacts 层让它本次多试几次自我纠错(下次照旧);Harness 层沉淀一条 Skill"先识别源格式再用对应转换函数"(下次直接不犯错);Model 层用大量正确样本微调(最根本也最贵)。多数团队写到第二条就够了。
§一 · 飞轮第一齿
信号——评测不是打分,是整个飞轮的信号源
一个看不见自己缺陷的系统,不可能进化。
1.1 核心论断 · 评测的角色被严重低估
传统评测只承担质量门控(上线前跑一轮,达标放行)。自进化系统里它多了两重职责:方向指引——告诉系统哪里有问题、往哪改;经验筛选——判断一次执行值不值得沉淀。这意味着评测信号会直接流入记忆与 Skill 更新链路、影响 Agent 的长期行为:传统评测打错分,只是上线了一个不够好的版本;自进化评测打错分,是 Agent 学到错误经验并持续污染后续所有任务。评测的质量直接决定记忆的质量、Skill 更新的方向,以及飞轮正转还是反转。
1.2七大难题:先过"三难困境"
| 难题 | 一句话 | 机理与代价 | 解法方向 |
|---|---|---|---|
| ① 弱评估器 最致命 | LLM 给 LLM 打分自带系统性偏差 | 偏好长文本 / 特定格式 / 表面正确性。偏差不是随机噪声:评估器爱长答案,Agent 就在多轮进化里"学会"越写越长——不是长更好,是长能骗过评估器。 | 错误的正反馈比没有反馈更可怕;先校准评估器,再谈自动化。 |
| ② 维度缺失 | Agent 输出 ≠ 单一答案 | 输出 = 推理过程 + 工具调用 + 中间结果 + 最终答案。只看结果会漏:幻觉碰巧答对(虚假通过)、工具冗余(5 倍 Token 做对)、推理链错但靠模型记忆蒙对。 | 结果与过程都评;只评结果,盲区里的问题永远不会被发现。 |
| ③ 粒度失衡 | 粗便宜不能归因,细精准但指数贵 | 粗粒度只知道"60 分",不知是 Prompt 不清、Skill 有 Bug 还是 API 参数错,修复只能瞎改;细粒度评到每个 step / tool call,一轮要几百到上千次调用。 | 日常粗筛,失败 case 再细粒度深度归因——归因精度决定修复精度。 |
| ④ 开放式难量化 | "好方案"十个人十个判断 | 编码 / SQL 有确定性对错,写作、策略、方案设计没有;人工审查是最终权威但不可扩展。这也是当前最成功的自进化案例集中在编码与确定性任务的原因。 | 偏好排序代替绝对打分("A 与 B 哪个好"比"A 几分"稳定);AI 初筛 + 人只复核有争议的 10-20%。 |
| ⑤ 评测集漂移 新鲜度 | 数字漂亮,用户骂街 | 业务在变、评测集半年不更新;Agent 在旧集刷高分,线上体验持续下降。隐蔽在于:没人会在评测全绿时怀疑评测本身。 | 把线上新失败样本持续回流进评测集,保持分布新鲜。 |
| ⑥ 预算不公平 | "进化"可能只是多花了钱 | Best-of-N、多轮重试取最好——提升来自额外预算,关掉就打回原形。3 倍 Token 才好 10%,不是进化,是用钱砸分。 | 真正的进化 = 相同 Token 预算下做得更好;评估必须预算对等。 |
| ⑦ 评测成本 限制迭代频率 | 每次改动都跑全量吃不消 | 一轮全评几百次调用;不跑又怕回归。评测太贵导致一周一轮,飞轮就转得很慢。 | 分层评测:每次改动跑核心 case 轻量回归,定期跑全量。 |
①-④ 本质是"信号质量"问题,⑤-⑦ 是"信号新鲜度与成本"问题——原文按"最致命 → 最常见"排序。
1.3建设要点:四个问题搭一套可信评测
用什么手段评 → 评测集怎么管 → 评完怎么处理 → 评估器本身可信吗。
要点一 · 手段分层组合,把成本花在刀刃上
- 底层:规则 / 自动化校验——代码能跑、测试通过、SQL 结果匹配、格式合规、响应达标:零成本、100% 客观、无偏差。这是基石,却是被利用最少的层;能用规则校验的维度拿 LLM Judge 来评,纯粹浪费。
- 中间层:LLM-as-Judge + 对照实验,四条纪律——生成与评估模型必须分离(自评触发自洽偏差);评估 temperature=0(同输入同分数,可复现);输出结构化(Pydantic / JSON Schema 定义维度与标准,不许自由发挥);分维度独立评(一个调用同时评四五个维度,每维质量都会变差)。
- 顶层:人工抽样 + 元评测集——随机抽样人工二次评审,人与 Judge 不一致率超阈值就校准;另维护几十条"绝对正确 / 绝对错误"的元评测集定期抽检:连极端 case 都判错的评估器,所有打分都不可信,系统应告警。
要点二 · 评测集三分法(最容易被忽视的关键)
要点三 · 评测的终点不是打分,是诊断归因
分数不告诉你为什么。没有归因的评测,就像体检只说"不健康"却不说是哪里不舒服。归因之后按根因类型分流:
血泪教训
某场景连续 3 轮失败率 80%+ 不降——先停下来查工具实现层(API 参数错误、服务端异常、数据根本没回来),别再在配置层打转。配置层的进化解决不了工具层的 Bug;原文记录过 20+ 轮无效迭代、根因最终在工具层的案例。
要点四 · 谁来评测评测器?
评估器自身有系统性偏差时,它打的所有分都不可信——而这一点恰恰难以自知。四种互补机制:人工随机抽样二次评审(盯人机判断一致率)、元评测集定期抽检(绝对正误样本)、不一致率超阈值即校准、极端 case 判错即全线告警。
1.4Skill 评测的特殊性:证明"真的有用"比想象中难
很多 Skill 看似有效,实际只是与模型能力碰巧重叠——它的存在恰好等于 Agent 本来就会做的事。原文给的四层验证,层层淘汰一种假象:
第一层 · 对照实验
淘汰"贡献为零的 Skill"。有 / 无 Skill 两组跑同一批 case:无 Skill 也对,贡献就是零。跳过这步的团队,攒下一堆"看似有用实则占上下文窗口"的 Skill。
第二层 · 难度校准
淘汰"看不出差异的评测"。case 太简单,有無 Skill 都对,对照实验失真。要有难度梯度:模型无 Skill 时"半对半错",才测得出增量。
第三层 · 轨迹追踪
淘汰"占着位置没用上的 Skill"。答案对 ≠ follow 了 Skill。查执行轨迹(tool calls、推理链)里是否出现 Skill 定义的关键步骤:写了"先调 A 再调 B",轨迹里直接调了 C,就是没在用。
第四层 · 路径验证
淘汰"绕过关键步骤碰巧对"。轨迹里有相关调用,但绕过了 Skill 要求的格式校验——这次碰巧对,路径不对意味着下次翻车,即使这次结果正确。
工程化四条:上线前必跑对照实验;case 带难度梯度;引入 trace-level 评测(看路径不只看结果);定期复评——API 改了、需求变了,Skill 会过时。
§二 · 飞轮第二齿
积累——记忆的核心不是存储,而是治理
评测给了信号,但信号会随风消散——除非有系统把它"记住"。
2.1 核心论断 · 记忆做不好,比没有记忆更差
原文观察到的现实:多个团队加了长期记忆后因检索噪声过高,最终降级回无状态模式——记忆模块被默默关掉;而具备有效长期记忆的 Agent,体验与留存显著更好。矛盾数据说明难度被严重低估:不是"加个向量库存起来就行",存了召回不准、注入干扰,还不如不记。最重要的认知转变:把记忆当"治理系统"设计,而非"存储系统"——就像 Git 的价值不在"能存代码",而在版本控制、分支管理、冲突解决、审核流程。
2.2三环矛盾,十大难点
写入环 · 沉淀什么才有效
- ① 价值判断难——海量中间信息里,真有用的可能只是"这个 API 凌晨 3 点限流"。
- ② 正负反馈不对称——知道做对了,不知道因什么对;归因错的写入就是错的经验。
- ③ 粒度选择——太粗不能复用,太细信息过载,无统一标准。
- ④ 隐性知识难捕获——最有价值的是"什么不能做"这类负空间知识。
存储环 · 存了怎么不腐烂
- ⑤ 记忆污染——一条错误记忆在被发现前可能已影响数百次任务;蔓延远快于修复,最危险的失败模式。
- ⑥ 时效衰减——半年前的信息没人清理,产出"高置信的错误输出"。
- ⑦ 记忆冲突——来源不同互相矛盾,Agent 随机引用;多 Agent 并发写入更糟。
- ⑧ 成本失控——没有遗忘策略,量只增不减:更慢、更吵。
读取环 · 怎么用不出问题
- ⑨ 检索噪声——向量相似 ≠ 语义相关:"查订单状态"召回"取消订单";注入错误记忆比不注入更糟。
- ⑩ 上下文预算——注太多挤压工作空间、分散注意;注太少漏关键背景;缺自适应是通病。
写入环问"什么值得存",存储环问"怎么不腐烂",读取环问"怎么精准召回且不撑爆窗口"。
2.3写入:策展,而非全存
核心原则:Agent 不是录音机,而是策展人。只在明确的正信号(用户确认 / 评测通过 / 任务成功)时写入长期记忆,没有信号的中间过程默认不存;失败同样提取经验,但标记为反例 / 陷阱——"这条路走不通,因为 X"。一个明确的反例比一个模糊的正例更有价值。
2.4存储:分层架构 + 生命周期管理
2.5读取:渐进披露 + 严格预算
生命周期四件套:版本控制(每条带版本号 + 来源:哪个会话 / 谁触发 / 因何写入)、演化(沿时间线更新、合并、分裂、衰减)、主动遗忘(TTL 过期 / 使用频率衰减 / 负反馈快速淘汰)、冲突解决(后入优先 + 高冲突人工仲裁 + 乐观锁防并发)。
反直觉发现 · Anthropic Dreaming 2026.5
记忆建模为文件系统、让 Agent 用 Bash / grep 检索管理,比硬造专用 API 更有效——Agent 本就擅长操作文件,ls / grep / cat 是它最自然的交互方式。另一个值得关注的方向是符号化压缩:用 Mermaid 编码任务状态、完整日志外置,Agent 在符号图上推理、按 node_id 取证据——实测 Token 节省超 60%,任务通过率显著提升。
§三 · 飞轮第三齿
落地——从"知道问题"到"产出修复"之间有多远
评测发现了问题、记忆积累了经验;但从"知道"到"改好",有一个比想象中大得多的 gap。
3.1 核心论断 · 自动化 ≠ 全自动
"Agent 自己发现问题、自己改、自己上线"在当前阶段是危险的幻想:① LLM 生成的修复质量不可控——它看不到代码背后的历史决策、业务约束、API 规范,会"修复"问题 A 的同时覆盖上次人工精心调整的逻辑;② 单点修复缺乏全局视角——改 Skill A 解决问题 X,悄悄破坏了边界重叠的 Skill B,只是把问题推到另一侧;③ "总结经验→生成 Skill"本身需要专门优化——SkillOS 研究证明训练过的小模型策展人优于冻结的大模型策展人,不能假设"用好模型就行"。自动化覆盖"生成候选→评测验证→门控筛选"链路,关键决策必须有人——不是效率妥协,是正确性保障。
3.2完整链路:八个环节
3.3五个关键建设要点
要点一 · 三路信号汇聚
修复方向不能只看"这次哪些 case 失败了",至少汇聚三路:本轮评测诊断(这次出了什么问题)、历史 Playbook(以前什么改法有效 / 踩过什么坑)、Auto-Research 外部知识(业界有没有更好做法)。第三路专治平台期:原文实践中,系统自己搜到的两条有效方向都不在初始配置里。
要点三 · 灰度 + 回流
10% 流量灰度 × 7 天观测;盯四个指标:成功率不降、Token 不暴涨、延迟不恶化、无投诉。任何一项 P0 级退化 → 一键自动回滚,不等人判断——自动回滚是灰度的灵魂,否则半夜出问题没人兜底。灰度期的新失败样本自动进入下一轮种子池:有回流的系统,每转一圈都比上一圈信息更多。
要点四 · 版本化一切
这不是锦上添花,是生存基础设施。每次变更四要素:版本号(随时可回任意历史)、变更日志(谁改 / 为什么 / diff 可见)、来源标记(哪次评测触发、自动还是人工)、关联评测结果(在什么数据上验证、通过率多少)。排查链路才能走通:异常 → 定位版本 → 看 diff → 看评测 → 决定回滚点。
要点五 · Diff 模式修复
LLM 全文重写 Skill 三宗罪:覆盖无关逻辑、reviewer 看不出改了什么、无法精准回滚。Diff 模式只输出修改片段、框架负责 patch 合并——改动一目了然、不碰无关区域、哪个 patch 有问题撤哪个。多文件联动要加 AST 签名验证:确认跨文件调用与数据接口没因单侧修改而不兼容——多 Skill 联动改写导致的隐蔽回归是最难排查的问题之一。
3.4Dreaming:异步的"做梦"式进化
同步进化抓不到跨会话的系统性模式:过去 100 次会话里 30 次在"时间格式转换"上出小错——单看都是偶发,合看是系统性短板。Anthropic Dreaming(2026.5)给了一条互补路径:
同步评测 · "每次作业批改"
解决"单次任务做得好不好":快速反馈、针对性强,抓具体错误。
Dreaming · "期中总结"
空闲时运行的异步进程,定期审阅一批历史轨迹,找三类模式:反复出现的失败、低效弯路(成了但绕远、烧 Token)、知识缺口(反复查外部资料的领域)。输出带优先级的修订建议列表,只建议不修改,决定权在人;高价值建议走正式八环节。
实操:每天或每周跑一次(看会话量);输入最近 N 天完整轨迹(成功 + 失败);输出结构化建议(优先级 + 影响面);人工审阅后进入进化流水线。
§四 · 飞轮第四齿
控制——人不是效率的瓶颈,是正确性的保障
完全自主可能跑偏,完全人工又太慢;关键是找到平衡点。
4.1 核心论断 · 人是教练和裁判,不是操作者
"完全放手"与"事事把控"是错误的二选一。正解:按场景分级自主、渐进放权、动态升降级——稳定领域高度自主,新领域与高风险操作必须有人;关键不是"人参不参与",而是"人在什么节点、以什么方式参与"。为什么不能全放手:Anthropic《When AI builds itself》(2026.6)警告,AI 自主迭代修改自身配置会产生隐蔽且累积的偏移——每次改动单独看都合理,累积起来已偏离初始意图;飞轮在自动转,错误被放大的速度与转速成正比。
4.2分级自主模型
4.3五个必须有人的节点
无论 Level 多高,这五处不许交给 Agent——不是"当前技术做不到"的权宜之计,是设计上的刚性约束。
①
规则级记忆写入前
"这类问题永远用方案 A"会被无条件遵循、影响全局;Agent 执行规则时不再质疑规则,错误可长期潜伏。人工确认每次只花几秒,避免的损失巨大。
②
Prompt / Skill 更新最终确认
尤其安全边界、拒答逻辑、权限控制。Agent 不应有能力修改自己的安全约束——如同程序不应有权改自己的权限配置文件。
③
发现回归时的决策
回滚到哪个版本、优先级多高、阻断全部还是冻结局部——涉及业务影响面判断,Agent 缺上下文。
④
新领域冷启动的种子
第一批评测 case("什么叫好")+ 初始 Skill("大致怎么做")+ 安全边界("什么绝不能做")。第一圈必须人推,跳过 = 在错误方向快速迭代。
⑤
安全边界的设定与调整
能改什么、不能改什么,这条线必须人画;让 Agent 自己决定自己的权限,就会出现逐步扩张、累积失控的偏移。
4.4审核疲劳:最常见的失败模式
理想是"关键节点有人审";现实是什么都弹审核,人三天后不看直接点通过——比没有审核更危险,因为制造了"有人审过"的虚假安全感。本质原因:到人手上的东西质量太差、数量太多(每天 50 个请求里 48 个本可自动过滤,等真正要紧的 2 个到来时,注意力已经耗尽)。三层解法:
- 自动化前四层门控——语法 / 回归 / 显著性 / Playbook 一致性全自动,95% 低质变体到不了人面前;人的注意力只花在机器判断不了的语义理解上。
- 批量异步审核——攒一批(一天或一个迭代周期)一次呈现:每个候选附评测数据、影响面、2-3 组代表性输入输出对比、AI 推荐理由。让人做批量选择题("这 5 个里哪些能上?"),不是逐条弹窗("这个批不批?再来一个……")。
- 渐进放权 + 自动降级——连续 3 个月稳定(通过率 >95%、无 P0、抽检无问题)可升 Level 2;升级后出回归自动降回 Level 1。信任通过实践积累,违反立刻收回。
4.5更深一层:进化方向如何与人类意图对齐
门控、回滚、审核都是技术层控制;更难的是对齐漂移:你想要"回答准确且简洁",但评测信号无意中奖励"详细"(更容易包含正确内容、得分更高)——多轮进化后 Agent 越来越啰嗦,每一步都在涨分,方向却已经偏了。门控抓不住它:门控检查"这次改动有没有回归"(局部),不检查"整体方向是否偏了一小步"(全局)——步步都能过,步步都在偏;等发现时可能已偏了十几个版本,连从哪开始偏都不知道。
类比 · 迷雾中走路
每一步都检查了"这一步有没有掉进坑里"(门控通过),但没有人检查"这一百步加起来,你还朝着目的地走吗"——可能已经偏了 90 度。门控解决安全性,不解决方向性;方向需要更高维度的观测。
原文的三层防护:
防护 ①
定期方向性审计(最关键)
每月半天,人工审进化轨迹:Skill 库在朝什么方向发展?记忆在积累哪类经验、有无异常?输出风格在变吗(更长 / 更保守 / 更激进)?与最初设计意图还一致吗?
防护 ②
方向性约束指标
除结果指标外,监控:平均输出长度(不能持续增长)、工具调用次数(不能越来越多)、拒答率(不能持续走高或走低)。阈值由人设,越线即告警。
防护 ③
评测集显式含"意图对齐"维度
不只评"答案对不对",还评"风格对不对"——专设 case 检查简洁性、格式规范性、语气合适度,把抽象意图具象为可评测维度。
§五 · 装配
飞轮——四个齿怎么咬合起来持续转动
拆开来做,每一块都能说"我做了";合在一起产生复利,靠的是环节之间的"箭头"。
5.1四条数据通路
飞轮转起来的前提:每个环节的输出恰好是下一个环节的输入。四条通路,断一条卡一台:
通路 ① · 评测 → 记忆
评测产出"好经验"信号,触发策展式写入。断了会怎样:做对了也不记住,每次从零开始。
通路 ② · 评测 → 落地
评测产出"问题 / 差距"诊断信号,驱动修复方案生成。断了会怎样:知道有问题,但不会去改。
通路 ③ · 落地 → 控制 → 生效
修复候选经五层门控与人工确认,灰度上线。断了会怎样:方案永远停在"候选",从不真正影响 Agent 行为。
通路 ④ · 生效 → 下一轮评测(回流)
新表现被下一轮评测捕获:成功入金标集,新失败回流为种子。断了会怎样:进化是一次性的;有了它,每转一圈都比上一圈信息更多。
多数团队的问题恰恰是:组件内部做得还行,组件之间的"箭头"没有自动化——评测结果躺在报告里、记忆存了没人回来验证、Skill 改了没有灰度直接全量。
5.2启动与持续
飞轮的物理特性冷酷而有用:推动静止的飞轮转过第一圈要很大的力,转起来之后维持转动的力小得多。
启动能量 · 人工推力,不能省不能跳
- 高质量的初始评测集——飞轮的"眼睛",第一批质量差(覆盖不全 / 标准不清 / 难度不当),系统从第一天就往错误方向跑;值得花 1-2 周精心设计。
- 人工注入的第一批 Skill / 记忆——白板状态下给初始方向:"这类问题大致这样处理""我们的系统架构是这样的"。
- 清晰的安全边界——自主进化开始前先画好"什么绝对不能做";越早越好,飞轮转起来后错误扩散速度与转速成正比。
持续动力 · 自动回流,越转越快
- 失败样本自动回流——灰度与线上监控发现的新问题自动导入进化流水线,是"燃料供应"。
- 成功经验按晋升规则自动升级——临时记录 → 多次验证 → 正式 Skill,满足条件自动触发,不需人判断"何时该升"。
- Dreaming 巡检跨会话模式——单次评测看不到的全局问题由异步进程定期发现,产出进种子池。
- Auto-Research 防方向枯竭——内部经验用尽时自动搜论文 / 开源项目引入新方向,防止飞轮停转。
5.3什么场景最容易跑通
已跑通全闭环的案例(工单自动修复:解决率从不到 30% 到近 90%;内容推荐:真实 CTR 驱动;长期记忆增强:LongMemEval 显著提升)共享两个特征:
- 评测信号来自真实业务指标,而非人工构造——真实 CTR、拒审率、工单解决率天然不存在评测集漂移:业务在变,指标跟着变。有天然业务指标可用就优先用它,那是飞轮最自然的燃料。
- 闭环链路短、反馈延迟低——从"发现问题"到"修复生效"链路越短,飞轮转得越快、团队越快看到收益。实践经验:5 轮迭代内能看到显著提升;需要 20 轮才见效的设计,团队早就失去耐心了。
5.4从零到一的落地路线
收束三条原则,一个范式判断
原则一
评测的可信度 > 系统的复杂度。评测不可信的系统,自动化程度越高、犯错速度越快。先擦亮"眼睛",再让"手脚"动起来。
原则二
记忆是治理问题,不是存储问题。向量库不是记忆系统;存 100 条低质记忆,不如治理好 10 条高质量的。
原则三
闭环的价值在环节之间的衔接,而非单个环节的先进性。大多数团队不是哪块做得不好,而是数据通路是断的。
范式判断
自进化不是一个功能,是一种系统设计范式:核心不是"让 Agent 自动变聪明",而是搭一套工程闭环——让每一次执行都不白费,每一个教训都不白吃,每一次改进都经过验证。最难的部分不是任何技术环节,而是让四个齿轮咬合在一起,持续地转。