AI 系统架构设计

flowchart LR
  A["AI 系统架构设计"]
  A --> B["分类：工程与生产"]
  A --> C["关键词：AI"]
  A --> D["关键词：架构"]
  A --> E["关键词：微服务"]
  A --> F["关键词：部署"]

AI 系统不是“传统软件外面包一层模型调用”。非确定性、高延迟、高成本、快速迭代，以及评估困难，决定了它需要一套不同于传统 CRUD 系统的架构思维。

为什么要从“架构”开始

很多 AI 项目在最早几周都显得进展很快：

接一个模型 API
写一个 Prompt
做一个聊天界面
接一点检索或工具调用

很快，一个能演示的版本就出来了。

但真正上线时，问题会突然集中出现：

同样的问题，今天和明天回答不一样，怎么验收？
成本一旦和调用量线性绑定，怎么避免越增长越亏？
一个回答生成 20 秒，前端应该怎么设计交互？
Prompt 要频繁调，难道每次都跟着业务代码一起发版？
模型、RAG、工具调用、权限、缓存，到底应该放在哪一层？
失败不再只是 500 或超时，还可能是“看起来正常，其实答错了”，这种系统怎么观测？

这篇文章讨论的，就是这些问题背后的架构逻辑。

它不是教你画一张“高大上”的系统图，而是想建立一个更实用的判断框架：AI 系统和传统软件到底哪里不一样，这些差异如何影响分层、部署、拆分边界、基础设施和演进路径。

1. AI 系统和传统软件，到底差在哪

一句话概括：

传统软件主要在管理确定性的业务逻辑；AI 系统则要在一个非确定性、成本敏感、持续变化的能力层之上构建产品。

这个差异不只是“多了个模型 API”，而是会一路影响到架构设计的优先级。

维度	传统软件	AI 系统
输出特性	相同输入通常得到相同输出	相同输入可能得到不同输出
失败模式	报错、超时、权限失败	幻觉、偏题、格式漂移、拒答、工具误用
成本结构	计算成本相对固定	token、推理时长、检索和工具调用成本随使用增长
迭代对象	代码、配置、数据库结构	代码、Prompt、模型、评估集、工具链、知识库
延迟分布	毫秒级为主	秒级常见，长任务并不少见
验收方式	单测、集成测试、业务规则校验	除功能测试外，还要做质量评估、离线评测与线上观测

1.1 非确定性：系统不再“可完全预测”

这件事是 AI 系统和传统系统最大的分水岭。

在传统软件里，你通常假设：

输入相同
代码相同
外部依赖相同
输出就应当相同

而在 LLM 系统里，就算你尽量把参数固定，输出依然可能出现差异。更麻烦的是，很多差异并不是“错得很明显”，而是：

大方向对，但细节有误
格式看似正确，但字段含义错了
结论合理，但证据不足
工具调用成功，但调用了不该调用的工具

所以 AI 系统不能只围绕“系统是否报错”来设计，还必须围绕“结果是否可信、可解释、可接受”来设计。

1.2 成本不是基础设施背景噪声，而是产品变量

传统 Web 服务里，计算资源成本当然也重要，但它往往不会精确到“每多说一段话就多花多少钱”。

AI 系统不一样。一次请求的成本可能直接和这些因素绑定：

prompt 长度
上下文窗口
检索召回数量
是否调用更强模型
是否发生多轮工具循环
是否进行了重试或重写

这意味着成本不是运维团队关心的事，而是产品和架构都必须参与的约束条件。

1.3 模型层在快速变化，系统必须允许“热插拔”

传统系统当然也升级依赖，但 AI 系统的变化速度通常更快：

模型版本在变
Prompt 在变
工具策略在变
RAG 策略在变
输出 schema 在变
评估指标也在变

如果你的架构把这些东西都和核心业务代码硬绑在一起，系统很快会变得难以迭代。LangSmith 的 Prompt 管理文档就明确把 prompt 视为可版本化、可拉取、可管理的对象，而不是只能写死在代码里的字符串。(docs.langchain.com (LangChain 文档))

