AI应用架构设计：一张图画清模块与数据流

刚开始接触AI应用开发的时候，我犯过一个特别蠢的错误：代码还没写几行，先花了一周时间把模型接口调通了，结果到了联调阶段才发现整个系统的数据流是乱的，用户请求进来之后不知道去哪取上下文，模型返回结果也不知道该往哪儿写，最后只能推倒重来。后来养成一个习惯，不管项目多小，先画一张AI应用架构图再动代码。就是这个习惯，帮我避免了无数次返工。

今天想聊的，就是这件看起来不起眼、实际上能救命的事：“图解AI应用架构设计”。不聊那些高大上的“大模型平台蓝图”，就说说一个普通的AI应用——比如智能问答、文档分析、Agent工具——从想法到落地，架构图应该怎么画、画完怎么用、里面每个格子到底在解决什么问题。适合正在做AI应用开发、想从“调通接口”走向“搭好系统”的工程师，也适合那些项目刚起步、还没理清模块边界的团队。

1. 为什么AI应用架构要先画图再动手

我一直觉得，AI应用和传统后端开发的本质区别，不在于“用了大模型”，而在于它的不确定性被放大了。传统接口的行为是可预期的，输入合法输出基本可测。但AI应用不一样，模型输出有概率性，同样的Prompt可能给出不同的答案，而且模型本身不持有业务上下文，你需要想清楚上下文从哪里来、经过什么处理、最终怎么被模型消费。这些问题不先想明白，代码写得再快也会被推倒。

1.1 架构图解决的是“看不见的依赖”

很多人写代码是靠脑子记依赖关系的，小项目还行，一旦模块超过六七个，就会开始乱套。典型的现象是：一个模块改了接口签名，结果调用方漏改，编译过了但运行时数据格式对不上，AI应用里这种坑尤其常见，因为很多数据是自然语言和结构化数据混在一起，类型错误往往不是编译期报出来的，而是到了推理阶段模型给了个奇怪回答你才发现。

架构图在这里的真正价值，是把每个模块之间的显式和隐式依赖摆在明面上。你要画的不是“系统结构图”，而是“数据流向+控制流向+外部依赖”三合一的图。画完这张图，你才能回答几个致命问题：模型到底在系统的第几层？知识库的更新路径是什么？用户会话状态存在哪里？异常时降级到哪一步？

我自己的经验是，架构图的第一版一定很粗糙，甚至很丑，但没关系。画图这个动作本身会逼你把系统边界划清楚：哪些是外部依赖（模型API、向量库、网关），哪些是自研模块（服务层、调度层、缓存层），哪些是配置而非代码（Prompt模板、模型参数、知识库索引策略）。

1.2 什么样的AI应用值得画架构图

不是所有AI功能都要画完整架构图。比如你只是调一个翻译接口、套一个文本分类模型，那谈不上架构。但一旦出现以下特征中的任意两条，架构图就应该出现在你的开发流程里：

• 有多个外部AI服务协作，比如大模型负责生成、语音识别负责输入、视觉模型负责分析截图
• 有持久化存储，尤其是向量数据库或文档仓库
• 同一份知识/上下文被多个功能模块共享
• 需要面向真实用户，有并发、延迟、成本约束
• 需要人工介入或审核机制

比如做一个“企业知识库问答机器人”，表面上就是个对话接口，实际上涉及文档解析、切片、向量化、检索、重排、Prompt组装、生成、引用追溯、权限过滤，这些环节只要有一个断了，用户感知就是“AI胡言乱语”。而架构图能让你一眼看出“权限过滤”在链路中的位置是否在检索之前，而不是等上线后被用户告到客服。

1.3 图解法的核心思路：分层不越层

任何一张好的AI应用架构图，都遵循一个原则：分层清晰、边界明确。我会把AI应用划分成四层：接入层、业务逻辑层、AI能力层、数据层。每一层只跟相邻层通信，不跨层跳转。

• 接入层：负责用户输入输出格式转换、鉴权、限流、协议适配
• 业务逻辑层：负责会话管理、业务规则校验、Prompt模板路由、工具调用编排
• AI能力层：负责模型调用、RAG检索、结果后处理、多模型路由
• 数据层：负责向量库、关系库、文档存储、缓存

“不越层”这个约束很多人不以为然，实际操作中就是这条约束帮你挡住灾难的。比如有人图省事，直接在接入层拼接Prompt字符串，把业务逻辑和模型调用耦合在一起。初期很爽，等Prompt迭代到第三版、用户权限规则也塞进去之后，接入层会膨胀成“上帝模块”，改一行Prompt要重新部署接入服务。分层画图、按层开发、按层部署，这句话本身就是架构设计最核心的纪律。

