🤖 AI

OR-Space: A Full-Lifecycle Workspace Benchmark for Industrial Optimization Agents

本文介绍了OR-Space，这是一个全生命周期工作空间基准，旨在评估工业优化代理在持久性多工件环境中处理涉及模型构建、修订和基于事实解释的真实多阶段任务的能力，从而超越传统的一次性问题 formulated 评估。

原作者： Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

发布于 2026-05-28

📖 1 分钟阅读☕ 轻松阅读

原作者： Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在招聘一位才华横溢的新助理来协助运营一家工厂。你希望确认他们是否真的能胜任工作，而不仅仅是空谈理论。

长期以来，我们测试这些 AI 助理（称为"LLM 智能体”）的方式，就像给它们一张完美撰写的食谱卡片。卡片上写着：“这是问题，这是食材，这是数学公式。现在，编写代码来解决它。”

如果 AI 正确写出了代码，我们就给它一颗金星。但在现实世界中，工厂经理们拿到的并不是完美的食谱卡片。他们面对的是杂乱的办公桌：上面贴着便利贴、堆着电子表格、放着去年的旧代码，还有老板发来的邮件，上面写着：“哦，顺便提一下，下个月的规则需要更改。”

OR-Space 是一项全新且更具挑战性的测试，旨在考察 AI 能否应对那种杂乱无章的真实办公环境。

测试 AI 的三种方式

该论文介绍了一个名为 OR-Space（运筹学空间）的基准测试。它不是提出单个问题，而是为 AI 提供一个完整的“工作空间”（一个包含文件的数字文件夹），并要求其完成在真实工厂中发生的三种不同类型的任务：

构建（架构师）：
- 场景： 你给 AI 一个文件夹，里面有一份商业备忘录、一份数字电子表格和一个空的代码文件。
- 任务： AI 必须阅读备忘录，理解数字的含义，并从头开始编写一个全新的计算机程序来解决工厂的问题。
- 难点： 备忘录可能含糊不清，电子表格的列可能杂乱无章。AI 必须在没有完美指南的情况下，将文本与数据之间的线索串联起来。
修订（修复者）：
- 场景： 工厂刚刚改变了主意。也许他们现在有了更多的卡车，或者有了新的安全规定。AI 被提供了旧程序和新规则。
- 任务： AI 必须更新旧代码以适应新规则，同时不破坏原本正常的部分。
- 难点： 这就像在有人居住的情况下翻修房屋。如果 AI 复制了旧代码中不再适用的变量名，整个系统就会崩溃。论文发现，一些 AI 会被旧代码搞糊涂，试图复制其中的错误；而更聪明的 AI 则知道该保留什么、该丢弃什么。
解释（翻译者）：
- 场景： 计算机已经解决了问题，但工厂经理（并非数学专家）问道：“你为什么决定派 5 辆卡车去北仓库，而不是南仓库？”
- 任务： AI 必须查看解决方案、代码和数据日志，给出真实的回答。
- 难点： AI 不能凭空编造故事。它必须指出电子表格中的具体行或代码中的具体规则，正是这些因素迫使它做出了该决定。如果它只是猜测，就会扣分。

为什么这项测试与众不同（“工作空间”与“提示词”）

作者认为，之前的测试就像抽认卡。你向 AI 展示一个干净、孤立的问题，然后它给出答案。

OR-Space 则像真实的办公室。

文件是分离的： 需求在 Word 文档中，数字在 CSV 文件中，代码在 Python 文件中。AI 必须打开所有文件，阅读它们，并理解它们如何相互关联。
“落地”问题： 在抽认卡测试中，AI 可能会因为识别出某些词汇而猜对答案。但在 OR-Space 中，如果 AI 未能正确地将备忘录中的单词“容量”与电子表格中的列“最大负载”联系起来，它就会失败。论文将这种现象称为“落地”——将词汇与实际数据绑定。

他们的发现（结果）

研究人员在 20 种不同的 AI 模型（目前可用的“最聪明”的模型）上测试了这一新基准。以下是发生的情况：