1.4 可观测性不再是“有日志就行”

OpenTelemetry 文档把 traces 定义为观察请求完整路径的方式，并强调 traces 对理解请求经过了哪些组件至关重要。对于 AI 系统，这种“完整路径”尤其关键，因为一次回答往往不是一个函数调用，而是一条链路：

入口请求
检索
Prompt 组装
模型调用
工具调用
结果后处理
安全检查
返回前端或写入系统

如果这条链路不可见，线上问题几乎无法定位。(opentelemetry.io (OpenTelemetry))

2. AI 架构设计的第一原则：把变化快的东西隔离出来

AI 系统最容易犯的一个错误，是把所有逻辑揉在一起：

API 层直接拼 Prompt
业务层直接决定模型
模型返回值直接写数据库
检索逻辑、工具逻辑、权限逻辑散落在各处

一开始这样写很快，但很快会遇到典型问题：

改一个 Prompt 要重新发版
换一个模型要改多处代码
同一类逻辑在多个接口里复制
很难知道到底是模型问题、检索问题还是业务逻辑问题
A/B 测试、灰度切流、回滚都变得麻烦

所以 AI 系统架构的第一原则，不是“先上微服务”，而是：

先把变化快、试验多、不确定性强的那一层和稳定业务边界隔离开。

这通常意味着，至少要把下面几类职责拆开：

面向用户和业务系统的接口层
稳定的业务应用层
AI 编排层
模型接入与路由层
数据与知识层

3. 一个更实用的分层架构

把 AI 系统抽象成五层通常是有帮助的，但真正有用的不是背层名，而是理解每层为什么存在。

┌─────────────────────────────────────────────────────┐
│ API / Experience Layer                             │
│ HTTP / SSE / WebSocket / Auth / Rate Limit         │
└──────────────────────┬──────────────────────────────┘
                       ↓
┌─────────────────────────────────────────────────────┐
│ Application Layer                                  │
│ 业务逻辑、租户隔离、会话、权限、工作流入口            │
└──────────────────────┬──────────────────────────────┘
                       ↓
┌─────────────────────────────────────────────────────┐
│ AI Orchestration Layer                             │
│ Prompt 组装、RAG、工具调用、Agent/Workflow 编排      │
└──────────────────────┬──────────────────────────────┘
                       ↓
┌─────────────────────────────────────────────────────┐
│ Model Access Layer                                 │
│ 模型路由、Fallback、重试、缓存、供应商适配            │
└──────────────────────┬──────────────────────────────┘
                       ↓
┌─────────────────────────────────────────────────────┐
│ Data / Knowledge Layer                             │
│ 业务库、对象存储、向量库、索引、外部系统              │
└─────────────────────────────────────────────────────┘

下面分别看。

4. API / Experience Layer：别把“调用模型”直接暴露给用户

这一层最容易被低估，因为很多 Demo 里它只是一个 /chat 接口。

但到了可上线阶段，它负责的往往不只是接请求，而是处理用户体验和系统边界：

鉴权与租户识别
限流与配额控制
请求幂等性
同步 / 流式 / 异步的交互模式
用户取消请求
前端实时状态回传
基础审计与日志入口

为什么这一层很关键

因为 AI 请求往往比普通 HTTP 请求更长、更贵、更不稳定。

如果你把它当成普通同步 API，很容易出现这些问题：

前端等待十几秒没有任何反馈
用户重复点击，产生重复计费
用户断开连接后，后端仍在傻跑
流式输出、工具调用状态、最终结果混在一起

所以 API 层要明确区分几种交互模型：

4.1 同步 + 流式

适合：

聊天
短文本生成
用户需要“边看边等”的场景

常见做法是 SSE 或 provider 自带 streaming。它不能缩短模型真实推理时间，但能改善感知延迟。

4.2 异步任务

适合：

长文档处理
批量分析
Agent 工作流
可能持续数十秒到数分钟的任务

这类场景更适合“提交任务 → 获取任务 ID → 轮询 / webhook / socket 通知完成”。

4.3 WebSocket / 实时双向通道

适合：

