系统设计篇

综合应用五套课件的知识。系统设计题是区分"知识点都会但没串起来"和"能独立交付"的关键题型。答题套路统一：先问清楚需求 → 给分层架构 → 每层给选型和理由 → 主动暴露风险和演进。面试官在这一环节最看重的是结构感和取舍意识，不是方案完美。本篇 7 题覆盖知识库、研究、客服、BI、网关五类高频场景。

---

Q01 · 设计一个企业知识库问答系统

难度：★★★★ ｜ 频率：极高 ｜ 对应课件：LangChain指南/06-08、agent核心/15

面试官：给你一个场景：5000 人规模的公司，各部门有内部文档（Confluence 导出、PDF 制度文件、Excel 台账），要做一个人人可用的问答系统。要求带引用溯源，且各部门文档不能互相泄露。设计一下。

第 1 层追问：先反问需求

你会先确认什么？

参考回答：先问四个问题再画图，这是系统设计的基本功。一，问答性质：事实型（"年假多少天"）还是综合型（"总结竞品策略"）——决定检索粒度和生成复杂度。二，数据规模与更新频率：十万级文档、天级更新 vs 百万级、小时级——决定入库管线是批处理还是流式。三，权限模型：按部门隔离还是文档级 ACL——直接决定检索层设计（这是本题最大的坑）。四，验收标准：正确率要求多高、能不能拒答——决定要不要上人工反馈闭环。不问需求直接画图，是初级工程师的典型动作。

第 2 层追问：架构分层

给你的总体设计。

参考回答：五层管线 + 一条回环。入库层：文档解析（PDF/Confluence 各自的 Loader）→ 按结构切割（Markdown 尊重标题层级、CSV 一行一 Document）→ embed_documents 批量嵌入（分批 + Semaphore 限流 + 断点续跑）→ 入向量库，metadata 必带：部门/权限标签/文档 id/更新时间。检索层：embed_query → 向量检索 + BM25 混合 → RRF 融合 → cross-encoder 重排取 top5；权限过滤在检索入口处用 metadata filter 强制注入（不是事后过滤——事后过滤会把结果滤空，事前过滤缩小检索范围）。生成层：RunnableParallel(context=retriever|format_docs, question=Passthrough) | prompt | model，提示词铁律"只依据材料回答，没有就说不知道"，temperature≈0。溯源层：结构化输出带引用块 id，校验引用真实存在才渲染。回环：用户点赞/点踩 + 失败案例回流评测集。

第 3 层追问：权限你怎么保证不泄露？

这是最关键的安全问题，具体说。

参考回答：三道防线。一，检索入口强制 filter：用户身份 → 可见文档集合 → 作为向量库 filter 条件，在相似度计算之前生效——这是唯一正确的位置，模型永远拿不到无权文档的向量。二，生成层兜底：就算混进了无权内容，提示词 + 引用校验让答案必须可溯源到用户可见的块，引用不到的内容出不来。三，审计：每次检索记录"谁、用什么 filter、命中哪些文档 id"——出事可倒查。反模式警告：把所有文档塞上下文再让模型"自己注意权限"是绝对红线——提示词是软约束，权限是安全边界，安全边界必须放在确定性代码里，这是课程"权限控制"一节的核心主张。

第 4 层追问：上线后怎么迭代？

系统跑起来了，怎么持续变好？

参考回答：两条数据线 + 一条评测线。数据线一（文档侧）：监控"检索为空"的 query 分布——高频空检索的 topic 说明知识库覆盖缺口，推动对应部门补文档。数据线二（用户侧）：点踩日志 + 追问"这不是我要的"聚类分析，定位是检索问题还是生成问题（分段归因：检索命中了吗？命中了但没用上吗？）。评测线：月度回归——固定测试集（含负例）跑命中率/MRR/忠实度，防止某次换嵌入模型/改切割参数引入回退。升级路径预留：单轮检索答不好的综合问题，后续升级为"Agent 化"——先检索、发现不够再深挖多轮，但初版不上 Agent，用最简单的架构满足需求。

