很多人现在一提 eval，脑子里冒出来的还是老三样：题库、benchmark、离线跑分、回归测试。这个思路在过去不是错的。问题是，今天的 agent 系统已经越来越不像“一个发布后基本不动的程序”了。它会接工具、会吃上下文、会随着用户习惯漂移，甚至连 harness 自己都可能被改写。你还拿一套静态题库去盯它，基本等于拿卷尺量潮水。
Vincent Koc 这场短讲，表面上是在聊 eval，实际上更像是在逼大家承认一个现实：AI 系统的评测对象已经变了。以前评的是一个静态模型，现在评的是一个会变形、会适配、会在真实流量里慢慢长歪的系统。这个变化一旦承认，很多熟悉的评测姿势都会显得有点落后。
真正的问题，不是 benchmark 不够多，而是它假设系统不会变
Vincent 一上来就拿软件工程做对照，这个切入其实很有效。传统工程里，我们从来不只有单元测试。还有回归、CI/CD、observability、chaos engineering。原因很简单：系统一旦上线，问题就不会只按你预设的姿势出现。
但到了 AI 这里，很多团队反而退回去了。大家特别迷信静态 benchmark：先手工写一批问题，定义一组答案，离线跑分，调到“看起来差不多”再上线。出了问题，再补数据集，再补 case，再补一轮打分。这个循环短期能缓解焦虑，但它有个硬伤：它默认系统的行为边界是相对固定的。
今天的 agent 显然不是这样。
一个接了 RAG、工具调用、工作流编排、长期记忆的系统，行为边界本来就在变。用户群一换，问题结构就变；工具一接，错误模式就变；上下文一长，策略就变；prompt 和 skill 一改，整个执行分布也会变。你如果还把 eval 当作一套预写死的题库，那测到的只是某个瞬间的切片，不是这个系统真实的运动状态。
所以 Vincent 讲“eval 有点死了”时，不是在说评测没用了，而是在说旧式评测范式已经跟不上 agent 的变形速度。这个判断我基本同意。
他说的“malleable evals”，本质是在把评测从静态文档拉回运行时
这场 talk 里最重要的词不是 benchmark，而是 malleable——可塑、可变形。
他想推动的，不是做一个更聪明的 benchmark 仓库，而是承认：既然应用本身会变，评测也必须跟着变。至少要从几个方向挪过去。
第一，评测目标要从“答案对不对”慢慢转向“意图有没有被满足”。
这点很关键。很多 agent 问题，本来就不是 1+1=2 这种唯一答案题。用户要的不是某个标准句子，而是一个结果状态：任务有没有完成，风格是否合适，成本是否可控，风险有没有越界，行为是不是符合这个用户而不是另一个用户。你如果还只盯着字符串级对齐，迟早会测不准。
第二，测试集不能只靠人手工编，而应该从 traces 里自己长出来。
Vincent 提到一个很实用的方向：真实使用痕迹才是变化最早出现的地方。80% 的请求也许稳定，但真正把系统搞崩的，往往就是那 20% 奇怪的输入、奇怪的上下文、奇怪的操作顺序。问题是，这 20% 在离线题库里通常不存在，或者存在得太晚。要是系统能持续从 traces 里抽样、聚类、识别漂移，再把这些新型案例反哺回评测套件，那 eval 才有可能真跟上生产。
第三，eval 不该只在上线前跑，而该常驻在线。
这个思路其实和 observability 很像。你不是一次性验收完就结束，而是让系统在运行中不断暴露自己的状态：哪些任务完成率下降了，哪些工具调用开始异常，哪些用户群的满意模式变了，哪些步骤的成本突然涨了。只要 agent 系统还是活的，eval 也就不该是静止的。
这场分享最有价值的地方，是把“评测”重新接回了 agent engineering
我觉得很多 eval 讨论的问题在于，它常常被讲成一个独立学科，好像和产品工程是分开的。Vincent 这场分享里更有意思的一点，是他把 eval 重新拽回了工程语境。
他说得很直白：软件工程里我们知道要做 chaos engineering，要做 observability，因为系统会在真实世界里以你没预料过的方式出错。那 agent 为什么不这么看？
这句话其实是在拆掉一个错觉：很多团队还在用“模型评测”的脑子做“agent 系统评测”。前者的重心是能力测量，后者的重心其实更接近系统控制。
agent 系统一旦落地，问题就不再只是“模型会不会答题”，而是：
- 它在接入工具后会不会形成奇怪的依赖路径；
- 它面对不同用户时会不会逐渐偏出最初的产品意图；
- 它会不会在某些上下文长度下开始不稳定；
- 它出了错以后，能不能靠 telemetry 和运行时约束自我修正，而不是直接摔死；
- 它的 harness、skill、memory、tool routing 一旦频繁迭代，旧测试还能不能说明新问题。
这已经不是“做几百道题看看模型分数”能解决的事了。它更像在维护一个持续变化的软件器官。
也因此，他提到 telemetry in the loop 的那段，我觉得比“adaptive benchmark”本身更有未来感。因为它暗示了一种更激进的方向：不是人拿日志回去分析完再修系统，而是 harness 自己就感知成本、错误、失败模式，然后做有限度的自我修正。
这条路当然很危险，但它是真问题的方向。
从 prompt engineering 到 intent engineering，这个脉络说得挺准
Vincent 把演进分成三段：prompt engineering、context engineering、intent engineering。这个划分我觉得相当有用，因为它对应的其实不是提示词流行史，而是“系统控制粒度”的变化。
prompt engineering 阶段，大家基本是在碰运气。塞词、改词、加角色、换顺序，本质都是黑箱试错。这个阶段也最容易催生那些看起来很努力、实际上很玄学的“优化”。
到了 context engineering，系统开始变复杂。RAG、tool calling、multi-step workflow 进来后，agent 不再只是“给我一句答案”，而是在一个被上下文和工具约束的空间里做动作。这个时候 eval 还勉强能拆：检索准不准、工具调没调对、流程有没有跑通。
但 intent engineering 再往前一步，就把事情推复杂了。系统不只是按固定流程走，而是开始理解你想达到什么结果，再动态调整自己的做法。Claude、Codex、OpenClaw 这类 harness 都在往这个方向探。它们想做的不是“执行一串固定指令”，而是“理解意图后，自己找路径”。
一旦走到这里，评测就很难再靠固定答案。因为不同用户、不同上下文、不同环境下，通向同一个目标的路径本来就可能不同。你最后只能定义 end state，再让系统自己逼近。也正因为如此，eval 会越来越像 policy + telemetry + trace curation 的组合，而不是一个题库。
我最认同的一点：真正毁业务的，往往就是那 20% 漂移样本
这场 talk 里我最喜欢的一段，不是什么概念，而是那个很朴素的 80/20 说法。
80% 的行为也许一直都稳定。真正让系统出事的，是不断变化的那 20%。有人会提一个很怪的问题，有人会把工具用到你根本没设计过的角落，有人会在极长上下文里逼出你完全没见过的失败模式。很多团队的问题不是没 benchmark，而是 benchmark 盯着那 80% 盯得太认真，以为平均正确率高就说明系统稳了。
不是这样的。
业务事故通常不是死在平均数上，而是死在边缘样本上。更麻烦的是，这些边缘样本还会随着产品增长、用户变化、外部工具演化不断漂移。你今天补上的 case，明天就未必还是最危险的那个。
所以他最后那句“把 eval 当成 code、当成 software、当成 living agent，而不是一个时间点上的对象”，我觉得不是修辞，是非常工程化的提醒。你如果不把评测系统本身做成一个持续演化的东西，最终就会出现一种很熟悉的局面：大家手里有很多分数，心里却并不知道系统现在到底稳不稳。
这场分享也有边界：方向是对的，但离落地还有一大段
当然，这场 talk 说服力强，不代表它已经把落地问题讲完了。相反，我觉得它更像是把旧框架推翻了一半，剩下一半还在施工。
最现实的难点有几个。
先说 intent。你把 eval 从“标准答案”转成“意图满足”，听起来很对，但怎么定义 intent，本身就很难。用户说的是字面需求，还是隐含需求？不同用户之间的满意标准怎么统一？“完成任务”到底看结果、过程、风格、耗时，还是成本？如果这些都没有制度化表达，intent-based eval 很容易变成一句漂亮口号。
再说 trace-driven suite curation。生产 traces 当然重要，但 traces 本身噪声很大。你把日志直接喂回去，系统很可能学到的是偶然行为、坏习惯，甚至是某种短期异常。怎么抽样、怎么聚类、怎么定义 drift、怎么避免把噪声误当趋势，这里其实全是硬工程，不是嘴上说一句“让 agent 自己维护测试集”就能解决。
还有一个更深的风险：一旦 eval 本身也 agent 化、自动化、在线化，它就会变成另一个需要被 eval 的系统。也就是说，你不是消灭了复杂度，而是把复杂度上移了一层。这个问题 Vincent 没展开讲，但任何真做过线上系统的人都会知道，它迟早会来。
所以我的看法是：这场分享最有价值的不是给了一个现成方案，而是把真正的矛盾摆清楚了。现在继续迷信静态 benchmark，已经有点像明知道地图过期了，还坚持拿旧导航开车。
对做 agent 的团队来说，更实际的启发是什么
如果把这场 talk 落回到实际工作，我觉得至少有三件事值得马上改。
第一，不要再把 eval 只理解成“上线前打一遍分”。
评测要进运行时，要和 traces、telemetry、失败恢复放在一起看。否则你得到的只是一个上线前快照，不是系统的真实生命体征。
第二，测试资产要从“人手工列题”转成“人定义框架，系统持续补样本”。
人工当然还重要，但人更该做的是定义 rubric、风险边界、目标状态，而不是无限手写 case。真正变化最快的部分，一定得从生产流里长出来。
第三，评测体系本身要配得上 agent 的更新速度。
如果你的 harness、skill、tool routing、memory 策略每周都在变，但评测体系还是月更，那最后不是系统被评测保护住了，而是评测变成了安慰剂。
说到底，Vincent 这场分享真正戳中的，不是“怎么做一个新 eval 产品”，而是一个更根本的判断：agent 时代的软件越来越像活体，评测也不能再按标本来做。
这句话听起来有点重，但问题确实已经到了这个阶段。
最后
这场 talk 只有十几分钟，不算长，但信息密度够高。它最有意思的地方，是没有继续在 benchmark 规模、榜单、指标细节上兜圈子，而是直接把话题推到了一个更不舒服的位置：如果系统本身会持续变化，那评测到底还要不要继续假装自己是静态的？
我自己的答案很明确：不能再装了。
接下来真正有竞争力的，不会是“谁的 benchmark 仓库更大”，而是“谁能把 eval 做成一个在线、可塑、能跟着 agent 一起演化的系统”。
这件事比刷分难多了。但它也更接近真实世界。