44 售后工单 Agent 需求分析
售后工单 Agent 需求分析
写 Agent 代码前，先把售后业务需求讲清楚：分类、知识库、订单、工单、确认和边界。
[TOC]
1. 先把 Agent 想清楚
很多人一听到 Agent，就会想到“让大模型自己决定下一步”。这个理解只对了一半。
在真实项目里，Agent 更像是一个被工程规则约束住的任务执行器：
模型负责理解自然语言、提出候选动作
代码负责权限校验、状态流转、工具执行
业务接口负责最终事实和写操作
日志审计负责事后追踪
没有需求边界就写 Agent，很容易做成一个什么都想管、什么都不可靠的聊天助手。
所以这一阶段的博客不要写成“模型越来越聪明”。更准确的写法是：我们正在学习如何把模型的灵活性放进一个可控的工作流里。
2. 一个业务场景
用户说：“我上周买的设备一直重启，能不能帮我处理？”系统要判断问题类型，查订单，查知识库排障，必要时创建售后工单。
这个场景里面最重要的不是模型能不能说出一段好听的话，而是：
它选了哪个工具
为什么能调用这个工具
参数从哪里来
权限在哪里校验
失败后状态怎么变
用户确认前会不会产生真实写入
把这些问题问清楚，Agent 项目才不会变成一个不可解释的聊天黑盒。
这一节先不急着画 Agent 流程。
售后 Agent 的需求要从业务风险反推：
1. 用户到底要解决什么售后问题：查询政策、查订单、申请售后、催进度
2. 哪些动作只是查询，哪些动作会创建工单或改变订单状态
3. 查询类能力可以让 Agent 自动选择工具，写入类能力必须确认后执行
4. 需求里要写清权限、异常、人工介入和不可处理范围
5. 最后用典型用户话术验证：需求是否覆盖真实表达，而不是只覆盖标准命令
它解决的是需求边界问题：先确定业务能做什么、不能做什么，再设计 Agent 怎么做。
3. 核心概念
1. 问题分类
区分咨询、故障、物流、退款、投诉和转人工。分类不确定时要澄清。
这一点在项目里要落到具体规则：先知道用户要干什么。
2. 知识库检索
用于回答政策、排障步骤和使用说明。检索范围受权限和产品影响。
这一点在项目里要落到具体规则：知识库解决资料问题。
3. 订单查询
查询实时业务状态，必须校验用户身份和订单归属。
这一点在项目里要落到具体规则：订单数据来自业务系统。
4. 工单创建
写操作需要字段完整、用户确认、幂等和审计。
这一点在项目里要落到具体规则：创建前必须确认。
4. 整体流程
graph TD;
A["用户描述问题"] --> B["意图分类"];
B["意图分类"] --> C["缺字段则澄清"];
C["缺字段则澄清"] --> D["查知识库或订单"];
D["查知识库或订单"] --> E["判断是否需要工单"];
E["判断是否需要工单"] --> F["展示工单摘要"];
F["展示工单摘要"] --> G["确认后创建"];
这张图里，模型只是其中一个节点。工具、状态、权限、确认和审计同样重要。
如果一个 Agent 图里只有“用户 -> 模型 -> 答案”，那它还只是 Chat，不是能进入业务系统的 Agent。
5. 落地步骤
1. 写用户故事
按普通用户、客服、管理员分别描述目标和权限。
完成后应该能看到：用户故事清单。
2. 列业务规则
什么情况答复、什么情况建单、什么情况转人工。
完成后应该能看到：规则表。
3. 设计澄清问题
缺订单号、联系方式、问题描述时，一次只问最关键的信息。
完成后应该能看到：澄清模板。
4. 写验收场景
正常、无权限、订单不存在、重复创建、用户拒绝都要覆盖。
完成后应该能看到：Given-When-Then 用例。
6. 状态、接口或工具字段
| 项目 | 说明 |
|---|---|
| intent | 用户意图 |
| requiredFields | 必填字段 |
| permission | 所需权限 |
| nextAction | 下一步动作 |
| fallback | 失败或不确定时策略 |
字段设计要尽量结构化。不要让下游通过一段自然语言去猜“成功了没有”“下一步要干什么”。
7. 示例
用户故事：
作为已登录客户，
我希望描述设备故障后查询自己的订单，
并在确认后创建售后工单，
以便获得后续处理。
验收：未登录不能查订单；创建前必须展示摘要；拒绝确认不创建工单。
示例里的字段不一定照搬，但思想要保留：输入、状态、输出、错误和审计信息要分开。
8. 哪些事不能交给模型自由发挥
模型不能自行决定用户有权查询哪个订单，也不能直接创建工单。订单归属、可售后状态和重复工单都由业务服务判断。
这一节特别重要。Agent 项目最容易踩坑的地方，就是把“理解意图”和“执行业务动作”混成一件事。
模型可以建议动作，但最终执行必须经过代码和业务系统的规则。
9. 测试路径
建议至少准备下面几类测试：
正常路径：输入完整，工具正常返回
缺字段路径：订单号、联系方式、问题描述不完整
权限路径：查询别人的订单、访问无权知识库
失败路径：工具超时、模型输出非法、检索为空
恢复路径：等待确认时服务重启、重复确认、超时确认
Agent 的测试不能只看最终回答。你要检查状态、工具调用、审计日志和是否产生真实副作用。
10. 工程取舍
- 需求阶段先做少量核心意图，不要一次覆盖所有售后场景。
- Mock 数据可以先行，但接口契约要按真实业务设计。
- 用户确认会多一步交互，但能降低误操作。
取舍讲清楚以后，读者才能知道你为什么这样设计，而不是以为所有问题都要上 Agent。
11. 常见坑
- 先画 Agent 图，后补业务规则。
- 分类结果被当成绝对正确。
- 只校验订单号，不校验归属。
- 工单字段由模型随意生成。
这些坑本质上都和一个问题有关：没有把模型输出当成“不可信的候选结果”。
12. 验收清单
- ☐ 角色和权限明确
- ☐ 核心意图有验收场景
- ☐ 写操作需要确认
- ☐ 异常和转人工规则明确
- ☐ 需求不依赖模型自由发挥
如果这些检查项没过，先不要急着加更多工具。工具越多，边界越乱，排查越难。
13. 落地清单
- ☐ 写 5 条售后用户故事
- ☐ 列出工单必填字段
- ☐ 设计缺字段澄清流程
- ☐ 写 6 个验收场景
练习时可以先用 Mock，不要一开始就连真实订单或工单系统。等状态、权限和幂等设计清楚后，再接真实接口。
14. 小结
Agent 不是从代码开始的。业务边界越清楚，后面的 State、Node、Tool 才越稳定。
Agent 的价值来自灵活性，但安全来自边界。能把这两件事同时讲清楚，才算真正理解 Agent 工程化。