Era by Eon Benchmark v1（simulator track）

为什么重要

企业 Agent 的评测有一个死结：要评就得有数据，而真正的数据在客户手里，是保密的。

现有的替代品都不解决根本问题——厂商沙箱里几乎没有数据、也没有历史；手工搭的测试环境只覆盖一两个系统，扩展成本高；更关键的是，两者都不提供 ground truth，你能观察 Agent 的行为，却量不出它的准确率。

Era by Eon 的破法很直接：既然真实数据拿不到，那就把一整家公司生成出来。

不是生成一个数据库，是生成一家完整的虚构企业——员工层级与雇佣历史、客户群、销售管线、支持工单、录制通话、聊天消息、文档——然后把它投影进 Salesforce、Zendesk、Slack、Gong、S3、Google Drive 等产品的模拟器。所有模拟器是同一张底层实体图的投影：CRM 里那条商机记录，和工单里、通话录音里提到的客户，是同一个 join key 下的同一个实体。跨系统问题因此是构造上良定义的，而不是事后对齐出来的。

这一步带来的最大好处是判分：每个期望答案都由最终记录计算得出，grading 是精确的，不需要 LLM judge，也不存在人工标注误差。在一个”Agent 评测普遍靠模型打分”的年份里，这一点相当罕见。

（arXiv:2609.09853，作者 Benjamin Gruenbaum、Doron Porat、Assaf Natanzon、Roy Zavida、Chen Dinachi、Or Itzahary，通讯邮箱 assaf@eon.io。）

构建方式

整套环境由四个参数加一个随机种子确定性生成：行业、公司规模、商业模式、应用组合。

机制一：种子化实体图 → 产品模拟器。 同一个种子必然复现完全相同的数据集，因此每次评测可精确重复。Agent 通过各模拟器的 MCP 工具访问环境，且数据面只读——被评测的 Agent 无法改动它自己被判分所依赖的数据。

机制二：题目条件化生成器 → 内部数据库。 真实公司的内部应用 schema 没有厂商会给你固定下来。这里的做法是：基准作者提供业务问题，语言模型设计一次 schema，然后由确定性代码为每个种子生成记录。生成时先从主实体图复制共享实体、键与值，再生成该应用特有的事实；一致性检查会拒绝任何共享键或值与主图冲突的数据库。

题目与答案。 覆盖模拟器的题目来自代码模板，用生成出的公司实体实例化；覆盖内部数据库的题目则反过来指导 schema 与记录生成——生成器会种入”命中行”和”近似未命中行”，再从所有完成行计算最终答案。两套机制都支持正确答案为”所请求信息不存在”的题目，即正确弃答。

验证分两套，各管一段。 内部数据库有显式列计划与种植指令，检查计划遵从度、题目特异性、标签完整性与依赖结构。实体图没有对应的真实公司可比对，于是用真实性记分卡（对照 Eon 运营数据与公开统计的目标分布）加对抗式检测器（专门搜索合成痕迹）来打分。这两件工具反过来驱动了生成器的迭代：跨 23 家生成公司，真实性均分从 61.8 提到 97.0，被标记为”合成”的记录占比从 55.2% 降到 0。

关键发现

1. 分拣简单，聚合崩塌。 九模型平均的能力分项极其分化：

“找出所有符合条件的记录”能到 92.6%，“找出最长的那通电话”只有 6.2%。 难度不在检索，在穷举聚合、多跳 join、时序汇总与有序排名——而后者恰恰是企业里最常见的问法（“这个客户累计通话时长多少""上个月工单解决时长的中位数是多少”）。

2. 有一道题九家模型全军覆没：工单解决时长的中位数。 另外有三道题同时出现在九个模型各自的”最难五题”里：找出最长的 Gong 通话、汇总全部 Gong 通话时长、报告工单数最多的客户的工单优先级分布。九家中还有七家的最难五题里包含一道 Salesforce × Gong 的组合题——先找出未结商机总额最大的客户，再求该客户的累计通话时长。这不是题目刁钻，这是企业分析的主干操作。

3. 头名是”上一代”模型，而且这个结果在统计上站不住。 Claude Opus 4.8 以 76.8% 居首，高于 Opus 5 的 67.7%。但作者自己的校正后两两检验给出了更重要的结论：36 组配对比较中只有 3 组提供了足够证据——Opus 4.8 高出 GPT-5.4 Mini 34.3pp、GPT-5.6 Sol 高出 27.3pp、Sonnet 4.6 高出 21.2pp。其余 33 组全部 inconclusive。 换句话说，这张榜上”谁第一”这个说法本身就不成立，能成立的最强陈述只有”GPT-5.4 Mini 明显更差”。

