企业官网建设流程全解析

1. AI五层结构的整体设计观

1.1 为什么AI系统需要分层

先把这个概念说清楚。很多人聊AI体系，一上来就盯模型选型，GPT还是Claude，换了一个又一个，结果系统跑起来还是不稳。我见过太多团队把一个LLM API直接嵌进业务代码里，改提示词全靠找人帮忙，换模型像拆炸弹，加功能就崩溃。这套玩法在小规模demo阶段没问题，但一旦进入生产环境，问题就全暴露了。

我倾向于把现代AI应用拆成五个层次来理解：算力基础设施层、模型层、工具与数据层、Agent编排层、应用与交互层。每一层各管各的事，层与层之间通过标准接口协作。之所以要这么拆，核心原因有三个：

第一，AI技术栈迭代速度极快。今天是ChatGPT，明天是开源模型霸榜，后天是多模态爆发。如果应用层直接和模型绑定，底层一换，上层全崩。分层之后，模型只是一个可替换的组件，接口不变，换模型就像换数据库驱动一样简单。

第二，每一层的技术挑战完全不同。基础设施层解决的是算力和吞吐问题，模型层解决的是智能水平问题，工具层解决的是数据获取与知识注入问题，Agent层解决的是任务规划与执行力问题，应用层解决的是用户体验问题。把这些混在一起讨论，谁也说不清楚瓶颈在哪。

第三，工程协作需要清晰的边界。五层结构让算法工程师、后端工程师、前端工程师各司其职，每一层都有独立的测试策略和迭代节奏。我在实践中见过太多全栈AI工程师，什么都碰，结果每一层都做不透。分层之后，每一层的负责人能把自己的技术栈打磨到极致。

1.2 五层结构的核心定位

这张图值得先记住：算力是地基，模型是大脑，工具是手和眼，Agent是调度中枢，应用是脸面。缺任何一层，整个体系都跑不起来。

算力基础设施层解决的是一切计算和存储问题。没有这一层，模型只能躺在纸面上。模型层决定系统的智能上限，但模型本身不懂你的业务数据，也不懂你的业务流程，它只是一个强大的语言理解和生成引擎。工具与数据层负责把外部世界接入进来，让模型能查知识库、调API、读数据库。Agent编排层负责把复杂的任务拆解成步骤，决定调用哪个模型、哪个工具、以什么顺序执行。应用与交互层就是把前面四层的能力封装成用户能直接使用的产品形态。

这个五层结构不是我的原创，业界很多成熟平台都遵循类似的架构。像Spring AI这类Java生态的重量级框架，本质上是把模型层、工具层、Agent层做了标准化封装，让企业应用能够快速接入AI能力。而像LangChain、LlamaIndex这些Python生态的编排工具，做的也是同一件事——降低各层之间的耦合成本。

理解了这个整体结构，接下来我就逐层拆开讲，每一层怎么选型、怎么搭、怎么避坑。

2. 算力基础设施层：所有智能的地基

2.1 算力与硬件的规划

基础设施层最核心的问题就一个：模型跑在什么地方。这里的选择基本决定了项目的成本和响应速度。

如果你的应用主要依赖云端大模型API，比如直接用GPT、Claude或国内厂商的模型接口，那算力基础设施层的压力小很多，你只需要保证服务器到API的网络质量、做好请求并发控制和缓存。这种情况下，基础设施层的核心管理工作是API Key管理、请求监控、限流和成本核算。很多人忽略后端源站服务器带宽，结果用户量一大，接口直接卡死。

如果你要自己部署开源模型，那算力规划就得认真做。常见的情况是部署7B到14B参数量级别的模型。以7B模型为例，FP16精度下模型权重大约需要14GB显存，再加上KV Cache和运行时开销，一张24GB显存的RTX 4090勉强够跑，但并发能力有限。如果换成70B级别的模型，权重就要140GB以上，必须用多卡并行的方案，至少4张A100或H100。

我这里的经验是：自己部署模型前，先按这个公式估算显存需求——模型权重占用的显存大约是参数量乘以精度字节数。FP16是2字节，INT8是1字节，INT4约0.5字节。7B模型FP16就是14GB，加上约20%的运行时开销，所以单卡部署至少需要17GB可用显存。

预算有限的情况下，可以考虑量化方案。把模型从FP16量化到INT4，7B模型的权重降到约3.5GB，一张消费级显卡就能跑。代价是生成质量会有所下降，不过对于大多数业务场景，这种精度损失几乎感知不到。我实测过用AWQ和GPTQ量化的模型，在代码生成和文本摘要场景下质量下降小于2%。

