企业官网建设流程全解析

架构图不是画出来的，是推演出来的。这些年我画过不少AI应用架构图，也评审过团队里其他人的设计，一个很深的感触是：很多人把架构图当成了"PPT配图"，画出来好看，但经不起推敲——别人问一句"这个模块挂了怎么办""数据流到这里延时多少""Agent在这步推理失败回不退路"，就答不上来了。

这次借着"图解AI应用架构设计"这个话题，把我自己画图、拆图、用图的完整思路梳理一遍。我会从一张图应该怎么分层讲起，再聊数据流怎么在图上推演，然后重点说Agent形态和传统AI应用在架构上的本质区别，最后复盘几个实际踩过的坑。内容不追求面面俱到，但求每一点都能落到工程实操上。

1. 先搞清楚：AI应用架构和传统应用架构，差在哪

很多从传统后端转来做AI应用的工程师，上手第一件事就是把以前的Spring Cloud那套搬过来——网关、微服务、消息队列、数据库一样不少。不能说完全错，但很容易把最核心的东西给架空了。

1.1 传统架构的确定性 vs AI架构的不确定性

传统应用架构的核心假设是"确定性"：同一个输入，同一个处理流程，必然产生同一个输出。所以架构设计的重心放在状态管理、事务一致性、服务发现、负载均衡这些维度上——因为系统行为是可预期的，复杂度的主要来源是规模和协作。

AI应用架构的核心假设彻底变了：模型本身的输出是概率性的，同一个Prompt问两次，结果可能不一样；同一个文档切出来喂给RAG，Recall的结果可能不同；甚至模型服务本身还有Token限流、上下文窗口溢出、推理超时这些传统架构里根本不存在的故障模式。

这就导致架构设计的重心发生了根本位移：

• 传统架构关注"请求能不能被正确处理"，AI架构还要关注"请求能不能被合理拒绝"
• 传统架构关注"服务高可用"，AI架构还要关注"模型幻觉兜底"
• 传统架构关注"数据一致性"，AI架构还要关注"上下文一致性"
• 传统架构的瓶颈在数据库连接和线程池，AI架构的瓶颈常在Token消耗和推理延迟

这四组差异，直接决定了架构图中的模块划分、连线方式和数据流向。如果不先把这层想明白，后面画的图就是"传统架构换了身AI皮"。

1.2 我画AI架构图的三个前提

在动笔画之前，我习惯先问自己三个问题，答不上来就先不画：

1. 这张图给谁看？给老板看，重点是分层清楚、能讲清业务闭环；给开发看，重点是模块职责、接口边界、数据流向；给自己看，重点是发现设计漏洞。同一套系统，三种画法。

2. 系统的核心不确定性在哪？是模型效果不行（需要人在环反馈），还是上下文管理复杂（需要状态编排），还是外部工具调用不可靠（需要重试和降级）？架构图一定要把"不确定性最集中的地方"画成视觉焦点。

3. 边界画到哪一层？是画到微服务级别，还是画到类/函数级别？架构图永远不是越细越好，画到能支撑当前讨论决策的粒度就停。

这三个前提定了，后面的分层和连线才不会跑偏。

2. 一张可用架构图的基本分层：从应用入口到模型底座

我自己画AI应用架构图，一般自顶向下拆五个层次，每一层聚焦一个核心问题。

2.1 接入与交互层：不只是HTTP接口

这一层是用户或上游系统触达AI能力的入口。很多人以为就是"Nginx + API Gateway"，但在AI应用里没那么简单。

这一层至少要承载四类差异化流量：

实际画图时，这一层要明确标出SSE（Server-Sent Events）的处理路径。很多首次接触大模型应用的团队，会在流式响应上栽跟头——网关层默认缓冲响应，导致前端等了很久才看到第一个Token，交互体验直接废掉。正确做法是网关对AI服务接口关闭缓冲，或者直接用支持流式转发的独立入口。

2.2 编排与业务层：AI应用的"大脑皮层"

这一层是整个架构图最核心的部分，也是AI应用和传统应用拉开差距的地方。它解决的核心问题是"一个用户请求，如何拆解成一次或多次模型调用，以及这些调用之间怎么组织"。

