客服智能体

典型题：设计一个客服 Agent，能回答政策问题、查询订单、创建工单，并在高风险场景转人工。

面试官真正想看什么

客服问“我的包裹到哪了，能不能退款”包含一个查询和一个高风险写操作。前者可以自动查，后者要核身、说明影响并确认；接口、状态和转人工都要围绕这条分界设计。

• 你会不会先把客服场景分成读操作、写操作和高风险操作。
• 你知不知道客服不只是“回答问题”，还要管身份、权限、情绪和升级。
• 你能不能设计一个可审计、可转人工、可评估的系统。

先问清楚

Q1：面试官让我设计客服 Agent 时，先问什么？

参考答案

我会先问五件事：

• 客服场景是什么：电商、SaaS、金融、教育还是内部 IT。
• 是否需要查订单、查用户、退款、改地址这类写操作。
• 是否允许自动处理，还是所有敏感动作都要人工确认。
• 是否需要多轮对话和身份校验。
• 成功指标是什么：解决率、转人工率、响应时延、满意度、成本。

这些问题会直接决定系统是不是只做 FAQ，还是要接业务工具和人工系统。

最小架构

核心模块

Q2：客服 Agent 的核心模块怎么拆？

参考答案

我会拆成六块：

模块	负责什么
意图识别	判断是 FAQ、订单查询、投诉、闲聊还是危险请求
知识库检索	查询政策、流程、产品说明
业务工具	查订单、查工单、创建工单、查询会员信息
权限校验	校验用户身份和可执行动作
人工接管	投诉、高价值客户、敏感问题、模型不确定时转人工
监控评估	记录成功率、转人工率、成本、违规率

客服系统本质上不是单一聊天接口，而是一个“意图路由 + 知识检索 + 业务操作 + 升级”的组合体。

Q3：为什么客服不能只靠一个大模型回答？

参考答案

因为客服里既有事实查询，也有写操作和风险动作。只靠大模型会有这些问题：

• 不能保证查到实时订单。
• 不能保证政策不被答错。
• 不能保证退款、改地址等写操作安全。
• 不能保证身份和权限正确。
• 不能保证出错后能审计。

所以客服系统一定要让模型做判断，但真实执行要交给代码和业务系统。

工具与状态

Q4：客服工具应该怎么设计？

参考答案

工具要窄，不要搞一个万能 operate_user_account。比较好的拆法是：

• search_policy(query)：查政策。
• get_order_status(order_id)：查订单状态。
• create_ticket(category, summary, priority)：创建工单。
• request_human_handoff(reason)：转人工。

像退款、改地址、取消订单这种写操作要再拆出来，并且加身份校验、确认和审计。这样模型更容易选对，系统也更容易控权限。

Q5：客服 Agent 的状态应该记什么？

参考答案

只记当前任务相关的关键状态，不要把整段聊天历史无限塞进去。常见状态包括：

• 用户身份和权限。
• 当前问题分类。
• 订单号、工单号等槽位。
• 已查到的政策和证据。
• 是否已经升级人工。

客服的重点不是“记住所有话”，而是“记住当前需要执行的事实”。

Q6：为什么写操作一定要确认？

参考答案

因为写操作往往是不可逆或高风险动作。比如退款、改地址、取消订单、修改权限、导出敏感数据，都不能只靠模型自己决定。确认机制能防：

• 误操作。
• 身份冒用。
• 模型幻觉导致的错误执行。
• 用户临时反悔。

在面试里你可以直接说：读操作可以自动化，写操作和高风险动作必须确认和审计。

关键边界

Q7：客服系统如何处理用户身份校验？

参考答案

身份校验要前置到敏感工具调用之前。对于只读 FAQ，可以不需要强身份；但如果涉及订单、地址、退款、账单等信息，就必须先校验用户身份和权限。

常见做法包括：

• 登录态确认。
• 手机号/邮箱/验证码确认。
• 订单号或账号绑定校验。
• 敏感信息脱敏展示。

