跳到主要内容

第 1.6.1 节：先判断哪些业务动作值得交给工具

进入实现之前，先围绕“先判断哪些业务动作值得交给工具”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出业务动作值得交给工具的适用场景、不适用场景、前置条件和进入工程实现的判断标准。

任务卡内容
本节任务判断客服场景里哪些业务动作值得做成工具。
你会产出一张“业务动作工具化判断表”。
使用场景查订单、查售后政策、创建工单、投诉、退款申请、转人工。
完成标准每个业务请求都有推荐处理方式、工具需求、审批需求和判断理由。

新手最容易把“能让模型回答”和“应该让模型执行”混在一起。客服 Agent 里至少有四种处理方式：

处理方式适合什么问题不适合什么问题
模型直接回答总结、改写、解释通用流程、整理用户诉求。涉及实时业务状态、账号数据、资金动作的问题。
RAG 检索回答售后政策、产品说明、FAQ、公司制度。用户私有订单、工单状态、需要写入系统的动作。
工具调用查订单、查工单、创建工单、提交审批、发送通知。高风险动作不能绕过审批直接执行。
人工审批或转人工退款、补偿、敏感投诉、规则冲突、资料不足。低风险、可自动查询的普通问题。

判断边界时先问三个问题：

  • 这个请求是否需要读取业务系统里的实时或私有数据？
  • 这个请求是否会改变业务状态，例如创建工单、发送通知、提交审批？
  • 这个请求是否涉及资金、合规、投诉或不可逆后果？

只要答案进入实时数据、写入动作或高风险后果，就不能只靠模型自由回答。

实现步骤或决策流程​

按下面 5 步做，不要从“我要做几个工具”开始。

  1. 把用户原话改写成业务请求，例如“查物流”“申请退款”“投诉客服”。
  2. 判断需要的数据来源：模型常识、知识库资料、业务系统、人工判断。
  3. 判断是否会写入或触发外部动作。
  4. 标出风险等级：只读、写入、高风险审批。
  5. 写出判断理由，避免只写“需要工具”这种空结论。

可复制模板​

## 业务动作工具化判断表

| 业务请求 | 推荐处理方式 | 是否需要知识库 | 是否需要工具 | 是否需要人工审批 | 判断理由 | 下一步产物 |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

示例填写​

业务请求推荐处理方式是否需要知识库是否需要工具是否需要人工审批判断理由下一步产物
我的订单什么时候发货？工具调用否是否需要读取当前用户订单和物流状态，模型不能猜。查订单状态工具契约
你们退货周期是多久？RAG 检索回答是否否答案必须来自最新售后政策。售后政策知识来源说明
帮我申请退款工具调用 + 人工审批是是是需要查订单和政策，但资金相关动作不能自动完成。退款审批工具契约
我要投诉客服态度工具调用 + 人工处理否是是需要创建投诉工单并记录证据，不能只安抚。创建投诉工单工具契约

新手自查清单​

  • 我有没有把“能聊天回答的问题”和“必须查业务系统的问题”分开？
  • 我有没有标出哪些动作会写入数据或影响资金？
  • 我有没有给退款、补偿、投诉等高风险动作设置人工审批？
  • 我有没有写清判断理由，而不是只写“需要工具”？
  • 我有没有把 RAG 检索和工具调用混成同一种能力？

本节交付物与面试讲法​

本节交付物是一张“业务动作工具化判断表”。合格标准是至少覆盖 8 个客服请求，并且每个请求都能说明为什么交给模型、知识库、工具或人工审批。

面试时可以这样讲：

我不会一上来就把所有客服问题都做成工具。我会先把用户请求拆成业务动作，再判断它是否需要实时业务数据、是否会写入系统、是否涉及资金或投诉风险。比如查订单必须走工具，退货周期应该走知识库，退款申请只能发起审批，不能让 Agent 直接退款。

继续学习​