从零设计一个能查库存、能下单的电商客服 Agent，讲讲整体架构
谁在问：二三面综合设计题；面试官用它检验前面所有单点知识能不能串成一个能上线的系统
口语化问法
- 设计一个电商客服 Agent，能查库存也能帮用户下单，你怎么做？
- 假设你来负责这个项目，第一版上线什么样？
- 这个系统里最容易出事的地方是哪儿？
考察意图
综合题不考知识点，考你会不会做工程。面试官在验四层：
- 会不会先澄清再动手。 上来就画架构图的人，通常也会在真实项目里做错需求。
- 第一版敢不敢做小。 直接上全自治 Agent 的方案，在有资损风险的场景里是危险信号。
- 知不知道钱和库存这类东西不能交给模型。 这是电商场景最硬的一条红线。
- 有没有演进路径和评测。 一个只讲架构不讲怎么验证、怎么扩权限的方案，等于没法落地。
答题用五步结构：先澄清需求 → 给基线 → 加挂并说代价 → 谈评测 → 谈演进。
参考答案
60 分答案（及格线）
架构分五块：
- 入口与分诊：判断用户意图（咨询 / 查询 / 操作 / 投诉），不同意图走不同路径；
- 工具层：库存查询、订单查询、物流查询、下单、改地址、退款申请，按意图切分而非按后端接口一比一映射；
- 上下文与状态：会话 slot 表（商品、数量、地址、已确认项）+ 用户档案（历史地址、偏好）；
- 护栏：输入侧注入检测，执行侧金额与归属校验，输出侧价格库存数字必须来自工具结果；
- 人工兜底：连续失败、用户情绪激动、高价值订单、护栏拦截时转人工。
写操作（下单、退款）必须有幂等键和确认环节，不能让模型自由发起。
90 分答案（有生产经验的回答）
第一步：澄清（问 3–5 个致命问题，不要问一堆）
- 流量与场景分布是什么？咨询类和操作类各占多少——这决定了要不要做 Agent，还是一个好检索加固定表单就够了。
- 哪些动作不可逆、错了的代价多大？（下单、退款、改地址都不可逆或半不可逆）
- 现有系统提供哪些接口，库存是强一致还是最终一致？
- 有没有人工坐席兜底、转人工的成本是多少？（这是所有降级路径的落点，也是成本对比的基准）
- 合规要求：客服记录留存、个人信息处理边界。
第二步：基线（第一版不是 Agent）
我的第一版是 router + workflow + 少量 agentic：
- 查询类（库存、物流、政策）→ 固定检索管线，可缓存、可测、成本恒定；
- 操作类（下单、改地址、退款）→ 确定性的表单式流程：模型负责理解和填槽，流程与校验全在代码里；
- 模糊与长尾（"我上次买的那个不对劲"）→ 才走受限的 agentic 循环（工具白名单、max_steps=3、超时回落转人工）。
理由就是 Q3-02 的判据：路径可枚举的部分不该交给模型，可测、可复现、成本恒定这三样在有资损风险的场景里比"聪明"重要得多。
第三步：加挂什么、代价是什么
- 工具设计：按意图切分，只读优先；写工具全部带幂等键；描述里写清负向边界（"用户只是询问能否退款时不要调用退款工具，改用政策查询"）。
- 状态：已确认的商品、数量、地址、金额进结构化 slot，常驻不参与压缩——这些是"系统不能忘"的东西（Q3-13）。
- 护栏分层（Q3-18）：执行前用代码校验（库存是否足够、订单是否属于该用户、金额是否在限额内）；输出层做实体溯源，价格和库存数字必须能在工具结果里找到，模型不得自行生成或推算。
- 分级自治（Q3-19）：小额下单自动执行 + 可撤销窗口（几分钟内可取消）；大额、异常收货地址、首次购买的高价商品 → 执行前确认；退款超过阈值 → 人工审核。
- 成本与延迟（Q3-23）：小模型做分诊；系统提示与工具定义稳定放前面吃 prompt 缓存；商品政策类结果可缓存，库存和价格不缓存或极短 TTL。
- 人工兜底：转人工触发条件写死在代码里，不由模型决定是否转。
第四步：评测怎么做（Q3-21）
- 程序化终态断言：订单真的创建了、商品和数量正确、地址正确、且没有产生多余副作用；
- 轨迹断言：下单前必须调用过库存校验和归属校验，禁止调用退款工具；
- 线上先行指标：转人工率、重试率、错单率、撤销率、投诉率；
- 评测集从真实会话采样并定期刷新，留一份不参与调优的 holdout。
第五步：演进路径
只读上线（只查不改，跑两周积累真实分布）→ 写操作影子模式（生成操作计划但不执行，和人工坐席的处理比对）→ 小额自动 + 可撤销 → 按误操作率逐步放宽额度。什么时候增加自治：badcase 里"预设外路径"占比明显上升时，而不是因为觉得 Agent 更先进。
我明确不做的：不做多 Agent（Q3-16，这个场景没有需要隔离的并行子任务）；不让模型算价格和优惠（交规则引擎，模型只做解释）；不把促销规则塞进提示词；不缓存库存用于下单判断。
追问链
综合设计题：五层挨个验「钱和库存能不能交给模型」
为什么第一版不直接做成全自治 Agent？
期望三条：① 可测性——操作路径可枚举，写成流程才能确定性回归，Agent 不可复现，上线前验证形同虚设；② 资损风险——下单退款不可逆，每个自由度都是潜在损失；③ 成本可预测——客服高频低价，方差吃毛利。第一版是为了拿真实分布，等 badcase 里「流程覆盖不到」的占比上来再放权信号把「第一版是为了拿分布」讲出来 → 做过冷启动；只答「先简单后复杂比较稳」→ 方向对但缺论证用户说「我要买上次那个」，怎么处理？
期望不能猜：从档案/历史订单捞候选 → 唯一命中且时间近，展示商品明细让用户确认（「是上个月买的 XX 吗」）→ 多个候选或时间久远就列选项 → 查不到就坦白没找到、请用户描述。判断是涉及花钱的歧义一律显式确认，不做自动消解；确认信息要带价格和数量，老订单的价格可能已经变了信号坚持显式确认并想到「老订单价格可能变了」→ 有电商经验；答「从历史记录里找出来直接下单」→ 真实场景会出错单库存能缓存吗？缓存导致超卖怎么办？
期望区分展示与下单依据：展示库存可短 TTL 缓存；下单必须实时校验走库存锁/扣减，绝不用缓存值或几轮前查到的值。经典事故是 Agent 第 2 步查到有货、用户犹豫两分钟、第 6 步下单没重新校验。所以「实时校验 + 原子扣减 + 幂等键」要封在下单工具内部，不指望编排记得再查一次信号明确区分展示缓存与下单依据、把实时校验封进工具内部 → 做过交易系统；答「缓存一分钟应该没事」→ 会出资损促销规则复杂又常变，写进提示词还是别的地方？
期望放规则引擎，工具返回算好的结果，模型只解释。四条：① 每条促销能写单测，提示词不能；② 算钱不能靠概率，算错优惠就是资损纠纷；③ 规则变更不用改提示词、不用重跑评测、不击穿 prompt 缓存；④ 可审计，出争议能证明当时按什么规则算。模型只做表达「满 300 减 50 已生效」信号给出「模型解释、引擎计算」的分工并提到可审计 → 想清楚了；答「把促销规则写在系统提示里让模型算」→ 本题最危险的答法大促流量涨到平时 10 倍，成本时延都爆了还出了几单超卖，怎么处理？
期望超卖优先于成本：一个资损，一个只是账。超卖止血：查扣减依据是不是缓存值或旧查询、扣减是否原子、幂等键是否生效 → 热门品收紧水位、下单前强制复核，已发生的补偿 → 成本止血：提分诊阈值、关 agentic 分支、收紧max_steps、限流，大促转人工阈值本就该调低 → 复盘落预案：压测须含工具超时，超卖 case 进回归集 + 断言「下单前有实时校验」信号按「资损优先于成本」排序、把超卖归因到缓存或旧查询当扣减依据、复盘落到压测含工具超时 → 扛过大促；只答「加机器扩容」→ 优先级排错了
综合题不判架构图，判你敢不敢把第一版做小：第 1 层考「为什么不上全自治」，第 3、4 层守资损红线（库存不缓存、算钱交引擎），第 5 层考出事时的排序。
评分要点
- 先澄清后设计，澄清问题少而致命（含不可逆动作与人工兜底成本）
- 第一版是 router + workflow + 局部 agentic，不是全自治
- 工具按意图切分，写工具带幂等键，描述含负向边界
- 已确认信息进结构化 slot，不参与压缩
- 护栏分层：执行前代码校验 + 输出层实体溯源（价格库存不得由模型生成）
- 分级自治：小额自动 + 可撤销窗口，大额/异常确认，退款人工
- 转人工条件写死在代码里，不由模型决定
- 评测有程序化终态断言（含无多余副作用）与轨迹断言
- 有演进路径：只读 → 影子 → 小额自动 → 逐步放宽
- 加分：明确列出"不做什么"（不做多 Agent、不让模型算价格、不缓存库存作下单依据）
常见错误
不澄清直接画架构图，或者问一长串无关紧要的问题。
第一版就上全自治 Agent，把下单交给模型自由发挥。
把促销规则和价格计算写进提示词，让模型算钱。
用缓存的库存值作为下单依据，说不出超卖风险。
写操作没有幂等键，模型重试一次就多一张订单。
转人工由模型自己判断——用户越激动模型越容易被带偏。
只讲架构不讲评测和演进，方案没法证明能上线。
一上来就设计多 Agent（客服、订单、售后各一个），说不出隔离与并行的收益在哪。