企业官网建设流程全解析

上个月评审会上发生的一件事，让我特别想写写“图解AI应用架构设计”这个话题。当时我们团队在争论一个AI客服应用的分工问题：意图识别放哪一层、知识库检索结果怎么传、Agent要不要单独一个服务，七嘴八舌聊了半个小时都没对齐。最后有同事把一张A4纸大小的架构图投到屏幕上，所有人突然就安静了——原来大家争论的其实是同一个问题在不同层级上的体现：图里压根没画“上下文管理”这个模块。

这已经不是第一次了。我发现在AI应用开发里，架构设计天然比传统软件更难“聊清楚”。因为系统里多了一个不确定性的核心组件——大模型，请求链路变长，状态管理变复杂，模型、记忆、工具、向量库之间的交互关系很难用文字描述。越是这样，一张画得足够清晰的架构图就越有价值。这篇内容想跟你聊的，就是我从大量AI应用项目里沉淀下来的一整套“图解AI应用架构设计”的方法：画什么、怎么画、画完怎么用，以及那些踩过的坑。

1. 为什么AI应用架构值得一张图

不是所有软件项目都需要画架构图，但AI应用几乎是刚需。传统应用的数据流是明确的：前端调接口，接口查数据库，返回结果。AI应用则完全不同，单单一个用户请求，就可能经历意图识别、上下文拼接、工具调用、模型推理、结果校验、记忆更新六个环节，每个环节还有可能失败、重试、超时。面对这种复杂性，纯文档描述会有严重的信息损耗。

1.1 我为什么开始画架构图

最初让我入坑“图解”这件事，是因为一次线上事故。我们刚上线一个带RAG（检索增强生成）的问答应用，用户反馈回答质量时好时坏。排查到最后，问题居然出在：向量检索的结果被拼进系统提示词时，因为字段顺序写错了，导致这些检索内容在模型上下文里的位置权重出了一个极小但致命的问题。那一次我盯着代码找了一下午，如果当时架构图上把“检索结果注入上下文”这一条链路画清楚，定位问题用不了五分钟。

从那以后我给自己定了一条规矩：任何AI应用项目，必须先把架构图推演清楚再写代码。后来发现这条规矩救了我很多次，因为画图的过程本质上是在强迫你把系统里所有的依赖、时序、数据流向都暴露出来，很多设计缺陷在落笔的时候就暴露了。

1.2 一张图要解决的问题清单

同一张架构图，不同阶段解决不同的问题。我通常用图回答四个问题：

• 谁在调用谁：请求从用户到模型的完整路径，包含哪些中间节点。
• 状态放在哪里：聊天记录、向量索引、会话上下文分别存在哪个存储层。
• 失败时会发生什么：链路中哪一个环节最脆弱，降级方案画没画。
• 扩展点在哪：将来要加一个新工具，要在哪一层做修改。

这里有一个关键认知：架构图不是“画完就完了”的文档，而是一个用来推理的工具。所以我画图时非常在意信息的精确度，哪个组件负责什么、数据从哪流入哪流出、哪条链路是同步哪条是异步，都必须能一眼看出来。

2. AI应用架构的五大核心模块拆解

很多第一次做AI应用的开发者会拿着传统后端架构硬套，结果画出来的图跟普通CRUD系统长得一模一样，唯独多了个“大模型API”的方块。这不叫AI架构设计，这叫“把大模型当数据库用”。真正的AI应用架构，核心模块其实跟传统应用有明显的差异。

2.1 接入层：请求进入系统的第一道关口

接入层不复杂，但最容易被人忽略。它负责鉴权、限流、输入校验、意图粗识别。在AI应用里，接入层比传统应用多一个职责：基础安全过滤。模型本身对恶意输入、越狱提示词的防御不可控，所以接入层的护栏（Guardrail）非常重要。

我习惯在架构图的接入层画两个子模块：

• 网关：负责流量分发、鉴权、速率限制。
• 输入检查：对超长文本截断、对敏感内容拦截、对异常格式直接拒绝。

这里的实操要点是：接入层的拦截结果必须可观测。很多团队把输入检查做成了黑盒，用户不知道为什么自己的请求被拒了。我一般在接入层埋结构化日志，记录拦截原因和请求指纹，方便后续复盘。

2.2 编排与记忆层：AI应用区别于传统CRUD的地方

