07. 系统设计模板
七、系统设计模板¶
导读：系统设计题真正考的是你能不能把“模型能力”还原成“工程链路”¶
AI 相关系统设计题最容易把人带到两个极端。一种是完全按照传统后端套路答，结果把模型、检索、Prompt、工具循环这些真正的特殊点讲没了；另一种则是被新词带着跑，一上来就列 Agent、MCP、向量库、多 Agent、工作流平台，听起来很热闹，却说不清业务目标和主链路。真正成熟的回答，应该是两条线一起抓：既把 AI 特有的部分讲出来，又始终把它们放在系统设计的主线里。
这类题更稳的答法，始终是先定义业务目标和约束，再讲主链路，然后拆关键模块，最后补风险、观测、评测和演进。比如“设计一个 AI 问答系统”，不要一上来先聊 Prompt，而要先说用户是谁、知识来自哪里、是否有权限边界、是否要求带引用、是否要流式返回；然后再讲请求如何进入系统，资料如何检索，模型如何调用，引用如何返回；接着再讲缓存、超时、限流、评测和失败兜底。只有这条主线先立住了，后面的组件选择才不会显得像背架构图。
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 的记录也不能脱离安全与审计单独讲，因为原始文本往往会带用户隐私和企业资料，记录策略一定和权限策略绑定。只要你能把这些平台能力都放回“统一运行时治理”这条主线里，答案就会比单独列几个组件成熟很多。
0. 系统设计题真正考的，不是你背过多少组件名¶
很多人一遇到系统设计题，就下意识开始列技术名词：Redis、Kafka、向量库、Agent、MCP、微服务。这样答最容易显得“好像懂很多”，也最容易暴露问题。因为面试官真正想听的，通常不是你知道哪些组件，而是你能不能把一个业务目标拆成一条合理、可解释、可治理的工程链路。
更直接一点说，系统设计题考的是你有没有工程叙事能力。所谓工程叙事能力，就是你能不能先讲清楚业务要解决什么问题，再讲请求是怎样穿过系统的，接着讲哪里最容易出错、为什么这样拆、出了问题以后怎么观察和定位。如果你一上来先说框架和中间件，面试官反而会更难判断你到底懂不懂题目本身。
1. 回答系统设计题时，脑子里先固定一条主线¶
无论题目是知识库问答、工具助手、流式对话，还是 Agent 平台，我都建议你按同一条主线来答。先定义业务目标和约束，再讲主链路，再拆关键模块，再补风险点和治理手段，最后说取舍和演进。这个顺序很重要，因为它能保证你的答案始终围着“系统如何工作”展开，而不是变成一堆零散组件。
先定义业务目标，意思是先把题目翻译成人话。比如“设计一个企业知识库问答系统”，你要先搞清楚用户是谁，是内部员工、客服还是法务；他真正要解决的是什么问题，是查制度、查产品知识还是查处理经验；成功标准是什么，是答得快、答得准、带引用，还是更强调权限和审计。只有这一步先立住了，后面你讲检索、缓存、索引和模型选择才有落点。
接着讲主链路，也就是“一个请求到底怎么走”。这一步不要急着讲存储和模块，而是先让面试官在脑子里形成一条完整流程。等这条流程成立后，再按入口层、编排层、检索层、模型层、存储层、治理层来拆模块，逻辑会自然很多。最后再补风险点、观测和演进，答案就会从“像背架构图”变成“像真的做过方案”。
如果你面试时容易紧张，可以给自己记一句固定口语：我先明确业务目标和约束，再讲主链路，然后展开几个关键设计点，接着补失败风险、监控和评测，最后讲第一版怎么做以及后面怎么演进。这句话看起来普通，实际非常有用，因为它能把你的回答牢牢拉回工程主线。
2. 企业知识库问答系统，应该怎样答得有工程味¶
这是最常见、也最适合当前学习主线的一道题。它表面上是在问“怎么做一个会回答问题的系统”，本质上其实是在问：你能不能把企业内部资料加工成可检索资产，并且让模型在权限正确、引用可信的前提下输出答案。
更稳的答法，是先把系统拆成两条链路：离线建库链路和在线问答链路。离线建库链路负责把文档变成可搜索资产，也就是上传、解析、清洗、切块、向量化、存储和索引更新。在线问答链路负责处理用户请求，也就是鉴权、确定租户范围、检索、必要时 rerank、模型生成、引用返回和结果记录。这样拆的好处非常明确：文档处理本身是重任务，频率和问答请求完全不同，更适合单独做异步执行、重试和监控；而在线问答链路则更关注延迟、权限和用户体验。
很多人会在这里暴露出一个典型问题：把“上传文档”和“立即可问答”设计成同一个同步请求。demo 里这么做很常见，真实系统里通常不稳。因为一份文档从接收到真正可检索，中间可能有 OCR、格式转换、清洗、切块、embedding、索引刷新，这些步骤任何一个都可能比较耗时。更合理的做法是上传接口只负责接收文件和创建任务，后台 worker 负责处理，前端通过任务状态知道文档什么时候真正可用。
如果面试官继续追问难点，你不要只说“检索精度”。更成熟的回答是把难点拆开讲：文档解析质量是否稳定，切块会不会把上下文切碎，多租户和权限过滤会不会串数据，索引更新后是否可能出现新旧版本不一致，引用是不是后端真实返回而不是模型自由编造。这样一答，系统就不再是“向量库加模型”的抽象口号，而是一条真实可落地的企业链路。
你还可以补一个具体失败案例，让答案更像做过项目。比如用户问“德国境内火车票报销上限是多少”，系统答错了。表面上像模型幻觉，实际上根因可能是旧版政策没有失效、切块把“上限 300 欧元”切散了、权限过滤没做对、或者引用本身是模型自由生成的。这种讲法能明显体现你的排查思路不是盲目调 prompt，而是沿着数据、检索、权限、生成整条链路看问题。
如果你想把这一题真正答成“像做过方案”，可以直接用一段接近现场口述的答案。比如这样说：如果让我设计一个企业知识库问答系统，我会先把它拆成离线建库和在线问答两条链路。离线侧负责上传文档、解析、清洗、切块、向量化和索引更新，这部分我会做成异步任务，因为文档处理天然是长任务，不适合绑在同步请求里。在线侧负责用户鉴权、租户与权限过滤、检索、必要时 rerank、模型生成和引用返回。存储上我会优先选 Postgres 加 pgvector，因为它能把文档元数据、权限字段和向量数据放在一套工程复杂度较低的体系里。第一版我最关心的不是把链路做得多花，而是把文档版本、权限过滤、引用可信和失败排查先收稳。观测上我会补结构化日志、trace 和基础评测集，确保我知道是解析、检索还是生成出了问题。这样答的关键，不是说了多少组件名，而是让面试官听到你对异步任务、权限、版本和排障这几件关键事是敏感的。
3. 能调用业务工具的智能助手，重点不是“会调函数”，而是“会不会出事”¶
这类题的核心，不是让模型显示出“好像很智能”，而是让自然语言请求在进入真实业务系统之后仍然可控。比较成熟的第一句话通常是：模型负责提出下一步动作建议，服务端负责决定能不能做、怎么做、做到哪一步为止。只要这条边界一开始讲清楚，后面的设计基本就不会跑偏。
主链路也很好讲。用户先发起请求，系统根据身份和场景装配可用工具集合，模型基于上下文给出工具调用意图，服务端再做 schema 校验、权限校验和风控判断，通过后执行工具，把结果带回给模型继续推理，直到达到停止条件为止。关键不是流程本身，而是你要主动说明这里为什么必须有工具注册表、为什么 schema 是硬约束、为什么写工具和读工具要分层治理。
工具注册表的价值，在于把工具从“散落在代码里的几个函数”提升成“被治理的系统能力”。一个成熟的工具条目，至少应该有名称、输入输出契约、所需权限、超时上限、是否允许重试、是否属于高风险写操作。这样做的意义是，当工具越来越多时，系统不会退化成“模型说调哪个就调哪个”的失控状态。
再往前一步，如果题目里出现真实副作用，比如“帮我查工单状态，如果还没处理就升级给值班经理”，你就要主动讲幂等、审计和审批。因为查状态出错大多只是体验问题，升级工单、发消息、发起退款这类动作一旦错，就是业务事故。成熟系统通常会把这类任务拆成查询阶段和执行阶段，前一段只读运行，后一段重新做权限、条件和确认判断，然后才允许执行。
如果要把这题答成完整样答，也可以直接顺着主链路说：这类助手我会把模型放在“建议下一步动作”的位置，而不是放在“直接执行”的位置。请求进来以后，服务端先根据用户身份和场景装配可用工具集合，再由模型输出结构化工具调用意图。执行前必须经过 schema 校验、权限校验、风控和超时控制。只读工具和写工具要分开治理，写工具再按是否幂等、是否高风险继续分级。查询结果保持结构化，便于模型汇总、日志审计和回放。如果进入高风险动作，例如升级工单、发通知或撤回申请，我会插入明确的审批节点，而不是让模型直接执行。观测上要保留每一步的 trace、工具输入输出摘要和审计记录，避免出问题时只能猜。这样一套回答，会比“我会让模型调用函数”更像真实系统设计。
4. 流式 AI 对话接口，最能暴露你有没有后端基本功¶
流式接口很容易被讲成“边生成边显示”，但这只是用户看到的表面。真正的工程问题其实是：服务端怎样在一个长连接里，一边从下游持续拿增量结果，一边尽快转发给客户端，并且在任何一方结束时都能干净地停下来。
这类题里，我建议你先讲为什么大多数单向流式问答优先选 SSE。因为 SSE 本质上还是 HTTP，接入简单，和浏览器兼容也好，足够满足“服务端持续推送文本片段”的大多数场景。只有在明确需要双向实时交互、复杂会话控制或者高频事件回传时，WebSocket 才会更有意义。很多人一上来就说 WebSocket，听起来热闹，实际上并没有先想清楚需求。
真正能拉开差距的，是你是否主动讲取消传播、背压和资源释放。浏览器关掉页面，并不等于服务端会自动停。你得把断连信号传到底层模型流、数据库查询、工具调用和后台 goroutine，不然用户已经走了，系统还在继续烧 token、占连接、堆 goroutine。背压问题也一样，下游生成快、客户端消费慢时，缓冲区怎么控、写阻塞怎么办、错误发生在中途时前面已经发出去的内容怎么处理，这些都比“怎么把文本一段段传给前端”更重要。
面试里如果你能给出一个具体场景，效果会更好。比如知识库问答使用 SSE 流式返回，用户在第 3 秒关闭页面。此时服务端如果没有把 Request.Context() 传到底层模型流和检索调用，下游照样会继续运行，最终问题不是“这次请求浪费了一点”，而是高并发时整个服务的资源会被慢慢拖垮。只要这层能讲清，你的流式接口题通常就会很稳。
5. Agent / MCP 平台题，考的是治理能力，不只是功能能力¶
现在越来越多面试不再满足于“单个问答接口”，而会往前推进一步，让你设计一个能接内部工具和数据源的 Agent 平台。到了这个层级，问题已经不只是“这次调用能不能成功”，而是“新的工具怎样接入、权限怎样声明、不同 Agent 如何共享能力、trace 怎样贯穿、失败怎样定位”。
这类题最稳的讲法，是把平台拆成接入层、运行时编排层、治理层和观测评测层。接入层负责把工具和数据源注册进来，无论是普通内部 API 还是通过 MCP 统一暴露的能力，都得在这里形成标准化描述。运行时编排层负责会话状态、模型调用、工具循环和停止条件。治理层负责权限、风险等级、审批、限流、参数校验和审计。观测评测层负责 trace、离线评测、失败复盘和成本分析。
MCP 在这里扮演的角色，要讲得克制一点。它解决的是工具和资源接入方式标准化，不是自动帮你做安全中台。平台真正的难点，仍然是权限收敛、风险分级、版本管理和审计。面试里如果你能主动说“我会把标准化接入和业务治理分开处理”，这个答案通常会很加分，因为它体现了你知道协议和策略不是一回事。
6. 怎么回答“你的 AI 系统到底有没有变好”¶
这是很多人最容易答虚的一道题。只说“看用户反馈”或者“看准确率”，通常都太粗。更成熟的方式，是把评估拆成离线评测、线上指标和失败复盘三层。
离线评测负责稳定回归，也就是提前准备一组固定问题，覆盖高频场景、历史失败案例、边界条件、权限敏感问题和容易误召回、误调用的样本。这样每次改 prompt、改检索、改工具策略，都能先跑一遍回归，不会完全靠主观感觉。线上指标则负责看真实运行效果，它不只包括错误率和延迟，还应该包括任务完成率、工具成功率、平均轮数、引用命中、成本和人工接管率。最后是失败复盘，优秀团队往往就是靠失败样本不断积累，慢慢把问题沉淀回离线评测集里，让系统越做越稳。
如果你把这三层讲清楚，面试官通常就能判断你不是在做一次性 demo，而是在考虑长期迭代的系统。
7. 系统设计题里最常见的失分方式¶
最常见的失分方式有四种。第一种是一上来就讲框架和组件，结果业务目标没说清，主链路也没立住。第二种是把 AI 题答成 prompt 题，只说模型怎么理解，不说权限、校验、评测和审计。第三种是只讲 happy path，不讲超时、取消、失败和资源释放。第四种是完全没有取舍意识，默认第一版就要上最重的方案，却说不清为什么。
所以你在收束答案时，最好主动加一句类似的话：第一版我会先保证主链路闭环，优先选择工程复杂度低但可治理的方案，把权限、结构化输出、日志、trace 和离线评测先打通；等数据规模、业务复杂度或组织协作压力上来后，再补更细的索引、缓存、Agent 编排和平台化治理。这样一句话，能很好地把“会列方案”收束成“有工程判断”。