「帮我给爸妈买一台 3000 元以内、噪音小的洗衣机，周末送到老家，别买延保」。这句话里有四个硬约束、一个模糊约束（噪音小）、一个明确排除项。九个工具可用，线上灰度里 32% 的会话出现计划跑偏——比如先下单再查配送，18% 卡在工具报错后循环重试直到超时。
多数候选人的第一反应是「让规划器更准」。可这道题问的不是规划器，是当计划会出错时，产品给用户留了什么。计划一定会出错，因为环境会变、用户会改主意、第三方接口会挂。
本系列第 2/10 篇 · 上一篇：Agent 的能力边界，不是一句「高风险要确认」 · 下一篇：检索对了 78%，答案引用还是错
计划骨架：先冻结约束，再展开细节
先把这句话拆成两层。约束层是全局的，全程不变：预算 ≤ 3000、配送到老家且周末可达、不买延保、噪音偏好可量化为分贝或「静音」标签。执行层才是步骤。
| 步骤 | 依赖 | 可否并行 | 完成条件 |
|---|---|---|---|
| s1 结构化约束 | 无 | — | 四个硬约束都有明确取值，模糊项已转成可筛条件 |
| s2 商品搜索 + 参数筛选 | s1 | 与 s3/s4 并行 | 候选集 ≥ 3 且全部满足价格、配送 |
| s3 评论摘要（噪音） | s1 | 并行 | 每台候选有噪音相关证据 |
| s4 比价 + 券后价 | s1 | 并行 | 券后价 ≤ 3000 |
| s5 库存与配送时效校验 | s2 | — | 周末可达且地址可送 |
| s6 候选集汇总 → 用户确认 | s3/s4/s5 | — | 用户选定一台，或提出修改 |
| s7 领券 → 下单 → 支付 | s6 | 顺序，且幂等 | 订单号生成 |
| s8 售后预约 | s7 | — | 可选，首期可砍 |
必须在 s6 之前冻结的是约束快照和候选集快照，不是整份计划。冻结约束，是为了后面十几轮工具调用里它不会随上下文漂移；冻结候选集，是为了用户确认的那台和他最终买的那台是同一台、同一个价。价格会变，所以 s7 之前还要重算一次券后价，越界就停下来问，而不是默默按新价下单。
「先下单再查配送」这类跑偏，根因通常不是模型笨，是计划里没有把 s5 写成 s7 的前置依赖，或者写了但没写 done_when。产品侧能做的，是要求每个不可逆动作在计划阶段就带上可判定的前置条件——这和上一篇的 requires_confirmation 是同一条思路：把概率判断搬到确定性结构上。
中途改一个约束，不要重跑全流程
用户说「改成 3500 吧」。最糟的实现是把 s1 到 s8 全部作废重来，前面三十秒白等，评论摘要和比价也跟着重算。
我的做法是给计划加 plan_version，并给每步声明它消费了哪些约束：
- 预算变了 → 只影响 s2 的价格筛选与 s4 的券后价；s3 的噪音证据、s5 的配送时效与地址校验可以复用。
- 地址变了 → s5 必须重跑，s2/s3/s4 的商品候选可复用，但要重新过滤可送区域。
- 用户换了一台具体型号 → 从 s3 起重跑该分支，其余并行分支不动。
界面上不出现「正在重新规划」这种黑盒提示，而是「已按 3500 元更新，另外两项检查结果仍然有效」。用户看到的不是重算，是哪些结论还作数。这里有个容易被忽略的细节：改约束时要把旧的候选集保留一个可回看的快照，用户常常会问「刚才那台呢」。
工具连续失败两次，产品状态该怎么切
18% 的会话卡在循环重试，本质是产品没有给「失败」一个用户可见的状态。我要求区分三类失败，并且同一工具连续失败 2 次后，禁止静默重试：
| 失败类型 | 用户看到什么 | 可选项 |
|---|---|---|
| 暂时不可用（超时/限流） | 「配送时效暂时查不到，其余结果已经好了」 | 稍后重试 / 跳过此步继续 / 转人工 |
| 参数不成立（该地址不可送） | 「这个地址周末送不到，要不要换日期或换地址」 | 改约束 / 换候选 |
| 能力缺失（没有该数据） | 明确说这项无法核验，并把它从结论里标成未确认 | 带着缺口继续 / 放弃 |
三个选项里，「跳过此步继续」必须真的能继续，且结果里永久带着一个「未核验」标记，不能到了下单页才甩出来。循环重试之所以让用户放弃，不是因为失败本身，是因为他不知道还要等多久、也不知道自己在等什么。
计划透明到什么粒度
我给算法同学的那版「隐藏计划、只给结果」留了一个折中：首屏只显示阶段进度，细节可展开。用户看到 3–5 个阶段（正在找符合要求的机型 / 核对配送 / 等你确认），不暴露工具名、参数、重试次数。约束做成顶部可编辑的 chips，点一下改预算，就是上一节的增量重算。
分档依据是任务的不可逆程度：只读任务只给一句进度，涉及下单的任务必须在 s6 展开完整的候选对比和依据。透明不是越多越好，用户要的是「能改」和「知道它在等我」，不是看执行日志。
至于砍哪个工具，我砍 s8 售后预约。它在下单前没有任何决策价值，却多一次调用、多一个失败点，还会让用户觉得「还没买就开始谈售后」。预期任务成功率略升（少一个失败点），下单转化不至于受损，甚至可能因为流程更短而略升；验证看「到支付页的转化率」和「单任务工具调用数」，如果转化率反而掉了，说明它承担了信任建立的作用，再加回来。敢给一个可能被数据打脸的判断，比说「都保留、让用户选」强。
追问：算法希望隐藏计划
我不会用「用户有权知道」这种话去压。先问清楚他担心的是哪种干扰：是进度文字刷屏，还是用户看到中间步骤会反复插嘴改需求。前者用折叠解决，后者恰恰是产品想要的——中途改约束比买错了再退货便宜得多。
决策方式可以很干脆：按任务风险分档做 A/B，只读任务隐藏、交易任务展开，看「中途修改率」和「下单后 24 小时取消率」。如果两个指标方向相反，以取消率为准，因为退货成本远高于多显示两行字。这是产品决策，不是审美偏好，所以要交给业务指标判。
我会怎么看答案
及格：画得出步骤顺序，说「要让用户可干预」。良好：能区分约束层和执行层、能写出依赖与完成条件、能处理工具失败。优秀：给出增量重算而非全量重跑、把失败做成有出口的状态、对透明化粒度给出分档依据并说明怎么验证。
最典型的失分是把这道题答成技术方案：调规划器、加重试、上更好的模型。产品岗要交的是状态机、交互和取舍，不是调度算法。
计划的价值不在于一次算对，而在于算错以后，用户只需要改那一处。
计划和工具都能跑通了，下一个问题更隐蔽：材料明明检索到了，答案引用的却是作废版本。
评论