AI 应用系统设计

1. 学习目标

能从需求、规模和 SLO 开始设计，而不是先堆模型与框架；
能画出同步回答、异步任务、RAG 和 Agent 的关键数据流；
能估算并发、Token、模型吞吐、存储和费用；
能设计模型网关、缓存、限流、降级、评测与可观测性；
能在面试中解释关键权衡、瓶颈、故障和演进路线。

2. 面试结论

2.1 30 秒回答

AI 系统设计要同时解决“软件系统是否可靠”和“模型输出是否有用”两类问题。先明确用户任务、质量目标、延迟、吞吐、成本和安全边界，再拆分确定性业务层、模型网关、知识检索、Agent/Workflow、数据与评测层。模型调用必须可替换、可超时、可降级，输出必须可评测、可引用、可追踪，不能把第三方模型 API 当作整个系统架构。

2.2 一分钟复述版

我会先区分在线同步链路和异步长任务，定义 SLI/SLO 及质量指标，然后画出入口网关、业务编排、模型网关、RAG、工具、状态存储和观测系统。在线链路关注首 Token 延迟、端到端 P95、并发和降级；异步链路关注检查点、幂等、恢复和进度。数据侧记录 Prompt、模型、语料、索引和评测版本。成本通过模型路由、缓存、上下文控制和预算门禁治理。安全上将模型视为不可信决策者，所有真实副作用都经过服务端权限和审计。

3. 面试官为什么问

是否能把模型能力转化为稳定产品；
是否会做需求澄清、容量估算和 SLO 设计；
是否理解模型、RAG、Agent、业务代码和基础设施的边界；
是否能同时处理质量、延迟、成本、安全和可维护性；
是否能识别单点、背压、数据版本和评测缺失等生产风险。

4. 概念与边界

4.0 小白先这样理解：周五晚高峰餐厅怎么不崩盘

周五晚餐厅突然涌入一百桌客人，经理不会只买“最贵的厨师”：迎宾先鉴权和限流，叫号台管理排队，传菜系统分发订单，不同厨师处理凉菜、热菜和甜点；爆单时先暂停复杂定制、提供安全的简化菜单，同时抽检味道并记录出餐时间和食材成本。这里，客单是请求，迎宾是网关，叫号单是队列，后厨编排是 Workflow，厨师是模型或工具，常备菜是缓存，味道、等候时间、成本和过敏安全分别对应质量、延迟、费用与安全指标。

类比边界： AI 输出比菜品更不确定，不能只靠固定配方验收；平均到客速度也不能代表峰值容量。容量公式必须配合真实压测，降级不能绕过权限、引用和关键业务校验，模型供应商不可用时还要有超时、熔断、替代路由或明确拒绝策略。

4.1 AI 系统与普通系统的共同点

都需要鉴权、限流、存储、缓存、队列、可观测性、部署、容灾和数据治理。不要因为引入模型就忽略成熟的软件工程原则。

4.2 AI 系统新增的不确定性

同样输入可能产生不同输出；
输出正确性难以用单一断言判断；
上下文和模型版本改变会造成行为漂移；
Token 与生成长度影响延迟和成本；
外部模型存在限流、区域、配额和策略变化；
非可信文档可能通过提示注入影响行为；
高质量 Demo 不代表总体质量。

4.3 同步与异步边界

链路	适合任务	核心指标	主要机制
同步流式	问答、抽取、短 Agent Run	TTFT、P95、取消、完成率	Streaming、超时、降级
异步任务	视频、批量评测、长研究	排队、完成时间、恢复率	Workflow、检查点、回调
离线数据	索引、训练、评测集构建	新鲜度、正确率、吞吐	批处理、版本、回滚

4.4 需求澄清清单

谁使用，核心任务和成功标准是什么？
是建议、生成、决策还是执行真实动作？
请求量、峰值、上下文长度和输出长度如何？
延迟、可用性、新鲜度、成本和数据保留要求是什么？
是否需要引用、人工批准、多租户隔离或地区合规？
错误输出、超时和供应商不可用时如何降级？

5. 原理剖析

5.1 设计流程