这张图的核心区域就是这一层。编排层（Orchestration）负责决定“下一步做什么”——是直接回复，还是先调用工具，还是先查知识库，还是多轮追问。记忆层则负责维护会话上下文、用户偏好、历史行为。

画这一层时，很多人会犯一个错误：把编排逻辑画成了一个庞大的“大脑”方块，下面挂了一堆工具。这种图画了等于没画，因为你看不出决策是怎么做的。我的建议是：把编排层的决策节点一个一个拆出来。比如“意图识别模块”“工具选择模块”“上下文组装模块”“输出校验模块”，每个模块在图上都能看清输入是什么、输出是什么。

记忆层则要区分短期记忆和长期记忆。短期记忆就是当前会话的上下文窗口内容，长期记忆可能是用户画像、历史摘要、向量化后的信息片段。这两类记忆在架构图上要用不同的存储节点表示，因为它们关联着不同的读写策略和检索策略。

2.3 模型层与工具层：能力边界在哪

模型层画的是你用的模型类型：基础大模型、微调模型、多模态模型，可能还不止一家服务商。工具层则是模型可以调用的外部能力：搜索API、计算器、数据库查询、第三方系统接口。

这里有一个架构决策重点：哪些能力放进模型层内部的系统提示词，哪些能力放进工具层。放提示词里，实现最简单但改动一次就得调一次prompt，且不稳定；放工具里，系统可以动态选择是否调用、何时调用，但代价是增加了编排复杂度。我一般的原则是：稳定不变、跟对话强相关的信息放提示词；动态获取、需要验证的信息走工具。

2.4 数据与向量存储：架构图里最容易画漏的一块

几乎所有AI应用都会涉及到知识库检索，所以数据层至少包含两块：关系型/文档数据库（存用户信息、配置、日志）和向量数据库（存嵌入向量、索引）。很多架构图只画了模型+数据库两层，完全省掉了向量库，这是把关键依赖给隐藏了。

向量库这一块画图时要注意标注三个参数：嵌入模型、相似度阈值、Top-K大小。我见过一份文档把这块讲得特别细，因为这三个参数直接决定了RAG检索的质量。比如Top-K太大，无关内容会把答案带偏；阈值设置不当，要么检索不到有效信息，要么把垃圾内容当权威依据。把这些参数标注在架构图上，运维和交接的人就能快速定位检索质量问题的根源。

3. 图解实战：从需求到架构图的完整流程

有朋友问我，架构图是从哪开始画的？是先画大框还是先画细节？我的经验是：从用户的一次请求出发，沿着数据流一路走到底，就能把主干画出来。这个流程在AI应用里特别合适，因为AI应用的链路复杂，不追着一条请求走，很容易画成“组件摆放图”而丢失时序关系。

3.1 第一步：定义用户旅程与请求链路

动手画图前，先用文字写一个典型请求的完整旅程。比如一个“AI智能客服”场景：

1. 用户输入一段带情绪的问题。
2. 接入层进行鉴权和输入检查。
3. 编排层判断是否需要检索知识库。
4. 检索模块把问题向量化后查向量库，拿到相关片段。
5. 片段和会话历史被组装成提示词。
6. 模型推理产生回答。
7. 输出校验模块检查答案内容，写入会话记录。

这一步的作用是把“顺序”定下来。我建议把这段旅程写在实际画图之前，因为后续画图时你会反复对细节做调整，有了这条主线就不容易跑偏。

3.2 第二步：识别状态与上下文存储位置

主线走完，第二步标注“状态”。在AI应用里，几乎每个环节都可能产生状态：对话历史、检索结果、选中工具的参数、模型返回的中间步骤。我在图上用不同的填充样式区分三种状态：

• 临时状态：存在内存或Redis里，超过一定时间就失效。
• 会话状态：跟一次会话绑定，存在Redis或者会话表里。
• 持久状态：用户偏好、长期记忆、向量索引，存在数据库或专门的存储里。

这一步往往能暴露最多架构问题。比如你可能会发现：为了让模型连续回答，你要把整段对话历史每次都全量传给模型，那这个应用的上下文拼接会越来越大，迟早会顶到模型窗口上限。这时候架构图上就需要增加“对话历史摘要”模块。这个问题如果不在画图阶段暴露，等到上线再改就要动大手术。

3.3 第三步：画出依赖关系与风险点

