大模型结合符号规划的自主决策方法

可视化演示

可视化展示大语言模型结合符号规划的自主决策流程：自然语言转PDDL、规划器求解与状态空间搜索，交互切换观察混合智能架构。

大模型规划短板

热情的路盲导游为什么总把游客带偏？因为他不是真的“认识路”，只是记住了很多“游客爱听的表达”：你说往南，他立刻联想“南边有古城”，再联想“古城附近应该有美术馆”，于是脑补出一条看似顺理成章、实际上不存在的路线。大语言模型也有同样的毛病：它在海量文本上学到了“计划长什么样”，却没有学过在状态空间里一步一步验证“这条路径真的能走通”。

从技术角度看，LLM 是一个自回归语言模型，它的目标是“预测下一个词”，不是“找到可达目标的动作序列”。当任务链条超过 5~10 步，它容易产生三类问题：第一，路径幻觉，编造出地图上不存在的地点或动作；第二，漏掉步骤，比如规划“订机票+订酒店+租车”时，把“租车”这个大目标忘了；第三，组合搜索弱，当动作空间很大、约束交错时，真正的最优解需要系统性搜索，而生成式模型只会沿着概率最高的方向一路走到底。

这就解释了为什么很多智能体 demo 看着聪明，一到真实多步任务就掉链子。单靠 LLM 规划，相当于让一位记性好但从不看地图的导游带团；我们需要给他配一张精确的地铁线路图，并把“找路”这步交给专业计算者。

PDDL语言基础

地铁图要发挥作用，必须有一套统一画法：每条线路用颜色标出，每个站点有标准名称，换乘关系清清楚楚。符号规划里的 PDDL 就是这套“标准画法”。PDDL 全称是 Planning Domain Definition Language，它把规划问题拆成两个文件：域文件（domain）描述通用的规则，比如“人可以乘坐地铁”“列车在站间移动”；问题文件（problem）描述具体场景，比如“当前在 A 站，要去 C 站”。域文件相当于地铁线路图，问题文件相当于你手写的行程单。

在 PDDL 中，动作是改变世界状态的最小单元。一个动作通常写作三元组：参数、前提条件、执行效果。只有当前状态满足前提条件，动作才能执行；执行后，世界按照效果更新。

把动作格式标准化以后，任何人都能写“地铁图”，任何规划器都能读“地铁图”。导游不需要亲手设计线路，他只需要用这套标准语言，把游客的需求准确写进行程单。

LLM+P流程

现在故事进入正题：导游怎么和调度中心合作？第一步，导游听完游客诉求后，用标准格式写出一份“需求单”；第二步，把需求单交给调度中心的换乘规划器；第三步，规划器算出精确换乘方案；第四步，导游把方案翻译成游客听得懂的话。LLM+P 就是把这四步搬到 AI 系统里：先用 LLM 把自然语言任务转成 PDDL 域文件和问题文件，再调用经典规划器求解，最后让 LLM 把规划器输出的符号动作序列翻译回自然语言步骤。

整个流程可以写成一条简洁的流水线：

这个流程的美妙之处在于各司其职：LLM 不负责“算路”，规划器不负责“听懂人话”。导游的短板被调度中心的精确计算补上，调度中心的“冷冰冰”又被导游的人性化翻译化解。

经典规划器

地铁调度中心的换乘规划器是怎么工作的？它不会像导游那样凭感觉说“往南走”，而是把地铁网络想象成一张巨大的图，每个站点是一个状态，每段线路是一个动作。它从当前站出发，逐条尝试所有能坐的线路，每到一个新站就记录下来，再继续尝试，直到找到一条能到达目标站的路线。这个过程就是状态空间搜索。

在符号规划中，每个状态是一组谓词的真假集合，动作会删除一些谓词、新增一些谓词。规划器从初始状态出发，反复执行“检查前提 → 应用效果”的步骤，形成一棵搜索树。

真实场景中，盲目搜索会指数爆炸。现代规划器如 Fast Downward 会计算启发式函数，优先探索“看起来离目标更近”的分支，再结合因果图、landmark 等技巧大幅剪枝。对 LLM+P 来说，规划器不需要多聪明，只要它给出的是可证可达的符号动作序列，就已经弥补了 LLM 最致命的可靠性短板。

转换接口设计

导游想要把需求单递给调度中心，中间需要一位既懂中文又懂地铁黑话的翻译官。如果翻译官把“美术馆”写成了“博物馆”，或者漏掉了换乘站的楼层信息，调度中心要么报错，要么给出一条完全错误的路。LLM+P 里最考验工程能力的，正是 LLM 和 PDDL 之间的“翻译官”——转换接口。

设计这个接口通常分三步：第一步，设计提示模板，用 few-shot 示例告诉 LLM“你只需要输出 PDDL 格式的 JSON，不要解释”；第二步，写语法校验器，把 LLM 输出解析成语法树，检查谓词是否定义过、对象类型是否匹配；第三步，设置错误恢复，如果校验失败，把错误信息回喂给 LLM，要求它重新生成。

