这几年我接触了不少LLM应用开发项目也见过太多团队卡在同一个位置上API调通了Demo也能聊朋友看完都说“哇塞”可一旦认真做产品立刻开始原地打转——回答胡说八道、上下文一长就失忆、接了知识库还是答非所问。原因多半是只盯着“模型”这一个点忽略了LLM应用开发本质上是一套五层架构在同时运转。这篇整理把这个五层架构拆开讲透模型接入、知识引擎、编排与智能体、记忆与状态、交互与体验每层干什么、怎么选型、有哪些坑顺手把当前爆火的工具箱按层排好小白照着抄也能从零摸到高阶AIGC的门道。不管你是纯新手还是已经写过几个Demo的开发这套框架都能帮你有章法地搭一个能上线的AI应用。1. 先把“五层”想清楚不是分层越多越高级而是每一层都得替你扛事很多初学者拿到LLM第一反应是把所有逻辑都塞进Prompt里。场景稍微复杂一点这个思路就失灵了你又要模型懂业务规则又要它记得数据格式还要它理解用户偏好再把外部工具串起来一个三五百字的Prompt根本装不下。就算勉强装下了调试时改一句都可能牵一发动全身今天加了这条约束明天发现另一个场景反而不对。分层的核心目的是“关注点分离”。每一层只解决一类问题层与层之间通过清晰的接口通信。这样做的直接收益是换模型不用重写业务逻辑文档切分策略变了不用动前端从单机Demo扩展到多服务部署时每一层都能独立升级、独立排障。说白了分层不是为了显得专业而是为了让你明天改东西的时候不用推翻整个项目。我习惯把五层架构定义为这样层级核心职责典型技术/工具第一层 模型接入层模型选型、API调用、路由与降级、成本控制、必要时本地推理各类模型API、Ollama、vLLM、模型网关第二层 知识引擎层文档解析、切分、向量化、检索、重排为模型补充外部知识Chroma、Milvus、Qdrant、RAGFlow第三层 编排与智能体层把模型调用组织成工作流让模型自主规划工具调用LangChain、LlamaIndex、Dify、Coze第四层 记忆与状态层多轮上下文、长期记忆、状态管理解决模型“失忆”问题Redis、向量记忆库、Langfuse第五层 交互与体验层Prompt设计、流式输出、引用展示、人在回路等用户侧交互SSE、前端框架、Prompt工程这套划分放在任何技术栈里都成立。关键不是“五层”这个数字有什么魔力而是让每个项目里最容易被忽略的问题——知识从哪来、状态怎么记、工具怎么调、用户怎么感知——都有明确的归属。这决定了后面的所有选型都应该围绕“哪一层需要加强”展开而不是“哪个工具最火就上哪个”。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_size500, chunk_overlap100, ) docs text_splitter.split_documents(source_docs) embeddings HuggingFaceEmbeddings( model_namebge-m3, # 中文场景可以换更合适的中文语义模型 model_kwargs{trust_remote_code: True}, ) vectorstore Chroma.from_documents(docs, embeddings) results vectorstore.similarity_search_with_score(query, k4)这里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上海、date2025-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 按五层分组的工具总表层级工具/项目定位说明模型接入GPT-4o / Claude / Gemini / Qwen / DeepSeek / GLM主流闭源与开源模型API按任务强弱搭配模型接入Ollama / vLLM本地一键部署 / 高性能推理引擎知识引擎Chroma / Qdrant / Milvus从原型到生产不同量级的向量库知识引擎Unstructured / LlamaParse多格式文档解析PDF、表格、扫描件处理知识引擎RAGFlow / FastGPT生产级RAG平台自带解析、检索、界面编排LangChain / LlamaIndexPython端编排框架灵活度和生态最强编排Dify / Coze可视化平台Workflow和Agent低门槛搭建编排AutoGen / CrewAI / MetaGPT智能体多角色协作框架记忆Redis会话缓存与短期状态存储记忆Langfuse / LangSmith链路追踪、Token成本分析、Prompt版本管理交互Vercel AI SDK / Streamlit / Gradio快速搭建对话界面与AI组件的常用模板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给你的启发复盘下来这个项目能用五层架构跑通并稳定上线最重要的原因不是用了多高级的工具而是每一层都知道自己在解决什么模型层管能力知识层管准确编排层管流程记忆层管连贯交互层管信任。五层各自分工再差的环境也能逐步调优。做完这个项目之后我对五层架构最大的体会是架构不是第一天就设计出来的是随着真实问题一层一层长出来的。刚开始它可能只有两层模型接入加一个傻傻的对话框等用户开始问私有知识你才意识到需要知识引擎等任务复杂起来你才补上编排层。关键是当你发现问题时心里要有这张五层地图知道该往哪个方向长。最后再分享一个小技巧每次准备加一层新能力之前先问自己一句——不加它用户会不会在某个具体场景里明显受挫如果会那就值得加如果只是“别人都有我也想要”就先缓一缓。