架构图不只是画给开发看的，也是给运维和测试看的。所以第三步必须把风险点直接标注出来。我习惯用不同颜色或符号标记四类风险：

• 单点依赖：模型API突然不可用怎么办，有没有备用模型或降级话术。
• 外部依赖：搜索引擎、支付接口、第三方工具挂了的影响范围。
• 数据一致性：向量库更新和原文档更新之间的延迟怎么处理的。
• 成本热点：哪个环节是大模型token消耗的大头。

画这一步时，我通常会问自己一个刁钻的问题：如果图中某个方框下周突然下线，我的应用还跑得起来吗？如果跑得起来，那么架构图有问题——因为你画了一个永远不需要的降级方案之外的东西，或者说你没有把真正的依赖暴露出来。反过来，如果某个方框挂了应用就瘫，说明这里必须有监控和告警。

3.4 用架构图反推设计方案：一张图的三次迭代

架构图不是一蹴而就的。我一般会连续画三轮：

• 第一轮：画出“理想架构”，不考虑成本和技术限制，把功能完整地画出来。
• 第二轮：砍掉过度设计。把可用可不用、吃了大量资源的模块删掉或降级。
• 第三轮：加上运维必备的内容。日志、监控、限流、降级、审计，全部补上。

这三次迭代在实践里特别高效。第一轮让你看到完整的可能性，第二轮让你务实，第三轮让你可交付。很多团队的问题是直接从第二轮开始，结果因为不了解可行性而反复返工；还有团队永远停在第一轮，画得花里胡哨但交付不了。

4. 三种主流AI应用架构模式的图解对比

画图画到一定程度，你会发现架构模式是有限的。常见的AI应用架构，本质上就是三种模式，或它们的组合。理解这三种模式的图解特征，能帮你更快地设计。

4.1 直连模式：适合简单问答场景

直连模式的架构图是最简单的：用户 → 网关 → 模型 → 返回。中间没有工具调用，没有RAG，最多加个对话历史的窗口管理。画这种图，重点是诚实：别把直连模式画成一套花哨的微服务，它就那么点内容。

直连模式的适用场景包括：简单文案生成、基础问答、翻译、代码补全等一次性任务。优点一目了然：延迟低、成本低、调试容易。缺点也明显：没有上下文能力，没有获取实时外部信息的能力，模型知识截止时间限制明显。

在画这种图时，我唯一要强调的是：把“提示词工程”画成一个模块。原因是提示词本身就是这段链路里的“逻辑代码”，它会持续迭代。我见过不少团队把提示词藏在代码配置里，从架构图上看好像不存在，实际上它却掌控着整个应用的行为。把它画出来，你才会认真管理提示词版本。

4.2 编排模式：用Workflow串起多步骤任务

编排模式会多一个明确的工作流引擎或编排逻辑模块，将任务按固定的步骤串起来。比如“AI总结周报”应用，流程是：读取邮件 → 提取重点 → 分类归并 → 生成摘要 → 发送推送。每一步都是相对确定的调用。

编排模式架构图的核心动作是画“线”：线要能体现出步骤的前后关系和条件分支。我在图中习惯用带箭头的实线表示同步调用，虚线表示异步消息，用菱形节点表示条件判断。这样一眼就能看出一个步骤失败会走哪个分支。

这种模式的难点在于：步骤之间的数据传递要非常明确。比如第2步提取的重点，要如何传给第3步做分类？是直接传文本，还是先结构化？我在画图阶段会要求团队把每一步的输出格式标注在连线旁边，免得后面开发时互相等着对方的数据结构。

4.3 智能体模式：让模型自主调度工具

Agent（智能体）模式是这几年最受关注的方向。架构图上，智能体表现为一个“决策循环”：模型在每一轮先判断当前目标是否需要调用工具，如果需要就生成工具调用参数，执行工具后将结果喂回模型，再决定下一步动作，直到认为目标已完成。

我画Agent架构图时，会把下面几个组件作为重点：

• 工具注册表：Agent能看到哪些工具，每个工具的schema描述是什么。
• 记忆管理器：负责把历史信息、当前观察结果组织好。
• 执行沙箱：工具实际运行的地方，隔离异常。

这里要给一个实战提醒：Agent模式的瓶颈往往不在模型推理能力，而在工具定义的清晰度。如果你的工具描述写得好，模型选择工具准确率会高很多；如果工具描述含糊，Agent就会频繁做出错误调用，看起来“模型不够聪明”。工具描述也是架构设计的一环，不是写完代码就完事了。

