AI 原生系列 · 研究

让模型来写问题，让求解器来签答案。

作者：Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-08-04

让语言模型帮你规划这个季度，你会得到一份很漂亮的方案。再问一次，你会得到另一份同样漂亮、但完全不同的方案——如果你拿它去对照你真实的约束条件（这位工程师早就排满了、那个截止日期动不了、这笔预算已经封顶），它会不声不响地违反好几条。换成二元整数规划就不一样了：你会得到唯一一个答案，它可以证明满足你给出的每一条约束——但它永远不会告诉你，你给的约束对不对，也不会告诉你，你让它去最大化的那个东西，到底值不值得被最大化。

这不是两个互相竞争的工具，而是同一个大脑的两半。而真正有意思的工程问题——也是这篇文章要谈的——正是那道接缝.

研究到底解决了什么

过去两年，“LLM 到底能不能做规划”这个问题得到了一个异常清晰的答案——而这不是谁赢谁输，是分工。

第一半：LLM 当不了担保人。 Kambhampati 及其同事在 ICML 2024 立场论文中说得很直白："We argue that auto-regressive LLMs cannot, by themselves, do planning or self-verification (which is after all a form of reasoning)"（中译：我们认为，自回归大语言模型本身无法独立完成规划或自我验证——毕竟这也是一种推理形式） [1]。实证结果同样直白。在 Game of 24、图着色和经典规划任务上，Stechly 等人发现，让模型批判自己的答案反而让结果变得更差："We observe significant performance collapse with self-critique and significant performance gains with sound external verification"（中译：我们观察到自我批判会导致性能显著崩溃，而使用可靠的外部验证则会带来显著的性能提升） [2]。另一项配套研究得出结论："self-critiquing appears to diminish plan generation performance, especially when compared to systems with external, sound verifiers"（中译：自我批判似乎会降低规划生成的表现，尤其是与具备外部可靠验证器的系统相比） [3]。说白了：一个 LLM 去检查另一个 LLM，就是让谣言去核实谣言。

第二半：LLM 在写问题这件事上，好得惊人。 Stanford 的 OptiMUS 把自然语言描述转化为混合整数线性规划，"can develop mathematical models, write and debug solver code, evaluate the generated solutions, and improve its model and code based on these evaluations"（中译：能够构建数学模型、编写并调试求解器代码、评估生成的解，并基于这些评估改进自身的模型与代码） [4]——比此前的最优水平高出 20%-30%。Chain-of-Experts 在 ICLR 2024 上提出了"the first LLM-based solution, namely Chain-of-Experts (CoE), a novel multi-agent cooperative framework to enhance reasoning capabilities"（中译：首个基于 LLM 的解决方案，即 Chain-of-Experts（CoE），一种用于增强推理能力的新型多智能体协作框架），用于复杂的运筹学建模 [5]；到 2025 年，OR-LLM-Agent 已将整条流水线拆解为"three sequential stages: mathematical modeling, code generation, and debugging"（中译：三个连续阶段：数学建模、代码生成与调试），并在运筹学基准测试中超越了前沿通用模型 [6]。问题建模——把一团混乱的现实处境翻译成决策变量与约束条件，这件又琐碎又容易出错的活——正是人类最讨厌、模型却最擅长的部分。

而真正证明这场组合可行的典范是： AlphaGeometry 用一套系统达到了接近奥赛金牌的水平，这套系统"uses a neural language model, trained from scratch on our large-scale synthetic data, to guide a symbolic deduction engine through infinite branching points"（中译：使用一个在我们的大规模合成数据上从零训练的神经语言模型，来引导一个符号推理引擎穿越无穷分支点） [7]。在搜索会爆炸的分支点上，神经网络负责提议；符号系统负责确定性推导。最好的纯符号系统只解出十道题，而这套组合系统解出了二十五道。单独任何一半都望尘莫及。