考察意图与踩坑点

• 考察意图：这是 AI 应用岗最常见的系统设计题。核心考察权限在检索层的正确位置（能答出的人立刻脱颖而出）和 RAG 全链路的完整度。
• 踩坑点：权限靠提示词"嘱咐模型"（安全红线）；事后过滤导致结果为空；没有拒答/负例意识；一开始就上多 Agent 炫技。
• 一句话总结：五层管线 + 引用校验回环；权限在检索入口强制 filter，安全边界放确定性代码，绝不放提示词。

---

Q02 · 设计一个联网深度研究 Agent（DeepResearch）

难度：★★★★ ｜ 频率：高 ｜ 对应课件：agent核心/08、09

面试官：做一个"深度研究"产品：用户提一个开放问题（如"对比主流向量数据库的选型建议"），系统联网查证并给出带引用的综合答案。设计核心架构。

第 1 层追问：为什么这是 Agent 而不是链？

先论证技术选型。

参考回答：因为研究任务的步骤写不死。要搜几次取决于第一轮结果质量、读哪些页取决于搜索返回的 URL、要不要换角度取决于已收集信息的相关性——路径强依赖中间结果，必须让模型在运行时决定控制流。这是 Agent 的正当主场（对照选型框架：分支不可枚举 + 多轮依赖 + 失败要换路 + 目标明确路径开放）。同时引用课程实战的克制结论：两个小工具 + 主循环就够起步，不需要一上来就多 Agent。

第 2 层追问：核心架构

给出你的设计。

参考回答：三层。工具层（关键设计）：只给两个正交小工具——web_search(query)（返回标题+URL+摘要列表）和 read_webpage(url)（返回清洗截断后的正文关键段，绝不把原始 HTML 塞上下文）。行为层：系统提示词定义角色（"严谨的研究员，结论必须给出来源，冲突信息要交叉验证"）+ 策略提示（"多角度并行搜索，结果不足时换关键词"——给模型"承认失败换方向"的合法出口）；ReAct 主循环串起来。工程层：四道闸门（自然终止/轮次上限/token 预算/重复检测）+ 事件轨迹全量落日志 + 检测到卡带时的纠偏提示注入。涌现的价值：工具小而正交，模型自己发展出"并行多路搜索 → 筛选 URL 精读 → 交叉对比"的策略——策略是运行时组合的，不是代码写死的。

第 3 层追问：引用可信怎么保证？

答案里的引用，怎么防止模型编造 URL？

参考回答：引用链全程可验证，分三步。一，来源白名单：模型只能引用工具返回结果里的 URL——read_webpage 没读过的链接不进引用池；工具返回结构里带 URL+标题，Agent 的最终输出要求引用映射到这些实体。二，生成后校验：结构化输出（JSON：结论 + 每条依据的 url + 摘录），校验器逐条核对 URL 是否出现在本次轨迹的工具返回里——编造的引用直接打回重试。三，冲突标注：多来源信息冲突时提示词要求明示"来源 A 说 X，来源 B 说 Y"——研究产品的可信度不来自"语气自信"，来自可核验。

第 4 层追问：成本和延迟怎么控制？

一次深度研究可能十几轮，用户要等几分钟。怎么办？

参考回答：四板斧。一，过程可视化：流式吐出"正在搜索 X → 正在阅读 Y"的步骤事件——研究产品的体验核心是过程可感知，用户愿意为透明的过程等，不愿意为黑盒转圈等。二，预算分层：预检问题的难度（简单事实题直接单轮搜索回答，只有开放研究题才进深循环）——先路由再深跑。三，结果缓存：同题或近题的最终报告缓存复用（嵌入相似度判断"近题"）。四，异步化：长研究任务转后台作业 + 完成通知，把"等待"从产品体验里剥离。成本意识贯穿始终：每轮 token 都要给用户换来可见的信息增量，闸门 + 轨迹复盘就是在监控这件事。

考察意图与踩坑点

