OR-License：当 AI 智能体走进真实的运筹咨询项目，能拿到"执业资格"吗？

你有没有想过一个问题：现在各种 Agent 榜单刷得飞起，但如果真把一个价值几十万美元的运筹优化咨询项目扔给 LLM 智能体——不是那种题干写好的数学题，而是客户甩给你一堆业务文档、数据文件，需求还说不全——它能交付一份客户愿意签字的方案吗？

这周看到的 OR-License（arXiv: 2610.24087）就是冲着这个问题去的。说实话，这是今年我读过的 benchmark 论文里，"下手最狠"的一篇：作者直接拿 31 个真实付费的工业运筹项目（总合同额 368 万美元）出题，让 11 个前沿模型以 coding agent 的方式完整跑一遍从需求沟通到求解器实现的全流程，最后用"客户当年实际验收过的专家方案"做参照打分。

结果挺扎心的：好几个模型在"能跑通"的任务上，目标值甚至超过了人类专家；但一旦把"不可行就零分"这条职场铁律加上，没有一个模型够到专家基准线。最强的配置也只拿到专家水平的 87%。

核心摘要：现有 OR benchmark 大多给的是自包含的数学题，跳过了"从客户原始材料翻译成可执行优化方案"这个最难的环节。OR-License 用 10 个行业、31 个真实付费咨询实例补上这一环，配了一个只泄露业务事实、不泄露专业知识的客户模拟器 ORSim，并用 Deployment-Adjusted Quality（DAQ，不可行交付直接记零）衡量"能不能上岗"。11 个前沿模型中，可行性从 45.16% 到 88.39% 不等，差距高达 43 个点；而条件目标质量只相差 4 个点——真正的瓶颈不是解得好不好，而是能不能交付一个可行的方案。这篇论文的价值不在某个新模型或新算法，而在于它第一次把"LLM 能否做专业 OR 工作"这件事，放进了接近真实商业交付的评估框架里。值得细读。

📖 论文信息

• 标题：OR-License: Evaluating LLM Agents as Real-World Operations Research Practitioners
• 作者：Peisong Wang, Feixue Liu, Yize Meng, Bowen Liu, Ruoyu Chen, Gaoyang Dai, Xing He, Aiqian Li, Fengchi Yuan, Aochuan Chen, Chenyi Zi, Yuhan Li, Hongchuan Zeng, Yimo Yan, Nuo Chen, Jie Fu, Zuo-Jun Max Shen, Yong-Hong Kuo, Jia Li
• 机构：HKUST-GZ、HKU、Qingzhi Optimization、Hunyuan, Tencent、XM Capital、Tianjin Meta & Infinite Technology、CZBANK、American University of Sharjah、Independent Researcher
• 日期：2026 年 10 月 16 日
• 链接：https://arxiv.org/abs/2610.24087

🎯 为什么现有 OR benchmark 测不出"上岗能力"

先交代下背景。运筹学（OR）是个典型的"高门槛高价值"行业——Gurobi 2024 年的行业报告里提到，82% 的从业者持有硕士或博士学位。一个真实的 OR 咨询项目长什么样？客户给你一个模糊的业务背景、几份格式各异的数据文件，然后你要自己问清楚缺失的信息、把业务语言翻译成数学模型、选算法、写代码、交付一个能跑且客户认可的东西。

现有的 LLM+OR 评测，比如 OptiMUS、NL4Opt 一脉的 benchmark，基本都是"题干给全、建模求解"的模式。OR-Space 和 ORAgentBench 往前走了一步，开始测多文件环境和多阶段工作流，但作者认为仍有三个结构性缺口没被填上：

图 1：每一列把一个评估缺口（上）对应到 OR-License 的改进（下）。缺口一是任务复杂度——学术/合成/重构任务和真实客户需求之间有落差；缺口二是信息获取——现有评测把完整任务上下文直接喂给模型，跳过了"谁来挖出缺失事实"这一步；缺口三是参照系——benchmark 自造的参考答案缺乏"被真实客户验收过的交付物"这个锚点。下方三列分别是 OR-License 的对策：真实付费项目脱敏后直接用、ORSim 全程可问、客户验收过的专家方案做参照。

我对 Gap 2 的感触最深。之前做业务建模项目的时候，真正花时间的从来不是写 Gurobi 代码，而是反复跟业务方确认"这个约束到底硬不硬"、"那个字段的定义是不是我想的那样"。GDPval 那篇也承认过这个局限——评测直接给了完整上下文，等于把专业工作里最难的一块切掉了。OR-License 把这块加回来了。

