大模型三层架构：基座层、输入层与输出层的工程实践

做 AI 应用开发这一年多，我最大的感受是：不同产品背后的模型能力越来越同质化，真正让一个 AI 功能显得"聪明""会干活""有新花样"的地方，往往不在模型本身，而在它输入了什么、输出又是怎么被处理的。今天就把我一直在用的一套"大模型三层架构"拆解分享出来：基座层、输入层、输出层。理解了这三层，你会看清市面上绝大多数 AI 新玩法的真实机理——它们没有改变模型的底层能力，只是在"输入什么 / 输出怎么处理"这两个环节上变出了花。

这套拆解适合所有做 AI 产品、搞智能体、搭知识库问答系统的开发者，也适合想弄明白"AI 到底是怎么变聪明"的非技术朋友。如果你正纠结于"要不要微调大模型""RAG 和 Agent 是什么关系""为什么同一个模型换个提示词效果天差地别"，这篇文章应该能帮你把答案一口气捋顺。

1. 先给"三层架构"一个准确定义：哪三层在干活，哪一层在变

1.1 我为什么要把大模型拆成三层来看

很多朋友一上来就研究模型参数量、训练数据、微调方案，但实际做产品时，你会发现绝大多数可优化的空间都不在模型内部。我把整个系统拆成三层：

• 基座层：模型的权重、训练出的世界知识、基础推理能力。通常你买来或下载来的那个"模型"就是这一层。
• 输入层：模型在生成回答前"看到"的所有内容，包括用户的提问、你拼进上下文的检索片段、多模态的图片音频、工具描述、示例、思维链引导。
• 输出层：模型吐出 token 之后你做的一切处理，包括解析成结构化 JSON、调用函数、校验结果、自我纠错、流式推送和渲染。

为什么这么拆？因为三个层面变化的频率和成本完全不一样。基座层几年才大更新一次；输入层可能一天调十次；输出层更是每次请求都在动态执行。AI 产品的体验差异，绝大部分来自后两层的工程博弈。

1.2 基座层是那条"不太动"的基线

先说基座层。有人可能会问：明明模型也在不断更新，怎么能说它"不太动"？从普通开发者的视角看，一个模型的训练成本极高、迭代周期以季度甚至年为单位，而且同一代模型之间的能力差距，远没有我们想象中那么大。你能用开源模型跑通的任务，换一个商用的强模型大概率也行；反之，如果输入输出两侧做得很粗糙，再强的模型也会给你输出一堆垃圾。

基座层更像发动机排量和缸数：它决定了这台车的极限，但你日常感受到的"好不好开"，更多取决于变速器匹配、进气道设计和底盘调校。应用开发者的全部工作，就是在不拆发动机的前提下，把进气和排气彻底玩明白。

1.3 输入层和输出层的边界到底画在哪

边界其实很好画：以一次标准的模型推理请求为分界线。请求发出前，你决定给它什么，这是输入层；请求返回后，你决定拿这些 token 干什么，这是输出层。

有个灰区是生成过程中的干预手段，比如采样参数调整、提前终止、约束解码，这些严格说发生在"吐出 token 的过程中"，我习惯把它归入输出层的范畴，因为它们本质是"让生成结果更符合要求"的控制手段。这样划分后，任何 AI 功能你都能快速定位：它是在喂的环节上动了脑筋，还是在处理结果上动了脑筋。

2. 输入侧：所有"喂法"创新都在这里发生

2.1 RAG 的真正秘密：把外挂知识变成输入的一部分

先说最典型的输入侧创新：RAG（检索增强生成）。它的做法是，收到用户问题后，先从知识库里检索相关片段，再把片段拼进提示词一起交给模型。注意，整个过程中模型权重没有改变，模型没有"额外记住"你的文档，它只是这一次"看见"了你喂它的内容。

我做过一个客户文档问答系统，一开始总想走微调路线，认为只有让模型"学会"内部文档才能答得好。后来实测发现，把文档切片、去重、拼接进上下文的效果，已经比微调好太多了，而且改动成本低到可以当天迭代——这就是输入侧的杠杆。你不需要重新训练一个模型，你只需要重新组装这一次的输入。