定义功能和非功能需求；
估算请求、Token、并发、存储和成本；
画在线、异步和离线三条关键链路；
定义数据模型、版本和状态机；
深挖最关键的质量与性能瓶颈；
设计故障、降级、安全和可观测；
说明评测、上线门禁和演进路线。

5.2 容量估算

在到达率和完成率长期平衡的稳定系统中，根据 Little's Law，系统内平均请求数可粗略估算为：

C o n c u r r e n c y \approx R e q u e s t R a t e \times A v e r a g e L a t e n c y

Token 计量至少拆成 Prefill 输入和 Decode 输出：

I n p u t T o k e n R a t e = Q P S \times A v e r a g e I n p u t T o k e n s

O u t p u t T o k e n R a t e = Q P S \times A v e r a g e O u t p u t T o k e n s

两者相加可作为计费或流量量级，但不能直接当成模型容量。Prefill 与 Decode 的计算形态、Batching、显存带宽和 KV Cache 占用不同；自部署容量必须按目标硬件、输入/输出长度分布和批策略分别基准测试。

单请求可变成本：

C o s t_{r e q u e s t} = T_{i n} P_{i n} + T_{o u t} P_{o u t} + C_{r e t r i e v a l} + C_{t o o l s}

其中，RequestRate/QPS 是单位时间请求数，AverageLatency 是请求在系统内的平均停留时间， $T_{i n}$ 与 $T_{o u t}$ 是输入、输出 Token 数， $P_{i n}$ 与 $P_{o u t}$ 是折算到单 Token 的价格， $C_{r e t r i e v a l}$ 与 $C_{t o o l s}$ 是本次检索和工具调用成本。若供应商按百万 Token 报价，必须先除以 $10^{6}$ 再代入。

这些公式只用于建立量级，不替代压测。平均并发也不能代表峰值容量；真实系统还受排队、Batching、缓存命中、生成长度分布、到达突发性和供应商配额影响。

5.3 模型网关

模型网关统一处理：

供应商和模型路由；
超时、重试、熔断和配额；
Prompt 模板和结构化输出；
Token、延迟、成本和错误归一化；
敏感数据策略和审计；
灰度、回滚和模型降级。

业务代码依赖内部能力接口，例如 generate_answer 或 extract_profile，而不是散落具体模型名。

5.4 缓存层次

精确缓存：相同规范化输入、模型和版本；
语义缓存：相似问题复用答案，必须考虑用户权限和时效；
检索缓存：Query、过滤条件和索引版本共同构成键；
Prompt/前缀缓存：复用稳定上下文；
工具结果缓存：只缓存可安全复用、带 TTL 的只读结果；
中间产物缓存：长 Workflow 按阶段复用。

缓存键必须包含影响输出的版本，不能跨租户或跨权限误用。

5.5 质量闭环

图：AI 变更从失败样本到灰度回滚的质量闭环

替代文本： 线上失败样本经脱敏、复核和根因分类后进入固定回归集；候选变更只有通过离线质量、安全、延迟和成本门禁才能进入灰度，评测失败会阻断发布；灰度不达标则停止扩流并回滚，灰度和扩流阶段的新失败样本持续回流。

图表加载中…

读图结论： 质量闭环不是“评测通过后一次性上线”，而是离线失败即阻断、灰度失败即回滚，并让每个线上失败 Run 成为下一轮可重放的回归样本。

关键节点需要按同一条证据链解释：失败样本入库前先脱敏、人工复核并保留 Run 与版本指纹；离线门禁同时检查质量、安全、延迟和成本，失败候选不得进入灰度；灰度一次只改变可归因变量，触发阈值后立即停止扩流并恢复最近健康版本。即使扩流成功，也要持续把线上失败样本补入关键切片，避免回归集长期停留在旧分布。

质量指标和系统指标必须关联到同一个 Run。同一个“回答差”可能来自召回为空、上下文截断、模型超时降级或 Prompt 版本错误；没有版本指纹和阶段 Trace，失败样本就无法转化为可复现的质量资产。

5.6 可视化辅助

图：架构｜生产级 AI 应用组件边界

图表加载中…

替代文本： 请求经过网关和业务编排，按需调用模型、RAG 与 Agent；缓存、异步任务、状态和观测构成横向能力。