4.4 架构模式选型的决策表

为了帮自己做选择，我整理过一张选型决策表，你要是遇到选择困难可以参考：

注意，模式是可以混合使用的。比如先编排处理固定流程，在中间某一步引入Agent做开放性决策，这是很多成熟应用的现实形态。架构图上分别用不同颜色或边框把两种模式区分开，避免误导。

5. 生产环境架构设计中的关键考量

架构图画到能跑通流程的程度，只能算完成了40%。剩下60%，是应对生产环境的复杂性。特别是并发、测试和可观测性三个维度，是AI应用跟传统应用拉开差距的地方。

5.1 并发问题：AI Agent 扛不扛得住，取决于哪一层

AI Agent是否扛得住并发，很多人第一时间想到的是模型API的限流。这当然是一部分，但真正的瓶颈通常在其他层。我拆开说：

第一层瓶颈是对外部工具的并发调用。Agent在推理时可能会并发调用多个搜索接口或数据库，如果你的工具层没有连接池、没有超时控制，十个Agent实例就可能打垮下游系统。

第二层瓶颈是上下文组装和记忆读写的竞争。多轮对话场景下，同一个用户的多个请求可能同时读写同一段会话记忆，处理不好就会产生不可预期的上下文混乱。架构图上记忆模块旁边，一定要标上“并发控制策略”。

第三层瓶颈是模型推理本身的排队。即使API服务商不限流，你的应用在高峰期也可能产生大量排队请求，导致用户等待时间超长。应对方案要么是队列化异步处理，要么是设置用户级并发上限，要么是多模型负载均衡。

我自己的实操经验是：画架构图时专门画一个“并发水位”标注，把每一层预估的QPS容量标在旁边。不用非常精确，大致量级即可。这一步能帮你及时发现“上线前才发现根本跑不动”的尴尬。

5.2 测试与评估：AI架构的“质量保障网”

AI应用的测试跟传统应用完全不是一回事。传统应用可以直接断言输入输出，AI应用输出有随机性，你怎么断言？所以架构图里必须包含一套“评估闭环”：从测试集、评估指标到回归测试的完整链路。

我把AI测试分成两层：

• 功能测试：验证架构组件的配置和调用正确。比如工具是否被正确触发、数据是否被正确传递、向量检索是否返回预期片段。
• 质量评估：验证模型输出本身的质量。人工评分、自动化打分、A/B对比等。

在做测试开发时，特别注重一个指标：工具调用的准确率和无效调用率。一个Agent如果频繁调用不相关的工具，说明工具的调度逻辑出问题了。这类问题可以通过埋点统计来量化。

在架构图上，我会把“评估服务”单独画出来，跟线上服务并行。每一次线上真实请求都可以抽样进入评估流程，用来持续监控模型质量的漂移。不少团队觉得这很重，但我可以明确告诉你：没有这个模块的AI应用，上线之后基本靠运气。

5.3 可观测性：架构图上没有监控节点等于白画

架构图最后一定是要跟可观测系统对齐的。我见过太多了：架构图画得漂漂亮亮，线上出问题时却连“哪个环节慢”都说不清。原因只有一个：监控节点没有跟架构图对应起来。

在AI应用里，有三个观测点是必须画的：

• 模型调用日志：包括输入和输出token数、延迟、模型名、提示词版本。
• 工具调用日志：工具名、入参、出参、耗时、状态码。
• 上下文拼接快照：每轮请求实际传给模型的消息体长度、检索片段的来源。

这三个观测点对应AI应用最常出问题的三个位置：模型抽风、工具异常、上下文被污染。把观测点和架构图对齐，排障时就可以拿着图一层层看数据，而不是拿着代码一行行猜。

在实践上，我习惯给每个模块加上一个唯一的追踪ID，贯穿从请求进入到最终返回的全过程。这个ID在日志里串联起所有环节，配合图上标注的模块名，排障效率能提高好几倍。

6. 常见设计误区与排查实录

画多了架构图，也帮其他人review了无数张图以后，我发现大部分AI应用架构的问题都是有共性的。这里挑几个出现频率最高的误区，每一个都是我用真金白银换回来的教训。

6.1 误区一：把所有逻辑塞进提示词

