企业官网建设流程全解析

写AI应用架构，最怕的就是上来就贴一张五颜六色的架构图，然后指着每个方块说“这是接入层、这是模型层”，听众点头如捣蒜，回去自己动手时照样一脸迷茫。我这两年带过不少从零搭建AI产品的团队，也复盘过好几个从PoC走向生产的项目，一个很深的感触是：AI应用的架构设计，难点不在于“画出那张图”，而在于想清楚这张图里每条连线的含义——什么数据在流动、谁在决策、模型在什么情况下会被调用、调用失败了对业务意味着什么。这篇文章不打算再复述那些“ChatGPT套壳”或“LangChain Demo”级别的架构，而是想把我在实际项目中反复迭代过的一套AI应用架构设计思路，用“看图说话”的方式拆开讲一遍。适合正在从“调API做原型”往“做可上线、可维护、可靠AI系统”方向迁移的工程师、技术负责人，也适合需要和研发对齐认知的产品经理。先给个结论：AI应用的架构图，本质上是画一张“人机协作的决策链路图”，LLM（大语言模型）只是这条链路上的一个组件，而不是整个系统的灵魂。

1. 从一张总览图开始：AI应用架构的底座其实一直是“老一套三角色”

我先说一个可能让不少人意外的判断：AI应用架构最底层的东西，和十年前做互联网应用没什么两样——你仍然需要用户端、服务端、数据端这三块。模型API、Agent框架、向量数据库这些新鲜名词的加入，并没有推翻这个底座，它们只是在服务端和用户端之间、在服务端和数据端之间，插入了更多的“智能中间层”而已。

画图的时候，我会习惯性地先画三块大区域，再往里面填充AI特有的模块。

1.1 用户接入层的变与不变

这一层本质上负责解决“用户怎么触达系统”的问题。传统Web应用可能是浏览器页面、小程序、移动App；AI应用则多出了对话式界面、语音入口，以及最容易被忽略的“Agent调用入口”——也就是你的AI服务被另一个程序通过API调用的场景。

我在实际设计时，强烈建议大家把“对话界面”和“程序化调用入口”分开考虑。原因有二：第一，它们的并发模型、限流策略、超时要求完全不同，人聊天可以等5秒，程序调用等待超过2秒就可能导致上游超时；第二，它们对无状态性的要求不同，对话界面通常需要保存会话上下文，而程序化调用最好做到每次请求都自包含，方便水平扩展。画图的时候，这两条路最好从第一层就分叉，后面接的网关、鉴权、流量治理策略也完全不同。

1.2 中间智能层的模块划分

这一层是AI应用架构图的“主战场”，通常包括路由编排、模型网关、Agent执行器、记忆与上下文管理、工具调用协议等模块。很多初学者喜欢把所有逻辑塞进一个巨大的“AI服务”方块里，这是架构图最容易翻车的地方。

我一般会把中间层拆成至少四个独立的方块：

• 编排层（Orchestrator）：负责理解用户请求、拆解任务、选择执行策略，相当于“大脑的决策中枢”。
• 模型接入层（Model Gateway）：统一封装对各类LLM的调用，负责密钥管理、模型路由、重试、降级、计费统计。它是架构图里最不该被省略的方块，因为它决定了你后续换模型、灰度新模型时是否需要推倒重来。
• 工具与插件层（Tool/Plugin Layer）：封装API调用、数据库查询、搜索、代码执行等能力，把外部系统“翻译”成LLM可以理解的工具函数。
• 记忆与状态层（Memory/State Layer）：管理对话历史、短期工作记忆、长期向量记忆、用户画像与偏好。这层在架构图上往往只画一个“向量数据库”就算完，但真实落地时，短期状态的管理比向量检索更麻烦。

1.3 模型与数据支撑层

