LLM应用开发五层架构：从模型接入到交互体验的实战指南

这几年我接触了不少LLM应用开发项目，也见过太多团队卡在同一个位置上：API调通了，Demo也能聊，朋友看完都说“哇塞”，可一旦认真做产品，立刻开始原地打转——回答胡说八道、上下文一长就失忆、接了知识库还是答非所问。原因多半是只盯着“模型”这一个点，忽略了LLM应用开发本质上是一套五层架构在同时运转。这篇整理把这个五层架构拆开讲透：模型接入、知识引擎、编排与智能体、记忆与状态、交互与体验，每层干什么、怎么选型、有哪些坑；顺手把当前爆火的工具箱按层排好，小白照着抄也能从零摸到高阶AIGC的门道。不管你是纯新手，还是已经写过几个Demo的开发，这套框架都能帮你有章法地搭一个能上线的AI应用。

1. 先把“五层”想清楚：不是分层越多越高级，而是每一层都得替你扛事

很多初学者拿到LLM，第一反应是把所有逻辑都塞进Prompt里。场景稍微复杂一点，这个思路就失灵了：你又要模型懂业务规则，又要它记得数据格式，还要它理解用户偏好，再把外部工具串起来，一个三五百字的Prompt根本装不下。就算勉强装下了，调试时改一句都可能牵一发动全身，今天加了这条约束，明天发现另一个场景反而不对。

分层的核心目的是“关注点分离”。每一层只解决一类问题，层与层之间通过清晰的接口通信。这样做的直接收益是：换模型不用重写业务逻辑；文档切分策略变了不用动前端；从单机Demo扩展到多服务部署时，每一层都能独立升级、独立排障。说白了，分层不是为了显得专业，而是为了让你明天改东西的时候不用推翻整个项目。

我习惯把五层架构定义为这样：

这套划分放在任何技术栈里都成立。关键不是“五层”这个数字有什么魔力，而是让每个项目里最容易被忽略的问题——知识从哪来、状态怎么记、工具怎么调、用户怎么感知——都有明确的归属。这决定了后面的所有选型，都应该围绕“哪一层需要加强”展开，而不是“哪个工具最火就上哪个”。

1.1 为什么不是“调API+写Prompt”就够了

说句不好听的，绝大多数翻车现场都是因为把架构压成了两层：一层是模型API，一层是前端页面。中间所有东西都靠一个巨长的Prompt硬撑。这种写法做Demo没问题，但一旦要对接真实数据、多用户并发、私有知识库，立刻窘态百出。

我见过一个项目，前期很顺利，上线后用户频繁反馈“它回答得很有礼貌但内容完全不对”。排查了很久才发现，知识库文档压根没被正确加载，模型全靠自己的常识硬答。这就是典型的第二层缺失。还有项目把用户所有对话历史一股脑拼进Prompt，结果第30轮对话还没聊完token就爆了，这是第四层缺失。这类问题不在少数，因为单靠肉眼很难在一两轮对话里发现，只有用户多轮聊下去才会暴露。

1.2 五层架构的“替换思维”

分层还有一个容易被忽略的好处：每一层都可以被替换，而不影响其他层。今天用的模型，明天可能换成更强的；今天用的向量库，后天也可能因为性能问题要迁移。只要你按层隔离，替换成本就很小。

我实际操作的体会是：先画清楚每层的输入输出接口，再动手写代码。比如知识引擎层对外只暴露“给一段文本，返回相关文档片段”，内部用Chroma还是Milvus，调用方完全不关心。有了这个接口意识，后面换组件就像换轮胎，而不是换整车。很多项目之所以越写越乱，就是因为没有提前定义层与层之间的边界，最后所有模块都在互相引用，牵一发动全身。

2. 第一层｜模型接入与算力底座：没有稳定的模型通道，上层全是空中楼阁

模型接入层的位置在最底下，却决定了整个应用的天花板。这层要回答三个问题：用哪个模型；怎么让调用稳定；怎么让成本可控。很多人觉得这就是“申请个Key调API”，实际远没有这么简单。

2.1 模型怎么选：能力、速度、价格三者不可能同时最好

选模型没有绝对标准，但有取舍框架。闭源模型通常综合能力最强，多模态、复杂推理都占优，适合做质量优先的产品；开源可部署模型胜在数据隐私和成本可控，适合内部系统和隐私敏感场景。

