论文理解【LLM-OR】——【OptiCycle/OptiState】Harnessing Language Models as Optimization Modeling Agents

• 本文初稿使用 PaperReading-skill 生成。给定论文标题、链接、arXiv/OpenReview 页面、DOI 或本地 PDF，让 Codex 自动完成论文检索、PDF 下载、图表抽取、代码仓库分析，并生成一份适合 Typora 阅读和后续整理的中文论文解读 Markdown 和 PDF，欢迎试用！
• 前往我的博客阅读本文，无需 CSDN VIP

• 文章链接：Harnessing Language Models as Optimization Modeling Agents
• 作者：Yunxiang Luo、Xin Xu、Tianhao Chen（共同一作），Zhixi Xiong、Peiqi Jiang、Fan Zhang、Wei Shao、Xuejian Gao、Yuwei Fan、Can Yang（通讯作者）。
• 机构：香港科技大学（HKUST）、华为。
• 代码：截至 2026-11-01，未找到
• 项目页：截至 2026-11-01，未找到
• OpenReview：截至 2026-11-01，未找到
• 发表：arXiv 预印本，2026-10-22 发布 v1；
• 领域：LLM-OR
• 一句话总结：本文使用 agentic 的执行—反馈—修正循环解决 LLM-OR 问题，以轻量的单智能体交互替代传统方法繁重的多阶段提示与多角色编排，无需额外训练即可提升建模与求解表现

• 摘要：大语言模型（LLM）可以将自然语言优化问题转换为求解器程序，但可靠地产生正确的数学模型及其实现仍然具有挑战。现有方法通过智能体工作流或任务专用的后训练来改善优化建模。这引出了一个实际问题：使用单一模型角色的轻量推理框架，能否在不进行额外训练的情况下取得有竞争力的表现？我们提出 OptiCycle 和 OptiState，两个面向优化建模的轻量推理框架，并使用参数规模覆盖 0.6B—27B 的 11 个 Qwen 变体，在包含 2,634 道问题的九个基准上进行评估。结果表明，执行引导的修订相较直接生成，在所有被评估模型上都持续提升了宏平均准确率，最高提升 49.46 个百分点。尽管设计简单，两种框架在使用相同模型的比较中均超过了六种经过适配的智能体工作流，并且在不进行额外训练的情况下，超过了四个规模相近、经过后训练的优化模型。显式建模状态能够带来进一步但依赖模型的改善，这表明额外结构并非普遍有益。

1. 背景与动机

1.1 研究背景

• 本文研究优化问题的自动建模与编程。具体而言，输入是一段自然语言描述的问题及其数值数据，如配送运输、订单分配、生产规划等，要求模型或系统完成运筹学建模，识别决策变量、目标函数与约束，并生成可调用求解器的代码，最终得到最优目标值或不可行、无界状态。这一过程需要同时保证数学模型忠实于题意，以及代码正确实现数学模型。
• 针对该任务，当前主要存在基于提示和基于微调的两类方法：
  1. 基于提示的建模（prompt-based modeling）：固定基础模型，通过专用提示、任务分解、角色分工和工具反馈组织求解过程。相关方法包括 OptiMUS、Chain-of-Experts、ORMind、AutoFormulation 等。其中，多阶段或多角色方法的重点在于将“复杂问题描述 → 数学模型 → 求解代码”的生成过程拆成多个子过程，再为建模、编程、检查和调度等环节分别设计提示或搜索规则，以降低单个环节的难度。

     这类方法不改模型参数，容易通过修改提示与流程进行迭代。随着阶段、角色和调度规则增加，系统也需要维护更多中间结果与上下文；因此，一个值得追问的问题是：获得较强建模能力，究竟需要多复杂的编排？

  2. 基于微调的建模（fine-tuned LLM modeling）：通过优化建模数据与任务反馈更新模型参数，形成领域专用模型。例如 ORLM 利用领域数据训练模型，LLMOPT、SIRL 等进一步探索后训练。这类方法的重点在于构造高质量的建模监督或求解器相关反馈，使变量识别、约束表达与程序生成能力进入模型参数。

     领域训练能够增强模型的优化知识，但需要额外的数据、训练与验证成本。同时，训练后模型如何使用工具、能否观察执行结果并继续修改，仍取决于推理时的运行方式；参数能力与外部工作流是两个可以共同优化的维度。

• 现有方法已经使用了智能体、执行反馈和自我修正等思想。本文进一步关注的是：能否减少繁重的多阶段提示与多角色编排，让一个冻结模型通过轻量的 agentic 交互循环，就获得有竞争力的优化建模与求解表现？

1.2 动机

• 作者注意到：同一个 LLM，既可以被当作一次性代码生成器，也可以被放进允许持续操作和修订的执行环境中。前者必须在一次输出中完成建模与编程；后者能够先写代码、观察运行结果，再决定下一步修改什么。模型参数相同，但发挥已有能力的机会不同。

• 论文用inference harness概括模型外部的这层运行框架：它负责组织工具、上下文、状态和控制流程。按照本文的问题意识，可以将相关路线整理如下：

  路线	典型做法	本文希望检验的问题
  一次性提示生成	用专用建模指令或示例，让模型一次输出完整程序	缺少执行后修订的机会，会损失多少能力？
  多阶段 / 多角色编排	为建模、编码、检查和协调设置不同角色或阶段	简单的单角色执行循环，能否达到甚至超过这些工作流？
  领域后训练	通过 SFT 或求解器相关反馈增强模型参数	不增加训练，仅改善推理环境，能否取得有竞争力的表现？
  显式中间表示	单独写出集合、参数、变量、目标和约束	将数学模型保存为可修改状态，是否总能帮助后续编码与纠错？