刚接触AI应用的团队，特别喜欢把“聪明”体现在系统提示词里：流程描述、判断规则、知识问答、禁止事项全堆进去，写出来几千字。这种做法的短期效果不错，模型确实能照着执行，但时间一长问题就出来了。

最大的问题是不可测试。提示词像一锅粥，你没法单独验证其中某一条规则的命中率。改一句话，可能影响整个行为。架构图上，如果所有业务逻辑都塞在“提示词”模块里，这个图基本就没有优化空间了。

我的处理方案是：把大段提示词拆成多个模块——系统指令、少样本示例、工具说明、用户指令模板。架构图上分别画出来，各自有自己的版本管理和评测数据。这样哪怕某个模块要调整，影响面也能控制住。

6.2 误区二：对模型输出稳定性的过度信任

哪怕是最强的大模型，输出也不是稳定的。同一个问题换个说法，模型就可能在工具调用A和B之间摇摆。不少架构图把“模型输出解析”当作理所当然，直接用正则匹配或者JSON解析，结果生产上一堆解析失败。

唾手可得的解决办法是增加一层“结构化输出校验”。我常用的做法是：让模型输出JSON格式，再用代码做Schema校验，校验不过就触发一次重试，重试时把错误信息反馈给模型让它修正。这一层必须在架构图上体现，因为它的存在会显著改变链路延迟和调用次数。

还有一个被我反复教训的经验：模型返回的内容一定要做长度限制，不然用户可能收到一篇莫名其妙的万字作文。

6.3 实测案例对比：一张图引发的重构

用一个实际案例来收尾这一章。去年我们复盘过一个对话式数据分析产品，当时架构图里编排层混了三个职责，导致遇到复杂问题时，模型经常调用错工具。

我们重新画了一遍架构图，把原来一个大方块拆成了“意图路由”“参数提取”“工具调度”“结果校验”四个模块。单纯从图面上看，变复杂了；但从实际运行效果看，复杂查询的准确率提升了约25%。原因很简单：职责拆分后，每个模块的提示词短了、工具描述定位准了、缓存命中率也上去了。

复盘时我们都感慨，画图这个动作本身不产生代码，但它逼着你把复杂问题拆解清楚。那个项目的成功，不是因为我们写了更聪明的算法，而是因为我们终于画对了那张图。

7. 画图工具选型与个人心得

到文末，聊聊画架构图用的工具。很多人纠结要不要用专业绘图软件，我个人的结论是：工具不重要，重要的是图的表达习惯和信息完整度。Excel画出来的图也能救命，只要信息对。

7.1 我试过的几种画法

按场景分类的话：

• 快速沟通：白板、纸笔、平板的涂鸦模式，适合小组讨论，特点是快、糙、容易改。
• 技术文档：绘图工具输出正式版本，作为沉淀文档。
• 代码化图表：用代码描述架构图，好处是能进Git仓库参与版本管理和Diff审查。
• 演示汇报：适合给老板和客户看，重点画大方向，少画细节。

我最常用的方式是从白板快速草图开始，验证完设计后，再用工具画正式版。官方架构评审时，正式版的图必须包含我在前几章讲到的状态标注、风险点和监控节点。如果一张图只能让人看懂模块关系，却看不到数据流向和失败行为，我宁可让它回到草稿阶段。

7.2 图解在文档之外的额外作用

最后聊一个可能反直觉的体会：画架构图最大的受益者其实是画图的人自己。我在设计AI应用时，画图能倒逼自己直面那些容易偷懒跳过的问题：这个问题我真的想清楚了吗？这段链路有重复造轮子吗？这个模块的输入输出具体是什么？

另外，架构图还是团队协作的语言。新同学看文档可能需要一个星期，但看一张好的架构图加半小时讲解，基本就能理解系统主干。项目组成员跨部门沟通时，一张图比十页PPT都好使——图能把信息密度和复杂度压在一个平面里，让所有人用同一个视角看问题。

所以在我的团队里，架构图跟代码一样，是要被review的。你得能解释清楚图里的每一个节点存在的必要性，削它、挪它、合并它会有什么后果。这个过程很较真，但也是AI应用架构设计里最有价值的部分之一。

说到底，AI应用的时代变化很快，模型更强、工具更多、范式更新，但“把系统想清楚再动手”这件事永远不过时。而把系统想清楚，最好的起点，就是好好画一张图。