4. 失败形态比总分更有信息量。 891 次运行产出 561 个正确、119 个错误、99 个误弃答、6 个畸形输出、106 个未答完。三类失败的分布在不同模型间差异极大：

• Claude Opus 4.8：0 个错误答案，但 10 次误弃答 + 13 次未答完——它几乎不答错，代价是相当比例的运行没交出答案
• GPT-5.6 Sol：17 个错误、13 次误弃答、0 次未答完——每次都给你一个答案，但其中 17 个是错的
• GPT-5.5：0 个错误，17 次误弃答——与 Opus 4.8 同型但更保守

“零错误”在这里不是美德，而是弃答换来的。 一个从不答错的模型如果 27% 的运行没有产出，在生产里的价值未必高于一个答错 17 次但从不空手的模型。这是本基准最有辨识度的设计——它把”误弃答”单列为一类失败。

5. 成本极低。 891 次运行的厂商列表价合计 $343.27，平均每次运行不到 0.39 美元。与 Terminal-Bench 4.0（榜首单次约 $3.3k）不在一个量级——企业工具调用类任务的 token 消耗远低于长程终端操作。

最新进展

• 2026-09-09：arXiv:2609.09853 上线，公布 simulator track 的九模型对比，准确率区间 42.4%–76.8%，并明确报告校正后只有 3/36 组配对差异显著
• 2026-09-26 建卡：本卡数值全部取自论文 HTML 全文 Table 1 与第 6、7 节原文，未依赖任何聚合站。三项加和自检均通过：九模型 Wrong 列合计 119、FA 列合计 99、NA 列合计 112（6 畸形 + 106 未答完），与正文”891 次运行产出 561 正确 / 119 错误 / 99 误弃答 / 6 畸形 / 106 未答完”完全吻合；单行层面亦可验证（如 Opus 4.8：99 − 0 − 10 − 13 = 76 → 76.8%）

局限性与展望

• 33 道题决定了这张榜几乎没有分辨力。 三遍重复降低的是生成噪声，不是题目数量。论文给出的 95% 区间宽达 ±15pp 上下，作者自己也承认”确切排序是不确定的”。任何把这张榜当排名用的行为都是误读——它的价值在失败形态与能力分项，不在名次
• 只覆盖一家公司、三个产品。 对比全部跑在同一个 segment_fintech_small 产业上，只用 Gong / Salesforce / Zendesk。全量语料有 83 个场景，另有内部数据库与文档类题目，本次一条都没评
• 题目筛选本身有系统性偏向。 67 道候选题里 8 道因需要尚未支持的 HubSpot/Jira/Slack 或跨系统身份操作被剔除，26 道涉及文档等非结构化产物、未被本次工具使用赛道暴露——剩余 33 题是”能被当前工具层支持的题”，天然偏简单。剔除在模型运行前固定，不影响可比性，但影响代表性
• 真实性目标的可靠性未被独立验证。 目标分布多数来自 Eon 自己的运营数据或公开统计，部分是估计值（虽已标注）。记分卡衡量的是”与目标的吻合度”，不是”目标本身的真伪”——目标错了，生成器会被推向一个错误的分布
• 模板生成文本有天花板。 内容多样性轴与对抗检测器目前都通过，但种子化模板 + 槽填充的文本，在多样性、个人化与错误模式上达不到人工写作的水平；更强的检测器未必分不出
• 利益关系：Eon 是提供企业数据相关产品的商业公司，本基准既是其技术展示也是其能力证明，读分数时把这层关系算进去

关联基准

• τ-bench：同样是”企业工具调用 + 策略遵循”，但只有零售与航空两个手工构造域，本基准可视为对其规模化路线的回应
• Terminal-Bench 4.0：同为 Agent 评测，但走”滚动淘汰饱和任务”路线，且单次成本高三个数量级
• ALE：真实职业工作流，同样追求”真任务”，但答案比对方式不同
• DAREBench：用统一运行时与证据审计解决跨基准分数不可比，与本卡的”精确到计算的标准答案”是两条不同的可信化路径