企业官网建设流程全解析

开头

前几周我帮一个团队评审他们的AI客服项目，团队负责人打开PPT，里面放了一张架构图——说真的，那张图我看了十分钟都没看明白。箭头从数据库直接画到大模型接口，中间夹着两个不知道干什么的微服务，缓存和消息队列全堆在角落里。更要命的是，图里找不到“业务输入”到底从哪里进来。

这不是个例。我看了很多AI应用的项目文档，发现一个普遍问题：大家不是不会做AI应用，而是不会把AI应用的架构“画”清楚。可架构图恰恰是AI项目里最值钱的一页纸——需求评审要靠它对齐，研发排期要靠它拆任务，线上出问题要靠它定位，新人入职要靠它上手。

这些年我参与过不少AI应用的设计和评审，从智能问答、内容生成工具到多Agent协作系统，也逐渐总结出一套画AI应用架构图的方法论。这篇文章就把这套方法完整拆出来讲，结合图解思路，聊聊AI应用到底怎么分层、Agent内部结构怎么画、数据流怎么标、并发压力怎么体现，以及我们在实战中踩过的那些坑。不管你是产品经理、后端工程师还是技术负责人，只要手头在做一个带AI功能的应用，这篇文章应该能帮你把脑子里的架构整理成别人一看就懂的样子。

1. 为什么AI应用架构必须先“画清楚”再动手做

1.1 不画图直接开干，最容易翻车

AI应用与传统软件相比，多了一个很不确定的部分：模型调用。传统接口是“输入参数、输出确定结果”，模型接口是“输入提示词、输出概率性结果”。这种不确定性让很多人在设计阶段就开始模糊——需求没说清楚上下文怎么管理，数据库字段先按老经验建，Agent要调几个工具也没定。

不画架构图直接写代码，我见过的最典型翻车场景是这样的：产品经理说要做“AI知识库问答”，后端工程师直接调了大模型接口，把用户问题拼一段提示词发过去，返回结果直接展示。前期demo跑得飞快，但一到生产环境就出问题——上下文一长，Token费用飙升；用户问了两轮，模型忘了之前聊过什么；知识库更新了但回答的还是旧内容。本质上是架构根本没有设计，没有上下文管理层，没有检索层，没有数据同步机制。

反过来说，如果动手前先花半天把架构图推演一遍，这些问题大部分能在白板上暴露出来。

1.2 架构图的三种常见误区

结合我看过的项目文档，画AI应用架构图最容易掉进三个坑。

第一个坑是“把部署图当架构图”。图里画了一堆Kubernetes节点、Nginx、Redis、数据库实例，看起来非常“硬核”，但完全看不出业务逻辑怎么流转。架构图的核心不是服务器怎么部署，而是组件之间怎么协作、数据怎么流动。

第二个坑是“画成功能清单”。把智能问答、文档总结、语音识别、代码生成这些功能全部平铺在图上，每个功能拉一条线指向大模型接口。这种图本质上是功能列表，不是架构。AI应用的多模块往往是复用一个模型底座、共享一套上下文机制和工具调用链路的，架构图要体现这种复用关系。

第三个坑是“只画同步调用链”。用户请求进来，调模型，返回结果，图就结束了。实际上AI应用的复杂度恰恰在链路之外——历史会话存哪里、知识库怎么更新、Agent工具调用失败怎么重试、用户反馈怎么回流，这些都是架构的一部分。

搞清楚了这三个坑，接下来就可以讲正确画法了。

2. 分层视角：把AI应用拆成四层一横

2.1 接入层：明确“用户在哪儿、怎么进”

画AI应用架构图，我习惯先画接入层。这不是指Web服务器或API网关，而是指用户与AI系统的交互入口：Web聊天窗口、移动App内嵌对话页、企业IM机器人、语音助手、IDE插件……不同入口决定了交互协议、消息格式和响应时效要求。

举个例子，Web聊天窗口对大模型响应时间容忍度较高，3到5秒返回都算正常；但语音助手如果延迟超过1秒，体验就崩了。IDE插件则要面对编辑器内上下文传递的问题——用户选中的代码片段是怎么被带入提示词的，这本身就是接入层需要设计的。

