10. 系统设计模板

十、系统设计模板

AI 相关系统设计题容易到两个极端。一种完全按照传统后端套路答，模型、检索、Prompt、工具循环这些真正的特殊点讲没了。另一种被新词带着跑，一上来就列 Agent、MCP、向量库、多 Agent、工作流平台，听起来很热闹，却说不清业务目标和主链路。成熟的回答两条线一起抓：把 AI 特有的部分讲出来，同时始终放在系统设计的主线里。

答法先定义业务目标和约束，再讲主链路，然后拆关键模块，最后补风险、观测、评测和演进。”设计一个 AI 问答系统”时，先说用户是谁、知识来自哪里、是否有权限边界、是否要求带引用、是否要流式返回。再讲请求如何进入系统，资料如何检索，模型如何调用，引用如何返回。接着再讲缓存、超时、限流、评测和失败兜底。这条主线先立住后，后面的组件选择才不显得像背架构图。

AI Chat 系统整体架构应该怎么讲

“AI Chat 系统整体架构”常被本能地答成一个聊天页面加一个模型接口。真实系统里，聊天只是表层交互，下面至少五层。接入层负责鉴权、限流、会话入口和流式返回。会话与编排层负责 conversation state、上下文裁剪、memory 注入、任务路由和 trace。知识与数据层是检索、业务数据库、缓存和外部工具。模型层负责普通生成、结构化输出、工具调用和必要的模型分层。治理层负责 Prompt 管理、日志、评测、审计、成本归因和回放。

这道题答得好的关键是说明为什么必须拆层。会话状态不能只靠浏览器端保留，服务端需要做权限控制、上下文裁剪和断连后的资源回收。模型层不应该直接碰所有业务系统，工具接入和策略层要能统一治理。评测和 trace 必须在一开始就留口，系统后面一定会持续迭代，不可能靠主观感觉判断是否变好。

多 Agent 协作系统和 Agent 平台题应该怎么讲

“如何实现多 Agent 协作系统”这类题，一紧张就开始讲角色列表：搜索 agent、执行 agent、总结 agent、审查 agent。光列角色远远不够。成熟的答案先问一个问题：为什么单 Agent 或工作流不够，必须拆成多个 Agent？这个问题答不出来，多 Agent 往往只是形式复杂化。

真正值得拆成多 Agent 的场景：明确角色边界、不同工具集、不同风险等级，或需要把上下文严格隔离。检索 agent 只访问知识库，执行 agent 只访问内部业务工具，审查 agent 只做合规复核。设计重点不再是”几个 Agent 并行”，而是协调者是谁、handoff 怎么做、共享状态放在哪里、冲突怎么处理、何时进入人工确认、trace 如何贯穿全局。主动讲这些，面试官会明显感觉到理解的是系统，不是概念演示。

Prompt 管理、评测和运行时治理平台题应该怎么讲

表面上在问平台，实质上在考治理能力。”怎么设计 Prompt 管理系统””怎么做 AI 平台的评测能力””怎么统一记录 Prompt 和 Response”。最稳的讲法是把它们看成运行时治理的一部分，不是独立的小工具。

成熟的 Prompt 管理系统要解决版本化、变量注入、灰度发布、回滚、负责人、与评测集绑定这些问题。成熟的评测平台要解决样本管理、回归执行、grader 或人工复核、与线上 trace 关联、失败样本沉淀这些问题。Prompt 和 Response 的记录不能脱离安全与审计单独讲，原始文本往往会带用户隐私和企业资料，记录策略一定和权限策略绑定。把平台能力都放回”统一运行时治理”这条主线里，答案比单独列几个组件成熟很多。

系统设计题真正考的，不是背过多少组件名

一遇到系统设计题就下意识开始列技术名词：Redis、Kafka、向量库、Agent、MCP、微服务。这样答最容易显得”好像懂很多”，也最容易暴露问题。面试官真正想听的不是你知道哪些组件，而是能不能把一个业务目标拆成一条合理、可解释、可治理的工程链路。

系统设计题考的是工程叙事能力。先讲清楚业务要解决什么问题，再讲请求是怎样穿过系统的，接着讲哪里最容易出错、为什么这样拆、出了问题以后怎么观察和定位。一上来先说框架和中间件，面试官反而更难判断到底懂不懂题目本身。

回答系统设计题时，脑子里先固定一条主线

无论题目是知识库问答、工具助手、流式对话，还是 Agent 平台，按同一条主线来答。先定义业务目标和约束，再讲主链路，再拆关键模块，再补风险点和治理手段，最后说取舍和演进。这个顺序能保证答案始终围着”系统如何工作”展开，不变成一堆零散组件。