我常用的策略是“核心任务用强模型，日常任务用轻模型”。比如复杂文档分析、代码生成这类任务，交给综合能力靠前的大模型；而意图识别、信息抽取这种结构化程度高的任务，用轻量模型完全够，速度和成本都会好很多。在中文场景下，国内模型的表现已经相当能打，很多业务甚至比通用国际模型更懂本地数据，文档理解、数学推理等专项能力也各有千秋。选型时不要只看榜单，建议先攒一组自己的业务评测题，用真实数据说话。

2.2 稳定性设计：超时、重试、限流、缓存缺一不可

调用LLM API和调用普通接口不一样，它延迟高、响应不稳定、偶尔还会报错。产品级代码里必须有超时控制、重试机制、并发限流和一定程度的缓存。

举个例子，同样一段产品介绍，如果每次都让模型从零生成，既慢又费钱。我在项目中会把“Prompt + 输入文本”的哈希值作为缓存Key，命中直接返回历史结果，命中率常常能到20%以上。对大并发场景来说，这一步就能省下一大笔成本。还有一个容易踩的坑是重试：模型接口在负载高时会返回限流错误，直接重试往往还会继续限流。正确做法是退避重试，第一次失败等1秒，第二次等2秒，最多重试三次；如果业务要求低延迟，超过两次就切备用模型。

2.3 本地模型部署：什么时候才轮到Ollama和vLLM

很多人一提到私有化部署就头大，我的建议是：先搞清楚需求。如果只是自己电脑上体验、跑个小工具，用Ollama这类一键部署工具就够了；如果要做企业级服务，几十路并发、低延迟响应，就得用vLLM这类高性能推理引擎，配合GPU资源做批处理优化。

本地模型真正的价值不是“省钱”，而是数据不出内网。凡是涉及隐私数据、合规要求高的场景，本地部署几乎是唯一选择。为了这个约束，接受比云端模型略弱的能力是值得的。在这层我也想泼一盆冷水：别在项目初期就搞多模型路由、自动降级这种高级功能。先把一个主模型稳定跑出效果，把接口封装好，架构上留一个“模型Provider”的抽象就够了。等真正遇到“某个模型扛不住/太贵”时再扩展路由逻辑，不然就是过度设计。

3. 第二层｜知识引擎：文档进来、向量出去，RAG才是LLM落地的主力

第二层是多数“看起来很能打、一用就露馅”的Demo最常缺的一层。LLM的训练数据有截止时间，也不包含你业务里的私有知识，你想让它回答“公司上季度营收到底是多少”，它只能一本正经地编。RAG的价值，就是先把答案相关的材料检索出来，再让模型基于材料回答。

3.1 RAG全链路：不是“向量库+搜索”这么简单

一个完整的RAG流程是：文档加载 → 格式解析 → 清洗 → 切分 → 嵌入向量 → 存入向量库 → 查询改写 → 检索召回 → 重排 → 注入Prompt。每一步都在影响最终答案质量。

我之前遇到过最典型的翻车：把一份几百页的PDF直接扔给模型，让它“读完之后回答”。结果模型被淹没在噪音里，回答又慢又乱。后来改成先解析成结构化文本，再按段落切分入库，答案质量立刻上了一个台阶。文本切分是最容易被忽视的环节，很多人习惯按固定字数切，比如每500字一刀，结果同一段逻辑被切得稀碎，检索时自然漏掉关键信息。我推荐先用解析工具还原文档层级，再结合段落语义做切分，句子太长就按标点断句，保持每个chunk表达一个完整意思。chunk大小可以从500-800字起步，overlap控制在10%-20%，然后在你自己的数据集上反复调。

落到代码层，核心链路大致是这样：

