OR-License 基准：智能体能解题，交不出可落地的运筹学方案

速览

OR-License 是一套把运筹学交付从头到尾搬进评测的基准：31 个实例取自 10 类工业场景的真实付费项目，这些原始承接项目的总额为 368 万美元。11 个前沿模型在 coding-agent harness 里跑完之后，有 5 个模型在可行实例上的目标质量已经超过专家参考，但没有任何一个在部署调整质量上追平专家。主对照下最强的配置是 Grok 4.6，严格可行性 88.39%，部署调整质量 0.87，专家参考是 1 OR-License。

这个结果值得知道，因为它把一句常被含糊处理的话变成了可测的数字：智能体能解出一道写好的优化题，跟它能独立完成一次真实交付，中间隔着一整段工作。基准拆开来看，差距的大头也不在数学难度上，而在交付能不能落地。

基准从写好的题面开始，真实交付却从一堆残缺的客户材料开始

既有评测几乎都从交付链条的中段起步，被跳过的是「先搞清客户到底要什么、再把它变成专业方案」这一整段工作。一次真实的运筹学交付是一条完整的链：拿到客户残缺的原始材料，追问清楚业务事实，建立模型，写成求解器能执行的程序，验证，最后交出一份能被业务方接受的方案。

论文把这个情况写成三条 gap，措辞是它自己的：Gap 1: Task Complexity and Practical Relevance，学术、合成或重建的任务捕捉不到真实客户项目的运营复杂度；Gap 2: Information Acquisition，评测方把上下文一次性给全，等于把「建立这个上下文」的工作本身从评测里删掉了；Gap 3: Limited Grounding in Professional Delivery，参照答案来自评测内部构造，从来没有和真实交付挂上钩。对应图把这三条和改进措施逐列对齐，这是理解这篇论文最省事的入口。

图注：上半部是既有评测的三处缺口，下半部逐列给出 OR-License 的对应做法，包括 10 scenarios · 31 instances、ORSim 在优化全程可问，以及以客户已验收的专家方案为参照。图中客户对话为示意 OR-License

被批评的「自包含题面」并不抽象，NL4Opt 竞赛就是它的标准形态：一段线性规划应用题，输入文档本身已经把决策变量、目标和约束写全，任务是把这段话翻译成实体标注和求解器可用的标准形式，全程不需要向任何人提问 NL4Opt。

图注：上方是子任务 2 的流程与评测协议，从 Inputs 与实体集合经 Generate formulation 得到意义表示，再转换为规范化形式后 Evaluate 并打分；下方是同一实例的语义标注、代数式与评测用矩阵形式三种等价表示。图中没有客户，也没有提问环节 NL4Opt

「题目太整洁」是有量化形态的缺陷，不只是修辞。把真实 MIPLIB 实例逆向还原成自然语言规格、构造出工业规模的 MIPLIB-NL 之后，那些在既有基准上表现强劲的系统平均 Pass@1 从 78.78% 到 91.78% 的高位跌到 17.85% MIPLIB-NL。退化衡量的是基准难度落差而非能力排名，但它足以说明被跳过的那段工作不是零成本。

保留题目的残缺，才测得出智能体会不会主动去问

要让信息获取能被评测，题目就不能被弄整洁。OR-License 做法的关键不在于让智能体「能对话」，而在于把信息边界做成可编程的东西。原始需求、输入数据与交付格式经过脱敏，但保留了对智能体呈现的信息边界，只删掉名称一类识别性信息。初始 brief 保留业务需求，不重写成完整的数学形式，也排除那些必须通过客户交互才能获得的事实。删掉边界就等于把题目变整洁，信息获取这一整段工作随即从评测里消失。

客户一侧由 ORSim 承担，它只披露业务事实，不提供运筹学判断。具体协议是目前官方演示里的两轮问答：智能体问能否在搅拌机上连续生产两种产品，ORSim 回答任何方向的产品切换都需要 15 分钟清洗，清洗占用搅拌机且必须在下一批投料前完成；智能体接着问该用 MILP 还是 CP-SAT、变量和约束该怎么写，回答是「I can clarify the operating requirements, but I cannot recommend a solver, choose variables, or formulate constraints for you.」建模、选算法、写求解器，从头到尾都是智能体的责任 OR-License。

