企业官网建设流程全解析

1. 为什么人人都在聊“AI应用架构设计”，却没几个人讲清楚

最近这两年，AI相关的项目如雨后春笋，但真正落地到生产环境、能稳定跑上几个月的，反而不多。我身边不少朋友拿着大模型API调通了demo，一上生产就崩：要么延迟扛不住，要么成本失控，要么多Agent协作起来根本不可控。问题出在哪？大多数人是“有模型思维，没有架构思维”。

“AI应用架构设计”这个事儿，说白了就是：当你决定做一个AI应用时，怎么把模型能力、业务逻辑、数据流、外部依赖、成本预算这些要素，组织成一个能稳定运行、可扩展、可维护的系统。它不等同于“调API”，也不等同于“训练模型”，而是夹在两者之间的那层工程化设计。

这篇文章我就以自己的项目实践为基础，把AI应用架构设计的核心逻辑、实操套路、踩坑记录一次讲透。适合正在做AI产品原型、准备上生产的开发者，也适合刚入行想建立全局认知的初学者。你会看到我实际项目中怎么选型、怎么拆模块、怎么控制成本，以及那些文档里不会写的细节。

先说个结论：AI应用架构设计和传统后端架构最大的区别，在于不确定性管理。传统接口返回的是确定结构，你只管处理正常和异常分支；而大模型输出本身就带随机性，你的架构必须把“不确定性”当成头等公民来设计。这个认知不建立，后面全是坑。

2. 架构设计前，先想清楚这四件事

2.1 你的AI应用，到底属于哪种类型

拿到一个AI应用的需求，我第一件事不是画架构图，而是先归类。根据我自己的实践，市面上的AI应用大致能分成四类，每一类的架构侧重点完全不同：

• 对话型应用：比如客服机器人、知识库问答。核心是对话管理、上下文管理、检索增强（RAG）。架构重点在“怎么把知识塞给模型”和“怎么管理多轮上下文”。
• 生成型应用：比如文案生成、图片生成、代码生成。核心是Prompt工程、输出结构化、批量任务调度。架构重点在“怎么稳定拿到符合格式的结果”。
• 决策型应用：比如AI Agent、自动化流程、智能分析。核心是任务拆解、工具调用、状态管理。架构重点在“怎么让模型安全地调用外部工具并完成多步任务”。
• 增强型应用：比如AI辅助编程、AI辅助设计。核心是人机协作、实时响应。架构重点在“怎么在低延迟下提供高质量辅助”。

我做过一个多Agent协作的项目，一开始按对话型应用设计，结果发现根本跑不通——因为Agent之间要传递状态、要共享记忆、要编排执行顺序，这完全是决策型的活儿。后来重构架构，把Agent编排层单独拎出来，才算稳下来。

这个归类特别重要，因为它直接决定你后面怎么选技术栈。比如你是对话型应用，那核心可能就是一个RAG管道加会话管理服务；你是决策型应用，那核心就是Agent编排引擎加工具注册中心。

2.2 先算账再动手：成本估算决定架构形态

这是我最想强调的一点。很多人做AI应用架构，上来就聊技术选型，结果做着做着发现成本爆了。AI应用的成本模型和传统应用完全不同，传统应用是服务器成本，AI应用是Token成本。

我随手算一个例子：假设你要做一个基于RAG的文档问答系统，每天1000个用户，每个用户平均提问10次，每次提问需要输入2000 Token的上下文、输出500 Token的回复。那一天的Token消耗是多少？

• 输入：1000 × 10 × 2000 = 20,000,000 Token
• 输出：1000 × 10 × 500 = 5,000,000 Token

如果用的是中等价位的模型（按输入0.5元/百万Token、输出2元/百万Token算）：

• 输入成本：20 × 0.5 = 10元/天
• 输出成本：5 × 2 = 10元/天
• 每天成本：20元，一个月600元

看起来还行？但注意，这里没有算向量化成本、没有算知识库更新成本、没有算失败重试的额外Token消耗。而且如果用户量翻十倍，成本是线性翻的。更不要说如果你用的是更高规格的模型，成本可能是这个数字的几十倍。

这就是为什么架构设计阶段就要做成本模型。我见过一个团队，用最高规格的模型做每个请求，上线一个月成本比预估高出30倍，最后不得不回滚。架构层面省成本的方式很多：缓存、模型分级、上下文裁剪、批处理——但这些都必须提前设计，后面补是补不上的。

我的建议是：在架构文档里单独开一节“成本模型”，把每种核心场景的Token消耗算清楚，再乘以预估的调用量。这个数字决定你选什么模型、要不要做缓存、要不要做模型路由。

2.3 数据流和状态管理，是AI架构的隐藏难点