• 考察意图：这题直接对应课程第九章的完整实战——答得好等于证明你把"小工具 + 闸门 + 引用链"这套生产化组合拳内化了。第 3 层引用校验是多数候选人完全想不到的点。
• 踩坑点：一上来设计三个 Agent 协作（过度工程）；工具返回原文不清洗（上下文爆炸）；没有闸门和预算层。
• 一句话总结：两个正交小工具 + ReAct 主循环 + 四道闸门 + 引用白名单校验——生产级研究的骨架，简洁压倒炫技。

---

Q03 · 设计一个电商客服 Agent

难度：★★★ ｜ 频率：高 ｜ 对应课件：langgraph框架指南/10、14、agent核心/15

面试官：为电商平台设计客服 Agent：能查订单、改地址、处理退款，复杂情况转人工。注意有写操作，出错的代价是真金白银。

第 1 层追问：总体架构

怎么组织这个系统？

参考回答：LangGraph 图 + 局部 Agent 的混合架构，不是单一巨型 Agent。流程图化：意图识别节点（分类：查单/改地址/退款/闲聊/投诉）→ 固定工具节点（查订单是确定性 API 调用，不需要模型决策）→ 退款处理子图（真 Agent：原因多样、要收集证据、路径开放）→ 人工转接节点。关键决策理由：能用固定链解决的绝不上 Agent——查单这种步骤完全确定的操作，走模型决策纯属浪费 token 和延迟；只有退款谈判这种路径开放的任务才给模型决策权。这就是"图里嵌 Agent"的标准形态。

第 2 层追问：写操作的安全设计

改地址、退款都是写操作，怎么防模型出错？

参考回答：三道闸。一，权限分级：读操作（查订单）Agent 自主执行；写操作（改地址、发起退款）一律 interrupt 人在回路——LangGraph 的 interrupt() 暂停，前端渲染"模型提议：将订单 X 的地址改为 Y，确认吗？"，用户点击后 Command(resume=决定) 恢复。二，参数校验前置：模型给的参数先过 Pydantic 业务校验（订单号存在且属于当前用户、新地址格式合法）再进确认环节。三，幂等与可回滚：写接口设计成幂等（重试不重复扣款），退款走先冻结后执行的二段式。核心原则：模型的决策是"提议"，人的确认是"批准"，系统的校验是"底线"——三者缺一不可。

第 3 层追问：转人工怎么设计？

什么时候转、怎么转？

参考回答：三个触发器 + 一个交接协议。触发器：情绪触发（用户表达愤怒——分类器判定）、能力触发（Agent 连续两轮没解决/闸门触发/模型自己输出"需转人工"意图）、业务触发（涉及金额超阈值的退款必须人工复核）。交接协议：转人工时上下文要完整打包——会话历史 + Agent 已做的事（查过什么、提议过什么、用户拒绝过什么）+ 未完成的诉求，客服接手不需要用户重新讲一遍——交接质量是客服产品体验的分水岭，也是 LangGraph thread 状态导出的标准用法。回归路径：人工处理完后会话状态更新，用户再找 Agent 能看到人工结果——单一 thread 贯穿始终。

第 4 层追问：怎么衡量这个 Agent 好不好？

上线后的北极星指标是什么？

参考回答：分三层。业务层（北极星）：自助解决率（不转人工闭环的比例）——降本的核心数字；同时盯转人工后的二次投诉率（防止 Agent"假解决"把麻烦推给后面）。质量层：写操作的事故率（改错地址/退款错误的绝对数——写操作事故是长尾，一票否决式监控）、意图识别准确率。体验层：响应延迟 P95、会话轮次（异常长的轮次往往意味着 Agent 在绕路）。配套机制：全量轨迹 + 抽样人工质检，事故案例强制进回归测试集——客服 Agent 的迭代是案例驱动的，不是灵感驱动的。

考察意图与踩坑点

