企业官网建设流程全解析

做AI应用到现在，最让我头疼的往往不是模型效果不够好，而是架构图上画不清一条失败的链路该怎么走。有一次评审AI客服的架构方案，PPT里分层图非常漂亮：接入层、服务层、模型层、数据层，框和框之间的箭头全是笔直的实线。我提了一个很普通的问题——如果大模型输出了一段语气流畅但完全错误的内容，这段错误由谁发现、由谁兜底、怎么回到上游修正？会议室安静了很久。不是大家不懂技术，而是图上根本没有数据回流的路，默认模型永远是对的。

这件事我复盘了很久。AI应用架构设计和传统后端架构最大的差异，不是多了一个"模型"框，而是整个系统的确定性假设被打破了。数据库查询是确定的，函数调用是确定的，大模型生成却是概率性的。承认这一点之后，所有架构决策都不一样了：路由要留降级，推理要留校验，数据要留闭环。这篇文章用图解的方式，把一张AI应用架构图从下到上拆开，讲清楚每一层该放什么、为什么这么放、链路里哪些位置最容易出事，以及从单体Prompt围绕到多Agent协作的演进路径。适合正在画架构图、做技术选型的工程师和架构师，也适合想搞明白"AI项目为什么这么复杂"的产品和技术负责人。

1. 先说清楚一件事：AI应用架构和普通后端架构的根本分歧在哪

1.1 确定性系统与概率系统的架构代差

传统后端系统的架构设计，基础是确定性。参数校验通过就执行，执行就有结果，结果固定可复现。也正因为每个模块的输入输出都可预期，拆解服务边界才容易：用户、订单、支付、库存，彼此之间依赖清晰，架构师主要解决流量、容错、一致性这三件事就够了。

AI应用不一样。一个对话系统、一个知识问答、一个智能客服，核心输出是模型生成的文本和结构化数据，这个结果在概率上可能正确，也可能不正确。模块之间的调用关系不再是"你传数据，我给确定结果"，而是"你传意图，我尽力生成结果，同时附带不确定性风险"。于是架构上出现了传统系统几乎不用考虑的三样东西：校验层、兜底分支、反馈闭环。

落到画图上，我的习惯是：每个AI结果的出口都画一个菱形校验节点，每个校验节点至少引出一条旁路——要么是兜底话术，要么是旧的规则引擎结果，要么是人工交接——而不是直接把模型输出画成实线指向下一个框。很多团队架构评审被挑战，往往就是漏了这条旁路。

1.2 概率性输出带来的三个架构硬约束

第一个约束是延迟不可控。同样一个用户问题，模型推理的耗时不是固定值，上下文越长、生成token越多，时延越高，波动也越大。业务层不能用"同步等着拿结果"的心态来设计，得给异步化、流式输出、并行检索留空间。

第二个约束是成本随调用量线性膨胀。每一次推理都对应GPU或API费用，token就是钱。如果架构层面对上下文不做裁剪、对缓存不做命中率设计，成本会在流量上涨后迅速反噬。我见过不止一个项目，业务跑赢了流量，成本却跑死了利润。

第三个约束是错误模式不可穷举。传统Bug有明确的位置，AI的错误来自模型本身，可能表现为幻觉、格式不符、内容安全、答非所问，靠try/catch解决不了，必须在链路里嵌入校验和回退策略。这三个约束，几乎决定了后面每一层的设计原则。

1.3 架构图最该画出来的是边界与退路

坦白讲，我看过很多AI生成的架构图，框很多，线很均匀，但信息量有限。一张真正有价值的架构图应该回答三个问题：流量入口是谁；主处理链路上每个节点出错后，退路在哪；数据最终怎么回流到数据集和评测里。如果一张图画完，这三个问题有一个答不上来，那图就只是装饰品。

所以后面所有章节，我都围绕这三个问题来讲：分层怎么分，数据流怎么走，阻塞点怎么处理，以及Agent化之后整个图要发生什么变化。

