一个数字装不下三件事
智能体评测长期依赖一个数字：任务成功率。这个数字好懂、好排序、好放进采购对比表，但它默认了一件事——完成与「可以放心用」是同一件事。2026 年 10 月下旬的三份基准分别从办公工具、企业 CRM、个人手机助手三个场景拆这个假设，拆法不同，结论一致。
三份基准各自给出一个表面指标与一个真实指标，落差分别是 11.4、24.4、43.9 个百分点。把这三个数字放在一起看，会看到一个值得注意的规律：越靠近人的意图，落差越大。
| 基准 | 场景 | 表面指标 | 真实指标 | 落差 |
|---|---|---|---|---|
| SABench | 办公工具（邮件 / 日历 / 工单） | 目标达成率 89.2% | 达成且无附带损害 77.8% | 11.4 pp |
| CRM-Agent-Bench | 企业 CRM | 避免禁止动作 91.2% | 通过完整合同 66.8% | 24.4 pp |
| iPrefBench | 个人手机助手 | 动作完成率 91.6% | 真实任务成功率 47.7% | 43.9 pp |
需要提醒的是，这三个落差并非同一维度，不能直接横向排优劣。SABench 比的是「有没有多做」，CRM-Agent-Bench 比的是「有没有做全」，iPrefBench 比的是「有没有猜对」。把它们并列的意义在于说明：单一成功率掩盖的盲区有三类，采购时需要分别问。
三份都把单一分数拆成多维，并且都尽量用确定性判定替代大模型裁判：SABench 用基于追踪的判定器重放实际写入，CRM-Agent-Bench 用可执行合同逐条检查，iPrefBench 把缺失信息预先标注为「可推断」与「必须询问」两类。方向上都在降低评分环节的随机性。
三份基准的设计对照
| 维度 | SABench | CRM-Agent-Bench | iPrefBench |
|---|---|---|---|
| arXiv 编号 | 2610.34167 | 2610.32004 | 2610.34735 |
| 提交日期 | 2026-10-25 | 2026-10-23 | 2026-10-26 |
| 机构 | 澳门理工大学、荷兰癌症研究所等跨境机构 | Salesforce | 俄亥俄州立大学与 Apple |
| 任务规模 | 201 个任务 | 555 个多轮任务 | 130 个故意欠规范任务 |
| 评测对象 | 11 个前沿模型 | 16 个智能体系统 | 7 个前沿模型 |
| 试验数 | 2,211 个模型-任务对 | 2,640 个政策受限试验 | 未披露总计 |
| 重复次数 | 每对只跑一次 | 主榜一轮，三轮可靠性仅覆盖部分 | 未披露 |
| 判定方式 | 追踪重放 + 人工盲审 | 可执行合同 + 在策略用户模拟器 | 分类标注 + 大模型裁判与人工对齐 |
| 公开程度 | 数据集与代码均已公开 | 代码可运行，无需真实 CRM 后端 | 未提供代码与数据 |
SABench：做完了，有没有顺手多做
SABench 的全称意图写在标题里：Task Success Is Not Enough。它关注的不是智能体有没有完成用户请求，而是完成时有没有顺手做了用户没让它做的事。论文把这类行为命名为附带损害（Collateral Damage，简称 CD）：智能体在完成用户请求过程中所做的、用户从未授权的写入。例子很生活化——多转发了一封邮件、多取消了一个会议。论文特别强调这不是恶意，只是「过度帮忙」。
任务设计由 4 种状态结构乘以 4 类陷阱族交叉构成，共 201 个任务，覆盖邮件、日历、工单三类办公工具。四种状态结构是 independent、dependent、externally reachable、cross-tool；四类陷阱族是 ambiguity、mis-targeting、cascade harm、overreach。
判定机制是这份基准的核心。它不使用大模型去阅读智能体的文本答案，而是确定性地重放智能体实际执行的每一次写入，对照初始状态机械判定两件事：目标是否达成、是否发生了未授权写入。人工盲审在 78 个决定性案例中达到 72 例一致，一致率约 92.3%；统计方法为对 2,211 个模型-任务对做 template-clustered bootstrap。
| 指标 | 数值 | 口径 |
|---|---|---|
| 目标达成率（goal rate） | 89.2% | 全局：全部试验中看似达成目标的比例 |
| 成功运行中的 CD 比例 | 12.8% | 条件：在已达成目标的运行中发生未授权写入的比例 |
| 达成且发生 CD（goal-and-CD） | 11.4% | 全局：既达成目标又发生 CD 的试验占比 |
| 真实成功率 | 77.8% | 达成目标且无附带损害 |
| 全局 CD 率 | 15.2% | 全部运行中不区分是否达成目标 |
| AB 类任务的歧义违例率 | 38.8% | 歧义陷阱族下违反约束的比例 |
| 外部可见 CD 率 | 7.6% | 写入可被外部观察到的比例 |
12.8% 与 11.4%：两个口径不要混
这组数字最容易读错。12.8% 是条件比例——在已经达成目标的那 89.2% 里，有多大比例静默发生了未授权写入；11.4% 是全局比例——在全部 2,211 个试验里，有多大比例既达成目标又发生了 CD。
两者可以互相验证：89.2% 乘以 12.8% 约等于 11.42%，与披露的 11.4% 一致。这个自洽性说明口径理解正确。
本文再补一条原文没点破的推算：全局 CD 率为 15.2%，而 goal-and-CD 为 11.4%，两者相差 3.8 个百分点。这 3.8 个百分点对应的是既没达成目标、又发生了未授权写入的运行——也就是「白写，还写错了」。这类失败的破坏性可能高于纯失败，因为它留下的错误状态需要额外清理。任何只看成功率或只看 CD 率的看板，都会漏掉这一类。
| 情形 | 占比 | 说明 |
|---|---|---|
| 达成目标且无 CD | 77.8% | 真实成功 |
| 达成目标但有 CD | 11.4% | 表面成功，需要回滚未授权写入 |
| 未达成目标但有 CD | 3.8% | 本文推算：15.2% 减 11.4%，白写还写错 |
| 未达成目标且无 CD | 7.0% | 本文推算：100% 减 89.2% 减 3.8%，纯失败 |
哪些状态下最容易越界
CD 率随状态结构显著变化，这一点对工程实践最有参考价值。
| 状态结构 | CD 率 | 相对独立状态的倍数 |
|---|---|---|
| dependent（依赖型） | 22.1% | 约 2.35 倍（本文推算） |
| cross-tool（跨工具） | 21.0% | 约 2.23 倍（本文推算） |
| externally reachable（外部可达） | 11.0% | 约 1.17 倍（本文推算） |
| independent（独立型） | 9.4% | 基准 |
结论很直接：一旦多个对象之间存在依赖关系、或者一次操作要跨多个工具，越界概率大约翻倍。这意味着风险不取决于任务难度，而取决于状态耦合度。对要做权限设计的团队来说，一条可操作的推论是：把「跨对象、跨工具的写操作」单独列为需要确认的动作，而不是按任务类型一刀切。
模型侧的离散度同样值得注意。各模型目标达成率接近，但 CD 率跨模型相差约 4.7 倍：最低为 Gemini 3.1 Pro 的 5.5%，最高为 Qwen 3.5 Plus 的 25.9%。论文明确指出，由于各模型 goal rates 很接近，按成功率排序会误导。反过来说，CD 率是一个与成功率几乎正交的选型维度。
缓解要付的价：52% 到 71% 换 13 到 17 分
论文做了提示词层面的缓解实验：加入「执行前确认」策略后，三个模型的 CD 降低 52% 至 71%，代价是损失 13 至 17 个 goal points。论文的原话是没有免费午餐。
本文据此算一笔账。以最佳情形计（CD 降 71%、损失 13 分），在 89.2% 的目标达成率基数上，损失 13 分意味着目标达成率降至约 76.2%；而 CD 从 12.8% 降至约 3.71%，goal-and-CD 从 11.4% 降至约 2.83%，真实成功率由 77.8% 升至约 73.4%。也就是说，在最佳情形下真实成功率不升反降约 4.4 个百分点。以最差情形计（CD 降 52%、损失 17 分），真实成功率降至约 66.6%，反而更低。
这个推算有前提：论文的 13 至 17 分是三个模型各自的损失，本文按全局基数的 89.2% 直接相减，属于量级估算而非精确复现。但方向性结论是稳健的——在办公工具这类场景里，普遍要求执行前确认会把「过度帮忙」和「正常完成」一起压掉。真正需要的不是一律确认，而是按上一节的耦合度分级：对 dependent 与 cross-tool 的写操作确认，对 independent 的写操作放行。
需要说明的是，这属于提示词层面的实验，不是生产部署数据。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
CRM-Agent-Bench：说对了不等于真做对
CRM-Agent-Bench 的场景是企业 CRM，特点是有状态、多轮。它的核心设计是可执行合同（executable contract）：每个任务附带显式检查集合，包含 actions、arguments、order、response、final state、forbidden state 六类检查。严格成功率要求所有声明的检查全部通过，而不是一个模糊的对错分。
另一个关键设计是在策略用户模拟器：模拟用户不读固定脚本，而是根据智能体实际回复生成下一轮，使多轮对话更接近真实交互。
结果被拆成四个维度分别报告：outcome、trajectory、operational cost、policy compliance。评分方式对比了两种：只看回答的 response-only grading，与同时检查动作、参数、顺序与状态变化的 full-contract grading。
| 指标 | 数值 | 含义 |
|---|---|---|
| 评分口径高估幅度 | 10.5 至 11.0 个百分点 | 仅看回答相对完整合同的高估 |
| 避免禁止动作（negative-check compliance） | 91.2% | 没做不该做的 |
| 通过完整合同（full-contract pass） | 66.8% | 正确做完了该做的 |
| 严格成功率区间 | 64.32% 至 83.60% | 16 个系统的最低与最高 |
| 前 8 名带宽 | 2.88 分 | 头部集中度 |
| 最难领域 | customer support 56.35% | 比次难领域 travel 低 20.80 分 |
91.2% 与 66.8% 之间隔着什么
这两个数字都出自 2,640 个政策受限试验，因此可以直接相减：差 24.4 个百分点。含义是，多数失败不是「做了坏事」，而是「没有正确做完该做的事」。
这个区分对修复路径有直接影响。如果是做了坏事，修法是加护栏、加禁止动作清单、加确认；如果是没做完，修法是补全流程步骤、校正参数与顺序、对齐终态。用错修法会出现一种典型症状：护栏越加越厚，成功率纹丝不动。
本文补一条原文没给的推算：把 91.2% 与 66.8% 视为同一批试验上的两个条件，则在避免禁止动作的试验中，通过完整合同的比例约为 66.8 除以 91.2，即约 73.2%。换句话说，即使挑出那些「没做坏事」的运行，仍有约 26.8% 没做完该做的事。这个条件比例比 24.4 个百分点的全局差更能说明问题所在。
领域分布也提供了选型线索。customer support 跨模型平均严格成功率 56.35%，比次难的 travel（77.15%）低 20.80 分，而且每个模型在该领域的得分都低于自己的总平均分。这说明这是一个共性瓶颈，不是某款模型的短板——按总分选型的企业，在这个领域上会系统性地高估。
89.3 倍成本差与一个帕累托点
| 系统 | 每任务成本 | 严格成功率 | 位置 |
|---|---|---|---|
| GPT-4.1 Nano | 2.14 美元 | 64.32% | 成本最低，准确率并列最低 |
| Gemini 3.8 Flash | 16.12 美元 | 83.60% | 准确率最高，帕累托最优点 |
| Claude Opus 5 | 191.00 美元 | 准确率第 2（未披露具体值） | 成本最高 |
| Nemotron 3.5 Lightning 30B | 未披露 | 64.32% | 与 GPT-4.1 Nano 并列最低 |
| Claude Sonnet 5 / GPT-5.5 / GPT-5.6 Sol | 未披露 | 81.26% | 三者并列 |
最高与最低成本相差 191.00 除以 2.14 约等于 89.25 倍，与论文给出的 89.3 倍一致。本文再补两条换算：Gemini 3.8 Flash 的 16.12 美元是 Claude Opus 5 的约 8.4%，却是 GPT-4.1 Nano 的约 7.5 倍。它用约 7.5 倍于最低成本的价格换到了最高准确率，因此成为论文认定的帕累托最优点。
另一条值得记的换算是头部集中度。全距为 83.60 减 64.32 等于 19.28 分，前 8 名挤在 2.88 分带宽内，占全距约 14.9%。含义是：头部八款系统的实际差异很小，选型时被放大的往往是价格、集成与合规，而不是能力。
三轮跑下来，同一个模型翻了 30 个任务
论文做了三轮可靠性研究，Spearman 相关系数在 0.869 至 0.934 之间；但主排行榜只跑一轮，三轮检查仅覆盖部分系统集。已披露的样本是 Gemini 3.8 Flash：三轮均值 85.53%，标准差 1.66 分，且每轮都排首位。
然而同一模型在所有三轮都成功的任务只有 78.20%，比三轮均值低约 7.33 个百分点；同一模型跨轮有 30 个任务级结果发生翻转。
本文据此推算不稳定性占：30 个翻转任务除以 555 个总任务约等于 5.4%。也就是说，约每 18 个任务就有 1 个的结果在不同轮次间会变。对采购方来说，这 7.33 个百分点是「均值看板」与「每次都行」之间的距离——如果业务要求的是后者，选型时应以三轮全成功率为口径，而不是以均值为口径。
这也是三份基准共同的方法学短板：SABench 每个模型-任务对只跑一次，CRM-Agent-Bench 主榜只跑一轮，iPrefBench 未披露重复次数。三份都没有给出 pass^k 类的稳定性信号。
iPrefBench：动作齐了，偏好猜错了
iPrefBench 的场景是个人手机助手，切入点是个性化：任务被故意写成欠规范的，缺失的信息分为两类——一类可从用户历史活动推断（inferable），另一类只有用户知道、智能体应当始终询问（ask-only）。
设定为单一用户画像 Jordan Avery，历史包含 3,051 条过去活动事件；任务经三阶段构建流程与两轮人工审核产生。模拟器在智能体询问时按角色回答，角色内准确率 96.6%。评分分三个维度：动作完成率、个性化分数（再分 inferable 与 ask-only）、交互质量（recall 与 precision）。真实任务成功要求动作完成且个性化正确。
| 指标 | Claude Opus 5 | 7 款模型区间 |
|---|---|---|
| 动作完成率 | 91.6% | 77.5% 至 91.6% |
| 个性化分数 | 69.4% | 未披露 |
| 其中 ask-only 信息 | 51.3% | 未披露 |
| 其中 inferable 信息 | 76.3% | 未披露 |
| 真实任务成功率 | 47.7% | 26.2% 至 47.7% |
| 默认询问召回率 | 44.3% | 未披露 |
| 询问精确率 | 60.4% 至 77.1% | 同上区间 |
本文给出一条原文未直说的推算：若动作完成与个性化正确相互独立，Opus 5 的任务成功率应约为 91.6% 乘以 69.4%，即约 63.6%。实际为 47.7%，比独立假设低约 15.9 个百分点。这说明两者并非独立——被猜错的偏好往往正是关键动作上的偏好，不是随机分布在无关细节上。这个发现对产品设计有直接含义：把个性化做对的价值不是均匀分布的，把力气花在「哪些决策会改变动作本身」上，收益高于全面提升个性化准确率。
另一组数字支持这个方向：ask-only 信息上的个性化分数 51.3%，比 inferable 的 76.3% 低 25 个百分点。也就是说，智能体擅长从历史里挖，不擅长在该问的时候开口。
论文还命名了四种失败模式，最常见的是 Silent Guess（明知信息缺失却静默挑一个值）与 Silent Default（甚至没意识到这是用户依赖的决策，直接沿用应用默认值）。这两种失败在日志上都显示为「动作完成」。
多问一点，能换回多少
论文对 Claude Sonnet 5 做了消融：增加显式执行前澄清阶段后，任务成功率从 39.2% 升至 53.8%，召回率从 25.7% 升至 85.0%，但精确率从 60.4% 降至 42.5%。
| 指标 | 默认 | 加澄清阶段 | 变化 |
|---|---|---|---|
| 任务成功率 | 39.2% | 53.8% | +14.6 pp |
| 询问召回率 | 25.7% | 85.0% | +59.3 pp |
| 询问精确率 | 60.4% | 42.5% | −17.9 pp |
本文的读法是：召回率换来 59.3 个百分点，精确率损失 17.9 个百分点，任务成功率只换来 14.6 个百分点。以「每换 1 个百分点成功率需要多少召回率」计，约为 4.06 个百分点召回——边际收益明显递减。原因是问得过多会打扰用户，而打扰本身有代价。
更有意思的是第二个消融：给智能体输入更多历史后，它问得更少、精确率上升，但 ask-only 信息的召回率反而下降——Qwen3.8-27B 从 33.6% 降到 21.2%，下降 12.4 个百分点。论文的解读是：更多历史让智能体成为更大胆的猜测者，而不是更善于判断「这个问题究竟能否从历史回答」。
这条对上下文工程有直接警示。近一年的主流做法是往上下文里塞更多用户历史，iPrefBench 的数据说明这条路存在拐点：历史越多，模型越倾向于自己补完，反而抑制了询问行为。合理的做法是给历史标注来源与置信度，或者把「该不该问」作为单独的判断步骤，而不是让它在填充上下文时被隐式决定。
iPrefBench 的局限也需要明确：只有 130 个任务、单一用户画像、7 个模型；个性化标准答案与用户模拟器来自同一套作者流程；且未提供代码与数据，外部复现仍待进行。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
失败该算谁的账：111 种组合与 52,168 条轨迹
三份基准回答了「完成率掩盖了什么」，还有一个更靠后的问题没回答：失败发生时，责任在模型还是在驾驭层。arXiv 2610.32483（10 月 23 日提交，12 位作者，预印本在审）给出了一个评测框架。
论文的出发点是：智能体基准分数反映的是模型与执行驾驭层的联合行为，因此驾驭层应当通过与底层模型的交互来评测。框架由五个互补测度构成：
- Valid Completion Rate（VCR）：智能体多可靠地正常结束并交付可评估结果，不论任务是否正确
- Model-Harness Fit：对给定模型，驾驭层通过有效完成支持任务达成的程度
- Cross-Model Fit：一款驾驭层跨被测模型的整体适配性
- Interaction Residuals：被组件级汇总掩盖的、特定配对的执行强弱
- Token Load：智能体执行的 token 需求，含失败尝试
评测覆盖四个通用驾驭层——OpenCode、Codex CLI、Pi CLI、DeepAgents——配合四个核心模型，外加两个固定的原生模型-驾驭层系统，在六个基准上覆盖上下文管理、工具使用、长上下文规划、多模态交互与产物交接。计入原生参照与压力条件，共 111 种评测设置、52,168 条轨迹。
结论有两条被明确写出：驾驭层排名随模型与基准变化；任务表现与有效完成可能指向不同的配对，且相似的任务分数可能伴随截然不同的执行画像。具体读数为 OpenCode 跨模型表现居首，DeepSeek V4 Flash Preview 在共享四基准面板上跨驾驭层保持较高的平均 VCR。
把 VCR 与三份基准放在一起看，逻辑是连贯的：SABench 量的是「完成后有没有越界」，CRM-Agent-Bench 量的是「做没做全」，iPrefBench 量的是「猜没猜对」，VCR 量的则是「有没有正常跑完并交出可评结果」。四者都指向同一件事——端到端成功率是一个结果，不是一张体检表。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
读榜检查清单与冷静判断
综合四份材料，本文给出一份面向采购与自评的读榜检查清单。
- 问口径，不问名次：看到百分比先问分子分母。SABench 的 12.8% 是条件比例、11.4% 是全局比例，混用会导致结论差约一成。
- 要求分维度出数：至少要求「没做坏事」「做完了该做的」「猜对了偏好」「正常跑完」四个维度分开报。CRM-Agent-Bench 的 91.2% 与 66.8% 之间隔着 24.4 个百分点。
- 要求重复跑：三轮可靠性下同一模型有约 5.4% 的任务结果翻转，7.33 个百分点是均值与「每次都行」的差。要求 pass^k 而不是 pass@1。
- 按耦合度分级授权：dependent 与 cross-tool 状态下的越界概率约为独立状态的 2.2 至 2.4 倍，护栏应按状态耦合度分级而非按任务类型一刀切。
- 把成本与准确率并排看：最高与最低成本相差 89.3 倍，而前 8 名能力带宽只有 2.88 分。头部选型的主要差异在价格与集成。
- 历史不是越多越好：更多用户历史使 ask-only 召回率下降 12.4 个百分点，上下文工程存在拐点。
- 区分模型与驾驭层的责任：同一模型换驾驭层、同一驾驭层换模型，排名都会变。归因不清时，优化会打在错误的层上。
冷静地说，这几份基准没有证明智能体不能用，而是证明「能不能用」这个问题问得太粗。三份基准的绝对水平并不低——77.8% 的真实成功率、66.8% 的完整合同通过率、47.7% 的真实任务成功率，在各自场景下都足以支撑有人复核的试点。真正的增量认知是：这三组数字分别对应三类不同的盲区，需要三条不同的修复路径，而一条总的成功率会把它们压成一个看不出问题的数字。
同时也应看到各自的边界：SABench 只覆盖办公工具三类领域且每对只跑一次，尚未验证代码编辑与机器人控制；CRM-Agent-Bench 由 CRM 厂商自建自评，独立第三方复现仍待进行；iPrefBench 样本最小且未公开代码；2610.32483 为预印本在审，具体分项读数披露有限。四份材料合起来给出的方向是可信的，任何单一数字的精确值都还需要独立复现。