好的翻译官能让两个体系无缝协作。工程上，这个接口往往是 LLM+P 系统里投入最多精力的部分：提示模板决定了 LLM 输出的规范性，校验器决定了坏数据不会被放行，错误恢复则给了 LLM 一次“重新翻译”的机会。

适用场景边界

是不是所有规划任务都适合“导游 + 地铁图”？当然不是。地铁图再精确，也没法告诉你哪家店好吃、哪个路口临时封路、游客突然想改行程怎么办。符号规划本质上要求三件事：状态可以枚举、动作效果可以确定、目标可以形式化。一旦任务涉及实时感知、开放世界或主观偏好，纯符号规划就会失灵。

适合 LLM+P 的任务通常有这些特征：步骤多但规则明确，比如装配流程、机器人搬运、API 编排；约束复杂但可描述，比如“先做身份验证再做余额查询”；目标可验证，比如“货物最终必须在发货区”。不适合的任务则是开放式闲聊、实时驾驶决策、个性化推荐等，这些需要常识和感知，符号化成本极高。

所以真正落地的混合架构不是二选一：LLM 负责把模糊需求抽象成结构化问题，符号规划器负责在结构化空间里精算，执行器负责感知真实世界并把反馈送回 LLM。导游、调度中心、现场工作人员三方配合，才能应对真实世界的复杂性。

质量评估方法

怎么判断一个导游带团带得好不好？最简单粗暴的标准是：承诺的景点是否都去了？去的顺序是否合理？游客是否真的满意？对应到 LLM+P，我们也有三个经典评估口径：规划成功率看重在可解任务中，系统最终是否输出合法计划；步骤正确率对比计划中的每一步是否和人工标注的 ground truth 一致；端到端完成率则把计划交给模拟器或真机执行，看最终目标是否真的达成。

规划成功率是最常用的基础指标，可以写成：

在对比评测中，纯 LLM 在短任务上成功率可能不错，但任务一长就急剧下降；LLM+P 虽然多了一道 PDDL 转换开销，成功率却更稳定。用数据说话，我们才能说服自己和团队：那个路盲导游，真的需要一张精确的地铁图。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""简化版 LLM+P 演示：模拟 LLM 把自然语言任务转成 PDDL 风格的初始/目标状态，再用 BFS 规划器搜索动作序列，最后翻译成自然语言步骤。"""from collections import deque  class LLMTranslator:    """模拟 LLM 的翻译能力：自然语言 -> PDDL 状态谓词"""     def translate(self, task_text):        # 真实场景中这里调用大模型，生成 (init, goal) 二元组        if "从3走到7" in task_text:            init = {("at", 3)}            goal = {("at", 7)}        elif "从1走到4" in task_text:            init = {("at", 1)}            goal = {("at", 4)}        else:            init = {("at", 0)}            goal = {("at", 5)}        return init, goal  class BFSPlanner:    """经典符号规划器：广度优先搜索可执行动作序列"""     def solve(self, init, goal, max_steps=15):        start = frozenset(init)        target = frozenset(goal)        queue = deque([(start, [])])        visited = {start}        while queue:            state, plan = queue.popleft()            if target.issubset(state):                return plan            if len(plan) >= max_steps:                continue            current_at = [value for pred, value in state if pred == "at"]            if not current_at:                continue            pos = current_at[0]            for next_pos in (pos - 1, pos + 1):                new_state = set(state)                new_state.discard(("at", pos))                new_state.add(("at", next_pos))                frozen = frozenset(new_state)                if frozen not in visited:                    visited.add(frozen)                    queue.append((frozen, plan + [("move", next_pos)]))        return None  class PlanTranslator:    """把符号动作序列翻译回自然语言"""     def translate(self, plan):        if plan is None:            return "抱歉，没有找到可行的行动计划。"        lines = []        for idx, (action, target) in enumerate(plan, 1):            lines.append(f"{idx}. 向前移动到位置 {target}")        return "\n".join(lines)  def main():    task = "帮我从3走到7"    translator = LLMTranslator()    planner = BFSPlanner()    plan_translator = PlanTranslator()     init, goal = translator.translate(task)    print("PDDL 初始状态:", sorted(init))    print("PDDL 目标状态:", sorted(goal))     plan = planner.solve(init, goal)    print("符号规划器输出:", plan)    print("自然语言计划:")    print(plan_translator.translate(plan))  if __name__ == "__main__":    main()

1. init = {("at", 3)}用 PDDL 谓词 “at“ 表示”当前位置是 3”，对应问题文件中的初始状态。
2. target.issubset(state)检查目标谓词是否全部满足，等价于 PDDL 中的目标判定。
3. new_state.discard(("at", pos))执行动作效果：从状态中删除旧的 "at" 事实。
4. new_state.add(("at", next_pos))执行动作效果：向状态中新增 "at" 事实，形成下一个状态。
5. planner.solve(init, goal)调用符号规划器完成组合搜索，这一步正是纯 LLM 最不擅长的部分。

常见误区

面试题