最近读到一篇两万字的 Agent 自进化方法论，写得相当扎实。其中记了一条血泪教训：有团队在某个场景上连续 20 多轮自动迭代，效果一直不提升——最后发现根因根本不在配置层，而在工具层。20 多轮里，系统忠实地修 Prompt、改 Skill，每一轮都按评测信号在优化。
回头看，最惊人的不是根因藏得深，而是这 20 多轮里，没有一个人问过：这批评测 case 本身，选对了吗？
没人问，因为没人需要问——这份评测集没有主人。
这篇方法论（作者 yannisyang、ethanytzhou）把评测、记忆、落地、控制四个环节拆成飞轮：评测是眼睛，记忆是大脑，落地是手脚，人机协作是方向盘。四个齿怎么建、坑在哪、从零到一怎么落地，都讲了。它最有价值的一句话是：
大多数团队的问题恰恰在于：每个组件内部做得还行，但组件之间的「箭头」没有自动化。
飞轮的瓶颈不在齿，在齿与齿之间的通路。我完全同意——但沿着这句话再往下推一步，会发现一个这篇两万字没有回答的问题：
所有箭头里最上游的那一条——「什么叫好」——它的定义权在谁手里？
一、飞轮的四颗齿都造好了
先把这篇文章做对的地方说清楚，因为它确实做对了很多。
评测承担三重职责：上线前的质量门控、告诉系统往哪改的方向指引、判断经验值不值得存的筛选信号。记忆系统的核心论断是治理而非存储——坏经验的淘汰速度（-0.12）是好经验强化速度（+0.05）的 2.4 倍，因为一条错误记忆的伤害大于一条正确记忆的收益。落地是一条八环节流水线，作者直接把它定义成「Agent CI/CD」。控制这一齿最见功力：它引用 Anthropic 递归自改进报告的警告，提出了「对齐漂移」——每一步改动都通过门控，但每步偏一小步，累积十几个版本，方向已经偏了 90 度。
工程上能挑的毛病不多。问题出在一个更基础的地方。
二、评测集的三个证据，都指向同一个缺席
这篇文章给评测体系提了三个很硬的要求。每一个，都需要一个定义者：
证据一：评测集三分法——训练集、验证集、测试集严格分离，互不泄漏，还要定期把线上失败样本回流进来替换旧样本。谁来做这个回流和替换的决策？
证据二：方向性指标——为了防止对齐漂移，要监控平均输出长度、工具调用次数这类方向性指标，「这些指标的阈值由人设定，超出阈值就告警」。哪个「人」？
证据三：规则级记忆写入要人审——一条「遇到这类问题永远用方案 A」的规则进入全局记忆前必须人工确认。确认的人凭什么判断？凭的还是评测集里的标准。
三个证据，同一个缺口：这套方法论详细规定了评测集该怎么被使用，却从未规定评测集该被谁拥有。 全文两万两千字，「谁」这个字在评测集面前缺席了。
三、改评测集比改 Prompt 的权重大一个量级
这里需要把一个容易被低估的事实说清楚。
改 Prompt，改的是这一次怎么执行；改评测集，改的是「什么叫好」的标准。
| 改 Prompt | 改评测集 | |
|---|---|---|
| 影响范围 | 一次任务的执行方式 | 整个飞轮的转向标准 |
| 生效方式 | 随任务重写 | 存活数年，跨任务生效 |
| 错了的后果 | 一次输出不好 | 所有进化方向在暗处被带偏 |
| 类比 | 一条 SQL 语句 | schema + 权限表 |
一个组织的数据库如果让工程师爱改就改、没有变更审批、没有负责人——所有人都会觉得这不可接受。但评测集今天恰恰就是这个待遇：一份被随意维护的共享文件，「想到了就加几条，半年不更新」（原文对评测集管理现状的描述，一字不差）。
所以原文里那个「评测集漂移——数字漂亮但用户骂街」的现象，值得重新归因。它表面是维护问题，本质是所有权问题：一份文件半年没人更新，不是大家懒，是因为没有人对它负责。没有主人的文件，才会半年没人碰——就像没有人会去修一段没人认领的公路。
这也解释了那条血泪教训的另一半：某团队连续 20 多轮无效迭代，最后发现根因在工具层而非配置层。20 多轮里，为什么没有人质疑「这批评测 case 本身选对了吗」——因为没有人为评测集负责，于是也没有人有权力、有动机去推翻它。
最有力的反方会拿开源软件类比：Linux 内核没有单一作者，成千上万贡献者共同维护，质量反而很好——评测集为什么不能是社区共建、无主之物？因为评测集不是代码。代码的对错由编译器和测试裁决，是客观可验证的；评测定义的是「什么叫好」，而「好」在一个组织里是业务判断，不是技术判断——「这个回答够不够简洁」「这个方案的风险能不能接受」，没有编译器可以裁决。开源社区能共建代码，是因为代码有客观真相；评测集没有客观真相，它只有立场。立场必须有名字，否则没人能为它负责。
四、把评测集变成一份要签字的文件
在麦肯锡终于说了：Agent 也要绩效考核里，我给出的答案是「考卷由业务出，监考由平台做」——回答的是谁该造尺子。这篇把问题往前推一层：尺子造好之后，这份文件本身由谁持有、由谁签署、变更走什么流程。
组织要做的不是再造一套基础设施，而是把已有的治理机制对准评测集：
- 出题人署名。 每条评测 case 标注出题的业务负责人，就像考卷要有出题人签名。工程师可以录入和维护，但标准和判分归业务。
- 变更走治理。 评测集的修改和 Skill 更新用同一套门控：谁能提、谁批准、灰度观察、可回滚——我在数字员工的自我进化里写数据飞轮时就说过，飞轮的燃料是生产数据，但燃料的质检单必须有人签字。
- owner 写进台账。 每个评测集在绩效台账里有明确的责任人，和它考的 Agent 一样接受盘点。
回到飞轮那句话：大多数团队断在齿与齿之间的箭头上。但最深的那条断点不在技术——「什么叫好」这条最上游的箭头，从来没接过一个叫责任人的端点。
你的评测集是谁在维护？上一次有人为一条评测 case 签字，是什么时候？欢迎留言讨论。