实时对话
工具调用状态推送
多轮交互和协作编辑
Agent 中间步骤可视化

关键不是“技术潮不潮”，而是用户是否真的需要更连续的过程反馈。

5. Application Layer：稳定业务规则，不要让 Prompt 替代它

应用层处理的是相对稳定的业务事实和系统规则，比如：

用户与租户模型
角色与权限
订单、工单、项目、对话等业务对象
工作流入口与状态机
计费、配额、审计
哪些动作允许自动执行，哪些必须人工审批

这一层最大的误区，是把模型当成业务逻辑执行器。

比如有人会这样设计：

让模型判断用户有没有权限
让模型决定能不能改生产配置
让模型自己理解什么叫“管理员可见”
让模型根据自然语言自由决定流程跳转

这样短期很方便，长期极不稳定。原因很简单：模型适合处理语义模糊和信息压缩，不适合承担刚性规则。

更合理的边界通常是：

应用层：决定“能不能做”
AI 层：决定“怎么更好地理解、生成、辅助完成”

也就是说：

是否有权限发邮件，不该让模型猜
是否超出预算，不该让模型猜
是否属于高风险动作，不该让模型猜
是否满足发布门槛，不该只靠模型说了算

AI 系统的好架构，不是让模型无所不能，而是让模型只做它擅长的部分。

6. Orchestration Layer：AI 应用真正容易失控的地方

如果说传统系统的复杂度常常集中在业务领域模型和数据库，那么 AI 系统的复杂度往往集中在编排层。

这一层通常负责：

Prompt 组装
上下文构造
检索与重排
工具调用
输出结构化
多模型协同
Agent 循环
工作流分支与重试
人工介入点

这也是为什么很多 AI 项目早期“明明只有几个接口”，却很快变得很难维护——因为真正的复杂度其实已经跑到编排层里了。

6.1 不要把业务逻辑和编排逻辑混在一起

比如下面两种写法，长期维护成本会非常不一样。

不好的方式

Controller 里直接拼 Prompt
业务服务里直接做向量检索
模型返回后顺手做格式修正和权限判断
工具调用逻辑写在 if/else 里

更好的方式

应用层明确提出“业务目标”
编排层负责把目标转换成 AI 执行过程
模型层只负责推理能力访问
业务规则仍在应用层统一执行

这种分离的价值在于，AI 方案会频繁变，而业务边界不该跟着一起抖动。

6.2 编排层不只是“Prompt 中转站”

很多文章把 orchestration 理解成“把检索结果和系统提示拼进 Prompt”。这太窄了。

真正成熟的编排层更像一个运行时协调器，要解决的问题包括：

哪一步用哪个模型
哪一步是否应该检索
检索失败后是否降级
结构化输出失败时要不要重试
哪些工具可调用
哪些结果必须经由校验器
哪些场景必须转人工
长任务如何拆成阶段执行

这也是 LangGraph、CrewAI、Temporal 这类框架会被反复讨论的原因：不是因为大家需要更多框架，而是因为编排本身已经成为独立复杂度来源。

7. Model Access Layer：把“模型”当成可替换基础设施，而不是业务写死依赖

模型接入层是很多系统早期最偷懒、后期最痛苦的部分。

最初常见写法是：

业务代码里直接调某家 API
到处散落模型名
Prompt 和模型参数耦合
错误处理、限流、重试各写各的

随着系统增长，很快会出现：

想换模型很难
想做 fallback 很难
不同场景的参数配置到处散
成本优化没有统一入口
无法做灰度和实验

所以更合理的做法，是把模型调用统一收敛到一个模型接入层，负责这些事情：

供应商适配
模型路由
fallback
重试和熔断
请求标准化
返回标准化
速率限制
成本与 token 统计
缓存与复用

7.1 模型路由不是“为了炫技”

模型路由最常见的误解，是把它理解成复杂平台才需要的“高端能力”。

其实很多系统很早就该有简单路由逻辑：

分类、抽取、改写用便宜模型
最终复杂生成用强模型
高置信模板化任务优先走小模型
供应商异常时切备用模型

