1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起很多人第一次接触大模型应用开发时都会有一种“怎么天天出新东西”的眩晕感。今天流行提示词工程明天流行RAG后天又冒出个Agent、Function Calling、MCP、工作流编排再往后还有多模态、长上下文、记忆系统、思维链、反思循环……名字一个比一个唬人教程一篇比一篇长但真正动手做的时候你会发现一个尴尬的事实大部分所谓的新花样拆到根子上无非是在解决两个问题——输入什么以及输出怎么处理。我做了几年AI应用落地从最早拿API写个问答机器人到后来做知识库、做自动化流程、做多步推理的智能体踩过的坑不算少。回头看真正让我从“追热点追得心累”变成“看什么新框架都能快速上手”的转折点就是我把大模型应用拆成了一个三层架构来理解。这个架构不是什么官方标准是我自己在项目里反复验证后总结出来的一套心智模型但它极其好用。这篇文章就是把这套三层架构彻底拆开讲清楚。不管你是刚入门想搞明白这些概念之间的关系还是已经做了一段时间但总觉得知识是散的这篇内容都值得你花时间看完。我会用大量类比、实操细节和踩坑经验让你看完之后再看任何AI新框架都能一眼看穿它到底在哪一层做文章。1.2 三层架构的全景图先把结论摆出来。我理解的大模型应用三层架构是这样的第一层模型层Model Layer—— 就是那个大模型本身负责“理解输入、生成输出”。你用的是哪个模型、什么参数、什么能力边界都属于这一层。第二层输入层Input Layer—— 所有在模型看到输入之前发生的事情。包括提示词怎么写、上下文怎么拼、知识怎么检索、工具怎么描述、历史怎么压缩统统算这一层。第三层输出层Output Layer—— 模型吐出token之后发生的所有事情。包括解析、校验、格式化、调用工具、多步循环、结果渲染、错误重试都归这一层。你可能会问那Agent、RAG、工作流这些热门概念放哪答案是——它们不是独立的一层而是横跨输入层和输出层的组合模式。RAG主要在输入层做文章把检索到的知识塞进上下文Agent主要在输出层做文章解析模型的工具调用意图并执行工作流则是把输入层和输出层串起来的多步编排。这个视角一旦建立你会发现市面上大部分“新概念”都能被归类。Function Calling是输出层的结构化解析MCP是输入层和输出层的工具协议标准化思维链是输入层的提示技巧加上输出层的多步展开记忆系统是输入层的历史管理加上输出层的写入决策。没有例外。1.3 为什么这个拆法比“追框架”更有效我见过太多人学AI应用开发的方式是看到一个热门框架跟着教程跑一遍demo跑通了觉得自己会了换个场景又不会了。原因很简单——他学的是框架的API不是问题的本质。框架会过时API会变但“输入什么、输出怎么处理”这两个问题永远不会变。用三层架构来理解你学的不再是“LangChain怎么用”“LlamaIndex怎么配”而是“我现在的输入够不够模型理解”“我的输出解析够不够健壮”。前者是记忆后者是能力。记忆会遗忘能力会迁移。而且这个拆法还有一个实际好处排查问题的时候定位极快。模型回答不对你先问自己——是输入层没给够信息还是输出层解析错了还是模型层本身能力不够三个问题一过方向基本就清楚了。不用像无头苍蝇一样到处改代码。2. 第一层模型层——能力边界决定一切2.1 模型层到底负责什么模型层是整个系统的“大脑”但它比很多人想象的要“单纯”。它做的事情只有一件给定一段输入token序列预测下一个token的概率分布然后采样输出。就这么简单。它不负责检索、不负责记忆、不负责调用工具、不负责格式化输出。所有这些“看起来像模型在做”的事情其实都是输入层和输出层在配合。理解这一点非常关键。很多人会抱怨“模型怎么记不住之前的对话”其实模型本身是无状态的它每次看到的只是你这次传给它的完整上下文。所谓“记忆”是输入层每次把历史对话拼进去的结果。模型没有记忆是输入层在帮它“回忆”。同样模型也不会“主动”调用工具。它只是在输出层被引导着生成了一段符合工具调用格式的文本然后输出层解析这段文本并执行。模型本身不知道工具的存在它只是在“续写”你给它的输入。2.2 模型选型的核心考量既然是模型层就绕不开选型。我一般从四个维度来评估维度关键问题实际影响能力上限复杂推理、代码、多语言表现如何决定输入层能偷多少懒上下文窗口能塞多少token决定输入层的拼接策略输出稳定性格式遵循、指令遵循是否可靠决定输出层解析的复杂度成本与延迟每百万token多少钱、首token多快决定整体架构的经济性这四个维度里输出稳定性是最容易被低估的。我踩过一个大坑早期用某个模型做结构化输出提示词里写清楚了JSON格式大部分时候没问题但偶尔会多输出一段解释文字导致解析失败。后来换了一个指令遵循更强的模型同样的提示词解析成功率从85%直接拉到99%以上。输出层代码一行没改整体稳定性天翻地覆。所以选型的时候不要只看“跑分”要拿你自己的真实任务去测。特别是输出格式的稳定性一定要用几十上百条真实输入压测一遍看失败率。这个数据比任何榜单都靠谱。2.3 模型层不是越强越好新手容易有一个误区既然模型是大脑那是不是越强越好答案是——看情况。模型越强通常越贵、越慢而且很多时候你根本用不到它的全部能力。举个例子。如果你只是做一个意图分类任务把用户输入分成“咨询、投诉、查询”三类用一个中等模型甚至小模型就够了准确率可能只比顶级模型低一两个百分点但成本和延迟可能只有十分之一。这时候把预算花在模型层不如花在输入层——把分类的类别定义写清楚、给几个示例效果提升比换模型明显得多。我的经验法则是先用中等模型跑通全流程找到瓶颈在哪一层再决定要不要升级模型。如果瓶颈在输入层信息不够换模型没用如果瓶颈在输出层解析不稳换模型可能有用但不如优化解析逻辑只有当输入输出都优化到位了模型能力才成为真正的瓶颈。2.4 模型层的参数调优实操模型层能调的参数其实不多但每个都有讲究。我拿最常见的几个来说温度Temperature控制输出的随机性。做事实性问答、结构化输出温度调到0到0.3做创意写作、头脑风暴可以到0.7到1.0。我见过有人做客服机器人温度设0.9结果同一个问题每次回答都不一样用户投诉“你们机器人是不是有病”。这种场景温度必须低。最大输出长度Max Tokens这个参数很多人不设结果模型啰嗦起来没完。我的习惯是根据任务设一个合理上限比如摘要任务设500分类任务设50。设太小会截断设太大会浪费。有个技巧先不设上限跑一批看输出长度的分布取95分位数作为上限。Top-p和温度配合使用一般调一个就行。我通常固定Top-p为1只调温度减少变量。这些参数没有“最优值”只有“适合你任务的值”。建议做一个简单的参数扫描固定其他变量只调一个跑20条测试用例人工评估效果。花不了多少时间但能让你对模型行为有直觉。3. 第二层输入层——决定模型能看到什么3.1 输入层的核心职责输入层是整个架构里最被低估、但实际影响最大的一层。它的核心职责只有一个在模型生成之前把所有它需要的信息以它能理解的形式塞进上下文窗口。听起来简单做起来全是细节。信息塞少了模型答不对塞多了模型被干扰格式不对模型理解偏顺序不对模型抓不住重点。我做过统计在我经手的项目里超过60%的效果问题最终都归因到输入层而不是模型能力。输入层要做的事情包括但不限于系统提示词设计、用户输入预处理、历史对话管理、知识检索与拼接、工具描述注入、少样本示例选择、上下文压缩与摘要。每一项都有讲究。3.2 提示词工程只是输入层的一部分很多人把提示词工程等同于输入层的全部这是个误解。提示词工程主要解决的是“怎么把指令说清楚”但输入层还要解决“把什么信息放进来”和“怎么组织这些信息”。我习惯把输入层的内容分成四块来管理指令块Instruction告诉模型要做什么、怎么做、有什么约束。这部分相对稳定通常就是系统提示词。知识块Knowledge模型需要参考的事实信息。可能是检索来的文档片段可能是数据库查询结果可能是用户上传的文件内容。历史块History之前的对话轮次。需要决定保留几轮、怎么压缩、什么时候摘要。示例块Examples少样本示例帮模型理解输出格式和任务边界。这四块的顺序、比例、格式都会影响效果。我的默认顺序是指令 → 示例 → 知识 → 历史 → 当前输入。但这个顺序不是固定的要根据任务调整。比如做多轮对话历史可能要紧挨着当前输入做知识问答知识块要放在显眼位置。3.3 上下文窗口的分配策略上下文窗口是输入层最硬的约束。假设模型支持128K token你不能真的塞满128K因为输出也要占空间而且太长的上下文会导致“中间遗忘”——模型对上下文中间部分的信息注意力下降。我的分配策略是这样的先预留输出空间比如4K剩下的按比例分。指令块通常1K到2K够了示例块看情况1K到4K知识块是弹性最大的历史块要设上限。具体操作上我会给每一块设一个token预算超了就压缩。知识块超了就减少检索条数或截断文档历史块超了就把早期对话做摘要。这个预算不是拍脑袋定的要跑测试看效果。我一般会做几组对比知识块给2K、4K、8K看效果和成本的平衡点在哪。有个实用技巧用tokenizer先算一遍各块的实际token数别靠字数估算。中英文token比例差异很大估算容易翻车。大部分模型都有对应的tokenizer库几行代码就能算。3.4 检索增强RAG在输入层的实现细节RAG是输入层最典型的应用模式。它的核心思想是模型不知道的知识我检索出来塞给它。但RAG做得好不好差距巨大。我见过很多RAG项目效果差问题往往出在几个地方切块策略太粗暴。按固定字数切把一句话切成两半检索出来语义不完整。我的做法是按语义切块比如按段落、按标题层级再配合重叠窗口。切块大小也要试256、512、1024都跑一遍看效果。检索只用了向量。纯向量检索对关键词匹配不敏感用户问“XX型号的参数”向量可能召回一堆语义相似但型号不对的内容。我通常用混合检索向量加关键词BM25再加重排序。这套组合下来召回质量提升明显。检索结果直接拼接。检索出来的片段直接塞进上下文没有去重、没有排序、没有标注来源。模型看到一堆重复信息反而困惑。我的做法是去重后按相关性排序每条前面加个编号提示词里告诉模型“参考以下编号内容回答”。忽略了“检索不到”的情况。用户问的问题知识库里没有检索出来一堆不相关的模型硬着头皮编。我的做法是设一个相关性阈值低于阈值就不塞知识块提示词里加一句“如果参考资料不相关请如实说不知道”。3.5 历史对话管理的实操技巧多轮对话是输入层的另一个难点。模型无状态每次都要把历史拼进去。但历史不能无限拼会超窗口也会稀释当前问题的注意力。我的历史管理策略分三档最近N轮完整保留。N一般取3到5保证近期上下文完整。更早的对话做摘要。用一个便宜的模型把早期对话压缩成一段摘要放在历史块开头。关键信息抽取。从历史里抽取实体、偏好、已确认的事实以结构化形式保留比如“用户偏好中文回答已确认订单号XXX”。这三档配合使用既控制了token又保住了关键信息。实测下来比单纯截断最近N轮效果好很多特别是长对话场景。有个坑要注意摘要本身也可能丢信息。我一般会在摘要后面保留最近几轮的原文形成“摘要近期原文”的结构。另外摘要的生成也要用提示词约束明确告诉它“保留事实、数字、用户偏好去掉寒暄”。4. 第三层输出层——决定模型吐出来的东西怎么用4.1 输出层的核心职责模型吐出token之后事情才做了一半。输出层要负责解析模型输出、校验合法性、格式化、执行动作、处理异常、决定是否继续循环。这一层最容易被新手忽略因为demo里模型输出直接打印出来就完事了。但真实项目里模型输出是要被程序消费的。你要从里面提取结构化数据、要判断是否调用工具、要处理格式错误、要在多步任务里决定下一步。这些全是输出层的活。我有个观点输出层的健壮性决定了一个AI应用能不能上生产。demo可以容忍模型偶尔抽风生产不行。输出层的核心任务就是把模型的不确定性“兜住”。4.2 结构化输出的解析与校验结构化输出是最常见的需求。你让模型输出JSON然后程序解析。但模型不是每次都给合法JSON可能多一段解释、可能少个括号、可能用了单引号。我的处理流程是这样的提示词层面约束。明确说“只输出JSON不要任何其他文字”并给一个示例。解析层面容错。用宽松的解析器能处理常见问题。比如先尝试提取第一个{到最后一个}之间的内容再解析。校验层面严格。解析出来后用schema校验字段类型、必填项、取值范围都查一遍。失败层面重试。校验失败就把错误信息拼回提示词让模型重新生成最多重试2到3次。兜底层面降级。重试还失败就走降级逻辑比如返回默认值、转人工、或者用规则解析。这套流程下来结构化输出的成功率能做到99.9%以上。关键是每一步都要有不能省。我见过只做第1步的成功率85%就上线结果线上天天报错。4.3 工具调用Function Calling的输出层实现工具调用是输出层的重头戏。模型本身不执行工具它只是生成一段“我想调用某个工具参数是XXX”的文本。输出层解析这段文本执行真正的工具再把结果拼回输入层进行下一轮。这里的关键是工具描述的格式和调用结果的回传格式。工具描述要清晰工具名、功能说明、参数名、参数类型、是否必填、参数说明。这些信息会作为输入层的一部分注入模型根据这些描述决定调不调用、怎么调。调用结果回传也有讲究。我一般会把结果包装成结构化格式比如{tool: search, status: success, result: ...}再拼回上下文。这样模型能清楚知道工具执行成功了没有、结果是什么。有个坑模型可能编造工具名或参数。输出层解析的时候要校验工具名是否在注册表里、参数是否符合schema。不符合就返回错误信息让模型重试而不是直接执行。我早期没做这个校验结果模型编了个不存在的工具名程序直接崩了。4.4 多步循环与终止条件Agent类应用的核心是输出层的多步循环模型输出 → 解析 → 执行 → 结果回传 → 模型再输出 → ……直到任务完成或达到终止条件。这个循环最容易出问题的地方是终止条件。如果不设好模型可能陷入死循环反复调用同一个工具也可能过早终止任务没完成就停了。我的终止条件一般设这几个模型输出中明确表示完成。比如输出{status: done, answer: ...}。达到最大步数。一般设5到10步防止无限循环。连续N步没有新信息。如果连续两步的工具调用和结果都一样说明卡住了强制终止。超出token预算。整个循环的累计token超过预算终止。这几个条件要同时监控任何一个触发就停。停的时候要给用户一个合理的反馈不能直接报错。4.5 输出格式化的实战经验模型输出最终要展示给用户格式化很重要。但格式化不只是加个markdown还要考虑流式输出。用户等不及模型全部生成完要边生成边显示。流式输出下输出层要处理“半截JSON”“半截markdown”的情况。我的做法是流式阶段只做纯文本展示等生成完了再做结构化解析和渲染。多模态输出。模型可能输出图片链接、表格、代码块。输出层要识别这些内容并正确渲染。我一般会在提示词里约定输出格式比如图片用表格用markdown表格代码用代码块。敏感内容过滤。输出层要过一遍敏感词和合规检查这个不用多说但要注意别过度过滤把正常内容也拦了。我一般用白名单加黑名单结合的方式。引用标注。如果输入层塞了检索知识输出层要把模型回答里的引用标注出来让用户知道哪句话来自哪个来源。这个要在提示词里约定引用格式输出层解析后渲染成可点击的链接。5. 三层架构的联动为什么新花样都逃不出这个框架5.1 RAG、Agent、工作流的架构定位现在回头看那些热门概念定位就清楚了概念主要作用层核心机制RAG输入层检索知识塞进上下文Function Calling输出层解析工具调用意图并执行Agent输入层输出层多步循环每步都涉及输入拼接和输出解析工作流输入层输出层预定义的多步编排每步的输入输出都受控记忆系统输入层输出层输入层读记忆输出层写记忆思维链输入层输出层输入层引导输出层展开多步推理MCP输入层输出层工具描述的标准化协议你看没有一个逃出三层。所谓“新花样”要么是在某一层做优化要么是把两层组合出新模式。理解了这个你再看新框架就能快速判断它到底解决了什么问题、值不值得学。5.2 一个完整案例智能客服系统的三层拆解我拿一个实际做过的智能客服系统来串一遍。需求是用户提问系统检索知识库必要时调用订单查询工具最后给出回答。输入层设计指令块客服角色设定、回答风格、禁止事项。知识块检索到的FAQ片段按相关性排序带编号。历史块最近3轮对话原文加更早对话摘要。工具描述订单查询工具的参数说明。当前输入用户问题。模型层选择中等模型温度0.3最大输出500 token。输出层设计解析模型输出判断是直接回答还是调用工具。如果调用工具校验工具名和参数执行查询结果回传进入下一轮。如果直接回答校验是否引用了知识块编号格式化输出。最多循环3步超时降级转人工。这套系统上线后问题解决率比纯模型回答提升了40%多核心提升就来自输入层的知识检索和输出层的工具调用。模型层反而没怎么动。5.3 常见误区把三层混在一起我见过最常见的架构错误就是把三层混在一起。比如在提示词里写“如果不知道就调用搜索工具”——这是把输出层的决策逻辑塞进了输入层导致模型输出不稳定。在输出层解析的时候重新检索知识——这是把输入层的活干了导致逻辑混乱。模型层选型的时候考虑“它能不能记住历史”——模型层根本不负责记忆这是输入层的活。分层清晰的好处是每一层的问题在每一层解决。输入层的问题不要指望换模型解决输出层的问题不要指望改提示词解决。定位准了解决起来就快。6. 实操中的常见问题与排查技巧6.1 效果问题的三层定位法模型回答不对怎么快速定位我的三步法第一步看输入层。把实际传给模型的完整上下文打印出来人工读一遍。信息够不够格式对不对有没有干扰信息我敢说一半以上的问题在这一步就能发现。第二步看输出层。如果输入没问题看模型原始输出是什么解析后是什么。是不是解析错了是不是格式没约束好是不是工具调用参数错了第三步看模型层。输入输出都没问题那就是模型能力不够。这时候才考虑换模型或调参数。这个顺序不能反。很多人一上来就怀疑模型换了一圈模型发现没用最后才发现是输入层少塞了一段关键信息。6.2 常见问题速查表现象可能原因排查方向模型答非所问输入层指令不清或知识干扰检查提示词和知识块输出格式不稳定输出层解析太严或提示词约束不够加示例、加容错解析多轮对话失忆输入层历史管理有问题检查历史拼接和摘要工具调用失败输出层校验太严或工具描述不清检查工具schema和错误回传响应太慢输入层上下文太长或模型太大压缩上下文、换小模型成本太高输入层塞太多或输出层循环太多优化检索条数、设循环上限6.3 几个我踩过的坑坑一提示词越长越好。早期我写系统提示词恨不得把所有情况都覆盖写了2000多字。结果模型反而抓不住重点效果下降。后来精简到500字以内只保留核心指令和关键约束效果反而好了。提示词不是越长越好是越准越好。坑二检索条数越多越好。做RAG的时候我一开始检索top 10塞进去觉得信息越多越好。结果模型被不相关的内容干扰回答质量下降。后来改成top 3加相关性阈值效果好很多。信息不是越多越好是越相关越好。坑三输出解析越严越好。我一开始用严格的JSON schema校验模型稍微格式不对就报错重试导致延迟很高。后来改成宽松解析加关键字段校验非关键字段容错成功率和延迟都改善了。校验要抓大放小。坑四循环步数越多越好。做Agent的时候我把最大步数设到20觉得给模型足够空间。结果模型经常在无关的步骤上打转浪费token。后来改成8步并且加了“连续无新信息就终止”的条件效率提升明显。循环要有边界。6.4 性能与成本的平衡技巧三层架构里每一层都有成本和性能的权衡。我的经验是输入层是成本大头。上下文越长成本越高。优化输入层的token效率比换模型省钱多了。具体做法压缩历史、精简提示词、控制检索条数、用更高效的格式。输出层是延迟大头。多步循环、重试、工具调用都会增加延迟。优化输出层的逻辑比换更快的模型有效。具体做法减少不必要的重试、并行执行独立工具、流式输出。模型层是能力上限。前两层优化到位了再考虑模型层。换模型之前先问自己输入输出还有没有优化空间7. 把这套框架用起来7.1 新项目的架构设计清单如果你现在要开始一个新项目我建议按这个清单过一遍输入层指令块写清楚了吗有没有示例知识块从哪来检索策略是什么怎么排序去重历史块保留几轮怎么压缩上下文预算怎么分配超了怎么处理模型层选哪个模型为什么温度、最大输出长度设多少输出稳定性测过了吗输出层输出格式是什么怎么解析校验规则是什么失败了怎么重试有没有工具调用怎么校验和执行有没有多步循环终止条件是什么异常怎么兜底这个清单过一遍架构基本就清晰了。7.2 老项目的优化切入点如果你手上已经有一个跑着的项目想优化我建议按这个顺序先看输入层。把实际上下文打印出来人工评估信息质量和格式。这一步往往能发现最大的优化空间。再看输出层。统计解析失败率、重试率、循环步数。这些指标能告诉你输出层的健壮性。最后看模型层。前两层优化完了再评估模型是否成为瓶颈。我做过一个项目什么都没换只是把输入层的检索策略从纯向量改成混合检索输出层的解析加了容错整体效果提升了30%多成本还降了。模型一行没动。7.3 后续可以怎么扩展这套三层框架不是终点是一个起点。你可以在此基础上继续深入输入层深入研究更高效的上下文压缩算法、更精准的检索策略、更智能的历史管理。输出层深入研究更健壮的结构化输出方案、更灵活的工具编排、更智能的循环控制。跨层优化研究输入输出联合优化比如根据输出反馈动态调整输入。但不管怎么深入记住核心所有AI新花样只在“输入什么”和“输出怎么处理”。抓住这两个问题你就抓住了大模型应用开发的命脉。我个人在实际操作中的体会是这套框架最大的价值不是让你多懂几个概念而是让你在面对新东西的时候不慌。你知道它一定在某一层或某两层做文章你只需要问自己它解决了输入的什么问题还是输出的什么问题问完你就懂了。