实操时有个细节被很多人忽视：检索出的片段不能无脑按相关度排序后整段拼进去。模型对中间位置的信息记忆最差，重要片段应放在靠前或靠后的位置；同时相邻片段之间要加明确的段落标记和引用来源，否则模型会把不同来源的信息错误混用。这些全是输入层的"组装工艺"。

2.2 思维链和提示工程：让模型"看见"推理路径

第二个输入侧大杀器是思维链（Chain of Thought）。给模型一个示例，说"请一步一步推理，最后给出结论"，模型的数学和逻辑表现往往明显上升。很多人把它当成某种神秘能力，其实回到三层框架里看，它只是在输入里额外铺设了一条"注意力引导路径"。模型在自回归生成时，每一步都在基于之前的 token 选下一个 token，如果你在开头就暗示它"先分析条件、再构建方程、最后验算"，它的 token 选择就会沿着更可控的方向走。

类似的还有 few-shot 示例。有段时间我在调一个分类场景，模型对几个边界类别的判断总飘。后来我从真实数据里挑了 8 个典型样本，在提示词里手把手教了一遍，效果立刻稳定。这 8 条样本花了我半小时，但换来的是大批量生产的稳定性——这就是输入侧最划算的投资。

但也要提醒：思维链不是越多越好。某些任务上模型会"强行解释"，生成冗长的中间步骤反而拉高 token 成本和延迟。我一般会在需要严谨推理的任务里才显式开启思维链，简单的翻译、摘要任务保持直接输出。

2.3 多模态输入与 Agent 的上下文组装

输入侧的另一片新大陆是"把各种东西塞进输入"。图片转成视觉 token、音频切成语音 token、工具调用说明写成函数描述、历史记忆压缩成摘要……这些最终都要在输入序列里被模型统一处理。你甚至可以理解为，模型只有一个大脑，但它的"眼睛"和"耳朵"是可以通过输入层无限扩展的。

Agent（智能体）的运作方式更直白。以一次任务执行为例，模型读到用户目标和可用工具清单，输出一个调用意图；外部程序执行工具后，把结果留痕追加到对话里，重新作为下一轮输入喂回去。Agent 的核心循环就是"造输入、收输出、再造输入"。如果你在这一层组装得粗糙，比如把工具返回的整段 JSON 原样塞回上下文，模型会被大量无关字段干扰，出现"指挥幻觉"或"目标漂移"。

我踩过最典型的坑是：某个工具返回了 300 行状态数据，其中只有 3 行是关键。我把 300 行全塞进输入，结果模型为了凑齐完整信息，反而把不相关的字段也编进了下一步决策。后来改成先对工具返回结果做字段抽取和摘要再喂回，效果立刻正常。

2.4 输入侧的成本和长上下文陷阱

输入侧不是免费的。所有拼进上下文的 token 都要付计算费用，且输入越长，首字延迟越高。最让人头疼的是"长上下文迷失"现象：当输入内容超过一定长度，模型对中间部分的信息敏感度显著下降，这不是模型变笨了，而是注意力资源被分散了。

我的处理方式是把输入分成三层来管理：固定指令层（系统提示词，恒定不变）、知识素材层（按需检索的文档片段，保持精简）、动态状态层（用户问什么、工具返回什么，按规则压缩）。这样做既省钱，又能减少无关信息对判断的干扰。所有在输入侧做工程的人，本质上都在做同一件事：让模型每一次"看到"的内容，既完整又干净。

3. 输出侧：所有"用法"创新都在这里发生

3.1 结构化输出：从"满嘴跑火车"到机器能直接用

模型默认吐的是自然语言，但业务系统要的是 JSON、YAML、可执行的 API 参数。于是出现了结构化输出、函数调用约束等一系列技术。它们的本质，是用解码时的 token 白名单或约束规则，把模型的输出"框"在某个约定的结构里。