读图结论： 模型只是可替换依赖，业务编排、数据权限、状态、评测和观测才决定产品能否稳定运行。

6. 实现与代码

6.1 技术栈、框架、库与组件清单

AI 系统设计首先是能力和边界设计，具体产品只是可替换实现。下表给出本章示例架构采用的参考栈，不代表所有项目都必须使用同一框架。

技术点 ID	技术点/环节	类型	采用方案	链路职责	版本/证据边界
TP-01	请求编排与可恢复状态	架构模式 + 工作流/状态组件	业务状态机；长任务按需接持久化 Workflow	统一 Run 生命周期、超时预算、幂等、检查点和终止	参考架构；是否引入工作流平台由任务时长、恢复要求和团队运维能力验证
TP-02	模型访问与路由	服务组件	模型网关 + 可替换模型适配器	归一化鉴权、限流、错误、版本、成本与降级路由	供应商 API 和能力会变化，落地时以官方文档、契约测试和压测为准
TP-03	知识检索	服务 + 索引组件	权限过滤的混合检索与 Rerank	从版本化语料召回证据并构造可追溯上下文	是否需要 Dense、Rerank 或独立向量库由语料、查询和离线评测决定

6.2 横向选型对比

技术点 ID	候选方案	优点	缺点/代价	适用场景	不适用场景	选择结论与依据
TP-01	进程内状态机 + 队列	依赖少、控制直接、调试简单	跨进程恢复、补偿和可视化要自行建设	短链路、MVP、失败可安全重放	小时级任务、跨服务补偿和频繁人工信号	先按状态复杂度与恢复演练选择；恢复证据不足时不宣称可靠
TP-01	持久化工作流引擎	检查点、重试、定时和恢复语义完整	引入平台、确定性约束和运维成本	长任务、多阶段补偿、进程重启后继续	简单同步请求或团队无法维护平台	当自建恢复成本高于平台成本且故障演练通过时采用
TP-02	业务直接调用单一模型 SDK	链路短、上线快、供应商特性暴露充分	业务与供应商错误、字段和版本耦合	单模型验证、低切换需求	多模型路由、统一预算、容灾和审计	MVP 可直接调用；出现第二模型或统一治理需求时切到网关
TP-02	独立模型网关	策略、配额、错误、观测和切换集中	多一跳且需维护能力差异矩阵	多团队、多模型、统一合规和成本治理	单服务、极简验证或延迟预算极紧	以双模型契约测试、额外延迟和运维成本共同决定
TP-03	仅关键词检索	可解释、精确术语稳定、成本较低	同义改写和语义召回能力弱	错误码、专有名词、短语精确查询	自然语言问法变化大且词面不重合	词面命中已覆盖目标查询时保持简单方案
TP-03	混合检索 + Rerank	兼顾词法与语义召回，能二次排序	索引、延迟、评测和版本治理更复杂	企业知识问答、查询表达多样、需要引用	语料很小、长上下文直接读取更简单	只有离线 Recall/排序及端到端引用指标证明收益时采用

6.3 最小容量估算脚本

python

from dataclasses import dataclass


@dataclass(frozen=True)
class Workload:
    qps: float
    avg_latency_s: float
    avg_input_tokens: int
    avg_output_tokens: int
    input_price_per_million: float
    output_price_per_million: float


def estimate(w: Workload) -> dict[str, float]:
    concurrency = w.qps * w.avg_latency_s
    input_tokens_per_second = w.qps * w.avg_input_tokens
    output_tokens_per_second = w.qps * w.avg_output_tokens
    request_cost = (
        w.avg_input_tokens * w.input_price_per_million
        + w.avg_output_tokens * w.output_price_per_million
    ) / 1_000_000
    return {
        "average_concurrency": concurrency,
        "input_tokens_per_second": input_tokens_per_second,
        "output_tokens_per_second": output_tokens_per_second,
        "accounting_tokens_per_second": (
            input_tokens_per_second + output_tokens_per_second
        ),
        "model_cost_per_request": request_cost,
    }


