本节要解决的事：自然语言里“接着下单”只有四个字，环境里却要求登录、权限、库存和确认同时成立。
写出步骤，不等于存在可执行动作
任务是买三盒红笔。模型列出“查库存→下单→确认成功”，看上去没有明显问题。但当前会话未登录，或者只有查询权限，这条链路到下单就会失败。更隐蔽的情况是查询时库存三盒，执行前被别人买走一盒；计划在生成时可行，执行时已经不可行。
朴素规划把动作名排成句子，省略了动作的进入条件。显式规划则先描述状态：已登录吗，有创建订单权限吗，库存至少三盒吗，用户已确认吗？动作不仅有名字，还包括需要什么，以及执行后改变什么。这样我们可以在真正调用之前发现明显缺口。
将下单动作展开成一张契约
设状态包含 logged_in、can_create_order、stock、approved。教学动作 create_order(3) 的前提是登录、权限、批准这三个布尔条件都为真，而且 stock 至少为 3。成功效果是产生订单编号并把库存扣减三盒；失败则必须返回明确错误，不能在状态里假装出现订单。
这只是简化模型。真实系统可能先预留库存，再支付，最后确认；订单创建与扣库存也可能属于不同服务。我们选择简单规则，是为了看清前提和结果，不把它当成所有电商的业务实现。生产系统必须使用真实接口与事务语义。
只少一个前提，下单还能执行吗？
先做预测，再逐步展开。这里是固定规则的教学回放，不是真实模型测评。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
登录＝是，创建权限＝是，批准＝是，库存 5，需要 3。
- 1. 检查前提
身份、权限、批准均满足；5≥3。
- 2. 执行动作
按教学规则创建订单 O-17。
- 3. 应用效果
库存 5−3＝2，并记录 O-17。
身份、权限、批准均满足；5≥3。
先预测，再核对结果与原因
订单存在，剩余 2动作效果只在执行成功后写入状态。
语言上的合理与物理上的可做不同
机器人计划“拿杯子”很符合目标，但杯子可能够不到。网页计划“点击退款”也符合目标，但用户角色看不到按钮。课件用 affordance 讨论动作在环境中能够成功的可能性：语言模型觉得哪一步合理，与执行技能在当前状态能否完成，需要一起考虑。
比较确定的小型环境和开放网页。前者可以穷举状态与动作规则，找一条满足前提的路径；后者页面、权限和外部事件不断变化，完整建模成本很高，甚至无法知道全部状态。此时可只显式建模关键前提，再通过观察更新，不必为了形式化把世界假装得比实际更确定。
另一种误解是“检查过就不必再检查”。规划时的检查减少无效尝试，执行时的检查处理竞态与最新权限。它们位于不同时间，不能互相替代。对于产生副作用的动作，最终服务端规则才应决定是否允许状态转移。
理解检查
问题一：用户同意购买，是否自动拥有下单权限？ 不会。用户意图与系统授权不同；批准满足任务层前提，接口仍可能要求对应身份和权限。两层都需要成立。
问题二：模型预测成功概率很高，能否绕过执行端检查？ 不能。概率是对未知结果的估计，授权和库存约束是实际操作边界。再高的预测也不能保证环境状态未变化。
问题三：创建请求失败后，计划能否先把库存写成 2，方便继续？ 不能。除非明确标为假设状态用于模拟，否则会把未发生的效果当作事实。真实状态应保持原值或标为未知，并依据返回结果恢复。
下一问
发现未知条件以后，Agent 有三个选择：继续推理、获取新观察、直接行动。下一节比较它们究竟分别能减少哪种不确定性。