我自己最常用的是给模型一个 JSON Schema 并要求严格按格式输出，同时开启外层解析。一旦解析失败，就让模型基于报错重试一次。这里有个小教训：如果你需要模型先思考再给结果，不要指望它在一个 JSON 字段里同时塞"思考过程和最终答案"，那样极易破坏格式。更稳妥的做法是让第一轮输出自由文本，第二轮再要求它把上一轮内容转成 JSON。

3.2 Function Calling 与工具执行：输出是起点不是终点

输出侧最具革命性的变化，是让模型的输出变成一个"动作指令"而不是"最终答案"。模型说"我想调用查询天气函数，参数是北京"，然后真正联网查天气的是你的代码，查完结果又追加回输入让模型组织语言回答。

这套循环里，模型充当的是"决策器"而不是"执行器"。因而不必让模型真的懂怎么查天气，它只需要从函数描述和参数 schema 中学会"何时调用、参数取什么值"。这是我做自动化工作流时经常用到的手段：把重复性操作拆成十几个工具函数，模型负责调度，业务逻辑负责执行。

但有个绕不开的大坑：模型会臆想出不存在的函数名，或者给函数参数编造不存在的取值。所以我一定会在输出层加白名单校验和参数类型校验，任何不在列表中函数名都被直接拦截，绝不"宽容放行"。这是工具调用稳定性的底线。

3.3 输出后处理与自我纠错：把一次生成变成多轮打磨

再往输出侧走，你会发现越来越多的"新花样"是在生成完之后做二次加工。自反思架构就是典型：模型先给一版答案，然后把"请检查你刚才的答案，指出错误并重写"作为新的输入再喂回去。这一招在代码生成、数学证明、长文润色里都很有效。

为什么有效？因为第一轮生成时模型容易"顺着惯性一口气写完"，把自己藏在推理链里的逻辑漏洞也顺带糊弄过去。第二轮给它一个审视指令后，它重新分配注意力去检查自己刚写的内容，本质上形成了"生成—审查—修正"的生产回路。缺点也明显：token 消耗翻倍、延迟翻倍。我的经验是最多做一轮自查，超过一轮的收益边际递减，很多时候第二轮和第三轮改的内容已经分不出高下了。

输出侧的另一个重要工作是护栏处理：过滤敏感词、机读字段的合法性校验、落库前的格式修复。这些虽然不起眼，但直接决定了系统的可用性。我见过一个项目把输出侧校验做成独立微服务，不管换哪个模型，校验规则都不变——这让团队后来换模型时省下大量适配时间。

3.4 输出侧的稳定性和延迟细节

不要忽视输出侧的工程参数。温度调得越高，模型创造力越强，但结构化输出的格式错乱率也越高；我发现在需要稳定 JSON 的任务里，把温度降到接近 0 是最划算的改动。流式输出则是个体验与逻辑的博弈：需要全文结构化校验的场景，等完整输出再处理更稳；纯粹聊天问答，边生成边推可以显著降低用户等待感。

还有超时兜底。模型卡住、网络抖动、服务端过载，都会让输出侧流程停滞。每层工具调用我都设超时并绑定降级策略，宁可返回"回答失败请重试"，也不能让用户看到无限转圈。技术上的道理其实不复杂：输出内容只是模型吐出来的一串 token，而后面的处理管道才是决定它有没有价值的关键。

4. 用这套框架重新看几个热门玩法

4.1 为什么说 RAG 是"输入侧的百科全书游戏"

有了三层框架，再回看 RAG 就特别清晰：它没有动基座层，也没有在输出侧做什么新处理，它就是单纯在输入侧拼装了几段与当前问题最相关的文本。所以任何宣传"RAG 让模型学会文档知识"的说法，严谨一点讲应该是"RAG 让模型在回答的那一刻读到了文档知识"。

这个区分有实际意义。如果你希望模型"长期记住"某个领域的说话风格，RAG 很难做到，因为每次都要现检索、现拼接；但如果你只需要"回答问题时能引用到最新资料"，RAG 的性价比完胜微调。判断一个方案该落在哪层，就看信息是一次性的还是持续的。