在这一层，我通常画出三个子模块：

任务拆解器。把用户意图拆成可执行的子任务。比如"帮我总结这份合同的风险条款"这个请求，拆解后可能是：调用LLM判断文档类型，调用文档解析服务抽取正文，再调用LLM按风险维度做结构化总结。这个拆解可以是规则驱动（意图分类模型 + 模板映射），也可以是LLM驱动（让模型自己产出子任务列表），架构图上不需要写算法细节，但一定要画出"拆解结果的落点"。

上下文管理器。这是最容易画漏、但实际最重要的一个模块。LLM的上下文窗口是有限的，多轮对话、长文档分析、Agent多步推理都依赖一个统一的上下文管理层来组织：哪些内容进System Prompt、哪些进历史消息、哪些做向量化检索、哪些在超出窗口时被压缩或丢弃。架构图上要把这个模块画成独立的框，和业务逻辑解耦。

服务适配层。不是所有能力都直接调大模型。有些走RAG检索、有些走传统规则引擎、有些走外部API（比如查天气、查数据库），这些异构能力需要一个统一的适配层把"语义化的工具调用"翻译成"具体的技术实现"。画图的时侯，这层的连线和下游依赖最多，也是评审时被问得最密集的区域。

2.3 模型接入层：别让模型供应商绑死你的架构

模型接入层是AI架构里最"动荡"的一层。今天我接的是GPT-4o，明天可能就换成文心一言，后天可能上一个开源模型微调版本。如果架构图上把业务代码和某个具体模型供应商的SDK直接画实线，那基本就等着重构吧。

比较务实的画法是在模型接入层抽象出一层协议转换层：

• 统一Prompt模板管理（同一个任务，不同模型用不同的Prompt模板）
• 统一模型元信息（上下文窗口大小、支持的Tool格式、多模态能力）
• 统一错误码映射（模型限流、内容审核拒绝、超时，转成应用层可理解的异常）
• 统一评估追踪（每条请求用了哪个模型、多少个Token、效果如何——这些数据是后续模型选型的依据）

这层的主要作用，是把"模型能力差异"挡在业务之外。架构图上看起来只是薄薄一层，实际代码量往往不小。

2.4 数据与记忆层：AI应用的地基

这一层画的是所有"喂给模型的内容"和"模型产生的内容"的存储方案。具体包括四类存储：

画图时要注意一件事：很多团队会把向量数据库当成"AI应用的标配"到处用，其实不是。如果业务里没有真正的语义检索需求，只是简单的"根据用户ID查记录"，那用MySQL加个LIKE查询就够了，完全不需要引入向量库。架构图上的每一个存储节点，都应该是被需求逼出来的，不是被概念炫出来的。

2.5 基础层与可观测：支撑所有上层的那条底线

基础层包括模型服务本身的部署形态（托管API还是私有化部署GPU集群），以及底层的计算资源、容器集群、消息队列等。这层在架构图上通常是"地基"的存在，看起来不起眼，但决定了整个系统的成本上限和故障半径。

比基础层更需要单独画一块的，是可观测性。AI应用的可观测比传统应用多两个维度：

1. Token消耗追踪：每个用户、每个会话、每个功能的Token成本一目了然，这是AI应用成本治理的生命线
2. 模型效果追踪：同样的输入在不同的模型版本下的输出对比、用户的最终反馈（点赞/点踩/重试）是否对齐

这两块数据光是看日志是不够的，通常需要单独的数据管道做采集和聚合。我在架构图上习惯把可观测模块画在右侧独立一列，和主数据流分开，避免主线被扯乱。

3. 数据流控：架构图上最容易被看穿的地方

分层是骨架，数据流是血管。一张AI架构图经不经得起推敲，基本看数据流画得清不清楚。

3.1 主数据流：从用户请求到Token返回的完整路径

以最典型的RAG应用为例，主数据流是：