如果身份没验证就去查敏感订单，这是明显的设计缺陷。

Q8：客服 Agent 如何避免乱承诺？

参考答案

要把“事实”和“承诺”分开。模型可以根据政策和工具结果回答事实，但不能超范围承诺补偿、退款或人工保证。防止乱承诺的办法有：

• system prompt 明确边界。
• 高风险话术加口径检查。
• 对退款、赔付、优惠等承诺词做规则拦截。
• 必要时转人工。

客服最常见的翻车点不是答错一个事实，而是乱给用户承诺。

转人工与异常

Q9：什么时候该转人工？

参考答案

转人工的典型条件包括：

• 用户强烈投诉或情绪非常差。
• 涉及高价值客户。
• 涉及敏感信息或高风险写操作。
• 模型连续几轮都无法解决。
• 证据冲突或政策不明确。
• 用户明确要求人工。

转人工不是失败，而是系统设计的一部分。一个成熟客服系统要知道自己什么时候该收手。

Q10：用户很生气时怎么处理？

参考答案

我会先让系统做情绪识别和语气收敛，避免继续激化矛盾。处理原则是：

• 先承接情绪。
• 再给出事实和下一步。
• 不要长篇解释废话。
• 必要时直接升级人工。

客服场景里，用户体验和事实准确一样重要。模型如果只会解释，不会收敛情绪，实际效果会很差。

Q11：工具返回错误后模型应该怎么处理？

参考答案

工具返回错误后，模型不应该瞎编成功，而应该根据错误类型决定：

• 重试。
• 更换参数。
• 请求补充信息。
• 转人工。

所以工具层最好返回结构化错误码，而不是只有一段自然语言。这样模型更容易做下一步决策。

评估与指标

Q12：客服 Agent 上线前看哪些指标？

参考答案

我会看这些指标：

• 首次解决率。
• 正确率。
• 转人工率。
• 违规率。
• 平均响应时间。
• 平均成本。

如果是写操作场景，还要额外看误操作率和确认失败率。

Q13：如何用 eval 测客服质量？

参考答案

我会准备一组覆盖不同类型的测试样本：

• FAQ 问题。
• 订单查询。
• 退款和改地址。
• 投诉和情绪激烈样本。
• 身份未通过样本。
• 攻击或越权样本。

然后看系统是否能正确路由、正确回答、正确转人工、正确拒绝。客服系统的评估重点不只是回答对不对，而是“处理得对不对”。

30 秒收口

Q14：你会怎么用 30 秒总结这个方案？

参考答案

我会把客服 Agent 拆成意图识别、知识库、业务工具、权限确认、人工接管和监控评估。
核心原则是：读操作可以自动化，写操作和高风险承诺必须确认和审计。

本题常见扣分点

• 只会说“加一个客服机器人”。
• 不讲身份校验。
• 不讲写操作确认。
• 不讲转人工。
• 不讲情绪处理。
• 不知道客服指标和技术指标要一起看。

深入追问：把客服 Agent 接进真实业务

客服系统的难点是“回答”和“执行”同时存在。面试时要主动区分信息查询、可逆操作、不可逆操作和高风险承诺，并说明模型只负责理解与决策建议，业务系统负责权限、校验和落库。

Q15：客服 Agent 的请求量、延迟和容量怎么估算？

回答脉络

按会话、消息和工具调用估算，区分同步回答与异步工单，并为高峰和人工转接留容量。

完整参考答案

我会先问日活用户、日均会话数、每会话消息数、峰值时段和渠道数量。假设每天 10 万个会话、每会话 6 轮消息，平均约 7 个请求每秒，按 10 倍峰值估算在线入口；但一次用户消息可能触发意图识别、知识库检索、订单工具和安全检查多次内部调用，所以模型 QPS 不能直接等于用户 QPS。

