淘天 Agent 开发二面：30 多道场景题与系统设计追问

《面试题目》

1. 淘宝要做个智能客服 Agent，你觉得难点在哪？
2. 如何拆分售前咨询、售后投诉、订单查询 Agent 的职责？
3. 你的 Agent 系统中「短期记忆」和「长期记忆」怎么设计？
4. 如果量大了怎么办？
5. 如果挂了怎么办？
6. 高并发下怎么做容灾和降级？
7. 淘宝搜索「夏天穿什么」，大模型怎么结合天气、地域、画像做个性化推荐？
8. 大模型在 Query 理解、商品召回、排序、推荐理由生成各能做什么？
9. 双塔召回和生成式召回各有什么优劣？
10. 用户行为序列怎么高效输入大模型？
11. 怎么解决大模型推荐中的「信息茧房」？
12. 推荐文案的点击率、转化率怎么评估？AB 实验怎么设计？
13. Agent 整体架构怎么设计？
14. 为什么用 Agent 而不是直接做平台或 API？
15. 你现在做的 Agent 效果如何？
16. Skill 泛滥问题遇到过吗？怎么解决？
17. 上下文窗口限制对 Skill 管理有什么影响？
18. 怎么沉淀部门级记忆或知识库？
19. 怎么解决「经验随人走」？
20. 云端 Agent 平台怎么推进？老旧服务怎么接入？
21. 动态 workflow 怎么实现？
22. 大模型写代码第一次不对，流程断不断？失败怎么回退？
23. 大模型幻觉怎么解？说执行了其实没执行怎么办？
24. 知识层怎么约束？RAG 怎么强制事实锚定？
25. 为什么配多 Agent 而不是全 CLI 或脚本？
26. 多 Agent 之间交互逻辑怎么实现？
27. 模型调用 RPC 耗时长怎么办？同步与异步链路怎么设计？
28. 异步用什么框架？
29. 几千个业务能统一 Agent 流程吗？怎么合并？
30. 项目大重构的思路是什么？正交与冗余怎么处理？

手撕

31. 如何用 PyTorch 实现双塔召回模型的前向传播？

项目追问

32. 深挖 CR Agent 项目：这个 Agent 是怎么设计的？团队里还有哪些 Agent？
33. 从 2022 年到现在，整个 Agent 与大模型的技术演进是怎样的？你参与过哪些框架设计？

---

《参考解析》

智能客服 Agent 的难点与职责拆分

难点可以归成四类：边界（用户什么都问，超出商品与订单范围的问题要能识别并礼貌兜住）、状态（售后是长流程、跨多轮甚至跨天，必须有可恢复的会话状态与工单关联）、数据权限（订单、退款、地址属于敏感数据，工具调用前要校验身份与归属，不能让模型凭对话自述就查别人的单）、确定性要求（答复口径、赔付规则、时效承诺不能由模型自由发挥）。

职责拆分按「业务域 + 状态机」切更稳：售前咨询偏检索与推荐（知识库问答、商品对比、优惠解释，可容忍一定灵活性）；订单查询偏工具调用（订单状态、物流、发票，答案唯一、要精确、要带数据来源）；售后投诉偏流程与升级（先判定诉求类型与责任归属，能自助处理的走规则与工具，触碰到赔付、责任争议、情绪激烈时转人工，并带上已收集的信息）。三个 Agent 之间不要互相调用成环，而是由一个入口做意图路由、共享同一份会话与用户上下文，各自只负责自己那段流程。

记忆设计：短期与长期

短期记忆是当前会话的上下文窗口：最近若干轮原文 + 会话摘要 + 结构化的槽位状态（订单号、诉求类型、已尝试的方案），窗口快满时把最早的几轮压缩成摘要，硬信息（金额、单号、承诺时效）单独留结构化字段，不能只留流水账。长期记忆是跨会话的用户与业务事实：用户偏好、历史诉求、处理结论，写进外部存储按需检索，而不是每轮全量塞进 prompt。工程上要配上写入过滤（低信息量、重复内容不入库）、冲突覆盖（口径变了旧记忆失效）、召回限额与时效标注（告诉模型这条记忆是什么时候的），以及敏感信息的脱敏与保留期限。

量大了怎么扛，挂了怎么兜

量大的解法是「分流 + 缓存 + 异步」三件事：入口先做意图识别，能用规则、FAQ 检索、小模型解决的不进大模型；高频问题的答案与工具结果做缓存（相同订单号短时间内的查询没必要重复打后端）；长流程拆成异步任务，用户侧给进度反馈而不是干等；模型侧做请求排队与配额、批处理与流式输出降低单请求成本。架构上没有状态才能水平扩容，会话状态放 Redis、任务状态放队列。

