规划Agent的三个结构性问题：更大模型也修不好

这是 PlannerCritic 系列的第 3 篇文章。PlannerCritic 是一个开源引擎，其中一个 LLM 负责写计划，另一个 LLM 负责审查。第 1 篇介绍了 157 个目标的大规模实测。第 2 篇讲的是审查器严格程度的一个 bug。这一篇要说的是实测中最令人不安的发现：规划器存在一个结构性问题，再大的模型升级也解决不了。

132 个具体阻塞项，横跨 63 个严格目标。三类缺陷族。gpt-4o 也试了。相同的模式。修复方案是确定性验证，而不是更多参数。

到第 10 个严格目标时，我就注意到了。到第 50 个时，我能在审查器打印出来之前就预测到失败。到第 100 个时，我不再惊讶，开始感到恼火。

规划器一直在犯同样的三个错误。不是偶发的。不是随机的。每个失败的严格目标，都源于三类缺陷之一。

未验证的依赖（57 个阻塞项）

计划声明了一个前置条件，但之前没有任何任务建立过这个条件。规划器知道什么应该为真。它没有安排步骤来使之成真。

真实案例——来自 ai-03-model-serving-migration：

[BLOCKER] unverified_dependencies — task=cutover_traffic_100
  "Cutover traffic from SageMaker to vLLM (100%) verification of
  latency SLO is dependent on prior traffic cutover stages being
  established but lacks clear confirmation of stability before
  proceeding."

计划说"切流 100% 流量"，但之前没有任何任务验证过 10% 和 50% 阶段是稳定的。

不安全的排序（46 个阻塞项）

任务在其硬依赖之前就绪了。切流在验证之前运行。备份在迁移之后完成。

真实案例——来自 ai-02-embedding-index-migration：

[BLOCKER] unsafe_sequencing — task=backfill_vectors
  "Backfill operation cannot proceed until the index is verified
  for quality; it is ordered incorrectly in the sequence."

计划把回填放在了质量检查之前，而质量检查本应作为其门槛。

薄弱的回滚（18 个阻塞项）

高爆炸半径的步骤缺少回滚。规划器在常规步骤上包含了回滚，但在切流、拆除和故障恢复上遗漏了。

真实案例——来自 db-10-multi-tenant-split：

[BLOCKER] weak_rollback — task=dual_write_setup
  "The dual-write setup task's rollback only switches to
  single-write mode without addressing potential inconsistencies
  during the transition."

回滚存在，但不可信。切换回单写并不能撤销双写可能引入的数据不一致。

我试了一个更大的模型

本能反应：用 gpt-4o。我一直等着它来救我。

两种方式都测了——gpt-4o 规划器配 mini 审查器，以及两边都用 gpt-4o。

相同的缺陷模式。更流畅的表述。相同的结构性错误。

未验证的依赖。不安全的排序。薄弱的回滚。

那一刻我停止了对模型大小的指责。规划器并不蠢。这才烦人。它说得通。它知道正确的步骤。只是无法闭合依赖图，也无法强制执行排序。

我面对的不是小模型问题。我面对的是规划结构问题。

为什么循环解决不了它

修订循环的设计目的是收敛。审查器报告阻塞项。规划器修订。

但规划器倾向于修复一个阻塞项，同时引入另一个。它打乱任务顺序而不闭合依赖缺口。它把回滚加到了错误的步骤上。

经过 2 次修订——33 个严格目标的中位数——规划器停止做出有意义的改变。收敛检测器触发。引擎升级。

循环按设计运行。规划器是瓶颈。我一直期待修订循环能收敛。它没有，因为规划器无法通过重写表述来修复一个结构性问题。

修复方案不是更多参数

最高杠杆的修复是前置条件闭合器：规划器产出初稿后，验证每个前置条件是否真的由更早的任务建立。如果一个任务说"需要 replica_verified"，就必须有一个更早的任务产生它。

这一个 pass 就能消除 132 个阻塞项中的 64 个（48%），而不需要让 LLM 更聪明。

剩下的阻塞项——不安全的排序和薄弱的回滚——需要更好的提示工程、额外的确定性验证，或者真正更好的排序和风险推理能力。

研究怎么说

这不只是我的观察。学术文献也得出了相同的结论。

"Why Reasoning Fails to Plan" 论文（arXiv 2601.22311）表明，LLM 智能体基于局部评估选择行动，而不考虑后续后果。在知识图谱遍历中，单步贪心策略超过 55% 的时间会选择短视陷阱。作者证明了逐步推理对长期规划必然不足。

PlanGenLLMs 调查（arXiv 2502.11221）评估了 LLM 规划在四个维度上的表现——完整性、可执行性、最优性、表示。LLM 在确保计划可执行上始终失败：前置条件未满足，步骤顺序混乱。

学界正在向混合方法收敛——LLM 加上确定性验证，加上经典规划技术。不是单靠 LLM。

你应该记住什么

如果你在构建多步骤规划的智能体：

在真实语料上测试你的规划器。157 个目标的运行揭示了一个 3 个演示目标永远不会展现的模式。

衡量缺陷类型，而不只是通过/失败。如果你的所有失败都属于一个族，你有一个具体的缺口。

不要假设更大的模型会修复结构性问题。规划差距是推理能力的局限，而不是语言能力的局限。

在信任 LLM 自我修正之前，加入确定性验证。修订循环有用，但它不是结构性检查的替代品。

PlannerCritic 系列第 3 篇，共 5 篇。

系列文章：第 1 篇："I Ran 157 Agent Plans Against a Real LLM" · 第 2 篇："I Told My LLM Critic to Be Adversarial" · 第 4 篇："The Field Test Found 10 Issues" · 第 5 篇："I Tried to Prompt-Inject My Own Engine"

仓库：github.com/deghosal-2026/planner-critic-engine

PyPI：pip install planner-critic

实测结果：横跨 35 个领域的 157 个目标

实测计划：156-goal corpus

架构：architecture-v0.1.0.md

用户指南：quickstart.md

更新日志：CHANGELOG.md