• 考察意图：客服是 Agent 落地最广的场景，这题考读写分离的权限意识和混合架构的克制——全 Agent 化方案是典型的过度设计信号。
• 踩坑点：所有操作都给模型决策权；写操作不设人工确认；转人工不打包上下文（用户体验的隐形杀手）；只汇报"能回答多少问题"不监控写操作事故。
• 一句话总结：图里嵌 Agent——确定的事走链、开放的事给模型、写的事必须人批；交接打包上下文，事故一票否决。

---

Q04 · 设计一个多 Agent 协作的报告生成流水线

难度：★★★★ ｜ 频率：中（对得上 LangGraph 课程的人极少）｜ 对应课件：langgraph框架指南/07、10、agent核心/12

面试官：要做一个"行业分析报告"生成系统：给定一个主题，产出一份结构化报告——需要并行调研多个子方向、汇总成稿。你怎么设计？

第 1 层追问：为什么用多 Agent？

先论证：单 Agent 不行吗？

参考回答：单 Agent 会撞两堵墙。上下文墙：一个 Agent 串行调研 5 个子方向，每个方向的搜索结果/阅读材料都堆在同一个上下文里——很快爆窗，且互相稀释注意力。串行延迟墙：5 个方向顺序调研，时间线性叠加。多 Agent 方案的本质：每个子 Agent 有独立上下文（互相不污染）+ 并行执行（时间由最长分支决定）。但要带着代价意识说：多 Agent 的协调误差和 token 放大是真实成本——所以任务确实"大到单 Agent 装不下"才用，这是课程多 Agent 选型的前提。

第 2 层追问：架构设计

具体怎么编排？

参考回答：map-reduce 模式，LangGraph 的 Send 就是为此而生的。规划节点：LLM 把主题拆成 N 个子方向（返回结构化列表）。动态扇出：规划节点后的边返回 N 个 Send("调研子节点", {"方向": 子方向_i, "私有载荷"})——N 是运行时决定的（不同主题拆出 3 个或 7 个方向），这正是条件边做不到的（条件边只能从编译期枚举的分支里挑）。调研子节点：每个实例只拿私有载荷（不是全量状态——每个分支不背别人的包袱），独立跑 ReAct 循环（联网查证），返回补丁写入 findings 列表。两个 reducer 关键点：findings 必须挂追加 reducer（N 路并发写入）；汇合的汇总节点要防"跨超步到达重复触发"（超步陷阱，见 LangGraph 篇 Q03）。汇总节点：拿到全部 findings 后综合成稿——单 Agent、大上下文、一次性生成。

第 3 层追问：失败怎么处理？

5 个调研分支挂了 2 个，整个报告怎么办？

参考回答：分级降级，不整体报废。一，分支级隔离：单个子调研失败（超时/闸门触发）只标记该分支 status=failed，不阻断其他分支——Send 的各实例天然隔离，这是架构送的红利。二，汇总级感知：汇总节点的提示词要求"基于成功的 findings 生成，缺失部分在报告中明示'本报告未覆盖 X 方向'"——诚实的缺口标注好过假装完整。三，补漏机制：汇总时发现某关键方向缺失，可以再发一轮 Send 定向补调研（动态扇出的二次利用）。四，资源兜底：全部失败（如联网服务整体故障）走纯参数知识 + 免责声明的降级版。Checkpointer 在这里的加成：长流程跑一半崩了，从 checkpoint 续跑，已完成的调研分支不重跑。

第 4 层追问：结果质量怎么保证？

报告是给人看的，怎么避免"结构工整、内容注水"？

参考回答：三道工序。一，子调研带证据规范：每个 finding 强制结构化（结论 + 依据来源 + 置信度）——子 Agent 的输出协议决定上游材料质量，上游注水下游必然注水。二，汇总前先"审稿"：在汇总节点前加一个轻量校验环节（LLM 裁判或规则）：过滤低置信度 finding、去重、标记互相矛盾的结论交给汇总节点显式处理。三，终稿自评 + 修订循环：生成初稿后跑一轮"编辑审稿"（对照主题检查覆盖度、逻辑一致性），不合格回炉——用图的条件边做"质检-修订"循环（最多 N 轮，闸门思想）。报告系统的差异化不在"能生成"，在"敢署名"。

