两份材料：谁做的、测什么、怎么测
读基准之前先要弄清三件事：谁做的、测的是什么、怎么判分。两份材料在这三点上差异明显，把它们对齐之后才谈得上交叉。
| 维度 | EGI-BENCH（arXiv 2610.27234） | PACE（arXiv 2610.26394） |
|---|---|---|
| 提交时间 | 2026 年 10 月 19 日 20:02 UTC | 2026 年 10 月 19 日 13:39 UTC |
| 定位 | 统一八个企业向基准的评测套件与聚合分数 | 成熟企业仓库中的 PRD 驱动开发评测 |
| 任务来源 | 八个既有基准的既有任务 | 43 个企业任务，新建 |
| 判分单元 | 750 个之外的细粒度子指标，路由进六维 | 750 个专家审计的 Code Points |
| 被测对象 | GPT、Claude、Gemini 三族共 14 款模型 | 11 种模型与脚手架组合 |
| 主指标 | 六维加权 EGI 总分 | PRD 满足度分数与完整交付率 |
| 代码 | SalesforceAIResearch/egi-bench | TianqiLiu1/PACE-Bench |
EGI-BENCH 的作者在摘要里把动机写得很直白：企业采用 LLM 做智能体工作流，需要横跨 CRM 操作、异构文档检索、个人数据理解、多轮规划、工具使用、函数调用、长程研究与长上下文软件工程等一大片能力，而这些评测今天散落在各自独立的仓库里，运行器、依赖与计分口径各不相同，跨基准比较因此变得困难，一个聚合数字究竟代表什么也变得模糊。
PACE 的动机是另一条线。既有编码基准要么测 issue 修复，要么测从零开发，两者都绕开了「按一份产品需求文档增量交付」这个企业里最常见的形态；而孤立的单测又不足以证明业务与集成需求被满足。PACE 因此把需求重建、判据构建与基于证据的评测三件事串起来。
EGI-BENCH 报告的全部主表结果来自 quick 模式，作者自己在局限里写明 quick 模式为适配预算做了子集化，置信区间更宽，只能作方向性指示，面向发布的决策应依赖 deep 模式。PACE 的结果来自 11 种模型与脚手架组合。两份材料均未声明独立复现或第三方审计。本文所有数字均取自两篇论文的公开摘要与正文，涉及换算处已标注为本文推算。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
EGI 的六维框架与那组权重
EGI-BENCH 没有简单地把八个基准的总分再平均一次，而是定义了六个维度，把各基准的细粒度子指标路由进对应的桶。
| 维度 | 名称 | 权重 | 回答的问题 | 主要子指标来源 |
|---|---|---|---|---|
| M1 | 任务结果准确性 | 28% | 有没有产出正确的业务结果 | CRMArena、Benchforce、LoCoBench |
| M2 | 工具动作可靠性 | 22% | 工具选得对不对、参数与顺序对不对 | MCP-Universe、MCPEval、Benchforce |
| M3 | 规划与工作流 | 16% | 多步多轮执行是否高效 | UserBench、LoCoBench |
| M4 | 检索与证据落地 | 14% | 回答是否有检索到的证据支撑 | CRMArena、HERB、PersonaBench |
| M5 | 安全、弃权与策略 | 14% | 该拒的时候拒不拒、是否违规 | CRMArena、HERB、Benchforce |
| M6 | 工程性与可维护性 | 6% | 产出的代码质量是否过得去 | LoCoBench |
聚合公式为 EGI 等于 0.28 乘 M1 加 0.22 乘 M2 加 0.16 乘 M3 加 0.14 乘 M4 加 0.14 乘 M5 加 0.06 乘 M6。每个子指标先归一化到 0 到 100 区间，越小越好的指标会先反转再路由；每个桶默认对路由进来的子指标取等权均值。
论文还提供了一项可选的发布门限：M5 与 M2 的默认阈值为 70，任一项低于 70 会被标记为尚未达到发布就绪。值得注意的是，这个门限不改变 EGI 分数本身——也就是说，一款模型可以拿到总分榜首，同时被标成不适合发布。后面会看到，这不是假设。
14 款模型的六维全表
下表为 quick 模式下 14 款模型的完整六维得分，按 EGI 降序排列。括号内为该列的列最佳。
| 排名 | 模型 | EGI | M1 | M2 | M3 | M4 | M5 | M6 |
|---|---|---|---|---|---|---|---|---|
| 1 | gpt-5.5 | 65.61 | 82.95 | 79.56 | 30.89 | 54.86 | 63.47 | 56.23 |
| 2 | Claude Sonnet 4.5 | 65.25 | 69.89 | 87.17 | 27.48 | 53.04 | 80.28 | 57.34 |
| 3 | Gemini 3.1 Pro Prev. | 63.51 | 78.45 | 76.82 | 19.57 | 54.43 | 75.56 | 55.30 |
| 4 | Claude Opus 4.5 | 63.31 | 74.29 | 75.58 | 27.95 | 52.08 | 75.56 | 58.98 |
| 5 | GPT-4o | 59.38 | 66.18 | 84.22 | 23.88 | 39.47 | 53.61 | 51.95 |
| 6 | Claude Haiku 4.5 | 59.13 | 69.02 | 73.98 | 24.05 | 48.61 | 65.69 | 61.28 |
| 7 | Gemini 2.5 Pro | 59.10 | 76.05 | 65.60 | 27.16 | 50.58 | 60.83 | 57.25 |
| 8 | GPT-4.1 | 58.31 | 69.88 | 81.60 | 27.36 | 44.99 | 49.03 | 54.19 |
| 9 | GPT-5 mini | 51.91 | 59.10 | 67.74 | 21.75 | 43.05 | 54.17 | 56.12 |
| 10 | Gemini 2.5 Flash | 51.36 | 59.25 | 64.10 | 24.72 | 40.99 | 54.58 | 55.48 |
| 11 | Claude 3.5 Haiku | 50.78 | 48.16 | 75.81 | 18.39 | 44.35 | 58.61 | 54.36 |
| 12 | Gemini 2.0 Flash | 49.29 | 48.57 | 72.53 | 20.65 | 42.54 | 51.67 | 53.96 |
| 13 | GPT-5 nano | 45.14 | 42.38 | 72.05 | 15.68 | 43.31 | 41.25 | 51.25 |
| 14 | GPT-4o mini | 39.56 | 30.91 | 64.45 | 16.66 | 39.33 | 39.17 | 51.14 |
领跑分布是这份表里信息量最大的部分。gpt-5.5 领跑 M1、M3、M4；Claude Sonnet 4.5 领跑 M2 与 M5；而 M6 的榜首是总分只排第六的 Claude Haiku 4.5。换句话说，七项指标（总分加六维）分布在四款不同的模型身上。
极差分析：哪些维度分得出高下，哪些分不出
把每个维度的最高值与最低值相减，可以得到一组极差。极差大说明这个维度能区分模型强弱，极差小说明大家普遍不行或者普遍差不多。这是本文基于上表的推算。
| 维度 | 最高 | 最低 | 极差 | 本文解读 |
|---|---|---|---|---|
| M1 任务结果 | 82.95 | 30.91 | 52.04 | 区分度最高，是拉开总分差距的主因 |
| M5 安全与弃权 | 80.28 | 39.17 | 41.11 | 区分度次高，且分布与总分不一致 |
| M2 工具动作 | 87.17 | 64.45 | 22.72 | 整体水平较高，是相对成熟的维度 |
| M4 检索落地 | 54.86 | 39.33 | 15.53 | 极差小且绝对值低，属共性瓶颈 |
| M3 规划 | 30.89 | 15.68 | 15.21 | 极差小且绝对值极低，属共性瓶颈 |
| M6 工程性 | 61.28 | 51.14 | 10.14 | 极差最小，且权重只有 6% |
| EGI 总分 | 65.61 | 39.56 | 26.05 | 约等于 M1 极差的一半 |
三个极差小于 16 分的维度——M3、M4、M6——值得放在一起看。它们的绝对值也都不高：M3 全部 14 款模型落在 15.68 到 30.89 之间，九成以上低于 28；M4 落在 39.33 到 54.86 之间。这意味着在「把多步流程组织好」「把回答锚在检索到的证据上」「产出过得去的代码」这三件事上，换模型带来的改善相当有限。
与之相对，M1 与 M5 的极差都超过 40 分。这给出一个相当清晰的判断：当前这一代模型在企业场景中的差距，主要体现在「能不能做对」和「该不该做」上，而不是「步骤排得顺不顺」或「引用标得准不准」。后者是行业共同欠的账，短期内靠换模型换不出来。
还有一条容易被忽略：M6 权重只有 6%，极差又只有 10.14 分，它对 EGI 总分的贡献上限约为 0.61 分（6% 乘 10.14）。而榜首与次席的分差只有 0.36 分。这说明这个权重最低的维度在总分层面几乎无法区分模型，却恰恰是 Claude Haiku 4.5 全表最好的一项——一款总分第六的模型，在工程质量上是十四款里最好的。
按论文自己的门限做一次达标统计
EGI-BENCH 给了一个可选的发布门限：M5 与 M2 的默认阈值都是 70，任一项低于 70 即被标记为尚未达到发布就绪，但不影响 EGI 分数。本文按这个门限对 14 款模型做了一次统计，这是论文没有直接给出的。
| 门限 | 达标模型数 | 达标的模型 |
|---|---|---|
| M2 不低于 70（工具动作） | 10 款 | gpt-5.5、Claude Sonnet 4.5、Gemini 3.1 Pro Prev.、Claude Opus 4.5、GPT-4o、Claude Haiku 4.5、GPT-4.1、Claude 3.5 Haiku、Gemini 2.0 Flash、GPT-5 nano；未达标的是 Gemini 2.5 Pro、GPT-5 mini、Gemini 2.5 Flash、GPT-4o mini |
| M5 不低于 70（安全与弃权） | 3 款 | Claude Sonnet 4.5（80.28）、Gemini 3.1 Pro Prev.（75.56）、Claude Opus 4.5（75.56） |
| 两项同时达标 | 3 款 | Claude Sonnet 4.5、Gemini 3.1 Pro Prev.、Claude Opus 4.5 |
这组数字里最扎眼的是：总分榜首的 gpt-5.5，M5 只有 63.47，低于门限 6.53 分，按论文自己的标准会被标记为尚未达到发布就绪。而总分第二的 Claude Sonnet 4.5，M5 是 80.28，是全表仅有的一个超过 76 的安全分。
换句话说，工具动作这一关 14 款里有 10 款过了，安全与弃权这一关只有 3 款过了。卡点在后者，而不是前者。这与前面极差分析的结论一致：M5 的分布与总分分布并不重合，一款模型完全可以在加权总分上领跑，同时在安全与弃权上排在第六位。
需要提醒的是，这个门限在论文中是可选的，且作者明确说明它不改变 EGI 分数。本文把它单独拎出来算，是为了说明「总分高」与「可发布」在框架内部就是两个不同的判断，不应互相替代。
权重敏感性推算：换一把尺子，榜首就换人
EGI 的六维权重是专家判断，作者自己在局限里写明尚未做经验校准。既然如此，本文做了一次简单的敏感性检查：如果把权重换一种给法，排名会怎么变。以下三行均为本文按上表数值的算术推算，不是论文结论。
| 加权方式 | gpt-5.5 | Claude Sonnet 4.5 | Gemini 3.1 Pro Prev. | Claude Opus 4.5 | 该方式下的首位 |
|---|---|---|---|---|---|
| 论文原权重（EGI） | 65.61 | 65.25 | 63.51 | 63.31 | gpt-5.5 |
| M1 与 M5 等权各 50% | 73.21 | 75.09 | 77.01 | 74.93 | Gemini 3.1 Pro Prev. |
| M2 与 M5 等权各 50% | 71.52 | 83.73 | 76.19 | 75.57 | Claude Sonnet 4.5 |
三种加权方式产生了三个不同的榜首。这件事的含义不是「榜单不可信」，而是：当六维之间的差距达到 M1 极差 52 分、M5 极差 41 分这种量级时，聚合分的排名主要由权重决定，而不是主要由模型决定。
对企业采用者来说，这给出一个相当实用的操作建议：不要直接引用 EGI 总分做选型，而应先确定自己业务里 M1 到 M6 各自的重要性，再按自己的权重重算一次。论文提供的六维分解恰恰让这件事成为可能——这也正是作者强调「单一标量会压缩信息」的原因。
PACE：52.1 到 78.1 的分数与 14.0% 的交付率
PACE 的评测单元是 43 个成熟企业仓库上的任务，配 750 个专家审计过的代码点。它把需求重建、判据构建与基于证据的评测三步串起来，目的不是看智能体能不能写对一段函数，而是看它有没有把一份产品需求文档实现完整。
结果方面，11 种模型与脚手架组合的分数大多落在 52.1 到 78.1 之间；完整交付率最高的是 GPT-5.6-Sol，也只有 14.0%。作者指出，不完整实现与缺失集成是两个主要瓶颈——把各个组件分别做出来，并不等于完成了一次交付。
评测方法本身也有一组可信度数据：PACE 的判分与专家共识的一致率为 95.2%，并且判分记录之间的用例级波动低于重复执行之间的波动。这后一条相当关键，它说明这套评测的噪声小于被测系统本身的噪声，这在一个以模型为裁判的年代并不常见。
两把尺子的落差：加权分与二值判定不是一回事
把两份材料的主指标放在一行里看，落差非常直接：EGI 的榜首是 65.61 分，看起来像是及格线之上；PACE 最好的完整交付率是 14.0%，看起来几乎不可用。同一个时间点的两篇论文，怎么会给出观感差这么远的结论？
| 对比项 | EGI-BENCH | PACE |
|---|---|---|
| 计分方式 | 子指标归一化后加权求和，部分得分可累积 | 按 PRD 判据逐点给分，另设完整交付的二值判定 |
| 最好结果 | 65.61（gpt-5.5，quick 模式） | 78.1 分区间上沿；完整交付率 14.0% |
| 最差结果 | 39.56（GPT-4o mini） | 52.1 分区间下沿 |
| 主要瓶颈 | M3 规划与 M4 检索，两维极差均小于 16 分 | 不完整实现与缺失集成 |
| 分数分布形态 | 连续，头部与尾部差约 26 分 | 分数集中但完整交付率极低 |
差别来自计量单位。EGI 是加权求和，做对一半的子指标就能拿到约一半的分；完整交付率是二值判定，少一个集成点就归零。前者衡量的是「平均做得多好」，后者衡量的是「有多少次真的做完了」。这两个问题在企业里都有意义，但对应的场景完全不同。
本文据此给出一条判断：如果一项工作可以被拆成若干个彼此独立、失败一个也不影响其他的部分，加权分是合适的指标；如果一项工作要求端到端跑通才算数——一次报销、一次下单、一次部署——那么完整交付率才是该看的那一个，而在这个指标上，当前最好模型的表现是 14.0%。
这也解释了为什么不少团队的实际体验与榜单观感存在落差：他们看到的是 60 多分的聚合分，跑起来遇到的却是 14% 的端到端成功率。
PACE 给出一个罕见的对照：在使用同一模型与同一套任务的前提下，连续的脚手架版本把平均分从 59.4 提升到 63.0，提升 3.6 分。EGI 全表 14 款模型的总分极差是 26.05 分。把这两个数字放在一起，3.6 分约相当于模型间总分差距的 13.8%（本文算术推算）。也就是说，换一轮脚手架带来的收益，大约相当于跨过六分之一左右的模型代际差距——不算小，但远不足以替代选对模型。这个换算跨越了两套不同基准，只能作量级参考。
脚手架迭代值多少分
PACE 除了做模型比较，还给出一个 harness 侧的反馈闭环：诊断结果可以指导针对性改进，而连续的脚手架发布在使用同一模型与同一任务集的情况下把平均分从 59.4 提升到 63.0。
这个数字的价值在于它是同模型对照。多数基准报告的是「换模型涨了几分」，很少给出「模型不动、只改脚手架涨了几分」。3.6 分在 PACE 自己的分数区间（52.1 到 78.1）里约占 13.8% 的位置，与 EGI 全表 26.05 分的极差相比约为 13.8%。两个口径都指向相近的量级，说明脚手架层的优化空间客观存在，但它的量级更接近一次小的版本迭代，而不是一次代际跃迁。
PACE 的诊断能力本身也值得注意。它把交付缺口与智能体行为联系起来，因此改进是有靶子的，不是靠试。这与本栏目此前拆解过的若干 Harness 层自优化工作方向一致——不动权重，改外面那层。
预算与裁判：两处容易被忽略的方法学设定
EGI-BENCH 的两种模式完全由墙钟时间定义，而不是由 token 上限或固定运行时间表决定。quick 模式总墙钟约 180 分钟以内，并行度设为两个 worker；deep 模式约 12 小时。子集化由各基准的运行时预算自动决定，规则是至少保留每个已有类别的一个任务，先减少每类任务数再考虑丢弃类别，若必须丢弃则优先丢弃其路由桶已被其他基准冗余覆盖的类别，子集定义会记录在配置文件中。
| 基准 | quick 模式覆盖范围 | deep 模式覆盖范围 |
|---|---|---|
| CRMArena | 全部 9 类任务，每类最多 6 个 | 扩展至上游默认 |
| HERB | 可答与不可答模式共 80 题 | 全量 |
| PersonaBench | 3 人、社区 0 与 1、噪声 0.0 与 0.7 | 噪声扩到四档 |
| UserBench | 三个环境，每环境最多 60 个任务、20 轮 | 全部环境 |
| MCP-Universe | financial_analysis 一个域、20 个任务 | 三个域（受 API Key 门控） |
| MCPEval | airbnb 一个域、50 个任务、20 轮 | 三个域各 50 个任务 |
| Benchforce | hospital 一个环境、40 条、15 轮 | 两个环境全量 |
| LoCoBench | easy 难度、30 个场景、1800 秒超时 | 500 个完整场景 |
裁判侧有一处设定必须知道：OPENAI_API_KEY 是必需的，即便被测模型并非 OpenAI 的模型，因为裁判与模拟器调用被固定到了 OpenAI。deep 模式还受益于若干可选 Key，缺失时对应域会被跳过并在覆盖率上标注，不算运行失败，但聚合报告的覆盖率会下降。这意味着跨团队比较时，如果可选 Key 的配置不同，实际评测范围并不相同。
两份论文各自写明的局限
EGI-BENCH 在第七节列了四条局限。其一，quick 模式的子集化让子指标平均基于更少样本，置信区间更宽，quick 模式 EGI 只能作为方向性指示，面向发布的决策应依赖 deep 模式。其二，六维权重基于专家判断，尚未按照企业风险做经验校准，把权重拟合到真实部署事故率属于未来工作。其三，任何单一标量都会压缩信息，需要结合六维分解诊断具体能力回归。其四，MCP-Universe 的部分评测使用 LLM 裁判，裁判模型的选择与裁判漂移会在被测模型完全不变的情况下改变绝对分数，同一发布内通过固定裁判保持稳定，但跨发布比较必须注明裁判版本。
在相关工作部分，作者还指出 EGI-BENCH 当前版本缺少 τ-bench 与 τ²-bench 那类大试验可靠性信号，例如 pass^k 与自动错误归因，并把它列为未来工作。这一条对读榜的人很重要：目前的分数是单次运行的水平，没有给出「跑八次能对几次」这类可靠性维度。
PACE 侧的边界相对集中在场景定义上：43 个任务与 750 个代码点是专家审计过的，但样本规模不大，且来自成熟企业仓库这一特定形态，能否推广到从零启动的项目或高度定制的内部系统，论文未作主张。11 种模型与脚手架组合的配置明细也未在摘要中完整展开。
读榜检查：四条不能跳过的口径提示
其一，EGI 的公开主表全部来自 quick 模式。论文自己说这只能作方向性指示。任何把它当作选型主要依据的做法都跳过了作者写明的限定。
其二，权重决定了排名。本文的敏感性推算显示三种加权方式给出三个不同的榜首。引用总分之前先确认自己的业务更看重哪一维。
其三，安全与弃权是独立的门禁。总分榜首的 gpt-5.5 在自己的门限下不达标，这件事说明可发布性与分数是两个判断。企业尤其不该用总分替代安全评估。
其四，聚合分与完整交付率不能互相换算。60 多分的加权分与 14.0% 的端到端交付率并不矛盾，它们量的是不同的东西，而后者更接近真实业务里「这件事到底办成了没有」。
冷静判断：这些数字能怎么用
两份材料共同的价值，是把企业场景的评测从「能不能跑通一个 demo」推进到「能不能按需求交付」。EGI-BENCH 的贡献在横向可比，它把八个原本互不相通的基准塞进一个框架，并明确拒绝用单一标量掩盖能力差异；PACE 的贡献在纵向可信，它用专家审计的代码点把「交付」这件事拆成了可判的单元，并给出了判分噪声低于执行噪声的证据。
它们共同的局限也很清楚：两份都是预印本，EGI 的主表只跑了预算受限的 quick 模式，PACE 的样本规模有限。EGI-BENCH 的权重未经验校准，PACE 的完整交付率只有 14.0% 但论文并未展开各组合的具体配置明细。
对使用者的建议是三句话。选型时看六维而不是总分，并按自己的权重重算；评估可行性时看完整交付率而不是加权分；评估自己的系统时，同时记录分数与端到端成功率这两个数，因为它们的落差本身就是最有价值的运营指标。