1. 用户请求进入接入层，鉴权、限流，确认用户身份和配额
2. 请求进入编排层，任务拆解器判断"这个问题需要检索知识库"
3. 上下文管理器把用户的原始Query改写成适合检索的形式（这一步叫Query改写，实际工程里很关键，直接决定Recall效果）
4. 改写后的Query向量化，去向量库检索Top-K相关文档片段
5. 检索结果拼进Prompt，连同会话历史一起组装成模型输入
6. 模型服务返回结果，经过答案校验（可选）后流式返回给用户
7. 整个过程产生的Token用量、检索耗时、模型延迟全部落可观测系统

这七步看起来直接，但实际画图的时候，有几个细节经常画错，我后来都会专门核对：

Query改写在架构图上要有明确的位置。很多人直接跳过RAG图里的Query改写这一步，把用户的原始Query直接拿去做向量检索，所以画图时根本没有体现这一步。但真实系统里，用户的原始表述往往口语化、无主语、代词多，直接检索效果很差。架构图上如果漏掉这个环节，说明设计的时候压根没考虑过这个问题——评审时我必抓。

Retrieved上下文和用户历史消息的拼接顺序要画出语义。是历史消息在前还是检索片段在前？两条路径在图上如果只是模糊地汇成一团，说明设计者没想过Prompt模板的细节。

兜底路径必须画。如果向量检索结果为空，或相关度低于阈值，系统是直接告诉用户"没找到"，还是退化成无检索的纯LLM回答？这条路径必须在图上明确画出，否则遇到边界情况，开发会临时拍脑袋，效果无法保证。

3.2 反馈与控制流：不只是"调用模型"这么简单

数据流画完之后，我还会在图上叠一层控制流。控制流解决的是"什么时候可以调模型、什么时候不能调、调了之后怎么处理结果"。

举个具体场景。用户提交了一个"帮我分析这份财报"的请求，控制流的走向是：

• 文档是否上传成功、格式是否支持？——不支持就直接拒绝，不用走模型
• 文档是否需要权限检查？——没权限就返回403，不走模型
• 文档内容是否涉及敏感信息？——命中敏感规则就拦截，不走模型
• 文档是否超过上下文可承载的长度？——需要切片走RAG，还是递归摘要
• 模型输出的分析结果，是否包含虚假的财务数字？——和原始文档做交叉验证
• 结果返回后，用户点了"没用"，这个反馈怎么回流到系统？

这些决策点，都应该以分支或网关的形式体现在架构图里。如果一张AI架构图只有"用户->模型->返回"这条线性路径，没有任何判断分支，那它反映的就不是真实系统，而是演示Demo。

我见过太多团队，架构图看起来"很AI"，但实际跑起来效果不稳定，最后定位原因，就是控制流缺失——该拦截的请求没有拦截，不该调模型的场景调了模型，结果效果差还烧钱。控制流就是AI应用的安全阀和成本阀。

4. Agent形态下的架构演进：从"一问一答"到"多步自主"

传统AI应用和Agent应用的最大差别，用一句话概括就是：前者是单次推理，后者是多轮决策循环。这个区别反映在架构图上，变化是根本性的。

4.1 从线性管道到循环引擎

传统AI应用的架构图是线性的：输入->处理->输出，一步到位。Agent应用的架构图必须画出循环结构：

用户请求 -> 规划器 -> 工具调用 -> 结果观察 -> 更新上下文 -> 再规划 -> ... -> 最终输出

这个循环在图上一定要突出，因为它改变了一切设计假设：

• 超时设计变了：Agent一次完整任务可能是几十次LLM调用，不能按单次请求的5秒超时去卡，要做整体任务超时加单步超时两层
• 上下文管理变了：每一步的观察结果都要拼进历史，上下文窗口可能很快就满了，需要压缩、裁剪、摘要
• 幂等性设计变了：同一个子任务可能因为Agent判断失误被多次执行，架构上要求所有对外部系统的副作用操作（发邮件、写数据库、创建订单）都具备幂等能力
• 成本控制变了：一个Agent任务烧掉的Token可能是普通对话的几十倍，必须在循环入口设置预算开关，超过预算就强制终止