考察意图与踩坑点

• 考察意图：这是 LangGraph 课程的招牌场景（对应 asyncio 实战和 Send 章节），能把 Send 动态扇出 + reducer + 汇合陷阱在一道题里串起来讲的人，几乎一定是真学过这套课程或做过类似系统。
• 踩坑点：用固定 5 个并行节点硬编码子方向（表达不出运行时扇出）；汇总节点不知道防重复触发；失败即全盘报废；报告质量靠"换个好模型"。
• 一句话总结：规划 → Send 动态扇出独立调研 → reducer 汇合 → 审稿汇总——map-reduce 的 Agent 版，失败分级降级，质检节点循环。

---

Q05 · 设计高并发 LLM 应用的服务架构

难度：★★★ ｜ 频率：中 ｜ 对应课件：Python框架指南/14、agent核心/13

面试官：你的 Agent 服务要支撑峰值 500 QPS，单次请求涉及多轮 LLM 调用，预算有限。FastAPI 层到 LLM 层，整个链路怎么设计？

第 1 层追问：并发模型选型

服务端用什么并发模型？为什么？

参考回答：FastAPI + asyncio 协程，因为负载是IO 密集型——每请求的耗时大头在等 LLM 返回（秒级），CPU 几乎空闲。协程（事件循环挂起等待 IO）比线程省资源得多（单进程数千并发连接 vs 线程数受内存限制），课程里"事件循环 → Future 与协程 → asyncio 实战"三章就是为这个场景铺的路。关键实现纪律：LLM 调用必须用异步客户端（httpx/AsyncOpenAI）——在事件循环里用同步阻塞调用，一个请求就把整个 loop 卡死，这是 FastAI/async 最经典的翻车点。

第 2 层追问：瓶颈在 LLM 服务，怎么办？

你的应用层 500 QPS 没问题，但 LLM API 限速 50 并发。这层怎么过？

参考回答：四件套。一，全局限流闸：asyncio.Semaphore(50) 包住所有 LLM 调用——在自己的边界内排队，好过把压力打给上游被 429；配合请求队列和超时，对外表现为"变慢"而不是"失败"。二，缓存层：语义缓存（问题嵌入 → 相似问题命中缓存答案，RAG 基建的复用）+ 精确缓存（固定上下文的重复请求，如 prompt 前缀的 KV 缓存命中）；热点问题通常集中在头部，缓存收益超直觉。三，降级矩阵：超载时按优先级丢——先降模型档位（大模型 → 小模型），再降功能（流式 Agent → 固定链兜底回复），最后限新请求保存量会话。四，成本预算护栏：全局限流 + 单请求 token 预算（Agent 的闸门在服务层再加一道），防止高峰期 token 账单失控——峰值 500 QPS 的多轮 Agent，烧钱速度是乘法关系。

第 3 层追问：状态和长任务怎么管理？

Agent 是长任务（几十秒），HTTP 请求怎么扛？

参考回答：同步壳 + 异步核。短任务（单轮问答）：SSE 流式响应（课程 FastAPI 篇第 14 章）——HTTP 连接挂着，token 逐块推送，用户体感流畅。长任务（多轮研究）：提交-查询模式——POST 提交返回 task_id，后台任务跑（任务队列 + LangGraph 的 Checkpointer 存进度），前端轮询或 WebSocket 订阅进度；HTTP 请求绝不为长任务保持几十秒（超时、重试、网关都在为难长连接）。状态归置：会话历史进持久化存储（thread_id 关联），服务实例无状态化——任意实例可接任意请求，才能水平扩容。

第 4 层追问：可观测性呢？

上线后你怎么知道链路哪里慢、哪里贵？