底座是各类模型服务（闭源API、开源部署、微调模型）和企业内部数据源（业务数据库、文档库、知识库、搜索索引）。很多人把这一层当作“外部依赖”随手一画，但实际上，这一层的就绪程度往往决定了整个AI应用的天花板——模型能力的上限、知识数据的质量、更新频率，都会直接传导到用户感知到的“智能程度”。

所以我的建议是：第一版架构图必须把这五层——接入层、编排层、模型网关层、工具层、数据层——画全，哪怕有些方块先不实现，也要在图上占一个位置。因为架构图本质上是一张“产品能力地图”，它不只要描述现状，还要标出未来半年的扩展方向。

2. 模型服务编排：所有画图的人最容易在这里绕晕，问题的根源是没分清“直连”和“编排链”

模型服务是整个AI应用架构图里的主角，但主角不等于“所有问题都在模型层解决”。我在评审过很多份架构图之后发现，翻车几乎都源于一个共同的错误：把LLM当成一台可以直接访问的“业务核心数据库”，所有链路都直连模型，中间没有任何路由、重试和上下文管理。这就像早年间的单体应用把所有代码塞进一个文件里一样，前期很爽，后期很疼。

2.1 模型层直接对接的三大隐患

第一，厂商锁定。今天你接的模型服务可能是一个对话API，明天你发现业务需要更强的函数调用能力，或者某个开源模型在隐私方面更有优势，你要换供应商。如果每个业务模块都直接调用了模型SDK，替换成本几乎是重写核心代码。

第二，无法灰度。新版本模型可能有推理能力提升，也有概率引入回退。你希望在5%的流量上验证新模型，再慢慢放大比例，没有中间层很难干净利落地做这种动态切流。

第三，成本失控。不同模型的价格差异可以到几十倍，同一个请求用GPT级别的模型回答和用轻量模型回答，成本天差地别。没有统一的计费与配额控制，复盘账单时很容易“爆表”。

所以我在架构图里永远放一个“模型网关”方块。它的职责很简单，但价值巨大：

• 统一鉴权：一次配置，处处调用，密钥永不进入业务代码。
• 统一协议：把OpenAI、Anthropic、开源模型的自建服务等各种协议，转换成内部统一的一个调用接口，业务侧甚至不需要知道今天用得是哪家模型。
• 统一重试与降级：上游模型超时了，网关按策略切换到备用模型，业务请求不会直接报错。
• 统一观测：每次调用都留下日志，记录模型、token消耗、延迟、结果质量，这是后面做评估和成本优化的数据底座。

2.2 三种主流编排模式的取舍：直连、路由、Agent式

架构图上最常见的编排模式有三种，很多新入行的朋友分不清区别，这里用大白话拆一下：

• 单模型直连：用户请求进来，直接发送给一个大模型，拿结果返回。适合简单问答、文案生成、翻译等单轮、确定性高的场景。优点是链路极短，延迟低、调试容易；缺点是完全不涉及“多步处理”，一旦任务里包含“先查点什么、再思考、再回答”，单模型直连就力不从心了。
• 路由分发（Categorized Routing）：先用一个轻量模型或规则对用户请求做分类，再根据分类把请求分发给不同专用模型或不同提示词模板。比如“闲聊”走轻量模型，“专业法律问题”走更强的模型并搭配特定知识库，“要读网页”则加上搜索工具。这种模式在架构图上会呈现为“一个分流器加多条处理链”，比较适合客服、助理类产品，既兼顾体验，又控制成本。
• Agent式编排：把任务拆解成多步，每一步都由LLM决定调用什么工具、如何继续。这是架构图最复杂的形态，也是当前各类“AI Agent应用”的热点。呈现在图上就是一个“规划-执行-观察-再规划”的循环，中间挂着工具集和记忆模块。适合复杂任务执行、多步骤信息检索、自主决策类场景；代价是链路长、状态复杂、token消耗高、可观测性要求高。