2.2 推理服务的技术选型

模型选好、显卡就位之后，接下来是推理服务的搭建。这一块千万不能用最原始的方式，直接加载模型平推。

行业内常用的推理加速框架有这么几个：

• vLLM：目前最流行的开源推理框架，核心优势是PagedAttention技术，能够大幅提升吞吐量。实测在相同硬件条件下，比Hugging Face原生Pipeline能提升3到5倍的吞吐。适合高并发场景。
• TensorRT-LLM：英伟达官方出品，对自家显卡的优化做到极致。延迟极低，适合对响应延迟敏感的在线推理服务，但配置复杂，编译时间长。
• Ollama：对个人开发者和中小团队极其友好，一行命令就能把模型跑起来。内部也做了不少量化优化，但大规模并发不如vLLM。

我很推荐在正式项目里用vLLM，配合OpenAI兼容API的方式暴露服务。这样做的好处是，上层代码完全不用感知底层是vLLM还是云端API，接口格式一致，随时可以平滑切换。我记得之前有个项目，一开始用云端API做原型验证，后来为了控制成本切换到自部署的vLLM服务，代码只用改一个base_url配置，业务层完全没动。

关于存储，也别忽视。模型文件动辄几十GB，SSD是必备的。加载模型时，IO瓶颈直接决定冷启动时间。H100这类新卡搭配PCIe 5.0的NVMe SSD，128GB的模型文件加载到显存大概需要2到3分钟，如果机械硬盘，可能要等十几分钟。

3. 模型层：智能的核心引擎

3.1 大模型选型考量

模型层的决策直接决定系统智能水平的天花板。选模型的逻辑不是越强越好，而是合适最好。

闭源商业模型的最大优势是效果稳定、开箱即用、持续迭代。GPT-4系列在复杂推理、代码生成、工具调用方面一直是标杆，Claude系列在长上下文理解和写作质量上表现优异。缺点是成本不可控、数据隐私存在隐患、无法深度定制。调用量大的时候，API费用会非常吓人。

开源模型最大的优势是可控性强、成本可预测（部署后主要是电费）、数据不出内网、可以针对业务数据做微调。现在的开源模型已经非常能打了。Qwen系列、Llama系列、DeepSeek系列，在多个评测集上的表现已经逼近甚至某些维度超越同尺寸的闭源模型。

我建议的选型策略是：先明确需求清单，比如需要多长的上下文、是否需要多模态能力、对延迟的要求是多少、单次调用的成本上限是多少、数据是否能出内网。把这些需求量化为指标，然后做一次候选模型的评测。评测数据一定要用自己业务的真实场景数据，不要只看公开榜单分数。公开榜单很多评测集都有泄漏问题，得分高不代表在你业务里好用。

多模态能力现在越来越重要。早期AI应用大多是纯文本，现在AI视频、AI绘画、AI漫剧这些方向都起来了。如果你的应用涉及图片理解、视频生成或者语音交互，那就需要考虑多模态模型。像GPT-4o可以同时理解图片、音频、视频，开源阵营的Qwen-VL系列也做得不错。我参与过的一个AI短剧项目，脚本生成用文本模型，角色视觉统一性靠图像生成模型，配音靠语音合成模型，每个环节都在模型层独立选型，最后在编排层把它们串起来。

3.2 微调与训练策略

很多人一上来就想微调模型，觉得通用模型不满足业务需求，微调一下就好了。但微调不是万能的，我见过太多团队花了大量时间和算力去微调，效果还不如做好提示词工程。

我的经验是：先用提示词工程解决80%的问题，再考虑RAG解决知识注入的问题，最后才轮到微调。提示词工程成本最低，迭代最快。RAG能解决模型不知道的业务知识问题，比如企业内部的制度文件、产品文档。只有当模型的表现风格和输出格式需要彻底改变时，微调才真正值得做。

微调的常见方案是LoRA。它只训练一小部分低秩矩阵参数，显存占用低、训练速度快。以7B模型为例，一张24GB显卡就可以完成LoRA微调。全参微调就不建议了，没有足够多的专业数据和技术积累，效果不一定比LoRA好，还容易灾难性遗忘。

微调的数据准备是最耗时的一环。我通常的做法是：准备500到1000条高质量的高质量对话样本，覆盖业务场景的典型输入输出。数据质量远重要于数量。1000条精心整理的数据，效果可能好过10000条从日志里捞的脏数据。还有个细节，微调数据里的指令格式必须和推理时完全一致，否则模型会表现得很奇怪。