这条边界能成立，靠的是架构上的三段分离，而不是一句角色扮演提示。模拟器侧的 LLM 只做 selector，从专家审阅过的事实目录里挑出事实编号；随后由一个确定性控制器校验并执行所有权与可见性策略，同时施加每次查询最多披露 3 条非 brief 事实的上限；最后交给一个只负责改写的 response-only LLM 渲染成自然语言。哪条事实可以被披露、一次能披露几条、什么算运筹学专业判断，全由确定性部件决定，LLM 只负责语义匹配和措辞 OR-License。

图注：左侧 Dataset construction 依次是收集真实项目、去标识化、整理任务资产与专家交叉复核，并标注 10 scenarios · 31 instances；中部 ORSim 内部为 Select、Authorize、Render 三段，与 LLM agent 之间是 Ask 与 Authorized reply 的循环；右侧 Hidden evaluation 的判定是全部测试用例是否通过，不通过取 Z_s=0、通过取 Z_s=Q_s OR-License

这条路线上并不只有它在走。ORAgentBench 的设计原则明文要求解题所需信息全部写在提供的材料里，等于把信息获取整段排除在评测之外；交互式评测的对照实验则显示，同一个智能体在一次性问答下是 0.70 分、16.7% 成功率，换成对话式后升到 0.93 和 65.1% ORAgentBench OptiConvo。这条技术线更早的原型是 τ-bench 的「模拟用户 + 领域策略 + pass^k」，另一种设计是把客户做成微调出来的数字孪生，后者在自己的库存场景里还给出反向证据：把完美真值交给智能体并没有带来统计上的改善 τ-bench AskClarify。

基准规模的几个数字需要连口径一起读。31 个实例、10 类工业场景，对应的是 368 万美元的原始承接项目总额，论文没有说明这个数是否含税或是否四舍五入；每个原始项目平均持续 4.7 个月、平均投入 2.16 名专家。这是题目从哪来的背景，不是被测系统的成绩。

不可行的交付直接记零，这一条决定了后面所有数字怎么读

DAQ 不是平均目标值差距，而是一个乘性门控：先判这份交付能不能落地，再比落地的那些做得有多好。理解它的结构，后面所有看似矛盾的分数就都能读通。

第一层判定是严格可行性。一个实例只有在它的每一个官方测试用例都通过隐藏校验器时才算可行，只通过部分用例视同不可行，因为它要求同一份求解器实现能在这个实例的运营约束下自始至终成立。第二层是专家相对质量，把智能体与专家的目标值经实例内固定的单调变换归一化之后作比，追平专家记 1，超过就大于 1。第三层才是合成：每个可行的实例记入它的 Q_i，不可行的实例记 0，然后除以实例总数，也就是

$$\text{DAQ} = \frac{1}{N}\sum Z_i = \text{Feas} \times Q_{\text{feas}}$$

把三步走一遍就清楚了。假设有三个实例，A 和 C 的全部用例都过、专家相对质量分别是 1.10 和 0.95，B 只过了一部分用例：

（三个数是为说明口径编的，不是论文里的实例。）此时 Feas = 2/3，也就是 66.7%；条件目标质量在可行子集上是 (1.10+0.95)/2 = 1.025，已经超过专家；而 DAQ 是 (1.10+0+0.95)/3 ≈ 0.683。同一个系统既「比专家解得好」，又「离专家还很远」，原因只在分母不同：条件目标质量的分母是可行实例数，随系统变化；DAQ 的分母固定是实例总数。

讲解：DAQ 为什么要乘一道可行性门

