1. 为什么“三层架构”是理解大模型应用的万能钥匙很多人第一次接触大模型应用开发时会被各种新名词砸晕RAG、Agent、Function Calling、思维链、多模态、工作流编排……每隔几周就冒出一个新框架仿佛不跟上就要被淘汰。但如果你把这些花样全部拆开看会发现它们折腾来折腾去本质上只动了三个地方输入侧做了什么加工、模型中间怎么被调用、输出侧怎么被处理和消费。这就是我所说的“三层架构”——输入层、模型层、输出层。这个视角的价值在于它把看似无穷无尽的新概念收敛成一个有限的分析框架。你不再需要追着每一个新框架跑而是问自己三个问题——它在输入层加了什么它在模型层做了什么调度它在输出层做了什么后处理三个问题问完一个陌生技术的底裤基本就被扒干净了。我拿几个热门概念做个快速验证。RAG检索增强生成拆开看就是输入层把用户问题拿去向量库检索把命中片段拼进提示词模型层正常调用输出层基本不动。Agent智能体输入层可能做任务分解模型层做多轮循环调用并决定何时调用工具输出层解析工具调用结果再喂回去。思维链CoT输入层在提示词里加“让我们一步步思考”模型层生成中间推理步骤输出层把最终答案提取出来。Function Calling输入层把工具描述塞进系统提示模型层输出结构化调用意图输出层执行真实函数并把结果回传。你看没有一个逃得出这三层。所以这篇文章我不打算讲某个具体框架怎么用而是把这套拆解方法讲透让你以后遇到任何新东西都能自己拆。适合谁看适合已经用过大模型API、但面对层出不穷的新概念感到焦虑的开发者也适合想从“调API”进阶到“设计系统”的工程师。读完你至少能做到看到一个陌生的大模型应用方案五分钟内判断出它的核心创新点在哪一层以及它可能在哪里翻车。2. 输入层决定模型上限的隐形战场2.1 输入层到底在加工什么输入层的本质工作只有一件事把人类的意图翻译成模型能高效理解的token序列。听起来简单但这里藏着整个应用效果的天花板。模型再强你喂进去的东西是垃圾出来的也是垃圾——这就是所谓的“垃圾进垃圾出”。输入层的加工手段可以分成几个层次。最基础的是提示词工程系统提示定义角色和约束用户提示提供具体任务少样本示例给出格式参考。再往上一层是上下文组装把检索到的文档、历史对话、工具描述、记忆片段按优先级拼进有限的上下文窗口。更复杂的是输入预处理把图片转成模型能吃的描述、把长文档切块并排序、把结构化数据序列化成自然语言。我见过太多项目在输入层偷懒直接把用户输入原封不动丢给模型然后抱怨效果不稳定。实际上输入层每多花一分功夫输出层的返工就少十分。一个典型的例子是用户问“帮我看看这个合同有没有风险”如果你直接把这句话丢给模型它会给你一堆泛泛而谈。但如果你在输入层做几件事——把合同文本附上、指定审查维度付款条款、违约责任、知识产权、给出输出格式要求——效果立刻天差地别。2.2 上下文窗口的分配是一场零和博弈所有输入层加工最终都要塞进模型的上下文窗口而窗口是有限的。这就带来一个核心矛盾你想塞的信息永远比窗口能装的多。所以输入层设计的本质是在有限预算下做优先级排序。我通常把上下文预算分成几块来管理。系统提示和角色定义是固定开销尽量精简能一句话说清就别用三句。少样本示例很占地方但效果显著一般放2到3个高质量示例就够多了边际收益递减。检索内容是最不可控的需要根据问题动态决定召回数量和片段长度。历史对话要定期做摘要压缩不能无限堆积。这里有个实操技巧给每一块内容打上优先级标签当总长度超限时从低优先级开始裁剪。比如系统提示优先级最高绝对不能裁检索内容优先级中等可以只保留最相关的几条历史对话优先级最低可以压缩成摘要。我见过一个项目因为没做这个把系统提示挤掉了模型直接“失忆”表现完全不可控。提示上下文窗口不是越大越好。窗口越大模型对中间内容的注意力越容易稀释这就是所谓的“迷失在中间”现象。关键信息尽量放在开头或结尾。2.3 检索增强的输入层陷阱RAG是输入层最典型的应用但也是最容易踩坑的地方。很多人以为RAG就是“向量检索拼进提示词”结果上线后发现模型经常答非所问。问题往往出在输入层的几个细节上。第一个陷阱是切块策略。把文档按固定字数切块会把一个完整的语义单元切碎检索出来的片段缺头少尾模型看不懂。我的经验是按语义边界切——段落、章节、标题层级而不是按字数。如果必须按字数至少加一些重叠让相邻块有上下文衔接。第二个陷阱是检索结果直接拼接。检索出来的几个片段可能互相矛盾、重复、或者顺序混乱。直接拼进去模型会困惑。正确做法是去重、按相关性排序、必要时加一句“以下资料按相关性排序”来引导模型。第三个陷阱是没有告诉模型怎么用检索内容。如果你只是把片段丢进去模型可能把它当成普通对话内容而不是“参考资料”。系统提示里要明确说“请基于以下参考资料回答如果资料中没有相关信息请明确说明不知道。”这一句话能大幅降低幻觉率。2.4 输入层的工程化实践在实际项目里输入层通常需要一套独立的处理管线。我一般会把它拆成几个模块意图识别模块判断用户想干什么上下文管理模块负责组装和裁剪检索模块负责召回相关内容格式化模块负责把一切拼成最终提示词。这套管线的好处是可测试、可替换。比如你想换一个检索方案只需要替换检索模块其他不动。你想调整提示词模板只改格式化模块。我见过把所有逻辑写在一个大函数里的项目改一处崩三处维护成本极高。还有一个容易被忽略的点输入层要做输入校验和清洗。用户可能输入超长文本、特殊字符、注入攻击。输入层是第一道防线该截断的截断该转义的转义该拒绝的拒绝。别等到模型输出了奇怪内容才回头查那时候已经晚了。3. 模型层调度逻辑才是真正的技术活3.1 模型层不只是“调个API”很多人对模型层的理解就是“把提示词发给模型拿回结果”。如果只是这样那确实没什么好讲的。但当你开始做复杂应用时模型层就变成了一个调度中心什么时候调模型、调哪个模型、调几次、每次给什么参数、拿到结果后怎么决定下一步。举个最简单的例子单轮问答只需要调一次模型。但如果是多轮对话你需要管理对话历史每次把历史一起发过去。如果是Agent你可能需要调多次模型每次根据上一步的结果决定下一步动作。如果是多模型协作你可能先调一个小模型做意图分类再调一个大模型做复杂推理最后调一个专用模型做格式化输出。模型层的核心问题就一个如何用最少的调用次数和最低的成本拿到最符合要求的结果。这里面全是权衡。3.2 模型选型不是越贵越好模型选型是模型层最基础的决策。市面上的模型从轻量到旗舰价格能差几十倍。很多人一上来就用最贵的结果成本爆炸也有人为了省钱全用最便宜的结果效果惨不忍睹。我的经验是按任务难度分层。简单任务——意图分类、实体抽取、格式转换——用轻量模型完全够速度快、成本低。中等任务——摘要、改写、简单问答——用中档模型。复杂任务——多步推理、代码生成、长文分析——才需要旗舰模型。这里有个实操技巧先用旗舰模型跑一批样本建立效果基线然后逐步降级到更便宜的模型看效果下降是否可接受。很多时候你会发现某个任务用轻量模型能达到旗舰模型90%的效果但成本只有十分之一。这个降级测试是模型选型的标准动作别凭感觉选。还有一个维度是延迟。有些场景对响应速度要求高比如实时对话这时候轻量模型的优势就出来了。旗舰模型虽然强但慢用户等不起。所以选型要同时看效果、成本、延迟三个维度没有单一最优解。3.3 多轮调用的编排逻辑当任务复杂到一次模型调用搞不定时就需要多轮编排。这是模型层最有技术含量的部分。常见的编排模式有几种。链式调用把任务拆成顺序步骤上一步的输出是下一步的输入。比如先让模型提取关键信息再让模型基于关键信息生成报告。这种模式简单可控但错误会累积前面错了后面全错。路由调用先让模型判断任务类型再路由到对应的处理流程。比如用户提问后先分类是“查询类”还是“操作类”查询类走检索操作类走工具调用。这种模式灵活但路由判断本身可能出错。循环调用模型输出一个动作执行后把结果喂回去直到模型认为任务完成。Agent就是典型。这种模式最强但也最不可控容易陷入死循环或者跑偏。我一般会设置最大循环次数和超时防止失控。并行调用把独立子任务同时发给多个模型最后汇总结果。比如同时让模型从多个角度分析一个问题再综合。这种模式快但汇总逻辑要设计好不然就是一堆碎片。3.4 模型层的成本控制与缓存策略模型调用是要花钱的尤其是旗舰模型。一个没控制好成本的应用可能一个月烧掉几万块。模型层的成本控制有几个抓手。缓存是最直接的。相同的输入没必要重复调用把结果缓存起来下次直接返回。但要注意缓存键要设计好不能只按用户输入缓存因为同样的输入在不同上下文下可能需要不同结果。我一般会把系统提示、上下文摘要、用户输入一起做哈希作为缓存键。批处理是另一个抓手。如果有大量独立请求可以攒一批一起发很多模型API支持批量调用单价更低。适合离线任务不适合实时交互。Token控制也很关键。输出长度要设上限别让模型无限生成。输入侧也要精简前面输入层做的裁剪工作这里直接体现为成本节省。降级策略是兜底。当预算快用完或者服务不稳定时自动降级到更便宜的模型保证服务不中断。这个策略要提前设计好别等出事了才手忙脚乱。3.5 模型层的可观测性模型层是黑盒你只能看到输入和输出中间发生了什么不知道。所以可观测性特别重要。我一般会记录每次调用的输入token数、输出token数、耗时、模型版本、温度参数、以及完整的输入输出内容。这些日志在排查问题时是救命稻草。比如用户反馈“模型答得不对”你可以翻日志看当时到底发了什么、回了什么。没有日志你只能靠猜。我见过一个项目因为没记日志一个偶发bug查了两周都没定位最后只能靠复现碰运气。还有一个进阶做法是采样评估。定期从日志里抽样人工评估输出质量建立质量基线。一旦发现质量下降能快速定位是模型更新了、还是输入分布变了、还是检索出了问题。这套机制在长期运营中价值巨大。4. 输出层被严重低估的价值洼地4.1 输出层为什么重要大部分人的注意力都在输入层和模型层输出层往往被当成“把结果展示出来”的简单环节。但实际上输出层是用户体验的最终交付点也是很多应用差异化的关键。模型输出的原始文本往往不能直接用。它可能格式不对、可能包含多余内容、可能语气不合适、可能长度超标。输出层的任务就是把这些原始输出加工成用户真正需要的东西。这个加工过程做得好不好直接决定用户觉得你的应用“专业”还是“业余”。我举个简单的例子。用户问“帮我总结这篇文章”模型输出了一段200字的摘要。如果你直接把这段文字显示出来用户觉得还行。但如果你在输出层做几件事提取关键要点做成列表、标注原文对应位置、提供一键复制按钮、根据用户偏好调整长度——体验立刻上一个台阶。同样的模型输出输出层加工不同产品感完全不同。4.2 结构化输出的解析与校验当模型需要输出结构化数据时输出层的解析和校验就至关重要。比如你让模型输出JSON它可能输出带markdown代码块的JSON、可能字段名拼错、可能漏字段、可能类型不对。这些都需要输出层来处理。我的做法是解析、校验、修复三步走。解析就是尝试把文本转成结构化对象容忍常见的格式偏差比如去掉代码块标记、处理尾随逗号。校验就是检查必需字段是否存在、类型是否正确、值是否在允许范围内。修复就是当校验失败时尝试自动修正或者重新调用模型。这里有个关键决策校验失败时是重试还是降级。如果重试成本低且成功率高就重试如果重试也大概率失败就降级到默认值或者提示用户。我一般会设置重试次数上限超过就降级避免无限重试拖垮系统。还有一种做法是用模型做输出校验。让另一个模型检查第一个模型的输出是否符合要求不符合就打回重做。这个方案成本高但效果好适合对准确性要求极高的场景。4.3 输出格式的适配与美化同一个模型输出面向不同渠道需要不同格式。面向网页要HTML面向移动端要简洁文本面向API要JSON面向邮件要正式格式。输出层要负责这些适配。我一般会定义一个中间表示把模型输出先转成这个中间表示再根据目标渠道渲染。中间表示包含内容结构、关键信息、元数据。这样新增一个输出渠道只需要写一个渲染器不用改核心逻辑。美化方面有几个细节很影响体验。换行和分段模型输出经常是一大段需要根据语义拆成段落。重点标注把关键信息加粗或高亮方便快速抓取。长度控制根据场景截断或展开比如列表页显示摘要详情页显示全文。语气调整根据用户画像调整正式程度对专业用户用术语对普通用户用大白话。4.4 输出层的安全过滤与合规检查输出层是最后一道防线必须做安全过滤。模型可能输出不当内容可能泄露敏感信息可能包含偏见。这些都要在输出层拦截。我的做法是多层过滤。第一层是关键词过滤快速拦截明显违规内容。第二层是模型审核用专门的审核模型判断内容是否合规。第三层是人工抽检定期检查过滤效果。三层叠加漏网之鱼很少。还有一个容易被忽略的点是输出一致性。同一个问题问两次模型可能给出不同答案。如果应用需要稳定输出输出层要做一致性处理比如缓存首次结果、或者对多次结果做投票。这个在客服、教育等场景特别重要。4.5 输出层的反馈闭环输出层还是收集用户反馈的最佳位置。用户对结果的评价——点赞、点踩、修改、复制——都是宝贵的信号。这些信号可以用来优化输入层的提示词、调整模型层的选型、改进输出层的加工逻辑。我一般会在输出层埋几个反馈点结果旁边放点赞点踩按钮用户修改输出时记录修改前后对比用户复制内容时记录复制了哪部分。这些数据积累起来就是持续优化的燃料。没有反馈闭环的应用只能靠猜来迭代效率极低。5. 三层架构的联动新花样到底新在哪5.1 用三层框架拆解常见应用模式现在回到开头的问题所有AI新花样到底新在哪我用三层框架拆几个典型模式你就能看出规律。RAG输入层做检索和上下文组装模型层单次调用输出层基本不动。创新点在输入层。Agent输入层做任务描述模型层多轮循环调用并决策输出层解析动作结果。创新点在模型层的调度逻辑。Function Calling输入层塞工具描述模型层输出结构化调用意图输出层执行函数并回传。创新点在模型层和输出层的配合。多模态输入层把图片/音频转成模型能处理的表示模型层正常调用输出层可能生成多模态内容。创新点在输入层和输出层。工作流编排输入层定义流程模型层按流程调度多个模型输出层汇总结果。创新点在模型层的编排。你看每个新模式都是在某一层做了加强或者打通了层与层之间的新连接。没有哪个模式是凭空出现的。掌握这个框架你看到新概念时就不会慌直接问它动了哪一层5.2 层与层之间的接口设计三层架构要跑通层与层之间的接口设计很关键。输入层输出的是标准化的提示词和参数模型层输出的是原始模型响应和元数据输出层输出的是面向用户的最终内容。每个接口都要定义清楚数据格式和错误处理。我一般会用数据类来定义这些接口而不是用字典。数据类有类型检查能提前发现字段缺失或类型错误。而且数据类自文档化新人接手时一看就懂。这个投入在项目变大后回报巨大。接口设计还有一个原则层与层之间尽量解耦。输入层不应该知道模型层用的是哪个模型模型层不应该知道输出层要渲染成什么格式。这样任何一层换实现其他层不受影响。我见过输入层直接拼特定模型的特殊token的项目换模型时整个输入层重写痛苦不堪。5.3 三层各自的测试策略三层架构的另一个好处是测试可以分层做。输入层测试提示词组装是否正确、检索是否召回相关片段、上下文裁剪是否符合预期。模型层测试调用参数是否正确、多轮编排逻辑是否符合预期、错误处理是否到位。输出层测试解析是否正确、格式适配是否符合目标、安全过滤是否生效。分层测试的好处是定位问题快。效果不好时先看输入层日志再看模型层日志再看输出层日志一层层排查很快能定位到是哪层的问题。如果所有逻辑混在一起只能整体调试效率低得多。我一般会为每层写单元测试再用端到端测试验证整体流程。单元测试跑得快改代码后立刻能验证。端到端测试跑得慢但能发现层间集成问题。两者结合质量有保障。5.4 从三层视角看技术选型技术选型时三层框架也能帮你做决策。比如选向量数据库这是输入层的事重点看检索效果和速度。选模型这是模型层的事重点看效果、成本、延迟。选前端框架这是输出层的事重点看渲染能力和交互体验。把选型问题归到具体层决策就清晰了。你不会因为一个输出层的问题去换模型也不会因为一个输入层的问题去换前端。各层的问题各层解决不混为一谈。还有一个好处是团队分工。三层可以对应三个小组输入层组、模型层组、输出层组。接口定义清楚后各组并行开发互不阻塞。当然小团队可能一个人全包但心里有这三层的划分代码结构也会更清晰。6. 实操中的踩坑记录与经验沉淀6.1 输入层踩过的坑坑一提示词里塞了太多规则模型反而记不住。我曾经在一个系统提示里写了二十多条规则结果模型经常违反其中几条。后来精简到五条核心规则违反率大幅下降。教训是规则要少而精重要的放前面次要的能删就删。坑二检索片段直接拼接没有去重和排序。有一次检索出来五个片段其中三个内容高度重复模型被重复信息误导给出了错误答案。后来加了去重和相关性排序问题解决。教训是检索结果不能直接用要加工。坑三上下文超限时粗暴截断把关键信息截掉了。有一次系统提示太长加上检索内容超了窗口代码直接从尾部截断结果把系统提示截掉了一半模型完全跑偏。后来改成按优先级裁剪低优先级先删。教训是裁剪要有策略不能一刀切。6.2 模型层踩过的坑坑一所有任务都用旗舰模型成本失控。项目上线第一个月账单出来比预期高了五倍。排查发现很多简单任务也在用旗舰模型。后来做了任务分级简单任务降级到轻量模型成本降了七成效果几乎没变。教训是模型选型要分层别一把梭。坑二多轮循环没有设上限陷入死循环。一个Agent任务因为工具返回了意外结果模型反复尝试同一个动作循环了上百次烧了大量token。后来加了最大循环次数和超时问题解决。教训是循环必须有刹车。坑三没有记录调用日志问题无法定位。用户反馈效果不稳定但因为没有日志不知道当时发了什么回了什么只能靠猜。后来补了详细日志问题很快定位到是某个检索源不稳定。教训是日志是生命线越早加越好。6.3 输出层踩过的坑坑一直接展示模型原始输出格式混乱。模型输出的markdown有时候渲染正常有时候乱掉用户体验很差。后来加了输出清洗和格式标准化稳定多了。教训是原始输出不能直接给用户看。坑二结构化输出解析失败没有兜底。模型偶尔输出不合法的JSON解析直接抛异常整个请求失败。后来加了容错解析和降级策略解析失败时返回原始文本并提示用户。教训是解析要容错不能假设模型永远输出正确格式。坑三安全过滤太严误杀正常内容。关键词过滤把一些正常讨论也拦了用户抱怨很多。后来改成关键词加模型审核双层过滤误杀率大幅下降。教训是安全过滤要平衡不能一刀切。6.4 三层联动的经验总结经验一先跑通再优化别一开始就追求完美架构。我见过团队花两个月设计完美架构结果还没上线。先用最简单的方式跑通再根据实际问题逐层优化效率高得多。经验二每层都要有降级方案。输入层检索失败时用缓存或默认提示模型层调用失败时用备用模型输出层解析失败时返回原始内容。任何一层挂了整体还能提供基本服务。经验三监控要覆盖三层。输入层的token数、检索命中率模型层的调用次数、耗时、成本输出层的解析成功率、用户反馈。三层数据一起看才能全面掌握系统状态。经验四定期回顾三层设计。业务在变模型在更新三层设计也要跟着调整。我一般每季度回顾一次看看有没有哪层成了瓶颈有没有新的技术可以引入。保持架构的生命力。这套三层框架我用了很久最大的感受是它不能帮你写出代码但能帮你想清楚问题。面对任何大模型应用需求先问三层各做什么再动手返工率会低很多。新花样还会继续出现但只要你手里有这把拆解的刀就不会被名词吓住。