还有一点，因为我的规划器正建立在它之上：滚动时域控制（receding-horizon control）——规划一个窗口、执行、观察现实、再从你实际所在的位置重新规划——并不是机器人学的专属把戏。它是一种通用的决策范式；近期有研究把整条竞争性供应链建模为多个智能体，其中"every agent re-plans their actions in a receding horizon manner based on estimates of market and supplier parameters"（中译：每个智能体都会基于对市场与供应商参数的估计，以滚动时域的方式重新规划自己的行动） [8]。

我工作台上的三套系统

我并不是从文献里走到这个问题面前的。而是手里已经攥着三件各自负责一部分的东西——它们相隔数年打造，彼此都不知道对方存在，却拼成了同一台机器。

求解器：Life GPS（2019 年，公开）。 完整的故事我在上一篇文章里讲过：一个把你的一周视为按小时切分的网格、并在其上求解一个二元整数线性规划的周计划工具——决策变量是x[slot,task] ∈ {0,1}，目标函数 = 加权满足度，约束条件为每个时段只能安排一项任务、每项任务有上下限、还有截止日期。重写后的 Python 引擎（allocator.py，PuLP + CBC）承担着最重要的那部分：replan() 把过去冻结，按你实际花费的量扣减每项预算，再对剩余的时域重新求解——这就是模型预测控制（Model Predictive Control），只不过应用在了人生上。我是在为这篇文章做研究时，才第一次真正体会到这个细节：这次重写里其实已经预留了两处 LLM 接缝。intake() 接受一段注入的llm_fn，把"上线我的 MVP、每天冥想、五天、八小时"这样的话，转化为一份经过验证的PlanRequest; explain() 把求解出的网格重新转述成句子。下面要讲的整合方案，并不是提议把 AI 硬焊到求解器上——插座早就装在墙里了。

策略层（私有）。 一套我一直闭源的策略操作系统：它按一条严谨的流水线运行——从诊断（Rumelt 式内核追问：到底发生了什么？）出发，经过真正彼此不同的方案集、压力情境与竞争对手的可能反应，最终抵达一个决策节点，而这个节点always signed by a human（中译：始终由人类签字确认） ——每一条论断都要有证据把关，执行过程用领先指标追踪，一旦某个假设被打破，绊线（tripwire）就会触发。用优化的语言来说，它产出的正是求解器自己产不出来的东西：目标函数（该看重什么，每个权重背后都有证据支撑）与约束集（哪些规则是硬约束，为什么是硬约束）。

它不是玩具的证据（私有）。 这套策略引擎的第一个真实项目，跑在一个按角色分权的团队协作平台上——一个正在进行的客户实战项目，其证据登记册、方案选项与 90 天计划全部来自同一条流水线。这里之所以重要，只有一个原因：真实项目里的权重与约束，背后挂的是具名的证据和人的签字，而不是模型的直觉。

架构：三层，两个时钟

把研究成果和这三件实物摆在一起看，设计几乎自己就浮现出来了。

第一层——策略层（慢时钟：以周为单位，或者任何绊线触发的时刻）。 语言模型负责推理，人类坐镇决策节点，两者共同产出问题陈述：有哪些项目在跑、每个项目值多少（一个权重，背后有证据支撑）、下限、上限、截止日期与依赖关系分别是什么。这其实是把 OptiMUS 的经验推而广之：模型的超能力在于「形式化建模」，它负责把问题写成一个线性规划。

第二层——求解器（快时钟：每天，或每次状态更新时）。 二元整数规划在约束集之下分配时间和金钱，MPC 循环则根据实际执行情况不断重新求解。这个求解器正是针对自我批判的研究反复呼吁的那种external sound verifier（中译：外部的、可靠的验证者）[2][3]：它不会被说服着放弃某条约束，也不会凭空幻想出一个根本不存在的小时数；当问题无解时，它会直接说无解，而不是编一个听起来靠谱的答案。

