客服数字员工实战：搭一个能查能改能闭环的 Agent

很多公司上了 AI 客服，用下来体验不怎么样——不是因为模型不好，而是只做到了"答 FAQ"就停了。用户问"我的快递到哪了"，它答一堆标准话术；用户问"能帮我改一下收货地址吗"，它回一句"请联系人工客服"。这种 Agent，说白了就是个带检索的 FAQ 机器人，没给真正的业务价值。

真正值钱的客服 Agent 是另一个样子：能查能改能闭环。用户问订单状态，它去查；用户要改地址，它去改；用户要退款，它走流程；搞不定的，它主动转人工——而且交接时把上下文带过去，不让用户重复说一遍。

这一节就讲这个怎么搭。不是大厂才能玩，中小团队接了业务系统 API 就能做到。

---

一个"真会干活"的客服 Agent 能做什么

对比一下两个版本，差距一目了然：

能力	FAQ 机器人	能查能改能闭环的 Agent
回答标准问题	有，靠关键词匹配或向量检索	有，用 RAG 答知识库问题
查订单状态	无，让用户自己去 APP 查	有，调工具查真实订单数据
修改收货信息	无，转人工	有，调工具写入业务系统
退款申请	无，转人工	有，小额自动走流程，大额走审批
多轮上下文	弱，每句话都要重复	强，记得你刚才说的什么
搞不定转人工	要么没有，要么死板触发	有，带完整上下文交接

第一类你去买标准 SaaS 就够用。第二类要自己搭——但也没那么难，核心是把四个层次都搭全，缺一层都会出问题。

---

客服 Agent 的四层架构

架构/流程图（文字版）

用户输入
   │
   ▼
┌─────────────────────────────────────────────────────┐
│  意图识别 + 上下文管理（多轮对话 messages 历史）        │
│  ┌──────────────────┐   ┌──────────────────────────┐ │
│  │  知识库 RAG 层    │   │  业务工具层（Tool Use）  │ │
│  │  ・产品说明       │   │  ・query_order           │ │
│  │  ・退换货政策     │   │  ・update_address        │ │
│  │  ・常见 FAQ       │   │  ・submit_refund         │ │
│  └──────────────────┘   └──────────────────────────┘ │
│                 ↓                  ↓                   │
│            模型决策：用 RAG 答 / 调工具 / 问用户 /      │
│            判断是否超出权限边界 / 是否需要升级           │
└─────────────────────────────────────────────────────┘
   │                          │
   ▼                          ▼
直接回答用户              升级转人工
（带工具执行结果）         （带完整上下文摘要）

四层逐一说清楚：

第一层：知识库 RAG——用来答不需要查系统的问题，比如退货政策、尺码说明、配送时效、售后流程。你把这些文档做成向量索引，用户问的时候检索最相关段落塞进上下文，模型用这段话来回答，不靠记忆、不瞎编。关于 RAG 的基本原理可以先看术语库，这里我们重点讲怎么和工具层配合。

第二层：业务工具层——这是和只答 FAQ 的本质区别。查订单、改地址、提退款——这些都是写好的函数，模型决策要调哪个、传什么参数，函数去真实系统执行。AI Agent 的工具调用机制保证了这些操作是确定性的，不是模型"猜"出来的。

第三层：多轮对话与上下文管理——用户不会一句话说清所有情况。"帮我退货"——退哪个订单？啥问题？这种多轮澄清全靠 messages 历史列表跟着走。同一次会话里，Agent 知道你刚才说了什么，不用你重复。

第四层：升级机制（Human-in-the-loop）——这层很多团队做不到位。正确姿势是：模型主动判断搞不定的场景（投诉、复杂纠纷、大额退款、用户明确说要人工），触发 escalate_to_human 工具，把带摘要的完整对话历史转给人工坐席，坐席打开就知道发生了什么，不用用户重讲。

---

关键工具定义示例

下面是三个核心工具的 schema 定义，可以直接用在 Claude Agent SDK 或兼容工具调用的框架里。

工具列表定义