2. 全景图：四层架构从下到上，每一层都放该放的东西

2.1 接入层：多模态入口的归一化与护栏

今天的AI应用入口远不止一个文本框：Web、App、企业微信、呼叫中心、语音、图片，形态各不相同。接入层的职责有两个：协议归一和护栏设置。

协议归一好理解，把不同渠道的请求转换成统一的内部事件结构，避免下游被渠道差异绑架。护栏则容易被忽略：限流、鉴权、输入长度控制、敏感内容过滤，必须在第一道口子上完成。我特别强调输入长度控制。很多线上事故不是模型不行，而是用户把上万字文本直接塞进prompt，推理时延飙升、成本爆炸。接入层加字符数上限、附件大小限制、并发配额，用最笨的手段把风险挡在门外。

画图时，接入层放在最上面，旁边接限流中间件和格式转换器，这两块没有太多花活，但它们是整个架构的门卫。没有护栏的接入层，相当于把门敞开让流量直接冲击模型，出事只是时间问题。

2.2 编排层：最容易被低估的"大脑"

编排层（很多资料里叫Agent层或逻辑层）几乎决定了AI应用聪明不聪明。它负责：理解意图、拆解任务、决定调用哪个模型、判断要不要检索、怎么组织上下文、如何调用外部工具、如何校验模型输出并决定重试还是降级。

为什么它重要？因为大模型本质上是"技能包"，它不知道自己下一步该做什么。编排层把这些技能包按业务目标组织起来。你可以把它想象成机场塔台，模型是跑道上的飞机，飞哪条航线、降落在哪个跑道、天气不好怎么备降，都由塔台调度。很多团队第一版架构里没有独立的编排层，把逻辑写在业务代码里，业务一复杂就成了"面条代码"。

架构图上，编排层是实线箭头最密集的地方。我建议在这个框内单独画出三个组件：上下文管理器（管短期记忆和token配额）、工具调度器（管外部API调用）、校验策略器（管输出审核）。这三个组件，分别对应Agent系统的记忆、工具、自我检查能力。

2.3 模型层：路由、部署与降级策略

模型层是大多数人最关注的，实际踩坑也最多。这一层有两个决策：模型路由和部署方式。

模型路由解决"什么问题用什么模型"。简单任务可以用规则，复杂场景要综合成本、任务类型、历史成功率来路由。比如复杂推理走大参数模型，意图分类这类简单任务走中等模型，没必要所有流量都压在高成本模型上。部署方式则是一道规划题：调用云API还是私有化部署。私有化部署意味着自己管GPU、弹性扩缩容、推理引擎优化，好处是数据可控、长链路成本可控；云API的好处是上线快、不用运维，适合快速验证阶段。

模型层还必须有降级。我实际项目里一定会画一个虚线分支：主模型超时或不可用，自动切到备用模型或本地轻量模型，再不行就退到规则引擎或人工。没有降级的模型层，等于把业务的开关完全交给了第三方。这一点，做模型部署和运维的人体会最深。

2.4 数据层：向量检索、记忆与评测的落脚点

数据层不只是数据库。对AI应用来说，它至少承担四个职能：业务数据存储、向量检索（召回相关知识片段）、历史会话存储（供上下文学习和评测回放）、评测样本集。向量库（pgvector、Milvus、Qdrant等）解决语义召回，围绕它的还有文本切片策略、embedding模型选择、重排逻辑。

这里说一个容易忽略的点：评测数据必须入库。架构演进过程中，没有历史数据，就说不清新方案到底比旧方案好多少。我会在数据层单独划一块"评测与运营数据集"，把线上真实反馈、badcase、人工标注结果沉淀下来。这是后续一切优化和架构演进的燃料。

2.5 实线与虚线的语言：如何在一张图里表达主链路与兜底链路

