OptimAI 用多智能体 LLM 流水线把自然语言优化问题转成求解器代码，在 NLP4LP 上达 88.1%、Optibench 上达 82.3%，错误率较此前最佳分别下降 58% 和 52%

OptimAI 把自然语言优化问题求解拆成四个由专门角色承担的阶段：formulator 负责把文字描述转成含决策变量、目标函数、约束与问题类型的数学建模；planner 在写代码前给出多个候选求解策略并选择求解器；coder 生成可执行的 Python 求解器代码；code critic 结合报错进行反思式调试。 与此前 OptiMUS、Optibench 等方法相比，该框架在功能上同时具备自然语言输入、编码前规划、多求解器支持、方案间切换与不同 LLM 协作（论文表 1 的对比），而此前方法各自只覆盖其中一部分。 论文以四阶段流水线描述与附录 A 的形式化状态更新给出方法细节，并在附录 B 列出各角色的完整提示词，方法可复现性由提示词与算法 1 支撑。

论文把“下一步调试哪个方案”建模为多臂老虎机问题，用 UCB 分数在多个候选方案间动态切换，并引入 decider 角色对方案打分、verifier 角色校验最终输出是否满足约束。 此前方法不具备“在方案之间切换”的能力（论文表 1 中 OptiMUS、Optibench、CoE 在该项均为否），该工作把探索-利用权衡显式引入调试阶段。 消融实验（论文表 7）显示，在 Optibench 困难子集上启用 UCB 使 token 用量从 64,552 降至 18,072（约 3.6 倍），生产力从 0.70 升至 2.32（约 3.3 倍），而 Pass@1 准确率保持 69% 不变、可执行性从 3.4 略升至 3.5。

在零样本设置下，OptimAI 在多个数据集上超过此前最佳方法：使用 GPT-4o+o1-mini 在 NLP4LP 上达 88.1%，使用 DeepSeek-R1 在 Optibench 上整体达 82.3%，且超过 99% 的生成代码可无错执行。 论文报告相比此前最佳，NLP4LP 错误率下降 58%，Optibench 四个子集（Linear w/o Table、Linear w/ Table、Nonlinear w/o Table、Nonlinear w/ Table）错误率分别下降 48%、47%、68%、41%。 结果来自论文表 3，覆盖四种底层 LLM（GPT-4o、GPT-4o+o1-mini、QwQ、DeepSeek-R1）与两个基准；论文称 DeepSeek-R1 配置在 Optibench 上以 8.1 个标准差超过此前最佳。

框架支持把不同阶段分配给不同 LLM，实验观察到异构模型组合可产生协同增益：单独使用 Llama 3.3 70B 或 Gemma 2 27B 准确率分别为 59% 和 54%，而由 Gemma 2 27B 担任 planner、Llama 3.3 70B 承担其余角色时准确率升至 77%。 该结果把“多智能体协作”从同构集成推进到按角色分工的异构模型组合，并给出可量化的组合收益。 证据来自论文表 6 在 Optibench 上的 3×3 组合矩阵；同时论文表 8 的角色消融显示移除 planner 需多 4.6 倍修订、生产力下降 5.8 倍，移除 code critic 修订增加 3.6 倍、生产力下降 3.1 倍。

该框架面向以自然语言描述优化问题、希望自动得到可执行求解器代码与解的用户，适用于零样本设置下的线性、非线性、混合整数规划以及 TSP、JSP、集合覆盖等组合优化任务；论文称其当前性能与一名熟练程序员相当，并明确把“需要专家团队的大规模问题”列为尚未覆盖的范围。对实践者而言，可直接复用的是四阶段角色划分、附录 B 的提示词模板、算法 1 的 UCB 调试调度，以及“planner 与 code critic 不可省略”这一工程结论；论文还指出最优方案数 n 会随 decider 能力增强而增大，因此该超参数应随模型升级重新调优。

论文报告的可执行性指标基于人工评估（4 分为完全正确），不同评估者的尺度一致性在文中未展开；表 4 显示 OptimAI 的 token 用量（18,072）高于 Optibench（955），论文将其解释为换取更广的问题覆盖，因此成本与覆盖之间的取舍需按使用场景判断。论文指出 decider 目前“不是特别强”，首次即选中最终成功方案的概率约为 39.7%，并预期最优方案数会随 decider 变强而上升，这提示当前超参数结论与具体模型绑定。此外，论文把强化学习微调 decider、扩展到需要专家团队的大规模问题列为未来方向，这些方向的效果尚待验证。