2. 一张图说清AI应用的核心模块

AI应用架构图不是只有“模型”和“数据库”两个盒子的示意图。真正可用的架构图，必须把每个模块的职责、关键接口、典型实现技术都标注出来。这一节我用一个实际的“AI文档问答助手”作为例子，拆解一张中等复杂度架构图里必须出现的模块。

2.1 接入层：不止是API网关

接入层是面向外部世界的窗口，很多AI应用的体验问题其实都出在这一层。它要处理的远不止“转发请求”这一件事。

首先是输入校验。用户传上来的可能是文件、图片、语音、长文本，你得判断格式合法性、大小限制，以及是不是恶意内容。其次是鉴权，B端场景要校验租户和角色，C端场景要管理匿名用户和登录用户的配额。接着是限流，模型API有成本和并发限制，接入层不做限流，上游服务被拖垮只是时间问题。最后是协议适配，同一个功能可能同时要支持HTTP同步返回和SSE流式输出，这一步必须在接入层完成。

我在架构图里给接入层画的典型组件包括：路由网关、会话初始化器、输入校验器、流式输出适配器。注意，接入层永远不要写业务规则，不要出现“如果用户上传的是合同类型文档，就走深度解析流程”这种逻辑，那是业务层的事情。

2.2 业务逻辑层：AI应用的“大脑皮层”

如果AI能力层是“思考层”，业务逻辑层就是“决策层”。这一层负责理解用户意图属于哪个场景、该调用哪些工具、需要从哪些数据源取上下文、最终用哪套Prompt模板。

一个容易被忽略的事实是：AI应用里90%的业务逻辑不是“判断-执行”这种确定性代码，而是“组装上下文-选模板-决定是否检索”这类半确定性流程。比如用户问“根据上季度销售数据，分析华东区增长原因”，业务逻辑层要做的事包括：识别这是数据分析场景、检查当前用户有没有华东区权限、把问题拆成检索条件和分析指令、决定是否需要调用SQL生成工具。这些决策如果都塞到提示词里让模型自由发挥，结果你也能想象——模型确实很聪明，但没有权限约束的聪明就是事故隐患。

业务逻辑层在架构图中要画清楚的子模块有四个：会话状态管理器、Prompt模板路由、工具编排中心、策略配置中心。会话状态管理器维护多轮对话的上下文摘要和引用信息；Prompt模板路由根据场景选择不同的提示词模板并完成变量填充；工具编排中心负责调度外部工具调用（比如搜索、SQL查询、维基检索）；策略配置中心则集中管理模型选择、温度参数、超时时间这些“运行时配置”。这层是架构图里最复杂的一块，但也正是这层决定了你的AI应用是“玩具”还是“产品”。

2.3 AI能力层：模型不是唯一的重点

很多刚入门的人把AI能力层理解成“放模型的地方”，画一个OpenAI的方框再加一个Llama的方框就完事了。实际上这一层的核心是“围绕模型的一系列工程能力”。

回答LLM调用的稳定性问题，你需要一个模型网关组件，负责多模型路由、重试、降级、成本统计。为了让回答不超时，你要支持流式输出。为了让模型不乱说，你要在AI能力层加入结果校验组件。至于RAG，它的完整链路（文档切片、向量化、索引、检索、重排序、上下文拼接）更是AI能力层的主战场。

如果你把RAG的每个环节都画在AI能力层的框里，你的架构图已经比市面上六成博文里的示意图专业了。RAG的每个环节单独看都不难，难的是它们之间的衔接：文档在何时被切块？切片后是否保留元数据？向量索引更新与业务数据变更如何同步？检索时topK取多少？重排模型和生成模型如何配合？这些细节全都在AI能力层的边界内，一个成熟AI应用的竞争力恰恰就藏在这一层的工程化深度里。

2.4 数据层：向量库不是银弹

数据层是架构图的地基，但很多人对AI应用数据层的理解只停留在“PostgreSQL+向量数据库”这种技术选型层面。我建议把数据层进一步拆成四个存储区：

• 源数据区：原始文档、图片、音视频等非结构化数据，存对象存储或文件系统
• 结构化业务区：用户信息、权限关系、业务订单等明确结构的数据，存关系型数据库
• 语义索引区：文档切片后的向量，以及标量过滤字段，存向量数据库
• 缓存区：高频问答、模型响应、检索结果的临时缓存，存Redis

