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 三层架构的扩展思路掌握了三层架构之后你可以用它来分析和设计任何大模型应用。遇到一个新玩法先问三个问题它在输入层做了什么它在输出层做了什么它换了模型层吗大多数情况下所谓的“新玩法”都是在输入层或输出层做了创新模型层本身并没有变。这个框架也可以帮你做技术选型。如果一个问题主要是输入构造的问题那就重点优化提示词和检索如果是输出处理的问题那就重点做解析和校验如果确实是模型能力不够再考虑换模型或微调。把问题定位到正确的层才能用对解决方案。我个人在实际项目中的体会是三层架构最大的价值不是技术上的而是沟通上的。当产品经理说“效果不好”时你可以用这个框架快速定位是输入信息不够是模型选错了还是输出没处理好把模糊的“效果问题”拆解成具体的层和环节团队协作效率会高很多。