第三层——传感器。 遥测数据把两个循环都闭合起来：测试是否通过、指标是否在移动、工作项是否落地（在我的技术栈里，就是每个仓库本就会自动生成的、带证据评级的「成绩单」）。正是这些低成本的传感器，把这套东西从一个 2019 年的玩具变成了一套真正在运转的活系统——过去要靠人每天手动录入两次的反馈，现在自己就会归档。

这两个时钟，恰恰是大多数设计漏掉的部分。战术层面的重新规划（求解器的时钟）和战略层面的重新规划（策略层的时钟），是成本完全不同的两种操作。重新求解分配方案只需要几毫秒，每小时跑一次都毫无压力；但重写目标函数代价高昂，一旦变成对突发情况的应激反应就很危险——那样只会导致反复调整、来回抖动。所以这里的升级机制是明确写死的：求解器会一直在当前的问题陈述范围内反复重新求解，直到某个tripwire ——一个提前命名、预先登记的假设破坏点——被触发，把笔重新交还给策略层。这正是滚动时域（receding-horizon）模式的二次应用，作用于两个不同的时间尺度[8]。

接缝契约

以上一切成败都系于这道接缝，所以要把接缝写成一份契约：

• 权重只能带着证据和签名向下流动。 模型可以提议「A 项目的价值是 B 项目的 3 倍」；这个提议附带其证据；在求解器看到它之前，必须有人签字确认。没有签名的权重，不会进入目标函数。
• 模型负责构造问题，绝不负责验证。 把问题翻译成决策变量、约束条件、求解器代码：这是模型的工作[4][5][6]。检查可行性与最优性：这是求解器的工作，是结构性的——不是让模型自己再提示一遍去复核自己[1][2]。
• 模型只解释求解器给出的数字，绝不解释自己的猜测。 explain() 把求解出的网格转述成句子。这里的纪律是：它只负责讲述已经被求解出来的结果。如果叙述和网格对不上，以网格为准。
• 无法衡量的目标，不能进入目标函数。 如果一个目标还没有指标，它就应该被标注为「尚不可衡量——待定义指标」，而不是被编造出一个系数。一个谁也无法衡量的目标项，正是仪表盘学会讨好人的方式。

失败模式：把猜测洗白成权威

这里有一个没人提醒过你的危险，也是上面那份契约必须写得如此严苛的原因。求解器给出的结果感觉上自带权威——毕竟它是可证明最优的。但它可证明最优，只是相对于它被喂进去的那个问题而言。如果喂给它的权重是模型凭空幻想出来的，它照样会给你一个自信、精确、最优的垃圾答案——而且这份精确会让这堆垃圾比模型原本那句粗糙的猜测更有说服力。求解器把猜测洗白成了权威。

三种低成本的应对办法：

• 证据门控的权重（如上文）：没有签名，就没有系数。
• 把敏感性分析列为核心输出：每份计划都附带一个问题：「which weight, if wrong by 2×, flips this plan?」（中译：哪一个权重如果错了 2 倍，会让这份计划翻盘？）如果答案是「the one weight we're least sure of,」（中译：正是我们最没把握的那一个权重），那这份计划就只是个假设，不是排期表——仪表盘应该老实说出这一点。
• 诚实的胜算，划定上限：任何展示给人看的概率，都来自「已观测速度」与「所需速度」的对比，并被限制在远离百分之百确定的范围内。按这条规则，我自己的仪表盘第一次读数，是某个营收目标上令人清醒的 2%——而这正是那种会让你去改输入、而不是去欣赏界面的数字。

今天在跑什么，接下来要做什么

