Agent 时代，我们测错了一半的东西
Agent 时代，我们测错了一半的东西
写在前面
2026 年过半了。回头看，这一年最显著的变化，是 Agent 范式真正从 demo 落到了生产。从 Auto Research 到 long-horizon coding，从 OS-level 操作到多工具协同，模型的能力被重新组装：Agent = Model + Harness 几乎成了所有人默认的工程范式。
我自己过去几年做了不少评估工作，再到最近这一年踩在 Agent 评估里的各种坑。越做越觉得，这个领域正在经历一次范式迁移，而我们大多数人还在用旧的尺子量新的东西。
所以想把这段时间的思考整理成这篇文章。它不是一份综述，更像是带着主观立场的一份阶段性总结。下面要展开的很多具体方法，都是我们在 Claw-Eval（我们团队做的 Agent 评估框架）这套体系里实际落地、踩坑、迭代出来的。
如果你也在做 eval，希望它对你有用；如果你在做 agent 或模型，希望它能帮你看清”分数”背后真正值得追的能力。
一、什么样的 Eval 才算好 Eval？
我心目中理想的评估，应该同时满足三件事。
第一，它要能定义或挖掘出模型能力的边界。 一个好的 benchmark，不只是给出一个分数，而是要让人看清楚”这个模型在哪里行、哪里不行”。它本质上是模型能力的一张地图，而不是一根温度计。
第二，它要在测评方法本身上有所推进。 LLM-as-a-judge、更细颗粒的 step-level scoring、对 trajectory 的结构化分析——这些是评估范式的工程进展，往往比单点指标的提升更有长期价值。
第三，它要打开新的想象力。 这一条我觉得最被低估。
举几个例子。上一个时代做得最好的代表之一，我认为是 OSWorld 和 SWE-Bench，前者测评让模型操作真实操作系统的能力，后者则是很早的预见到了 Coding 的爆发。它们把评估从”单轮问答”推到了操作系统级 / 软件工程修 PR，让大家第一次意识到模型可以被放到一个真实的、有副作用的环境里去做事。这件事的意义远不止于多了一个 benchmark，而是反向定义了模型能力的可能性边界。
到了今年，ProgramBench 和 RepoZero 这类 long-horizon coding 任务（要求模型在真实代码库里完成跨文件、跨模块的修改）又把想象力往前推了一步：模型不再是补全一个函数，而是要在一个有真实历史的代码库里完成跨文件、跨模块的修改。AutoResearch 范式出现之后，这些评估也很快跟进，让我们能去衡量开放性的、长程的科研类任务。
好的 eval 不只是打分尺。它在定义”什么是值得追求的能力”。
二、传统 benchmark 的天花板正在被消解
先说结论：很多我们曾经引以为豪的能力测评，正在以肉眼可见的速度失去意义。
知识类测评的尴尬
模型不需要”背下整个维基百科”。当 web search 成为 Agent 的标配，实时的、超训练 cutoff 的知识可以随时被拉取。继续在知识 QA benchmark 上刷分，本质上是在补长尾，而补这部分的 ROI 越来越低。
长链推理测评的尴尬
拧魔方的状态推演、掷骰子翻面的概率、复杂的组合数学——这些题目的”含金量”在 Agent 范式下大打折扣。原因很朴素：几行 Python 模拟比脑算稳定得多。一个能调用 code interpreter 的模型，在这类题上的表现不取决于它的”推理深度”，而取决于它能不能想到”这件事应该用代码做”。
Harness 在很多场景下规避了推理链的随机波动。当我们继续在这些 benchmark 上看到分数提升时，要警惕：我们到底是在测能力，还是在测”用对工具”？
必要的边界声明
上面这些论断成立的前提是基础能力够用。
我并不是说基础能力评估不重要。在主流模型还没普遍到 1T+ 规模、或者在做小模型、特定垂直领域时，基础 eval 仍然是最可靠的”查漏补缺”工具，这是个原则。我只是想提醒：当你的目标模型已经处在前沿规模时，继续把大量资源压在基础能力 benchmark 上，可能是在补一些极度长尾、且很快会被 distillation 或数据合成 catch up 掉的部分。 中长期看，基础能力会随着大模型变强自然下沉到小模型，因此这个分歧的意义会越来越小。
所以问题不是”还要不要测基础能力”，而是”前沿模型的评估主战场该挪到哪里”。
三、真正该测的是什么？Delegation Intelligence
讲完”不该测什么”，该讲”该测什么”了。
我把想法和 Claude / GPT 讨论之后，认为一个合适的描述可能是 Delegation Intelligence，委托智能。
核心论点很简单：我们要测的，不是”模型能不能做出来”，而是”模型知不知道这件事该怎么做”。
打个比方。一个聪明的工程师，不会去心算 2^37 × 1.0732，他会打开计算器。”聪明”的体现不是他自己能算多大的数，而是他知道这件事应该委托给计算器。同理，一个真正强的模型，不需要把所有能力都内化在权重里，但它需要知道：什么时候该自己想，什么时候该调工具，什么时候该搜信息，什么时候该写代码模拟，什么时候该停下来交叉验证。
Delegation Intelligence 在我看来至少包含三个维度：
- Tool use judgment：什么时候该调工具、调哪个工具、以什么参数调
- Information synthesis & verification：多源信息的整合，以及对信息源可靠性的判断
- Path selection：在 direct reasoning、code execution、web search 之间做路径选择
下面三个例子，可以帮你建立直觉。
Example 1：知识类委托
问题：”X 公司 2026 年 Q1 的财报营收是多少？”
模型 A 凭训练记忆给出一个 2024 年的数字，语气非常自信。模型 B 立刻意识到这是时效性信息，调用 web search，并在两个独立来源之间交叉验证后给出答案，同时标注信息来源和发布时间。
谁更聪明？显然是 B。B 的”自知之明”比 A 的”博闻强识”更有价值。
Example 2：计算类委托
问题：”一个标准骰子连续掷 10 次，至少出现一次连续两个 6 的概率是多少？”
模型 A 硬算条件概率，链条很长，中间一步错就全错。模型 B 写五行 Python 蒙特卡洛，跑十万次模拟，得到稳定答案，还顺手给出 95% 置信区间。
B 没有”更聪明的脑子”，但它有”更聪明的判断”。
Example 3：信息加权
问题：”X 药物对 Y 疾病有效吗？”
搜索返回三篇内容：一篇 Nature 的 RCT 研究、一篇个人博客、一篇 2018 年的过时综述。模型 A 简单平均所有来源，得出一个模糊的”可能有效”。模型 B 优先采信 RCT，把博客标注为低权重并说明理由，同时指出综述的时间局限，最终给出有结构、有置信度的回答。
这是 information synthesis 的核心——信息加权，而不是信息平均。
回到 Part 1 提到的那些 benchmark，它们之所以重要，正是因为这些任务单靠”脑力”做不出来，必须依赖 delegation intelligence 才能完成。”想象力的场景”和”该测的能力”在这里是闭环的。
四、Claw-Eval 的实践：我们怎么测 Delegation Intelligence
这一节我以我们最近做的 Claw-Eval 为例子，分享我们如何评估 Delegation Intelligence 的一种尝试:
双重维度：结果 + 路径
只看最终答案是不够的。Agent 评估必须同时关注两件事：
结果正确性: 优先选可验证的任务设计：单元测试、数值答案、文件 diff、API 状态。能机器验证就别用 LLM judge，能用 LLM judge 就别用人工。
路径合理性: 通过工具记录所有调用，把 trajectory 作为审计入口。这里要特别强调一点：承认”一题多解”。同一个任务，有的 Agent 用搜索 + 整合，有的则会用代码 + 验证，只要路径合理、结果正确，都应该被认可。强行规定”必须按某条路径走”会反过来损害评估的公正性。
从 Pass@k 到 Pass-all-k
Pass@k 衡量”k 次尝试至少 1 次成功”，是过去几年的主流指标。但在 Agent 评估里，我们 Claw-Eval 越来越倾向用 Pass-all-k：k 次尝试全部成功。
更有意思的，是去看这两个指标之间的 gap：
\[\text{Stability Gap} = \text{Pass@}k - \text{Pass-all-}k\]- gap 大：模型靠运气——有时能做对，但路径不稳定
- gap 小：模型的决策路径是稳定收敛的
只有 gap 足够小的模型，我才认为它的 Delegation Intelligence 真的到位了。 因为稳定性本身，就是判断力的体现。一个会因为随机扰动就选错工具、错过验证步骤的模型，谈不上”知道该怎么做”。
另外也有人会好奇说我们为什么不用 OpenClaw 的 harness 而是自己建设一套，并且问：不同 Harness 下模型表现差异很大，怎么横向比？ 我们的回答是为了更好的 audit。当然，一个更好的处理方式是把”对 Harness 的 adaptability”当成评估的一个独立维度。一个真正强的模型，应该在更换 prompt 模板、更换工具集、更换执行环境时，依然保持稳定水准。未来 Claw-Eval 也会让同一个模型跑多套 harness 配置，看分数的 variance，这种适应能力本身就是一个泛化能力指标。
Cost-aware metrics：Token Efficiency
光做对还不够，得看用了多少代价做对。
Claw-Eval 同样 考虑了 token efficiency，衡量模型能不能在尽可能少的工具调用、尽可能短的 trajectory、尽可能少的 token 消耗下，得到正确答案。这个指标在 production 场景里直接关联成本，在评估场景里则反映了模型的”经济判断力”，一个用 50k token 做对题的模型，和一个用 5k token 做对同一道题的模型，不应该在评估里被等同对待。
我们的 leaderboard 也提供了 cost-accuracy 的二维散点图，很多模型在 accuracy 上接近，但 token cost 能差出几倍。当然，这个权衡取决于任务的关键程度，在医疗、金融等高 stakes 场景下，correctness 的权重显然远高于 cost。这本身也是评估设计需要考虑的维度。
一个我们正在尝试 measure 的维度：模型的”直觉”
我们在分析跑出的大量 trajectory 时，观察到一个非常有意思的现象：不同模型的”直觉”差异极大，而这种差异，目前没有任何主流 benchmark 在 measure。
具体是什么意思？举几个例子：
- 有的模型没有完整读完一篇 paper，但准确指出了 method section 里关键的那两段
- 有的模型没有真的熟悉一个 codebase，但看一眼目录结构就能告诉你哪几个文件是核心，以及里面大概会有什么 pattern 值得 grep
- 有的模型在信息明显不充分的情况下，给出的第一判断就接近最终答案；而另一些模型，必须把整个搜索/读取流程跑完，才能收敛到同一个结论
如果说 tool use 和 path selection 是 delegation intelligence 的”外显行为”，那 instinct 就是 delegation 的”内隐前计算”: 它解释了为什么有的模型不必试遍所有路径，上来就是对的。这是 delegation 的高阶形态：不是”知道该怎么找到答案”，而是”在还没完全找完之前，就已经大致知道答案在哪里”。
它和 accuracy 不一样，和 token efficiency 也不一样。两个 accuracy 完全相同的模型，instinct 可以差很远: 一个是”试遍所有路径终于试对”，一个是”上来就走对”。这两件事在可能最终分数上看不出区别，但在 trajectory 上一目了然，token efficiency 可能是个 proxy 但不够准确刻画。
这些都是还很初步的观察，但我相信把”模型直觉”这件事定义衡量清楚非常有价值。
五、被严重低估的工程性挑战
最后说一些不那么”思想性”、但极度影响评估结果可靠性的工程问题。这部分是我们 Claw-Eval 团队踩过最多坑的地方。
我把这些问题分成两组来看。
服务侧问题
模型服务的稳定性：大规模评估时，模型 endpoint 的偶发超时、限流、context window 截断，都会污染结果。一次完整评估可能跑几十小时，中间任何一个抖动都可能让你怀疑人生。
Harness 服务的稳定性：Agent 评估比 QA 评估对环境敏感得多。Browser 自动化卡住、shell 容器崩溃、文件系统状态不一致，这些都不是”模型问题”，但会被记到模型头上。
Docker-based Evaluation 的资源充分性：对于 computation-heavy 的任务，容器的 CPU/内存/磁盘配额必须给够。隔离不仅要做环境隔离，更要做资源隔离，否则一个 OOM 任务会拖垮整个 evaluation pipeline。
评估设计侧问题
模型与 Harness 的匹配度：同一个模型在不同 system prompt 下表现可以差出 20 分。Mismatch 严重影响评估结果的横向可比性。 这也是为什么我们在前面强调要把 adaptability 单独作为一个维度去测。
Mock 服务的动态性：web search 是评估里最棘手的工具之一。同一个 query 今天和明天搜出来的结果不一样，这会让题目的”标准答案”漂移。要么用快照，要么在评估设计上避开强时效性问题。
一个容易被忽略的维度：安全
Agent 有了自主调用工具的能力，评估里自然应该多一个维度：模型会不会调用不该调的工具、删不该删的文件、对外泄露不该泄露的信息。 目前这块在社区里讨论得还不够多，但当一个 Agent 可以自主操作文件系统、发送网络请求时，”守规矩”和”聪明”同等重要。Claw-Eval 通过设计 Trap 任务来观察并且在计分的时候用一票否决来体现安全的地位。
写在最后：Eval 的下一站
回到开头那三条理想的标准：定义能力边界、改进测评方案、打开想象力的场景。 在 Agent 时代，这三条都需要重新解释。
如果你在做 Agent eval：优先关注 delegation intelligence，看 Pass-all-k 而不只是 Pass@k，把 token efficiency 当一等公民，并且开始思考如何 measure”模型直觉”。
如果你在做 基础能力 eval：它在小模型、垂直领域、查漏补缺的场景下仍然有不可替代的价值，但要清楚自己在补的是不是长尾。
如果你在做 模型本身：Agent 时代的强模型，不再是”什么都会”的模型，而是”知道什么时候该做什么”的模型。Delegation 比 Memorization 更值钱。
这篇文章里很多观点是和团队同事、社区朋友讨论中逐步成型的，挂一漏万。Agent 评估仍然是一个非常早期的领域，我写的不一定对，但希望它能给正在这个方向上探索的人一些参考。