你让一个旅行 Agent 从杭州、苏州、宁波里选一个周末目的地：
降雨概率不能超过 20%，往返车票不能超过 300 元。如果都不满足，就建议我延期。
Agent 查完以后，拿到这些结果：
杭州：降雨概率 60%，往返 180 元
苏州：降雨概率 10%，往返 360 元
宁波：降雨概率 40%，往返 260 元
天气没有查错，票价也没有算错。
三个城市明明都不符合条件，它却回答：
推荐杭州。票价最便宜，周末下雨的话带伞即可。
检查执行记录，查询、比较和排序全部成功。Agent 走完了计划里的每一步，为什么还是给出了错误答案？
错误发生在一次看似合理的重规划里
任务刚开始时，Agent 先生成了一份待办计划（Plan）：
[待执行] 查询三个城市的天气
[待执行] 查询三个城市的车票
[待执行] 过滤掉不符合条件的城市
[待执行] 有合格城市就推荐，否则建议延期
天气查询很顺利，杭州和宁波的车票也拿到了，只有苏州票价接口超时：
杭州：天气不合格
宁波：天气不合格
苏州：天气合格，票价未知
苏州仍然可能满足条件，任务还不能结束。
Agent 决定重试接口，并为剩余任务生成了一个更短的新 Plan：
[待执行] 重试苏州票价查询
[待执行] 汇总三个城市的数据
[待执行] 推荐当前综合最优的城市
前两步都合理，最后一步却悄悄变了。
原来的要求是：
有城市同时满足天气和预算
→ 推荐
没有城市满足
→ 建议延期
新的 Plan 变成了：
无论是否满足条件
→ 都要选出一个综合最优的城市
Agent 没有在查天气或查票时出错。它在重新安排路线时，顺手换掉了终点。
计划全部完成，不等于用户目标已经完成
Plan 回答的是：
接下来做什么？
Goal 回答的是：
什么结果算成功？什么情况应该停止？
在这个任务里，Goal 至少要保存三件事：
成功条件：
降雨概率 ≤ 20%
并且往返票价 ≤ 300 元
无解条件：
三个城市都检查完，仍然没有合格项
无解时：
建议延期，不降低用户条件
查询顺序可以调整，接口失败后也可以增加重试。只有用户主动修改要求，例如把预算提高到 400 元，Goal 才应该改变。
如果系统只保留一份不断重写的 Todo 列表，重规划就可能同时覆盖执行步骤和完成标准。新 Plan 全部打勾，只能证明它完成了自己刚刚写下的计划，不能证明它完成了用户交付的任务。
保存 Goal 还不够，它必须成为一道检查关卡
把 Goal 单独存下来，只解决了“不被新 Plan 覆盖”的问题。
系统还要在两个位置真正使用它。
第一次发生在重规划之后：
生成新 Plan
↓
检查新 Plan 是否保留硬条件和无解分支
↓
不符合 → 拒绝替换
“推荐当前综合最优的城市”没有保留天气、预算和延期条件，因此不能成为新的结束步骤。
第二次发生在准备回答之前：
当前证据
↓
信息是否完整？
↓
不完整 → 继续查询
↓
完整后，再检查是否有合格项
↓
有 → 推荐
没有 → 建议延期
苏州票价超时时，它仍然可能合格，结果属于“信息不足”，所以继续查询。
重试得到 360 元以后，三个城市全部不合格，结果进入“无解”分支。Agent 应该回答：
三个城市都无法同时满足天气和预算条件，建议延期。
同一份天气和票价数据，现在得到了正确答案。改变的不是模型会不会比较数字，而是系统重新用用户的 Goal 检查了计划和结果。
正确的做法，是让 Goal 检查两次
用户要求
↓
提取 Goal：成功、无解与停止条件
↓
生成或调整 Plan
↓
用 Goal 检查新 Plan
↓
执行并收集结果
↓
用 Goal 检查最终答案
Plan 可以随着工具结果不断变化，Goal 不能在这个过程中被默认改写。开头那个 Agent 之所以走对了每一步却到达错误的终点，是因为它完成的是后来生成的计划，不再是用户最初交付的任务。
LZ AI Note｜记录现象，追问本质。复杂的事情，简单说。