🏗️ Benchmark 设计：三件事都踩在点子上

图 2：左边是数据集构建流水线——收集真实付费项目、脱敏、整理任务资产（brief + 输入文件 + 隐藏评估资产）、专家交叉复核；中间是 ORSim 的三段式架构（Select → Authorize → Render）和智能体交互；右边是隐藏评估与实例级报告体系，Feas → Q_feas → DAQ → DAQ_α 层层递进。

数据：368 万美元真金白银的项目

31 个实例，覆盖 10 个工业场景（按 NAICS 三位数行业代码分类），全部来自委托制、竞标得来的真实付费 OR 项目，总合同额 368 万美元，平均每个项目周期 4.7 个月、投入 2.16 位专家。脱敏由至少三年从业经验的专家完成，保留原始需求、数据格式、交付格式和信息边界——注意，没有把需求重写成干净的数学形式，业务里的歧义和术语原样保留。

这一点很关键。很多 benchmark 的"真实感"是把真实问题洗成干净题目，OR-License 反着来：脏就脏着，那才是工作的本来面目。

参照系同样"真"：专家参考解不是为评测补做的，而是当年在项目里被客户实际验收通过的交付物。也就是说，DAQ=1 这条线的含义是"客户当年愿意为它付钱的水准"，不是某个理论最优。

问题规模也不是玩具级的：从几百个整数变量的小模型，到 Task 19 那种 560 万整数变量 + 560 万连续变量的大家伙都有。

ORSim：只给业务事实、不给专业答案的客户

真实项目里需求一开始就是不完整的，客户得在建模、求解、修正的全过程里被反复追问。ORSim 就是模拟这个角色。它的设计有个我很欣赏的细节：证据选择和回复生成是分离的——一个 selector LLM 从封闭的事实目录里挑出相关条目，一个确定性控制器校验所有权和可见性规则（每次查询最多披露 3 条非 brief 事实，要专业建议或数据解读会直接被拒），最后由一个 response-only LLM 把授权文本润色成自然语言。目录本身对被测智能体不可见。

为什么要这么麻烦？因为如果让一个 LLM 自由扮演客户，它大概率会"好心办坏事"——把建模思路、甚至答案暗示出去。这个三段式结构把"披露什么"的决定权锁死在程序里，LLM 只负责匹配和措辞。信息边界是程序保证的，不是靠 prompt 祈祷的。

指标：不可行就是零分

指标体系是分层设计的，逻辑非常"职场"：

严格可行性（Strict Feasibility）：一个实例的所有官方测试用例都必须通过隐藏的程序化 verifier，才算 \(F_i = 1\)。一个用例挂了就全挂。

专家相对质量（Expert-Relative Quality）：只对可行的实例算，\(Q_i = 1\) 表示打平专家目标值，大于 1 表示更好（最小化问题取倒数，最大化问题取正比，另有保序变换 \(T_i\) 处理目标尺度）。

部署调整质量（DAQ）是主指标，把不可行的交付直接记零：

其中 \(Z_i = Q_i\) 当且仅当实例可行，否则为 0。专家基准的 DAQ = 1。

这个设计的逻辑很朴素：客户不会为一份跑不通的方案付 90% 的钱。此外还有一个 \(\mathrm{DAQ}_\alpha\) 幂均值族（\(\alpha\) 从 1.0 到 3.0，步长 0.1 共 21 档），\(\alpha\) 越大对低分实例的惩罚越狠，用来检验排名在"越来越不能容忍短板"的评估口径下是否稳定。

轨迹分析：不只看你交付了什么，还看你怎么研究的

这是论文另一个我很喜欢的部分。作者人工标注了每条保留轨迹的三个维度：

• 信息获取时机：每次提问被归到六个工作流阶段 S1–S6（从写求解器代码前，一直到最终提交前）；
• 科研式探究链路（HCAEU）：对每个"可研究的不确定点"，看智能体是否走完了 假设（H) → 机理猜想（C) → 诊断实验（A) → 证据解读（E) → 基于证据的修正（U) 这条完整链路；
• 错误分类：八类错误源头，从问题理解（UND）、数据映射（DATA）、静态约束（CON）、动态状态转移（DYN）、目标与偏好建模（OBJ），到实现交付（IMP）等。

这种标注的颗粒度在 Agent benchmark 里很少见，代价是人力，收益是后面 RQ2/RQ3 那些真正有信息量的发现。

🧪 实验：11 个前沿模型集体"考执业资格"

