Appearance
很多团队上线AI Agent产品之后，发现一个规律：内部演示时完成率能到90%，真实用户用了一周，完成率跌到40%以下。问题出在哪？不是工具本身，是规划。
工具少但规划严密的Agent，复杂任务完成率稳在80%以上；工具多但规划乱的Agent，完成率在40%到60%之间随机飘。
以订火车票这个日常例子，把Agent从接到任务到最终完成的完整过程拆成10步，说清楚每步在做什么、为什么必须做、不做会出什么问题。
01 需求解析：听懂你到底要什么
Agent接到"帮我订明天北京到上海的高铁，7点前出发，靠窗"这句话后，第一件事不是查票，而是先整理成一张清单：
硬条件（必须满足）：
- 出发地：北京 ✓
- 目的地：上海 ✓
- 出发日期：明天 → 2026-04-28
- 时间：7点前出发
软要求（可以降级）：
- 座位偏好：靠窗 → 找不到可换靠过道
这两类要求的区别很关键。 硬条件不满足，任务直接终止；软要求不满足，可以降级处理但要告诉你。如果不区分，Agent遇到没有靠窗座位时就会直接报失败，而不是换一个座位继续帮你买。
02 可行性判断：先确认这件事能不能做
要求理清楚后，下一步不是立刻执行，而是先判断这件事能不能完成。
订票任务有三个前提必须都满足：
- 能查到票（能访问12306或第三方票务系统）
- 有你的实名信息（身份证已录入）
- 你授权了它替你付款
这三个缺任何一个，都要现在告诉你，而不是等做到一半才说。
用户不怕你做不到，怕你做不到还不说清楚。 能明确说清楚做不了、原因在哪、建议怎么调整的Agent，用户满意度比直接静默失败高出约60%。
03 任务拆解：把大目标拆成一个个小步骤
确认可以做了，把订票这个大目标拆成可以一步一步执行的具体动作：
- 查询2026-04-28北京到上海7点前的高铁车次
- 从查到的车次里，筛出有靠窗余票的
- 调出你的实名信息（姓名和证件号）
- 把可选车次展示给你，等你确认选哪趟
- 按你选的车次和你的实名信息，下单付款
- 查订单有没有出来，把订单详情告诉你
漏掉任何一步，后面必然出问题。 其中步骤4（让用户确认）是不能省的——订票要花钱，必须让你确认选哪趟，Agent不能替你自动选好直接买。
老王分析过大量Agent失败日志，约35%的失败根源是拆步骤时漏掉了某一步，最常见的两个：让用户确认，以及查订单是否成功。
04 依赖排序：搞清楚哪些步骤有先后顺序
这六步不是随便哪个先做都行，必须搞清楚谁依赖谁：
- 步骤2筛余票，必须等步骤1查车次列表出结果
- 步骤3取实名信息，和步骤1、2没关系，可以同时进行
- 步骤4让你确认，必须等步骤1、2、3都做完
- 步骤5下单，依赖步骤4你的选择+步骤3的实名信息
- 步骤6查订单，必须等步骤5完成
聪明做法：步骤1和步骤3同时启动，步骤1出来后再做步骤2，之后一路串行。
这样实测下来，全部排队串行约14秒，合理安排并行后约9秒，快了约36%。这个差别在高频任务里直接影响用户体验。
05 工具规划：给每个步骤配好工具和参数
步骤顺序定了，下一步是给每个步骤确定用哪个工具来做、需要填哪些参数、参数从哪来。
| 步骤 | 工具 | 参数来源 |
|---|---|---|
| 1 查车次 | 查车次接口 | 出发地、目的地、日期、最晚出发时间（来自步骤1解析） |
| 2 筛余票 | 查余票接口 | 步骤1的车次列表+座位类型靠窗 |
| 3 取实名 | 取用户信息接口 | 用户ID（系统自动获取） |
| 4 等确认 | Agent自己整理 | - |
| 5 下单 | 下单接口 | 步骤4你的选择+步骤3的实名信息 |
| 6 查订单 | 查订单接口 | 步骤5返回的订单号 |
一个重要细节： 步骤5的车次选择，必须来自步骤4里你的确认结果，而不是系统自动取步骤2筛出来的第一条。这个区别在规划阶段就必须写死。
另外每个步骤最好有备用工具。 主工具挂了或超时，立刻切换到备用的。
06 计划固化：把整个计划写成执行手册
前面几步把任务拆清楚了，现在要把结果固定下来，变成一份正式的执行手册。
这份手册里每一步都要写清楚：
- 这一步叫什么名字、编号是多少
- 用哪个工具、参数从哪来、期待拿到什么结果
- 前面必须先完成哪几步
- 能不能和其他步骤同时跑
- 等多久算超时
- 出了问题怎么重试
数据说话：
| 方式 | 5步以上任务完成率 |
|---|---|
| 提前写好执行手册 | 83%-88%（稳定） |
| 每步靠AI临时决定 | 50%-72%（波动） |
波动是前者的3倍以上。 原因很简单：AI在处理长对话时越往后越容易忘事。把计划提前写死成手册，执行时不需要AI再实时推理，不稳定性就消除了。
07 状态追踪：执行的同时实时记进度
手册准备好，开始执行。执行时不只是一步一步做，还要同步维护一张进度表。
这张进度表记四件事：
- 每一步现在是什么状态（还没开始/进行中/已完成/失败）
- 每一步做完之后拿到了什么结果
- 每一步花了多少时间
- 失败的话，具体是什么错误
订票任务做到步骤4时，进度表长这样：
- 步骤1，已完成，查到3趟车（G101 05:32/G201 06:08/G301 06:45），用时1.2秒
- 步骤2，已完成，G101靠窗无票，G201靠窗余9个，G301靠窗余23个，用时0.8秒
- 步骤3，已完成（和步骤1同时跑），实名信息已拿到，用时0.5秒
- 步骤4，进行中，等你从G201和G301里选一趟
- 步骤5、6，还没开始
进度表有两个不可替代的用处：
第一，步骤之间传信息。步骤5需要你选了哪趟车和实名信息，这些都得从进度表里拿。
第二，出了问题知道从哪继续。步骤5失败了，进度表能精确告诉程序问题在哪，前面4步的结果不需要重新跑。
08 结果验收：每做完一步，先验收一下结果
每一步做完，不是直接往下走，而是先判断结果符合要求吗。
判断结果不是只有成功或失败两种，而是三种：
- 完全符合 - 所有要求都满足，按计划继续
- 部分符合 - 必须满足的条件满足了，软要求没满足，继续往下走但要告诉你
- 不符合 - 必须满足的条件没达到，或执行出错，需要调整后重来
订票案例的验收节点：
- 步骤1查出来0趟车 → 7点前没车，现在就告诉你，问要不要调时间
- 步骤2查出来G101没靠窗余票，G201和G301有 → 继续做，但步骤4只展示G201和G301
- 步骤5下单失败 → 提示支付授权过期，引导你重新授权后再继续
老王遇到很多Agent不做这个验收，步骤1查出来0条结果，直接进步骤2，步骤2因为没有任何车次而报错，错误信息和真正原因完全对不上。查这种问题往往要翻4到6步的日志才能找到根源。
09 容错重规划：遇到问题不直接放弃，先想想能不能绕过去
执行中途出了问题，Agent不应该立刻