难度超出预期： 即使是最好的 AI 也感到吃力。虽然有些模型能解决“抽认卡”版本的问题，但当它们需要在杂乱的文件夹中导航时，往往就会失败。
旧代码是一把双刃剑： 当 AI 获得旧代码以帮助其修订模型时，最聪明的 AI 表现更好，因为它们将旧代码用作有用的提示。但较弱的 AI 表现更差，因为它们盲目地复制了旧代码中的错误（例如试图使用一个已不存在的变量）。
“解释”差距： 一些 AI 擅长编写代码，却不擅长解释。它们能解决数学问题，却无法根据手中的文件告诉你为什么做出那个选择。
“文件系统”惩罚： 论文发现，当 AI 必须实际导航文件夹并读取文件（即“文件系统”模式）时，其表现不如将相同信息直接粘贴到一个巨大的文本块中时好。这证明查找和组织信息本身就是一种技能，而不仅仅是格式问题。

核心结论

该论文得出结论，我们不能仅仅根据 AI 在完美提示词下编写代码的能力来测试它。为了在物流、制造或金融等真实行业中发挥作用，AI 需要接受以下能力的测试：

在一堆杂乱的文档中找到正确的信息。
在更新旧系统时不破坏其功能。
利用实际文件中的证据来解释其决策，而不仅仅是编造故事。

OR-Space 是这些 AI 智能体的新“驾驶考试”，将它们从停车场（完美提示词）推向繁忙的城市街道（真实工作空间）。

技术摘要：OR-Space

问题陈述

现有针对运筹学（OR）中大语言模型（LLM）智能体的基准测试，在很大程度上抽象掉了现实世界工业工作流的复杂性。当前的评估通常将 OR 任务简化为“单次”问题，即智能体将自包含的文本提示转化为数学公式或求解器代码。这种方法未能捕捉到工业 OR 的两个决定性特征：

工作空间设置：现实世界的智能体在持久化、多工件的环境中运行，该环境包含业务需求、结构化数据（CSV/JSON）、代码工件、求解器反馈以及分散在多个文件中的利益相关者交互。
生命周期设置：工业 OR 是迭代的。工程师不仅仅生成一次解决方案；他们构建初始模型，根据不断变化的业务规则或求解器反馈修订模型，并向非专家利益相关者解释由此产生的决策。

因此，当前的基准测试无法确定智能体是否能够在多工件工作空间中并贯穿建模生命周期的多个阶段执行可靠的优化工作。

方法论

作者引入了OR-Space，这是一个全生命周期工作空间基准测试，旨在评估工业优化智能体。该方法围绕两个核心轴构建：持久化可执行工作空间和面向生命周期的任务管道。

1. OR 工作空间形式化

OR 工作空间（ $W$ ）被定义为一个结构化、持久化、可执行的环境：
$W = \langle D, P, S, E, M \rangle$

$D$ （文档）：描述目标和需求的自然语言工件（例如 business_requirement.md）。
$P$ （参数）：包含数值输入的结构化数据文件（CSV、JSON），通常需要进行清洗和模式对齐。
$S$ （代码）：代码工件，包括启发式脚本、部分模板或遗留实现。
$E$ （环境）：基于 Docker 的沙箱，支持文件 I/O、求解器执行（Gurobi、COPT、PuLP、HiGHS）以及资源约束。
$M$ （指标）：基准测试框架使用的评估指标（对智能体隐藏）。

与将全部上下文序列化为单个提示的先前基准测试不同，OR-Space 要求智能体在这些分布式工件之间定位、连接并确立信息。

2. 面向生命周期的任务模式

OR-Space 定义了三种源自 100 个基础问题（从 IndustryOR 基准测试扩展而来）的序列任务模式：

构建（ $T_{Build}$ ）：智能体利用业务文档和数据文件，从零开始构建求解器就绪的优化模型，起始于空的代码脚手架。
修订（ $T_{Revise}$ ）：智能体在更新的需求下修改现有的优化工作流。这包括 Revise-code（修改遗留代码）、Revise-model（仅修改公式）和 Revise-all 等变体。智能体必须在整合新约束或变量的同时，保留有效的先前逻辑。
解释（ $T_{Explain}$ ）：智能体利用分布在文档、数据、代码和求解器输出（例如对偶变量、松弛值）中的证据，回答关于解决方案、约束和业务影响的具体问题。