先定义业务目标，先把题目翻译成人话。”设计一个企业知识库问答系统”，先搞清楚用户是谁——内部员工、客服还是法务。真正要解决的是什么问题——查制度、查产品知识还是查处理经验。成功标准是什么——答得快、答得准、带引用，还是更强调权限和审计。只有这一步先立住后，讲检索、缓存、索引和模型选择才有落点。

接着讲主链路，也就是”一个请求到底怎么走”。不急讲存储和模块，先让面试官在脑子里形成一条完整流程。流程成立后，再按入口层、编排层、检索层、模型层、存储层、治理层来拆模块，逻辑自然很多。最后再补风险点、观测和演进，答案从”像背架构图”变成”像真的做过方案”。

追问到机制深度时，展开同步升级，不停在”有缓存、有 MQ、有向量库”。主链路里每个关键模块都补一句”它在解决什么压力”和”关键参数或边界是什么”。数据库层补”为什么这一版优先选 pgvector，向量和权限元数据在同库会降低哪部分复杂度”。缓存层补”缓存的是 query 结果还是 embedding，key 带不带版本，为什么这个 TTL 可以接受”。检索层补”BM25、向量和 rerank 分别在补哪一层信号”。这样答时，系统设计才会和前面正文里的机制深讲真正接上。

面试时容易紧张，记一句固定口语：我先明确业务目标和约束，再讲主链路，然后展开几个关键设计点，接着补失败风险、监控和评测，最后讲第一版怎么做以及后面怎么演进。这句话看起来普通，实际非常有用，因为它能把回答牢牢拉回工程主线。

企业知识库问答系统，应该怎样答得有工程味

最常见、最适合当前学习主线的一道题。表面上在问”怎么做一个会回答问题的系统”，本质上在问：你能不能把企业内部资料加工成可检索资产，并且让模型在权限正确、引用可信的前提下输出答案。

先把系统拆成两条链路：离线建库链路和在线问答链路。离线建库链路把文档变成可搜索资产：上传、解析、清洗、切块、向量化、存储和索引更新。在线问答链路处理用户请求：鉴权、确定租户范围、检索、必要时 rerank、模型生成、引用返回和结果记录。文档处理本身是重任务，频率和问答请求完全不同，更适合单独做异步执行、重试和监控。在线问答链路关注延迟、权限和用户体验。

把”上传文档”和”立即可问答”设计成同一个同步请求，demo 里常见，真实系统里不稳。一份文档从接收到真正可检索，中间可能有 OCR、格式转换、清洗、切块、embedding、索引刷新，任何一个都可能比较耗时。上传接口只负责接收文件和创建任务，后台 worker 负责处理，前端通过任务状态知道文档什么时候真正可用。

面试官继续追问难点时，不只说”检索精度”。把难点拆开讲：文档解析质量是否稳定，切块会不会把上下文切碎，多租户和权限过滤会不会串数据，索引更新后是否可能出现新旧版本不一致，引用是不是后端真实返回而不是模型自由编造。这样一答，系统不再是”向量库加模型”的抽象口号，而是真实可落地的企业链路。

补一个具体失败案例。用户问”德国境内火车票报销上限是多少”，系统答错了。表面上像模型幻觉，实际上根因可能是旧版政策没有失效、切块把”上限 300 欧元”切散了、权限过滤没做对、或者引用本身是模型自由生成的。这种讲法体现排查思路不是盲目调 prompt，而是沿着数据、检索、权限、生成整条链路看问题。

接近现场口述的答案：设计企业知识库问答系统，先拆成离线建库和在线问答两条链路。离线侧负责上传文档、解析、清洗、切块、向量化和索引更新，这部分做成异步任务，文档处理天然是长任务，不适合绑在同步请求里。在线侧负责用户鉴权、租户与权限过滤、检索、必要时 rerank、模型生成和引用返回。存储上优先选 Postgres 加 pgvector，因为它能把文档元数据、权限字段和向量数据放在一套工程复杂度较低的体系里。第一版关心的是把文档版本、权限过滤、引用可信和失败排查先收稳。观测上补结构化日志、trace 和基础评测集，确保知道是解析、检索还是生成出了问题。这样答的关键：不是说了多少组件名，而是让面试官听到对异步任务、权限、版本和排障这几件关键事是敏感的。

