COOPA：一种面向运筹学问题的模块化LLM智能体架构

# COOPA：一种面向运筹学问题的模块化LLM智能体架构  
来源：https://arxiv.org/html/2606.27611  

Chuanhao Li¹†, Xiaoan Xu²†, Dirk Bergemann³, Ethan X. Fang², Yehua Wei², Zhuoran Yang³  
¹清华大学 ²杜克大学 ³耶鲁大学  

###### 摘要  

运筹学（OR）为高风险决策提供了严谨的框架，但有效的OR建模需要深厚的领域知识、数学抽象能力和求解器专业知识。近年来基于LLM的系统实现了部分自动化，但在复杂问题上仍存在准确率低、输出不透明、求解器支持范围窄等局限。我们提出**COOPA**（协作运筹智能体），一种模块化LLM智能体架构，旨在提供可解释且可扩展的OR决策支持。它包含三个组件：**基于置信度的迭代建模**，生成多个候选公式化方案，从多个建模维度进行自评估，并通过最大最小置信度准则选择最优方案；**元素级溯源与置信度解释**，将变量、参数、约束和目标函数与引用的源文本关联，提供可供人工验证的审计线索；**多求解器路由**，根据OR问题类别将任务分派给专门的优化智能体。在三个OR基准、八个LLM主干模型以及四个对比基线（同等条件下）的实验中，COOPA在八个主干模型中的六个上取得了最佳宏观平均准确率，相比最强基线提升高达6.7个百分点。系统内消融实验分离了迭代建模的贡献，额外分析与案例研究则展示了源文本可追溯性与多求解器分派的价值。  

所有资源可在 https://github.com/xxxxxa-hub/COOPA 获取。  

## 1 引言  

运筹学（OR）为复杂系统中的决策提供了坚实的基础。在供应链、交通、能源、医疗、金融、工程和公共政策等领域，OR利用数学和计算模型来刻画资源约束、系统动态、不确定性以及性能目标。其工具包涵盖确定性优化、随机优化、鲁棒优化；动态规划；排队论；基于仿真的优化，并由精确算法、分解方法、近似算法、启发式算法和元启发式算法提供支持。这一广度使OR成为高风险决策支持的基础学科。  

然而，有效应用OR仍然高度依赖专业知识。构建一个有用的模型需要：明确变量、目标函数和约束；决定哪些内容需要显式建模或抽象化；表示不确定性、时间结构和系统交互；在决策相关性与计算可行性之间权衡；以及在专门的优化环境中实现模型。这一过程通常是迭代的，且需要与领域专家密切互动。即使经验丰富的从业者也可能花费数周或数月来优化公式、诊断计算行为并验证结果是否符合实际运行情况。因此，OR在许多组织中仍未被充分使用，尤其是在缺乏专业建模知识的地方。  

近年来大语言模型（LLM）的进展提供了降低这一门槛的可能性。LLM能够处理自然语言问题描述、生成结构化输出和代码、并在符号表示上进行推理，因此自然适用于公式化、面向求解器的代码生成以及结果解释等任务。相关研究领域通过针对优化任务定制的提示（prompting）、代码合成和微调策略进行了探索（Xiao et al., 2024；AhmadiTeshnizi et al., 2024；Huang et al., 2025；Shu et al., 2025）。然而，当前系统距离可靠的OR决策支持工具仍有很大差距。我们指出三个主要局限。  

第一，**在较难的OR问题上准确率仍然有限**，公式化错误是主要瓶颈。多项研究表明，不完整的公式化、错误的变量或约束、以及未正确指定的目标函数占失败原因的50%–70%，远超编码错误（Huang et al., 2025；Liu et al., 2026；AhmadiTeshnizi et al., 2024）。大多数方法仍采用一次性生成单个公式化的方式，在代码生成之前几乎没有改进机会（Xiao et al., 2024；Liu et al., 2026；Zhang and Luo, 2025；Huang et al., 2025）。即使进行修订，通常也是由下游执行失败触发，而非针对公式本身进行显式迭代（AhmadiTeshnizi et al., 2024；Shu et al., 2025）。因此，数学上错误但可执行的公式化可能未被发现而通过检查。  