tools = [
    # ── 工具 1：查订单状态 ──────────────────────────────
    {
        "name": "query_order",
        "description": (
            "查询订单的实时状态，包含物流信息、配送进度、预计到达时间。"
            "当用户询问订单在哪、快递到了吗、发货了没有时使用。"
            "需要用户提供订单号或先确认用户身份。"
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "订单号，格式如 ORD-20240601-001"
                },
                "user_id": {
                    "type": "string",
                    "description": "用户 ID，用于鉴权，确认订单归属"
                }
            },
            "required": ["order_id", "user_id"]
        }
    },

    # ── 工具 2：修改收货地址 ────────────────────────────
    {
        "name": "update_shipping_address",
        "description": (
            "修改订单的收货地址。仅在订单状态为'待发货'时可操作，"
            "已发货的订单无法修改地址，需走拦截或退货流程。"
            "修改前必须向用户确认新地址，获得明确确认后才能调用此工具。"
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "description": "订单号"},
                "user_id": {"type": "string", "description": "用户 ID，用于鉴权"},
                "new_address": {
                    "type": "object",
                    "description": "新收货地址",
                    "properties": {
                        "province": {"type": "string"},
                        "city": {"type": "string"},
                        "detail": {"type": "string", "description": "详细地址含门牌"},
                        "recipient": {"type": "string", "description": "收件人姓名"},
                        "phone": {"type": "string"}
                    },
                    "required": ["province", "city", "detail", "recipient", "phone"]
                }
            },
            "required": ["order_id", "user_id", "new_address"]
        }
    },

    # ── 工具 3：提交退款申请 ────────────────────────────
    {
        "name": "submit_refund_request",
        "description": (
            "提交退款或退货申请。小额退款（<=200元）可直接受理，"
            "大额退款（>200元）会进入人工审核队列，不会立即到账，"
            "必须提前告知用户审核时间。提交前必须确认用户理解退款规则。"
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "user_id": {"type": "string"},
                "reason": {
                    "type": "string",
                    "description": "退款原因，如：质量问题/不想要/发错货/描述不符"
                },
                "amount": {
                    "type": "number",
                    "description": "申请退款金额，单位元"
                },
                "evidence_urls": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "凭证图片 URL 列表，质量问题必须上传"
                }
            },
            "required": ["order_id", "user_id", "reason", "amount"]
        }
    },

    # ── 工具 4：升级转人工 ──────────────────────────────
    {
        "name": "escalate_to_human",
        "description": (
            "当问题超出 Agent 处理能力时转接人工客服。触发条件包括："
            "用户明确要求人工、投诉类问题、大额争议无法自动处理、"
            "Agent 连续两轮无法解决用户问题。"
            "转接时会自动附上本次对话摘要，坐席无需用户重复说明。"
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "reason": {
                    "type": "string",
                    "description": "转人工原因，会附在工单上"
                },
                "priority": {
                    "type": "string",
                    "enum": ["normal", "urgent"],
                    "description": "优先级，投诉类填 urgent"
                },
                "context_summary": {
                    "type": "string",
                    "description": "本次对话摘要，帮助坐席快速了解情况，100字以内"
                }
            },
            "required": ["reason", "priority", "context_summary"]
        }
    }
]

权限边界：哪些操作要人工确认

不是所有工具都能"自动就执行"，需要在 system prompt 里明确划边界：

SYSTEM_PROMPT = """
你是一名客服数字员工，代表公司处理售后问题。

## 可以直接执行的操作
- 查询订单状态、物流信息
- 回答产品说明、政策类问题（用知识库）
- 小额退款（<=200元）受理

## 执行前必须先向用户确认的操作
- 修改收货地址：读出新地址让用户确认后再调工具
- 退款申请：告知预计到账时间、审核说明，用户确认后再提交

## 必须转人工的场景
- 用户明确说"我要投诉"或"找人工"
- 大额退款（>200元）有争议
- 连续两轮没能解决用户问题
- 涉及法律纠纷或消费者维权

## 严禁
- 不能承诺"保证退款""一定赔偿"等无法确定的结果
- 不能在没有确认订单归属的情况下查询或修改订单
- 不能捏造物流信息或政策条款
"""

这段 system prompt 就是权限边界的落脚点。模型不会自己"猜"该不该执行——你在 system prompt 里写清楚了，它就照着走。

---

落地三阶路径

不要一上来就全自动。这是很多团队踩坑的地方——功能没跑稳就开全自动，出了问题满地救火。推荐分三阶：

第一阶：只答问题（2 周能上）

目标：把知识库接好，答 80% 的常见问题，出错了有兜底。

• 整理 FAQ、产品文档、退换货政策做成向量索引
• 接入对话入口（网页/APP/微信）
• 系统提示词里写清楚：不知道的直接说"帮您转人工了解"，不瞎猜
• 配置兜底转人工（用户连续问了 3 句没答好，自动转）

验收标准：常见问题答对率 ≥85%，没有乱承诺的回答，转人工入口畅通。

第二阶：能查能改（1 个月内可落地）

目标：接入业务系统 API，查订单、改地址、提退款真能干。

• 和研发联调：拿到查单 API、改地址 API、退款 API 的接口文档
• 写好工具函数，加鉴权和参数校验
• 上线前跑沙箱测试：每个工具用真实用例测 20 条
• 先灰度：只给 10% 用户开放，观察一周，没大问题再全量