题目追问成”设计一个高并发 AI 搜索系统”时，把系统从”能答”继续讲到”能扛量”。先报量级：日活、峰值 QPS、P95 延迟目标、知识库规模、索引规模和更新频率。再拆瓶颈层。入口层讲限流、鉴权、会话控制和 query cache。检索层讲倒排、向量、rerank 和 metadata filter。模型层讲流式返回、并发预算和降级路线。存储层讲索引更新、连接池、对象存储和缓存。治理层讲灰度发布、A/B、评测集和 trace。数字和边界先讲清后，”为什么选 pgvector 而不是 ES + 向量库双栈””为什么要做 embedding cache””为什么 rerank 不一定对所有 query 都开”这些取舍才有落点。

“报数字”讲成”像真的做过容量设计”，主动补三条直觉。第一，在途请求数 ≈ QPS × P95 延迟，直接决定入口并发、连接池和模型并发预算。第二，检索总调用量 ≈ QPS × (召回通道数 + rerank 批次数)，帮助解释为什么同样是 200 QPS，双路召回加 rerank 的系统比单路检索的系统基础设施压力不是一个量级。第三，回源压力 ≈ 原始请求量 × (1 - hit_ratio)，把 query cache、embedding cache 和结果缓存为什么重要说得非常具体。这些量化关系讲出来后，”QPS、P95、缓存、索引规模和并发预算”真正连成一条容量控制线。

成熟的答法还会把量化指标和机制直接绑在一起。P95 主要慢在检索前半段时，先看 query cache 命中、BM25 倒排命中和向量检索 Top-K 是否过大。主要慢在 rerank 时，先看候选集大小、batch、序列截断长度。主要慢在模型层时，看流式首字节时间、模型并发预算和是否存在”其实可以部分降级”的链路。报数字不再像背 KPI，而是证明自己知道这些数字对应的是哪一层机制。

能调用业务工具的智能助手，重点不是”会调函数”，而是”会不会出事”

核心是让自然语言请求在进入真实业务系统之后仍然可控，不是让模型显示出”好像很智能”。第一句话：模型负责提出下一步动作建议，服务端负责决定能不能做、怎么做、做到哪一步为止。这条边界一开始讲清楚后，后面的设计基本不会跑偏。

主链路：用户先发起请求，系统根据身份和场景装配可用工具集合，模型基于上下文给出工具调用意图，服务端再做 schema 校验、权限校验和风控判断，通过后执行工具，把结果带回给模型继续推理，直到达到停止条件。关键要主动说明这里为什么必须有工具注册表、为什么 schema 是硬约束、为什么写工具和读工具要分层治理。

工具注册表把工具从”散落在代码里的几个函数”提升成”被治理的系统能力”。成熟的工具条目，至少应该有名称、输入输出契约、所需权限、超时上限、是否允许重试、是否属于高风险写操作。工具越来越多时，系统不会退化成”模型说调哪个就调哪个”的失控状态。

题目里出现真实副作用，比如”帮我查工单状态，如果还没处理就升级给值班经理”，主动讲幂等、审计和审批。查状态出错大多只是体验问题，升级工单、发消息、发起退款这类动作一旦错，就是业务事故。成熟系统通常会把这类任务拆成查询阶段和执行阶段，前一段只读运行，后一段重新做权限、条件和确认判断，然后才允许执行。

完整样答顺着主链路说：这类助手把模型放在”建议下一步动作”的位置，不是”直接执行”的位置。请求进来以后，服务端先根据用户身份和场景装配可用工具集合，再由模型输出结构化工具调用意图。执行前必须经过 schema 校验、权限校验、风控和超时控制。只读工具和写工具分开治理，写工具再按是否幂等、是否高风险继续分级。查询结果保持结构化，便于模型汇总、日志审计和回放。进入高风险动作——升级工单、发通知或撤回申请——插入明确的审批节点，不让模型直接执行。观测上保留每一步的 trace、工具输入输出摘要和审计记录，避免出问题时只能猜。这样一套回答，比”我会让模型调用函数”更像真实系统设计。

题目改成”设计一个支持多轮对话和工具调用的 Agent”时，把状态层单独讲出来。接入层负责会话和流式连接。编排层负责状态机、工具路由、停止条件和 checkpoint。工具层负责 schema、权限和副作用治理。记忆层负责短期上下文、结构化状态和长期记忆。治理层负责审批、reflection、trace、评测和回放。一遇到多轮就开始只讲 memory，漏掉了真正更关键的东西：每一轮状态是怎么更新的，工具失败以后从哪一步恢复，哪些动作必须走审批，长任务怎样断点续跑。

流式 AI 对话接口，最能暴露你有没有后端基本功

流式接口容易被讲成”边生成边显示”，这只是用户看到的表面。真正的工程问题：服务端怎样在一个长连接里，一边从下游持续拿增量结果，一边尽快转发给客户端，并且在任何一方结束时都能干净地停下来。