第二，**现有系统输出不透明**。大多数基于LLM的OR系统向用户展示公式化、求解器代码和最优解值（AhmadiTeshnizi et al., 2024；Xiao et al., 2024；Zhang and Luo, 2025；Huang et al., 2025）；部分系统还会报告质量指标，如每个子句的置信度分数（AhmadiTeshnizi et al., 2024）。然而，这些输出都**不包含质量评估背后的理由**，例如为何某个元素获得特定分数、或该分数源自问题描述的哪一部分，也没有系统提供**元素级溯源**，将每个参数、变量、约束或目标项与激发它的具体文本关联起来。在实际涉及数百个约束的OR问题中，缺乏这种可追溯性迫使从业者重新阅读整个问题描述并在脑中重建LLM的推理过程以验证正确性或定位错误，这既费力又不可扩展。  

第三，**现有系统难以适应新的求解器后端**。对于依赖模型微调的方法，求解器依赖性直接：ORLM（Huang et al., 2025）、OR-R1（Ding et al., 2026）和SIRL（Chen et al., 2026）针对COPT，而LLMOPT（Shu et al., 2025）使用Pyomo。在这些方法中更换后端需要新的求解器数据、调整输出格式或额外微调。无需微调的系统虽然避免了求解器特定的重新训练，但求解器特定的假设仍可能嵌入在整个工作流中，包括公式化模板、代码生成提示、求解器API调用、执行与调试逻辑以及输出解析。例如，OptiMUS（AhmadiTeshnizi et al., 2024）、CoE（Xiao et al., 2024）、OptiTree（Liu et al., 2026）、OR-LLM-Agent（Zhang and Luo, 2025）和LEAN-LLM-OPT（Liang et al., 2026）都生成面向Gurobi的代码。OptimAI（Thind et al., 2025）通过支持多个数学规划后端（包括PuLP、Pyomo和OR-Tools）扩大了覆盖范围。不过，现有系统通常将后端支持视为固定的实现选择，而非可扩展的架构接口。  

基于这些局限，我们提出**COOPA**（协作运筹智能体），一种模块化LLM智能体架构，用于OR建模和求解器执行，围绕三个设计要求构建：在代码生成前提高公式化质量、以结构化且可追溯的形式表示建模工件、以及支持可扩展的求解器分派。COOPA通过三个组件实现这些要求。首先，**基于置信度的迭代建模**：生成多个候选公式化，从四个建模维度对每个进行评分并附带置信度解释，通过最大最小准则选择具有最高最小置信度的候选。其次，**可解释输出供人工验证**：通过验证后的模式提取建模元素，并将其与引用的源文本关联，构建从问题陈述到公式化的审计线索。第三，**可扩展的多求解器分派**：对问题类型进行分类，并将其路由到四个优化智能体之一（覆盖Pyomo、OR-Tools、pymoo和标准Python），新智能体可在不修改工作流其余部分的情况下添加。  

我们在三个基准和八个LLM主干模型上，针对四个智能体基线评估了COOPA。COOPA在八个主干模型中的六个上取得了最高宏观平均准确率。最强结果包括COOPA与GPT-5.2（70.6%）、GPT-5（69.4%）和Gemini-3-Flash（68.4%）的组合，表明该架构能放大了强主干模型的优势。此外，增益不仅限于顶尖模型：COOPA在GPT-5上比最强基线提升6.7个百分点，在GPT-4.1上提升6.3个百分点。系统内消融实验则分离了迭代建模的贡献。  

## 2 LLM驱动的OR系统的失败模式与设计要求  