挂了要分「模型挂」和「工具挂」两层兜：模型不可用时降级到检索式 FAQ 加规则引擎，再不行直接转人工并把上下文带过去；工具接口失败要有超时、有限重试、熔断和幂等键，写操作必须有回执校验，不能重试出两笔退款。高并发下的容灾标准答案是分层隔离（不同业务线独立资源池）、限流与排队保护下游、降级开关（按业务分级，先牺牲非核心推荐理由这类能力）、以及全链路可观测——每个请求要能查到走了哪个模型、哪次工具调用、在哪一步失败，否则出故障只能靠猜。

推荐链路：大模型能做什么

Query 理解层做意图与属性抽取、口语化改写、时效与场景补全；召回层做语义向量召回、生成式召回、以及多路召回的融合；排序层大模型更多是给精排做特征、做多样性与业务规则重排，或者对小候选集做 listwise 重排；推荐理由生成是最适合大模型的环节，把结构化事实翻译成自然语言，但必须锚定在真实属性上，不能编造卖点。

「夏天穿什么」这种 query 的个性化要拼接上下文：query 语义 + 地域与实时天气 + 用户画像与历史行为 + 库存与时效，天气这类动态信号通常做成特征或在检索前做一次查询改写（比如把「夏天」细化成具体品类与材质），而不是让模型凭空推理。用户行为序列要进大模型，主流做法是先用行为建模（序列模型或兴趣向量）压成定长的兴趣表示，或者把最近若干条行为转成语义描述（商品标题、类目、动作、时间），两者结合：既保留 ID 侧的协同信号，又让模型能读懂。

双塔召回与生成式召回

双塔是双路编码：用户侧塔编码画像与行为，商品侧塔编码标题、类目、属性，两侧各自出向量做内积或余弦，商品向量可以离线预计算建索引（Faiss、HNSW 之类），在线只算用户塔，延迟低、可扩展到亿级商品，代价是两塔不能交叉、表达能力受限，只能靠特征工程补。生成式召回（TIGER 一类语义 ID 方案）把商品离散成语义 ID，用序列生成的方式直接产出候选，好处是能引入上下文与序列建模、天然做多路融合，问题是需要额外训练、可能生成无效 ID、线上要做合法性校验且推理成本高。工程上的常见结论是双塔打底做大规模召回，生成式或大模型 re-rank 叠在上面做提效，而不是彼此替代。

信息茧房与 AB 实验

茧房的本质是反馈闭环里只放大已证明的兴趣，解法是显式引入探索：ε-greedy 或 Thompson Sampling 做探索利用平衡、在排序目标里加入多样性与新颖度约束、做兴趣衰减让老偏好自动退场、控制相似商品在列表里的重复度。评估上要同时看短期指标（点击、转化）和长期指标（次日/七日留存、复访类目数、退货率），只看点击会把茧房越养越深。

AB 实验的基本功是：先定唯一的核心指标和护栏指标（延迟、成本、退款率），按用户或设备维度做随机分流保证同组体验一致，算清最小样本量与实验周期（至少覆盖一个完整行为周期），避免用一天的数据下结论，注意多重比较与网络效应（推荐场景下同群用户会互相影响），最后看细分维度是否出现「总体涨、某类人群跌」。文案类优化的指标通常是 CTR、CVR、以及下拉/停留这类过程指标。

Agent 架构与 Skill 治理

整体架构讲清分层就够：入口与路由层（鉴权、意图识别、分流）、编排层（规划、步骤状态机、失败重试、人工节点）、能力层（工具与 Skill，统一用 schema 描述）、记忆与知识层（会话状态、长期记忆、检索）、模型层（按任务选模型与推理档位）、可观测与评测层（轨迹落盘、成本与延迟、回归评测集）。

Skill 泛滥与上下文窗口是同一枚硬币：知识不该常驻在系统提示里。做法是分层 + 按需加载——系统提示只放技能索引（名字 + 一句话描述 + 触发条件），模型先决定要不要用，再把对应文档读进上下文；技能之间做去重与合并，粒度按「一个可完成的任务」而不是「一段知识」切；版本化、定期用真实任务回归淘汰没被调用过的技能。确实需要长流程时把它做成工具或工作流，而不是靠一堆提示词拼出来。

为什么要用 Agent、而不用平台或 API

平台/API 解决的是「调用模型」，Agent 解决的是「完成一件需要多步、需要判断、需要接触真实系统的事」：它能把不确定的自然语言输入收敛成确定的多步执行，能在中间步骤失败时换路，能把自己的过程记录下来给人审计。回答时最好绑定一个真实收益：以前要人工点五步的操作，现在一句话走完，且每一步都有回执——而不是说「Agent 更先进」。

「你现在做的 Agent 效果如何」这类题要给可核对的指标：任务完成率、人工接管率、平均步数与 token 成本、端到端延迟、线上 badcase 的典型模式，并且说清评测集怎么建的。答不出数字，前面的架构讲得再好也会被认为没上线。

经验随人走与部门知识沉淀

