延伸：从 RAG 到客服 Agent

一句话： 给助手配上课程状态查询、订单查询、创建工单等工具，只读的 RAG 系统就变成了客服 agent；而每一个会改变数据的工具，都会带来权限、确认和审计的要求。

加上工具后发生了什么变化

RAG 助手只能复述文档里写的内容。但很多真实的客服问题需要某个人的实时数据：“我的报名确认了吗？""我的退款到哪一步了？""能把我调到周六的班吗？“文档回答不了这些问题，工具可以。

这一步在代码上很小，在后果上很大。工具分为两类，风险集中在第二类：

工具类型	示例	新增要求
读工具	课程状态、订单状态、课表查询	查询前先确认用户身份；只返回这个用户的数据
写工具	创建工单、申请退款、调班	执行前和用户确认；重复调用必须安全；记录谁请求了什么

读工具返回了另一个学生的记录，就是隐私事故。写工具因为模型重试被调用了两次，就是重复退款。这两种失败都源于把工具当成了文档。

一次只加一个工具

从今天最常导致转人工的问题入手，给助手一个能回答它的读工具。然后衡量它减少了多少转人工。只有当读工具已经可靠、并且有人签字确认了确认环节之后，才加写工具。

升级通道保留。客服 agent 能处理的情况比 RAG 助手多，但它仍然要把自己无权决定的事情转交出去。

怎样设计一个好工具

工具是给模型用的接口，所以它需要和给人用的界面同样用心：

• 清晰的名称和描述，说明什么时候该用、什么时候不该用。
• 少量、类型明确的输入。 接收学生 ID 和课程代码的工具，比接收任意文本的工具更难被误用。
• 有用的错误信息。 “找不到该学生；请让用户确认邮箱”能帮助模型恢复，一段报错堆栈不能。
• 精简、相关的输出。 只返回回答需要的内容，而不是整行数据库记录。

常见误区

• “工具只是另一个知识来源。” 文档对所有人都一样，工具的结果属于某一个人，必须限定在这个人的范围内。
• “模型只会在合适的时候调用工具。” 写工具需要确认环节和安全重试，而且要用代码强制，而不是写在 prompt 里。
• “有了工具，就该变成多 agent。” 工具和 agent 是两个独立的选择。一个 agent 配几个设计良好的工具，通常才是正确的下一步。

典型面试题

客户希望助手直接办理退款。你首先要做哪些准备？

任何查询前先识别用户身份；设置确认环节，向用户明确展示将要发生的事；用幂等键保证重试的调用不会重复退款；设定一个金额上限，超过需人工批准；并对每次调用记审计日志。然后先对一小部分用户上线，并复查日志。

怎么决定先做哪个工具？

看 RAG 版本的转人工日志。最常见的、一次只读查询就能解决的转人工原因，就是第一个工具。它以最小的新增风险，最大幅度地减少人工工作量。

延伸阅读

• 文档：Tool use overview（Claude 文档）
• 文章：Writing effective tools for agents（Anthropic）

相关页面

• 案例概览：辅导 / 客服 RAG
• 参考实现：n8n 版客服 RAG，第一版的边界
• 案例概览：内容运营，上一级阶梯

Syllabus 行：M6-L1.5