画数据层的时候，重点要标出“数据流向”。文档进来之后是先到源数据区，再经处理管线进入语义索引区；业务数据变更时，需要同步更新索引区里对应的向量；用户问答时产生的上下文，则读写缓存区。一个没有箭头的数据层，画得再漂亮也是死的。

3. 从请求到响应的数据流设计

架构图如果只有模块和连线，那训练有经验的工程师一天能画三张，但全是废纸。真正让架构图有生命力的，是数据流——一份请求从用户端出发，经历了哪些模块，在每个模块里被加工成了什么形态，最后如何回到用户手里。

3.1 时序视角：一次完整问答的六步链路

我习惯在架构图之外补一张时序图，把一次典型的问答请求拆成六步。不要用只在架构图里画箭头然后自high，一定要走一遍时序图，才能发现隐藏的问题。

第一步，用户输入经过接入层的输入校验和鉴权，被包装成内部标准请求格式，写入会话上下文（会话状态管理器）。第二步，业务逻辑层意图识别：这里既可以用规则匹配，也可以用小模型分类，或者直接让大模型判断，但无论哪种方式，决策结果必须结构化，作为后续路由依据。第三步，检索触发：如果判定需要知识库内容，业务逻辑层调用AI能力层的RAG链路，根据当前会话上下文生成检索Query，去向量库召回topK候选。第四步，Prompt组装：业务逻辑层根据场景选择Prompt模板，将检索结果、会话历史、用户输入、业务规则拼装成最终的模型输入。第五步，模型推理：AI能力层通过模型网关调用模型，支持流式返回，并把原始输出传给结果校验组件（格式检查、内容安全过滤、引用完整性校验）。第六步，结果回写：业务逻辑层把最终回答写入会话存储和缓存，再经接入层返回给用户。

这六步走完，你会发现两个关键真相：真正调用模型前后的大量工作才是架构差异所在；上下文质量决定了回答质量，而上下文是在第二步到第四步之间被加工出来的。一张架构图+一张时序图组合使用，能帮你把“AI应用”从玄学变成工程。

3.2 异步与同步的边界选择

AI推理耗时较长（首Token几百毫秒到几秒都很常见），如果在链路中同步等待模型结果，你的API服务线程就会被无限拖住。因此数据流设计里必须明确区分“同步处理”和“异步处理”的边界。

我的经验是两个原则：用户体验需要即时反馈的，用流式输出（SSE/WebSocket）把等待感降到最低；重计算或长流程的，用任务队列（Celery、BullMQ）异步处理。比如文档解析、批量向量化、定时知识库更新，这些绝不可以在用户请求线程里做，否则一次上传就把服务搞崩了。

以“文档问答助手”为例，用户上传PDF后应该立刻响应“文件已接收，解析中”，后台任务队列异步处理文档解析、切片、向量化，完成后回调更新索引状态。用户多轮对话时则用SSE流式输出，边推理边返回。这条边界如果不在架构图里画清楚，开发过程中必然会出现谁等谁的问题：是把解析过程拖到对话请求里，还是让用户等文件解析完才能发问题——两个都是坏选择。

3.3 缓存策略：AI应用的隐形加速器

AI应用里最容易被低估的模块是缓存。模型调用贵且慢，如果你的AI应用每天都有一大堆完全相同的重复问题打到模型上，烧的就不只是钱，还有用户体验。

我一般在三个位置加缓存。第一个是业务逻辑层入口的“整回答缓存”，适合对同一问题、同一用户、会话状态下结果一致且不会过期的场景，用问题Hash+用户Id做Key，命中直接返回历史回答。这个缓存对数据变化不敏感的场景特别有效。第二个是AI能力层的“中间结果缓存”，比如RAG检索结果缓存：同样的Query在短时间内再次检索，向量和重排结果大概率一样，缓存检索结果能省下二次向量计算。第三个是Prompt模板渲染结果缓存，尤其是模板里拼接了大量静态知识与固定业务规则时，把渲染结果缓存下来能减少字符串处理和上下文组装耗时。

缓存最大坑在于失效问题，索引更新后旧缓存还在，用户得到的答案和最新知识不一致。我的做法是在数据流图里专门画一条“索引更新触发缓存失效”的虚线，无论是文档新增还是删除，都必须联动清除相关上下文的缓存。没有这条虚线，缓存就是你的知识库版本分裂的元凶。