接入层在架构图上通常画在最顶部，标注清楚每个入口的协议类型，比如HTTP/WebSocket、SDK回调、消息平台Webhook。这一层不要堆太多细节，但必须让看的人一眼知道这个系统服务哪些场景。

2.2 编排层：AI应用的“中枢神经”

编排层是整个AI应用架构的关键层，也是图解时最需要花心思的部分。它承载了三个核心职责：会话状态管理、意图路由、工具与模型调用编排。

会话状态管理解决的是“模型记不记得之前聊了什么”的问题。很多人以为把聊天记录拼进提示词就行，实际上生产级应用通常会用独立的会话存储，按会话ID组织历史消息，组装上下文时还要考虑Token窗口、摘要压缩等策略。这部分在架构图上用“会话管理器”组件表达，旁边标注存储介质和上下文组装策略。

意图路由处理的是“用户这句话该交给哪个模块”的问题。一个AI应用往往有多个子能力，比如AI辅助编程工具里，用户说“帮我解释这段代码”和“帮我修这个Bug”，走的是完全不同的流程。意图路由可以用分类模型实现，也可以用规则加模型混合实现。

工具与模型调用编排是AI Agent的核心，后面第三章专门细讲。

2.3 模型层与数据层：底座和记忆

模型层在图里画成底座形状，下面是基础模型服务，上面是模型网关。模型网关的作用容易被忽略，但生产环境里几乎必备：统一管理多个模型供应商的API Key、做请求转发和限流、记录调用日志、灰度切换模型版本。

数据层的核心不只是“数据库”。AI应用的数据层至少包括四类：业务数据（用户信息、订单等）、会话数据（对话历史）、向量数据（知识库embedding后的向量索引）、以及提示词模板和工具定义这类配置数据。这四类数据在图里要分开画，因为存储选型差异很大——业务数据适合关系型数据库，向量数据必须用向量数据库或带向量插件的搜索引擎，会话数据往往用Redis或MongoDB这类高写入性能的存储。

“一横”指的是治理与可观测性，贯穿所有层——调用链追踪、Token消耗统计、模型质量评估、反馈数据回流。这部分不是某个层专属的，画图时用横向的条带或独立的侧边栏来表达。

3. AI应用架构的核心看点：Agent、数据流与并发

3.1 Agent的内部结构怎么画

AI Agent是现在AI应用架构里绕不开的话题。所谓Agent，简单说就是让模型不只是“回答问题”，而是“自主完成任务”——用户说“帮我把这季度销售数据的异常汇总成报告”，Agent要自己决定先查数据、再分析、再生成图表、最后写成报告。

画Agent内部结构时，我建议至少画出三个子模块：规划器、工具调用器、记忆管理器。规划器负责任务拆解，工具调用器负责实际执行外部操作，记忆管理器负责在长流程中保持状态。三者之间用消息总线连接，而不是直接互相调用，这样每个子模块可以独立演进。

画图时有一个容易犯的错误：把Agent画成一个黑盒子，直接一个大方块写上“Agent”，然后四面八方连上工具。这种画法等于没画。至少要把“模型在哪个环节做决策”和“工具在哪个环节被调用”体现出来。规划器内部可以标注提示词策略，工具调用器旁边标注工具清单和调用协议。

3.2 数据流比组件本身更重要

我评审架构图时最看重数据流。组件画得再漂亮，数据流混乱就说明设计没想清楚。

以RAG（检索增强生成）架构为例，一条完整的数据流要画清楚两个过程。一个是离线索引构建：源文档进文档解析器，切片，生成Embedding，写入向量库——这条流通常在架构图下方，用虚线表示批量任务。另一个是在线问答流程：用户提问，生成查询向量，向量库检索，拼装提示词，调大模型生成回答——这条流用实线表示在线请求。

两条流必须明确分开，因为它们的时效性、失败处理方式、资源消耗完全不同。我在实际项目中见过有人把这两条流画成一条，结果排查问题时根本分不清是索引没更新还是检索逻辑出错。

还有一条容易被忽视的数据流是反馈流。用户对回答点“赞”或“踩”，这个信号要回流到评估系统，甚至用来触发提示词模板的调整或微调数据的采集。架构图里哪怕用一条细线标出来，都会让整个系统的闭环意识强很多。