实验设置：11 个前沿模型（Claude Opus 5、GPT-5.6 Sol、Gemini 3.8 Flash、Grok 4.6、DeepSeek-V4.1-Flash、Doubao-Seed-2.1-Pro、GLM-5.3-Flash、Qwen3.8-Max、Hy3、Hy4 preview、Muse Spark 1.3），主 harness 是 Claude Code 2.1.278，通过 Bash 命令 ask 访问 ORSim。每对模型–任务跑 5 次，指标先在任务内平均再对 31 个任务等权平均。执行上限 500 轮交互、12 小时墙钟、单次求解器调用 3600 秒。

主表：可行性才是分水岭

表 1：Claude Code harness 下的主结果（%，± 为任务内样本标准差的均值）

看到这张表我愣了一下。两组数字讲的故事完全相反：

条件质量几乎拉不开差距——所有模型在各自能跑通的可行子集上，质量都在 96.92% 到 101.01% 之间，跨度只有 4.09 个点，好几个还超过了专家参照。单看这一列，你会以为 LLM 已经能打平甚至超越人类 OR 专家了。

但可行性跨度高达 43.23 个点——从 Hy3 的 45.16% 到 Grok 4.6 的 88.39%。DAQ 一乘，全员掉到专家基准线以下。最强的 Grok 4.6 是 86.55%，差 13.45 个点。作者做了个分解：这 13.45 个点里，11.61 个点来自不可行交付的零分，只有 1.84 个点来自可行实例上的净目标值差距。也就是说约 86% 的失分不是因为"解得不够好"，而是因为"没交出一个能用的方案"。

这就是关键。

还有个细节容易被忽略：Quality 那列超过 100% 要冷静解读。它是各模型各自的可行子集上的条件平均，不同模型的分母不一样——一个只在简单任务上可行的模型，它的"质量"天然偏高。作者自己也明确说了这不构成跨实例的可比优化能力。别被"超过专家"的标题党解读带跑。

可靠性–质量剖面（\(\alpha\) 从 1.0 扫到 3.0）显示 11 个模型的排名在全部 21 档下完全不变，只是分数随惩罚加重整体下移。排名稳，但没人缩小与专家的差距。

Harness 消融：换个"壳"，分数能差 30 个点

附录里的 Codex 消融（同一模型端点、同任务、同预算）是我觉得最值得工程团队警觉的一张表：

GPT-5.6 Sol 换到 Codex 上 DAQ 涨了 8.6 个点，GLM-5.3-Flash 直接腰斩还多。说实话，这个方差幅度说明"模型能力"和"模型×harness 适配"在这类长程任务里是纠缠在一起的——以后看 Agent benchmark 排名，不看 harness 信息基本没法下结论。

科研链路：会做研究，但坚持不下来

HCAEU 链路的完成率全员低于 50%：最低的 Muse Spark 1.3 只有 24%，最高的 Grok 4.6 也只有 45%。断点位置各有特色——GPT-5.6 Sol 在 41% 的可研究机会里连可检验假设都没形成；Qwen3.8-Max 则有 21% 停在 HCAE，也就是"证据解读完了，但没有基于证据去修正方案"。

更微妙的是链路质量和 DAQ 排名对不上：GPT-5.6 Sol 的 DAQ 排第二（85.02%）但条件阶段质量偏低；Qwen3.8-Max 条件阶段质量最高，链路完成率却只有 27%，DAQ 77.97%。我的理解是：现在的智能体偶尔能展现出很漂亮的循证推理，但缺少把"不确定性 → 证据 → 修正"这套流程稳定地跑到底的可靠性。交付能力和持续研究能力是两个独立维度，得分开测。

RQ2：提问集中在开局，但后期提问"命中率"更高

信息获取的时机分析揭示了一个有点矛盾的现象。提问高度前置——S1 阶段（写求解器代码之前）占了 86.7% 到 98.3% 的提问。哪怕是后期交互最多的 Hy4 Preview 和 GPT-5.6 Sol，S1 之后的提问也只有约 13%。

但确认问题解决的"命中率"反过来了：S1 的确认解决比例只有 10.6%–37.0%，而后期阶段高得多——DeepSeek-V4.1-Flash 在 S4（已有初步候选解）约 56%，Hy4 Preview 在 S5（候选解完整但未过自检）达到 71%。

想想看这其实很符合直觉：开局提问大多是"收集需求"式的泛泛确认，后期提问是带着具体 bug 或异常结果来的，一问一个准。智能体明明全程都能问客户，却把信息获取当成了一次性的开工仪式，没有在求解过程中根据反馈持续回访业务假设。这是当前 Agent 的一个系统性短板。