参考回答：三张图 + 一条链路。三张图：延迟分布（P50/P95/P99 分解到环节：检索/每轮 LLM/工具执行）、token 成本流（按 endpoint/用户/模型档位聚合的每分钟美元）、错误率（按类型：超时/限流/解析失败/闸门触发）。一条链路：全链路 trace——用 context 注入 request_id，Agent 的事件轨迹（轮次、工具调用、token 数）按请求聚合，一次慢请求能展开看到"卡在第 3 轮的 web_search 8 秒"。告警绑业务：闸门触发率突增、语义缓存命中率骤降、单用户成本异常——这些比 CPU 告警早发现问题。可观测不是锦上添花：LLM 应用的故障是"静默变贵/变慢/变错"，没有指标等于盲飞。

考察意图与踩坑点

• 考察意图：考后端基本功和 LLM 特有问题的结合——限流在自己边界内、降级矩阵、长任务异步化三个点答出，就是"AI 应用工程师"而不只是"调 API 的"。
• 踩坑点：事件循环里用同步客户端；把压力直接打给上游被限速；长任务挂长连接；没有成本维度的监控（LLM 应用的独特盲区）。
• 一句话总结：asyncio 扛并发、Semaphore 守上游、缓存削峰、降级矩阵保体验、长任务异步化、成本和延迟一起监控。

---

Q06 · 设计一个 ChatBI：让业务人员用自然语言查数据

难度：★★★★ ｜ 频率：高（数据方向必考）｜ 对应课件：agent核心/07-09（工具调用与 schema）、LangChain指南/08

面试官：公司有数仓，业务人员不会 SQL，天天找分析师拉数。设计一个自然语言查数的 ChatBI，怎么做？

第 1 层追问：先澄清需求

你会先问清哪些问题？

参考回答：三个关键澄清。用户是谁：业务运营——会问"上个月华南区销售额多少"，不懂数仓表结构。数据在哪：数仓 + 已有指标平台（有多少现成指标可复用，直接决定方案）。错的代价多大：ChatBI 的特殊之处——查询结果错一个数，业务会基于错误数字做决策，危害比闲聊幻觉大得多，所以准确性优先级压倒一切。

第 2 层追问：整体架构

核心链路怎么设计？

参考回答：五段管线。意图识别：闲聊 / 数据查询 / 模糊待澄清，先分流。语义层（关键设计）：不直接对数仓裸跑 Text2SQL——先建指标字典，把"销售额"映射到受控的指标定义（口径、维度、过滤条件），把模糊业务词对齐到规范词表。查询生成：拿语义层对齐后的结构化意图生成 SQL 或调用指标 API，表结构 + 指标定义 + few-shot 样例注入 prompt。校验执行：只读账号、表白名单、强制 LIMIT、超时控制。结果表述：数字 + 口径说明（"销售额，含税，口径为支付时间"）+ 图表——口径说明是 ChatBI 的信任基石。

第 3 层追问：准确性和安全怎么保？

模型编造指标、越权查数怎么办？

参考回答：四个防线。宁可澄清不要编造：问的指标在语义层不存在或口径歧义（"销售额"含税不含税），反问澄清而不是硬猜——幻觉在 BI 场景是灾难。执行前校验：只读账号 + 白名单表 + LIMIT + 超时，生成的 SQL 过一道解析校验再放行。行级权限：查询自动拼接数据权限过滤，用户只能看到权限内的数据——权限在执行层兜底，不依赖 prompt。置信度兜底：低置信度路由到人工/分析师，别让边缘 case 污染信任。

第 4 层追问：怎么评估和演进？

上线怎么迭代？

参考回答：评测集：收集真实业务问题 + 标准答案，持续测查准率；错误要分类——指标错、维度错、过滤条件错、语法错，不同类对应不同修法（指标错修语义层，语法错加 few-shot）。沉淀飞轮：高频问题固化成语义层指标和缓存，用户越用越准越快。演进方向：从单轮 Text2SQL 到 Agent 化——多轮澄清、SQL 报错自动修复重试、跨指标对比分析。

考察意图与踩坑点