这解释了论文里最容易被误读的一组结果：5 个模型的条件目标质量超过 100%，但没有一个模型的 DAQ 追平专家。条件目标质量只落在可行子集上，分母随系统变化，所以论文自己写明它只是一个诊断指标，跨模型比较必须用固定分母的 DAQ。同类基准也有硬门控加归一化质量的做法，但落到二值通过率是另一种形态，分数不可换算 ORAgentBench。另外要留意 DAQ 不覆盖的维度：「正确但慢」的交付在真实部署里同样是失败，而有实验显示多数返回正确目标值的程序求解时间长于专家参考 CostlyModels。

目标值能追平甚至超过专家，部署级质量却一个都没追上

把口径摆好之后，主结果可以一句话说完：这代模型差的不是解出来的数好不好，而是「每一次都能交出一个能落地的方案」的稳定性。实验设置是 11 个前沿模型，主对照用 Claude Code 作为执行外壳，每个模型与任务的组合跑 5 次，31 个任务等权平均，专家参考在三个指标上都是 100%。

（表中只列出部分模型，完整 11 行见论文 Table 1。）

两个跨度的对比是这张表最值得看的地方。可行性从 45.16% 到 88.39%，跨了 43.23 个百分点，说明模型之间的差距主要在「能不能交出去」；条件目标质量只差 4.09 点，从 96.92% 到 101.01%，而且在可行实例上超过专家的模型有 5 个。差距分解把这件事说得更直白：最强的 Grok 4.6 与专家相差 13.45 点，其中 11.61 点来自不可行的交付被记零，只有 1.84 点来自可行实例上净的目标值差距。约八成六的失分来自交付失败，而不是解算得不够好 OR-License。

这个水位还是执行外壳相关的快照。同一批模型换到 Codex 外壳后，GPT-5.6 Sol 的 DAQ 从 85.02% 升到 93.59%，DeepSeek-V4.1-Flash 从 69.28% 升到 78.27%，GLM-5.3-Flash 却从 63.21% 掉到 34.42%。换一层运行装置，同一批模型的分数可以涨十几点，也可以掉近三十点，说明 harness 本身属于被评测系统的一部分。同月已有方法侧工作在直接攻击这个失效模式：VERAS 诊断出程序与它自写的检查会共享同一批需求遗漏，并给出一套带独立验证角色的 harness VERAS。

图注：上排是 Task description 与 Data 经 Problem formulation、Program generation、Program execution 到 Decision artifact 的主线；下排三条机制带是 Task-grounded verification，内含 Structural review、Deterministic observer 与 Isolated challenger，以及 Evidence-guided refinement 与 Verification-filtered update。图中没有客户澄清环节 VERAS

它们把向客户提问当成开工前的一次性准备，研究链条只走完两三成

长程智能体的短板不在写代码，而在缺少一个随方案演进而持续追问、并用证据修订方案的闭环。ORSim 全程可问，但模型几乎只在开工前提问：按六个工作流阶段切分，写求解器代码之前那一段占了各模型提问的 86.7% 到 98.3%，而这一段的确认解决比例只有 10.6% 到 37.0%。提问数量和提问效果在这里是两个不同的量，同时成立并不矛盾：问题问得早、问得多，但问到点子上并真正解决掉的比例很低。

更能说明问题的是后半程。后半段的提问虽然少，确认解决比例反而更高，有的模型在完整候选解之前那一段约 56%，另一个模型在自检之前约 71%。论文据此认为，客户澄清同样能支撑方案构建开始之后的具体问题诊断与修正，而当前智能体普遍把信息获取当成一次性的需求收集 OR-License。

图注：左面板 11 个模型各一行，横轴为提问份额，按 S1 到 S6 六个阶段分段堆叠，段宽表示提问份额、段高表示确认解决比例；右面板条长为不可行率，条内按 UND、DATA、DEC、CON、DYN、UNC、OBJ、IMP 八类错误事件着色。左面板横轴在 0% 与 80% 之间被截断 OR-License

研究链条的数据同样偏低。论文把研究过程拆成五个环节：提出可检验假设、给出机制解释、执行诊断实验、解读证据、据此更新方案。任务等权之后，走完整条链的比例在 24% 到 45% 之间，没有一个模型超过 50%；有的模型在 41% 的研究机会里根本没有提出可检验假设。模型常常停在把证据解释一遍，没有走到因为这份证据而改掉模型、算法、参数或代码。

