OccuBench：通过语言世界模型评估 AI 智能体在真实职业任务上的表现 OccuBench: Evaluating AI Agents on Real-World Professional Tasks via Language World Models
用LLM模拟100个职业场景，跨10大行业测评15个前沿智能体的鲁棒性与行业专长。
前置知识
LLM智能体（LLM Agent）
以大语言模型为决策核心，通过多轮工具调用与环境交互的自主系统。每个回合，agent 根据历史 $H_{t-1}$ 输出动作 $a_t$，接收观察 $o_t$，循环迭代直到完成用户指令。
OccuBench 的核心评估对象就是 LLM agent 在专业场景下的多步骤决策能力，没有 agent 与工具交互的概念就无法理解 LES 的设计动机。
世界模型 / 环境模拟器（World Model）
一个学习或编码环境状态转移函数 $f(s_{t+1}, o_{t+1}) = g(s_t, a_t)$ 的模型；传统如 Dreamer、IRIS 面向低维状态空间，本文 LES 把这种思想扩展到 LLM 驱动的工具响应模拟。
LES 是论文最核心的贡献，理解世界模型范式才知道为何把环境搭建从工程问题转为配置问题是一次范式转变。
工具调用（Tool Use / Function Calling）
智能体输出结构化 JSON 描述对外部 API 的调用，由执行器真正发起请求并返回结果；评测中常以工具 schema、调用次数、参数合法性等维度衡量能力。
OccuBench 的每个场景都定义了 2–10 个工具，测评指标包括完成率、步骤数、抗故障能力，全部围绕工具调用展开。
多智能体合成流水线（Multi-Agent Synthesis）
用多个专门的 LLM 角色（如生成器、验证器、修复器）协作产出带质量保证的数据集；通常包括生成、求解性验证、难度校准、迭代修复等阶段。
论文第 4 节介绍的合成管线是 OccuBench 数据质量的保证机制，不理解多 agent 协作就无法把握为何任务具有"可解且可区分"的特性。
研究动机
现有智能体评测基准严重偏向少数有公开 API 的领域：WebArena 测网页浏览、OSWorld 测桌面操作、SWE-bench 测代码仓库、TAU-bench 测零售与航空 API。这导致在 AI 最具应用价值的医疗分诊、金融审计、工厂排产、核电站安全监控、海关报关等数百个专业职业领域，几乎没有任何评测环境。表 1 之前的引言把这称为"the untestable majority"。另一个关键缺陷是现有基准只在 happy path 上评估，缺少对环境噪声（API 超时、数据截断、字段缺失）的系统鲁棒性测试，而真实部署中这类故障不可避免。第三，工程成本高昂——为 WebArena 加一个新域需部署整套网站，为 TAU-bench 加新域需集成真实 API，把评测扩展到几十上百个职业领域实际上不可行。
本文的目标是本文提出 OCCUBENCH，目标是把"不可评测的大多数"职业任务变得可评测。具体而言：(1) 覆盖 100 个真实职业场景、65 个专业域、10 大行业类别，共 382 个评测实例；(2) 评测沿两条正交维度展开——跨行业的任务完成率，以及在显式错误（E1）、隐式数据降质（E2）、混合故障（E3）下的鲁棒性；(3) 评估 15 个跨 8 个模型家族的前沿模型，并系统比较代际、规模、推理深度的影响。作者希望借此填补跨职业 AI 评测的空白，让组织能基于自身行业挑选最合适的 agent 模型。
与已有工作不同的是，区别于 GDPVal、$OneMillion-Bench 等聚焦"交付物质量"的基准（评写作、PPT），也区别于 TheAgentCompany、SWE-Lancer 等偏软件邻接领域的工作，OCCUBENCH 聚焦"交互式多步决策"，覆盖 65 个非软件的专业领域。作者的关键切入点是引入 Language Environment Simulator（LES）——把环境构建从工程问题变成配置问题：只要 LLM 理解某域的运作逻辑，就能用一段 system prompt + 工具 schema + 初始状态 + 状态描述，配置出该域的 stateful 交互环境。这是对传统"需要真实 API 才能评测"范式的根本突破。
核心方法
OCCUBENCH 的核心思路是把"环境"重新定义为一段可配置的语言提示，而不是一段部署好的真实代码。具体地，把每个评测环境 $c$ 形式化为四元组（系统提示、工具 schema、初始 JSON 状态、字段语义描述），由一个充当 LES 的 LLM 读入 agent 的动作 $a_t$ 与历史 $H_{t-1}$，输出下一观察 $o_t = f_\theta(s_t, a_t; c)$。评测时由待测模型做 agent，由 Gemini-3-Flash-Preview 担任 LES；任务完成后由基于评分细则的验证器做多数投票判定通过与否。382 个任务实例则通过多 agent 合成管线（生成 → 求解性验证 → 难度校准 → 修复）批量产出，确保每个任务可解、可区分、结构多样。这种"语言即环境"的设计是 OccuBench 与传统评测体系最本质的差异。
核心创新是把环境构建从"工程部署"转为"配置编辑"。传统世界模型（如 Dreamer、IRIS）从数据中学习状态转移；LES 则直接调用 LLM 已有的领域知识，让系统提示编码模拟规则、工具 schema 定义动作空间、初始 JSON 锁定起点、状态描述保证长程因果一致性。这一思路把扩展评测域的成本从"部署一套网站"降到"写一份配置文档"，是评测范式的根本转变。此外，OCCUBENCH 把鲁棒性评测作为一等公民：通过向 LES 的系统提示追加故障规则（E1 注入 500/Timeout、 E2 注入字段截断、E3 混合），无需修改 agent 代码即可系统化测其在噪声下的退化程度。
方法步骤详情
方法包含三条流水线。LES 配置化：每个环境由四部分组成——系统提示定义模拟规则（如酒店定价、医院分诊流程）、工具 schema 描述 2–10 个工具（平均 5 个）的参数与示例输出、初始 JSON 锁定起点（房间库存、患者队列）、状态描述注解字段语义以保证 LLM 的因果一致性。多 agent 合成管线（Gemini-3-Flash-Preview 为 LES）：先生成环境配置、任务指令、工具定义、解题计划与评分细则；再以"有/无参考计划"两种模式多次执行验证可解性并校准难度；rubric-based 多数投票验证轨迹；修复模块诊断失败后重跑；最后过滤全成功、全失败、工具 schema 非法三类实例。鲁棒性故障注入：E0 干净基线；E1 显式错误（500、TimeoutError、ConnectionRefused、ServiceUnavailable）；E2 隐式降质（截断字段、缺项、null、stale 缓存）；E3 约一半显式一半隐式。故障瞬时（重试可恢复），由故障次数（默认 2）和持续轮数（默认 2）两参数控制。最终 382 任务，以"自洽成功率最低"的难度档作为评测关卡，平均每任务 5.5 个工具、16.2 次调用。
技术新颖性
新颖性体现在四点。第一，把世界模型范式从"训练时用"（如 WebWorld 训 1M+ 交互做 agent 训练）首次规模化地迁移到"评测时用"，且支持 stateful 多步工具交互而非低维状态转移。第二，16 个非重叠子主题 + 专业参考文档的结构化多样性设计，确保实例在结构而非表面差异（避免了 LLM 生成题目的同质化问题）。第三，首次系统化区分显式 vs 隐式环境故障并量化其对 9 个旗舰模型的影响——发现隐式故障比显式更难的反直觉结论。第四，提出"强 agent 不等于强 simulator"的洞察：通过 8×3 跨仿真器矩阵证明，GPT-5.2 做 agent 第一但做 simulator 最差（其他 agent 在其下的平均分仅 29.3%，对比 Gemini Flash 下 67.9%）；同时给出 85.7% 的 pairwise ranking agreement 上限，证明 LES 评测在 simulator 足够强时是可信赖的。
实验结果
论文围绕 5 个核心问题展开实验。(1) 跨行业完成率（Table 2）：15 个模型平均完成率排序为 GPT-5.2 (79.6%) > Gemini 3.1 Pro (72.3%) > Claude Opus 4.6 (71.5%) > Qwen 3.5 Plus (69.9%) > DeepSeek V3.2 (69.6%)，最低 Claude Sonnet 4 (53.4%)。无单一模型全行业领先：GPT-5.2 在 Sci (94%) 最佳但 Commerce 仅 67%；Claude Opus 4.6 在 Transportation (77%) 居首但 Commerce 仅 53%。(2) 环境鲁棒性（Table 3）：9 个旗舰模型平均 E0=67.5%、E1=62.6%（-4.9）、E2=53.4%（-14.1）、E3=54.4%。E2 隐式故障最难——4/9 模型在 E2 下比 E3 更差；Opus 4.6 在 E2 下跌 17.6 点至 53.9%。(3) 模型缩放（Figure 5）：同家族大模型稳定领先——Gemini Pro vs Flash-Lite +11.0、Qwen Plus vs Flash +10.2、Opus vs Sonnet 4.6 +7.1。(4) 推理深度（Figure 7）：GPT-5.2 从 none (54.7%) 到 xhigh (82.2%) 单调提升 27.5 点；Opus 4.6 从 low (70.2%) 到 max (73.8%) 提升 3.6 点。(5) Simulator 质量（Table 4, Figure 8）：GPT-5.2 做 simulator 时 8 个 agent 平均仅 29.3%（远低于 Gemini Flash 下 67.9%）；pairwise agreement 显示 Gemini Flash 与 Qwen 3.5+ 一致率 85.7%，前 3 名 agent 排序完全一致，证明 LES 评测在强 simulator 下可信。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 跨行业任务完成率 E0（10 大行业平均） | Completion Rate (%) | GPT-5.2 平均 79.6%，Sci 94%、Biz 86% | Claude Sonnet 4 仅 53.4% | 最佳 vs 最差差距 26.2 个百分点 |
| 环境鲁棒性（E2 隐式故障下完成率） | Robustness R = min(E1,E2,E3)/E0 | Gemini 3.1 Pro R=0.87，M2.7 R=0.87 | Kimi K2.5 R=0.63，Claude Sonnet 4.6 R=0.70 | 最强 vs 最弱鲁棒分数差 0.24 |
| 推理深度对 E0 完成率的影响 | Completion Rate (%) vs reasoning effort | GPT-5.2 xhigh 82.2% | GPT-5.2 none 54.7% | +27.5 个百分点（同一模型） |
| 代际进展（Claude Opus 三代） | E0 Completion Rate (%) | Opus 4.6 平均 71.5% | Opus 4 平均 61.3% | +10.2 个百分点跨越三个版本 |
| 跨仿真器 pairwise ranking agreement | 28 对模型排序一致率 | Gemini Flash vs Qwen 3.5+ 一致 85.7%（24/28 对） | Gemini Flash vs GPT-5.2 simulator 仅 75.0% | 强 simulator 下评测可信赖，弱 simulator 下结论失真 |
局限与改进
作者明确承认两点核心局限。第一，**仿真保真度**：LES 模拟的是"领域逻辑"而非"领域数据"。它知道药物相互作用检查应返回禁忌项，但具体数值是生成而非查真实数据库——因此 OCCUBENCH 评估的是 agent 的"决策过程"（检查顺序、对错），而非对精确数值的处理。对金融精算到分这种数值敏感场景，必须配合真实环境测试。第二，**simulator 依赖**：跨仿真器实验表明评测结果与合成时所采用的 simulator 绑定。同样的任务在 Gemini-3-Flash 下可解，在 GPT-5.2 simulator 下可能无解（GPT-5.2 simulator 下 8 个 agent 平均仅 29.3%）；agent 排名也会随 simulator 变化（Qwen 3.5+ simulator 与 Gemini Flash 在 28 对中只对 24 对排序一致）。这是 LES 评测的固有局限——simulator 不是中立观察者，而是评测设备的一部分。隐含的第三点局限：382 个实例对 65 个域平均每域不到 6 个，覆盖深度有限；任务全部基于合成场景，与现实企业系统仍有距离。
独立分析的弱点
从独立视角看，OCCUBENCH 还有几个可改进的弱点。(1) 故障建模偏简单：E1 故障被动注入到 LES 响应中，未模拟真实环境的级联故障（超时引发下游接口连锁失败），也未考虑时序相关故障；E2 截断是固定规则，缺少对部分查询路径的精细干扰。改进方向是引入基于状态机的故障注入器，让故障触发概率依赖任务阶段与历史动作。(2) 评分过度依赖 LLM judge：rubric 多数投票由 Gemini-3-Flash-Preview 担任，与 LES 同源存在自验证偏差。Figure 14 中 Qwen 3.5 Plus 未调用 `get water chemistry(5)` 即声称 "ammonia remained low"，验证器接受了无证据主张——暴露了 LLM judge 对"未调用"与"已调用但为空"的辨别薄弱。(3) 行业不平衡：100 场景分布 19/16/12/11/9/8/7/7/7/4，Business 与 Tech 占 35%，Science 仅 4 场景，跨域结论统计效力受限。(4) simulator 质量门槛不明确：85.7% 一致率是后验观察，没有事前可计算的 simulator 质量指标。
未来方向
作者与读者都可延展多个方向。(1) 作者提出的方向：在 LES 评测中建立 simulator 质量门槛与事前校验——例如先跑一组"诊断任务"（已知答案的 reference trajectory）评估 simulator 的状态保持、规则遵循、错误响应一致性，再决定是否采纳评测结果。(2) 隐式故障的更深建模：把"截断"扩展为"语义不一致"（字段值与 schema 冲突但格式合法）、"陈旧数据"（返回 24 小时前快照）、"幻觉"（生成不在 state 中的实体）。Figure 9-11 已展现 state fabrication / entity omission / rule invention 三种失败模式，恰是真实 LLM-as-a-service 常遭遇的故障类型。(3) 多 simulator 集成评测：与其纠结"哪个 simulator 最对"，不如同时跑 K 个 simulator，把通过率视作分布——只有 K 个 simulator 都通过才记为完成。(4) 真实环境桥接：把 OCCUBENCH 合成场景作为 pre-deployment filter，把 GDPVal / SWE-Lancer 真实任务作为 fine-grained 校验，建立"廉价合成 → 高保真真实"的两阶段流水线。
复现评估
复现性整体较好但仍有门槛。**开源情况**：作者明确提供 Project Page、Code、Data 三个链接，方法论层面没有黑盒成分——LES、合成管线、评测 prompt 都可复现。**数据规模**：382 个评测实例 + 16 个子主题/场景 × 100 场景 ≈ 1600 个候选任务再经多轮过滤得到最终集合，规模适中。**算力门槛**：评测 15 个模型 × 382 个任务 × 4 个环境（E0/E1/E2/E3）= 约 22800 次完整 trajectory；外加多 agent 合成管线本身的迭代执行；按 Gemini-3-Flash 单价估算完整复现成本在数千美元量级，研究机构可承担但个人研究者较吃力。**三个隐藏门槛**：(a) 需要稳定访问 15 个前沿模型 API（部分需企业合约）；(b) Gemini-3-Flash-Preview 作为 LES 本身版本迭代会影响评测可比性；(c) rubric 验证器与 LES 同源存在自验证循环。综合而言，方法可复现、结论可信，但完整数值重现需要相当工程投入。
论文图表
对比同一 Claude Opus 4.6 agent 在 Gemini Flash（PASS）和 GPT-5.2（FAIL）下处理急诊分诊任务的轨迹。GPT-5.2 simulator 凭空捏造了 ROOM 03、ROOM 04 两个不存在的空房间，agent 用了错房间导致失败。
展示 LES 三种失败模式之一——state fabrication，是论证"simulator 决定评测有效性"的具体证据。
对比同一 Opus 4.6 agent 在两 simulator 下处理工单升级任务。GPT-5.2 simulator 在 agent roster 查询中漏掉了 "Raj NYC"（数据库专家），使 agent 无法找到满足"数据库专员"约束的候选。
展示第二种失败模式——entity omission，证明 simulator 的实体保留能力直接影响任务可解性。
对比同一 Opus 4.6 agent 在两 simulator 下处理危险品退货。GPT-5.2 simulator 自行计算"30 天退货窗口已过期"并拒绝授权，但任务规格里根本没有这条规则。
展示第三种失败模式——rule invention，证明 simulator 可能引入环境契约外的额外约束，破坏任务可控性。
对比 Opus 4.6（PASS）与 DeepSeek V3.2（FAIL）处理医疗包裹配送任务的 6 步轨迹。两者都识别出最高编号包裹 MED-615 与 Walton Street 节点，但 DeepSeek 在电量 28% 时直接 move to node 导致跌到 12.5%（违反 ≥15% 约束），Opus 先 recharge 再 move 到达后剩 82%。
展示"主动约束监测"这一智能体差异化能力——同一任务、同一目标，差别在行动前是否检查前提条件。
对比 Opus 4.6（PASS）与 Qwen 3.5 Plus（FAIL）处理水产养殖池水质控制任务的 7 步轨迹。两者都达到温度与溶解氧目标，但 Qwen 跳过最后对底层水化学（ammonia）的复检，Opus 完成了这一步安全关键验证。
展示"skipped verification"失败模式——agent 做出正确主张但未收集支撑观察，体现 LLM judge 对动作-观察对账的薄弱。
对比 Opus 4.6（PASS）与 DeepSeek V3.2（FAIL）处理医疗气体系统 NFPA 99 认证任务的 11/12 步轨迹。DeepSeek 在许可证过期时仍直接执行钎焊，且未调用 manage gas(restore) 重启氧气阀；Opus 按 renew permits → containment → braze → test → restore gas → certify 的正确顺序执行。
展示"missing sub-goal"失败模式——子目标遗漏与顺序错误都会让合规流程功亏一篑。
对比 Opus 4.6（PASS，12 步）与 Kimi K2.5（FAIL，2 步）在显式故障下处理公交车调度恢复任务。Kimi 在第二次工具调用遇到 HTTP 500 即停步，仅完成 RTPI 抑制而未解决 hold 与车辆重派；Opus 遇到 4 次错误（Timeout、ConnectionRefused）都通过重试恢复并完成全部动作。
证明 E1 显式故障放大了"坚韧 vs 脆弱"agent 之间的差距——故障次数虽少，但放弃成本极高。
对比 Opus 4.6（PASS，4 步）与 Kimi K2.5（FAIL，4 步）在隐式故障下评估 Oakwood Manor 公寓物业财务稳定性。E2 把 15 个单元记录截断为 2 个，无错误信号。Opus 注意到 2/15 不一致并重试取回完整数据，正确算出 DSCR 1.19x（不通过 covenant）；Kimi 重试仍遇故障，遂假定所有 15 单元遵循抽样的高租金模型，得出 DSCR 1.72x（错误地判通过）。
完美演示"为什么 E2 比 E1 更致命"——没有错误信号时，agent 的隐式假设会直接导致灾难性财务误判。