if __name__ == "__main__":
    # 仅为假设输入；请替换为实测分布和当前官方价格。
    sample = Workload(2.0, 3.0, 1200, 300, 1.0, 4.0)
    print(estimate(sample))

6.4 使用边界

示例数字是假设，不是任何真实服务价格或容量；
平均值不能表达长尾，应使用 P50/P95/P99 和长度分布；
accounting_tokens_per_second 只表示总 Token 计量，不能把输入与输出 TPS 等价折算成 GPU 容量；需分别压测 Prefill、Decode、Batching 与 KV Cache；
供应商价格会变化，必须从官方来源刷新；
自部署模型还要估算 GPU 显存、Batching、KV Cache 和利用率；
压测需分别覆盖缓存命中、未命中、长输入和长输出。

6.5 核心接口建议

text

POST /v1/runs                  创建同步或异步 Run
GET  /v1/runs/{id}             查询状态和结果
POST /v1/runs/{id}/cancel      取消长任务
POST /v1/runs/{id}/approve     批准绑定动作指纹的工具调用
GET  /v1/runs/{id}/events      获取阶段与流式事件
POST /internal/model/generate  内部模型网关
POST /internal/retrieval/query 内部检索服务

外部 API 使用业务状态，不能直接暴露供应商内部状态和错误格式。

7. 实际项目案例

7.1 示例项目：AI 面试教练

示例项目，非本仓库真实业务；没有真实部署、事故、规模、质量、延迟、成本或收益指标。以下内容只用于架构推演，完成相应实测与演练后才能作结果性表达。

目标是按岗位和主题进行一问一答、动态追问、知识检索、评分和复盘。核心约束是低延迟交互、评分可解释、不同用户数据隔离以及长对话可恢复。

7.2 关键链路

图：技术调用流程｜AI 面试教练单轮回答的状态化时序

替代文本： 用户答案先经过鉴权和幂等检查，由 Run 状态机进入分析态；状态机按权限和版本调用 RAG，以独立 Rubric 生成结构化评分，再把评分和证据交给 Agent 决定追问、讲解或结束。依赖超时会以同一 Run 转入可恢复异步态，不可恢复错误进入失败终态；业务存储只持久化受治理的答案、状态、摘要、评分、证据 ID、版本指纹和事件。

图表加载中…

读图结论： 一轮面试不是 Agent 串行调用几个模型，而是由可恢复的 Run 状态机守住生命周期，RAG、Rubric 和 Agent 各自只承担检索、评分和对话决策，并在受控边界内持久化可审计结果。

关键边界有四个：会话服务负责鉴权、幂等和流式协议，状态机拥有唯一合法的状态迁移；RAG 读取版本化共享知识并执行权限过滤，不把用户答案写进索引；Rubric 输出可解释评分，Agent 只能基于评分选择追问、讲解或结束；关系库保存受保留策略约束的用户答案和结构化业务证据，完整 Prompt、临时检索片段及模型内部推理不作为长期状态。依赖超时时继续沿用同一个 Run ID 转异步，避免重试产生第二份互相矛盾的评分。

7.3 设计决策

高频知识文档离线索引，用户答案和分数存关系数据库；
Agent 只决定对话策略，最终评分由结构化 Rubric 约束；
检索必须按文档状态和用户权限过滤；
每轮保存结构化摘要，不把全部历史永久塞入上下文；
模型不可用时降级到固定题库和规则反馈；
三轮以上的完整评测可异步生成复盘报告。

7.4 核心技术难点