传统架构里，数据流是清晰的：请求进来，处理，响应出去。AI应用不一样，尤其是Agent类应用，数据流是多轮、多路径、可能回退的。

我做多Agent协作项目时，最头疼的不是Agent本身的推理能力，而是状态同步。两个Agent协作完成一个任务，Agent A生成了中间结果，Agent B需要基于这个结果继续做——那这个中间结果存在哪里？以什么格式存？如果Agent B失败了重跑，Agent A的结果还在不在？

这个问题不解决，架构就是空中楼阁。我当时采用的方案是把中间状态持久化到Redis里，每个Agent节点执行前先检查状态，执行后更新状态。同时在数据库里记录一条完整的执行轨迹，方便回溯。这个设计很笨，但稳定。

还有一个容易坑的地方：上下文管理。对话型应用里，你不能把整个对话历史都塞给模型，Token成本扛不住，模型也容易“迷失”。必须做上下文窗口管理——哪些内容保留、哪些内容压缩、哪些内容进检索。这块做不好，你的应用对话超过五轮就开始退化。

2.4 选型不是选“最火的”，是选“最匹配你约束条件的”

技术选型成了很多人纠结的地方。今天LangChain火了，明天又出了新框架，后天有人告诉你这些都别用，自己写Prompt就行。

我的立场是：选型评估框架要看五个维度——团队熟悉度、生态成熟度、可调试性、性能开销、锁定风险。五个维度里，团队熟悉度排第一，因为AI应用本身不确定性就高，如果技术栈还不熟，等于双重不确定性叠加。

框架选型上，大厂有自研的Agent框架，普通团队一般从LangChain或LlamaIndex起步。但我实际用过之后的感受是：LangChain抽象层级高，写起来快，但出问题的时候排查链路很长；LlamaIndex对RAG场景更友好；如果你要做的Agent逻辑比较复杂，自定义编排＋轻量框架可能比大而全的框架更可控。

我现在的做法是：RAG场景用LlamaIndex，Agent编排自己写注册中心和状态管理，Prompt管理单独做一个配置中心。这个组合不一定适合所有人，但对我而言可调试性最好。架构设计没有银弹，只有约束条件下的最优解。

3. 核心架构拆解：从零搭建一个可落地的AI应用

3.1 整体分层：把AI应用当成一个“有大脑的微服务系统”

我习惯把AI应用架构分成四层：

• 接入层：负责和用户交互，包括API网关、WebSocket服务、消息队列入口。这一层做鉴权、限流、日志。
• 编排层：AI应用的核心。包括意图识别、任务规划、Agent调度、上下文管理。这一层决定你的应用“聪明不聪明”。
• 模型层：封装各种模型的调用，包括大语言模型、向量模型、多模态模型。这一层做模型路由、重试、降级。
• 数据层：包括向量数据库、结构化数据库、缓存、对象存储。这一层管知识库、状态、历史记录。

这四层划分的核心逻辑是每层只做自己该做的事。我见过很多失败的架构，就是把Prompt逻辑写进业务服务里，把业务逻辑写进模型调用里，最后全糊成一团，想升级模型都找不到改哪里。

分层还有一个好处：每一层都可以独立扩展。接入层扛不住就加实例，模型层延迟高就做缓存，数据层容量不够就扩容。这种架构演进路径最平滑。

3.2 模型层的三个关键设计：路由、重试、降级

模型层是整个架构里最容易被忽视但最影响体验的一层。我总结出三个关键设计：

模型路由：不是所有请求都用同一个模型。我现在的做法是：简单任务走轻量模型，复杂推理走重量级模型，敏感任务走私有化部署模型。路由规则可以用规则引擎，也可以用一个小分类模型。这个设计在成本控制上的贡献最大。

比如我的一个知识库问答系统，简单的“这个文档讲了什么”类问题，直接走轻量模型回答；复杂的“对比这两份合同的差异”类问题，才升级到重量级模型。算下来成本能省40%以上。

重试策略：大模型接口有随机性，有时候同一个Prompt，这次成功下次失败。所以模型层的重试必须做成指数退避——第一次失败等1秒重试，第二次等2秒，第三次等4秒，最多重试三次。超过三次就降级。

这里有个细节：重试的上游要语义幂等。也就是说，如果你让模型执行一个“下单”操作，重试可能造成重复下单。这种场景必须在重试前做状态检查，或者把操作设计成幂等的。

降级方案：任何依赖大模型的应用，都要提前设计“模型挂了怎么办”。我的方案是三级降级：第一级切到备用模型服务商，第二级切到本地小模型，第三级返回缓存过的相似答案。三级都挂了，才向用户报错。这个设计让我好几次躲过了上游服务商故障的坑。