这本质上是在把“成本”和“质量”做成系统级策略，而不是开发者拍脑袋。

7.2 缓存也不只是 Redis 一把梭

AI 系统的缓存至少有三类思路：

精确匹配缓存：同输入直接复用结果
语义缓存：近似问题复用近似结果
前缀/KV 缓存：推理层复用共享上下文

vLLM 官方文档明确提供了 Automatic Prefix Caching 设计，用于复用前缀对应的 KV cache，从而减少重复推理开销。(docs.vllm.ai (vLLM))

这提醒我们一个很重要的架构点：缓存不只发生在应用层，也可能发生在推理层。

8. Data / Knowledge Layer：别把“有向量库”误当成“有知识系统”

AI 系统的数据层通常比传统应用更杂：

业务数据库
文档与对象存储
向量库 / 检索索引
实时缓存
特征或画像数据
外部 API
审计与事件日志

一个常见误区是：只要接了向量库，就觉得知识层搞定了。

其实向量库只解决了知识系统的一部分问题。更完整的知识层至少还包括：

文档采集
清洗与切分
元数据管理
权限映射
索引更新策略
召回与重排
多源融合
新鲜度控制
可追溯引用

这意味着，RAG 架构里最难的往往不是“query embedding 一下”，而是让知识系统变得：

可更新
可控权限
可追溯
可评估
可与业务对象关联

如果这一层做得粗糙，模型再强也会被脏知识喂偏。

9. 单体 vs 微服务：AI 系统里更应该警惕“过早拆分”

这是很多团队最容易过度讨论的话题。

一句话结论先说：

对大多数 AI 产品，早期更适合 模块化单体（modular monolith），而不是一上来就拆一堆微服务。

原因很简单：AI 系统的最主要复杂度，往往不是服务调用链，而是：

Prompt 和上下文设计
编排逻辑
模型与工具选择
评估与观测
成本优化

如果这些还没稳定，过早拆服务通常只会放大复杂度。

9.1 为什么早期单体通常更合适

迭代快
调试方便
本地开发简单
Trace 好看
跨层改动成本低
认知负担更小

尤其在 MVP 阶段，你往往还在同时修改：

产品流程
Prompt
模型
检索逻辑
前端交互
评估标准

这时候服务边界本身都还不稳，先拆成微服务很容易把不确定性固化成网络边界。

9.2 什么叫“模块化单体”比“单体”更重要

不是说把所有东西写在一个文件里，而是：

进程可以是一个
代码结构要按能力域分模块
API、应用、编排、模型接入、数据访问仍然要分层
内部边界清晰，未来才有可能自然拆分

真正可演进的系统，往往不是“从混乱单体突然进化成微服务”，而是“先有清晰模块，再按压力点拆出去”。

9.3 什么时候值得拆成微服务

通常在这些信号出现时：

1. 资源形态明显不同

比如：

推理服务需要 GPU
业务 API 服务只需要 CPU
检索服务需要高内存与高 IO
批处理任务需要异步 worker

这时分开部署通常有明显收益。

2. 团队边界已经清晰

如果模型平台、业务应用、搜索/RAG 平台已经是不同团队维护，那服务边界更容易稳定。

3. 多租户与合规要求上升

例如：

企业租户隔离
数据驻留要求
审计边界
SLA 不同

这些都会推动服务拆分。

4. 扩缩容模式差异显著

Kubernetes 官方文档明确支持 workload autoscaling，也支持 GPU 作为可调度资源，通过 device plugins 暴露给 Pod 使用。(kubernetes.io (Kubernetes))

这意味着，在 AI 系统里，“推理层单独扩 GPU，业务层维持 CPU 服务”常常是合理拆分边界。

9.4 哪些边界最适合先拆

比起按“前后端、用户、订单”这种传统域来拆，AI 系统更常见的天然拆分边界是：

推理网关 / 模型服务
检索与索引服务
异步任务 / 工作流执行器
业务 API 服务
观测与评估服务

这些边界往往和资源、职责、故障模式都更一致。

10. 核心基础设施：AI 系统很早就该有的“五件套”

