1. 为什么“三层架构”是理解大模型应用的万能钥匙
很多人第一次接触大模型应用开发时，会被各种新名词砸晕：RAG、Agent、Function Calling、思维链、多模态、工作流编排……每隔几周就冒出一个新概念，感觉永远追不完。但如果你把这些花样全部摊开来看，会发现一个让人安心的事实：几乎所有大模型应用，本质上都在做三件事——决定输入什么、让模型怎么处理、对输出做什么加工。
这就是我所说的“三层架构”。它不是某个框架的官方定义，而是我在做过多个大模型落地项目之后，总结出来的一套拆解思路。一旦你掌握了这个视角，再看到任何新概念，都能在三秒内把它归类：它到底是在改输入层、处理层，还是输出层？它解决的是哪一层的什么问题？
先把这个框架的核心逻辑说清楚。大模型本身是一个“输入文本→输出文本”的概率函数，它没有记忆、没有手脚、没有外部知识。所有围绕它构建的应用系统，本质上都是在三个位置做文章：
- 输入层：决定送给模型的上下文里到底有什么。包括提示词设计、检索增强、历史对话管理、工具描述注入、多模态信息转换等。
- 处理层：决定模型在生成过程中怎么被引导和控制。包括思维链、推理策略、采样参数、多轮迭代、模型路由等。
- 输出层：决定模型吐出来的原始文本怎么被解析、验证、加工和落地。包括结构化解析、格式校验、后处理、工具调用执行、结果渲染等。
你可能会问：为什么不是四层、五层？因为再往下拆，每一层内部的细分确实可以很多，但从系统设计的角度看，任何对大模型能力的扩展或约束，最终都必然落在“进去什么”和“出来怎么用”这两个端点上。处理层则是介于两者之间的调控手段。三层已经足够覆盖所有主流模式，又不会复杂到难以记忆。
这个框架最大的价值在于：它让你从“追新”变成“归类”。下次再看到什么新概念，你不需要从头学起，只需要问自己——它改的是哪一层？改的方式是什么？我现在的系统需不需要这个改动？这三个问题一过，你就知道该不该花时间深入了。
提示：三层架构不是学术分类，而是工程视角的拆解工具。它的目的是帮你快速定位问题、做技术选型，而不是追求理论上的完备性。
2. 输入层：决定模型“看到什么”才是效果的分水岭
2.1 提示词工程只是输入层最表面的那一层
大部分人提到大模型应用，第一反应就是“写提示词”。提示词确实是输入层最直观的部分，但它远不是全部。提示词工程解决的是“怎么把指令说清楚”，而输入层要解决的是“模型在生成之前，它的上下文窗口里到底应该有什么信息”。
这两者的区别很大。提示词写得好，模型能更准确地理解你的意图；但如果模型压根没看到关键信息，提示词写得再漂亮也没用。举个例子：你让模型回答“我们公司去年的营收增长率是多少”，提示词写得再清晰，模型也不可能知道这个数据——除非你把财报数据放进了输入里。
所以输入层的核心任务可以概括为一句话：在模型的能力边界内，把完成任务所需的信息尽可能完整、准确、结构化地塞进上下文窗口。提示词只是组织这些信息的一种手段。
2.2 检索增强生成（RAG）的本质是动态构建输入
RAG是过去两年最火的大模型应用模式之一。很多人把它当成一个独立的技术栈来学，但如果从三层架构来看，RAG本质上就是在输入层做动态信息注入。
它的工作流程是这样的：用户提出一个问题，系统先去外部知识库（向量数据库、搜索引擎、文档系统等）检索相关内容，然后把检索到的片段和用户问题一起组装成提示词，送给模型生成答案。模型本身没有变，变的是它看到的输入。
为什么RAG这么重要？因为大模型有三个硬伤：知识截止日期、幻觉问题、私有数据盲区。RAG分别对应解决这三个问题——检索最新资料解决知识截止，用真实文档作为依据减少幻觉，接入内部知识库解决私有数据问题。但注意，RAG的所有动作都发生在模型生成之前，它不改变模型本身，只改变模型看到的东西。
实操中，RAG最容易被忽视的细节是“检索质量决定生成质量”。很多人花大量时间调提示词，却忽略了检索环节的召回率和准确率。如果检索回来的内容本身就不相关，模型再强也生成不出好答案。我的经验是：在RAG系统里，检索环节的优化优先级应该高于提示词优化。先把对的资料找出来，再考虑怎么让模型用好这些资料。
2.3 上下文窗口管理：被低估的工程难题
输入层还有一个很容易被低估的问题：上下文窗口管理。模型的上下文窗口是有限的，但实际应用中，你可能有很多信息都想塞进去——系统指令、历史对话、检索结果、工具描述、用户输入、格式要求……这些东西加起来很容易超出窗口限制。
怎么取舍？这不是一个简单的“截断”就能解决的问题。我的做法是分层管理：
- 固定层：系统指令和核心规则，永远保留，放在最前面。
- 动态层：检索结果和工具描述，按相关度排序，优先保留高相关的内容。
- 历史层：对话历史，采用滑动窗口加摘要的方式，近期对话保留原文，远期对话压缩成摘要。
- 用户层：当前用户输入，永远保留，放在最后。
这个顺序不是随便定的。模型对上下文不同位置的注意力分布是不均匀的，通常开头和结尾的信息更容易被关注，中间部分容易被忽略。所以关键指令放开头，当前问题放结尾，中间放辅助信息，这是一个比较稳妥的策略。
注意：不同模型对上下文位置的敏感度不同，实际项目中需要针对你使用的模型做测试。不要假设所有模型都遵循同样的注意力模式。
2.4 多模态输入：把图片、音频、表格都“翻译”成模型能懂的形式
多模态是大模型应用的重要方向，但从三层架构来看，多模态输入的本质是把非文本信息转换成模型能处理的表示形式。无论是图片、音频还是视频，最终都要被编码成向量或文本描述，才能进入模型的上下文。
这里有一个常见的误区：很多人以为多模态模型就是“直接看懂图片”。实际上，当前主流的多模态模型在处理图片时，通常是把图片切分成小块，每块编码成一个向量，然后和文本 token 一起送入模型。模型并不是像人一样“看”图片，而是在处理另一种形式的输入序列。
这个认知很重要，因为它决定了你在做多模态应用时的优化方向。比如，如果你要让模型识别图片中的文字，直接把高清原图送进去可能效果不好，因为图片被切分后文字可能变得模糊。更好的做法是先做 OCR 提取文字，再把文字和图片一起送入模型。这就是在输入层做优化的典型例子。
3. 处理层：模型“怎么想”决定了输出的上限
3.1 思维链与推理策略：让模型“慢下来”思考
处理层最核心的问题是：模型在生成答案之前，要不要先“想一想”？思维链（Chain of Thought）就是解决这个问题的经典方法。它的做法很简单：在提示词里要求模型“一步一步思考”，或者给出几个带推理过程的示例，模型就会在给出最终答案之前，先输出一段推理过程。
为什么这有效？因为大模型的生成是逐 token 进行的，每一个 token 的生成都依赖于前面的 token。如果模型直接输出答案，它没有“中间计算”的空间；但如果它先输出推理步骤，这些步骤就成为了后续生成的上下文，相当于模型在“自言自语”中完成了计算。
这个原理听起来简单，但实操中有几个关键细节：
- 推理步骤的质量比数量重要。让模型写十步废话，不如写三步关键推理。
- 不是所有任务都需要思维链。简单的分类、抽取任务，直接输出答案往往更准确。思维链主要适用于数学、逻辑、多步推理类任务。
- 思维链会增加 token 消耗和延迟。在生产环境中，这是一个需要权衡的成本。
我的经验是：先测试不用思维链的效果，如果准确率不够，再加思维链。不要一上来就默认开启，那样既浪费成本又可能引入不必要的错误。
3.2 采样参数：温度、Top-p 这些旋钮到底在调什么
处理层还有一组很重要的控制参数：温度（Temperature）、Top-p、Top-k 等采样参数。这些参数控制的是模型在生成每个 token 时，如何从概率分布中选择下一个 token。
用生活化的类比来解释：模型在每一步生成时，会给词表里每个 token 算一个概率。温度参数就像是一个“冒险程度”旋钮——温度低，模型倾向于选概率最高的那个 token，输出稳定但可能保守；温度高，模型会给低概率 token 更多机会，输出多样但可能跑偏。
Top-p 则是另一种控制方式：它不看概率的绝对值，而是看累积概率。比如 Top-p=0.9，意思是只从累积概率达到 90% 的那部分 token 里采样，剩下的 10% 直接排除。这样可以避免模型选到那些概率极低的离谱 token。
这些参数没有“万能最优值”，完全取决于任务类型：
| 任务类型 | 推荐温度 | 推荐 Top-p | 原因 |
|---|---|---|---|
| 事实问答 | 0-0.3 | 0.8-0.9 | 需要稳定准确的输出 |
| 创意写作 | 0.7-1.0 | 0.9-0.95 | 需要多样性和惊喜感 |
| 代码生成 | 0-0.2 | 0.8-0.9 | 需要精确和可运行 |
| 数据抽取 | 0 | 1.0 | 需要完全确定性的输出 |
| 对话聊天 | 0.5-0.8 | 0.9 | 平衡稳定性和趣味性 |
提示：温度设为 0 并不保证完全确定性输出，因为底层硬件和并行计算可能引入微小差异。如果业务要求严格可复现，需要在应用层做缓存或结果校验。
3.3 模型路由：不是所有任务都需要最贵的模型
处理层还有一个很实用的策略：模型路由。简单说就是根据任务难度和类型，选择不同规模或不同专长的模型来处理。
为什么要这样做？因为大模型 API 的成本和延迟差异很大。一个简单的意图分类任务，用最小的模型就能做到 95% 的准确率，没必要用最贵的模型。而一个复杂的多步推理任务，小模型可能完全做不了，必须用大模型。
模型路由的实现方式通常有两种：
- 规则路由：根据任务类型、输入长度、关键词等规则，硬编码路由逻辑。简单可靠，但不够灵活。
- 学习路由：训练一个分类器或使用小模型来判断任务难度，动态选择模型。更灵活，但需要额外训练和维护。
我的建议是：从规则路由开始，等积累了足够的数据和经验，再考虑学习路由。大部分场景下，规则路由已经能覆盖 80% 的优化空间。
3.4 多轮迭代与自我修正：让模型“再想想”
处理层还有一个重要模式：多轮迭代。它的核心思想是不让模型一次生成就定稿，而是让它在生成后自我检查、修正，再输出最终结果。
常见的做法包括：
- 自我一致性：让模型用不同的推理路径生成多个答案，然后投票选出最一致的那个。
- 自我修正：让模型生成初稿后，自己检查错误并修正。
- 批判-修订：用一个模型生成，另一个模型批判，再让第一个模型修订。
这些方法确实能提升输出质量，但代价是成倍的 token 消耗和延迟。在实际项目中，我通常只在高价值、低频率的任务上使用多轮迭代，比如合同审查、代码审查、重要报告生成等。对于高频的日常任务，单次生成加输出层校验往往更划算。
4. 输出层：模型“吐出来”之后才是真正见功夫的地方
4.1 结构化输出：让模型返回 JSON 的可靠方法
输出层最基础也最重要的任务，就是把模型的自然语言输出转换成程序能处理的结构化数据。最常见的就是让模型返回 JSON。
但让模型稳定返回合法 JSON 并不是一件理所当然的事。早期的大模型经常会在 JSON 外面加解释文字，或者漏掉引号、多出逗号。虽然现在很多模型 API 提供了“JSON 模式”或“结构化输出”功能，但在实际项目中，你仍然需要做校验和兜底。
我的做法是三层保障：
- 提示词约束：在提示词里明确要求“只输出 JSON，不要任何其他文字”，并给出格式示例。
- API 参数：如果模型支持，开启 JSON 模式或指定输出 schema。
- 代码校验：拿到输出后，先用 JSON 解析器尝试解析，失败则触发重试或降级处理。
重试策略也很关键。不要简单地“原样重试”，那样很可能再次失败。更好的做法是：把解析错误信息附加到下一次请求中，让模型知道上次哪里错了，有针对性地修正。
4.2 工具调用：输出层最强大的能力扩展
工具调用（Function Calling / Tool Use）是大模型应用的一个里程碑式能力。但从三层架构来看，它的本质是在输出层做动作执行。
工作流程是这样的：你在输入层告诉模型有哪些工具可用（工具描述），模型在处理层决定是否需要调用工具，如果需要，它在输出层生成一个结构化的调用请求（比如函数名和参数），你的程序解析这个请求，执行实际的操作，再把结果送回给模型，让模型生成最终回复。
这个流程里，最容易被忽视的是工具描述的质量。工具描述就是输入层的一部分，它决定了模型能不能正确理解每个工具的功能和使用场景。我见过很多工具调用失败的案例，根源不是模型能力不够，而是工具描述写得太模糊。
好的工具描述应该包含：
- 工具的功能是什么（一句话说清楚）
- 什么情况下应该使用这个工具
- 每个参数的含义、类型、是否必填
- 参数的格式要求或取值范围
- 一个简单的调用示例
注意：工具描述不是写给人类开发者看的文档，而是写给模型看的“使用说明书”。要用模型能理解的自然语言，避免过于专业的缩写和内部术语。
4.3 输出校验与后处理：别让模型的“自信”骗了你
大模型有一个特点：它生成的内容往往语气很自信，但内容可能是错的。这就是所谓的“幻觉”问题。输出层的校验和后处理，就是要在模型输出和最终用户之间建立一道质量防线。
校验的维度可以包括：
- 格式校验：输出是否符合预期的结构（JSON、XML、Markdown 等）。
- 事实校验：输出中的关键事实是否与知识库或检索结果一致。
- 逻辑校验：输出中的推理步骤是否自洽，有没有矛盾。
- 安全校验：输出是否包含不当内容或敏感信息。
- 业务规则校验：输出是否符合业务约束（比如金额范围、日期格式等）。
后处理则是在校验之后，对输出做进一步的加工。比如：把模型输出的 Markdown 转换成 HTML，把数字格式化成货币样式，把长文本截断或摘要，等等。
我的经验是：输出层的校验规则应该是可配置、可扩展的。不同业务场景对输出的要求不同，硬编码校验逻辑会导致系统难以维护。用一个规则引擎或配置化的校验管道，会让后续迭代轻松很多。
4.4 流式输出与用户体验：让等待变得不那么难熬
输出层还有一个影响用户体验的重要因素：流式输出。大模型生成完整回复可能需要几秒到几十秒，如果等全部生成完再一次性展示，用户会觉得系统“卡住了”。流式输出就是让模型每生成一个 token 就立即推送给前端，用户可以看到文字逐字出现，感知上的等待时间大大缩短。
实现流式输出在技术上并不复杂，大多数模型 API 都支持流式接口。但有几个细节需要注意：
- 前端渲染要跟上：流式输出需要前端配合，用 WebSocket 或 Server-Sent Events 接收数据并实时渲染。
- 中途错误处理：流式输出过程中如果出错，已经输出的部分怎么处理？是保留还是清空？需要提前设计好。
- 后处理与流式的冲突：如果输出层有复杂的后处理逻辑，可能无法做到真正的流式。这时候需要权衡：是牺牲流式体验保证后处理质量，还是简化后处理换取流式体验。
5. 用三层架构重新理解那些“新花样”
5.1 Agent 不是新东西，它只是三层架构的循环
Agent 是最近很火的概念，但如果你用三层架构去拆解，会发现它并不神秘。Agent 的本质就是把输入层、处理层、输出层串成一个循环：模型观察当前状态（输入），决定下一步动作（处理），执行动作并获取结果（输出），然后把结果作为新的输入，继续循环，直到任务完成。
所以 Agent 的核心挑战不在于“它是什么”，而在于循环的控制：什么时候继续循环，什么时候停止？如何避免无限循环？如何处理循环中的错误？这些问题才是 Agent 工程化的关键。
5.2 工作流编排：把多个三层架构串起来
工作流编排（Workflow Orchestration）是另一个热门方向。它的做法是把一个复杂任务拆成多个步骤，每个步骤可能是一次模型调用，也可能是一个传统程序处理。从三层架构来看，每个步骤都是一个独立的三层架构，工作流编排则是决定这些步骤怎么串联、怎么传递数据、怎么处理分支和异常。
理解了这一点，你就知道工作流编排的核心不是“怎么调模型”，而是“怎么设计步骤之间的接口和数据流”。模型调用只是其中一个环节，真正的复杂度在于流程控制和状态管理。
5.3 微调与三层架构的关系
微调（Fine-tuning）看起来和三层架构无关，因为它改的是模型本身。但如果你仔细想，微调的目的通常是让模型在特定任务上的输入-输出映射更准确。它改变的是模型处理层的能力，但输入层和输出层的设计原则并没有变。
而且，在实际项目中，微调往往不是第一选择。大多数场景下，优化输入层（更好的提示词、更准的检索）和输出层（更严格的校验、更完善的后处理）就能达到可接受的效果。微调应该是在输入输出层都优化到位之后，仍然无法满足需求时的进阶手段。
6. 三层架构的实操检查清单
6.1 输入层检查项
- 模型是否看到了完成任务所需的全部关键信息？
- 提示词是否清晰、无歧义、有格式示例？
- 检索结果的相关度和覆盖度是否足够？
- 上下文窗口是否超限？超限时的截断策略是否合理？
- 多模态输入是否经过了适当的预处理？
6.2 处理层检查项
- 任务是否需要思维链？当前是否开启？
- 采样参数是否匹配任务类型？
- 是否考虑了模型路由来优化成本和延迟？
- 是否需要多轮迭代？成本是否可接受？
- 工具描述是否清晰、完整、无歧义？
6.3 输出层检查项
- 输出格式是否稳定？是否有校验和兜底？
- 工具调用的解析和执行是否可靠？
- 是否有事实校验和逻辑校验？
- 流式输出的体验是否流畅？错误处理是否完善？
- 后处理逻辑是否可配置、可扩展？
这张清单不是一次性的，而是应该在每次迭代时重新过一遍。大模型应用的效果优化，本质上就是在三层架构里不断找瓶颈、补短板的过程。
7. 我在实际项目中的几点体会
做了这么多大模型项目，最大的体会是：不要被新概念牵着走，要回到三层架构去思考。每次看到一个新框架或新方法，先问自己：它改的是哪一层？它解决的是什么问题？我现在的系统有没有这个问题？这三个问题一过，大部分新概念都可以被快速归类，该深入就深入，该跳过就跳过。
第二个体会是：输入层的优化往往投入产出比最高。很多团队一上来就想微调模型、上 Agent，但实际问题可能只是检索没做好、提示词没写清楚。把输入层做扎实，效果提升往往立竿见影，成本却低得多。
第三个体会是：输出层的校验和后处理是生产环境的生命线。Demo 可以容忍模型偶尔出错，但生产环境不行。输出层的校验规则越完善，系统就越可靠，用户信任度就越高。这块工作不性感，但必须做。
最后一个建议：三层架构不是割裂的，而是相互影响的。输入层的信息质量会影响处理层的推理效果，处理层的策略会影响输出层的解析难度，输出层的反馈又可以用来优化输入层的检索和提示词。把这三层当成一个整体来设计和迭代，而不是各自为战，才能让系统持续进化。