我的个人经验是：架构图不要一开始就往Agent式去画。先尝试“路由分发+单模型”，把系统跑通上线，再看哪些用户请求真的需要多步推理，把它们单独拆出来走Agent链路。很多失败的AI项目都是因为首版就上了全自由度的Agent循环，结果连“用户到底要什么”都没搞清楚，就陷在无穷的自动纠错里。

2.3 路由分发怎么画才不容易歪

这里实际操作的经验是：不要试图让路由模型“一次判断全部事情”。画路由的时候给它拆成“需要”和“不需要”两个问题：第一，这个请求需不需要工具/知识增强？第二，如果需要，应该用哪个工具集或知识库？

然后画一个决策表：

• 请求意图为“闲聊”：走轻量模型，不挂工具。
• 请求意图为“问答但知识库可能有关键答案”：走检索增强链路，先查向量库再送模型。
• 请求意图为“完成多步任务”：走Agent链路。

这种拆分比让路由模型输出“我该走哪一个分支”要稳定得多，因为它把不确定的“分类问题”变成了更窄的“是否问题”，模型出错率低很多。

3. 数据与记忆：架构图里画得最少，实际坑最多

我看过太多AI应用架构图，数据层就画一个云厂商的数据库图标，旁边写个“向量库”，然后就没了。结果到了线上，问题全从这里冒出来：召回的内容驴唇不对马嘴、知识更新了一版用户问的还是旧内容、多轮会话中模型忘掉了前面的关键约束。老实讲，数据与记忆这一层，在AI应用架构里决定了“体验下限”——模型能力决定上限，数据和记忆决定下限，这句话值得写在架构图旁边。

3.1 向量检索的架构定位：它是记忆的索引，不是全部的数据库

很多人对向量数据库寄予厚望，觉得把文档切碎丢进去，一个AI知识库就搞定了。实际上，向量检索只是“记忆的粗筛层”。正确的链路通常是这样：

1. 用户问题进来，先做意图理解和关键词抽取。
2. 用这些信息对向量库做召回，拿到一批候选片段。
3. 再用重排序（Rerank）模型或规则，在这些候选中挑出真正相关的内容。
4. 最后把精选内容和用户问题一起拼装成提示词，送进LLM。

架构图上，一定要把“召回”“重排”“拼装”这三步分开画。因为在实际调优时，你会发现返回质量差的问题，八成不是模型不行，而是召回条件太宽或重排策略太弱。分开画，你才能知道该调哪一个方块。

3.2 会话记忆的短期与长期分层

对话类AI应用必须处理记忆，而记忆至少分两层：

• 短期会话记忆：当前对话轮次的上下文，通常放在Redis或内存态里，设置合理的过期时间。短路了，模型会丢上下文；太长，token成本爆炸。
• 长期用户记忆：用户偏好、历史事实、之前对话中主动提供的个人信息，存放在独立的数据库，按用户ID组织。需要的时候，以摘要的形式注入短期上下文。

画图时常见错误是把所有记忆都塞进一个“向量数据库”。短期记忆讲究的是快速读写和准确覆盖，长期记忆讲究的是持久化和跨会话检索，二者对存储引擎的要求不一样，拆开画才能避免后续为性能头疼。

3.3 知识更新的链条：入库、索引、生效

企业级AI应用一定会涉及“知识库更新”的事情。这块有一个大家容易忽视的细节：从文档上传到向量库里的内容真正能被检索到，中间通常需要经过解析、清洗、切分、向量化、写入、索引刷新等多个环节。任何一环出了问题，用户都会觉得“系统没更新”。

架构图上我建议专门画一条“数据接入与更新链路”，而不是只画一个静态的知识库方块。因为这里的延迟和失败率，直接决定了你对用户说“文档已上传成功”这句话是否真的属实。实际做过的朋友应该有体会：上传后立刻检索却什么都搜不到，十有八九就是切分和向量化任务在后台还没跑完，这是排队、异步处理要考虑清楚的事情。

