01 / 明确允许执行的任务
将客服助手的职责拆为知识问答、订单查询与预约创建。问答可以使用检索增强生成，订单查询依赖已认证用户上下文，预约创建则必须经过参数校验与用户确认。
不要把所有工具暴露给一次模型调用。根据当前业务状态只提供必要动作，工具层再次验证租户、角色和数据范围。
工具返回值应包含可解析的状态码和业务标识，而不是仅有自然语言说明。模型可以解释结果，但不能覆盖底层失败状态。预约完成文案应从工具确认结果生成，并展示用户能追踪的预约编号。
02 / 用确定性状态驱动执行
模型负责识别意图并提取候选字段；状态机负责决定下一步。缺少门店或时间时进入补全状态，时间段不可用时返回可选方案，确认后才允许创建预约。
对每个状态列出允许的事件，例如用户补充信息、工具成功和工具超时。状态变更与任务日志一起持久化，进程重启后按已确认状态恢复；不要通过重读整段对话猜测业务是否已经执行。
type BookingState = "collecting" | "confirming" | "completed";
function canCreateBooking(state: BookingState, confirmed: boolean) {
return state === "confirming" && confirmed;
}
03 / 为工具失败设计体验
工具超时不能被解释为操作成功。保留请求标识并查询实际结果，避免重复创建订单；无法确认状态时明确交接人工。
通过幂等键把一次用户意图与一次实际业务操作绑定。模型重试、网络重传和用户重复点击都应命中同一个结果。
把“请求未发出”“请求已发出但结果未知”“业务明确失败”区分开来。只有第一类可直接重试；第二类先按幂等键查询；第三类根据错误类别要求用户调整参数或转人工。
04 / 评测应覆盖整个任务
除了答案正确率，还要记录工具参数正确率、越权阻断率、人工接管比例及最终任务完成率。测试集中加入越南语口语、混合语言、缺失字段和恶意指令。
本文展示设计方法，示例代码不包含鉴权、存储和真实预约服务，不能直接作为生产实现。
建立固定回归集与持续收集的线上失败集，记录每个样例的预期工具、授权范围和最终状态。变更模型、提示词或知识库后都运行同一批关键任务，比较任务层面的退化。
- 工具执行前独立校验用户、租户和参数。
- 超时先查询结果，不重复触发业务副作用。
- 回归集覆盖多语言、越权请求和人工接管。
AI Agent工程治理