我们在第5节详细讨论相关工作，这里重点阐述激发COOPA的失败模式。基于LLM的OR系统的关键瓶颈往往是“问题到模型”阶段：将自然语言翻译为变量、目标函数、约束和参数。这为COOPA提出了两个需求：在代码生成前提高公式化质量，以及以可追溯形式表示建模工件。第三个需求——可扩展的求解器分派——则源于OR问题类别和求解器后端的广泛多样性。  

### 2.1 公式化错误是核心瓶颈  

现有分析一致将公式化阶段的错误视为主要失败来源。ORLM的错误分类（Huang et al., 2025）指出“主要挑战在于优化建模阶段”，而代码生成的通过率约为95%。在采样到的建模错误中，56.3%来自模型完整性低，30.3%来自目标或约束翻译错误，13.4%来自对问题文本的语义误解。相似地，OptiMUS（AhmadiTeshnizi et al., 2024）报告称，在涉及多维变量的困难混合整数问题上，参数提取和建模比编码生成的模型更难。OptiTree（Liu et al., 2026）进一步观察到，许多中度和难度实例的失败源于不正确的变量定义。这些发现表明，仅改进代码生成是不够的。执行反馈可以捕获语法错误、运行时异常或格式错误的约束，但无法捕获可执行但在语义上与问题描述不一致的公式化。因此COOPA以公式化质量为靶点，利用迭代候选生成、基于置信度的评估和结构化提取。  

### 2.2 从失败模式到设计要求  

基于LLM的OR系统在如何构建公式化以及支持哪些求解器后端方面存在差异。这些工作流选择为COOPA指出了三个设计要求。  

**代码前公式化改进**。不同方法在获得传递给代码生成的公式化方式以及何时验证它方面存在差异。有些方法生成初始公式化后依赖下游反馈修复错误，使用有限的重试（Xiao et al., 2024；Zhang and Luo, 2025）或由执行或求解器反馈驱动的修正循环（AhmadiTeshnizi et al., 2024；Shu et al., 2025）。另一些方法通过分类法引导的分解（Liu et al., 2026）或在OR任务上微调（Huang et al., 2025；Chen et al., 2026；Ding et al., 2026）来提高公式化质量。这些方法有助益，但通常针对单一公式化轨迹进行修正，而非在代码生成前显式比较多个备选方案。此外，验证往往是下游或结果驱动的：一些系统采用评估-改进循环（AhmadiTeshnizi et al., 2024）、基于执行的自校正（Shu et al., 2025）或求解失败后的反向反思（Xiao et al., 2024），而另一些系统一旦生成的代码运行并返回答案就直接接受第一个结果（Zhang and Luo, 2025；Liu et al., 2026；Huang et al., 2025）。这留下了一个关键缺口：一个公式化可以是可执行的，但仍可能曲解原始问题的语义。因此COOPA在生成求解器代码之前评估公式化质量，生成多个候选并通过基于置信度的评估进行选择。  

**结构化和可追溯的建模工件**。系统在表示中间工件的方式上也存在差异。先前工作使用JSON（AhmadiTeshnizi et al., 2024）、从求解器日志中提取的正则表达式（Liu et al., 2026）、自由格式注释（Xiao et al., 2024）和Markdown输出（Zhang and Luo, 2025）。这一选择很重要，因为下游阶段必须从LLM输出中可靠地恢复变量、参数、约束和目标函数。因此僵化的格式假设或临时解析可能影响执行和测量准确率；例如我们发现OptiTree（Liu et al., 2026）使用的正则表达式提取在某些主干模型上相较于LLM提取显著降低了准确率。同时，现有系统对人工验证的支持有限：它们返回公式化、求解器代码和最终答案，但不提供将变量、参数、约束或目标项关联到问题文本的元素级溯源，也不提供单个建模选择的置信度信息。用户因此必须自行重构为何引入每个建模元素，随着公式化规模增大，这一过程成本高昂。COOPA通过模式验证的结构化输出和源文本可追溯性解决了这两个问题。