画架构图要有一套自己的绘图语言，团队内部最好约定统一：实线箭头表示正常流量必走路径，虚线表示降级、旁路或异步回写路径，菱形节点表示条件判断，颜色区分模型服务和业务服务。这样一张图的信息量立刻翻倍。

举个例子，编排层正常路径是"工具调用→模型生成"，但工具超时时，虚线分支指向"直接让模型凭已有上下文回答"；主模型不可用，模型层的虚线分支指向"备用模型或规则引擎"。这套语言不统一，审图时就会为"这条线什么意思"吵半天。画完图，站在图前把请求流程走一遍：每条实线都走通，每条虚线都走到，这张架构图才算有底气。

3. 数据流才是心脏：一次AI请求的完整旅程

3.1 从用户问题到上下文拼装：RAG链路的五个关键跳点

RAG（检索增强生成）是当前AI应用最主流的增强手段。一次典型请求的数据流，我习惯画成五个跳点。

第一步，问题解析。接入层拆解"用户这句话到底想问什么"，可能附带意图分类结果。很多系统在这里做查询改写，把口语问题改写成适合检索的短查询。第二步，向量召回。把查询转成向量，到向量库取TopK相关片段，这个阶段追求召回率，宁多勿缺。第三步，重排。对候选片段用重排模型或规则精排，挑出最相关的片段，过滤低分内容。第四步，上下文拼装。把选出来的片段、历史会话、系统提示词拼成一个prompt，这一步决定模型看到什么，直接影响答案质量。第五步，推理与校验。模型生成回答，过格式校验、关键信息核对，才算完成。

这五个跳点里，前四个很容易在架构图上被简化成一个"RAG"框，但真正出问题的往往在拼装环节——片段冲突、token超限、历史会话污染。所以我画图会把上下文拼装单独画一个节点，旁边标注token占用估算值。这一处细节，救过我好几次。

3.2 流式输出如何改变架构的每一根神经

AI对话系统几乎都要流式输出，token逐个或逐段返回，不然用户等待感太强，体验直接崩。但这会给架构带来一连串变化：网关不能做聚合缓冲等单一响应，要支持协议转发和中间过程透传；编排层不能等完整结果再决策，要能边生成边校验；日志系统也不能只记一个最终响应。

首字时延（TTFB）成为新的核心指标。模型推理之前的检索、拼装、鉴权，都得压缩在几百毫秒内完成，否则用户先看到转圈圈，已经想关页面了。我做架构评审时会重点看：检索和拼装是否并行，路由决策是否在进入模型前完成。这些时序关系，我建议在架构图旁边配一条时间轴，把检索耗时、路由耗时、首字耗时、总耗时标注清楚。这个习惯对定位问题极其有帮助。

3.3 可观测性设计：让一次问题定位在五分钟内完成

AI应用排障比传统系统痛苦得多，一个问题可能是检索错了、prompt拼错了、模型幻觉了，也可能是工具调用失败，肉眼很难看出来。我的方案是全链路trace_id：从接入层开始，为每个请求生成全局ID，贯穿编排、检索、推理、输出校验。日志里记录每个节点的输入摘要和输出摘要，尤其要记录prompt内容，方便事后复现。

还要记录成本指标：一次请求消耗多少token、调用哪个模型、耗时多少。当用户投诉"为什么越来越慢"时，这些数据能快速定位是上下文膨胀、模型路由错误还是检索耗时上升。在架构图上，可观测性不是某一个框的职责，是横向贯穿所有层的横切面，可以用一条横向色带标出链路埋点。这块缺失的架构图，运维时会非常痛苦。

4. 请求链路上的三个阻塞点，以及架构解法

4.1 模型推理时延：并发、排队与首字耗时

多个用户同时请求大模型时，最容易出现的问题是排队和超时。模型推理是算力消耗型操作，并发能力有限，尤其私有化部署，GPU卡数有限，请求一多就排队，P99时延直线上升。

