谁发起任务
出问题时能查到证据，而不是靠猜。
让 AI 会调用工具
从试验脚本到可上线流程
本地脚本跑通，只能证明想法可行；真正上线给用户使用，还要处理输入缺失、工具失败、权限、重复提交、状态、日志、成本和止损。
一句话回答
能跑通，不等于能稳定上线。试验脚本证明想法可行；上线流程要证明这个能力能面对真实用户、异常输入、工具失败、权限限制、重复提交、成本压力和问题追踪。
01 什么叫试验脚本？
prototype
读取客户资料
发送给 AI
AI 判断客户等级
返回结果
试验脚本的目标是验证能力，不是直接承担真实业务。
02 为什么试验脚本不能直接上线？
real world
用户少填信息
API 突然超时
数据库查询失败
模型输出格式错误
同一任务重复提交
用户没有权限
工具调用到一半失败
上线以后最麻烦的，不是正常流程，而是大量“不按预期发生”的情况。
03 第一步：把流程固定下来
fixed flow
接收任务
检查输入
检查权限
准备上下文
调用模型
需要工具？
调用工具
检查结果
生成答案
保存日志
04 第二步：输入一定要检查
input check
用户请求
信息够不够？
不够
先补充信息
正式系统第一件事不是执行，而是先确认输入是否完整。
05 第三步：每一个工具都要考虑失败
failure branch
调用订单 API
成功？
失败：判断原因
重试 / 提示 / 转人工
不能只设计成功路径，也要设计失败以后重试、提示、降级或转人工。
06 第四步：高风险动作要加确认
confirm
AI 判断符合条件
生成操作建议
用户或人工确认
检查权限
执行高风险动作
AI 可以提出动作，但系统必须检查它有没有资格真正执行。
07 第五步：防止重复执行
idempotency
创建工单
实际已成功
返回时超时
Agent 以为失败
再次创建
出现重复工单
重要操作要有唯一任务编号，同一个任务重复请求，不应该造成重复结果。
08 第六步：一定要有状态
task state
查询客户
完成分析
生成方案
邮件发送失败
CRM 尚未更新
长任务执行到一半失败时，系统应该知道从哪里继续，而不是每次从头再来。
09 第七步：要记录日志
traceability
什么时候开始
出问题时能查到证据，而不是靠猜。
调用了哪些工具
出问题时能查到证据，而不是靠猜。
工具返回什么
出问题时能查到证据，而不是靠猜。
哪里失败了
出问题时能查到证据，而不是靠猜。
最终结果是什么
出问题时能查到证据，而不是靠猜。
10 第八步：控制成本
cost guard
简单任务用便宜模型
上线后请求量变大，成本要从流程里被限制住。
复杂任务用强模型
上线后请求量变大，成本要从流程里被限制住。
重复问题走缓存
上线后请求量变大，成本要从流程里被限制住。
无效循环及时停止
上线后请求量变大，成本要从流程里被限制住。
限制 Token 和工具次数
上线后请求量变大，成本要从流程里被限制住。
限制重试和任务时长
上线后请求量变大，成本要从流程里被限制住。
11 第九步：不要相信模型永远按格式输出
output validation
模型可能加废话
即使要求输出 JSON，也可能多出“好的，下面是结果”。
代码必须验证格式
字段名、枚举值、类型和必填项都要检查。
不合格先处理
修正、重试或拒绝进入下一步，不要把脏结果交给业务系统。
程序要消费模型结果，就必须做输出验证。
12 第十步：给流程加保险丝
stop rules
最多执行多少步？
最多运行多久？
最多重试几次？
最多花多少成本？
哪些操作必须确认？
什么时候转人工？
超过边界就停止、保存当前状态，并告诉用户原因。
13 一个完整例子：AI 客服退款流程
refund flow
用户申请退款
确认订单号
查询订单
检查用户身份
读取退款政策
AI 判断
生成退款建议
高金额？
人工确认
调用退款工具
检查结果
记录日志
返回用户
14 Demo 和上线系统最大的区别
demo vs launch
Demo
证明这个想法可以成功跑通一次。
上线
成功、失败、异常、重复、权限、成本都要能处理。
15 上线前先问这 8 个问题
launch checklist
用户少给信息怎么办？
工具失败怎么办？
模型输出错格式怎么办？
任务重复提交怎么办？
高风险动作谁确认？
执行到一半失败怎么办？
成本失控怎么办？
出问题以后能不能查到日志？
本节练习
把一个退款 Demo 改成可上线流程
从“用户说退款 → AI 判断 → 调用退款 API”开始，补齐订单号、身份权限、退款政策、人工确认、结果检查、日志、失败处理和重复保护。
输入订单号、原因、金额是否齐全？
权限当前账号有没有资格操作？
失败工具超时、查不到、无权限怎么办？
重复同一请求会不会执行两次？
日志以后能不能查清发生了什么？
止损超过步数、时间或成本后怎么停？
本节小结
Demo 证明“这个想法能实现”，上线流程证明“这个能力可以放心交给真实用户使用”。
- Demo 只证明能成功一次，上线系统要能处理异常和重复。
- 上线系统第一件事不是执行，而是检查输入是否完整。
- 每个工具、模型输出和高风险动作都要有失败与保护方案。
- 状态、日志、成本限制和止损机制，是 Agent 能长期稳定运行的基础。