X Article · Lei Li · 2026-05-18

Delegation Intelligence：Agent 时代该如何重新理解评测

这篇文章真正想推进的不是再发明一个 leaderboard，而是把 Agent 评测的中心从“模型脑内能不能做”迁移到“模型是否知道该把任务交给工具、搜索、代码、人审或验证流程”。

1. 读了什么，以及如何核验

原帖 https://x.com/_TobiasLee/status/2056339539866886649 本身只有一个短链，实际内容是 X Article Measuring the Delegation Intelligence of Agents。OpenCLI 的 twitter thread 成功抓到原帖和回复；twitter article 对该 X Article 返回 Article not found，因此用 opencli web read 抽取文章正文。

X Article 主文 Measuring the Delegation Intelligence of Agents 作者 Lei Li，2026-05-18；核心讨论 Agent 评测、Delegation Intelligence、Pass-all-k、token efficiency、model instinct。
Claw-Eval 页面 Claw-Eval leaderboard 用于交叉确认文章提到的 benchmark 指标：Pass^3、Pass@3、Completion、Robustness、Safety、Avg Score。
Pass^k 背景 Sierra 关于 τ-bench 的说明 用于核对评论里提到的 tau2 / pass^k 背景：重复运行中的一致成功概率。
Pass@k vs Pass^k 解释 Phil Schmid: Pass@k vs Pass^k 用于补充公式层面的直观解释：Pass@k 偏乐观，Pass^k 更接近生产可靠性。
可靠性边界：Claw-Eval leaderboard 是活页面，模型列表和分数会变化；本报告只把 2026-05-20 抽取到的信息作为上下文，不把其分数当成静态事实。

2. 文章在反对什么旧评测范式

作者的出发点是：2026 年 Agent 已经从 demo 进入生产，主流范式变成 Agent = Model + Harness。这里的 harness 指工具、系统提示、浏览器、shell、代码解释器、检索、文件系统、执行环境、验证器等外部支架。模型不再是孤立地回答一道题，而是在一个可操作环境里完成任务。

这会让很多传统 benchmark 的意义发生变化。

知识题的尴尬

如果 web search 是标准工具，那么“记住 Q1 2026 营收”不再是核心能力。更关键的是模型是否知道这类问题必须联网、是否能交叉核验、是否能标注时间和来源。

长链推理题的尴尬

很多概率、组合、状态跟踪题可以用几行 Python 更稳定地解决。此时高分可能测到的不是脑内推理深度，而是模型是否知道“该写代码”。

边界条件

作者没有否定 base capability eval。对小模型、垂直模型、基础能力还没补齐的场景，传统 eval 仍然是 gap finding 工具。争议只在 frontier agent 的主战场应该迁移。

我对这篇文章的理解是：它把“能力”从静态参数里的知识和推理，重新定义成一种动态决策策略：知道什么时候自己做，什么时候借外力，什么时候验证，什么时候停。

3. Delegation Intelligence 到底是什么

Delegation Intelligence 可以翻译成“委派智能”或“代理式委派能力”。它不是说模型一定要调用更多工具，而是说模型要能在不同路径之间做正确选择。

维度 具体含义 好行为 坏行为
Tool-use judgment 什么时候用工具、用哪个工具、参数怎么设。 实时财报问题主动搜索；概率模拟主动写代码；高风险操作先 dry-run。 能心算就硬心算；需要当前信息却凭记忆答；工具参数乱猜。
Information synthesis & verification 多来源整合、可靠性加权、冲突处理。 RCT 权重高于博客；旧综述标注时效边界；关键数字找两个来源。 把所有来源平均；把低质量摘要当事实；不说明不确定性。
Path selection 在直接推理、代码、检索、阅读、验证、人审之间选择路径。 先定位核心文件再改代码；先看 README/测试再下判断；任务完成后运行验证。 无计划地扩搜；过早下结论；为简单问题启动昂贵流程。
这比“会用工具”更严格。会用工具只是动作空间扩大；委派智能关心的是策略质量：是否在正确时间把正确子任务交给正确外部机制，并且能回收证据、判断证据、承担最终答案责任。

4. 为什么 Pass-all-k / Pass^k 比 Pass@k 更重要

这条 X 的回复里，xeophon 提到作者的 pass-all-k 与 τ-bench 语境里的 pass^k 基本指向同一类可靠性指标。这个点很关键，因为它正好解释 Agent 评测为什么不能只看“多试几次总能成功”。

Pass@k：乐观的“至少一次成功”

给模型 k 次独立尝试，只要其中一次成功就算通过。代码生成里常用，因为用户或评测器可以从多个候选里挑一个正确答案。