RQ3：错不在代码，在"建错了模"

错误分类可能是全文对工程最有指导意义的一块。IMP（实现与交付）只在 11 个模型中的 2 个身上是最大错误类别——GPT-5.6 Sol 的 33.3% 和 Hy3 的 33.1%。其余模型的错误大头都在 formulation 侧：

• Claude Opus 5：静态约束错误（CON）占 42.7%
• Hy4 Preview / GLM-5.3-Flash：动态与状态转移错误（DYN）分别占 28.7% 和 25.5%
• Grok 4.6 / Muse Spark 1.3：目标与偏好建模（OBJ）+ 不确定性与信息结构（UNC）合计占 69.0% 和 70.5%

这个发现值得单独成段强调：代码可以忠实地实现一个错误的建模。把"解一个给定的优化问题"和"从业务需求出发建对问题"混为一谈，是当前评测和优化方向的常见误区。提升代码执行能力救不了建模层面的偏差——约束理解错了、状态转移画错了、目标函数抄岔了，求解器跑得再欢也是白搭。

附录彩蛋：智能体的"打法风格"

附录 E 对最终采用解法做了三维标注（求解技术 T、目标处理 O、结构利用 S），两张热力图信息量很大：

图：各模型在七类求解技术（T1 通用求解器 / T2 专用结构算法 / T3 贪心规则 / T4 局部搜索 / T5 元启发式 / T6 显式枚举 / T7 分支搜索）上的采用比例。所有模型都重度依赖 T1（67.7%–87.1%），而专家行除了 93.5% 的 T1 之外，T2 占 19.4%、T7 占 16.1%——专家更常掏出专用结构算法和受控分支搜索，模型几乎从不主动用 T7（全员 0%）。

图：(a) 目标处理：O1 直接优化业务目标 vs O2 自造代理目标。Hy3 有 48.4% 的任务用了代理目标（最高），这大概是它 DAQ 垫底的部分原因；有趣的是专家的 O2 也有 38.7%——说明合理设计代理目标本身是专家技能，问题出在模型的代理目标设计得不靠谱。(b) 结构利用：专家在 S2 问题分解（41.9%）和 S4 搜索约简（45.2%）上远超所有模型。

专家与模型的风格差异一目了然：模型是"一把梭调求解器"，专家是"先拆结构再选刀"。

💡 我的判断

这篇论文最值钱的地方，不是又造了一个榜单，而是把评估的参照系从"题目对不对"换成了"客户当年收不收"。DAQ 这个指标设计（不可行记零 + 专家验收方案归一）简单但非常贴近商业现实，我预计后面做专业 Agent 评测的工作会大量借用这个思路。

几个让我保留意见的点。一是规模：31 个实例对应 11 个模型 × 5 次运行，任务内标准差动辄 ±15–25 个点（看 GLM-5.3-Flash 的 ±25.68），这个噪声水平下相邻名次的差距解读要小心，作者用 ± 标注的是任务内变异而非 benchmark 均值的标准误，这点他们写得挺诚实。二是 ORSim 本身是个 LLM 系统，尽管有确定性控制器兜底，selector 的匹配质量仍然会影响"客户"的真实度——附录 C 做了可靠性测试，但模拟客户和真人客户之间的 gap 始终存在。三是 harness 敏感性：GLM 那个 63% → 34% 的腰斩提醒我们，这个榜单测的其实是"模型 × harness"的联合能力。

对工程的启发很直接：

1. 如果你在做专业领域的 Agent 产品，可行性门禁应该先于质量优化。86% 的失分来自不可行交付，先把"每个用例都过 verifier"做扎实，收益远大于在可行子集上抠目标值。
2. 把"提问"做成贯穿全流程的机制，而不是开工前的一次性需求表。后期提问的确认解决率（56%–71%）远高于开局（10.6%–37%），说明"带着具体中间结果回去问客户"是高价值动作，值得在 harness 或 prompt 层面显式激励。
3. 错误预算要向 formulation 倾斜。多数模型的主要错误在约束理解、状态转移、目标建模，而不是代码实现。评测和自改进回路都应该覆盖"建对模"这个环节，而不只是"跑通代码"。

最后说句实话：看到"好几个模型在可行子集上质量超过专家"时，我的第一反应是 LLM 要抢 OR 顾问饭碗了；看完 DAQ 分解又冷静下来——能解好题和能交付项目，中间隔着一整套需求确认、边界处理、鲁棒实现的功夫。这 13 个点的差距，可能就是未来两年专业 Agent 最值得攻关的方向。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我