4. Agent与工具调用：架构图上最花哨的部分，也是我踩坑最多的地方

聊到AI应用架构，Agent是绕不开的。很多架构图画到Agent就开始放飞自我：一个循环，左边挂个“代码解释器”，右边挂个“浏览器”，中间拿个数据库，看起来非常智能。但真上线后，Agent经常会陷入一种“看起来在努力，实际在空转”的状态：不断调用工具、不断报错、不断重试，最后给用户一个不知所云的答案。

4.1 工具调用的本质是“协议”，不是“魔法”

在架构设计层面，我们需要想清楚：LLM本身并不会“调用”工具，它只会输出一段结构化的文本——比如“我要调用查机票API，参数是上海到北京、明天”。真正去执行这个调用的是你的代码。所以，Agent架构的核心，是一套“让LLM的意图输出与你的代码动作对齐”的协议。

我在图里会专门画一个“工具注册中心”方块。每个工具都有一份JSON Schema描述，包括：工具能做什么、参数格式是什么、什么时候适合用、什么时候千万别用。Agent循环从注册中心取到这批描述，拼进系统提示词。LLM在决策时，就是从这个“工具的菜单”里挑菜。与其说是智能模型在驾驭工具，不如说是一套精心设计的菜单在引导模型做出可用决策。

画这个图的时候，切记不要画成“Agent直接连接所有系统”。中间必须有“工具注册中心”这一层，否则每新增一个API，你都要修改Agent循环的核心代码，维护成本会直线上升。

4.2 规划-执行-反思循环的工程实现

Agent执行链路的架构图，最经典的画法是一个循环，三个环节：规划（Plan）、执行（Act）、观察（Observe）。但在工程落地上，需要给每个环节加上限流和护栏：

• 规划环节：模型基于当前任务和工具列表，输出一个行动计划。这里要控制的是“规划的粒度”：太粗会跳过必要步骤，太细则token消耗爆炸。我的经验是把规划限制在两到五步内，不要一开始就让模型输出二十步的超长计划，后续执行中根据观察再动态调整。
• 执行环节：代码真正调用工具，等待结果。这里要格外关注“超时机制”。工具调用可能挂住，模型可能返回无效参数，这些都必须有兜底。我见过很多Agent项目挂在“某次工具调用永远没有返回”上。
• 观察环节：把工具返回的结果重新整理成文本，送回模型。这一环容易被忽视，但往往决定成败：工具返回的可能是一个巨大的JSON，直接塞给模型既不经济又容易“迷失重点”。正确做法是在观察环节做摘要或筛选，只把关键信息放进上下文。

4.3 多Agent协作的构图陷阱

顺着热搜词里“多AI协作”的趋势，现在很多架构图开始画“多个Agent互相聊天”的场景。我对此的态度是：可以画，但要想清楚它们之间靠什么协作。是靠共享同一份任务清单？还是靠消息队列传递事件？还是靠一个主Agent统一调度？

我的建议是：多Agent协作的架构图，至少有两种画法可以在视觉上更清楚——第一种是“主从模式”：一个主Agent负责任务拆解和结果汇总，多个子Agent各自负责一个子任务，彼此不直接通信。第二种是“流水线模式”：任务按阶段传递，上一个Agent的输出是下一个Agent的输入，适合文档处理、内容生产这类有明确先后顺序的流程。

最不建议的构图，是把所有Agent画成一团互相连接的网状结构。协作链路一旦是网状，状态复现和问题排查就会变得极其困难，而且任何一个Agent的行为偏差都会像多米诺骨牌一样传导到整个系统。

5. 工程化落地：架构图从纸面到生产的断点清单

架构图画得再漂亮，最终还是要接受生产环境的拷问。我把它称为“断点清单”——每一条都是真实项目里踩过的坑，写出来给大家参考。

5.1 可观测性：你要监视的指标远不止延迟和错误率