技术难点	为什么难	设计抓手	验证证据
系统 SLO 与质量 SLO 联动	请求成功不代表回答有用，降级后“可用”也可能掩盖质量坍塌	将完成率、TTFT/P95 与事实准确、追问相关、评分一致、引用正确按同一 Run 关联	固定回归集、线上失败切片、降级结果单独指标、Run 级 Trace
多版本因果追踪	模型、Prompt、语料、索引、Rubric 和工具任一变化都可能改变结果	为每次 Run 生成不可变版本指纹，并让灰度一次只改变可归因变量	任意失败样本能还原完整指纹；旧版本可重放或明确说明无法重放的边界
同步交互与异步复盘衔接	超时转异步、重试和恢复容易制造两个 Run、重复结果或状态卡死	使用统一 Run ID、显式状态机、幂等命令、事件序号与检查点	在断连、超时、Worker 重启下，状态单调推进且最终结果唯一
Agent 决策与真实副作用隔离	模型输出是非可信建议，参数、权限和当前资源状态会在执行前变化	模型只提议；服务端做 Schema、权限、动作指纹、二次确认和审计	越权/篡参/重复提交测试均被拒绝；批准内容与实际执行动作可比对
检索权限与新鲜度一致	语义相近不等于有权访问；文档、元数据和索引更新也可能不同步	权限前置过滤、结果后验校验、版本化索引和原子别名切换	跨用户/租户隔离测试、文档—索引版本对账、新旧索引切换演练
不确定长度下的容量与成本	输入、输出、Agent 步数和外部工具重试都有长尾，平均 Token 会低估峰值	分阶段预算、最大步数/输出、租户配额、模型路由和转异步策略	长度与并发分布压测、预算拒绝原因、单 Run 成本分解、重试放大系数

7.5 可验证的工程亮点与证据边界

下表是候选亮点，不是已经取得的成果。只有取得对应证据后，才能在项目复盘或面试中使用“实现了”“降低了”“避免了”等结果性表达。

候选亮点	可复用价值	最小证据包	证据边界
能力接口与模型网关解耦	业务按 `generate_answer`、`score_answer` 等能力依赖，不绑定供应商请求格式	契约测试、双供应商/双模型切换演练、错误归一化与回滚记录	只写了抽象接口但未做切换演练时，不能声称“供应商无感切换”
Run 全链路版本指纹	让回答、评分、引用和工具行为具备可追踪的因果上下文	Trace 中的模型/Prompt/语料/索引/Rubric/Workflow/工具版本与重放记录	无法固定的外部服务和随机性必须记录，不能保证跨环境逐字复现
质量感知的降级阶梯	主模型、检索或工具故障时，不把低质量结果伪装成正常结果	故障注入矩阵、每级降级的能力声明、独立质量指标与客户端提示截图/事件	只证明接口返回成功，不能证明降级结果满足质量要求
可恢复的统一 Run 状态机	同步转异步、取消、重试和 Worker 重启共享同一生命周期	状态迁移测试、检查点、幂等键、事件序号、进程终止恢复演练	未覆盖的外部副作用必须单独声明恢复边界
证据驱动的质量闭环	将线上失败样本变成可重复的发布门禁，而不是临时改 Prompt	失败分类、脱敏回归样本、对照实验、灰度结果和回滚阈值	回归集只代表已覆盖分布，不能据此宣称所有输入质量稳定
服务端权限与动作指纹	即使模型或上下文被注入，也不能绕过真实系统的授权边界	对抗提示、跨租户、过期授权、参数篡改和重复执行测试；完整审计链	模型拒答率不是权限安全证据，安全结论只覆盖服务端实际强制的动作

7.6 需要验证的指标与验收证据

技术：TTFT、端到端 P95、完成率、恢复率和错误分类；
质量：事实准确、问题不重复、追问相关、评分一致和引用正确；
业务：完成一轮面试的比例、主动复习和人工申诉；
成本：单轮 Token、检索、工具和复盘报告成本。

验收时还应保存工作负载与数据集版本、对照组、随机/采样配置、Run 指纹、原始失败样本、灰度范围、门禁阈值和回滚结果。没有这些实测证据前只定义指标和验证方法，不声明目标已达到。

8. 方案权衡与常见误区

8.1 自建模型与托管 API

方案	优点	代价	适合场景
托管 API	上线快、能力更新、少运维	配额、数据边界、单价和外部依赖	早期验证与弹性负载
自部署	数据与推理栈可控	GPU、部署、升级和利用率	稳定大规模或强合规
混合路由	兼顾质量、成本和容灾	网关、评测和一致性复杂	多任务生产系统

8.2 常见误区

一开始就讨论向量数据库，而没有需求和数据规模；
只定义系统可用性，不定义回答质量和降级质量；
所有请求都走最大模型；
只存最终答案，不记录 Prompt、模型、索引和证据版本；
把缓存键写成用户原始问题，忽略权限和版本；
用平均延迟掩盖长尾和队列拥塞；
Agent 直接持有生产系统最高权限。