4.2 Agent 是输入输出两侧的"双料选手"

Agent 最不好归类的地方在于它同时改了两侧：每次行动前，它在构造输入（把工具结果、历史目标重新组装）；每次行动后，它在解析输出（把模型指令翻译成可执行动作）。它的"聪明"不在于模型本身多强，而在于外部系统给了它一个"反馈回路"。

我在设计 Agent 时习惯把每一轮子任务都看成一个独立的"输入输出契约"：这一轮模型要读什么、输出什么结构、校验通过后触发哪个动作。一旦把 Agent 拆成无数个小契约，调试就变得非常简单——你永远不会面对一个不可控的"大模型怪物"，你面对的是一系列可以逐个排查的输入输出环节。

4.3 思维链和自反思到底归在哪一层

细心一点会发现，思维链和自反思的边界其实很暧昧。思维链显式写在提示词里，是输入侧工程；自反思要把第一轮输出作为第二轮输入，属于"输出—输入"的跨层回路。这也是我喜欢这套框架的原因：它不追求非此即彼的分类，而是帮你把每一种创新放到它真正动了的环节上。

任何 AI 新玩法出现时，你都可以用两个问题快速定位：它改变了模型看到什么吗？它改变了模型生成之后的处理方式吗？如果两个答案都是"是"，那你面对的是工程型创新；如果两个答案都是"否"，多半只是换个说法炒作旧概念。

5. 我在实战中怎么用这套框架

5.1 先定输入输出契约，再选模型

现在我做任何 AI 功能，都强制走一个流程：先写清楚"系统要接收什么输入、最终要产出什么输出、失败时怎么兜底"，然后才去挑模型。这个契约一旦定下来，绝大多数技术路线都跟着明朗了。需要读长文档？输入层要做切片和检索，模型挑长上下文支持好的。需要稳定 JSON？输出层要做 schema 校验，模型挑格式跟随能力强的。剩下的事不过是把三层各自优化好。

这样还有一个额外好处：换模型变成低成本事件。只要输入输出契约不变，底座换一个差不多的模型，系统整体表现不会有太大波动。我最近一次换底座只改了两个提示词，剩下的校验逻辑、组装逻辑全部原封未动。

5.2 分层调试：出了问题先归因再做决定

遇到模型返回异常时，我的第一反应永远是"这是哪一层的问题"，而不是急着换模型或加提示词。这里是我常用的诊断清单：

这套清单帮我避免了很多无用功。以前遇到问题我先盲目堆提示词，现在则先分三层定位，多数情况下问题出在"输入没组织好"或"输出没校验好"，根本轮不到换模型。

5.3 一个判断"AI 新花样"值不值得追的小过滤器

朋友圈每隔几周就会传一个新玩法：某框架能自动写代码、某方案能做复杂推理、某产品号称"结合了大模型和知识图谱"。我现在不会立刻跟着跑，而是先做一次三层归因：它在哪一层做了什么？如果它本质上是在输入侧做更好的上下文组装，或者输出侧做更强的工具调度，那我就会认真研究，因为这些是可持续的工程积累。如果它绕了半天说不清改了哪一层，只丢出一堆效果截图，我大概率当噪音处理。

说实话，用这套框架一年多，我最大的变化是心态稳了：不再焦虑"模型会不会很快淘汰我的方案"，因为模型是别人训练的，而输入输出两侧的工程能力是我自己沉淀的。只要某个需求能被清楚地定义成"喂什么、怎么处理结果"，我就有信心把它做得又快又稳。

最后分享一个实操小技巧：把你项目里最核心的那一条提示词拿出来，用"输入层做了哪些组装、输出层做了哪些加工"逐个拆解，往往能发现几处此前完全没意识到的浪费——可能是多余的历史消息拖慢了速度，可能是没做结构化校验导致下游频繁报错。把这些不起眼的小问题修完，整个系统的提升可能比你换一个更强的模型还要明显，这也是我对这套三层架构最直观的体会。