3.3 并发与性能：架构图上怎么体现

很多AI应用刚开始没并发压力，demo跑通就上线，结果一有真实流量就撑不住。画架构图时就得把并发能力设计进去。

关键看三个位置。第一，模型网关处必须有限流和排队机制，否则突发流量会直接打爆模型供应商的配额。第二，耗时任务一定要走异步链路——用户发起一个需要多步Agent处理的任务，前端通过WebSocket或轮询拿结果，后端用消息队列解耦，否则一次请求占用HTTP连接几秒钟，服务很快无响应。第三，向量检索和会话存储这类高频操作要有缓存层，热门问题直接命中缓存，降低模型调用成本。

架构图上建议用不同线型区分同步调用和异步消息：同步调用用实线箭头，异步任务用虚线或双线。这么做看似只是画图规范，实际操作价值很大，线上排查问题时能一眼看出链路瓶颈在哪里。

4. 实操示例：从零画一个AI应用架构图

4.1 需求场景设定

讲理论容易飘，下面用一个贯穿全程的示例来演示怎么实操画图。假设我们要设计一个“AI辅助编程助手”的架构，它有两个核心能力：代码片段解释和代码Bug修复建议。强调一下，这个例子引用了当下很热的“AI编程”场景，很多团队正在做类似功能。

产品形态是一个IDE插件，用户在编辑器里选中代码，右键触发“解释这段代码”或“帮我找找Bug”。要考虑的问题包括：代码上下文怎么传给模型、历史对话怎么存、Bug修复时要不要拉取代码仓库上下文、多人使用时如何控制成本。

有了这个需求，就可以开始从空白页画第一版本架构图了。

4.2 第一版：理清模块与边界

画图第一步是列出所有必须出现的模块。接入端是IDE插件，编程语言和编辑器类型决定了SDK集成方式，这里先统一抽象成“IDE插件客户端”。服务端至少要有一层API网关接收插件请求，一个会话管理器维护每个开发者的对话历史，一个意图识别模块区分“解释”和“修Bug”，一个工具执行模块负责拉取代码文件、执行静态检查，最后是模型网关接大模型。

数据层需要三类存储：会话历史库（存对话记录）、代码上下文缓存（临时存最近打开的代码文件）、以及可选的向量库（如果要做跨项目代码搜索的话，第一版可以暂时不画）。

把这些模块摆在图上之后，先把大框画出来：左侧是客户端，中间是服务端核心，右侧是模型服务，下方是数据存储。箭头先在模块之间标上，暂时不区分类型。

4.3 细化：数据流、接口与边界

模块确定后，开始细化数据流。我通常会把关键流转场景一个个过一遍。

场景一是“解释代码”：插件把选中代码和光标位置发给网关，网关带上会话ID转发给意图识别模块，识别为“解释”意图，从会话管理器取最近上下文，把代码和上下文一起发给模型网关，模型返回解释文本，再通过网关返回给插件。同时，这次交互要写入会话历史。

场景二是“找Bug”：流程比解释复杂一些。插件发来代码，意图识别为“修Bug”，服务端先调工具执行模块——工具执行模块要调用静态检查工具（比如ESLint）跑一遍代码，拿到检查结果，再把代码、检查结果和用户描述一起组装成提示词，发给模型。模型返回建议列表，服务端把结果格式化返回。这里工具调用结果要回填到提示词上下文里，这个细节很多人画图时容易漏掉。

场景确定了，数据模型也就清楚了：会话ID贯穿全程，每个请求都要带上下文ID，工具执行结果要临时存储。这些在架构图里对应为“会话管理器”以及“上下文组装策略”两个组件的内部逻辑，画图时可以在组件旁边用注释框标注。

4.4 完善治理能力与技术选型标注

第一版画完，加上治理能力：模型网关旁标注限流策略和供应商切换逻辑，会话管理器旁标注TTL策略，API网关层加上身份认证和按用户配额控制——比如免费用户每人每天50次请求，这个配额控制要落到架构图上，因为它是成本控制的关键。