8.3 故障与降级

以下是生产前应完成的故障演练清单，不是 AI 面试教练项目的真实事故记录。线上排障不能直接套用表中的场景根因，必须先用请求指纹和分阶段 Trace 取证。

问题	现象与影响	定位证据	场景根因	应急止损	长期修复	验证	防复发
主模型超时/限流	流式首 Token 迟迟不来，请求堆积，完成率下降	网关与模型 Span、输入 Token、队列时间、供应商错误码/配额、取消状态	输入超预算、供应商拥塞，且超时/重试预算未分层	停止放大重试；缩短上下文、切降级模型或转异步，并向用户标明能力变化	分阶段超时、带抖动的有界重试、熔断、配额感知路由和取消传播	注入慢响应/429，确认总超时受控、队列可回落且降级质量被单独记录	供应商错误分类契约、配额与队列告警、定期切换演练
索引过期或切换混用	新文档查不到，或同一批请求引用新旧语料，答案不可解释	文档/索引版本、入库事件、别名指向、检索结果 ID 与权限元数据	增量任务失败，或索引与元数据切换不原子	固定到最近健康索引，暂停有问题的增量发布；必要时降级关键词检索并声明时效	版本化构建、对账、原子别名切换、可回滚发布和新鲜度 SLO	用带版本固定问题验证新旧语料可见性、权限一致性与回滚	文档—索引数量/版本对账；新鲜度告警；切换前后 Canary 查询
Agent 重复执行副作用	同一批准动作被执行两次，产生重复消息、订单或写入	Run/工具调用 ID、动作指纹、审批记录、服务端审计、外部系统幂等键	Worker 重试或回调重复，执行接口没有唯一约束；只依赖模型“不要重复”	立即暂停该写工具，冻结重复任务并按审计记录人工核对/补偿	服务端幂等键、动作指纹绑定审批、唯一约束、Outbox/状态机和补偿流程	在执行前后杀进程、重复投递，确认外部副作用最多一次或可确定补偿	所有写工具接入前通过幂等/权限/重放测试；重复键和补偿失败告警
语义缓存跨权限复用	用户收到无权访问的事实或引用，形成数据泄漏	Cache Key、租户/用户/角色、检索过滤条件、索引版本、命中来源与审计日志	Cache Key 只使用相似文本，遗漏权限域、数据版本或时效	关闭语义缓存，清理受影响命名空间，阻断相关响应并启动安全审计	权限域和版本进入 Key；缓存后再做权限校验；敏感场景禁用语义缓存	跨租户/角色对抗测试必须不命中；权限变更后旧条目不可用	Cache Key 契约测试、权限变更失效事件、安全抽检与命中审计
异步 Run 长期卡在处理中	用户看不到进度或结果，重复提交使队列进一步拥塞	状态迁移时间、队列可见性、Worker 心跳、检查点、重试次数和死信	Worker 终止后缺少租约回收，或不可恢复错误被无限重试	暂停新增长任务，回收过期租约，将不可恢复项送死信并提供明确状态	持久化状态机、租约/心跳、检查点、有界重试、死信与人工恢复入口	在各阶段终止 Worker，确认任务恢复或进入可解释终态且结果唯一	卡态时长 SLI、死信告警、状态迁移不变量检查、定期恢复演练
成本突然放大	单 Run Token/工具调用上升，预算快速消耗并挤占正常用户	上下文长度、Agent 步数、重试次数、模型路由、缓存命中和每阶段成本	历史无界增长、循环终止失效、重试风暴或缓存/路由版本错误	启用单 Run/租户硬预算，限制步数和输出，熔断异常路由并降级	上下文摘要与裁剪、终止条件、成本分解、预算门禁和异常检测	重放同一流量并注入循环/限流，确认软告警、硬门禁和降级按预期触发	成本按版本与阶段看板；预算配置评审；循环和重试放大测试
质量回归	系统可用且延迟正常，但事实、追问、评分或引用切片变差	失败 Run 指纹、固定评测集、线上反馈、检索证据、模型/Prompt/索引/Rubric 版本	多变量同时发布，回归集缺少该切片，或灰度只看系统指标	停止扩流，回滚最可疑单一变量，对高风险结果增加人工复核	一次一变量灰度、质量与安全门禁、失败样本入库和分层评测	同一版本/数据配置复测；关键切片恢复门槛后再逐步扩流	发布必须关联回归报告；线上失败自动分流待审核；定期检查评测集覆盖漂移