先讲为什么大多数单向流式问答优先选 SSE。SSE 本质上还是 HTTP，接入简单，和浏览器兼容也好，足够满足”服务端持续推送文本片段”的大多数场景。只有在明确需要双向实时交互、复杂会话控制或者高频事件回传时，WebSocket 才有意义。一上来就说 WebSocket，没有先想清楚需求。

拉开差距的是主动讲取消传播、背压和资源释放。浏览器关掉页面，不等于服务端会自动停。断连信号传到底层模型流、数据库查询、工具调用和后台 goroutine。用户已经走了，系统还在继续烧 token、占连接、堆 goroutine。背压问题一样，下游生成快、客户端消费慢时，缓冲区怎么控、写阻塞怎么办、错误发生在中途时前面已经发出去的内容怎么处理。这些比”怎么把文本一段段传给前端”更重要。

给出一个具体场景。知识库问答使用 SSE 流式返回，用户在第 3 秒关闭页面。服务端没有把 Request.Context() 传到底层模型流和检索调用，下游照样会继续运行。最终问题不是”这次请求浪费了一点”，而是高并发时整个服务的资源被慢慢拖垮。这层讲清后，流式接口题就稳了。

Agent / MCP 平台题，考的是治理能力，不只是功能能力

题目从”单个问答接口”推进到”能接内部工具和数据源的 Agent 平台”。这一层级的问题不再是”这次调用能不能成功”，而是”新工具怎样接入、权限怎样声明、不同 Agent 如何共享能力、trace 怎样贯穿、失败怎样定位”。

回答时先把主链固定为平台治理链。业务目标与租户边界，能力接入，运行时编排，状态与记忆，审批与风控，观测评测，故障恢复与回放。平台不再只是”多接几个工具”，而是让不同 Agent 和不同业务线复用同一套执行边界的底座。接入层负责工具与数据源注册表、统一适配层和统一结果 envelope。运行时编排层负责会话状态、工具循环、停止条件和 handoff。状态与记忆层负责会话存储、checkpoint、长期记忆和恢复入口。治理层负责权限、风险等级、审批、限流、参数校验和审计。观测评测层负责 trace、离线评测、失败复盘和成本分析。

“Agent 中台”和”单个智能助手应用”有明确差别。单个应用解决一条具体业务链能不能跑稳，重点是将本业务的工具、状态和失败收口做好。中台解决能力复用、治理一致性和多团队接入，重点转为注册表、适配层、统一策略、统一审计和共享运行时。面试中讲清这层差异，答案从”功能设计”进到”平台设计”。

MCP 的定位要讲得克制。它解决工具和资源接入方式标准化，不自动构建安全中台。平台真正的难点仍然是身份映射、权限收敛、风险分级、版本管理和审计。MCP 统一接入方式和能力发现，不替代租户治理、审批策略和输出标准化。主动说明”把标准化接入和业务治理分开处理”，能体现协议和策略的区分。

平台题进一步落到机制层时，把公共底座拆为固定对象：工具/资源注册表、统一 schema 与 envelope、运行时状态与 checkpoint、策略与审批中心、trace/eval/audit、租户与身份映射。面试官追问”为什么要有统一 envelope””为什么 checkpoint 要平台化””为什么审批规则不该散在各个 Agent 里”时，有稳定的回答锚点。

怎么回答”你的 AI 系统到底有没有变好”

把评估拆为离线评测、线上指标和失败复盘三层。

离线评测负责稳定回归。提前准备一组固定问题，覆盖高频场景、历史失败案例、边界条件、权限敏感问题、容易误召回和误调用的样本。每次改 prompt、改检索、改工具策略，先跑一遍回归，不靠主观感觉判断。

线上指标看真实运行效果。除错误率和延迟外，还包括任务完成率、工具成功率、平均轮数、引用命中率、成本和人工接管率。

失败复盘将线上问题沉淀回离线评测集。失败样本不断积累，系统逐步迭代变稳。三层讲清后，面试官可以判断系统是长期迭代方向，不是一次性 demo。

系统设计题里最常见的失分方式

四种失分方式最典型。一上来就讲框架和组件，业务目标和主链路均未立住。把 AI 题答成 prompt 题，只谈模型理解，不谈权限、校验、评测和审计。只讲 happy path，忽略超时、取消、失败和资源释放。缺乏取舍意识，默认第一版就上最重方案，说不清原因。

收束答案时主动加一句约束。第一版先保证主链路闭环，优先选工程复杂度低但可治理的方案，把权限、结构化输出、日志、trace 和离线评测先打通。数据规模、业务复杂度或组织协作压力上来后，再补更细的索引、缓存、Agent 编排和平台化治理。这句话将”会列方案”收束为”有工程判断”。