我在画Agent架构图时，习惯把"终止条件"明确画出来。一个没有终止条件的Agent循环，在图上看起来是无限箭头，这样的系统上线就是灾难。

4.2 工具层：Agent的"手和脚"

Agent架构里比传统AI应用多出来的一个重要层次是工具层。工具层是Agent和环境交互的桥梁，可以是内部API、外部第三方服务、代码解释器、数据库查询器。

工具层的架构设计有几个关键点：

工具注册与发现。每个工具需要声明自己的名称、功能描述、参数Schema。Agent通过LLM的函数调用来决定用哪个工具、传什么参数。工具描述写得好不好，直接决定Agent调用的准确率——这块在实际工程里需要反复磨，架构图上体现为"工具注册中心"。

工具调用的沙箱与权限。Agent调工具和你写代码调接口不一样，Agent的入参是模型生成的，可能完全超乎预期。所以工具层必须做参数校验、白名单控制、超时熔断。给Agent用的工具，默认按"不可信输入"处理。我见过一个Agent因为参数异常把生产环境的测试数据清掉的案例，血泪教训。

工具结果的标准化。不同工具返回的数据格式五花八门，有JSON有纯文本有二进制。工具层要把结果统一转成LLM友好的文本格式（或特定结构化格式），这一步不处理好，Agent的"观察"环节就是一团乱麻。

4.3 多Agent协作：画图上容易失控的地方

现在"多AI协作"、"多Agent协作"很热。说实话，单Agent系统架构都没做扎实就上多Agent，大概率是灾难。但如果在架构层面能看清协作模式，多Agent也不是玄学。

多Agent协作在架构上主要画三种拓扑：

• 指挥/汇报模式：一个主Agent负责任务拆解，把子任务分给多个专业Agent执行,结果汇总回主Agent。这种模式控制最简单，主Agent是唯一的决策中心，但主Agent容易成为瓶颈
• 流水线模式：Agent A的输出直接作为Agent B的输入，前一个的结果是后一个的上下文。这种模式链条清晰，但中间任何一步失败都要整条重来，架构上要有断点续跑机制
• 去中心化协商模式：多个Agent共享一个消息总线，自由发布任务和认领任务。这种模式最灵活，但也是最难控制——架构上必须有全局的监控、审计和熔断开关

不管哪种拓扑，多Agent架构图上必须画三样东西：共享上下文存储、全局任务状态中心、冲突仲裁逻辑。这三样少了任何一样，多Agent系统跑几天就会乱成一锅粥。

我自己的实际建议是：能用单Agent+工具解决的问题，绝不上多Agent。多Agent的复杂度和成本是指数级上升的。架构图上的每多一个框，都是未来的一份债务——加框很容易，填坑很难。

5. 图解复盘：几个真实项目中踩过的架构坑

最后这部分，聊几个我实际经历过的架构设计教训。这些问题如果只靠画图推演，往往发现不了，必须结合真实运行数据才能暴露，但一旦暴露，回头改架构图的成本是巨大的。

5.1 坑一：把"检索"画成了"查询"，RAG的架构位置放错了

这个项目是给客户做企业知识库问答。第一版架构图，我们画得很传统：用户请求 -> 文档检索 -> 拼Prompt -> LLM生成 -> 返回。看起来没什么问题，但上线后效果一直不好，用户问的问题经常答非所问。

后来逐层排查，发现卡点不在检索本身，而在检索的前一步。用户的自然语言问句直接拿去向量检索，意图和文档内容之间隔了一道"语义鸿沟"。比如用户问"我们公司的年假政策是什么"，但知识库文档里的原文是"休假管理办法"，直接检索根本匹配不上。

这个问题的根源，就是架构图上漏掉了"Query改写"和"多路检索"两个环节。后面我们重画了这一段的架构，把检索前处理单独画成一个模块，拆成了：意图识别、Query改写、关键词检索+向量检索双通道、结果融合重排。架构调整之后，Recall的效果提升非常明显。

这件事之后我养成了一个习惯：架构图上凡是有"检索"这个动作的，一定先从图上往下追问三层——检索之前有没有预处理？检索之后有没有重排？检索失败了走什么兜底？