• 将这个想法落实到 LLM-OR，需要考虑三方面问题：

  1. 执行结果能否真正影响后续决策：一次生成再执行，只能发现程序失败，无法让模型针对错误继续操作。本文希望把代码生成、求解器执行、观察与修订连成循环，让同一模型根据输出或异常决定下一步，而不必为每种情况预设一个专用角色。
  2. 多轮求解能否保留已有工作：修改索引或约束时，模型需要延续之前创建的变量、数据和求解器对象，同时知道已经尝试过什么。本文将持久 Python 执行状态与提供给模型的近期历史摘要结合，使后续操作能够基于当前进度继续进行。
  3. 代码之外是否还需要显式建模状态：代码记录已经实现的操作，但变量含义、索引关系和约束选择分散在实现细节中。单独保留一份可修改的数学模型，可能帮助模型重审这些决策；不过，它也增加调用与上下文开销，是否值得需要实验判断。

• 因此，本文使用相同 Base Model，比较一次性生成程序（Direct Generation）、单一角色 Agentic Loop（OptiCycle ）、附加可编辑建模状态的 Agentic loop（OptiState ）三种推理方式，观察执行交互与显式状态分别带来什么变化。核心动机是让 LLM 在执行与反馈中逐步完成优化建模，以轻量的 agentic loop 减少对繁重提示编排的依赖。

  AlphaOPT、OptSkills 等传统工作更关注如何将过去任务的经验组织为可复用知识；本文首先关注一道题内部如何持续执行、保留状态并修正当前方案。跨题经验积累被作者放在未来自演化 harness 的展望中

• 另外，作者指出不同系统往往使用不同 backbone、基准和评分规则，因此需要共享模型与评估协议进行比较；本文保留各工作流自身的调用预算，具体效果与成本将在实验中一起分析

2. 本文方法

2.1 统一 inference harness 框架

• 作者为 LLM-OR 设计了统一 inference harness，这是一个用于控制固定权重 LLM 执行环境、交互历史和持久状态的框架，包含以下三个部分：
  • LLM：生成求解代码
  • 环境：执行代码，得到最优目标值、infesible 标志或 unbounded 标志
  • 控制器：决定下一次 LLM 调用可获取的反馈和状态，以及何时停止
• 在此基础上，Direct Generation 是一种单步设置，opticycle 引入了基于执行反馈的修订机制，optistate 进一步提供了一个可修订的表述形式。所有设置都是 Single Agent
  1. Direct Generation生成完整程序并执行一次，执行行为不会再影响下一次模型决策
  2. OptiCycle将程序生成、执行、观察和修订连成循环，并保留 Python 状态
  3. OptiState在循环外增加可读写的五要素建模（源自LLMOPT），帮助模型保留并重审建模选择

2.2 OptiCycle：在持久解释器里执行与修订

• OptiCycle 将优化建模组织为代码生成、执行、观测和修正的连续过程。这里文章没有写很清楚，我理解它是类似为每个求解问题维护一个类似 Jupyter 的 python 解释器内核，这样求解过程中导入的库、变量、数据结构和求解器对象可以跨轮存在，遇到错误时模型可以基于已有工作继续修改，不必从空白环境重新生成完整程序
• OptiCycle 迭代形式化表示为
  a t ∼ M θ ( ⋅ ∣ q , C ( H t ) ) , ( s t + 1 , o t ) = E ( c t , s t ) , H t + 1 = H t ∥ ( a t , o t ) . \begin{aligned} a_t &\sim M_\theta\bigl(\cdot\mid q,\mathcal C(H_t)\bigr),\\ (s_{t+1},o_t)&=\mathcal E(c_t,s_t),\\ H_{t+1}&=H_t\mathbin{\Vert}(a_t,o_t). \end{aligned}at​(st+1​,ot​)Ht+1​​∼Mθ​(⋅∣q,C(Ht​)),=E(ct​,st​),=Ht​∥(at​,ot​).​其中q qq是原始问题，M θ M_\thetaMθ​是冻结模型，a aa是目的和动作，E \mathcal EE是执行环境，c cc是求解代码，s ss是执行环境状态，o oo是输出或异常，H HH是执行历史，∥ \Vert∥表示追加历史，C ( H ) C(H)C(H)是执行历史的有限摘
• 第t tt轮迭代时，流程可以理解为：
  1. 准备输入：将原始问题q qq与当前历史摘要C ( H t ) \mathcal C(H_t)C(Ht​)组合，配合建模指令与恢复提示输入 LLM
  2. 生成动作：LLM 生成a t a_tat​，包含本轮的目的说明与代码c t c_tct​，例如建立约束、调用求解器或修复上一轮的索引错误
  3. 执行代码：环境E \mathcal EE在当前状态s t s_tst​下执行c t c_tct​，得到新状态s t + 1 s_{t+1}st+1​，并返回输出、求解状态或异常等反馈o t o_tot​

     文章没有详细说明，但可推测状态s ss包含解释器状态和工作区文件

  4. 记录历史：将动作与反馈追加到历史，得到H t + 1 = H t ∥ ( a t , o t ) H_{t+1}=H_t\mathbin{\Vert}(a_t,o_t)Ht+1​=H<