架构层面的解法我有四类。异步化：把不要求实时的任务丢进队列慢慢处理。流式化：让用户先看到首字，缓解等待感。语义缓存：对相同或相似问题直接返回缓存结果，大幅降低真实模型调用量，缓存命中率做好的服务能省40%以上成本。批处理：把多个短请求凑一起推理，提高吞吐，但延迟敏感场景要慎用。

画图上怎么表现？模型层到模型API的连接要加"并发限流"标签，旁边画一个独立队列节点；编排层在调用模型前先查语义缓存，命中则直接绕开模型层。这些都是小改动，但能在高峰期保住系统的命。

4.2 上下文窗口的成本膨胀：短期记忆与长期记忆分层

多轮对话里，每轮把所有历史都塞进prompt，是最常见也最昂贵的做法。token数随轮次线性增长，成本随之上升，上下文接近窗口上限时，模型理解质量反而下降。

解法是把记忆分层。短期记忆：只保留最近两三轮对话，直接拼进prompt，保证连贯性。中期记忆：最近二十轮以内的对话做摘要，用压缩后的摘要替代冗长原文。长期记忆：用户画像、关键偏好、重要历史事实，写进向量库，按需检索。架构把"什么都记得"改成"用的时候才想起来"，成本和效果都更优。

画这部分架构图，我会把记忆模块画在编排层内部，分别对接短期缓存、摘要存储和向量库三条连线。很多Agent跑着跑着变蠢，不是模型变笨了，是上下文被无关历史对话灌满了。记忆分层几乎是必做的一步。

4.3 工具调用的不可控性：超时、熔断与降级回退

Agent调用外部API时，第三方服务的延迟和稳定性完全不可控。我见过不少事故：Agent调用一个外部接口卡死，整个操作转圈到超时，用户以为系统挂了。工具调用的架构设计有三个关键词：超时、熔断、回退。

超时设置要分级别：连接超时、响应超时、整体调用超时，每个级别都有对应处理动作。熔断是连续失败到阈值后，暂时停止调用该工具，避免故障放大。回退是工具不可用时，编排层快速换路：天气查询失败，引导用户看静态页；股票数据失败，退化成纯文本回答。工具调度器旁边至少要有两条虚线分支，每条都指向一个"没有这个工具也能继续"的出口。

4.4 三个阻塞点对照表

这张表可以直接贴在架构图旁边，当作评审时的检查单。每次新服务上线前，对着表问一遍，能省掉不少线上事故。

5. 从单模型到多Agent协作：架构的Agent化改造

5.1 编排方式的变化：从单轮Prompt到计划-执行循环

最初级的AI应用，就是一个Prompt请求过去、一个响应回来，架构上完全没有"计划"概念。到了Agent阶段，系统自己拆任务、自己排计划、自己决定调哪些工具，本质上是把原来写死在代码里的业务流程，交给编排层动态决策。

架构上的变化在于：模型从"被调用方"变成了"参与决策方"。原来用代码写死的if/else分支，变成模型动态生成的步骤序列。这意味着架构需要一个Plan状态存储。我画Agent架构时，会把编排层内部拆成三个组件：Planner负责生成计划，Executor负责按计划执行工具调用或子任务，Memory负责每轮执行后更新状态。这套拆法，对应了Agent工程实践里最常讨论的计划、执行、记忆三角色。

5.2 主从式、流水线、群聊式：多Agent协作的三种常见拓扑

多AI协作在架构上大致有三种拓扑。

主从式最简单：一个主Agent负责意图解析和任务分解，把子任务派发给若干子Agent，子Agent完成后结果收拢回来。适合角色分工明确的场景，比如一个写代码、一个审查代码、一个做测试。流水线式：任务按固定顺序在多个Agent间传递，每个Agent只处理自己负责的阶段，适合内容生产流程，比如资料收集、提纲生成、初稿、校对。群聊式：多个Agent通过共享消息总线互相对话，各自基于收到的消息做下一步动作，灵活但控制难度大。