4. 工具与数据层：让模型拥有外部世界的能力

4.1 RAG与向量数据库实践

模型训练完就固定了，知识截止日期就是训练数据的截止日期。要让模型知道最新的业务信息，RAG（检索增强生成）是目前最主流的技术方案。

RAG的标准流程是这样的：先把业务文档解析成文本块，每块文本通过嵌入模型转成向量，存储到向量数据库里。用户提问时，把问题也转成向量，在向量数据库里做相似度检索，找到最相关的文档片段，然后把这些片段和用户问题一起交给大模型，让模型基于这些上下文生成答案。

这里有几个关键环节直接决定RAG效果的好坏。

文档切分策略。别用固定的字数切，要根据文档结构来。Markdown标题、段落、表格，这些都是天然的切分边界。我踩过很深的坑，一开始图省事按512字符硬切，结果很多句子被拦腰截断，检索出来的片段语义不完整，模型生成答案时经常张冠李戴。后来改成按语义块切分，一个标题下的小节作为一块，检索准确率提升非常明显。

嵌入模型的选择。目前开源的BGE系列、M3E系列、以及专为多语言优化的模型都是不错的选择。嵌入模型的好坏直接影响检索质量，建议用MTEB榜单上的头部模型，并且在自己的业务语料上做小范围验证。

向量数据库的选型。小规模场景（百万级向量以下）用Chroma或FAISS就足够了，轻量好部署。中等规模用Milvus或Qdrant，功能齐全。如果团队已经在用PostgreSQL，那pgvector是最省事的选择，不用引入新的中间件，事务一致性和备份机制都是现成的。选向量数据库不用追新，稳定、团队熟、不引入额外运维负担才是关键。

4.2 工具调用与外部API集成

RAG解决的是静态知识检索，但很多场景需要模型动态调用外部系统，比如查天气、查库存、下订单、读数据库。这就是工具调用（Function Calling）的用武之地。

具体做法是：在调用模型时，以JSON Schema的形式声明可用的工具列表，模型会根据用户意图选择调用哪个工具，并生成调用参数。然后应用层执行这个工具调用，把结果返回给模型，模型再基于工具返回值生成最终回复。

这个机制实际落地时有个很容易踩的坑：工具返回的结果可能非常大，比如数据库查询返回几千行数据，直接塞给模型既浪费token又容易超出上下文窗口。我的做法是，在工具调用层做好结果裁剪和摘要。工具只返回核心字段，复杂数据先用程序做聚合统计，摘要成几百字的文本再交给模型。

我在实际项目中还遇到过工具调用循环失控的问题。模型发现自己拿到的结果不够，就无限循环调用工具，一次对话消耗几十次API调用。解决办法是设置工具调用上限和超时控制，通常是2到3次就截断，强制让模型基于已有信息作答。这个限制在Agent场景尤其重要，后面会详细讲。

5. Agent编排层：从单次对话到复杂任务交付

5.1 AI Agent的设计理念

工具与数据层解决了单次交互的增强问题，Agent编排层则是把多次交互串起来，让AI能独立完成复杂任务。一个完整的Agent需要具备感知、决策、执行、记忆四个能力。

感知是接收用户目标和环境信息。决策是拆解任务、规划步骤。执行是调用工具和模型完成每一步。记忆则是让Agent能记住前几步做了什么，避免重复劳动。

业界常用的Agent设计模式是ReAct，即Reasoning和Acting交替进行。每次循环里，Agent先推断当前应该做什么，然后调用工具执行，观察结果，再推断下一步。这种模式在开放领域任务里效果很好。

规划能力是Agent做得好不好的分水岭。最简单的Agent是单步执行，问一句答一句。进阶的Agent能做任务分解，比如"帮我写一份行业分析报告"，Agent会拆解成查行业数据、整理竞争格局、分析趋势、撰写报告提纲、逐章生成、格式排版等子任务。更高阶的Agent会反思，做完一步检验结果是否合理，不对就回头重做。

多Agent协作是目前比较热门的方向。让多个Agent分工配合，一个做规划，一个执行检索，一个做内容审核，一个负责最终输出。这就像现实中一个团队协作一样。多Agent系统的问题在于协调成本高、token消耗大，一个小团队的业务场景其实用不上，单Agent配合好工具调用就已经能解决大多数问题。

5.2 基于Spring AI的工程化实践