技术选型建议在图上用括号注释方式标注，不单独展开：会话历史库用Redis或MongoDB，向量库用开源的Milvus或云厂商的向量检索服务，消息队列用Kafka或轻量级的Redis Stream。工具执行模块如果只是跑静态检查，可以做成同步调用；如果要做复杂的多步分析，则需要引入异步任务队列。对第一版架构来说，画图时用不同线型把这两种情况区分开，基本就及格了。

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

5.1 架构图“画不对”的典型症状

画了几年架构图，也帮别人审过几十张图，总结出几个高频问题，整理成对照表：

排查自己画的图，我有个实用技巧：对着图把“用户从发起请求到拿到最终结果”的完整路径讲给旁边同事听，讲到卡壳或者需要临时编造一个环节的时候，就是图缺东西的地方。

5.2 真实项目里踩过的几个坑

画图本身不复杂，复杂的是画完之后真正落地。我在一个实际项目里遇到过这样的问题：架构图上画了“代码上下文缓存”，用的存储是单机Redis，结果每天只有几十个开发者的场景跑出了内存溢出。排查后发现缓存没有设TTL，每个代码文件缓存永久驻留。这个没问题后来在架构图上是发现不了的，得靠可观测性数据。

另一个坑和Agent工具调用有关。架构图上画了“工具执行模块”可以调用外部代码搜索服务，但生产环境里外部服务偶发超时，Agent没有超时重试机制，任务直接失败，用户端只看到“模型生成异常”。后来在架构图的Agent内部增加了“工具调用超时与重试”标注，并为不同工具设置了差异化超时策略——静态检查这类快速工具给2秒超时，代码搜索这类慢速服务给15秒超时。

还有一个细节值得提：多Agent协作场景下，多个Agent之间通信需要通过一个统一的消息协议，而不是各自直接HTTP调用。我帮一个团队优化过类似架构，他们几个Agent之间全部走REST接口，互相等待，整个链路经常卡死，后来在架构图上引入一个协调Agent统一分发任务，问题解决了。

6. 从单体AI应用到多AI协作架构的演进

6.1 多AI协作：架构图怎么表达

热词里提到“多AI协作”和“AI Agent怎么扛并发”，说明现在大家关注的不只是单Agent应用了。当系统里有多个Agent分工协作时，架构图表达方式要升级。

多Agent协作架构的核心是引入“调度中枢”。用户请求先进调度中枢，中枢负责任务分解、结果聚合、冲突消解。每个Agent在图里是一个相对独立的子图，拥有自己的规划器、记忆和工具集。调度中枢与各Agent之间建议用消息队列连接，任务以事件驱动方式流转，而不是Agent之间互相直连。

画这类架构图时要注意控制图中连接的复杂度。我见过一张8个Agent互相拉线的图，密密麻麻根本没法看。正确的画法是：调度中枢在中间，Agent分布在四周，所有连线都过中枢，即使实际代码里有Agent之间直接通信的优化路径，图上也可以先不画，等具体讨论到那个场景再补充。

6.2 AI应用架构与研发范式的互动

架构图不只是技术方案，它反过来会塑造团队的研发范式。最近常听到“AI Native研发范式”这个说法，本质上是说：研发流程本身要围绕AI应用的特点重新设计——从模型提示词管理、数据集构建、评测回流到灰度发布，都需要和传统软件研发流程融合起来。

架构图上如果有独立的“评测集与自动化测试”模块，提示词改动就必须经过回归测试才能上线；如果架构图上画了“用户反馈回流”链路，产品团队就会把反馈分析当成日常任务；反过来，如果架构图上没有这些组件，嘴上说再多“重视AI质量”都是空的。

所以说，图纸即流程。动手画AI应用架构图的时候，表面上是在画组件和箭头，实际上是在给团队的协作方式定规矩。这也是为什么我越来越觉得，AI应用架构设计这个环节值得多花时间，值得反复推敲。

最后分享一个我个人用得很顺手的收尾技巧：架构图画完初稿之后，放一晚上，第二天用一个完全不了解项目背景的同事当作“读者”，请他从图里反推项目需求。如果他推出来的和他的实际需求差不多，这张图就及格了。如果推不出来，继续迭代。这个习惯帮我发现过很多自己画图时察觉不到的跳跃和省略，比自我检查有效得多。