延迟拆成首 token、工具返回和最终答案三个指标。FAQ 可以要求 1 到 2 秒内开始流式回复；查订单或创建工单要先发送“正在查询”，工具超时不能让模型无限等待。对话服务保持轻量无状态，状态放持久化存储；工具调用和人工转接通过队列隔离，避免业务接口慢时拖垮聊天入口。

我会按渠道、租户和高价值客户做限流，给模型、知识库、业务工具分别设熔断和并发上限。人工坐席也要按预计转人工率预留容量，否则 Agent 降级时会把压力集中推给人工系统。

为什么这样设计、替代方案和扣分点

• 低并发内部客服可以同步调用业务 API；大规模客服必须异步化、限流并提供降级话术。
• 常见扣分点是只报聊天 QPS，不计算多次工具调用、峰值消息和转人工后的容量。

Q16：一次客服请求的完整数据流和核心状态是什么？

回答脉络

讲清消息接入、身份解析、路由、检索/工具、确认、回复和审计的顺序。

完整参考答案

消息进入后先生成 conversation_id、message_id 和 trace_id，校验渠道签名和租户，再加载最小必要的会话状态。意图路由器判断 FAQ、查询、写操作、投诉或人工请求，并提取订单号、产品、时间范围等槽位。FAQ 进入带权限过滤的知识库；业务查询进入身份校验后的只读工具；写操作先生成预览和影响范围，等待用户明确确认后才执行。

状态至少包括用户身份级别、当前意图、槽位、工具调用结果、待确认动作、确认过期时间、人工接管状态、政策版本和最后一次处理事件。工具执行成功后由业务系统返回真实结果，Agent 只负责把结构化结果转成可理解的话。回复发布前做敏感字段脱敏、承诺口径检查和引用检查，并将状态与审计事件持久化。

为什么这样设计、替代方案和扣分点

• 简单 FAQ 可以无状态地每轮检索；涉及多轮补槽、确认和人工接管时必须有显式状态机。
• 把整段聊天历史当唯一状态容易出现旧订单号、过期身份和重复执行。常见扣分点是没有 pending_action、确认过期和幂等事件设计。

Q17：读操作、可逆写操作和高风险写操作如何分级？

回答脉络

先定义风险等级，再为每级绑定权限、确认、人工审核和审计策略。

完整参考答案

我会把动作分成四类：公开知识问答；用户本人可查的只读操作；可撤销或影响较小的写操作；退款、转账、改收货地址、删除账号、修改权限等高风险动作。第一类可直接回答，第二类必须完成身份校验，第三类至少展示动作预览并要求明确确认，第四类需要二次认证或人工审批，具体以业务合规要求为准。

工具 schema 中直接声明风险等级、所需 scope、是否需要确认、幂等键和审计字段。模型不能通过修改自然语言参数绕过这些约束，服务端在每次工具调用前重新校验用户、资源归属、金额、状态和策略版本。确认应绑定具体动作摘要和参数，不能用“好的”去确认一个后来被改过的退款金额。

为什么这样设计、替代方案和扣分点

• 低风险内部 IT 工单可以减少确认；金融、账户和隐私操作应默认升级人工或二次认证。
• 只在 prompt 中写“不要退款”是不够的，模型可能误判意图。常见扣分点是没有风险分级，把查订单和退款放进同一个万能工具。

Q18：工具接口如何保证幂等、权限和可审计？

回答脉络

每个工具做窄接口，业务服务端最终负责鉴权、状态机、幂等和审计。

完整参考答案

以创建工单为例，接口可以要求 conversation_id、request_id、分类、摘要、优先级和用户身份上下文，服务端用 request_id 做幂等键；网络超时后重试不会创建两张工单。退款工具不能接收模型自由描述的“帮我处理一下”，而应接收订单 ID、金额、原因和确认凭证，并由订单服务再次检查订单状态、退款上限和用户权限。

工具返回结构化结果，例如 success、error_code、retryable、user_message、audit_id，而不是把数据库异常原样交给模型。每次调用记录调用者、授权 scope、资源、参数摘要、结果、策略版本和时间；敏感参数脱敏。模型只拥有工具声明的能力，不能直接访问数据库。

