1. 为什么“三层架构”是理解大模型应用的万能钥匙
很多人第一次接触大模型应用开发时，会被各种新概念砸晕：提示工程、RAG、Agent、Function Calling、思维链、结构化输出、工作流编排……每隔几个月就冒出一批新词，感觉永远追不完。但如果你把这些东西拆开看，会发现一个让人安心的事实：几乎所有大模型应用，本质上都落在三个层面上——输入层、模型层、输出层。而模型层本身的能力边界，是由模型厂商决定的，普通开发者真正能折腾、能做出差异化的，只有输入层和输出层。
这个判断听起来有点绝对，但我可以拿实际经验来佐证。过去两年我参与过十几个大模型落地项目，从智能客服、文档问答到代码助手、数据分析Agent，每次遇到新需求，团队里总有人第一反应是“要不要换个更强的模型”或者“是不是要微调”。但真正复盘下来，绝大多数效果问题最后都是在输入构造和输出处理上解决的，模型本身换不换反而没那么关键。原因很简单：同一个模型，你给它一段模糊的指令和一段结构清晰、上下文完整的输入，输出质量可以差出好几倍；同样一段模型输出，你直接扔给用户和经过一轮解析、校验、格式化再返回，用户体验也是天壤之别。
所以这篇文章想做的事情很明确：把大模型应用拆成输入层、模型层、输出层这三层，逐层讲清楚每一层到底在做什么、有哪些常见套路、哪些坑最容易踩。不管你是刚入门想搞清楚RAG和Agent到底怎么回事，还是已经做过几个项目但总觉得效果不稳定，这套框架都能帮你把零散的知识点串起来。读完之后，你再看到任何新的AI玩法，都可以用这个框架去拆解它——它到底是在输入上做了文章，还是在输出上做了处理，或者只是换了个模型。
提示：这篇文章不会教你训练模型，也不会深入Transformer的数学细节。我们聚焦的是应用层——你作为一个开发者或产品负责人，拿到一个现成的模型API之后，怎么把它用好。
2. 输入层：决定模型“看到什么”才是效果的分水岭
2.1 输入层的本质：把用户意图翻译成模型能理解的形式
输入层要做的事情，说白了就是把用户的真实需求，转换成一段模型能正确处理的内容。这件事听起来简单，但实际做起来，它是整个应用链路里最考验功力的环节。因为用户的表达往往是模糊的、不完整的、带有隐含前提的，而模型只能根据你给它的文本来推理。你给的信息不够，它就猜；你给的信息有歧义，它就选一个它认为最可能的解释——而这个解释未必是你想要的。
举个很常见的例子。用户说“帮我看看这个合同有没有问题”，如果你直接把这句话扔给模型，它会给你一段泛泛的合同审查建议，什么“注意违约责任条款”“确认付款方式”之类，看起来有道理但完全没法用。但如果你在输入层做几件事：把合同全文附上、告诉模型“你是一名有十年经验的企业法务，请从甲方角度逐条审查风险点”、要求它“按条款编号输出，每条给出风险等级和建议修改方案”——同一个模型，输出质量立刻上一个大台阶。这就是输入层的价值。
从技术角度看，输入层的核心工作可以归纳为四类：指令构造、上下文注入、示例引导、格式约束。下面逐一展开。
2.2 指令构造：系统提示词不是越长越好，而是要“有层次”
系统提示词（System Prompt）是输入层最基础也最重要的部分。很多人写系统提示词的习惯是“把所有能想到的要求都堆上去”，结果写了几百字，模型反而抓不住重点。我自己的经验是，好的系统提示词应该有清晰的层次结构，一般包含四个部分：
- 角色定义：告诉模型它是谁，这会影响它的语气、知识调用倾向和推理方式。比如“你是一名资深后端工程师”和“你是一名技术写作专家”，面对同一个问题给出的回答风格完全不同。
- 任务描述：明确它要做什么，越具体越好。“回答用户问题”太模糊，“根据用户提供的代码片段，找出潜在的并发安全问题并给出修复建议”就清晰得多。
- 约束条件：哪些能做、哪些不能做、边界在哪里。比如“不要编造不存在的API”“如果信息不足，明确说明而不是猜测”。
- 输出要求：格式、长度、语言风格等。这部分和输出层有重叠，但在输入层就要提前约定好。
我见过不少项目把系统提示词写成一大段没有分段的文字，模型理解起来其实很吃力。后来我们改成用Markdown的分级标题来组织，比如用## 角色、## 任务、## 约束、## 输出格式这样的结构，模型对指令的遵循度明显提升。这个技巧背后的原理是：模型在训练时见过大量结构化文档，分级标题本身就是一种它熟悉的“语义分隔符”，能帮助它区分不同模块的指令。
2.3 上下文注入：RAG的本质就是“把对的资料放到输入里”
RAG（检索增强生成）这两年特别火，但拆开看，它的本质非常简单：在用户问题之外，额外把相关的资料片段拼接到输入里，让模型基于这些资料来回答。它解决的是模型知识过时和幻觉的问题——模型不知道的事情，你把资料给它，它就能回答。
但RAG做得好不好，差距极大。我踩过的坑包括：检索回来的文档片段太长，把模型上下文塞满了，导致它反而忽略了用户真正的问题；检索片段之间互相矛盾，模型不知道该信哪个；检索到的内容和问题只是关键词匹配，语义上根本不相关。这些问题都不是模型的问题，而是输入层的问题。
实际操作中，有几个经验值得分享。第一，检索片段要做重排序和截断。不要检索到十条就塞十条，先用一个轻量级的重排序模型打分，取最相关的前三到五条，每条控制在合理长度内。第二，给每个片段加上来源标注，比如“以下内容来自《XX技术规范》第3.2节”，这样模型在回答时能引用来源，用户也更容易验证。第三，在输入里明确告诉模型怎么使用这些资料，比如“请优先基于以下资料回答，如果资料中没有相关信息，请明确说明”。
注意：RAG的效果上限取决于检索质量，而不是模型能力。检索环节做不好，换再强的模型也救不回来。
2.4 示例引导：Few-shot不是万能药，选例有讲究
Few-shot（少样本示例）是输入层另一个常用手段。它的逻辑是：与其用文字描述你想要什么，不如直接给几个例子让模型模仿。这在输出格式复杂、任务边界模糊的场景下特别有效。
但示例的选择是有讲究的。我见过一个项目，为了让模型学会提取合同中的关键条款，在输入里塞了二十个示例，结果模型反而变得死板，遇到示例没覆盖的条款类型就不知道怎么办了。后来我们把示例减到三个，但每个示例都覆盖不同的条款类型和边界情况，效果反而更好。示例的质量和多样性，比数量重要得多。
另外，示例的排列顺序也会影响效果。有研究表明，把最典型的示例放在最后（离用户输入最近的位置），模型遵循度更高。这个细节在实际项目中经常被忽略，但调整一下顺序就能带来可感知的提升。
2.5 输入层的常见误区：信息过载与信息不足
输入层最容易犯的两个极端错误，一个是给太多，一个是给太少。
给太多的情况通常出现在“我觉得这些信息可能有用，都放进去吧”的心态下。结果模型被大量无关信息干扰，反而抓不住重点。大模型的注意力机制虽然能处理长上下文，但并不意味着它对所有位置的信息同等关注。实践中，输入越长，模型对中间部分内容的利用率越低，这是有实验证据支持的。
给太少的情况则常见于“用户就问了一句话，我直接转发给模型”的做法。模型缺乏必要的背景信息，只能靠猜。解决办法是在输入层加一个“意图识别和信息补全”的步骤——先用一个轻量模型或规则判断用户意图，然后从数据库或知识库中拉取相关信息，补全后再送给主模型。
3. 模型层：能力边界由厂商决定，但选择策略在你手里
3.1 模型层到底在做什么：从输入到输出的“黑盒变换”
模型层是整个架构中最“神秘”的部分，因为它的内部工作机制对应用开发者来说基本是不可见的。你给它一段文本，它给你一段文本，中间发生了什么，你只能通过输出结果来推断。但这不意味着模型层没有可操作的空间——选择什么模型、怎么调用、调用几次，这些都是应用开发者可以控制的变量。
从应用视角看，模型层提供的核心能力包括：语言理解、知识调用、推理、生成、格式遵循。不同模型在这些维度上的强弱不同，有的擅长推理，有的擅长生成流畅文本，有的对格式指令遵循得特别好。你的任务是根据具体场景，选择最合适的模型，而不是盲目追求“最强”。
3.2 模型选型的三个维度：能力、成本、延迟
选模型不是选“最好的”，而是选“最合适的”。我通常从三个维度来评估：
| 维度 | 关键问题 | 常见权衡 |
|---|---|---|
| 能力 | 任务需要多强的推理和生成能力？ | 强模型效果好但贵，弱模型便宜但可能不够用 |
| 成本 | 每次调用的token消耗和单价是多少？ | 高频场景下成本差异会被放大 |
| 延迟 | 用户能接受多长的等待时间？ | 流式输出可以缓解感知延迟，但首token时间仍关键 |
实际项目中，我经常采用混合策略：用一个小模型做意图识别和路由，用一个大模型处理复杂推理任务，用另一个模型做输出格式化。这样整体成本和延迟都可控，效果也不差。比如一个客服场景，用户问题先经过小模型分类，简单问题直接走小模型回答，复杂问题才路由到大模型，整体成本能降一半以上。
3.3 调用策略：一次调用 vs 多次调用 vs 并行调用
很多人默认“一次调用解决所有问题”，但实际项目中，多次调用往往效果更好。原因在于：每次调用可以让模型专注于一个子任务，输入更聚焦，输出更可控。
常见的多次调用模式包括：
- 链式调用：第一步的输出作为第二步的输入。比如先让模型提取关键信息，再基于提取结果生成回答。
- 并行调用：同时发起多个调用，各自处理不同方面，最后合并结果。比如同时让模型从技术、法律、商业三个角度分析一份文档。
- 投票调用：同一个问题调用多次，取多数一致的结果。这在需要高可靠性的场景下有用，但成本会成倍增加。
我自己的经验是，链式调用在复杂任务中几乎是必需的。一步到位让模型做太多事情，它很容易顾此失彼。拆成几步，每步只做一件事，整体成功率反而更高。
3.4 模型层的“不可控”与应对：幻觉、漂移、格式不遵循
模型层有几个让人头疼的固有特性，应用开发者必须学会应对：
幻觉是模型编造不存在的信息。应对方法包括：在输入层提供可靠资料、要求模型引用来源、在输出层做事实校验。完全消除幻觉目前不现实，但可以通过这些手段把影响控制在可接受范围内。
输出漂移是同一个输入多次调用得到不同输出。这在需要确定性的场景下很麻烦。应对方法包括：设置较低的温度参数、使用固定随机种子（如果API支持）、在输出层做一致性校验。
格式不遵循是模型没有按你要求的格式输出。这在需要结构化数据的场景下很常见。应对方法包括：在输入层用更明确的格式说明和示例、在输出层做解析和重试、使用支持结构化输出的API特性。
提示：不要假设模型每次都会遵循指令。在生产环境中，永远要有输出校验和兜底逻辑。
4. 输出层：把模型生成变成可用产品的最后一公里
4.1 输出层的核心任务：解析、校验、格式化、呈现
输出层是很多项目最容易忽视的环节，但它直接决定了用户体验。模型生成的原始文本往往不能直接展示给用户——它可能包含多余的说明、格式不符合要求、包含敏感信息、或者需要转换成特定的数据结构。输出层要做的事情就是把模型输出加工成最终产品形态。
具体来说，输出层的工作包括：
- 解析：从模型输出中提取结构化数据。如果模型返回的是JSON，需要解析；如果是自然语言，可能需要用规则或另一个模型来提取关键信息。
- 校验：检查输出是否符合预期。比如JSON是否合法、必填字段是否齐全、数值是否在合理范围内。
- 格式化：把输出转换成前端需要的格式。比如Markdown转HTML、文本转表格、长文本分段。
- 呈现：决定怎么展示给用户。流式输出还是一次性展示、是否高亮关键信息、是否提供引用来源。
4.2 结构化输出：让模型输出可编程处理的数据
结构化输出是大模型应用从“玩具”走向“产品”的关键一步。如果模型输出只是一段自然语言，你的程序很难对它做进一步处理。但如果模型输出是JSON、XML或特定格式的文本，你就可以像处理普通数据一样处理它。
实现结构化输出的常见方法有几种。第一种是提示词约束：在输入里明确要求“以JSON格式输出，包含以下字段……”，并给出示例。这种方法简单但不够可靠，模型有时会加一些额外说明文字。第二种是使用API的结构化输出特性：一些模型API支持指定输出格式，模型会保证输出符合该格式。这是最可靠的方式。第三种是后处理解析：用正则表达式或解析库从模型输出中提取JSON部分，忽略多余文字。
我自己的做法是组合使用：优先使用API的结构化输出特性，同时在提示词里也强调格式要求，最后在输出层加一层解析和校验。这样即使某一层出了问题，后面的层还能兜住。
4.3 输出校验与重试：别让错误输出直接到用户面前
模型输出出错是常态，不是异常。所以输出层必须有校验和重试机制。校验的内容包括：格式是否正确、必填字段是否缺失、数值是否合理、是否包含敏感内容、是否与输入矛盾。
一旦校验失败，重试策略有几种：原样重试（同样的输入再调一次，适合随机性导致的错误）、修正重试（把错误信息附加到输入里，让模型修正）、降级处理（换一个更可靠的模型或走规则兜底）。
我踩过的一个坑是：没有设置重试上限，结果一个格式错误导致无限重试，把API配额耗光了。后来我们设置了最多重试两次，两次都失败就走兜底逻辑，比如返回一个默认回答或提示用户稍后再试。
4.4 流式输出与用户体验：让等待变得可感知
大模型生成一段长文本可能需要几秒到几十秒，如果用户一直盯着空白屏幕，体验很差。流式输出（Streaming）解决的就是这个问题——模型每生成一小段就立即返回，前端逐步展示，用户能很快看到内容开始出现，感知等待时间大大缩短。
但流式输出也带来新的问题：输出层的校验和格式化变得更复杂。因为你不是拿到完整输出后再处理，而是边接收边处理。如果中途发现格式错误，已经展示给用户的内容怎么办？我的经验是：对于需要严格格式化的场景，不用流式输出，等完整结果再处理；对于聊天、写作等场景，用流式输出提升体验，同时在最后做一次整体校验。
4.5 输出层的进阶玩法：多轮修正与自我反思
输出层还有一个进阶用法：让模型对自己的输出进行修正。具体做法是，把模型的第一次输出作为输入的一部分，让模型检查并改进。这在需要高质量输出的场景下很有效。
比如，模型第一次生成的代码可能有bug，你可以把代码和错误信息一起发给模型，让它修复。模型第一次写的文案可能不够吸引人，你可以让它“从更有说服力的角度重写”。这种“生成-批评-修正”的循环，可以显著提升最终输出质量，代价是更多的调用次数和更长的延迟。
实际操作中，我通常设置一个最大迭代次数（比如两到三轮），避免无限循环。同时，不是所有场景都需要自我反思——简单任务一次生成就够了，复杂任务才值得多轮打磨。
5. 用三层架构拆解当下热门AI玩法
5.1 Agent：输入层的动态构造 + 输出层的动作解析
Agent（智能体）是当下最热的概念之一，但拆开看，它的核心机制并不神秘。一个Agent本质上就是：根据当前状态动态构造输入，调用模型，解析输出，决定下一步动作，循环往复。
输入层在Agent里的体现是：每一步的输入都包含历史对话、当前状态、可用工具列表、以及上一步的执行结果。这个输入是动态构造的，不是固定模板。输出层的体现是：模型输出的不是给用户看的文本，而是结构化的动作指令——调用哪个工具、传什么参数。输出层需要解析这个指令，执行工具，把结果反馈到下一轮的输入里。
所以Agent的难点不在模型本身，而在输入构造的逻辑（怎么把状态和历史组织成模型能理解的格式）和输出解析的可靠性（怎么保证模型输出的动作指令能被正确解析和执行）。这两个问题都是应用层的问题，不是模型层的问题。
5.2 工作流编排：把多次模型调用串成流水线
工作流编排（Workflow Orchestration）是另一个热门方向。它的思路是：把复杂任务拆成多个步骤，每个步骤是一次模型调用或工具调用，步骤之间按预定逻辑流转。
从三层架构看，工作流编排主要工作在输入层和输出层之间的衔接上。每个步骤的输入层负责构造该步骤的提示词和上下文，输出层负责解析该步骤的结果并决定下一步走向。模型层只是每个步骤中的一个组件。
这种模式的好处是可控性强——每个步骤的输入输出都是明确的，容易调试和优化。缺点是灵活性不如Agent，遇到预设流程之外的情况可能处理不了。实际项目中，我倾向于能用工作流就用工作流，实在需要动态决策才上Agent，因为工作流的稳定性和可维护性要好得多。
5.3 多模态应用：输入输出层的扩展
多模态（图片、音频、视频）应用最近也很多。从三层架构看，多模态主要扩展的是输入层和输出层的数据类型。输入层不再只是文本，可能包含图片、音频；输出层也不再只是文本，可能包含生成的图片、语音。
但核心逻辑没变：输入层负责把多模态数据转换成模型能处理的形式（比如图片转成向量、音频转成文本），输出层负责把模型输出转换成用户能消费的形式（比如文本转语音、数据转图表）。模型层仍然是那个黑盒，只是输入输出的数据类型变多了。
5.4 微调与蒸馏：改变模型层，但不改变架构
微调（Fine-tuning）和蒸馏（Distillation）是在模型层做文章的技术。微调是用特定领域数据继续训练模型，让它在那个领域表现更好。蒸馏是用大模型的输出训练小模型，让小模型获得接近大模型的能力。
这两种技术改变的是模型层本身，但不改变三层架构的整体逻辑。你仍然需要构造好的输入、处理好的输出。而且，微调并不能替代输入层的优化——一个微调过的模型，如果输入构造得不好，效果照样不行。我见过一些团队花大力气微调模型，却忽视了提示词优化，结果整体效果提升有限。
6. 三层架构的实战检查清单与避坑经验
6.1 输入层检查清单
在每次上线前，我会对照以下清单检查输入层：
- 系统提示词是否有清晰的角色、任务、约束、输出要求四个部分？
- 是否提供了足够的上下文信息，同时避免了信息过载？
- 如果用了RAG，检索片段是否经过重排序和截断？是否标注了来源？
- 如果用了Few-shot，示例是否覆盖了主要场景和边界情况？
- 输入长度是否在模型上下文窗口的合理范围内？
6.2 模型层检查清单
- 模型选择是否匹配任务需求？是否考虑了成本和延迟？
- 是否需要多次调用或链式调用？调用策略是否经过测试？
- 温度、最大token数等参数是否针对场景调优？
- 是否有降级方案，应对模型API不可用或超时？
6.3 输出层检查清单
- 输出是否有解析和校验逻辑？校验失败是否有重试或兜底？
- 如果需要结构化输出，是否使用了API的结构化输出特性？
- 流式输出场景下，如何处理中途错误？
- 输出是否经过敏感信息过滤？
- 最终呈现格式是否适合目标用户？
6.4 我踩过的三个典型坑
第一个坑：忽视输入长度对效果的影响。早期做文档问答时，我把整篇文档塞进输入，觉得信息越全越好。结果模型对文档中间部分的内容几乎不引用，回答质量很差。后来改成只检索最相关的片段，效果反而大幅提升。教训是：输入不是越多越好，精准比全面重要。
第二个坑：假设模型输出总是符合格式。有一次做数据提取，我要求模型输出JSON，测试时一直正常，上线后偶尔出现模型在JSON前后加了说明文字的情况，导致解析失败。后来加了容错解析和格式校验重试，问题才解决。教训是：永远不要假设模型会100%遵循格式要求。
第三个坑：忽视输出层的用户体验。有一个内部工具，模型回答质量很好，但输出是一大段没有排版的文字，用户抱怨“找不到重点”。后来在输出层加了分段、加粗关键信息、生成摘要，同样的模型输出，用户满意度明显提升。教训是：模型输出不等于产品输出，中间需要加工。
6.5 三层架构的扩展思路
掌握了三层架构之后，你可以用它来分析和设计任何大模型应用。遇到一个新玩法，先问三个问题：它在输入层做了什么？它在输出层做了什么？它换了模型层吗？大多数情况下，所谓的“新玩法”都是在输入层或输出层做了创新，模型层本身并没有变。
这个框架也可以帮你做技术选型。如果一个问题主要是输入构造的问题，那就重点优化提示词和检索；如果是输出处理的问题，那就重点做解析和校验；如果确实是模型能力不够，再考虑换模型或微调。把问题定位到正确的层，才能用对解决方案。
我个人在实际项目中的体会是，三层架构最大的价值不是技术上的，而是沟通上的。当产品经理说“效果不好”时，你可以用这个框架快速定位：是输入信息不够？是模型选错了？还是输出没处理好？把模糊的“效果问题”拆解成具体的层和环节，团队协作效率会高很多。
