01agent 什么都回答，还是先做分流？
先分流：每一条进来的消息都先分类意图——可由知识回答、需要账户数据，或该立刻交给人工（动怒的客户、法律威胁、流失风险）。
免费完整指南
AI 客服 Agent
为一个 SaaS 产品设计一套 AI 客服 agent。涵盖意图路由、知识检索、账户安全的工具操作、对话记忆、基于置信度的人工升级、支持工单交接、评测套件、隐私管控，以及运营监控。
00
练习检查点
面试节奏保持精简,让页面能把注意力花在真正的设计决策上。
- 01澄清范围
- 02需求 + 规模
- 03API + 数据模型
- 04画出架构
- 05深入探讨
- 06取舍决策
01
塑造设计的需求
不要只是陈述需求,要主动问出来。每张卡把设计约束和一句你可以在画架构前说出口的澄清问句配成一组。
功能需求
02agent 实际上可以对账户「做」什么？
只用带类型输入的已批准工具——查状态、改设置、发一笔有上限的退款。有风险或不可逆的操作需要明确确认或交给人工。
03什么时候必须由人工接手，他们会收到什么？
在置信度过低、反复失败，或客户要求时：人工会拿到一份交接数据包——对话、检索到的来源、已尝试的操作，以及 agent 自己的不确定性——而不是从零开始。
04agent 记得先前的轮次——还有先前的对话吗？
在单次对话内，一律记得——就算对话拉得很长也一样。跨对话则只保留账户事实——依保留策略，绝不留先前的聊天内容。
05单一语言还是多语言？
管线与语言无关，但评测不是：golden set 要分语区，因为答案质量无法跨语言迁移。
06客户能在任何时候要求人工吗？
随时都可以——「找人工」在每一步都只差一轮；把出口藏起来会灌水拦截指标（deflection metrics，即从未接触人工的对话比例），同时摧毁信任。
范围外语音渠道与实时语音 · 训练自定义的基础模型 · 销售与营销对话（只做客服）
非功能需求
01最糟的失效模式是什么——慢，还是错？
错：一条捏造的策略或一笔未授权的退款，代价都比任何延迟更高。扎实、引用来源与操作把关，都优先于流畅度。
02agent 回答时能看到哪些数据？
只有这位客户可以看到的：知识访问按租户与套餐限定范围；内部 runbook 与其他租户的数据绝不能出现在答案里。
03回答要让人感觉多快？
答案必须在约 2 秒内开始出现、并远在 30 秒内完成——而且在每日约 1 万次对话的量级下也要守得住。
04出事的时候，我们能重建原因吗？
可以：每一轮都留追踪——查询、检索到的分块与分数、prompt、带输入／输出的工具调用，以及升级决策。失败会回放进评测集。
05我们怎么知道 agent 正在变差？
每次换模型或改 prompt，都要用一套常设的参考客服对话来检查质量——没量过的东西不出货；光看拦截率（deflection rate）不等于质量。
持续追问 —— 面试是一场对话
真实面试探得比一份整齐清单深得多。这些范围问句,区分出真正拷问问题的人和只是背诵的人。
- 升级的契约是什么——交接后人工必须多快响应？
- 对话日志的数据保留与 PII 规则是什么？
- 每次对话有没有成本上限——到什么程度 agent 的花费会比它取代的人工还贵？
- 要不要预期对抗性用户——刻意想骗 agent 退款或套出数据的人？
- 客服量有没有季节性或发布日的激增需要我们吸收？
02
逼出架构决策的数字
把每个估算都当成一种压力,用来合理化一个组件:缓存、队列、分片、副本、worker pool 或退路。
拦截经济学
每日 1 万次对话（面试官给定），agent 完全解决约 60%，一张人工工单平均约 15 分钟1 万 × 60% = 每日解决 6,000 次；6,000 × 约 15 分钟 = 90,000 分钟 ≈ 每日 1,500 个客服工时；按 8 小时班算 ≈ 吸收掉约 190 个客服席位
商业价值的成败取决于解决「质量」——这正是评测套件是需求、而非附属工具的原因。
每轮的上下文预算
约 8K tokens：system + 策略（2K）+ 检索分块（4K）+ 对话窗口（2K）2K + 4K + 2K = 每轮 8K tokens——检索分块占掉整个预算的一半，所以那 4K tokens 必须足以承载答案
检索精度才是真正的质量杠杆——把窗口开大只是加成本，不是解法。
延迟拆解
p95 目标：检索 300 ms + rerank 200 ms + 第一个 token 1.5 s≈ 2 秒到第一个流式 token
每一阶段有自己的预算与监控——「AI 很慢」不是一个诊断。
评测套件成本
每次发布 500 个 golden 对话 × 3 个受评变体500 × 3 = 每次发布 1,500 次受评运行——并行跑只需几分钟墙钟时间，评审模型的 token 花几美元
持续评测的成本，比一张被搞砸的企业工单还低。
升级负载
1 万次对话中约 40% 升级每日 4,000 次路由给人工，并「附上」交接数据包
交接质量决定人工是否信任 agent——一份糟糕的数据包会让他们的工作量翻倍。
决策示例
数字
每日一万次对话，其中六成由 agent 完全解决——整个价值都押在这些解决是「对的」，因为一条捏造的退款策略就能抹掉一个月省下的成本。
我的选择
我会把 agent 建成一条有把关的管线：先分类意图，用客户自己的权限做检索，只以引用来源作答，并把每一个副作用都放在带类型、允许清单、且风险层级在模型之外强制执行的工具后面。置信度把关每一步——低于阈值，客户就得到一位人工加上一份交接数据包，里面带着对话、来源、已尝试操作，以及 agent 的不确定性。每一轮都留追踪、可回放，失败会喂进一个 golden 评测集，由评分准则与两两比对评审、并由人工校准。
避免
我不会做的事：把数据库连接交给模型，再配一句「请乐于助人」的 system prompt——自由访问正是 agent 退款给错的客户的原因。我也不会只用拦截率来衡量质量：一个自信地用错答案拦截的 agent 分数会很完美，却在摧毁信任。而精确匹配的测试无法评判客服对话——「有没有正确解决」是一种偏好判断，这正是评测集要同时存好答案「与」坏答案参照输出并附评分准则的原因。
何时改变
如果产品走向多区域并带数据驻留规则，检索索引与对话日志就必须按区域分片，评测套件也要增加分语区的 golden set——质量无法跨语言迁移。
03
架构路径
先看一张完整的图,再把每条路径各自画成一张图 —— 写入路径与读取路径承载不同流量,合理化不同的组件。
完整全貌
总览 —— 每个组件
模型做的每一件事都要过一道关卡：检索限定在权限范围内，操作走工具网关，置信度过低就带着完整交接数据包退场给人工。追踪记录每一跳。
路径 1
回答路径——分类、检索、扎根、响应
意图分类在任何生成之前先路由；检索把客户的权限带进索引查询；答案要引用来源，否则就不出货。
路径 2
操作路径——风险层级后的类型化工具
模型提议，网关裁决。低层级直接执行，中层级请客户确认，高层级需要人工——而且每一次调用都落进追踪。
04
API 与数据模型
在优化之前,先让契约可被检视:端点、实体、所有权、重试与状态。
POST/support/messages
请求{ conversation_id?, text }
响应200 流式回答并附引用来源 · 或 { escalated: true, ticket_id }
客户身份来自 session——agent 的权限就是客户的权限，绝不更宽。
POST/support/{conversation_id}/escalate
响应201 { ticket_id } 并附上交接数据包
在置信度过低、反复失败，或客户明确要求时触发——升级是一项功能，不是失败。
POSTinternal: tools.execute(tool, input, risk_tier)
响应result · blocked（需确认）· denied（策略）
从模型输出到真正副作用的唯一路径：带类型的输入、允许清单内的工具、在模型之外强制执行的风险层级。
核心实体
Conversationconversation_id (PK) · customer_id · channel · state: active/escalated/resolved
Turnturn_id (PK) · conversation_id · role · content · trace_ref
trace_ref 连到可完整回放的追踪：检索、prompt、工具调用、决策。
ToolActionaction_id (PK) · conversation_id · tool · input · result · risk_tier · confirmed_by
有风险的层级会记录由谁确认——agent、客户，或一位人工客服。
HandoffPacketconversation_id · summary · retrieved_sources · attempted_actions · uncertainty_notes
人工在升级时收到的东西——这决定了是接手还是重来。
05
深入方向
在面试最后三分之一挑一条路线。每条路线给你主题、它该回答的面试官问题,以及要避免的失败模式。
agent 承诺了一笔不该给的退款
问
在「模型想退 $500」和钱真的动起来之间，有哪些层层防线？
回答
做决定的是 gateway，不是模型。退款工具接收带类型、带硬上限的输入，风险分级放在模型之外的 tool gateway 里。500 美元在自动执行线以上，所以钱只有在客户确认或有人工批准之后才动。就算是被拦下的尝试，也会记进 trace。
避免
把 system prompt 当成控制——策略活在工具网关里，在模型之外。
租户数据留在家里
问
两家公司都用这个产品。走一遍检索：某个问题最佳匹配的分块刚好属于「另一个」租户。
回答
把 tenant ID 放进索引查询里。这样别的 tenant 的 chunk 根本就不会成为检索候选——它在排序之前就被排除了，而不是事后再挑出来。别改成对结果做 post-filter。那里漏查一次，竞争对手的文档就进了 prompt。
避免
对检索到的分块做事后过滤——权限过滤必须在索引查询本身之内。
交接的那一刻
问
对话中途置信度掉下来。人工客服究竟看到什么，客户的流程又会怎样？
回答
人工打开的是一份交接包，不是一块白屏。里面有完整对话、顶部一段滚动摘要、agent 检索过的来源、它试过的每一个动作，还有它自己标的不确定说明。客户还在同一个对话里，只是看到有个真人加了进来。他们不用把话再说一遍。
避免
只带一份逐字稿就升级——来源、已尝试操作与不确定性备注，才是让人工免于重来的东西。
它是不是变差了？
问
一次 prompt 微调上线。你怎么知道客服质量没有悄悄回退——在客户告诉你之前？
回答
每次发版都拿一套固定的 golden 对话重放一遍。一个 judge 模型按 rubric 给每个回答打分，把新版本和旧版本对比，人工再定期重新校准它。精确匹配没法评一段话写得好不好，deflection rate 又会奖励那些自信的错误答案。rubric 加上两两对比的判断，能在客户之前抓到退化。
避免
拿精确匹配测试或拦截率当指标——客服答案需要评分准则加两两比对评审，并由人工校准。
谁看了什么
问
客户对 agent 上个月做的某个操作提出争议。重建这段对话：存了什么、存多久、谁可以读？
回答
每一轮都被 trace 下来了——查询、检索到的 chunk 和分数、prompt、带输入输出的工具调用，还有升级决定。所以有争议的那个动作能原样重放出来。日志只在保留期内存在，PII 已脱敏。读这些日志本身也是一个要授权、会被审计的动作。
避免
把原始对话带着 PII 永久存放——保留与脱敏是需求，不是事后清理。
准备好练习了吗?
把 AI 客服 Agent 大声讲一遍,让 AI 为你的说明评分。