Java技术栈的团队会特别关注Spring AI这个项目。Spring AI的定位是Spring生态的AI应用开发框架，把模型接入、数据嵌入、向量存储、函数调用、Agent模式都做了统一抽象。

用Spring AI的体验是：配置一个模型客户端，大模型的ChatClient接口直接注入到Service层，跟写普通Java代码没有太大区别。框架内部封装了提示词模板、输出解析、RAG管道、结构化输出转换这些通用能力。

我一开始做AI应用时用的是Python栈，但后来发现Java团队用Spring AI做企业级AI应用集成非常丝滑。企业里大量存量系统是Java写的，用Spring AI可以自然地接入Spring Security做权限控制，接入Spring Cloud做服务治理，这些是企业落地AI绕不开的诉求。Python栈在模型实验阶段有优势，Java栈在生产系统集成阶段有优势，两者是互补关系。

还有一点值得说，Spring AI对国产模型和开源模型的支持很完善。通过OpenAI兼容接口，可以接入几乎所有主流模型服务。这意味着模型层做替换时，Java业务代码几乎不需要改动。这是分层架构带来红利的一个典型例子。

5.3 当前主流Agent开发框架与代码生成场景

Python生态的主流选择是LangChain、LlamaIndex和AutoGen。LangChain生态最成熟，文档最全，组件最丰富，缺点是抽象层级多，调试起来费劲。LlamaIndex更专注RAG场景，做知识库类应用很顺手。AutoGen适合做多Agent协作研发。

Agent在实际业务中的典型应用场景非常多。AI编程辅助是一个我参与比较多的领域。现在的AI编程工具已经从"代码补全"进化到"理解整个代码仓库并完成多文件修改"的阶段。像GitHub Copilot、Cursor这些工具，本质上就是在代码的多个层次上应用大模型能力。

另外，AI在工业控制软件编写里也开始有落地化尝试，比如自动生成PLC控制代码。这类场景的特殊之处在于，代码出错代价极高，AI生成的代码必须经过严格的模拟验证才能上线，所以Agent在推理过程中需要更强的自我检查和约束机制。

我建议研发团队从辅助编码开始应用AI。先是代码补全和注释生成，然后尝试代码评审和测试用例生成，最后再上自动化重构和多文件级的功能开发。这个节奏比较稳，每走一步都能看到收益。

6. 应用与交互层：把AI能力变成产品

6.1 流式响应与交互体验

应用层是用户直接接触的那一层，体验好不好，用户一用便知。

LLM推理天生是token逐个生成的，正常文速下生成几百字的回答就要十几秒。如果等模型全部生成完再一次性返回，用户体验极差。现在主流做法是流式输出，模型每生成一个token就立刻通过SSE或WebSocket推送到前端，用户看到的就是一个字一个字蹦出来的效果，等待感大幅降低。

我实现流式输出的经验是，后端要做好背压控制和中断处理。用户会在生成过程中点击停止，这时候要立刻中断推理服务端的生成任务释放显存，否则会拖垮后续请求。流式输出还会带来数据计量的挑战，token数统计、成本分摊都要在流式管道里同步做。

另外一个容易忽略的点是并发管理。单张大卡跑一个模型，并发高了显存就顶不住。生产环境一般会在推理服务层面加请求队列和限流，让推理框架走Continuous Batching。同时配置超时和重试，模型在高峰期偶尔会卡住或超时，系统要有自动降级的机制。

6.2 多模态内容生成类应用的落地

现在AI应用最火的几个方向是AI视频、AI绘画、AI短剧和AI漫剧。这些产品形态本质上都是五层架构的应用层，底层调用的是各种多模态生成模型。

我做AI短剧项目时有个很深的体会：生成质量只是成功的一半，工作流设计才是关键。一个AI短剧的产出要经历脚本创作、分镜规划、角色形象设计、画面生成、配音、剪辑合成、字幕排版等多个环节。把每个环节交给专门的模型和工具，然后用Agent层把它们串起来，才是一条高效的流水线。

画面生成的一致性是这类应用最大的痛点。同一角色在剧集的不同镜头里要长得一样，纯靠文本提示词很难保证。业界目前的解决方案是借助IP-Adapter这类插件做角色一致性控制，或者训练LoRA模型固定角色风格。这些本质上都是在模型层做定制，目的是让应用层的产品体验更连贯。

AI视频生成的节奏也要控制好。生成一秒钟的高质量视频可能要花几十秒甚至几分钟，如果让用户一直盯着进度条，流失率会很高。比较有效的做法是转异步模式，任务提交之后，用户可以先去刷其他内容，生成完成后再推送通知。这也是很多成熟AI视频产品的做法。