传统应用看QPS、P99延迟、错误率，AI应用除此之外，还要看这些：

• Token消耗分布：同一类请求，是哪个链路环节吃掉了最多token？往往是上下文管理出错，历史消息无限堆积。
• 工具调用成功率：Agent每调用一次工具，成功还是失败？失败原因是工具本身不可用，还是模型产生了无效参数？
• 内容质量抽检：答案是否准确、是否有幻觉、是否遵循了系统约束。质量无法完全自动化衡量，但至少要保留对话样本供人工抽检。

架构图上最好给每个核心链路都画上一个“观测点”小标记。不要等到上线后再补，上线后再补意味着你失去了最早期的调优数据。

5.2 优雅降级：模型不可用的时候，你的系统怎么办

很多AI应用架构图里，LLM是唯一的“大脑”。一旦模型服务商抖动或超时，整个应用就瘫痪了。生产级架构必须考虑降级路径。

我在架构图里会额外画一条“降级支线”：当主模型不可用时，先把服务切换到备用模型；备用模型也不可用时，返回已缓存的历史答案；连缓存也没有，就向用户展示“当前服务繁忙，请稍后再试”，而不是让请求在后台无限重试，拖垮整个应用。

画这条支线只花一分钟，但能在真实的故障演练中救你一次。

5.3 评估与回归体系：没有评估集的AI架构是空中楼阁

最后这块特别想多说一句。普通代码有单元测试和集成测试，AI应用也要有“评估集”（Eval Set）。它就是一组精心标注过的“用户问题-预期表现”样本，每次改模型、改提示词、改检索逻辑，都要拿这批样本跑一遍，对比回答质量的变化。

架构图上，我会把评估体系画在最外层，像一个“质量护栏”包围整个系统。它不是一个功能模块，但它是整个架构能够持续迭代的前提。没有评估集，你会陷入“今天优化了一个case，明天弄坏三个case”的窘境，而且毫无察觉。

6. 一张完整的小型产品架构图示例

讲了这么多，最后给一个可以直接拿去改的架构示例。假设我们要做一个“企业内部文档问答与自动化助手”，它的架构图从上到下是这样的：

• 接入层：企业微信/钉钉机器人入口，还有一个用于其他系统集成的OpenAPI入口。
• 网关层：鉴权、限流、请求上下文解析。
• 编排层：路由判断。简单闲聊走轻量模型；知识类问题走RAG链路；涉及跨系统操作的任务走Agent链路。
• RAG链路：召回（向量检索+关键词检索）、重排、上下文拼装。
• Agent链路：工具注册中心（连接企业Wiki系统，CRM系统，工单系统）、规划-执行-观察循环、任务状态存储。
• 模型网关：统一封装主模型、备用模型、速答模型的路由，记录token用量。
• 数据层：向量库、业务数据库、会话存储、用户长期记忆库。
• 质量护栏：评估集、日志平台、人工抽检工具。

这个架构的好处是，每一层都能独立扩缩容，每一层的失败都有相对明确的兜底策略。如果未来要接入语音助手，只需要在接入层加一个语音转写模块；如果要支持更复杂的业务自动化，也只需要在工具注册中心注册新工具。

画图的顺序建议是：先用一个晚上在白板上把“用户请求从哪里进来，到哪里结束”这条主线画出来，再填充支线和降级路径。别一上来就画得很满，留白是给未来的故障准备的。

最后分享一个我自己的体会：好的AI应用架构图，不是说上面用了多新的模型、多智能的Agent编排，而是“当你半夜被电话叫醒处理故障时，能凭这张图在五分钟内定位到是哪个环节出了问题”。画图不是写文档，它是逼迫你把自己的系统想清楚的一种方式。每次画完一张架构图，我都会发现至少两三个之前完全没有想清楚的细节，这大概就是画图这项“老本事”在AI时代仍然有用的原因。