为什么这样设计、替代方案和扣分点

• 业务已提供成熟 API 时，Agent 只需要适配器；遗留系统没有幂等能力时，必须在网关或业务侧补偿，不能靠模型避免重复。
• 常见扣分点是工具返回一段自然语言、把鉴权放在模型里、或者没有考虑超时重试造成重复写入。

Q19：如何处理身份校验、会话劫持和敏感信息泄露？

回答脉络

身份、会话、资源授权和输出脱敏是四个不同问题，不能混为“用户已登录”。

完整参考答案

登录态只说明账号身份，不能自动授权所有资源。查订单时还要校验订单与账号的归属；代他人处理时需要明确委托关系和额外 scope。会话服务校验 token、渠道签名、过期时间和重放风险，工具调用使用服务端保存的身份上下文，不信任用户在聊天里声称的账号或管理员身份。

输出侧对手机号、地址、银行卡、身份证和内部备注做最小展示和脱敏；日志、trace、模型供应商请求和人工坐席界面采用不同的可见范围。权限或身份服务失败时 fail-closed，不为了“用户体验”返回可能属于他人的数据。对提示词注入、伪造客服指令和诱导导出数据做输入分类，但最终防线仍是工具权限和服务端授权。

为什么这样设计、替代方案和扣分点

• 低敏 FAQ 可只使用登录态；金融、医疗和账户数据必须做资源级授权和审计。
• 常见扣分点是认为验证码通过就可以访问所有订单，或只讲输出脱敏却没有防止数据进入 prompt、日志和缓存。

Q20：模型、知识库或业务工具失败时，如何恢复和降级？

回答脉络

按错误类型决定重试、改参数、降级、追问还是转人工，并保证用户不会收到虚假成功。

完整参考答案

工具错误统一映射为错误码和 retryable 标志。网络超时、限流和临时 5xx 可以有限次数指数退避；参数校验失败要让模型修正或向用户补槽；订单不存在、无权访问和业务状态不允许属于不可盲目重试的错误。写操作超时尤其危险，必须先查询幂等键或业务结果，再决定是否重试。

知识库不可用时，系统可以只回答明确的固定政策或转人工，不能让模型凭记忆编政策。主模型不可用时可降级到小模型处理路由和模板回复；情绪激烈、连续失败、工具结果冲突或高风险动作直接转人工。人工接管时传递会话摘要、已验证身份、证据、工具结果和未完成动作，避免用户重复描述。

为什么这样设计、替代方案和扣分点

• 对纯 FAQ 可以使用静态缓存答案；订单、退款等实时业务不能使用过期结果冒充成功。
• 常见扣分点是所有错误都重试、工具失败后模型说“已经处理好了”，或者转人工只传一段原始聊天记录。

Q21：用户情绪和人工转接如何产品化，而不是只写一句“转人工”？

回答脉络

定义触发条件、交接上下文、坐席接管边界和转接失败时的兜底。

完整参考答案

转人工条件可以由规则和模型共同判断：用户明确要求人工、重复表达未解决、强烈投诉、涉及法律或安全事件、模型置信度低、身份或工具多次失败，以及高价值客户服务策略。情绪识别只用于调整话术和升级优先级，不能单独决定拒绝退款或给用户贴永久标签。

转接事件要生成 handoff_id，传给坐席的是结构化摘要、用户诉求、已确认事实、政策证据、工具调用结果、风险等级和建议下一步，同时保留原始记录供审计。坐席接管后 Agent 只做检索和摘要，不能继续自动执行动作，除非坐席明确授权。坐席系统不可用时，创建工单、给出预计响应时间并保存上下文。

为什么这样设计、替代方案和扣分点

• 低复杂度客服可以直接排队转接；高峰期需要按技能、语言、优先级和 SLA 路由。
• 常见扣分点是只说“情绪不好就转人工”，没有可执行阈值、上下文交接、接管后的权限和转接失败策略。