「经验随人走」的解法是把人脑子里的隐性知识变成可执行资产，分三层：知识（业务规则、SOP、口径，写成结构化文档并挂到检索里）、工具（把重复操作封装成有 schema 的工具，谁都能调）、评测（把历史 badcase 与验收标准固化成回归集，换模型、改流程先跑一遍）。沉淀机制上要有人负责（owner + 评审）、有更新触发（线上问题必回写）、有消费入口（新人在 Agent 里直接问得到），否则文档写完就烂在库里。

幻觉、假执行与事实锚定

模型说「已执行」但实际没执行，根因是把模型的自然语言当成事实来源。正确做法是状态只由程序的回执决定：工具调用返回什么、数据库里写了什么，才是执行结果；模型只能转述结构化回执，不许自述。工程上加三道闸——工具调用要有明确返回码与幂等键；关键动作落库并回读校验；对外承诺（已退款、已改地址）必须由回执驱动。

幻觉的抑制则是概率问题，做法是收窄自由度加验证：能自动补全的参数不要问模型、不允许输出未在检索证据中出现的事实、回答里带上引用来源并做引用校验（引用的片段真存在且支持该结论）、对高确定性场景（订单、金额、时效）直接走模板而不是生成。RAG 强制事实锚定就是这几条的组合：先检索再答、证据不足时明确说「查不到」、生成后做一次事后校验，把无依据的断言拦下来。

多 Agent 与交互实现

用多 Agent 而不是全 CLI/脚本，理由是并行、隔离与可治理：不同 Agent 有各自的工具权限与上下文，可以并行跑互不干扰，失败范围可控，出了事能单独限流或替换；脚本适合确定性、步骤固定的任务，一旦需要判断和异常处理就会迅速长成一堆 if-else。代价是通信成本与协调复杂度，所以能用工作流表达的就别上多 Agent。

交互实现上有几种典型形态：编排者-执行者（主 Agent 规划、子 Agent 执行并回结构化结果）、流水线（前一个的输出是后一个的输入）、黑板/共享状态（多个 Agent 读写同一份上下文，需要加锁或版本号）。落地要点是统一的消息与结果协议（谁调的、参数、结果、耗时、失败原因）、共享状态放在外部存储而不是塞回 prompt、给每个 Agent 明确的能力清单与终止条件、避免互相触发成环。

模型调用链路的性能与异步

模型 RPC 慢是常态（几秒到几十秒），同步链路会同时占住连接、线程和用户耐心。设计上分三类：能流式的走流式，让用户先看到第一个字；能并行的并行（多路检索、多个子任务）；长任务全异步——提交成任务拿 taskId，前端轮询或走推送，服务端用队列削峰。接口层面要有超时与预算（单步超时、整任务预算）、幂等（重试不会重复产生副作用）、以及断点续跑（中间结果落盘，失败从最后一步接着做，而不是重头再来）。

异步框架按语言和团队来选：Python 侧轻量用 asyncio + FastAPI 加 Celery/RQ，要长流程编排、重试与可视化就用 Temporal、Airflow、Dagster 这类工作流引擎；跨服务解耦用 Kafka、RabbitMQ 等消息队列，配死信队列处理反复失败的任务。追问常落在「任务状态放哪」（Redis 或数据库，别放进程内存）、「怎么保证不重复消费」（幂等键 + 去重表）、以及「怎么观测」（traceId 贯穿全链路）。

几千个业务能不能统一 Agent 流程

不能靠一套流程硬套，而是分层抽象 + 配置化：底层统一（模型接入、工具协议、记忆存储、评测与观测），中间层把常见形态固化成几种模式（问答检索型、数据查询型、长流程办理型、内容生成型），业务层只填配置（用哪些工具、走哪种模式、验收标准是什么）。合并的前提是先做口径统一——同一个概念在不同业务里的字段与规则对齐之后，才谈得上复用；实在差异大的就并存，用统一的入口和观测来管理，而不是强行合并成一个巨型流程。

大重构的思路也是这两条：正交——按职责切分模块，让每个模块的变化原因唯一，公共能力下沉、业务差异上浮，依赖方向单向不回头；去冗余——同一份逻辑只留一个事实来源，把复制粘贴出来的多份实现收敛成一份带配置的实现，并靠回归评测集保证收敛不改变行为。改造节奏上先加测试与观测、再小步替换、保留开关可回滚，别一次性大爆炸。

手撕：双塔召回的前向传播

要点是把结构写清楚而不是写得花：用户塔和商品塔各自是 embedding 查表 + 若干层 MLP（Linear → 激活 → Dropout → Linear），输出的向量做 L2 归一化，再用内积（等价于余弦相似度）算分数。训练时用 in-batch 负采样：一个 batch 里用户与商品的相似度矩阵，对角线是正样本，其余是负样本，除以温度系数后做交叉熵（cross_entropy 对行和列各算一次即对称损失）；推理时商品向量离线算好建索引，在线只跑用户塔。代码里要注意维度对齐、dim=-1 归一化、温度参数 logits / tau，以及 mask 掉 padding。