8.4 可复用的系统设计与排障经验

可以把生产经验固化成“三条链路、两类 SLO、一组版本指纹、一个 Run 状态机”：

三条链路：分别画在线同步、异步长任务和离线数据/评测链路，避免用一个同步接口承担全部工作；
两类 SLO：系统 SLO 管延迟、可用性和恢复，质量 SLO 管事实、引用、评分、安全和降级质量，两者必须能关联到同一 Run；
版本指纹：至少记录模型、Prompt、语料、索引、Rubric、Workflow 和工具版本；无法固定的供应商状态与随机性也要记录为证据边界；
一个状态机：创建、运行、等待审批、转异步、取消、失败、完成等状态共享同一 Run ID，重试和恢复不能另造一条不可关联的结果。

排障时按以下顺序收敛范围：先确认用户、租户、Run ID 和请求预算，再核对版本指纹，然后看网关—编排—检索—模型—工具的阶段 Span，之后检查队列、连接池、配额等资源，最后才调整 Prompt 或模型。这样可以避免把索引过期、权限过滤、降级路由或供应商限流误判成“模型突然变笨”。

长期应维护以下经验资产：需求与 SLO 表、容量假设表、版本字段字典、降级矩阵、故障注入清单、固定质量回归集、权限对抗用例、Run 状态迁移测试和回滚 Runbook。每次事故或演练都按“现象与影响—定位证据—根因—止损—长期修复—验证—防复发”补齐记录；没有证据的判断标为假设，不进入稳定知识结论。

9. 面试题与参考答案

9.1 设计 AI 问答系统时先问什么？

合格答案：用户任务、成功标准、质量、延迟、吞吐、成本、安全和数据边界；
加分项：区分在线、异步、离线链路及失败降级；
常见错误：第一句话就是选模型或向量库。

9.2 模型网关解决什么问题？

合格答案：统一路由、超时、限流、成本、Prompt、错误、审计和降级；
加分项：内部能力接口与具体供应商解耦；
常见错误：只把网关理解为反向代理。

9.3 如何估算 LLM 系统容量？

合格答案：请求率、输入输出 Token 分布、延迟、并发、模型吞吐和缓存；
加分项：Little's Law、P95/P99、Batching 和供应商配额；
常见错误：只根据日活估算。

9.4 如何设计 AI 系统降级？

合格答案：按能力分级，主模型失败后切小模型、固定 Workflow、缓存或异步；
加分项：降级输出明确标记限制，质量指标独立监控；
常见错误：任何错误都直接重试主模型。

9.5 如何证明一次 Prompt 或模型升级有效？

合格答案：固定回归集、盲评、分层指标、灰度、在线反馈和回滚；
加分项：同时看质量、延迟、成本和安全，不只看平均分；
常见错误：展示几个成功案例。

10. 递进追问

基础概念：AI 系统为什么需要同时定义系统 SLO 和质量 SLO？
原理细节：语义缓存如何避免跨用户权限泄漏？
实现边界：流式响应中途模型失败，客户端和服务端如何处理？
工程权衡：何时选择同步回答，何时转为异步 Run？
系统设计：峰值扩大十倍时，如何判断先扩 API、检索还是模型容量？
项目复盘：如果质量分数提升但用户完成率下降，下一步查什么？

11. 实践任务

[ ] 为一个 AI 问答产品写功能和非功能需求；
[ ] 使用实测或明确假设完成 Token、并发和成本估算；
[ ] 画在线、异步和离线三条链路；
[ ] 设计模型、检索、工具和质量回归四类降级；
[ ] 定义十个 Trace/Metric/Log 字段及敏感数据策略；
[ ] 用 15 分钟完成一次 AI 面试教练系统设计口述。

12. 相关知识与参考资料

