1. 为什么“三层架构”是理解大模型应用的万能钥匙很多人第一次接触大模型应用开发时会被各种新名词砸晕RAG、Agent、Function Calling、思维链、多模态、工作流编排……每隔几周就冒出一个新概念感觉永远追不完。但如果你把这些花样全部拆开看会发现一个让人安心的事实几乎所有大模型应用本质上都在做同一件事——控制输入什么以及处理输出怎么用。我把它叫做大模型的“三层架构”。这不是某个官方标准而是我在实际做项目时总结出来的一套思维框架。它足够简单简单到你可以用它去拆解任何一个你看到的新产品又足够深深到每一层里面都有大量工程细节值得反复打磨。先把这个框架摆出来第一层输入层。决定模型看到什么。包括提示词设计、上下文拼接、检索增强、历史对话管理、多模态输入处理等。第二层模型层。决定模型怎么想。包括模型选型、参数配置、推理策略、微调与对齐等。第三层输出层。决定模型的结果怎么用。包括结构化解析、格式校验、后处理、工具调用、多轮编排等。这三层里模型层的变化其实是最慢的——底层能力由少数几家机构推动普通开发者能做的微调空间有限。而输入层和输出层才是绝大多数应用创新真正发生的地方。你看到的每一个“新花样”几乎都可以归到这两层的某个组合里。举个例子。RAG看起来很复杂但拆开看就是输入层多了一步“检索相关文档拼进上下文”输出层多了一步“引用来源标注”。Agent看起来更玄乎拆开看就是输出层解析出“要调用某个工具”然后把工具结果再拼回输入层循环往复。Function Calling、结构化输出、思维链提示全部都能放进这个框架里。所以这篇文章的目的很明确给你一套可以反复使用的拆解工具。下次再看到什么新概念你不用慌先问两个问题——它在输入层做了什么它在输出层做了什么想清楚这两个问题你就能判断它到底有没有新东西值不值得花时间学。这套框架特别适合两类人一是刚入行、被各种术语搞得焦虑的开发者二是需要做技术选型、但不想被厂商宣传牵着走的团队负责人。2. 输入层模型看到什么比模型本身更决定结果2.1 提示词不是“随便写写”而是输入层的核心工程很多人对提示词的理解还停留在“写一段话让模型干活”。但在我做过的项目里提示词设计是输入层最需要花时间的地方没有之一。同一个模型提示词差一个结构输出质量可能差出两个档次。我习惯把提示词拆成四个部分来设计角色设定告诉模型“你是谁”。比如“你是一名有十年经验的合同审核律师”。这一步的作用是激活模型在预训练阶段学到的相关领域分布。任务描述明确“要做什么”。越具体越好避免“帮我分析一下”这种模糊指令。约束条件规定“不能做什么”和“必须怎么做”。比如“只输出JSON格式”“不要编造数据”“如果信息不足直接说不知道”。示例给一两个输入输出样例。这一步对格式要求高的任务特别有效模型会模仿示例的结构。这里有一个我踩过的坑早期做信息抽取时我花大量时间调模型参数效果一直不稳定。后来发现问题出在提示词里任务描述太模糊模型每次理解的“抽取粒度”都不一样。把任务描述改成“抽取以下字段每个字段如果原文没有明确提及填null”准确率立刻上了一个台阶。提示词工程的核心不是“写得漂亮”而是“消除歧义”。你每消除一个歧义模型输出就稳定一分。2.2 上下文拼接把什么塞进窗口是一门取舍艺术大模型的上下文窗口是有限的。即使现在有些模型支持很长的上下文但“能塞进去”和“塞进去有用”是两回事。上下文越长模型对中间部分的注意力越容易稀释这是目前架构决定的。所以输入层的第二个关键问题是在有限的窗口里放什么、不放什么、怎么排序。我通常按优先级来组织上下文系统指令放在最前面定义角色和硬约束。当前任务相关的核心信息比如用户问题、检索到的关键文档片段。少量历史对话只保留最近几轮或者只保留与当前问题相关的轮次。示例如果任务格式要求高放一两个示例在任务描述后面。这里有个实用技巧如果你发现模型“忘记”了前面的指令不一定是模型能力问题很可能是上下文太长导致注意力分散。解决办法不是换模型而是精简上下文——把不必要的历史对话删掉把长文档先做摘要再拼进去。2.3 检索增强输入层最实用的“外挂”RAG本质上就是输入层的一个扩展在用户问题之外额外拼接一段从外部知识库检索到的相关内容。它的价值在于让模型在生成回答时能“看到”它训练数据里没有的信息。但RAG的效果好坏八成取决于检索质量而不是模型本身。我见过太多项目模型选得很强但检索出来的文档跟问题不相关结果回答照样胡编。做好检索增强有几个关键点切分粒度文档切得太碎检索到的片段缺少上下文切得太粗噪声太多。我的经验是技术文档按段落切每段300到500字比较合适。检索策略纯向量检索适合语义匹配但关键词匹配在专有名词上更准。实际项目中我通常用混合检索——向量加关键词再做一个重排序。拼接方式检索到的片段不要直接堆进去最好加上来源标注和简短说明比如“以下内容来自产品手册第三章”。这样模型更容易判断信息的可靠性。2.4 多模态输入图片、表格、音频怎么进模型现在很多模型支持多模态输入但“支持”和“好用”之间还有距离。图片输入时模型对图中文字的识别能力通常不错但对空间关系、图表趋势的理解还不稳定。表格输入时直接贴截图的效果往往不如把表格转成Markdown或CSV文本再输入。我的建议是如果任务对精度要求高尽量把多模态输入转成文本再喂给模型。比如图表先做数据提取图片先做OCR音频先做转录。模型处理纯文本的稳定性目前还是远高于直接处理原始多模态数据。3. 模型层选型与参数配置的实战判断3.1 模型选型不是越强越好而是越合适越好模型层的第一个决策是选哪个模型。这里最常见的误区是“无脑选最强”。最强模型通常意味着更贵、更慢而且在你具体任务上的提升可能微乎其微。我选模型时主要看四个维度维度说明实际考量任务复杂度简单分类、抽取用中小模型就够复杂推理、长文分析才需要大模型延迟要求实时交互场景对延迟敏感批量处理可以接受慢一点成本预算按token计费量大时差距明显先用大模型跑通再蒸馏到小模型输出格式要求结构化输出对模型指令遵循能力要求高格式严格时选指令遵循强的模型我的常规做法是先用一个中等规模的模型跑基线如果效果不达标再逐步升级。很多时候优化提示词和检索策略带来的提升比换一个更大的模型更明显。3.2 温度与采样控制输出的“随机性旋钮”温度参数控制模型输出的随机性。温度越低输出越确定、越保守温度越高输出越多样、越有创造性。但很多人不知道的是温度不是唯一影响随机性的参数。Top-p和Top-k采样也会影响输出分布。我的经验配置是信息抽取、分类、代码生成温度设0到0.2保证输出稳定可复现。创意写作、头脑风暴温度设0.7到1.0鼓励多样性。对话系统温度设0.3到0.5兼顾稳定性和自然度。有一个容易被忽略的点即使温度设为0输出也不保证完全可复现。因为底层计算存在浮点误差不同批次的推理结果可能有细微差异。如果业务要求严格可复现需要在输出层做额外的规范化处理。3.3 微调什么时候值得做什么时候不值得微调是模型层最“重”的操作。它需要准备数据、训练、评估、部署成本不低。我的判断标准很简单如果提示词工程能做到80分就不要微调如果提示词怎么调都卡在60分再考虑微调。微调真正有价值的场景通常有两类风格对齐你需要模型稳定输出某种特定风格比如固定的客服话术、特定的代码注释格式。提示词能描述风格但微调能让风格更稳定。领域术语你的领域有大量专有名词和特殊表达通用模型经常理解偏差。微调可以让模型更好地适应领域分布。但微调也有风险数据质量差会导致模型学偏过拟合会让模型丧失通用能力。我见过一个项目微调数据里混入了标注错误结果模型在错误的方向上越走越远最后不得不回滚。4. 输出层模型吐出来的东西才是真正决定产品体验的地方4.1 结构化解析让模型输出变成程序能用的数据模型输出的是文本但你的程序需要的是结构化数据。这中间的转换就是输出层最基础也最重要的工作。最常见的做法是让模型输出JSON。但模型输出的JSON经常有问题多了markdown代码块标记、字段名拼写错误、缺少引号、嵌套结构不对。所以解析时不能直接json.loads要先做清洗。我通常的解析流程是用正则提取JSON部分去掉代码块标记和前后多余文字。尝试直接解析。如果失败尝试修复常见问题补引号、去尾逗号、修正括号匹配。如果还失败把原始输出和错误信息一起返回让模型重新生成。更稳妥的做法是使用模型提供的结构化输出功能。现在很多模型支持强制JSON模式输出格式的可靠性会高很多。但即使有强制模式我仍然建议在输出层做校验因为模型偶尔还是会“越狱”。4.2 格式校验与重试别让一次失败毁掉整个流程输出层的校验不只是格式校验还包括业务逻辑校验。比如模型抽取了一个日期字段格式是合法的但日期是“2024年13月45日”这就是业务逻辑错误。我的做法是分两层校验格式校验字段是否存在、类型是否正确、JSON是否合法。业务校验数值范围是否合理、枚举值是否在允许列表内、关联字段是否一致。校验失败时不要直接报错给用户。更好的做法是把校验错误信息拼回提示词让模型重新生成。通常重试一到两次就能得到合格输出。如果连续失败再降级到人工处理或返回默认值。4.3 工具调用输出层最强大的扩展方式工具调用Function Calling的本质是模型输出一个结构化的“调用请求”程序执行这个请求再把结果拼回输入层。这样模型就能完成它本身做不到的事情比如查数据库、发邮件、调外部API。工具调用的关键在于工具描述的设计。模型根据工具描述来判断什么时候调用、传什么参数。如果描述模糊模型要么不调用要么传错参数。我设计工具描述时遵循几个原则名称清晰用动词加名词比如search_orders而不是order_tool。参数说明具体每个参数说明类型、含义、是否必填、示例值。边界明确说明什么情况下应该用这个工具什么情况下不该用。一个实战经验工具数量不要太多。我见过一个项目给模型挂了二十多个工具结果模型经常选错。后来精简到五个核心工具准确率反而提升了。模型的选择能力也是有限的工具越多选择难度越大。4.4 多轮编排把单次输出变成工作流复杂任务往往需要多轮模型调用。比如先让模型做任务规划再逐步执行最后汇总结果。这就是输出层的编排能力。编排的核心是状态管理每一轮的输出要保存下来作为下一轮输入的一部分。同时要定义清楚终止条件避免无限循环。我常用的编排模式有两种线性链任务拆成固定步骤依次执行。适合流程明确的任务比如“先抽取再校验再格式化”。循环加判断模型输出一个动作程序执行后判断是否完成没完成就继续循环。适合探索性任务比如“反复检索直到找到答案”。编排的复杂度要控制。我见过一些项目把编排做得非常复杂结果调试困难、错误难定位。我的建议是能用线性链解决的就不要用循环能两步完成的就不要拆成五步。5. 用三层框架拆解几个常见“新花样”5.1 RAG输入层检索加输出层引用RAG拆开看非常简单输入层多了一步“根据用户问题检索相关文档”输出层多了一步“标注引用来源”。它的核心价值是让模型基于外部知识回答减少胡编。但RAG的难点不在模型而在检索质量。检索不准后面全白搭。所以做RAG项目时我花在文档切分、检索策略、重排序上的时间远多于调模型。5.2 Agent输出层工具调用加循环编排Agent的本质是“模型输出动作程序执行动作结果拼回输入继续下一轮”。它把输出层的工具调用和编排能力结合起来让模型能完成多步任务。但Agent的可靠性目前还是个问题。模型可能选错工具、传错参数、陷入循环。我的经验是Agent适合容错率高的场景比如信息收集、初步筛选。对准确性要求极高的场景还是用固定流程更稳妥。5.3 思维链输入层提示加输出层解析思维链Chain of Thought是在输入层提示模型“一步一步想”然后在输出层解析出最终答案。它的价值在于提升复杂推理任务的准确率。但思维链不是万能的。简单任务加思维链反而浪费token还可能让模型把简单问题想复杂。我的判断标准是如果任务需要多步推理、涉及数值计算或逻辑判断才值得加思维链。5.4 结构化输出输出层的格式控制结构化输出是让模型按指定格式返回数据比如JSON、XML、表格。它的核心在输出层的格式约束和校验。现在很多模型支持强制结构化输出可靠性比早期靠提示词约束高很多。但即使有强制模式我仍然建议在输出层做校验和重试因为模型偶尔还是会“发挥创意”。6. 三层框架的实战价值与常见误区6.1 为什么这个框架能帮你快速判断新技术当你看到一个新概念时用三层框架过一遍它在输入层做了什么是改了提示词结构还是加了检索还是换了上下文组织方式它在输出层做了什么是加了格式校验还是加了工具调用还是加了多轮编排它在模型层做了什么是换了模型还是调了参数还是做了微调如果三层里都没有实质变化那它大概率只是包装。如果有变化你就能快速定位到它真正创新的地方判断是否值得深入。6.2 常见误区一只关注模型层忽略输入输出很多人把大量精力花在“选哪个模型”上却忽略了输入层和输出层的优化。实际上在模型能力已经足够强的今天输入输出层的工程优化往往能带来更大的收益。我做过一个对比实验同一个模型只优化提示词和输出解析准确率从70%提升到90%以上。而换一个更大的模型提升只有几个百分点。输入输出层的优化性价比远高于换模型。6.3 常见误区二把简单问题复杂化三层框架是分析工具不是设计目标。不是每个项目都需要三层都做得很重。简单任务可能只需要一个好的提示词加一个简单的输出解析。过度设计只会增加复杂度和维护成本。我的原则是从最简方案开始遇到问题再逐层加码。先写一个基础提示词跑通效果不够再加检索格式不稳再加校验需要多步再加编排。每一步都问自己这个问题真的需要这一层吗6.4 常见误区三忽略输出层的错误处理输出层是离用户最近的地方也是最容易出问题的地方。模型输出格式错误、内容不合规、工具调用失败这些都需要在输出层处理。我见过一些项目输入层和模型层做得很精致但输出层几乎没有错误处理。结果模型偶尔输出一个格式错误整个流程就崩了。输出层的健壮性直接决定产品的可用性。7. 我在实际项目中的几条经验做过多轮大模型应用之后我最大的体会是这个领域变化很快但底层逻辑变化很慢。新模型、新工具、新框架层出不穷但“控制输入、处理输出”这个核心任务没有变。把三层框架吃透你就能以不变应万变。第二条经验是先跑通再优化。不要一开始就追求完美架构。先用最简单的方案跑通端到端流程看到实际效果再针对瓶颈逐层优化。很多时候你预想的瓶颈和实际瓶颈完全不是一回事。第三条经验是输出层的校验和重试比输入层的提示词优化更值得投入。提示词优化是概率游戏你只能提高模型输出正确的概率。而输出层的校验和重试是确定性保障它能确保即使模型偶尔出错系统整体仍然可靠。最后分享一个实用技巧如果你不确定某个任务该用哪层来解决先问自己“模型缺什么”。缺信息就在输入层补缺格式就在输出层控缺能力才考虑模型层。大部分时候问题都出在输入输出层而不是模型本身。 
长河君 · 2026/10/22 5:12:51 · 阅读 1.2k 大模型应用三层架构：输入层、模型层与输出层实战拆解
1. 为什么“三层架构”是理解大模型应用的万能钥匙很多人第一次接触大模型应用开发时会被各种新名词砸晕RAG、Agent、Function Calling、思维链、多模态、工作流编排……每隔几周就冒出一个新概念感觉永远追不完。但如果你把这些花样全部拆开看会发现一个让人安心的事实几乎所有大模型应用本质上都在做同一件事——控制输入什么以及处理输出怎么用。我把它叫做大模型的“三层架构”。这不是某个官方标准而是我在实际做项目时总结出来的一套思维框架。它足够简单简单到你可以用它去拆解任何一个你看到的新产品又足够深深到每一层里面都有大量工程细节值得反复打磨。先把这个框架摆出来第一层输入层。决定模型看到什么。包括提示词设计、上下文拼接、检索增强、历史对话管理、多模态输入处理等。第二层模型层。决定模型怎么想。包括模型选型、参数配置、推理策略、微调与对齐等。第三层输出层。决定模型的结果怎么用。包括结构化解析、格式校验、后处理、工具调用、多轮编排等。这三层里模型层的变化其实是最慢的——底层能力由少数几家机构推动普通开发者能做的微调空间有限。而输入层和输出层才是绝大多数应用创新真正发生的地方。你看到的每一个“新花样”几乎都可以归到这两层的某个组合里。举个例子。RAG看起来很复杂但拆开看就是输入层多了一步“检索相关文档拼进上下文”输出层多了一步“引用来源标注”。Agent看起来更玄乎拆开看就是输出层解析出“要调用某个工具”然后把工具结果再拼回输入层循环往复。Function Calling、结构化输出、思维链提示全部都能放进这个框架里。所以这篇文章的目的很明确给你一套可以反复使用的拆解工具。下次再看到什么新概念你不用慌先问两个问题——它在输入层做了什么它在输出层做了什么想清楚这两个问题你就能判断它到底有没有新东西值不值得花时间学。这套框架特别适合两类人一是刚入行、被各种术语搞得焦虑的开发者二是需要做技术选型、但不想被厂商宣传牵着走的团队负责人。2. 输入层模型看到什么比模型本身更决定结果2.1 提示词不是“随便写写”而是输入层的核心工程很多人对提示词的理解还停留在“写一段话让模型干活”。但在我做过的项目里提示词设计是输入层最需要花时间的地方没有之一。同一个模型提示词差一个结构输出质量可能差出两个档次。我习惯把提示词拆成四个部分来设计角色设定告诉模型“你是谁”。比如“你是一名有十年经验的合同审核律师”。这一步的作用是激活模型在预训练阶段学到的相关领域分布。任务描述明确“要做什么”。越具体越好避免“帮我分析一下”这种模糊指令。约束条件规定“不能做什么”和“必须怎么做”。比如“只输出JSON格式”“不要编造数据”“如果信息不足直接说不知道”。示例给一两个输入输出样例。这一步对格式要求高的任务特别有效模型会模仿示例的结构。这里有一个我踩过的坑早期做信息抽取时我花大量时间调模型参数效果一直不稳定。后来发现问题出在提示词里任务描述太模糊模型每次理解的“抽取粒度”都不一样。把任务描述改成“抽取以下字段每个字段如果原文没有明确提及填null”准确率立刻上了一个台阶。提示词工程的核心不是“写得漂亮”而是“消除歧义”。你每消除一个歧义模型输出就稳定一分。2.2 上下文拼接把什么塞进窗口是一门取舍艺术大模型的上下文窗口是有限的。即使现在有些模型支持很长的上下文但“能塞进去”和“塞进去有用”是两回事。上下文越长模型对中间部分的注意力越容易稀释这是目前架构决定的。所以输入层的第二个关键问题是在有限的窗口里放什么、不放什么、怎么排序。我通常按优先级来组织上下文系统指令放在最前面定义角色和硬约束。当前任务相关的核心信息比如用户问题、检索到的关键文档片段。少量历史对话只保留最近几轮或者只保留与当前问题相关的轮次。示例如果任务格式要求高放一两个示例在任务描述后面。这里有个实用技巧如果你发现模型“忘记”了前面的指令不一定是模型能力问题很可能是上下文太长导致注意力分散。解决办法不是换模型而是精简上下文——把不必要的历史对话删掉把长文档先做摘要再拼进去。2.3 检索增强输入层最实用的“外挂”RAG本质上就是输入层的一个扩展在用户问题之外额外拼接一段从外部知识库检索到的相关内容。它的价值在于让模型在生成回答时能“看到”它训练数据里没有的信息。但RAG的效果好坏八成取决于检索质量而不是模型本身。我见过太多项目模型选得很强但检索出来的文档跟问题不相关结果回答照样胡编。做好检索增强有几个关键点切分粒度文档切得太碎检索到的片段缺少上下文切得太粗噪声太多。我的经验是技术文档按段落切每段300到500字比较合适。检索策略纯向量检索适合语义匹配但关键词匹配在专有名词上更准。实际项目中我通常用混合检索——向量加关键词再做一个重排序。拼接方式检索到的片段不要直接堆进去最好加上来源标注和简短说明比如“以下内容来自产品手册第三章”。这样模型更容易判断信息的可靠性。2.4 多模态输入图片、表格、音频怎么进模型现在很多模型支持多模态输入但“支持”和“好用”之间还有距离。图片输入时模型对图中文字的识别能力通常不错但对空间关系、图表趋势的理解还不稳定。表格输入时直接贴截图的效果往往不如把表格转成Markdown或CSV文本再输入。我的建议是如果任务对精度要求高尽量把多模态输入转成文本再喂给模型。比如图表先做数据提取图片先做OCR音频先做转录。模型处理纯文本的稳定性目前还是远高于直接处理原始多模态数据。3. 模型层选型与参数配置的实战判断3.1 模型选型不是越强越好而是越合适越好模型层的第一个决策是选哪个模型。这里最常见的误区是“无脑选最强”。最强模型通常意味着更贵、更慢而且在你具体任务上的提升可能微乎其微。我选模型时主要看四个维度维度说明实际考量任务复杂度简单分类、抽取用中小模型就够复杂推理、长文分析才需要大模型延迟要求实时交互场景对延迟敏感批量处理可以接受慢一点成本预算按token计费量大时差距明显先用大模型跑通再蒸馏到小模型输出格式要求结构化输出对模型指令遵循能力要求高格式严格时选指令遵循强的模型我的常规做法是先用一个中等规模的模型跑基线如果效果不达标再逐步升级。很多时候优化提示词和检索策略带来的提升比换一个更大的模型更明显。3.2 温度与采样控制输出的“随机性旋钮”温度参数控制模型输出的随机性。温度越低输出越确定、越保守温度越高输出越多样、越有创造性。但很多人不知道的是温度不是唯一影响随机性的参数。Top-p和Top-k采样也会影响输出分布。我的经验配置是信息抽取、分类、代码生成温度设0到0.2保证输出稳定可复现。创意写作、头脑风暴温度设0.7到1.0鼓励多样性。对话系统温度设0.3到0.5兼顾稳定性和自然度。有一个容易被忽略的点即使温度设为0输出也不保证完全可复现。因为底层计算存在浮点误差不同批次的推理结果可能有细微差异。如果业务要求严格可复现需要在输出层做额外的规范化处理。3.3 微调什么时候值得做什么时候不值得微调是模型层最“重”的操作。它需要准备数据、训练、评估、部署成本不低。我的判断标准很简单如果提示词工程能做到80分就不要微调如果提示词怎么调都卡在60分再考虑微调。微调真正有价值的场景通常有两类风格对齐你需要模型稳定输出某种特定风格比如固定的客服话术、特定的代码注释格式。提示词能描述风格但微调能让风格更稳定。领域术语你的领域有大量专有名词和特殊表达通用模型经常理解偏差。微调可以让模型更好地适应领域分布。但微调也有风险数据质量差会导致模型学偏过拟合会让模型丧失通用能力。我见过一个项目微调数据里混入了标注错误结果模型在错误的方向上越走越远最后不得不回滚。4. 输出层模型吐出来的东西才是真正决定产品体验的地方4.1 结构化解析让模型输出变成程序能用的数据模型输出的是文本但你的程序需要的是结构化数据。这中间的转换就是输出层最基础也最重要的工作。最常见的做法是让模型输出JSON。但模型输出的JSON经常有问题多了markdown代码块标记、字段名拼写错误、缺少引号、嵌套结构不对。所以解析时不能直接json.loads要先做清洗。我通常的解析流程是用正则提取JSON部分去掉代码块标记和前后多余文字。尝试直接解析。如果失败尝试修复常见问题补引号、去尾逗号、修正括号匹配。如果还失败把原始输出和错误信息一起返回让模型重新生成。更稳妥的做法是使用模型提供的结构化输出功能。现在很多模型支持强制JSON模式输出格式的可靠性会高很多。但即使有强制模式我仍然建议在输出层做校验因为模型偶尔还是会“越狱”。4.2 格式校验与重试别让一次失败毁掉整个流程输出层的校验不只是格式校验还包括业务逻辑校验。比如模型抽取了一个日期字段格式是合法的但日期是“2024年13月45日”这就是业务逻辑错误。我的做法是分两层校验格式校验字段是否存在、类型是否正确、JSON是否合法。业务校验数值范围是否合理、枚举值是否在允许列表内、关联字段是否一致。校验失败时不要直接报错给用户。更好的做法是把校验错误信息拼回提示词让模型重新生成。通常重试一到两次就能得到合格输出。如果连续失败再降级到人工处理或返回默认值。4.3 工具调用输出层最强大的扩展方式工具调用Function Calling的本质是模型输出一个结构化的“调用请求”程序执行这个请求再把结果拼回输入层。这样模型就能完成它本身做不到的事情比如查数据库、发邮件、调外部API。工具调用的关键在于工具描述的设计。模型根据工具描述来判断什么时候调用、传什么参数。如果描述模糊模型要么不调用要么传错参数。我设计工具描述时遵循几个原则名称清晰用动词加名词比如search_orders而不是order_tool。参数说明具体每个参数说明类型、含义、是否必填、示例值。边界明确说明什么情况下应该用这个工具什么情况下不该用。一个实战经验工具数量不要太多。我见过一个项目给模型挂了二十多个工具结果模型经常选错。后来精简到五个核心工具准确率反而提升了。模型的选择能力也是有限的工具越多选择难度越大。4.4 多轮编排把单次输出变成工作流复杂任务往往需要多轮模型调用。比如先让模型做任务规划再逐步执行最后汇总结果。这就是输出层的编排能力。编排的核心是状态管理每一轮的输出要保存下来作为下一轮输入的一部分。同时要定义清楚终止条件避免无限循环。我常用的编排模式有两种线性链任务拆成固定步骤依次执行。适合流程明确的任务比如“先抽取再校验再格式化”。循环加判断模型输出一个动作程序执行后判断是否完成没完成就继续循环。适合探索性任务比如“反复检索直到找到答案”。编排的复杂度要控制。我见过一些项目把编排做得非常复杂结果调试困难、错误难定位。我的建议是能用线性链解决的就不要用循环能两步完成的就不要拆成五步。5. 用三层框架拆解几个常见“新花样”5.1 RAG输入层检索加输出层引用RAG拆开看非常简单输入层多了一步“根据用户问题检索相关文档”输出层多了一步“标注引用来源”。它的核心价值是让模型基于外部知识回答减少胡编。但RAG的难点不在模型而在检索质量。检索不准后面全白搭。所以做RAG项目时我花在文档切分、检索策略、重排序上的时间远多于调模型。5.2 Agent输出层工具调用加循环编排Agent的本质是“模型输出动作程序执行动作结果拼回输入继续下一轮”。它把输出层的工具调用和编排能力结合起来让模型能完成多步任务。但Agent的可靠性目前还是个问题。模型可能选错工具、传错参数、陷入循环。我的经验是Agent适合容错率高的场景比如信息收集、初步筛选。对准确性要求极高的场景还是用固定流程更稳妥。5.3 思维链输入层提示加输出层解析思维链Chain of Thought是在输入层提示模型“一步一步想”然后在输出层解析出最终答案。它的价值在于提升复杂推理任务的准确率。但思维链不是万能的。简单任务加思维链反而浪费token还可能让模型把简单问题想复杂。我的判断标准是如果任务需要多步推理、涉及数值计算或逻辑判断才值得加思维链。5.4 结构化输出输出层的格式控制结构化输出是让模型按指定格式返回数据比如JSON、XML、表格。它的核心在输出层的格式约束和校验。现在很多模型支持强制结构化输出可靠性比早期靠提示词约束高很多。但即使有强制模式我仍然建议在输出层做校验和重试因为模型偶尔还是会“发挥创意”。6. 三层框架的实战价值与常见误区6.1 为什么这个框架能帮你快速判断新技术当你看到一个新概念时用三层框架过一遍它在输入层做了什么是改了提示词结构还是加了检索还是换了上下文组织方式它在输出层做了什么是加了格式校验还是加了工具调用还是加了多轮编排它在模型层做了什么是换了模型还是调了参数还是做了微调如果三层里都没有实质变化那它大概率只是包装。如果有变化你就能快速定位到它真正创新的地方判断是否值得深入。6.2 常见误区一只关注模型层忽略输入输出很多人把大量精力花在“选哪个模型”上却忽略了输入层和输出层的优化。实际上在模型能力已经足够强的今天输入输出层的工程优化往往能带来更大的收益。我做过一个对比实验同一个模型只优化提示词和输出解析准确率从70%提升到90%以上。而换一个更大的模型提升只有几个百分点。输入输出层的优化性价比远高于换模型。6.3 常见误区二把简单问题复杂化三层框架是分析工具不是设计目标。不是每个项目都需要三层都做得很重。简单任务可能只需要一个好的提示词加一个简单的输出解析。过度设计只会增加复杂度和维护成本。我的原则是从最简方案开始遇到问题再逐层加码。先写一个基础提示词跑通效果不够再加检索格式不稳再加校验需要多步再加编排。每一步都问自己这个问题真的需要这一层吗6.4 常见误区三忽略输出层的错误处理输出层是离用户最近的地方也是最容易出问题的地方。模型输出格式错误、内容不合规、工具调用失败这些都需要在输出层处理。我见过一些项目输入层和模型层做得很精致但输出层几乎没有错误处理。结果模型偶尔输出一个格式错误整个流程就崩了。输出层的健壮性直接决定产品的可用性。7. 我在实际项目中的几条经验做过多轮大模型应用之后我最大的体会是这个领域变化很快但底层逻辑变化很慢。新模型、新工具、新框架层出不穷但“控制输入、处理输出”这个核心任务没有变。把三层框架吃透你就能以不变应万变。第二条经验是先跑通再优化。不要一开始就追求完美架构。先用最简单的方案跑通端到端流程看到实际效果再针对瓶颈逐层优化。很多时候你预想的瓶颈和实际瓶颈完全不是一回事。第三条经验是输出层的校验和重试比输入层的提示词优化更值得投入。提示词优化是概率游戏你只能提高模型输出正确的概率。而输出层的校验和重试是确定性保障它能确保即使模型偶尔出错系统整体仍然可靠。最后分享一个实用技巧如果你不确定某个任务该用哪层来解决先问自己“模型缺什么”。缺信息就在输入层补缺格式就在输出层控缺能力才考虑模型层。大部分时候问题都出在输入输出层而不是模型本身。