验收标准：查单准确，改地址成功率 ≥95%，退款提交 0 异常，转人工率从第一阶降低 30%+。

第三阶：全自动闭环（稳定后推进）

目标：覆盖 90%+ 的常见售后场景，人工主要处理投诉和异常。

• 完善 Human-in-the-loop：转人工时带完整上下文，坐席界面接收工单
• 加主动通知：物流异常时 Agent 主动给用户发消息
• 建反馈闭环：坐席处理完的工单，拿来反标知识库和工具边界
• 定期跑 非确定性评测，发现能力退化及时处理

验收标准：全自动解决率 ≥70%，CSAT（满意度）不低于人工客服同期水平，大额争议 0 漏转人工。

---

故障排查/避坑表

症状	根因	解法
Agent 乱承诺"保证退款""一定赔偿"	system prompt 没写禁止语，模型补全时走"讨好用户"路线	system prompt 加严禁列表；工具执行完只描述结果，不加"一定/保证"措辞
搞不定的问题一直转圈，就是不转人工	escalate 条件写得太严，或者没有 escalate 工具	明确加"连续两轮无法解决"触发规则；把 escalate_to_human 加进工具列表
知识库答案三个月没更新，政策已经变了	没有知识库维护流程，文档烂在那里	建文档维护责任人制度；政策类文档加"最后更新时间"字段，超过 60 天触发复查提醒
用户改了地址，Agent 成功确认，但系统没改	工具函数没做接口鉴权，调用悄悄失败返回了假成功	工具函数强制检查返回码，失败时返回明确错误信息给模型；加日志追踪每次工具调用
多轮对话超长，模型忘了前面说的什么	messages 列表无限增长，超出上下文窗口	加对话摘要机制：每 10 轮把历史压缩成摘要，保留最近 5 轮明细；用 记忆模式 做更系统的上下文管理
用户说"帮我退款"，Agent 直接就提交了，没确认	system prompt 权限边界没写"执行前确认"规则	对写操作的工具，description 里加"调用前必须获得用户明确确认"；用两步确认流程

---

常见问题

Q：小公司没有 IT 团队，怎么把 Agent 接上自己的业务系统？

大多数电商 / ERP 系统都有 REST API，让供应商提供接口文档就行。实在没有 API，也可以退一步——先做"查单功能"（只读），查订单不改数据，风险最低。改地址、退款这类写操作等稳定了再加。实在没接口的场景，用 RPA 机器人填表也是一个过渡方案，只是不够稳健。接 API 不需要大团队，一个会写 Python 的人一周内能完成单个工具函数的联调。

Q：知识库 RAG 和工具调用怎么决定用哪个？

简单判断标准：答案是不是实时的、跟具体用户有关的。"退货政策是什么"——答案是文档里的固定内容，用 RAG。"我的订单退款到账了没"——答案要查数据库、跟你这个用户的具体订单有关，用工具。实际上这两个经常配合：先用 RAG 答"我们的退款政策是 3-5 个工作日"，再用工具查"您这笔退款当前状态是已受理，预计后天到账"。

Q：转人工之后，Agent 怎么把上下文带过去？

调 escalate_to_human 工具时，让模型自己生成一段 context_summary——"用户问了订单 ORD-001 的退款进度，退款原因是质量问题，已提交申请，用户追问说凭证已上传但三天没回音，情绪较激动"。这段摘要写进工单，坐席一打开就知道情况，不用用户再说一遍。坐席界面接收工单这块需要和工单系统联调，但 Agent 侧只需要调一个工具，不复杂。

Q：怎么知道 Agent 有没有乱承诺或者答错了？

光靠 QA 人工抽查不够，要建自动评测。参考 Agent 非确定性评测怎么做 这节，关键是把"乱承诺"定义为评测维度——用一批测试对话跑模型评判，专门查"有没有出现'保证/一定/肯定'加承诺结果"这类句式。每次更新系统提示词或工具后都跑一遍回归测试。

---

小结

客服数字员工不难落地，但要做到真正有价值，不能停在 FAQ 层面。四层架构缺一不可：知识库 RAG 答静态问题，业务工具干真活，多轮对话保上下文，升级机制兜底不让用户受气。

落地顺序别搞反：先把 RAG 答问题做稳，再接工具干活，最后打通人工交接闭环。每一阶都有验收标准，别自己没达到就往下跑。

搭之前还可以看看 组织层面的智能客服重塑 这节，从更高视角理解客服数字化的整体思路；关于跨会话的记忆管理，文件级记忆的 Hermes Agent 范式 那节有具体方法。更多场景落地案例在 AI Agent 智能体阶梯 里。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。