用户任务
分析这个客户值不值得重点跟进。
让 AI 会调用工具
串行、并发与失败重试：Agent 怎么把任务跑得又快又稳
上一节我们讲了：复杂任务要先拆步骤，再决定调用哪些工具。任务拆开以后，还要判断哪些步骤要按顺序做，哪些可以同时做，以及工具失败后怎么办。
一句话回答
有先后依赖就串行，没有依赖就并发；偶发失败可以重试，但不能无限重试。执行类工具还要特别防止重复执行。
01 什么是串行？
serial
查询订单
获得物流状态
判断是否异常
如果异常
创建客服工单
后面的动作依赖前面的结果，这种上一步决定下一步的任务，就适合串行。
02 再举一个更简单的例子
need params
查询客户
获得客户 ID
查询客户订单
获得订单号
查询物流
后面的工具需要前面的结果作为参数，所以不能跳着来。
03 什么是并发？
parallel
查询 CRM
查询历史订单
查询沟通记录
AI 分析
三个查询互不依赖，可以一起做，再汇总给 AI 分析。
04 为什么要并发？
faster wait
全部串行
2 + 3 + 4 = 9 秒每一步都等上一项完成，用户等待更久。
合理并发
约 4 秒互不依赖的查询同时跑，整体接近最慢那一步。
05 但不是所有任务都能并发
dependency test
需要上一步结果
查询物流需要订单号，订单号还没拿到，就必须串行。
不需要上一步结果
CRM、历史订单、沟通记录互不依赖，可以考虑并发。
06 一个任务里可以同时有串行和并发
mixed workflow
找到客户
并发查询资料
汇总结果
AI 分析
判断高意向
创建跟进任务
该一起做的时候一起做，该等结果的时候就等结果。
07 工具调用一定会成功吗？
real systems fail
API 超时
网络异常
数据库暂时连接失败
第三方服务繁忙
请求频率过高
工具临时不可用
08 什么叫失败重试？
retry
查询物流
超时
等待
重新查询
返回物流信息
09 为什么不能失败一次就放弃？
temporary errors
很多错误只是暂时的
网络刚好抖了一下、第三方接口刚好繁忙、请求刚好超时。对这类临时问题，合理重试能明显改善体验。
10 但也不能无限重试
retry limit
第一次失败
稍后重试
第二次失败
再次尝试
第三次仍失败
停止并换方案
重试是解决偶发错误，不是死磕一个永远不会成功的任务。
11 什么错误适合重试？
classify error
网络超时
可以重试
服务暂时繁忙
可以重试
临时连接失败
可以重试
参数错误
先修正参数
数据不存在
通常不重试
没有权限
不重试
用户信息不足
询问用户
12 重试最好不要马上疯狂请求
backoff
第一次失败：等一下
第二次失败：再多等一会
第三次失败：停止
服务忙的时候，不要疯狂敲门，稍微等一下再试。
13 特别小心执行类工具的重试
side effects
查询类
查天气、查物流、查订单，失败后再查一次通常风险较低。
执行类
创建订单
发送邮件
扣款
退款
删除数据
如果其实已经成功，只是返回时超时，盲目重试可能造成重复执行。
14 怎么避免重复执行？
idempotency
生成唯一任务编号
提交请求
网络超时
再次提交同编号
后台识别已执行
不重复执行
同一个操作重复请求，不应该造成重复结果。点两次退款，也不能真的退两次钱。
15 某一个工具失败，要不要整个任务失败？
degrade
CRM 资料
成功
历史订单
成功
聊天记录
失败
非关键资料暂时失败时，可以说明限制并降级继续，而不是让整个任务全部失败。
16 Agent 应该学会几种失败后的选择
next action
重试
换备用工具
问用户
降级继续
转人工
17 一个完整的例子
full run
并发查询资料
处理失败
汇总资料
AI 分析
判断高意向
创建跟进任务
检查结果
完成
18 为什么这些东西很重要？
stable agent
任务拆解
串行 / 并发
工具调用
结果检查
失败判断
重试 / 降级 / 询问 / 转人工
最终完成
真正难的不是成功时怎么运行，而是现实没有按照预期运行时怎么办。
本节练习
给一个 Agent 流程补稳定性
把“分析张先生，如果高意向就创建跟进任务”标出串行、并发、失败重试、降级和转人工点。
串行哪些步骤必须等结果？
并发哪些资料可以一起查？
重试哪些临时错误可再试？
止损什么时候停止或转人工？
本节小结
- 后一步依赖前一步，就串行执行。
- 几个任务互不依赖，可以并发执行，提高速度。
- 临时错误可以重试，但要限制次数并适当等待。
- 查询类重试相对简单，执行类工具必须防止重复执行。