Q22：如何评估客服 Agent 的真实效果？

回答脉络

同时评估“答对、办成、合规、体验、成本”，并按意图和风险分层。

完整参考答案

离线评估集要覆盖 FAQ、订单查询、补槽、确认、退款、越权、投诉、注入、工具失败和多轮上下文。每条样本标注正确意图、必需身份等级、允许调用的工具、标准结果、应该转人工的条件和禁止承诺。线上指标包括一次解决率、任务完成率、工具成功率、正确转人工率、错误转人工率、平均处理时长、用户满意度、复联率和人工接管后的修复率。

安全指标要单独看：越权访问率、错误写操作率、重复写入率、敏感信息泄露率、违规承诺率和审计完整率。技术指标看首 token、P95 完成延迟、模型/工具错误率、每会话 token、缓存命中率和成本。总体平均数可能掩盖退款类问题，必须按高风险意图单独设门槛。

为什么这样设计、替代方案和扣分点

• 满意度高不代表业务正确，用户可能没有发现错误；必须结合工具结果和人工抽检。
• 常见扣分点是只报“转人工率越低越好”，实际上错误不转人工比高转人工更危险，也没有区分首次解决和真正完成任务。

Q23：客服请求一次花多少钱？缓存哪些东西才安全？

回答脉络

以会话和意图为成本单位，区分模型 token 缓存、知识结果缓存和业务数据缓存。

完整参考答案

每个会话记录输入、输出和缓存输入 token，所用模型及单价，embedding、rerank、工具调用、重试、日志和基础设施开销。一个会话成本是所有模型调用成本之和，而不是只算最终回复；如果意图识别、query 改写和安全检查分别调用模型，也要纳入。客服还要把人工接管成本作为业务指标，否则为了省 token 增加转人工，整体成本可能更高。

安全缓存方面，公开政策和稳定 FAQ 可以缓存，但 key 至少包含知识版本、语言、地区和渠道；订单状态、账户余额、退款资格等实时或用户私有结果不能做跨用户共享缓存，个人缓存也必须设置很短 TTL 并绑定用户和权限版本。模型 token 缓存则依赖稳定的系统前缀和工具 schema，变化的用户内容放后面；不能因追求命中率把不同用户的隐私拼进可共享前缀。

为什么这样设计、替代方案和扣分点

• FAQ 重复度高时缓存收益明显；个性化订单问题更适合优化 prompt、路由小模型和减少无意义历史。
• 常见扣分点是只说“Redis 缓存回复”，没有区分缓存价格、权限和时效，也没有把人工成本和重试算进去。

Q24：如何灰度上线、监控和回滚？

回答脉络

先影子流量，再低风险意图小比例上线，高风险动作最后由人工审核；回滚要能切模型、prompt、知识版本和工具策略。

完整参考答案

我会先用脱敏历史会话做离线回归，再以 shadow 方式运行新 Agent，不向用户执行工具或发送回复。第一阶段只开放公开 FAQ，第二阶段开放低风险只读查询，最后才在明确范围内开放创建工单等可控写操作；退款、改地址、账户安全等高风险动作保留人工确认。

灰度看一次解决率、正确率、错误转人工率、首 token 和 P95 延迟、工具失败率、越权率、错误写入、违规承诺、每会话成本和缓存命中率。安全指标触发阈值立即停止扩量；回滚时可把路由切到旧模型和旧 prompt，知识库切回旧索引别名，关闭高风险工具，保留人工入口。每次回复和动作都带版本号和 trace，便于把线上事故定位到具体配置。

为什么这样设计、替代方案和扣分点

• 低风险内部服务可以加快只读灰度；面向外部客户或受监管行业必须保留人工审批和可审计记录。
• 常见扣分点是只说“逐步放量”，却没有阶段边界、安全停止条件、工具开关和回滚粒度。