Anchor：缓解智能体基准生成中的工件漂移

# Anchor：缓解智能体基准生成中的工件漂移

来源：https://arxiv.org/html/2605.26321  
\(2026\)

###### 摘要。

AI 智能体开始能够完成有价值的、长周期的企业运营任务，但企业工作的训练和评估环境仍然在平衡真实性、可验证性和规模方面存在困难。环境和任务的创建经常遭受一种我们称之为*工件漂移*的失败模式：当指令、环境、预言机和验证器由松散耦合的流程创建时，它们经常对任务的要求产生分歧，从而产生不可解、易遭奖励攻击或不一致的环境。我们提出了 Anchor，一个任务生成管道，它将领域专家对业务流程的规范形式化为约束优化程序。从一个参数化规范出发，该管道联合生成自然语言指令、环境配置、求解器认证的 ground-truth 解决方案以及基于状态的验证器。通过 Anchor，改变参数可以产生具有受控难度和已知最优解的新任务，从而产生与框架无关的环境，其奖励仅取决于最终状态的业务正确性。我们应用 Anchor 生成了 ERP-Bench：一个包含 300 个长周期任务的基准，这些任务涵盖了生产级 ERP 系统中的采购和制造工作流。我们发现生成参数可以预测实现的难度，并且前沿模型在 26.1% 的试验中满足显式任务约束，但仅在 17.4% 的试验中达到完全最优解。总体而言，我们表明 Anchor 和 ERP-Bench 为构建可审计的评估环境以评估具有经济价值的智能体工作提供了具体配方。我们发布任务生成器和 ERP-Bench 数据集，网址为 erpbench.ai (https://erpbench.ai/)。

智能体基准，可验证奖励，企业工作流，约束优化，ERP 系统

††copyright:none††journalyear:2026††conference:RLEval：评估 AI 智能体的方法与强化学习环境研讨会，ACM 人工智能与智能体系统会议 (ACM CAIS 2026)；2026 年 5 月 26 日；美国加利福尼亚州圣何塞††ccs:计算方法 人工智能††ccs:计算方法 规划与调度††ccs:软件及其工程 软件测试与调试

## 1. 引言

参见图注 图 1. 工件漂移。任务的四个工件——指令 II、环境 EE、预言机解 x∗x^{∗} 和验证器 VV——之间的不一致性各自以不同方式使预期任务 ττ 无效。展示四个任务工件以及它们不一致时产生的四种失败模式的图表。

参见图注 图 2. Anchor 单一来源任务创建管道。求解的约束可满足性问题规范为每个任务实例生成指令、环境设置、预言机解和终端状态验证器。Anchor 单一来源任务创建管道。

最近的调查记录了语言模型智能体在企业任务上的基准分数与生产性能之间存在显著差距 (Pan 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib21)；Mehta，2025 (https://arxiv.org/html/2605.26321#bib.bib16)；Yehudai 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib30))。审计将这一差距的大部分归因于基准本身的构建错误。无操作智能体在 38% 的 ττ-bench 航空任务中通过 (Yao 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib29))，因为验证器接受空响应 (Zhu 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib34))，而加强 SWE-bench 中的单元测试 (Jimenez 等人，2024 (https://arxiv.org/html/2605.26321#bib.bib13)) 会重新排名 40.9% 的 SWE-bench Lite 排行榜位置 (Aleithan 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib1)；Yu 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib31))。基准作者面临着真实性、可验证性和规模之间的内在张力。专家编写的基准提高了真实性，但需要昂贵的策展 (Xu 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib28))；合成生成器扩展了任务创建，但带来了噪声或单路径评分器 (Xie 等人，2026 (https://arxiv.org/html/2605.26321#bib.bib27)；Saxena 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib24))；并且 τ2τ^{2}-bench 的作者观察到，早期的基准将指令推向“精心设计的……以帮助确保单一、可解路径” (Barres 等人，2025 (https://arxiv.org/html/2605.26321#bib.bib4))。大多数基准仍然并行创作每个任务的四个工件（指令、环境、预言机解和验证器），并通过审计事后验证一致性。这产生了一种我们称之为*工件漂移*的四向一致性失败（图 1 (https://arxiv.org/html/2605.26321#S1.F1)）：松散耦合的过程最终描述了略有不同的任务，例如环境缺少指令假设的数据，预言机依赖于环境忽略的状态，或者验证器接受指令未要求的结果。

我们通过 Anchor 解决这个问题，这是一个任务生成管道，它从一个已求解的规范中编译所有四个工件。领域专家与工程师一起，将业务流程形式化为 OR-Tools CP-SAT (Perron 和 Didier，2025 (https://arxiv.org/html/2605.26321#bib.bib23)) 中的参数化约束程序，包含决策变量、业务规则约束和目标指标。对于提议的参数设置，CP-SAT 求解器要么拒绝参数（视为不可行），要么认证一个最优解，然后该最优解确定性地编译成任务工件。由于所有四个工件都是同一已求解规范的确定性投影，数据集通过构造缓解了工件漂移。定义任务的相同参数也调整其难度，因此该管道可以为智能体训练提供可验证的训练数据课程。我们应用 Anchor 生成了 ERP-Bench，包含 300 个采购和制造任务，涵盖生产级开源 ERP 系统 Odoo 19 中的 29 个工作流模式。我们在 18,000 次试验中，跨编码、浏览器和计算机使用框架评估了五个前沿模型。在每种框架中，pass@5 随难度等级（从简单到困难）单调下降，在编码框架中从 70.5% 降至 22.3%，在浏览器框架中从 46.5% 降至 7.7%，在计算机使用框架中从 56.0% 降至 9.5%，并且在评估期间零次出现奖励攻击实例。

我们的主要贡献是：

- •Anchor：一个任务创建管道，从一个已求解的约束程序规范中编译指令、环境、预言机和验证器。
- •ERP-Bench：一个包含 300 个任务的可验证基准，涵盖生产级 ERP 中的长周期采购和制造工作流，具有受控难度和认证的最优解。
- •评估：在 ERP-Bench 任务上，跨编码、浏览器和计算机使用框架，对前沿专有模型和开放权重模型进行受控比较。

## 2. Anchor

我们的任务创建管道借鉴了大型语言模型和数学推理方面的先前工作。AlphaProof 及相关系统将非正式的数学陈述视为管道的起点，该管道将其翻译成正式的 Lean 程序，其中确定性检查器对任何候选证明进行评分，并且形式化语句的合成变体成为强化学习的课程 (Hubert 等人，2026 (https://arxiv.org/html/2605.26321#bib.bib12)；AlphaProof 和 AlphaGeometry 团队，2024 (https://arxiv.org/html/2605.26321#bib.bib2))。我们类似地旨在将非正式的业务工作流转化为可检查的程序，并生成合成变体以解决数据稀缺性和保真度问题。与 AlphaProof 和其他自动形式化工作不同，我们手动进行形式化步骤，生成的变体被翻译回非正式场景，用于智能体训练和评估。

许多企业工作流在记录系统中的结构化数据上运行，遵循明确的业务规则，并优化可衡量的结果，这使得它们自然可以表示为约束可满足性和优化问题。Anchor 管道（图 2 (https://arxiv.org/html/2605.26321#S1.F2)）从领域专家和工程师将工作流（如发票优先级排序、交易资格认定或生产调度）形式化为参数化约束程序 (Perron 和 Didier，2025 (https://arxiv.org/html/2605.26321#bib.bib23)) 开始，包含决策变量、业务规则约束和目标函数。这个约束程序成为任务生成引擎的核心。

给定参数设置 θθ，求解器要么拒绝样本（视为不可行），要么认证一个最优解 xθ∗x^{∗}_{θ}。我们将得到的参数、约束、目标和认证解称为已求解规范 SθS_{θ}。然后四个翻译层将 SθS_{θ} 编译成图 2 (https://arxiv.org/html/2605.26321#S1.F2) 中所示的任务工件：一个*指令生成器*将参数、约束和目标渲染为自然语言；一个*设置生成器*将采样的初始记录写入环境容器；一个*预言机生成器*将求解器的解写入参考终端状态；一个*验证器生成器*根据程序的约束和目标对终端状态进行评分。由于这四个工件是 SθS_{θ} 的确定性投影，图 1 (https://arxiv.org/html/2605.26321#S1.F1) 中的不一致性通过构造得到缓解。由于求解器认证了最优目标值，验证在不将任务限制为单一操作路径的情况下仍然是可行的。

Anchor 并没有消除所有构建错误：约束程序可能编码不完整的业务逻辑，渲染器可能错误地翻译正确的规范。五个端到端检查可以发现残留缺陷（附录 I (https://arxiv.org/html/2605.26321#A9)）：无操作智能体应在每个任务上得零分，预言机重放应获得满分，LLM 评判者根据 CP-SAT 程序交叉检查工件，奖励攻击金丝雀标记那些在不触发验证器规则的情况下超过求解器目标的展开，以及领域专家手动抽查任务。

## 3. ERP-Bench

我们应用 Anchor 创建了 ERP-Bench：300 个长周期采购和制造任务，涵盖开源 ERP 系统 Odoo 19 (Odoo S.A.，2026 (https://arxiv.org/html/2605.26321#bib.bib20)) 中的 29 个模式。采购和制造后台工作具有重要的经济意义：2024 年制造业为美国 GDP 贡献了 2.91 万亿美元，涉及约 1260 万工人和 23.9 万家企业 (美国经济分析局，2025 (https://arxiv.org/html/2605.26321#bib.bib5)；美国全国制造商协会，2025 (https://arxiv.org/html/2605.26321#bib.bib18))，采购岗位预计在 2034 年前每年有 58,700 个职位空缺 (美国劳工统计局，2025 (https://arxiv.org/html/2605.26321#bib.bib6))。这些工作流中的错误直接影响支出、履行、产能、开票和可审计性，而不仅仅是表面上的任务完成。每个任务在其自己的容器中运行，针对一个填充了场景所需的客户、供应商、库存、物料清单和工作中心的新数据库。智能体与后台用户会接触的相同持久记录交互，包括销售订单、采购订单、制造订单、供应商价目表和发票，通过 JSON-2 API 或标准 Odoo Web 客户端。例如，一个任务可能要求智能体满足一周内到期的四个客户销售订单，而起始仓库库存不足以覆盖它们：它必须根据分层供应商价目表下达采购订单（遵循最小订单量和交货时间），安排将从采购组件组装成品的制造订单，将生成的记录链接回每个销售订单，同时最小化总支出，并向客户发送带有正确付款条款的发票。这 29 个工作流模式基于与 10 名自由 ERP 从业者约 40 人时的咨询和审查，然后管道将每个模式采样为许多任务实例，因为专家工作是根据任务模式而非每个实例来承担的。每个模式的名册见附录 B (https://arxiv.org/html/2605.26321#A2)，Harbor 任务规范见附录 C (https://arxiv.org/html/2605.26321#A3)，生成器细节见附录 D (https://arxiv.org/html/2605.26321#A4)。

验证器结合了三个维度，权重分别为 25/60/15%：*约束满足*对需求覆盖、截止日期、采购规则、制造可行性和开票执行离散检查；*最优性*将实现的目标与认证最优值进行比较，对于次优计划采用指数衰减；*可追溯性*对 PO、MO、发票与其服务的销售订单之间的审计关联性进行评分。约束维度控制其他维度，并且一小部分结构先决条件充当硬零点（附录 E (https://arxiv.org/html/2605.26321#A5)）。因此，ERP-Bench 任务既是可验证的又是开放式的：CP-SAT 求解器认证精确的最优目标值以及实现该目标的分配，而智能体可以通过许多操作序列达到许多有效的终端状态。

难度由参数组控制，这些参数组组合成简单、中等和困难配方。需求侧参数缩放客户数量、每个订单的规模以及每个订单到期的紧迫程度。供给侧参数减少现有库存，收紧供应商产能，以及减少供需之间的松弛。采购参数逐步解锁更多的 ERP 表面，分层引入单阶段和多阶段制造、工作中心产能以及智能体必须诊断和修复的破损初始状态。更高的难度还丰富了目标，从仅可行性或简单支出目标转向供应商整合、产能保护和计划修复。附录 B (https://arxiv.org/html/2605.26321#A2) 和 D (https://arxiv.org/html/2605.26321#A4) 总结了任务分类法和生成设计。

## 4. 评估

我们评估了五个前沿模型，跨越三个框架，每个智能体-任务对进行五次试验，共 18,000 次预定试验，所有试验共享一个验证器，运行在相同的容器化实例上。我们在最小的、开源的 pi-monagent 工具包 (Zechner，2026 (https://arxiv.org/html/2605.26321#bib.bib32)) 上构建框架，以便测试平台反映真实的智能体支架，而不是仅用于评估的基准特定包装器。编码框架使用 shell 和文件系统工具，通过 JSON-2 API 驱动 Odoo。浏览器框架扩展了 pi，使用 Playwright 工具，通过无障碍解析的操作驱动标准 Odoo Web 客户端。计算机使用框架通过像素坐标点击、按键和截图驱动基于 Xvfb 的 Chromium，没有 DOM 访问。我们评估了两个专有模型（GPT-5.5、Claude Opus 4.7）和三个开放权重模型（GLM-5.1、GLM-5V-Turbo、Kimi K2.5）。GLM-5.1 在计算机使用框架上被替换为 GLM-5V-Turbo，因为前者本身不支持视觉输入（附录 F (https://arxiv.org/html/2605.26321#A6) 提供了框架和模型的详细信息）。

参见图注 图 3. 按模型、框架和生成难度层级划分的 pass@5（95% Wilson 置信区间）。在评估的每个模型和框架中，生成难度层级与实现的性能相关。每个模型的 pass@5 条形图按 Easy、Medium、Hard 难度带排列的 2x2 网格，每个难度带有三个框架条形（编码、浏览器、计算机），附带 95% Wilson 置信区间。