6.3 AI原生应用的性能治理

AI应用上线之后，性能治理是长期工作。我先说几个跟监控相关的心得。

日志是必须的。但AI应用的日志和传统应用不同，不能只记请求和响应，还要记录prompt版本、模型参数、调用成本、流式输出时长、token消耗，这样出了问题才能定位是提示词问题、模型问题还是基础设施问题。

性能监控方面，AI应用需要关注的指标很不一样：首token延迟（用户看到第一个字需要多久）、生成速度（每秒多少个token）、请求排队时长、模型推理失败率、上下文命中率（RAG场景）。这些指标我建议做成实时面板，出现问题尽早告警。

成本控制是AI应用运营的另一大主题。大模型API是按token计费的，一次对话成本可能不高，但并发一上去成本就涨得快。我常用的成本控制手段包括：embedding向量做缓存，相同问题直接返回缓存结果；长文档处理做分段摘要，不要每次把全部文档塞给模型；RAG检索结果按相关性阈值过滤，减少送进上下文的无关内容。

7. 跨层调试与问题排查实录

7.1 分层定位问题的思路

AI应用出问题和传统软件出问题的排障思路有本质不同。传统软件多数是确定性Bug，AI应用的错误往往是概率性的、语义性的。我总结了一套分层的排查方法：

出问题先判断是哪一层。用户说"AI回答不对"，可能的原因分布在每一层：提示词写得不好（模型层问题）、知识库里根本查不到相关内容（工具层问题）、检索结果排序不对（数据层问题）、Agent拆解任务时路子跑偏（编排层问题）、前端把流式输出截断了（应用层问题）。

拿到一个具体问题，我习惯从模型层往上排查。先把用户问题直接丢给模型API看原始输出，如果模型输出正常，说明问题出在下面的工具层或编排层。如果模型输出就不对，再考虑是上下文没有注入需要的知识，还是提示词指令模糊。

7.2 高频故障对照表

我整理了这段时间在AI项目里遇到频率很高的问题和对应的解决办法：

这里我再补充一个很多人忽视的问题：prompt版本管理。AI应用的prompt会频繁调整，我今天把温度参数从0.7改到0.3，明天换一个system prompt，如果不用版本管理和A/B测试来验证效果，很容易出现"上次还好好的，这次怎么变蠢了"。我的做法是每个prompt模板都有固定的版本号，线上流量按比例切到不同版本，对比真实用户反馈来决策是否全量发布。

7.3 成本与质量平衡的几个小技巧

最后分享几个成本优化和效果提升的小技巧。

温度参数的微调。很多业务场景不适合太高的随机性。客服问答、合同分析、代码生成，这些场景建议把temperature控制在0.2以下，输出更稳定。头脑风暴、创意文案生成这类发散性任务，可以调高到0.8甚至1.0。

模型分桶策略。别所有请求都用同一个最强的模型。简单的意图识别、关键词提取、格式转换，用一个小模型的成本可能只有大模型的十分之一。先在路由层做请求分级，简单任务走轻量模型，复杂推理才动用大模型，整体成本能降低60%以上。

上下文压缩。上下文越长，token费用越高，响应也越慢。长文档场景建议用MapReduce方式，先分段提取要点，再对要点做二次综合。不要一股脑把所有内容都塞给模型。

用好缓存和批处理。相同或相似的请求可以做缓存，尤其在固定的知识问答场景，命中率可以到40%。非实时场景的批量任务可以错峰执行，优先占用低峰期的空闲算力。

8. 写在最后

这套五层架构，我前前后后在多个项目里验证过。从最开始自己搭的简易问答机器人，到后来给企业做知识库平台，再到AI多模态内容生产管线，每一层都经历过踩坑和重构。现在回头看，当初如果一开始就把层级边界划清楚，很多返工本来可以避免的。

我个人在实操中最深的体会是：不要试图在一个项目里同时推进五层技术的深度优化。基础设施够用就行，模型选型做完评测就定下来，把主要精力放在工具层和Agent层的打磨上，这两层是最能体现业务价值的地方。等跑通了全流程，再回头逐一优化每一层的细节。

还有一个体会是：AI技术演进太快，别跟风。今天火的框架，可能三个月后就没人维护了。架构设计的核心是"稳定接口+可替换组件"，只要每一层的接口稳定，底层组件随便换，系统都能稳定运转。这就是五层结构给项目带来的最大安全感。