• 考察意图：考"幻觉高风险场景的工程约束"——候选人有没有意识到 ChatBI 的核心矛盾是用概率系统产出确定性数字，以及用语义层、校验、澄清机制对冲它的能力。
• 踩坑点：直接对数仓 schema 裸跑 Text2SQL（错误率不可接受）；不提权限和只读校验；没有"宁可澄清不要编造"的意识。
• 一句话总结：语义层对齐业务词、执行层校验权限、模糊就澄清——ChatBI 用工程约束把概率系统逼成确定性输出。

---

Q07 · 设计一个 LLM 网关（模型接入层）

难度：★★★ ｜ 频率：中（中大型公司/架构岗高频）｜ 对应课件：Python框架指南/14、agent核心/13

面试官：公司十几个业务都要接大模型，各家 API 都在用。让你设计统一的 LLM 网关，解决什么问题、怎么设计？

第 1 层追问：为什么需要网关

不就调个 API 吗，统一它干嘛？

参考回答：三个真实痛点。供应商分散：不同任务适合不同模型（简单分类用小模型、复杂推理用大模型），各家 API 协议、参数、流式格式、错误码都不同——业务代码直接对接等于每家绑死一份。治理集中：密钥管理、成本计量、限流、审计，这些不该散在每个业务里各自实现。容灾：供应商超时、限流、宕机时要能切换，没有统一层就没法做降级链。

第 2 层追问：核心能力

网关具体提供什么？

参考回答：四块。协议适配：对内统一接口（事实标准是 OpenAI 协议），对外适配各家差异——业务方一套代码接所有模型。路由策略：按任务类型路由（分类走小模型、推理走大模型）、按成本路由、按健康度路由——主模型 429/超时自动切备模型。弹性能力：重试（指数退避 + 尊重 Retry-After）、熔断、超时分级控制。配额与预算：按业务方的 token 配额管理、预算告警——防止某个业务失控烧钱拖垮全公司账单。

第 3 层追问：可观测和成本

成本怎么管清楚？

参考回答：网关是成本治理的天然卡点。全量调用日志：业务方、模型、token 用量、延迟、错误码——这是计量计费和成本分摊的数据底座。缓存下沉：语义缓存、固定前缀缓存放网关层，全公司共享收益。告警体系：错误率、延迟、token 成本异常——比业务自己发现"这个月账单怎么这么高"早得多。

第 4 层追问：有什么坑？

设计上要小心什么？

参考回答：三个坑。流式透传：SSE 转发要处理好超时和背压，网关别成为流式链路的瓶颈。抽象泄漏：某家模型的独特参数和行为统一不掉——要留 escape hatch 允许透传原始请求，别为了统一接口阉割能力。别过度设计：两家供应商、三个业务方之前，一个薄适配层就够——网关的规模应该随规模长出来，不是第一天就上全家桶。

考察意图与踩坑点

• 考察意图：考架构层面的"统一治理"意识——能不能把散落的共性能力（鉴权、路由、计量、容灾）识别出来收口到一层，这是从业务工程师到架构工程师的分水岭。
• 踩坑点：只会答"统一封装 API"；漏掉路由降级和成本计量这两块核心价值；不提 escape hatch（强行统一所有模型能力的接口会阉割能力）。
• 一句话总结：协议统一是壳，路由降级 + 成本计量 + 容灾才是魂——网关让"换模型"从改造变成配置。

---

本篇速记卡

题	一句话核心
Q01 知识库	五层管线；权限在检索入口 filter，安全边界不进提示词
Q02 深度研究	两个小工具 + 闸门 + 引用白名单校验；过程可视化对冲等待
Q03 客服	图里嵌 Agent；读自主、写审批；转人工打包上下文
Q04 报告流水线	Send 动态扇出 + reducer 汇合 + 审稿循环；失败分级降级
Q05 高并发	协程 + 信号量守边界 + 缓存 + 降级矩阵；成本监控是独有维度
Q06 ChatBI	语义层对齐、执行层校验、模糊就澄清——概率系统逼成确定性
Q07 LLM 网关	协议统一是壳，路由降级 + 成本计量 + 容灾才是魂