4. 模型层选型与部署策略

架构图画到最后，总归要落到一个关键问题：你的模型从哪来、跑在哪、怎么调节奏。模型层选型不是“哪个强用哪个”，而是基于延迟、成本、可控性、数据合规四个维度综合权衡的结果。

4.1 API调用还是私有化部署

先从最简单的维度讲起。如果团队没有GPU资源、数据合规压力不大、业务对延迟容忍度较高，直接调用商业模型API是最快路径。优点是几乎零运维成本，模型能力迭代由供应商负责，你只需要关注应用层工程；缺点是单次调用成本会随着业务规模增长变得不可忽视，并且存在数据外发合规风险。

如果业务数据敏感，或需要完全控制推理延迟与可用性，就要考虑私有化部署开源模型。像Qwen、Llama这类相对成熟的开放模型在中等规模场景下完全可用。但请注意：私有化部署不等于“装个Ollama就完事”，你要自建推理服务，处理显存管理、并发排队、模型分片、版本热更新、推理日志与监控。架构图上至少要多出三个组件：推理服务、模型仓库、GPU资源监控。我个人对中小团队的建议是采用“混合路线”：核心高价值场景私有化，冷门低频场景走API，这个决策在架构图里就应该被清晰标注。

4.2 模型网关：多模型共存的必需品

AI应用架构图里如果只画了一个模型方框，我基本可以判断这个应用走不远。模型供应商随时可能调整版本、限流、涨价，单一模型的故障意味着整个应用瘫痪。所以在AI能力层一定要有一个模型网关。

模型网关的核心能力有四块。第一，路由策略：按业务场景/用户等级/QPS权重把请求分发到不同模型；第二，重试与降级：上游超时或报错时自动重试，对非关键请求可以降级到小模型或模板回答；第三，成本统计：记录每个场景、每个用户、每个模型的Token消耗，把成本归因到业务线；第四，缓存与限流：对重复请求做语义级缓存，同时用维度限流保护下游模型。这四块能力落到架构图上，就是AI能力层里最核心的一个组件。

我见过一个真实案例：某团队自研AI客服，刚开始直接写死调用GPT-4，后来某天上游服务波动，客服系统整瘫一上午。架构调整后引入模型网关，默认走自有部署的Qwen模型，复杂问题才升级到GPT-4，同时配置了重试3次和熔断降级，之后再也没因为单模型服务不稳定影响过主流程。这种“看不见的稳定性”才是架构设计的真正价值。

4.3 推理参数与架构设计的关系

最后聊一个很多人忽略的“软参数”：温度、Top-p、max_tokens、重复惩罚这些推理参数，它们不只是模型推理的问题，还应该反映在架构设计的配置中心里。

原因是：不同场景下推理参数差距极大。比如客服工单分类，想要稳定，温度设0或接近0；营销文案生成，想要创意，温度设0.8-1.0；代码生成，想要确定性又要一定灵活，温度设0.2。如果你的架构把这些参数分散写在业务代码里，每次调整都要发版；如果抽到配置中心，产品经理都可以在后台调。更关键的是，模型网关的多重路由策略本身就是基于这些参数生成不同的推理Profile。所以说，推理参数不是模型工程师的私事，它是架构层“配置策略”的一部分。

我在架构图里专门给“策略配置中心”加了一个小方块，里面列出模型选择、温度、超时时间、重试次数、缓存TTL等。这个方块能时刻提醒我：架构不仅是静态的图，还是运行时可变参数的载体。

5. 实操过程与核心环节实现

思路讲了一大堆，落地才是硬道理。这一节我分享一个从0到1画AI应用架构图并照着搭建的完整实操过程。拿“企业内部智能问答机器人”举例，结合前面拆的模块，一步步来看最终架构图长什么样、模块之间怎么连。

5.1 第一步：确认业务边界和核心流程

动笔画架构图之前，先拿一页纸写下最核心的业务场景和问题清单。不需要列表很多，五个以内即可。比如这个企业内部问答机器人，核心场景是：员工询问制度政策（如休假规则）、员工查询项目信息（如某客户进展）、上传新文档并让机器人学习。问题清单包括：回答的实时性要求是多高、涉及的权限体系复杂吗、文档更新频率如何、知识库冷启动的数据量有多大、允许的模型成本上限是多少。