很多团队会把 AI 基础设施理解成“大厂才需要”。其实有些东西应该很早就有，只是形态可以先做轻。

10.1 Prompt 管理

Prompt 不应该只是散落在代码里的字符串。它应该至少具备：

版本化
环境区分
回滚能力
实验能力
评估集对照

LangSmith 文档已经把 Prompt 作为可创建、管理、fork 和程序化拉取的对象，而不是纯手写常量。(docs.langchain.com (LangChain 文档))

10.2 模型路由与供应商抽象

哪怕早期只有一个 provider，也建议统一出口。原因不是为了“未来也许会换”，而是为了：

统计成本
做 fallback
管理参数
做实验
控制超时和重试

10.3 缓存

缓存不只为了省钱，也为了：

降低延迟
提高系统稳定性
减少重复推理
给高峰流量兜底

10.4 限流与预算

AI 请求的资源消耗远高于普通读接口，所以你不仅要限 QPS，还经常要考虑：

每用户 token 配额
每租户每日预算
高峰期队列控制
长任务并发上限

10.5 观测与 Trace

OpenTelemetry 是当前通用的 vendor-neutral 观测框架，覆盖 traces、metrics 和 logs。对 AI 系统来说，这类统一 trace 能力非常重要，因为你需要把模型调用、检索、工具、业务动作串到同一条链路里。(opentelemetry.io (OpenTelemetry))

一句更直接的话是：

线上 AI 系统如果没有可追踪的输入、Prompt、模型、检索上下文、工具调用和输出摘要，基本等于不可运维。

11. 长任务与异步处理：AI 系统里“超过 3 秒”通常就该认真设计了

传统 API 里，一个请求几百毫秒或一两秒算正常；AI 系统里，几秒只是起点。

尤其这些任务很容易变成长任务：

长文档解析
批量总结
复杂 RAG
多轮工具调用
Agent 工作流
代码生成与测试
企业审批链

所以架构上要尽早区分：

11.1 同步流式任务

适合聊天和短生成。关键目标是改善感知延迟，而不是假装任务很快。

11.2 异步任务队列

适合长流程。重要的不只是“扔进队列”，而是你要定义清楚：

任务状态
超时
重试策略
幂等性
失败通知
取消机制
中间结果可见性

11.3 长连接状态推送

适合用户需要看到过程的场景，比如：

工具调用进度
多阶段状态
协作式编辑
Agent 当前执行步骤

一个常见误区

很多系统做了异步，但没有做好状态机。结果就是：

前端只知道“处理中”
后台失败了用户也不知道
重试和重复提交分不清
同一个任务无法恢复

所以真正的问题不在“同步还是异步”，而在于：你的任务是否被当成一等对象来管理。

12. 部署模式：别把“自托管大模型”当成成熟的标志

部署问题在 AI 领域也常常被讨论得很浪漫，好像谁自托管得多，谁就更高级。

其实大多数团队一开始真正要解决的是：

需求是否已经成立
成本是否能闭环
延迟是否可接受
数据和合规是否允许外部 API
团队是否有能力运维推理栈

从这个角度看，部署模式更像一条演进路径，而不是身份象征。

12.1 API-first：大多数团队的合理起点

对于多数 AI 产品，业务层跑在自己的服务里，模型能力优先使用成熟 API，通常是最现实的选择。

优点很明确：

上线快
无需自己维护推理栈
模型升级快
GPU 运维成本低

代价也明确：

成本结构受供应商影响
可控性有限
某些合规场景可能不满足
深度推理优化空间小

12.2 容器化业务层：最常见的生产形态

即便模型走第三方 API，业务层、编排层、检索层通常也会跑在容器/Kubernetes 上。这样做的价值在于：

扩缩容灵活
环境一致
与企业基础设施整合方便
可分离 CPU 服务与 GPU 服务

12.3 自托管推理：只有在理由足够强时才值得做

适合的典型场景通常是：

合规要求数据不出域
访问量大到 API 成本失衡
需要深度控制模型与推理参数
有专门平台团队维护 GPU 资源

否则，自托管经常会把团队从“做 AI 产品”带向“做推理平台”。