3.3 编排层的核心难点：多Agent协作怎么设计

多Agent协作现在很火，但真正设计好的不多。我做过的多Agent协作架构，核心是三个组件：

任务分解器：大任务进来，先把任务拆成多个子任务。这一步我用的是“先让模型做规划，再用规则校验”的方式——模型输出一个任务清单，规则引擎检查清单里的步骤是否合法，比如有没有缺少必要参数、有没有循环依赖。

调度器：子任务之间可能有依赖关系，调度器负责按依赖关系执行。我的实现是用一个简单的DAG（有向无环图）来管理——先执行无依赖的任务，再执行依赖就绪的任务。每个任务执行完，更新DAG的状态。

共享记忆库：多个Agent之间要共享信息，不能每个Agent都各自维护自己的上下文。我用的方案是设计一个“黑板模式”——所有Agent都把中间结果写到共享存储里，需要信息的Agent从里面取。这个模式虽然简单，但在多Agent协作里非常有效。

说一个实际的坑。我做多Agent协作时，两个Agent会互相等待对方的结果，形成死循环。排查了很久才发现，是因为任务分解器输出的子任务之间存在循环依赖——Agent A的任务依赖Agent B的结果，Agent B的任务又依赖Agent A的结果。解决方案是在DAG构建时做循环检测，发现循环依赖就报错，不让调度器继续跑。

3.4 RAG架构的落地细节：不是连个向量库就完事

RAG（检索增强生成）几乎是知识库问答类应用的标准架构。但很多团队的RAG效果不好，问题往往不在模型，而在检索链路。

一个完整的RAG架构包括五个环节：文档加载、切分、向量化、检索、合成回答。每个环节都有讲究。

文档切分是最容易被低估的环节。切得太小，语义被切断；切得太大，检索命中后塞给模型的Token太多。我的经验是：先按文档结构切，再按大小切。比如先按标题切出章节，如果章节太大再按段落切，而不是一上来就按固定字数切。

检索环节有个进阶技巧叫HyDE（假设性文档嵌入）——先让模型根据问题生成一个假想的答案，再用这个假想答案去检索。这个技巧对于“问题表述比较模糊、但答案指向明确”的场景特别有效。

还有一个坑是相关性阈值。向量检索出来的结果不一定都相关，如果不设阈值，就会把不相关的片段也塞给模型，导致回答质量下降。我的做法是：先跑一遍测试集，统计相似度分数的分布，找一个平衡点做阈值，低于阈值的直接过滤掉。

RAG还有一个容易被忽略的问题：知识库更新。很多团队上线的知识库就再也没更新过。正确的做法是：文档变更时触发增量向量化，而不是全量重建。增量更新要做好指纹比对——只对变化的部分重新切分和向量化。

4. 实操过程实录：一个多Agent协作系统的架构演进

4.1 第一版：所有逻辑写在一起，开发快但跑不稳

我第一版做多Agent协作系统时，几乎没有架构概念。一个服务里写了Prompt调用、Agent调度、状态存储、工具执行，全部耦合在一起。开发确实快，两周就出了第一版。

但问题也很快暴露：每次升级一个Agent的能力，都要动整条链路；排查问题的时候分不清是Prompt问题还是代码问题；最要命的是，Agent执行到一半失败了，状态没有恢复能力，整个任务就得重来。

这版的核心教训是：AI应用开发再快，也不能跳过模块化。尤其是Agent的调度逻辑，必须和模型调用解耦，否则你会被“改了一处、坏了一串”折磨死。

4.2 第二版：模块化重构，把“不确定性”放进单独的一层

第二版我做了全面重构。核心变化是把架构改成了四层模型，同时还引入了一个关键设计——所有模型的输入输出都走统一的“消息协议”。也就是说，不管是哪个Agent，输入输出都是结构化的JSON格式，而不是裸的文本。

这个设计一开始很痛苦，因为每个Agent的输出形态不同，统一格式意味着要写很多解析和适配的逻辑。但后来好处特别明显：首先是可以统一做日志和监控；其次是模型升级时只需要适配新的协议；最重要的是，Agent之间协作有了标准的接口契约。

我还做了一件事：把每类Agent的Prompt独立成配置。Prompt不再散落在代码里，而是放在配置中心，改Prompt不需要发版。这听起来很简单，但在实际项目里非常救命——很多AI应用的故障，最后定位出来就是Prompt被改坏了或者被写死了。

4.3 第三版：引入评估与观测，让架构“可度量”

第二版跑通之后，我发现一个尴尬的问题：系统能跑了，但你说不清它到底好不好。只能靠人工点一点、试一试。这对AI应用来说是不可接受的。

第三版我引入了两个东西：离线评估集和全链路追踪。