三种拓扑在架构图上都是"消息总线+多个Agent节点"的变体。我的经验是：团队尽量从主从式起步，不要一上来就群聊式，否则Bug排查会让你崩溃。

5.3 多Agent通信的协议选择与工程底线

Agent之间通信用什么？我见过直接用自然语言来回传的，简单但脆弱，解析不可控。更稳的方式是给每个Agent定义结构化输入输出协议，比如JSON Schema，把意图、参数、环境状态格式化传递，只有真正需要生成内容时才放开自然语言。

工程底线还有几条：必须有父任务ID做链路追踪，否则多Agent间的问题根本没法定位；必须有步骤上限和超时总控，防止Agent陷入自我循环；每次Agent决策都要落日志，让它的"意识流"可回放。这些底线不加，多Agent架构就是一场技术事故预备役。好消息是，基础设施可以直接复用消息队列和任务调度系统，不必重造轮子。

6. 演进路线：先能跑，再能扛，最后能进化

6.1 阶段一：单体Prompt应用，带病快速启动

不要一开始就追求完美架构。先用单体Prompt做的页面和接口把业务跑起来，验证需求成不成立。这个阶段架构图很简单：接入层、调用一个模型、返回结果。它的问题很多，但它能让你快速获得真实用户反馈。

即使这个阶段，也应该保留基础的评测样本记录，把用户疑似badcase单独存下来。这些数据就是后续架构演进的种子，没有它们，后面的优化都靠拍脑袋。

6.2 阶段二：数据层独立，RAG与检索进场

当知识问答、客服类场景出现"模型不知道领域知识"的问题时，RAG就要上场。这个阶段架构图上出现向量库和检索链路，编排层开始承担组织检索结果的职责。最容易犯的错误是把所有知识都塞进向量库，而不做切片和精排优化。

我的建议是：先人工挑200个典型问题和回答做评测集，每改一次配置就回放一次，看真实效果是否有提升，而不是凭感觉调参。这一步很笨，但长远看最省时间。

6.3 阶段三：编排层浮出水面，Agent化落地

当业务要求AI完成多步操作——订个会议、查个天气、写个周报——单体Prompt撑不住了。编排层独立出来，引入Planner、Executor、Memory和工具调度器，架构图上多出虚线降级分支和工具节点。这个阶段的核心是控制：给Agent上缰绳，限步、限时、限预算，确保它不脱缰。

我见过不少团队在这个阶段才回头补接口超时、补失败重试、补日志埋点，导致重构阵痛。如果前两个阶段把数据层和评测集基础打好，Agent化的过程会平滑很多。

6.4 阶段四：多模型路由与反馈闭环，架构真正长出手脚

最后，模型不再只有一个，路由、灰度、成本矩阵上线。同时把线上反馈通过评测回流到数据层，形成"上线、收集badcase、评测、调优、再上线"的闭环。架构图在这一步达到完整：接入层、编排层、模型层、数据层齐备，实线虚线交织，链路埋点贯穿每一层。

这一阶段的价值在于，业务的每一次抱怨，都能变成评测集里的一个样本，转化为下一次迭代的燃料。我用一个表格总结四阶段：

演进过程中我特别想提醒一句：架构是长出来的，不是设计出来的。越复杂的AI应用，越需要靠真实流量和真实badcase倒逼重构。没有反馈闭环的架构图再漂亮，也只是静态装饰。

根据我个人的实操体会，最后再分享一个心得：AI架构图里最难画的永远是那几条虚线。实线代表"我打算这么走"，虚线代表"这条路断了怎么办"。从单体Prompt演进到多Agent协作，真正让系统变可靠的，不是模型换了多强的参数，而是虚线的密度和长度。每画一条新的实线，就多问自己一句：它的虚线备好了吗？这个习惯，比任何架构方法论都值钱。