13. 从 MVP 到企业级：真正该演进的不是“技术栈酷不酷”，而是系统能力

很多架构讨论的问题，不在于观点错，而在于忽略了阶段。

13.1 MVP 阶段：速度第一，但别埋太深的坑

目标通常是：

证明需求成立
找到有效交互
跑通最小可行链路

这个阶段通常更适合：

模块化单体
单模型或极少模型
最少必要的 RAG
最基本的日志、trace、配置化 Prompt
很少的异步链路

这个阶段最常见的错，不是“架构不够先进”，而是把本该配置化和可观察的东西全写死。

13.2 增长期：稳定性、成本和评估开始成为主问题

一旦开始有真实流量，架构重心会明显转向：

模型路由
Prompt 管理
缓存
观测
评估集
限流与预算
异步任务系统
检索质量优化

这时你会发现，真正限制系统增长的，通常不是“再接一个更强模型”，而是你是否能：

稳定复现问题
快速回滚策略
把坏请求挡在外面
把贵请求控制住

13.3 企业阶段：治理能力开始压过“单点效果”

到了企业级，系统关注点通常变成：

多租户
审计
权限与审批
SLA / SLO
数据隔离
合规与驻留
灰度、回滚、灾备
长流程恢复与人工介入

这时“模型答得不错”已经不够了，系统还得能被治理。

14. 一个更成熟的思路：AI 架构里同时存在“控制面”和“数据面”

如果再往上抽象一层，可以把 AI 系统理解成同时包含两类东西：

数据面（runtime path）

也就是每次请求真正走过的路径：

请求进入
检索
Prompt 构造
模型推理
工具调用
返回结果

控制面（control plane）

也就是不直接生成结果，但决定系统如何运行的那一层：

Prompt 版本管理
模型配置
灰度切换
评估集
预算策略
观测与告警
安全策略
审批与治理规则

很多系统一开始只有数据面，没有控制面，所以看起来能跑，但很难运营。

一旦有真实业务，控制面会越来越重要。因为你不只是想“调用成功”，而是想：

知道现在用的是什么 prompt 和模型版本
某次事故是否可以回滚
某个租户是否超预算
某类请求是否该走更便宜模型
某个实验版本是否真的更好

这也是为什么成熟 AI 系统最终都不只是几个接口，而会逐步长出一套平台能力。

15. 最后给一个架构判断顺序

如果你正在设计一个 AI 系统，比起先问“该不该上微服务”，更建议按这个顺序思考：

第一步：先界定 AI 只负责什么

不要让模型背业务规则的锅。先明确：

它负责理解什么
负责生成什么
负责决策到什么程度
哪些边界必须由规则系统把住

第二步：再设计分层

尤其把：

业务逻辑
AI 编排
模型接入
数据与知识访问

明确分开。

第三步：尽早补齐最小基础设施

至少包括：

Prompt 可配置
模型调用统一出口
Trace
成本统计
基本缓存
限流和预算

第四步：用模块化单体起步

除非你已经非常清楚边界和流量模式，否则不要过早拆微服务。

第五步：按真实压力点演进

谁先成为瓶颈，就先拆谁：

GPU 推理先成瓶颈，就先拆模型服务
检索先成瓶颈，就先拆检索层
长任务先成瓶颈，就先补任务系统和工作流引擎

而不是按流行架构模板一次性搭满。

小结

AI 系统架构设计的核心，不是“把模型接进去”，而是围绕 AI 这层能力的几个现实约束来重新组织系统：

它不确定，所以要做评估、校验、回退和观测
它昂贵，所以要做路由、缓存、预算和限流
它变化快，所以要把 Prompt、模型和编排从稳定业务逻辑里隔离出来
它常常更慢，所以要认真设计流式、异步和长任务处理
它会进入真实业务，所以最终一定要面对权限、审计、治理和部署演进

所以，一套好的 AI 架构并不追求“从第一天就完美”，而追求另一件事：

先把边界划清，再让系统随着真实压力逐步长出复杂度。

这比一开始就追求“终极架构图”更重要，也更接近真实工程。