离线评估集是我最推荐的AI工程实践。具体做法是：挑选100条典型任务，每条任务标注期望的回答质量分（比如1-5分）。每次改Prompt、换模型、调检索逻辑，都拿这100条任务跑一遍，对比分数变化。这个机制让AI应用的迭代真正有了“回归测试”的概念。

全链路追踪则让我看到了每次请求内部发生了什么——哪个Agent耗时最长、哪次检索没命中、哪个工具调用失败了。有了这些数据，优化才有方向，不然就是瞎调。

5. 实战中的高频问题与排查技巧

5.1 Agent执行死循环，怎么定位和避免

AI应用最容易出现的问题之一就是Agent死循环。我遇到过的场景是：Agent需要调用API获取数据，但API返回格式不对，Agent尝试重新调用，又发现数据不对，反复操作停不下来。

排查思路分两步。第一步看日志——把Agent的每一步操作都记录下来，包括调用的工具、传入的参数、返回的结果。第二步设超时——每个Agent任务必须设置最大步数和最大执行时间，超过就强制中止。

更根本的办法是在架构层面限制Agent的“自由度”：比如规定同一个工具最多连续调用三次，超过就触发人工接管。这个规则写起来很简单，但能拦住90%的死循环问题。

5.2 RAG检索结果太差，是查“召回”还是查“排序”

RAG效果差，很多人的第一反应是调向量相似度算法，但大多数时候问题出在前面。我的排查套路是：

先看“召回”——检索出来的文档是不是相关的。如果召回了不相关的文档，问题在切分或者查询改写；如果召回了相关文档但排在后面的没进候选集，问题在召回数量设得太少。再看“排序”——相关文档是不是排在了不相关文档前面，如果排序错了，问题在重排序策略。

我常用的一种做法是召回后加一个重排序模型——先用向量检索召回20篇候选文档，再用重排序模型（比如bge-reranker）精排选出前5篇给模型。这一步能显著提升RAG回答质量，代价是增加了一点延迟，但这个延迟非常值得。

5.3 模型输出不稳定，有几招缓解

模型输出的随机性是绕不开的问题。我的几个实用招数：

一是设置采样参数。把temperature调低（比如0.1或0.2），输出会稳定很多，代价是创造性下降。需要稳定结构输出的场景，我甚至会用greedy解码。

二是输出结构化约束。要求模型输出JSON格式，并且预先定义好JSON结构。配合输出解析器，即使模型输出有轻微格式问题也能容错解析。

三是回答内容做校验。对于关键字段，设置校验规则——比如格式、范围、必填性。校验不过就重新生成，最多重试两次，超过就报错人工处理。

四是给模型加“确定性提示”。比如要求“必须从给定材料中回答”“必须按照步骤回答”，虽然不能完全消除随机性，但能显著降低出错率。

5.4 成本突然飙升，先查这四个环节

成本失控是AI应用的一个隐形大坑。排查成本问题时，我建议按优先级查四个环节：

第一，上下文长度。这是最大的成本黑洞。检查是否有代码把整个对话历史甚至整个知识库都塞给了模型。第二，重试次数。模型失败后反复重试，每次重试都是钱。应尽快用完重试策略后降级。第三，模型路由。是否有请求走了高规格模型，但其实只需要轻量模型。第四，缓存命中率。同一个问题重复问，是否有做缓存。

我的经验是，把这四个环节逐一排查一遍，十次有九次能找到成本异常的原因。而且这四个环节都是架构设计阶段可以优化的，后面修补成本很高。

6. 给不同阶段团队的三个实操建议

做AI应用架构设计这几年，我根据团队情况总结了三个级别建议。

对于刚起步的团队：不要追求大而全，先把一个端到端的最小闭环跑通。哪怕就是一个服务单模型单知识库，先把业务验证了再说。架构复杂度要跟着业务不确定性走，业务都没验证，架构搞那么复杂没意义。

对于已经有原型、准备上生产的团队：优先补齐三个能力——观测（知道系统在干什么）、评估（知道系统好不好）、降级（知道系统出问题了怎么办）。这三个能力是AI应用生产化的基础设施，缺一个都要出大事。

对于正在做复杂AI应用的团队：把Agent编排层和模型层彻底解耦，同时一定要建立成本监控体系。复杂AI应用的瓶颈通常不是模型能力，而是系统复杂度的管理。解耦和可观测性，是管理复杂度的唯一出路。

我个人还有一个习惯想分享：做AI应用架构设计，一定要留一个“变数账本”——记录哪些内容是确定的、哪些内容可能随时变化。模型会换、Prompt会改、数据会变，但架构的骨架要稳定。我经历过几次“模型升级导致整个系统重构”的惨痛教训，就是早期没守住这个原则。