工具上用简单的“场景×问题”矩阵就能梳理清楚。我画了一张表，横向是场景，纵向是刚才提到的非功能指标：数据敏感度、实时性、成本、容错容忍度。每个格子做简单标注。这个矩阵就是架构图的第一层输入：它告诉你接入层要不要做复杂的权限集成、业务逻辑层的策略配置要覆盖哪些场景、数据层的索引更新策略要设计到什么程度。

5.2 第二步：画出轻量级分层架构图

接着就是动手画分层架构图。不用专业工具，白纸、白板或者draw.io都行。我从上到下画四层：接入层、业务逻辑层、AI能力层、数据层。然后在每层里摆组件。

接入层画出：网关、SSE适配器、鉴权模块。业务逻辑层画出：会话管理器、意图路由器、Prompt模板中心、工具编排器、策略配置中心。AI能力层画出：模型网关、RAG检索服务、结果校验器。数据层画出：Redis缓存、PostgreSQL业务库、向量数据库Milvus、对象存储MinIO。

层的右侧再画两个竖条：偏左侧放外部依赖（用户权限系统、邮件服务、OA接口），偏右侧放非功能性设施（监控、日志、告警）。层与层之间用箭头连起来，标注“同步调用”或“异步事件”。画出来之后退后两步看这张图，如果你能顺着箭头把一次问答流程从头走到尾，这张图就合格了。

5.3 第三步：落地核心代码骨架

架构图确认后，代码骨架其实已经可以照图搭了。我用FastAPI作为接入层和业务层的载体，核心代码分模块，对应架构图的层。关键骨架如下：

# 目录结构 ai_assistant/ ├── api/ # 接入层：路由、鉴权、SSE ├── core/ # 业务逻辑层：会话、意图、Prompt路由 ├── ai/ # AI能力层：模型网关、RAG链路 ├── data/ # 数据层：SQLAlchemy、Redis、向量库客户端 ├── config/ # 策略配置中心：YAML管理推理参数 └── main.py

模型网关的核心接口，我写的比较简洁：

# ai/model_gateway.py async def chat_with_gateway(req: ChatRequest) -> ChatResponse: # 优先尝试私有化部署的Qwen模型 try: resp = await qwen_client.chat( messages=req.messages, temperature=req.temperature, max_tokens=req.max_tokens, ) return resp except QwenUnavailableError: # 降级到备用云上模型，做一层超时控制 async with timeout(10): resp = await cloud_api.chat( model="fallback-model-v2", messages=req.messages, ) return resp

这个网关的“重试与降级”逻辑看架构图一目了然，模型框不再是一个孤零零的盒子。如果当初没画架构图，大概率你会把这两个模型的调用逻辑写死在两个不同的业务模块里，各管各的，崩溃时才发现没有一个统一兜底。

RAG检索服务的核心，把向量检索和业务权限结合起来：

# ai/rag_retriever.py def retrieve(user_id: str, query: str, top_k: int = 5): # 先从Redis查相同Query的缓存, 命中则跳过向量检索 cache_key = f"rag:{hash(query)}:{user_id}" cached = redis_client.get(cache_key) if cached: return json.loads(cached) # 向量检索 + 元数据过虑 (权限隔离) docs = vector_store.search( collection="enterprise_kb", query_embedding=embed(query), top_k=top_k, filter={"allowed_dept_ids": get_user_dept_ids(user_id)}, ) # 把检索结果缓存 redis_client.setex(cache_key, ttl=300, value=json.dumps(docs)) return docs

这段代码就对应了架构图里AI能力层的RAG服务和数据层的缓存组件。初次上手的人可能觉得“就这几行代码有什么好架构的”，但你把向量检索和权限过滤放在同一个函数里，就是“数据层权限在检索之前”这个架构决策的体现，这比在模型生成之后筛结果要可靠得多。

Prompt模板和策略配置中心的落地也是这样。我把每个场景的Prompt拆成独立的YAML配置，意图路由器从这里读取场景对应的模板路径：

# config/prompts/leave_policy.yaml system: | 你是企业内部政策问答助手，请严格根据下文中提供的文档内容回答， 不要自行发挥。若文档中没有明确说明，请回复"抱歉，暂无该政策细节"。 context: | 【公司休假政策】 {retrieved_kb} user: | 用户的提问：{input} 以上问题请给出准确、简洁的回答，并注明政策出处。

这样一来，产品经理想调Prompt文案，不需要动代码，改配置即可。架构图中的策略配置中心就直接落实到这样一个文件目录里。这就是工程化和非工程化的差距：广告素材的AI应用也能回答用户问题，但没法快速迭代配置，没法最低成本地让产品参与调优。