3. 评估协议

构建与修订：通过求解器评分指标进行评估。如果提交内容无错误执行、返回“最优”状态，并且相对于真实值 oracle 的相对目标误差 $\le 1\%$ ，则判定为正确。
解释：使用基于具体依据的“LLM 作为裁判”评分标准进行评估。评分基于精确覆盖（35%）、推理（35%）、具体依据（20%）、回答质量（10%）以及幻觉惩罚（最高 -12）。
失败分析：该框架记录特定的失败模式，包括执行错误、不可行公式、错误的目标函数以及不忠实的解释。

主要贡献

局限性识别：本文指出，现有的 OR 基准测试存在自包含工作空间设置和单次任务设置的缺陷，未能充分代表现实工业工作流的多工件和面向生命周期的本质。
OR-Space 基准测试：这是一个围绕持久化可执行工作空间构建的新基准测试，其中需求、数据、代码和求解器输出分布在多个文件中。
任务模式：定义了三种面向生命周期的模式（构建、修订、解释），涵盖了模型构建、维护和沟通。
评估框架：一个用于分析智能体在工作空间接地任务中的能力和失败模式的协议，包括数据接地、修订一致性和解释忠实度。

结果

作者在基准测试中评估了 20 个模型（闭源前沿模型、小型 API 模型和开源模型）。主要发现包括：

工作空间接地具有难度：即使是前沿智能体也难以进行工作空间接地的模型构建。最佳构建得分为 72.0%（gemini-3.1-pro），大多数前沿模型在 53–68% 之间。这突显了从分布式工件中恢复数据模式和业务语义，比从清洁提示中恢复要困难得多。
遗留代码作为信号与噪声：在 Revise 任务中，强模型（例如 gpt-5.4、claude-opus-4-6）通常通过利用遗留代码作为信号来提升性能（例如 gpt-5.4 从 59% 提升至 79%）。相反，较弱或“闪电”模型往往出现性能下降（例如 gemini-3-flash 下降了 23 个百分点），这表明它们将实现细节视为噪声或复制了非求解器导入。
可解释性是独特的：Explain 的性能与 Build 和 Revise 得分的相关性较弱（ $r \approx 0.16-0.28$ ）。一些能够构建可运行模型的模型未能忠实地解释它们（例如 gemini-2.5-pro 解决了 69% 的修订实例，但在解释任务中仅得 32.2 分）。
接口影响：使用文件系统接口（相对于扁平提示序列化）通常会降低代码生成任务（构建和修订）的性能，平均分别降低了 8.2 和 12.2 个百分点。这表明文件发现和模式检查是实质性的困难，而非表面问题。
上下文敏感性：将形式化公式添加到代码上下文中通常有助于强模型，但可能会损害轻量级模型。发现仅包含公式的上下文比基于代码的上下文更脆弱。

意义与主张

本文将 OR-Space 定位为评估范式的必要转变，即从孤立的文本生成转向稳健的、基于求解器的工程工作流。作者声称：

可靠性差距：导航开放的多工件工作空间对当前的 LLM 智能体来说仍然极具挑战性，暴露了数据映射和约束接地方面的系统性失败，而这些在纯文本基准测试中很大程度上被掩盖了。
实际就绪度：OR-Space 通过模拟工业 OR 的迭代、多步骤性质，为衡量优化智能体的实际就绪度提供了严格的基础。
失败模式：该基准测试能够实现对失败的细粒度归因，区分数学建模错误、数据接地错误和幻觉约束，这对于在现实世界环境中部署智能体至关重要。

该研究得出结论，虽然 LLM 在孤立的公式化任务中显示出潜力，但它们目前在持久化工作空间和完整生命周期中执行可靠 OR 工程的能力仍然有限，因此需要进一步研究智能体的可靠性、失败模式以及工作空间交互。