这套架构的 v0 版本，今天已经上线到我作品集的所有者仪表盘上：三条带日期里程碑的目标轨道、以依赖关系图呈现的创投版图、以及每次加载时根据实时「成绩单」遥测数据重新求解出的「接下来最该做的 1—3 步」——还包括时间旅行功能，可以回放这套系统在过往任意一天本会给出的答案。它的重求解器目前还只是个贪心打分器，不是完整的整数规划；把它换掉的路径很短，因为 Life GPS 已经通过 HTTP 暴露出 /plan 和 /replan。接下来的构建顺序，每一步一个工作时段即可完成：（1）在受所有者权限保护的 API 背后，把贪心打分器换成 BILP；（2）让策略引擎像撰写一份实战项目那样撰写权重文件——附带证据、由人签字；（3）注册 tripwire，让策略层的重求解由事件触发，而非按计划表定时进行。目标：三道接缝都在两周内上线（截至 2026-08-18）。每一步都很小，因为每一块都已经在跑了；真正的工作在于接缝本身——这正是本文的论点。

模式 / 反模式

• 模式： 神经网络负责提议，符号系统负责裁定——只在每一个分支爆炸的节点上如此，仅此而已 [7]。
• 模式： 两个时钟——分配层的重求解又快又便宜；目标层的重求解则缓慢，且只在触发 tripwire 时进行。
• 模式： 验证者是结构性的（一个求解器、一次测试、一道闸门），绝不是再问模型一遍。
• 反模式： 让模型既做计划又检查计划——这是让一则谣言去审计另一则谣言 [2][3]。
• 反模式： 给优化器喂未经签字的权重——结果是被精度包装过的最优垃圾。
• 反模式： 只用一个时钟——要么让策略层天天变来变去，要么让分配层按季度冻结不动。

出处说明——哪些是经过核实的，哪些是我自己的

全部八条研究引文，均已在发表时对照所列来源逐字核实（Nature 摘要页面需要用浏览器 user-agent 才能抓取）。Life GPS 是我本人公开的代码，描述内容取自其代码仓库。策略引擎及其客户实战项目属于我的私有系统，仅在能力层面描述——按其许可协议，不涉及内部细节。仪表盘、其中的贪心重求解器，以及那个 2% 的读数，都是实时运行、受所有者权限保护、且归我所有的。

参考文献

1. Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., Saldyt, L., & Murthy, A. (2024). Position: LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks. ICML 2024. arxiv.org/abs/2402.01817
2. Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks. arxiv.org/abs/2402.08115
3. Valmeekam, K., Marquez, M., & Kambhampati, S. (2023). Can Large Language Models Really Improve by Self-critiquing Their Own Plans? arxiv.org/abs/2310.08118
4. AhmadiTeshnizi, A., Gao, W., & Udell, M. (2024). OptiMUS: Scalable Optimization Modeling with (MI)LP Solvers and Large Language Models. ICML 2024. arxiv.org/abs/2402.10172
5. Xiao, Z., Zhang, D., et al. (2024). Chain-of-Experts: When LLMs Meet Complex Operations Research Problems. ICLR 2024. iclr.cc/virtual/2024/poster/18977
6. Zhang, B., Luo, P., Yang, G., Soong, B. H., & Yuen, C. (2025). OR-LLM-Agent: Automating Modeling and Solving of Operations Research Optimization Problems with Reasoning LLM. arxiv.org/abs/2503.10009
7. Trinh, T., Wu, Y., Le, Q., He, H., & Luong, T. (2024). Solving olympiad geometry without human demonstrations. Nature 625.nature.com/articles/s41586-023-06747-5
8. Hall, S., Guerrini, L., Dörfler, F., & Liao-McPherson, D. (2024). Receding Horizon Games for Modeling Competitive Supply Chains. arxiv.org/abs/2401.09853

相关文章

• 2019 年我造出了公司的大脑，却把它当成了待办清单 ——第一部分：坦白书，也是本文所依据的 MPC 框架。
• 我们造了一台会跟自己较劲的机器 ——同样的「验证者而非感觉」原则，用在了交付主张上。
• 策略即代码 ——为什么策略层是数据与闸门，而不是幻灯片。

本文是公司 GPS 系列第二部分。研究素材包（八篇来源，引文均在发布时逐字核验）整理于 2026-08-04。——Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app