5.2 坑二：上下文管理没有独立模块，多轮对话越跑越笨

这个项目是做一个业务辅助问答助手，支持多轮对话。初期架构图里，会话历史直接存在Redis里，每次请求简单拼接最近的N条消息一起送给模型。

一开始用着还行，但对话轮次一多，问题暴露了：用户的问法越来越"笨"——明明是同样的意思，模型好像忘了之前的上下文。排查原因，就是无脑拼接历史消息导致的：

• 无关的历史消息占用了宝贵的上下文窗口
• 关键的上下文（用户刚才提到的某个具体实体）被挤出了窗口
• Model之间的系统指令和用户历史混杂，语义被稀释了

这个项目后期对架构做了一个大手术，把上下文管理从业务代码里抽出来，单独做了一个对话状态管理层，负责：

• 实体记忆：从历史对话里抽取核心实体（客户名、项目名、日期区间），动态注入上下文
• 窗口裁剪：按Token数和重要性双维度裁剪历史，保证关键信息不被挤出
• 摘要压缩：对话超过窗口上限时，前半部分压成摘要保留

这个改动没法在架构图上"加两个框"就完事，它实际上重做了整个编排层的设计。从那以后，我画任何AI应用架构图，都会问一句：上下文管理器在哪？没有独立上下文管理的多轮对话系统，架构图我直接打回。

5.3 坑三：Agent的"手"没有套安全壳，测试阶段报了生产数据

这是一个Agent自动化报表的项目。Agent会自动调用数据查询工具生成周报。测试阶段一切正常，结果灰度放量之后，某一次Agent在规划时把"参数表"和"生产明细表"搞混了，触发了全量数据的聚合查询，直接把数据库的IO打满。

后面复盘，问题就出在工具层的设计：Agent调用数据查询工具时，只有功能验证，没有做资源级的安全控制。如果架构图上把工具层画成一个独立的"安全边界"——所有工具入参过白名单、所有查询任务强制带分区条件、敏感表离线隔离，这次的故障完全能避免。

现在我对Agent类应用有个硬性要求：架构图上必须画出工具层之外的"工具安全网关"。这个网关不参与业务逻辑，专注做三件事：参数合法性校验、副作用行为审批（比如批量删除、全量查询、对外发送消息）、资源配额掐断。Agent的能力越强，这个网关就要画得越重。

5.4 坑四：可观测画成了"日志收集"，Token成本失控无人知

最后一个坑，也是很多团队会踩的：架构图上"可观测"画得很大气，但实际落地就只是一个日志收集管道，ELK一把梭。

我们这个项目问题暴露得很讽刺——是财务那边先发现的：某个客户的上月账单Token消耗异常高，逼近整个平台其他客户的消耗总和。排查之后发现，这个客户的会话里挂着一个高频定时任务，每隔几分钟就自动调一次LLM做监测判断，一个月攒下来烧了几十万Token。而平台的监控面板上，Token成本是看不到的——因为设计时只做了功能日志，没做成本维度的聚合。

架构图中可观测模块的正确画法，应该至少包含三条独立链路：

1. 链路追踪：一次请求从进入网关到模型返回的每一跳耗时
2. 质量监控：模型输出与用户反馈的关联分析，幻觉用例的采样收集
3. 成本监控：Token消耗按用户、按会话、按功能多维聚合，超预算实时告警

三条链路在架构图上看起来都在"可观测"这个框里，但底层的数据管道分别是不同索引、不同聚合逻辑，不能混在一个日志流里糊过去。

这部分的教训是：AI应用的架构图，不能只画"功能流"，还要画出"钱流"和"质量流"。这两个维度，恰恰是AI应用和传统应用在运维层面最大的差异。

画AI应用架构图，说到底是在画一个"不确定性管理系统"的设计方案。模型输出的不确定、工具调用的不确定、上下文边界的动态变化、运行成本随流量非线性膨胀——架构图的每一笔连线，本质上都是在回答一个问题：当不确定性发生时，系统如何优雅地应对。把这些年踩过的坑都画进图里，图自然就有价值了。