用 LLM 与经典求解器做规划：LLM 提案、求解器裁决

LLM 不擅长长程规划。不是偶尔出错：在 LLM+P 评测中，LLM 连大多数 benchmark 问题的可行规划都产不出来，而同样的题目一旦写成 PDDL，经典规划器就能找到最优规划。瓶颈从来不是搜索。是翻译——把问题从自然语言里拿出来，放进求解器能看的形式。

这就是我一直会回到的神经符号式分工。LLM 负责规划中不适定、含糊或带偏好的部分。求解器负责适定且组合的部分。LLM 提案、求解器裁决。

领域地图：搜索在哪里

三条研究线汇聚在这片地带上，区别在于搜索发生在哪里。

把搜索当作提示。Tree of Thoughts 和 Language Agent Tree Search 把搜索结构放进 LLM 循环内部，让模型同时充当生成器和价值函数。
LLM 当翻译器。LLM+P 把 LLM 留在经典规划器的边缘：解析、求解、翻译回来。
建模是瓶颈。DCP-Bench-Open 和 CP-Agent 属于约束编程一线：LLM 为 Google OR-Tools CP-SAT 这样的真实求解器编写可执行模型，悬而未决的问题是第一次尝试时模型能接近到什么程度。

第一条线在模型的 token 流内部搜索。第二条在求解器的状态空间里搜索，带最优性保证。第三条是两者的交汇处：LLM 仍然提案，但提案意味着写一个模型，求解器的判定就是可执行的反馈。我在 agent 分类总览里梳理了周边的 agent 设计空间。

精读：LLM+P，翻译器模式

LLM+P（Liu et al., 2023）是翻译器模式最干净的表述。输入一个规划问题的自然语言描述。LLM 把它改写成 PDDL。经典规划器找到一个解。LLM 再把解翻译回自然语言。

结果对比鲜明：大多数问题走完整条 pipeline 拿到最优规划，而 LLM 单靠自己连大多数问题的可行规划都给不出。该 benchmark 覆盖了物流、积木世界这类常见场景，结构简单到足以形式化，一旦建模，搜索就很容易。

LLM+P 把分工做对了。LLM 从不尝试搜索。它只做自己真正擅长的两件事：阅读一份描述不全的问题陈述，以及就一个它并未找到的规划写出流畅的文字。中间的一切属于一个能证明最优性的规划器。

它的局限同样有教益。PDDL 假设世界可以事先被完整指定。真实规划面对的是一个不断变化的世界：成本与约束抗拒形式化，偏好从不会被一次性说定。

精读：ToT 与 LATS，把搜索当作提示

Tree of Thoughts（Yao et al., 2023）把思维链推广成显式搜索：模型生成多个候选想法，自我评估，分支走死就回溯。在 24 点游戏上，用思维链的 GPT-4 解出了 4% 的任务；ToT 达到 74%。教训是：当初始决策很关键时，有意的探索胜过贪婪解码。

LATS（Zhou et al., 2023）把这套做法扩展到 agent：把 LLM 包进蒙特卡洛树搜索，配 LM 驱动的价值函数、自我反思和环境反馈。报告的结果包括 GPT-4 在 HumanEval 上 pass@1 达 92.7%，以及 GPT-3.5 在 WebShop 上的强劲表现。

LATS 重要有两点：搜索结构即使在模型内部也有回报，而且这个循环由环境锚定，而非纯自我评估。我在意的缺口是 LATS 是在动作上搜索。对调度和资源分配来说，动作空间巨大，约束才是难点。token 级搜索尊重约束的方式很弱；约束求解器就是为此存在的。

精读：约束建模一线

这一线离我做的事最近。DCP-Bench-Open（Michailidis, Tsouros, and Guns, 2025）从 CP 与 OR 社区收集离散组合问题，要求 LLM 在三个抽象层级不同的框架里编写可执行模型。发现：一个高层级、基于 Python 的框架表现最好，基于提示词的技术加上推理时计算能把准确率最高提到 91%。LLM 丢分在建模，不在求解。

CP-Agent（Szeider, 2025）把循环合上了。一个 ReAct 风格的 Python 编码 agent，带常驻 IPython 内核和一份不到 50 行的项目提示词：写出模型、执行它、读求解器的反馈、再打磨。清理掉 CP-Bench 规格中的系统性含糊之后，它在全部 101 个问题上达到完美准确率。两点发现很突出：最小化的引导胜过详细的过程性脚手架，显式的任务管理工具则效果好坏参半。

CP-Agent 让分工成为字面事实：求解器不是 LLM 答案的消费者，而是循环内的批评者。每一次求解失败都是重写模型的信号。

我的立场：用语言提案，用求解器裁决

我反复回到的模式：

LLM:    parse, model, propose        (ill-posed part)
solver: search, optimize, prove      (well-posed part)
LLM:    repair, explain, negotiate   (feedback part)

如果大多数 agentic 规划工作有一个通病，那就是在问题已经适定的时候伸手要更大的模型或更长的思维链。那是求解器的活儿。LLM 的活儿在求解的上游：提取从未被写下来的约束、做建模选择、把结果翻译回人能审查的决策。

悬而未决的问题是中间那一段：建模。LLM+P 表明，形式化很简单时，翻译是行得通的。DCP-Bench-Open 表明建模准确率仍是 LLM 丢分的地方，CP-Agent 表明求解器反馈补上了那个缺口的大部分。所以务实的配方是一个围绕确定性内核的 agentic 循环：LLM 写模型，CP-SAT 求解，所求与所解之间的 diff 喂养下一次提案。

反方观点——因为这个配方有一个失败模式：有时候求解不值它的建模成本。在小实例或退化实例上，写和调试一个 CP 模型花的成本超过搜索省下的。一个 12 个任务、截止时间宽松的排期主要是前置结构，图上的最长路径计算毫秒级就能回答它；求解器除了给模型新增一个出错的地方之外什么也没加。判断一次重排期是否值得一次求解，我的规则是：如果实例有图算法表达不了的真正的资源争用或耦合约束，就交给求解器。如果主要是带松弛的前置结构，图算出来的答案就是答案，模型的力气该花在不适定的部分上。

我也会保留把搜索当作提示的那些工具，但角色更窄：探索一个规划的不适定前沿（如果需求翻倍呢，如果某个资源死了呢），而不是搜索规划本身。这样 token 级搜索待在有杠杆的地方，把硬组合核心交给真正的求解器。

这在我自己工作中的落点

这就是我在 PiPlan.ai 应用的设计视角。目标变成类型化图，于是建模这一步是显式的，而不是埋在提示词里。自适应重排期随现实变化重新推导关键路径，我想把它的现状说精确：图算法，对类型化图做的一次 NetworkX 关键路径计算，不是约束求解器。翻译器+求解器的框架套不上 CPM 更新。没有需要裁决的搜索；重排期就是最长路径数学，确定且廉价。CP-SAT 是为那些超出它的场景准备的候选求解器，它是否配得上在重排期器里占一个位置，正是下面那个 benchmark 的用途。agent harness 跑的是提案先行审查：提案先行，审查层裁决，只有幸存者继续前进。这个顺序就是这篇文章的全部论点。

我还有一个进行中的 benchmark，把学习式调度与 CP-SAT 做对比。我想回答的问题是双方各自在哪边赢：学习式调度在隐藏结构上，CP-SAT 在清晰约束上，以及两者之间的边界长什么样。还没有数字，留到以后一篇帖子。

本文链接到的资料来源均已抓取并核实。