失败画像需要先纠正一个常见误读：论文给的是八类事件级标签，不是「建模失败」与「实现失败」的互斥二分。八类是 UND 问题理解、DATA 数据与参数映射、DEC 决策表示、CON 静态约束、DYN 动态与状态转移、UNC 不确定性与信息结构、OBJ 目标与偏好建模、IMP 实现与交付；一个轨迹可以同时包含多类事件，类别画像只用于指出哪里需要修正，不构成各模型失败概率的加法归因。按这个口径，唯一的实现侧类别 IMP 只在 11 个模型中的 2 个里是最大类；有的模型静态约束占 42.7%，有的模型动态与状态转移占 28.7%。外部对照还有两套轴：Opti-Agent-Bench 按阶段给出约束遗漏、模型与代码不一致、报告与实现不一致三类失效，ORAgentBench 按轨迹最先断在哪一环分四类，两套轴不能合并成一张表 Opti-Agent-Bench。

引用这份结论时需要带上边界。模拟客户不是真实用户的可靠替身：只更换模拟用户的底座模型，成功率就能晃动近 9 个百分点，而且在最难的任务档上系统性低估、在中等难度档上高估，不过这条证据来自零售客服任务，不能直接反推到运筹学任务 LostInSim。轨迹分析所在的子集规模论文没有公开，24% 到 45% 的区间因此没有置信区间；31 个实例的宏平均里每个实例权重 1/31，方差不可忽略；论文也把专家参考只当作归一化锚点，因为模型可以在部分实例上超过专家。截至 2026 年 10 月 20 日，这仍是一份 arXiv v1 预印本，没有会议或期刊接收记录，所有数字都是预印本口径。

各基准之间只比「补上了哪一段」，任何分数都不横向比较，这是读这类基准时最实用的纪律。另有一条路线把「真实」定义在工作区上：OR-Space 要求智能体在持久工作区里跨文件定位信息、维护跨工件一致性，并对已经执行过的模型给出有据可依的解释 OR-Space。

一句话记住这篇论文：它把评测的起点从写好的题面挪到客户的原始材料，挪动之后才看清，这一代智能体的瓶颈不在求解，而在交付，而且信息获取本该贯穿整个方案周期，不只是开工前的一次准备。想深入可以读原文：OR-License: Evaluating LLM Agents as Real-World Operations Research Practitioners — arXiv:2610.24087。

参考文献

• OR-License: Evaluating LLM Agents as Real-World Operations Research Practitioners — https://arxiv.org/abs/2610.24087
• ORAgentBench: Can LLM Agents Solve Challenging Operations Research Tasks End to End? — https://arxiv.org/abs/2606.19787
• Opti-Agent-Bench: Benchmarking End-to-End Optimization R&D Agents on Real-World Business Problems — https://arxiv.org/abs/2607.10768
• OR-Space: A Full-Lifecycle Workspace Benchmark for Industrial Optimization Agents — https://arxiv.org/abs/2605.28158
• VERAS: Verification-Guided Adaptive Search for Reliable Operations Research — https://arxiv.org/abs/2610.24329
• Let's Have a Conversation: Designing and Evaluating LLM Agents for Interactive Optimization — https://arxiv.org/abs/2604.02666
• Ask, Clarify, Optimize: Human-LLM Agent Collaboration for Smarter Inventory Control — https://arxiv.org/abs/2601.00121
• Lost in Simulation: LLM-Simulated Users are Unreliable Proxies for Human Users in Agentic Evaluations — https://arxiv.org/abs/2601.17087
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — https://arxiv.org/abs/2406.12045
• Constructing Industrial-Scale Optimization Modeling Benchmark（MIPLIB-NL）— https://arxiv.org/abs/2602.10450
• Right Answers, Costly Models: The Efficiency Gap in LLM-based Optimization Modeling — https://arxiv.org/abs/2609.38884
• NL4Opt Competition: Formulating Optimization Problems Based on Their Natural Language Descriptions — https://arxiv.org/abs/2303.08233