12.1 相关知识

12.2 一手参考资料

以下资料于 2026-07-10 核对：

13. 简明总结

一句话记忆： AI 系统设计要把概率模型放进可替换、可降级、可评测的确定性系统边界。

先定义任务、规模、质量、延迟、成本和安全，再选择模型与框架；
在线、异步和离线链路使用不同状态、指标和恢复机制；
模型网关、版本、评测和观测让能力可切换、可验证、可回滚；
容量估算同时考虑请求、Token、长尾、缓存和供应商配额；
面试重点是把技术难点、故障闭环和可验证亮点讲成有证据边界的项目经验。

AI 应用系统设计 ​

目录 ​

1. 学习目标 ​

2. 面试结论 ​

2.1 30 秒回答 ​

2.2 一分钟复述版 ​

3. 面试官为什么问 ​

4. 概念与边界 ​

4.0 小白先这样理解：周五晚高峰餐厅怎么不崩盘 ​

4.1 AI 系统与普通系统的共同点 ​

4.2 AI 系统新增的不确定性 ​

4.3 同步与异步边界 ​

4.4 需求澄清清单 ​

5. 原理剖析 ​

5.1 设计流程 ​

5.2 容量估算 ​

5.3 模型网关 ​

5.4 缓存层次 ​

5.5 质量闭环 ​

5.6 可视化辅助 ​

6. 实现与代码 ​

6.1 技术栈、框架、库与组件清单 ​

6.2 横向选型对比 ​

6.3 最小容量估算脚本 ​

6.4 使用边界 ​

6.5 核心接口建议 ​

7. 实际项目案例 ​

7.1 示例项目：AI 面试教练 ​

7.2 关键链路 ​

7.3 设计决策 ​

7.4 核心技术难点 ​

7.5 可验证的工程亮点与证据边界 ​

7.6 需要验证的指标与验收证据 ​

8. 方案权衡与常见误区 ​

8.1 自建模型与托管 API ​

8.2 常见误区 ​

8.3 故障与降级 ​

8.4 可复用的系统设计与排障经验 ​

9. 面试题与参考答案 ​

9.1 设计 AI 问答系统时先问什么？ ​

9.2 模型网关解决什么问题？ ​

9.3 如何估算 LLM 系统容量？ ​

9.4 如何设计 AI 系统降级？ ​

9.5 如何证明一次 Prompt 或模型升级有效？ ​

10. 递进追问 ​

11. 实践任务 ​

12. 相关知识与参考资料 ​

12.1 相关知识 ​

12.2 一手参考资料 ​

13. 简明总结 ​

AI 应用系统设计

目录

1. 学习目标

2. 面试结论

2.1 30 秒回答

2.2 一分钟复述版

3. 面试官为什么问

4. 概念与边界

4.0 小白先这样理解：周五晚高峰餐厅怎么不崩盘

4.1 AI 系统与普通系统的共同点

4.2 AI 系统新增的不确定性

4.3 同步与异步边界

4.4 需求澄清清单

5. 原理剖析

5.1 设计流程

5.2 容量估算

5.3 模型网关

5.4 缓存层次

5.5 质量闭环

5.6 可视化辅助

6. 实现与代码

6.1 技术栈、框架、库与组件清单

6.2 横向选型对比

6.3 最小容量估算脚本

6.4 使用边界

6.5 核心接口建议

7. 实际项目案例

7.1 示例项目：AI 面试教练

7.2 关键链路

7.3 设计决策

7.4 核心技术难点

7.5 可验证的工程亮点与证据边界

7.6 需要验证的指标与验收证据

8. 方案权衡与常见误区

8.1 自建模型与托管 API

8.2 常见误区

8.3 故障与降级

8.4 可复用的系统设计与排障经验

9. 面试题与参考答案

9.1 设计 AI 问答系统时先问什么？

9.2 模型网关解决什么问题？

9.3 如何估算 LLM 系统容量？

9.4 如何设计 AI 系统降级？

9.5 如何证明一次 Prompt 或模型升级有效？

10. 递进追问

11. 实践任务

12. 相关知识与参考资料

12.1 相关知识

12.2 一手参考资料

13. 简明总结