from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_huggingface import HuggingFaceEmbeddings text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=100, ) docs = text_splitter.split_documents(source_docs) embeddings = HuggingFaceEmbeddings( model_name="bge-m3", # 中文场景可以换更合适的中文语义模型 model_kwargs={"trust_remote_code": True}, ) vectorstore = Chroma.from_documents(docs, embeddings) results = vectorstore.similarity_search_with_score(query, k=4)

这里embedding模型值得单独拿出来说：通用英文模型在中文场景效果会差一截，中文领域建议用专门的中文语义模型。别小看这一层，检索效果不好时，七成问题出在embedding和切分方式上，而不是向量库本身。

3.2 检索增强的进阶：重排与查询改写

单纯按向量相似度召回top-k，质量往往不稳定。用户问“最近营收怎么样”，直接拿这句话去检索，可能搜不到任何带具体数字的文档。这时候可以先把用户问题做一次改写：“最近营收怎么样”改成“近两个季度营收数据、增长率构成”，再拿改写后的查询去检索，召回质量立刻不一样。

重排是另一道保险。先向量检索召回大概50个候选片段，再用重排模型按相关性精排，取前5条注入Prompt。效果通常立竿见影，代价只是多一点延迟和调用成本。对精度敏感的业务，这个环节建议必上。

3.3 知识库工具的选型：从上手快到扛得住大并发

给新手推荐Chroma，零配置、嵌入式使用，做原型最快。Qdrant和Milvus更适合生产环境，支持过滤、混合检索、水平扩展；数据量超过几百万条文档时，这两者的优势会非常明显。如果团队不想从头搭，直接上RAGFlow或FastGPT这类自带RAG编排的平台，一礼拜内就能跑通一个带界面、带知识库的问答系统。

在这层我踩过的最深刻的坑是：把“加向量库”想成了银弹。向量库只是存储和检索工具，它不会替你理解文档。文档本身脏、乱、缺结构，你检索出来的自然也是脏的。先做清洗再谈向量化，这个顺序一定不能乱。

4. 第三层｜编排与智能体：把“一个LLM”变成“一队会干活的小助手”

模型接入层和知识引擎层解决的是“回答得准不准”，编排层解决的是“能不能把事办完”。用户说“帮我分析这份财报并写一封总结邮件发给老板”，你不可能只调一次模型就完成，需要拆成读文件、提炼要点、起草邮件、写入草稿箱等多个步骤，这就是编排要做的事。

4.1 Workflow和Agent不是一回事，别上来就追求“自主智能”

我经常看到新手一开口就要上Agent，想让模型自己决定调用什么工具。这样做往往失控。实际产品里，绝大多数任务用确定性工作流就够：节点固定、流程清晰、每一步都可控可监控。比如退款流程、审批流程、数据报表生成，全走固定工作流。

Agent更适合开放性的任务：用户需求描述不完整，需要模型自己判断“先查什么、再做什么”。一个典型的Agent循环是：接收任务 → 拆解任务 → 调用工具 → 观察结果 → 再决策 → 输出答案。它强大，但不稳定，必须配合护栏来用。我的建议是“能用Workflow解决的，绝对不上Agent”。只有在任务边界模糊、步骤不固定的场景，才引入Agent，而且要给Agent限定可调用的工具范围，不要给它一把万能钥匙。

4.2 Function Calling：工具调用是编排层的地基

编排层最核心的技术机制是Function Calling，也就是让模型输出一个结构化的“工具调用意图”，你的程序再真实执行。比如查航班，你不用教模型具体怎么接API，只需要给它一个工具定义：

{ "name": "search_flight", "description": "查询符合条件的航班信息", "parameters": { "type": "object", "properties": { "from": {"type": "string", "description": "出发城市"}, "to": {"type": "string", "description": "到达城市"}, "date": {"type": "string", "description": "出发日期，格式YYYY-MM-DD"} }, "required": ["from", "to", "date"] } }

模型会返回类似“我要调用search_flight，参数from=北京、to=上海、date=2025-06-01”的结构化结果，你的代码再执行真实查询，并把结果喂回模型。工具描述的清晰程度非常关键，写得越具体，模型调用越准确。很多新手在这一步翻了车：工具描述模棱两可，模型一会儿把参数穿成字符串，一会儿又把date填成“明天”。

4.3 主流编排工具怎么选：框架还是平台

用LangChain这类框架，灵活度最高，适合深度定制和对技术栈有信心的团队；用Dify或Coze这类平台，搭建成本最低，适合快速验证、中小业务、运营同学也能上手。我自己的分工方式是：原型和内部工具用平台，一天能搭完；对外产品和复杂业务用代码框架，好测试、好追踪、好部署。

Python环境里，LangChain生态最全，坑也最多，任何新版本都可能打破旧代码，建议锁版本、多测试。LlamaIndex对知识密集型任务更强，它的索引结构和检索组件更专精。Agent方向则有AutoGen、CrewAI、MetaGPT这些各有侧重的框架，但生产级别都要做很多加固。这块的总结是：别把编排层做成“一堆节点乱连的蜘蛛网”。每个节点尽量小、职责尽量单一，节点之间传结构化的数据而不是一大段文本，后续调试和迭代会轻松非常多。

5. 第四层｜记忆与状态：别让AI每次都像初次见面

LLM本身是无状态的，你发一条请求它就处理一条，前面聊过什么它完全不知道。可用户不管这些，他会自然觉得“你是我身边的助手，应该记得我上一句说过什么”。所以记忆必须由应用自己实现，这就是第四层的价值。

5.1 短期记忆：多轮上下文的管理技巧

最朴素的短期记忆，就是把最近几轮对话拼进Prompt。但拼接要讲策略：把最相关、最新的消息放在靠近结尾的位置，因为模型对输入中后段的内容更敏感；还要给每轮消息标记角色，明确哪些是用户、哪些是助手、哪些是系统指令。

上下文总会越来越长，所以必须有裁剪策略。我常用的三板斧：滑动窗口（只保留最近N轮）、关键信息抽取（把用户提供的重要事实抽出来，以摘要形式保留）、对话压缩（每过几轮就用模型把旧对话总结成一段短摘要）。很多框架内置了这些能力，但你要搞清楚底层用的哪种，免得按钮一开行为诡异。

5.2 长期记忆：向量记忆库与结构化记忆

跨会话的长期记忆，通常不是靠把历史记录全塞进Prompt，而是存起来、按需检索。两类存法很常见：一类是向量记忆，把对话中值得记住的事实写成文本片段存进向量库，新会话里根据当前问题召回；另一类是结构化记忆，比如用户的身份、偏好、权限，放在关系型结构里，所有对话开始前自动加载。

举一个实际例子，我做客服助手时，让系统记住“用户上次反馈的问题编号”“用户所在城市”这类结构化信息。每次会话先查一遍，再带着这些信息去回答，客户体验明显提升。但要注意，长期记忆不是越全越好，存太多无关信息，既浪费token，又会在检索时引入噪音。我给自己定的记忆准入标准是：“这条信息如果不记住，下次对话会不会出问题？”不会，就不记。

5.3 记忆层的成本与可观测性

记忆层还有一个务实作用：控制token成本。如果把记忆设计成“按需加载”，很多场景的成本能显著下降。我习惯统计每次对话的输入token构成，如果历史记录占了80%以上但真正用上的没几条，就该优化记忆策略了。

可观测性放在记忆层聊也特别合适。有了Langfuse、LangSmith这类链路追踪工具，你能看到每一次回答到底用上了哪段记忆、哪份知识库文档，出问题才能定位。对话型应用最容易“断案无门”，带着链路追踪上线，是给自己留的一条后路。

6. 第五层｜交互与体验：Prompt工程只是交互层的冰山一角

到了最上层，很多人觉得“有手就行”：套个聊天窗口，把模型返回的文本显示出来。但真实产品里，同样的模型，交互层设计得好不好，用户体感和业务效果可以差出一大截。

6.1 Prompt工程其实是交互设计的一部分

Prompt当然重要，但它不是藏在代码里的魔法咒语，而是你为模型设定的“对话界面”。系统提示词要明确角色、任务、输出格式、边界条件，但不要塞一堆自相矛盾的要求。把Prompt按模块组织、用版本管理，效果往往比一版流式修改好得多。

以前我做项目时，把系统提示词拆成“角色定义-任务目标-约束规则-输出格式-示例”五段，调试效率提升了很多。改一行约束不用重写全文，而且能针对每个模块做A/B实验。

6.2 流式输出与引用溯源是“高级感”的关键

用户等模型生成几十秒，是极其糟糕的体验。第一行字越快出现，用户耐心就越强。所以产品层必须做流式输出（SSE），让内容一个字一个字蹦出来。这个技术本身不复杂，但它会带来一连串连锁设计：前端要做增量渲染，代码块要实时识别高亮，流中断要能优雅提示。

有知识库的应用，一定要做引用溯源。模型说“公司去年营收增长了30%”，用户能看到这句话来自哪份文档的第几页。这不仅提高可信度，还能在模型胡说八道时迅速暴露问题。这是从Demo走向正式产品的高频分水岭，也是用户愿不愿意长期用你的AI功能的关键。

6.3 人在回路：让用户参与纠错和确认

高阶的交互不止于展示。某些任务要设计人对关键决策进行确认：一键生成邮件草稿之前，先让用户预览；删除类操作，让模型只生成“建议动作”而不是直接执行。这叫做人在回路，它能把模型从“替你做事”变成“配合你做事”，大幅降低出错风险。

交互层还有多模态的想象空间：语音输入、语音播报、图片问答、实时手写标注。每增加一种交互方式，都是在抬高答案触达用户的效率。开局可以小，但交互层的架构最好能支持扩展，别把输入输出写死成纯文本。

7. 爆火工具箱：一张表看清当前主流工具的分工

前面五层每层都点名了一些工具，这节把它们汇总起来，顺便补全成一份可以直接照着抄的工具箱清单。

7.1 按五层分组的工具总表

7.2 小白直接抄作业的最小工具链

如果你是刚入门，我建议不要一上来就把上面表格里的工具全学一遍。最小闭环七件套就够：一个模型API、一个编排平台（Dify，或LangChain二选一）、一个向量库（Chroma）、一个文档解析工具、一套RAG流程、一个前端聊天界面、一套日志追踪。

实际操作路径可以这样：先在Dify里创建知识库，上传几份你熟悉的业务文档，配置好检索参数；再建一个聊天助手，把知识库关联进去；最后把自带界面嵌入你的项目。一个能回答私有知识的应用，半天就能跑通。先跑通，再回来理解内部发生了什么，这个过程比从零学框架快得多。

7.3 进阶组合与选型原则

有了一定基础后，可以把最小闭环拆开，逐步替换成生产级组件：Dify换成自研编排层，Chroma换成Milvus，加上重排环节，接入Langfuse这类可观测体系。组合不是越复杂越好，每加一个工具前，都要问自己：它替哪一层扛了什么事？没有明确答案就不加。

更重要的原则是“工具只是工具，理解分层才是本事”。很多工具在功能上是重叠的，选型不是收集器，不是每一个爆火的库你都必须用。真实项目里，一个组件能同时覆盖知识引擎和记忆层的场景很常见，合理复用远比堆砌更高效。

8. 用五层架构跑通一个“内部知识问答”Demo复盘

最后用一个实际做过的项目复盘来收尾。背景很简单：某团队手里有一堆零散的产品文档、会议纪要和FAQ，想做一个内部知识问答机器人，员工随时可以问“报销流程怎么走”“这个功能在哪配置”。

8.1 分层落地的具体选型

模型接入层用了一个面向国内场景的对话模型API，前期只用一个主模型，路由和降级没做；知识引擎层用开源的RAG方案，文档先统一解析成Markdown，再做清洗和切分，embedding用中文语义模型，向量库先上Chroma；编排层用Dify搭建，因为需求就是“知识检索+问答”两条主线，不需要复杂Agent；记忆层用Dify自带的会话记忆，并设置只保留最近10轮；交互层先复用Dify的页面，后续再自研前端。

这个架构不是最强的，但足够把五层全部跑通。开发周期大约一周，大部分时间花在文档清洗上，而不是写代码。

8.2 上线后的三个问题和对应调整

第一个问题是答非所问。排查后发现，会议纪要里大量口语化内容干扰了检索，清洗时增加了实体归一化，把“上周”“大家”这类模糊表达提前处理掉，效果明显改善。第二个问题是回答没有引用来源，团队不敢直接信任。后来给结果附加了文档溯源字段，前端展示引用卡片，信任度立刻提升。第三个问题是费用比预期高。加了查询缓存和对话摘要压缩后，token开销降了三分之一，效果几乎没变。

8.3 这个Demo给你的启发

复盘下来，这个项目能用五层架构跑通并稳定上线，最重要的原因不是用了多高级的工具，而是每一层都知道自己在解决什么：模型层管能力，知识层管准确，编排层管流程，记忆层管连贯，交互层管信任。五层各自分工，再差的环境也能逐步调优。

做完这个项目之后，我对五层架构最大的体会是：架构不是第一天就设计出来的，是随着真实问题一层一层长出来的。刚开始它可能只有两层，模型接入加一个傻傻的对话框；等用户开始问私有知识，你才意识到需要知识引擎；等任务复杂起来，你才补上编排层。关键是，当你发现问题时，心里要有这张五层地图，知道该往哪个方向长。最后再分享一个小技巧：每次准备加一层新能力之前，先问自己一句——不加它，用户会不会在某个具体场景里明显受挫？如果会，那就值得加；如果只是“别人都有我也想要”，就先缓一缓。