\[ \mathrm{Pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \]
其中 \(n\) 是总尝试数，\(c\) 是成功数。它回答：“抽 k 个候选，至少一个正确的概率是多少？”
Pass^k / Pass-all-k：严格的“每次都成功”

关注 k 次尝试是否全部成功。它更接近生产环境：用户不会因为系统三次里有一次成功就满意，用户关心连续请求是否稳定完成。

\[ \mathrm{Pass}^{k} \approx \left(\frac{c}{n}\right)^k \]
这是独立同分布假设下的简化估计。实际 benchmark 也可以直接按重复运行结果统计“同一任务 k 次是否全部通过”。

一个小例子

假设某客服 Agent 单次任务成功率是 70%。如果给它 3 次机会，Pass@3 可能看起来接近 97%，因为至少一次成功很容易。但如果要求连续 3 次都成功，Pass^3 = 0.7^3 = 34.3%。这就是为什么 Pass@k 会掩盖可靠性问题。

\[ \mathrm{Stability\ Gap} = \mathrm{Pass@}k - \mathrm{Pass\text{-}all\text{-}}k \]
gap 大，说明模型“有时能撞对”；gap 小，说明决策路径稳定。对 Agent 来说，稳定路径本身就是能力。

Claw-Eval 的指标组合

Claw-Eval 页面把 Pass^3、Pass@3、Completion、Robustness、Safety 和 Avg Score 放在一起。这个设计体现了文章主张：只看最终答案不够，还要看重复运行稳定性、鲁棒性和安全边界。

Claw-Eval token efficiency scatter plot
文章中的 token efficiency 图：同等准确率附近，不同模型可能消耗差几个倍数的 token。图像来自 X Article 配图，本地保存用于阅读报告。
不要把成本指标绝对化。Token efficiency 很重要，但它不是所有任务的第一目标。医疗、金融、代码删除、权限变更等高风险任务里，额外验证的 token 成本可能是必要成本。更合理的做法是画 task-conditioned cost-quality frontier，而不是给所有任务套同一个成本惩罚。

5. “Model Instinct” 是这篇文章最有意思但也最难测的部分

作者观察到不同模型有不同“直觉”：有些模型还没完整读论文，就能定位关键 method 段；还没深入代码库，就能猜到核心文件；信息还不充分时，第一判断就接近最终答案。这种能力不是最终准确率，也不完全等于 token efficiency。

我觉得这个概念有价值，因为它描述的是“搜索策略的先验质量”。强模型不只是会穷举路径，而是更早把注意力放到高信息密度的位置。

可测 proxy 测什么 潜在混淆
Time-to-first-relevant-artifact 多久找到真正关键的文件、段落、网页或日志。 可能受工具速度、索引质量、先验泄漏影响。
Early-path regret 前几步选择与最终最短成功路径的偏离程度。 “最短路径”未必是最安全路径。
Unnecessary-tool rate 调用了多少对最终答案没有贡献的工具。 探索性任务中冗余调用不一定是坏事。
Source-weight calibration 是否能早期区分高质量来源和噪声来源。 需要人工或强验证器标注来源质量。
我的判断：“instinct”值得研究，但不能直接变成一个玄学 leaderboard。它必须落到轨迹指标、可复核证据和反事实路径比较上，否则很容易把“看起来聪明的 shortcut”误当成真实能力。

6. 作者强调的工程挑战，其实是 Agent Eval 的可信度底座

文章最后一部分很工程化，但重要性不低于指标本身。Agent eval 比 QA eval 更容易被环境污染。

基础设施侧
  • 模型服务超时、限流、上下文截断会污染结果。
  • 浏览器、shell、容器、文件系统状态漂移会被误归因成模型失败。
  • Docker CPU、内存、磁盘不足会让任务互相影响；隔离不仅是文件隔离，也是资源隔离。
评测设计侧
  • 同一模型换 prompt、工具集、harness 后可能差很多；跨模型比较必须考虑 harness mismatch。
  • Web search/mock service 会随时间漂移；需要 snapshot 或避免强时效依赖。
  • 安全应作为 veto 维度：越权删文件、泄漏信息、乱发请求，不能用任务成功抵消。

这里最值得带走的工程原则是：Agent eval 的样本不是“题目 + 答案”，而是“题目 + 环境 + harness + 工具状态 + 执行轨迹 + 最终状态”。缺任何一项，复现性和可解释性都会下降。

7. 我的核心 insight

这篇文章的重要性，在于它把 Agent 能力从“是否拥有某项内生技能”推进到“是否拥有正确的外包策略”。这是一个更接近真实生产的能力定义。

它解释了为什么旧题会失效

不是因为知识、推理、数学不重要，而是因为在 Agent 系统里，这些能力经常被工具重构。评测如果仍然禁止工具，就测不到真实工作流；如果允许工具却不记录路径，又分不清模型能力和 harness 偶然性。

它把可靠性放回中心

Pass@k 奖励“多试几次总会成功”，Pass^k 追问“连续处理真实请求是否稳定”。生产系统真正要的是后者。

它也暴露了新风险

Delegation Intelligence 容易被 harness 设计劫持。一个模型在某个工具环境里很强，不代表它具备可迁移的委派能力。因此多 harness 方差、路径审计和安全 veto 是必要配套。

我会把这篇文章看作一个评测方向的宣言：下一代 Agent benchmark 不应该只问“模型答对了吗”，而应该问“它为什么选择这条路径、这条路径是否稳定、成本是否合理、是否遵守边界、换一个 harness 是否仍然成立”。

8. 本次使用的关键命令

opencli twitter thread "https://x.com/_TobiasLee/status/2056339539866886649" --limit 80 -f json --trace retain-on-failure
curl -Ls -o /dev/null -w '%{url_effective}\n%{http_code}\n' "https://t.co/Rb5eLxvoaF"
opencli web read --url "https://x.com/i/article/2056333686597890048" --stdout true --download-images false --wait 5 -f json --trace retain-on-failure
opencli web read --url "https://claw-eval.github.io/" --stdout true --download-images false --wait 5 -f json --trace retain-on-failure

补充来源通过 mcp-router/Grok Search 定位到 Sierra τ-bench 说明和 Phil Schmid 的 Pass@k vs Pass^k 解释，再用 mcp-router fetch 抽取正文。