5.4 第四步：为每一次请求做端到端联调

架构图定稿、骨架代码跑通之后，就进入联调阶段。我的建议是：不要用一个假想的“正确答案”来验证，而是准备一组有代表性的测试用例，覆盖核心架构决策的每一个分支。

比如：命中缓存的重复问题（验证Redis链路）、需要知识库检索的复杂问题（验证向量召回和重排链路）、权限不足的问题（验证检索过滤链路）、上游模型超时的场景（验证降级链路）、流式输出时网络中断的恢复（验证SSE断线重连）。每一条用例，都要对照架构图里对应的那条链路。

这轮联调的核心目的不是验证功能正确，而是验证每一个架构决策在真实运行中的表现。模型网关的重试会不会导致重复扣费？缓存命中后是否需要更新会话历史？降级到备用模型后，Prompt模板是否兼容？这些细节问题，早期暴露一个就修复一个，比上线后被真实用户“测”出来强一百倍。

6. 常见问题与排查技巧实录

架构设计做多了，你会发现在AI应用这个领域，问题总是出现在几个固定位置。这一节把我在实际项目中反复踩过的坑整理成一份速查表，每个都对标架构图里的具体模块。

6.1 架构图常见问题速查表

这张表是我做AI应用架构咨询时用得最频繁的一张表，几乎可以覆盖六成以上的线上问题。

6.2 排查时的三条实操心得

第一，永远从架构图开始定位，而不是从代码开始。出现线上问题时，把架构图摊开，顺着请求链路逐段打日志、看指标。基于“分层不越层”的架构，你可以快速隔离故障在哪一层，而不用在一万行代码里翻找。每次排查完，把问题原因标注在架构图对应组件上，一张张标注过的图就是团队最珍贵的故障知识库。

第二，AI应用的日志设计要围绕请求链路来建。给每个请求分配一个traceId，从接入层开始透传到模型网关和RAG服务。这样不管问题出在Prompt组装还是模型调用，你都可以用同一个traceId串起完整日志。不建这条链路，AI应用出问题会特别痛苦，因为你连“模型到底收到了什么上下文”都查不到。

第三，把“模型输出的质量”纳入监控指标。传统应用监控的是错误率、时延、吞吐，AI应用还要多一个回答质量维度。最简单的做法是随机采样部分回答，由脚本做规则校验（比如是否包含引用、是否为空、是否超长），再配合人工抽检。架构图里AI能力层的结果校验器不是摆设，它是质量监控的第一道关卡。

6.3 独家避坑技巧：先画“丑图”再“美化”

最后一个技巧，也是最容易被忽略的：第一版架构图一定要画得像草稿，不要追求完美。很多团队在架构评审会上花几个小时争论箭头是实线还是虚线、组件名字用“搜索引擎”还是“信息检索服务”，这种争论毫无意义。架构图的本质是信息传递工具，画给开发团队看、画给自己理清思路，不是参加设计比赛。

我自己的做法是：先用铅笔或白板，画出一个能解释通的草图，用“模块+箭头+一句话注释”的格式。草图确认后，再花十分钟用draw.io或excalidraw整理成电子版，发给团队。这里有一个很重要的细节：电子版架构图一定要带上“数据流方向”的标注，让新加入的工程师能够顺着图读懂系统，而不是靠问人。一个合格的架构图，应该让一个不熟悉项目的人十分钟内回答出“用户请求到达后依次经过哪些模块”“哪些模块是强依赖，哪些可以降级”这两个问题。

写在最后的经验分享

我个人的体会是，AI应用架构设计跟传统软件架构最大的不同在于，它需要同时处理“工程的确定性”和“模型的不确定性”。确定性的部分，比如数据流、缓存、权限、限流、部署，还可以沿用传统架构的经验；不确定性的部分，比如Prompt质量、模型波动、检索召回效果，则必须在架构上留出缓冲和降级空间。画好一张AI应用架构图，就是给这两部分划清边界，让确定性的工程系统能承载不确定性的模型行为。

还有一个小技巧是我做每一个项目都会用到的：架构图不是画完就扔的，它需要跟代码同步演进。每过半程或大版本迭代，把当前架构图和实际代码对照一遍，看有没有模块被悄悄跨层调用、有没有新增的依赖没有画进去。这个习惯看着简单，但能让你始终对整套系统保持全局感，不会走着走着就迷失在代码的细节里。希望这篇分享能对你手头的AI应用有点帮助——先画图，再写码，省下的是真金白银的返工时间。