模型越大逻辑反而越烂？我发现大模型做复杂规划时有三个死穴

在做 Agent 任务规划的时候，很多人有个误区：觉得如果模型生成的 Plan 不靠谱，那就换个参数量更大的模型，比如从 GPT-3.5 换到 GPT-4o。我最近在研究 PlannerCritic 这个开源引擎（一个专门让一个模型写计划、另一个模型挑刺的架构）时，发现这个逻辑完全行不通。

哪怕你把模型升级到顶配，它在处理复杂任务时依然会反复掉进同一个坑里。在 63 个严格目标的实测中，我发现 Planner 哪怕换了 GPT-4o，依然会犯下极其相似的结构性错误。这些错误不是因为模型“笨”，而是因为大模型的逻辑闭环能力在长链条规划面前非常脆弱。

我把这些错误总结成了三类“顽疾”：

• 依赖关系验证缺失： 模型知道做 A 之前需要 B，但它在写计划时，并不会在前面的步骤里安排一个“验证 B 是否成功”的任务。比如它计划“100% 切流”，但前面并没有任何一步去确认“10% 切流是否稳定”。
• 执行顺序逻辑混乱： 这是最容易翻车的地方。模型会把“备份”放在“迁移”之后，或者把“数据回填”放在“质量检查”之前。它能写出这些步骤，但它对步骤之间的先后因果律缺乏强约束。
• 回滚方案极其敷衍： 遇到高风险操作（比如数据库拆分），模型往往只会在常规步骤里写回滚，但在真正关键的切流环节，它只会写一句“切回单写模式”，却完全忽略了切换过程中产生的数据不一致问题。这种回滚方案在实战中根本没法用。

我测试过用 GPT-4o 当 Planner，搭配一个轻量级的 Critic 模型，甚至用 GPT-4o 双持（一个写一个审），结果发现：文字变得更漂亮了，逻辑漏洞依然如故。

这说明解决规划问题的路径根本不是去堆参数，而是要引入“确定性校验”。单纯靠“Critic 报错 -> Planner 修改”这种循环是修不好的，因为 Planner 往往是改好了一个 Bug，又引入了另一个新的依赖冲突。

如果我们要写一个靠谱的 Planner Prompt，不能只让它“列出步骤”，必须强制它在每一个关键节点进行状态检查。

这里是我总结的一个针对复杂任务规划的 Prompt 优化思路，重点在于强制引入“前置条件验证”和“风险回滚闭环”：

# Role: Senior Systems Architect & Planner

## Task
Generate a high-precision execution plan for the following goal: {{goal}}

## Strict Constraints (Mandatory)
1. **Dependency Verification**: For every critical task, you MUST explicitly include a "Verification Step" in the preceding task. Do not assume a state is achieved; prove it.
2. **Sequential Integrity**: Tasks must follow a strict causal chain. No high-risk operation can be scheduled before its prerequisite stability check is completed.
3. **Robust Rollback**: For every task with a "high blast radius" (e.g., data migration, traffic cutover, schema change), you must provide a "Deep Rollback" plan. A deep rollback must address data consistency and state recovery, not just a simple toggle switch.

## Output Format
For each task, use the following structure:
- **Task ID**: [ID]
- **Action**: [Detailed description]
- **Prerequisite Verification**: [How to confirm the previous state is ready for this task]
- **Success Criteria**: [Specific metric or state to confirm completion]
- **Rollback Plan**: [Detailed steps to revert to a consistent state if this task fails]

如果你还在尝试通过换模型来解决 Agent 的规划问题，建议先停下来，去优化你的工作流和校验逻辑。