计划赶不上变化
前面五篇文章讨论的问题都有相对明确的对策——幻觉可以加 RAG，工具错误可以强 Schema，崩溃可以做检查点，协调可以共享状态，治理可以定规则。但有一个问题是本质性的：未来不可预测，而智能体必须做决策。
这就是规划失效问题：智能体基于当前信息制定了完美的执行计划，但执行过程中环境变了、信息更新了、前提不成立了——计划从"最优解"变成了"最蠢路径"。
这不是 AI 的特殊问题，是人类也在天天面对的。区别在于人类有丰富的经验来应对不确定性，而智能体的"经验"只有训练数据和当前上下文。
不确定性的三个来源
来源一：环境动态性
外部环境在 Agent 执行任务期间发生了变化。
典型场景
Agent 计划：查库存 → 下单 → 发货
现实发生：查库存时有货 → 下单时库存已变（另一位客户买了）→ 发货失败
动态环境中的"信息时效性"问题：
- 查询时信息准确 ≠ 行动时信息准确
- 信息和行动之间的时间差越大，规划越可能失效
- 有些环境变化不可预测（突发需求、系统故障、外部政策调整）
特殊难点：Agent 自身改变了环境
Agent 的行动可能改变了它所处环境的条件，导致后续计划的前提不再成立：
Agent 分析了市场数据 → 基于分析推荐了 A 股票
→ 1000 个用户跟随买入 → A 股价被推高
→ Agent 原有的"低估"判断不再成立
这就是反身性（Reflexivity）——观察行为本身改变了被观察对象。 Soros 讲了几十年的金融哲学，在 Agent 时代以新形态重现。
来源二：信息不完备性
Agent 做决策时所依据的信息不完整。
已知的不确定 vs 不确定的不确定
- 已知的不确定：Agent 知道自己不知道什么。比如"我不知道今天的库存量，需要先查询"
- 不确定的不确定：Agent 不知道自己不知道什么。比如 Agent 以为自己了解退货政策，但政策上周刚改了，它不知道
后者更危险——Agent 在错误的前提下做出自信的决策，和幻觉类似但根源不同：幻觉是模型编造事实，信息不完备是真实事实缺失但 Agent 假装拥有。
隐性约束
很多约束没有写在文档里，是行业惯例或组织内部的不成文规则：
- “和这个客户的合作需要 CTO 审批” —— 没有写在系统里
- “超过 10 万的合同需要法务走特殊流程” —— 存在人的记忆中
- “这个 API 在每天 0-1 点维护时段不可用” —— DM 里提过一句
人类凭经验知道这些隐性约束，Agent 完全不知道——直到踩坑。
来源三：认知局限
即使信息完整、环境稳定，Agent 的推理能力可能不足以找到最优路径。
组合爆炸
设有 20 个待办任务，寻找最优执行顺序需要比较 20! ≈ 2.4 × 10^18 种排列。这不是任何 LLM 能穷举的。人类的策略是用启发式（先做最紧急的、先做最简单的），Agent 也能用启发式，但好的启发式需要领域经验——而 Agent 往往缺少这种经验。
约束冲突
现实任务的约束经常互相矛盾：
- “尽快完成” vs “不能出错”
- “最小成本” vs “最高质量”
- “全面分析” vs “快速响应”
人类协商权衡，Agent 在没有明确目标函数时会陷入困境——选择了"快"但用户期望"准"，或者做了"全面分析"但用户等不及了。
规划失效的三种表现
表现一：刚性执行——计划一旦确定，环境变了也不改
# 刚性执行
plan = generate_plan(task)
for step in plan:
execute(step) # 即使前面的步骤已经失败或产生了新信息
# 仍然按原计划继续
这是最简单的实现方式，也是最脆弱的。一旦发生任何偏离，Agent 就像 GPS 导航一样"请在下个路口掉头"——无论实际情况如何。
表现二：过度重规划——每次新信息都推翻当前计划
获得信息 A → 制定计划 1
获得信息 B（微调了 A）→ 全盘推翻计划 1 → 制定计划 2
获得信息 C → 又推翻 → 计划 3
...
这像"分析瘫痪"——不停重新规划，永远不行动。Token 预算烧完了，任务一个没完成。
表现三：规划幻觉——基于错误前提制定"完美"计划
Agent 的规划能力很强，能生成非常完整、专业的执行方案。但如果规划前提有问题（遗漏了约束、信息过时、假设错误），越"完美"的计划越危险——它看起来太好了，让人放松了警惕。
应对策略
策略一：反应式规划（Reactive Planning）
不做长程固定计划，改为"观察-决策-行动"的短循环：
loop:
1. 观察当前环境状态
2. 基于当前状态选择下一步行动（而非未来十步）
3. 执行行动
4. 观察结果
5. repeat
优点：环境下变了自动适应，不存在"计划赶不上变化" 缺点：可能陷入局部最优——只顾眼前，看不到长远
最佳实践：保持一个粗粒度的长期目标 + 细粒度的短期行动
长期目标：帮用户完成退货（不变）
短期行动：先查询当前退货政策 → 再决定下一步（可变）
策略二：信息采集优先
在行动前先补充信息，减少"不确定的不确定"：
接到任务后先不直接行动，而是：
1. 列出完成这个任务需要知道什么
2. 识别哪些信息是缺失的
3. 优先获取缺失信息
4. 信息充分后再做决策
这和人类的好习惯一样——先问清楚再做，别急急忙忙开始然后发现前提错了。
实现模式——扇出-扇入信息采集：
[任务] → 同时查询：库存系统 + 退货政策 + 客户历史 + 物流状态
↓（扇出）
所有信息收集完毕
↓（扇入）
[基于完整信息做决策]
并行采集比串行更快，且在信息到齐后再决策，避免"先行动后补信息"的后悔。
策略三：元认知——知道自己不知道什么
让 Agent 在推理过程中显式评估自身的不确定性：
推理步骤 X：基于当前信息推断 A 是最优选择
→ 元认知评估：这个推断的信心是多少？
- 信心 > 90%：自主执行
- 信心 60-90%：执行但标记"需要后续验证"
- 信心 < 60%：暂停，请求补充信息或人工指导
元认知的核心是显式的不确定性建模——不是"假装知道"，而是"承认不知道"并在不知道时采取保守策略。
策略四：渐进细化——分层规划
从粗到细，逐步细化执行方案：
Level 0（战略层）：目标是退货
Level 1（战术层）：步骤是 [查询政策 → 提交申请 → 跟进进度]
Level 2（执行层）：立即执行的是"查询政策"——只细化这步
后续步骤等到了那一步再细化
好处：不会在第一步就花大量 token 规划十步，而环境可能在第三步就变了。只细化当前步骤，其他步骤保持粗粒度锚点。
策略五：假设管理
显式追踪计划依赖的假设：
plan_assumptions = {
"库存充足": {"checked": True, "valid": True}, # 已验证
"退货政策未变": {"checked": False, "valid": None}, # 未验证
"客户有退货权限": {"checked": True, "valid": True} # 已验证
}
# 执行前检查关键假设
for assumption, status in plan_assumptions.items():
if not status["checked"]:
# 先验证这个假设，再继续执行
verify(assumption)
如果关键假设未验证，行动暂停——等验证通过后再走。假设管理是连接"规划"和"验证"的桥梁。
更深层的思考：智能的边界
不确定性的终极问题是：在不确定性面前，智能体能走多远？
人类的答案不是"更聪明地预测未来"——没有人能完美预测——而是"保持灵活性和冗余度"。好的管理者不会制定一个不能修改的完美计划，而是制定一个能随时调整方向的框架，并为意外情况预留缓冲。
智能体也需要这种"管理智慧"：
- 不是追求完美规划，而是追求可适应的规划
- 不是假设信息完整，而是承认信息永远不会完整
- 不是消除不确定性，而是在不確定性中稳健行动
这才是 Agent 规划能力的最终目标：不是更准确的预见，而是更灵活的适应。
系列小结
六篇文章，六个问题，映射了智能体从"能用"到"好用"之间的全部鸿沟：
- 幻觉 → 不实信息如何通过推理链级联放大
- 工具调用失败 → 智能体与外部系统交互的结构性困难
- 中途崩溃 → 长链路任务对基础设施的可靠性要求
- 多 Agent 协调 → 分工协作的协调成本与失败模式
- 治理问责 → 自主行动者的责任边界和控制框架
- 不确定性与规划 → 面对未知环境时的规划与适应
每个问题都有技术对策，但没有银弹。智能体工程不是单一算法的突破，而是多层防御的系统工程——在模型的不可靠性假设下，用检索锚定、类型约束、持久化引擎、共享状态、权限边界和适应式规划，一层层构建出整体可靠的系统。
正如工程界的老话：可靠性不是来自每个组件的完美，而是来自对每个组件不完美的假设下的系统设计。