1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起这两年AI圈的新概念几乎是以周为单位往外冒。今天某个团队发布了新的智能体框架明天又有人搞出了新的记忆机制后天满屏都是某个推理增强方案。很多做开发的朋友跟我聊的时候都会有一个共同的困惑这些东西看起来五花八门但底层到底有没有一个统一的框架能把它们串起来我自己的答案是有的而且这个框架比大多数人想象的要简单。你把市面上几乎所有大模型应用的新花样拆开来看会发现它们本质上都在做三件事中的一件或几件改变输入给模型的内容、改变模型输出的处理方式、或者在模型调用前后增加编排逻辑。真正去改模型本身权重和结构的少之又少绝大多数所谓的“新架构”“新范式”拆到最底层动的都是输入和输出这两端。这个认知对我帮助极大。以前看到一个新框架我会花很多时间去读它的论文和源码试图理解它到底“新”在哪里。现在我会先问三个问题它改了输入吗它改了输出吗它改了中间的编排流程吗大部分情况下五分钟就能定位到它的核心创新点然后判断这个东西对我当前的项目有没有实际价值。1.2 三层架构的分层逻辑我习惯把大模型应用拆成三层来看这个分法不是学术上的严格定义而是从工程落地角度出发的实用划分。最底层是模型层也就是那个真正做推理的大模型本身。这一层包括基座模型的选择、微调策略、量化方案、推理引擎的配置等。这一层的特点是门槛高、成本大、迭代慢。除非你是做基础模型研究的团队否则大部分开发者在这一层的操作空间其实很有限主要就是选型和调参。中间层是编排层负责协调模型调用和外部工具之间的交互。这一层包括提示词模板管理、工具调用路由、多步推理链的编排、状态管理、错误重试等。这一层是大多数应用框架真正发力的地方也是“智能体”“工作流”这些概念的主战场。最上层是交互层处理的是用户输入怎么变成模型能吃的格式以及模型输出怎么变成用户能用的结果。这一层包括输入解析、上下文组装、输出格式化、结果校验、流式渲染等。看起来简单但实际上大量所谓的“新花样”都发生在这里。三层之间的关系可以用一个简单的类比来理解模型层是发动机编排层是变速箱和传动系统交互层是方向盘和仪表盘。用户感受到的驾驶体验很大程度上取决于后两层的设计而不是发动机本身有多强。1.3 为什么这个拆法能解释大部分新花样拿几个具体的例子来说明。检索增强生成本质上是在输入侧做文章——在用户问题前面拼接检索到的相关文档让模型有更多上下文可以参考。它的核心创新不在模型而在“检索什么、怎么检索、检索结果怎么拼进提示词”这些输入侧的处理逻辑。思维链推理本质上是在输出侧做文章——让模型先输出推理步骤再输出最终答案然后通过解析这些步骤来做校验或后续处理。模型本身没变变的是我们怎么引导它输出以及怎么处理它的输出。工具调用和函数调用本质上是在编排层做文章——模型输出一个结构化的调用请求编排层负责执行这个调用并把结果返回给模型形成多轮交互。这里模型的能力是基础但真正的工程复杂度在编排层的状态管理和错误处理上。记忆机制拆开来看也是输入侧和编排层的组合——把历史对话的关键信息存储起来在后续对话中检索并拼接到输入中。存储和检索的策略是编排层的事拼接方式是输入侧的事。你去看那些让人眼花缭乱的新框架几乎都能用这个三层框架来解释。区别只在于它们在哪一层做了更精细的设计以及三层之间的接口怎么定义。2. 输入侧的核心处理逻辑2.1 输入到底包含哪些东西很多人以为输入就是用户打的那行字实际上送到模型面前的输入远比这复杂。一个典型的输入组装过程至少包含以下几个部分系统提示词、历史对话记录、检索到的外部知识、当前用户问题、格式指令、以及各种约束条件。系统提示词决定了模型的角色和行为边界。这部分通常是静态的或者半静态的但在一些高级用法中系统提示词会根据用户画像或场景动态生成。我见过一些团队把系统提示词做成了模板库根据不同的业务场景切换不同的模板效果比一个万能提示词要好得多。历史对话记录的处理是输入侧最容易被低估的环节。对话轮次多了之后全部塞进去会超出上下文窗口简单截断又会丢失关键信息。常见的做法有滑动窗口、摘要压缩、关键信息提取等。每种做法都有取舍滑动窗口实现简单但可能丢掉早期的重要约定摘要压缩能保留大意但会损失细节关键信息提取需要额外的模型调用来做判断。检索到的外部知识是另一个大头。检索增强生成听起来简单但检索什么、检索多少条、怎么排序、怎么拼接每一个决策都会影响最终效果。我自己的经验是检索结果的数量不是越多越好通常三到五条高质量的结果比十条混杂的结果效果更好。拼接的时候加上明确的分隔标记和来源标注能帮助模型更好地区分哪些是背景知识、哪些是用户问题。2.2 输入组装中的常见陷阱第一个陷阱是提示词膨胀。随着功能迭代系统提示词会越来越长各种规则、示例、约束不断累加。我见过一个项目的系统提示词超过了三千字里面充满了互相矛盾的指令。模型在这种情况下的表现会变得很不稳定因为它不知道该听哪一条。定期审查和精简系统提示词是必要的维护工作。第二个陷阱是上下文污染。历史对话中如果包含了错误的模型输出或者用户的错误前提这些信息会被带入后续对话导致模型在错误的基础上继续推理。解决办法是在组装输入时对历史记录做质量过滤或者在某些关键节点主动重置上下文。第三个陷阱是格式不一致。不同的输入来源可能使用不同的格式标记拼接在一起后模型需要额外精力去理解结构。统一使用清晰的分隔符和标签能显著提升模型对输入的理解准确度。实操心得我习惯在输入组装完成后做一个“可读性检查”——把最终拼好的输入当成一篇文章来读看看结构是否清晰、信息是否有冗余、指令是否有冲突。这个习惯帮我提前发现了很多问题。2.3 动态输入与静态输入的取舍静态输入指的是那些不随对话变化的固定内容比如系统提示词、格式指令、通用约束等。动态输入则是根据当前对话状态实时生成的内容比如检索结果、用户画像、历史摘要等。静态输入的好处是稳定、可缓存、调试方便。动态输入的好处是灵活、针对性强、能处理复杂场景。实际项目中通常是两者结合但结合的方式很有讲究。我的做法是把静态部分尽量前置动态部分尽量后置。原因是模型对输入开头和结尾的内容注意力更集中把稳定的指令放在开头能确保模型始终遵循基本规则把动态的上下文放在靠近用户问题的位置能确保模型优先参考最新信息。另一个经验是给动态输入加上明确的边界标记。比如用特定的标签把检索结果包起来并注明“以下内容来自外部知识库仅供参考”。这样模型能清楚知道哪些是背景信息、哪些是用户的实际问题减少混淆。3. 输出侧的处理艺术3.1 模型输出为什么需要处理模型输出的原始文本往往不能直接使用。原因有几个格式可能不符合下游系统的要求、内容可能包含不需要的冗余信息、结构可能不稳定导致解析失败、质量可能参差不齐需要筛选。输出处理的目标就是把模型的原始输出转化成可靠、可用、可预期的结构化数据。这个过程听起来像是简单的格式转换但实际上涉及到大量的工程细节和容错设计。我见过很多项目在演示阶段效果很好一到生产环境就频繁出问题大部分问题都出在输出处理环节。模型偶尔输出一个格式变体解析器就崩了模型多说了几句解释性的话下游系统就报错了。这些问题的根源在于对模型输出的不确定性没有做充分的预案。3.2 结构化输出的实现路径让模型输出结构化数据有几种主流做法各有优劣。第一种是提示词约束在提示词中明确要求模型按照特定格式输出比如JSON、XML或者自定义的标记格式。这种做法实现简单但可靠性一般模型偶尔会“忘记”格式要求特别是在输出内容较长的时候。第二种是少样本示例在提示词中给出几个输入输出的示例让模型模仿。这比单纯的格式描述效果要好因为模型能从示例中理解具体的格式细节。缺点是示例会占用上下文窗口而且示例的质量直接影响输出质量。第三种是约束解码在模型生成过程中通过技术手段限制输出必须符合特定语法。这是最可靠的做法但需要推理引擎的支持实现复杂度也最高。目前主流的推理框架都在逐步支持这个能力。第四种是后处理修复先让模型自由输出然后用规则或另一个模型来提取和修复结构。这种做法最灵活但引入了额外的延迟和成本。实际项目中我通常采用组合策略用提示词约束做第一层保障用后处理修复做兜底关键场景再考虑约束解码。3.3 输出校验与重试机制无论用哪种方式获得结构化输出校验都是必不可少的环节。校验的内容包括格式是否符合预期、必填字段是否齐全、字段类型是否正确、值是否在合理范围内。校验失败后的处理策略很关键。最简单的做法是直接报错让用户重试但体验很差。更好的做法是自动重试把校验失败的信息反馈给模型让它重新生成。重试次数通常控制在两到三次超过就降级处理或者转人工。重试的时候有一个技巧不要简单地把原始输入再发一遍而是把校验失败的具体原因附加到提示词中。比如“你上次的输出中缺少了summary字段请确保输出包含这个字段”。这样模型能针对性地修正成功率会高很多。注意事项重试机制要设置超时和次数上限避免在模型持续输出错误格式时陷入无限循环。我一般设置最多两次自动重试之后走降级逻辑。3.4 流式输出的处理策略流式输出是提升用户体验的重要手段但处理起来比一次性输出要复杂。因为你需要在不完整的输出上做判断和渲染。对于纯文本展示流式输出相对简单收到一段渲染一段就行。但如果输出需要结构化解析流式处理就麻烦了——你无法在输出完成之前确定它是否符合JSON格式。我的做法是分层处理对于需要结构化解析的场景先用流式输出展示原始文本让用户看到进度同时在后台缓冲完整输出等输出结束后再做解析和结构化处理。这样兼顾了体验和可靠性。对于可以增量解析的格式比如逐行输出的列表或者特定分隔符分隔的段落可以边接收边解析边渲染。这需要输出格式的设计和解析器的配合但效果很好。4. 编排层的核心机制4.1 编排层到底在编排什么编排层的核心任务是管理模型调用和其他操作之间的顺序、条件和数据流。它要回答的问题是什么时候调用模型、调用哪个模型、传入什么参数、拿到结果后做什么、什么条件下进入下一步、出错怎么办。一个最简单的编排就是单次模型调用组装输入、调用模型、处理输出、返回结果。但随着应用复杂度提升编排逻辑会迅速膨胀。多轮对话需要管理对话状态工具调用需要处理调用请求和结果回传多步推理需要串联多个模型调用条件分支需要根据中间结果决定下一步走向。我见过一些项目把编排逻辑写成了几百行的if-else嵌套维护起来极其痛苦。更好的做法是把编排逻辑抽象成状态机或者流程图每个节点是一个独立的处理单元节点之间的连线定义了流转条件。这样不仅代码清晰而且可视化之后很容易发现逻辑漏洞。4.2 工具调用的编排细节工具调用是大模型应用中最常见的编排场景也是坑最多的环节。模型输出一个工具调用请求编排层需要解析这个请求、执行对应的工具、把结果返回给模型、让模型基于结果继续生成。第一个坑是工具描述的质量。模型能不能正确选择工具很大程度上取决于工具描述是否清晰。描述要说明工具的功能、参数的含义、什么场景下使用。我见过很多工具调用失败是因为描述太模糊模型不知道该在什么时候用这个工具。第二个坑是参数校验。模型生成的参数可能类型不对、缺少必填项、或者值超出范围。编排层需要在执行工具之前做校验校验失败时把错误信息返回给模型让它重新生成。第三个坑是结果格式化。工具返回的结果可能是各种格式需要统一转换成模型能理解的文本形式。结果太长的话还需要截断或摘要避免占用过多上下文。第四个坑是循环控制。模型可能会反复调用同一个工具或者陷入调用-失败-再调用的循环。编排层需要设置调用次数上限和超时机制。4.3 多步推理的编排模式多步推理指的是把一个复杂任务拆成多个步骤每步调用一次模型前一步的输出作为后一步的输入。这种模式能处理单次调用难以完成的复杂任务但也引入了新的复杂度。常见的编排模式有几种。顺序链是最简单的步骤依次执行每步的输出传给下一步。路由模式是根据输入内容选择不同的处理路径比如简单问题直接回答、复杂问题走多步推理。并行模式是多个步骤同时执行然后汇总结果适合可以独立处理的子任务。循环模式是重复执行某个步骤直到满足条件适合需要迭代优化的场景。选择哪种模式取决于任务的特点。我的一般原则是能用顺序链解决的就不要用循环能并行的就尽量并行路由条件要尽量简单明确。每增加一种模式调试和维护的复杂度都会上升一个台阶。4.4 状态管理与上下文传递多步编排中状态管理是最容易出问题的地方。哪些信息需要在步骤之间传递、怎么传递、传递过程中怎么保证一致性这些都需要仔细设计。我的做法是定义一个明确的状态对象包含所有需要在步骤间共享的字段。每个步骤从状态对象中读取需要的输入执行完后把输出写回状态对象。这样步骤之间不直接通信都通过状态对象来交互耦合度低也方便调试。上下文传递有一个常见的误区是把所有中间结果都塞进上下文。这会导致上下文迅速膨胀不仅增加成本还会稀释关键信息的权重。正确的做法是只传递下一步真正需要的信息中间过程可以记录在日志中但不一定进入上下文。实操心得我会给状态对象加一个版本号每次修改都递增。这样在调试时可以清楚地看到状态在每一步的变化过程定位问题非常方便。5. 三层架构的协作与边界5.1 层与层之间的接口设计三层架构能不能用好关键在于层与层之间的接口是否清晰。输入侧的输出是编排层的输入编排层的输出是输出侧的输入每一层的输出格式都需要明确定义。我的经验是接口要尽量简单和稳定。输入侧对编排层暴露的就是一个组装好的提示词和一组元数据编排层不需要知道这个提示词是怎么拼出来的。编排层对输出侧暴露的就是模型的原始输出和调用上下文输出侧不需要知道这个输出是经过了几轮调用才得到的。接口稳定的好处是每一层可以独立演进。输入侧的组装策略变了只要输出的提示词格式不变编排层就不需要改动。编排层增加了新的调用步骤只要最终输出的格式不变输出侧也不受影响。5.2 什么逻辑应该放在哪一层这是一个在实际开发中经常引起争论的问题。我的判断标准是看这个逻辑的变更频率和影响范围。变更频率低、影响范围广的逻辑放在底层。比如模型选型和基础提示词模板这些一旦确定就不太会频繁改动放在模型层或输入侧的底层比较合适。变更频率高、影响范围窄的逻辑放在上层。比如某个特定场景的输出格式调整只影响这一个场景放在输出侧的上层处理就好不需要动到底层。跨多个场景的通用逻辑放在编排层。比如重试机制、日志记录、成本统计这些是多个场景共用的放在编排层统一处理最合适。场景特有的逻辑放在对应的层。比如某个场景需要特殊的输入预处理就放在输入侧的这个场景专属处理模块中不要污染通用逻辑。5.3 性能与成本的权衡三层架构的每一层都会引入延迟和成本。输入侧的检索和组装需要时间编排层的多步调用会成倍增加模型调用次数输出侧的校验和重试也会增加开销。优化的时候要找到瓶颈在哪一层。如果瓶颈在输入侧可以考虑缓存常用的组装结果、优化检索策略、减少不必要的上下文。如果瓶颈在编排层可以考虑合并步骤、并行执行、减少模型调用轮次。如果瓶颈在输出侧可以优化解析逻辑、减少重试次数、简化输出格式。成本控制方面我的经验是大部分成本花在了模型调用上而模型调用的次数和每次调用的输入长度是主要影响因素。减少不必要的调用、压缩输入长度、在合适的场景使用更小的模型这三招能解决大部分成本问题。6. 常见问题与排查技巧6.1 输入侧常见问题问题一模型忽略系统提示词中的指令。排查方向检查系统提示词是否过长导致关键指令被稀释检查指令之间是否有冲突检查指令的表述是否足够明确。解决办法精简提示词、消除冲突、把最重要的指令放在开头和结尾。问题二检索结果与问题不相关。排查方向检查检索的查询语句是否准确表达了用户意图检查检索的召回数量和质量检查拼接方式是否让模型能正确区分检索结果和用户问题。解决办法优化查询改写、调整检索策略、改进拼接格式。问题三多轮对话中模型忘记之前的约定。排查方向检查历史对话是否被正确保留检查关键信息是否在上下文中足够突出。解决办法对关键约定做显式摘要并放在显眼位置或者使用外部存储来管理长期记忆。6.2 输出侧常见问题问题一JSON解析失败。排查方向检查模型输出中是否包含JSON之外的文本检查是否有格式变体如单引号、尾逗号、注释等。解决办法在提示词中强调只输出JSON使用更宽容的解析器增加后处理修复步骤。问题二输出内容不符合预期格式。排查方向检查提示词中的格式描述是否清晰检查是否有示例可以参考。解决办法增加少样本示例使用更明确的格式标记考虑约束解码。问题三流式输出时前端渲染错乱。排查方向检查增量解析逻辑是否正确处理了不完整的片段检查特殊字符的转义。解决办法使用缓冲机制等待完整结构再渲染或者设计对增量友好的输出格式。6.3 编排层常见问题问题一工具调用陷入循环。排查方向检查工具返回的结果是否让模型误以为需要再次调用检查是否有明确的终止条件。解决办法设置调用次数上限在提示词中明确说明何时应该停止调用优化工具返回结果的格式。问题二多步推理中间步骤出错导致后续全错。排查方向检查每一步的输出质量定位是从哪一步开始偏离预期。解决办法在关键步骤增加校验出错时回滚到上一步重新执行或者设计更细粒度的步骤。问题三并发请求下状态混乱。排查方向检查状态管理是否线程安全检查是否有共享的可变状态。解决办法为每个请求维护独立的状态对象避免跨请求共享状态使用不可变数据结构。6.4 排查技巧速查表现象可能原因排查方法解决方向模型不遵循指令提示词冲突或过长逐条检查指令一致性精简、消歧、调整位置输出格式不稳定格式约束不够强统计格式错误类型分布增加示例、约束解码工具调用失败描述不清或参数错误检查工具描述和参数校验优化描述、增加校验响应时间过长调用轮次过多统计每步耗时合并步骤、并行化成本超预期输入过长或调用过多统计token消耗分布压缩输入、缓存结果多轮对话失忆上下文管理不当检查历史记录保留策略摘要压缩、外部存储实操心得我习惯在开发阶段打开完整的调用日志记录每一次模型调用的输入输出和耗时。上线后保留采样日志出问题时能快速定位是哪一层、哪一步出了问题。这个习惯帮我省了大量的排查时间。7. 从三层架构看新技术的定位7.1 用三层框架快速理解新概念当你看到一个新的AI应用框架或者技术方案时用三层框架去拆解它能快速抓住重点。先看它在输入侧做了什么。是改变了提示词的组装方式引入了新的上下文来源还是优化了历史对话的管理输入侧的创新通常围绕“给模型看什么”和“怎么看”展开。再看它在输出侧做了什么。是改变了输出的格式要求增加了输出校验还是优化了流式处理输出侧的创新通常围绕“怎么让模型的输出更可用”展开。最后看它在编排层做了什么。是引入了新的调用模式增加了工具集成还是改进了状态管理编排层的创新通常围绕“怎么协调多次调用和外部操作”展开。大部分情况下一个新框架会在一到两个层面有实质创新其他层面是沿用现有方案。找到它真正创新的那一层就能快速判断它是否值得深入研究。7.2 哪些创新是真正有价值的不是所有新花样都有实际价值。我的判断标准有几个。第一它解决的是不是真实存在的问题。有些创新解决的是理论上存在但实际很少发生的问题这种价值就有限。第二它的收益是否值得引入的复杂度。有些方案确实能提升效果但需要引入大量的额外代码和依赖维护成本很高。这种情况下要权衡收益和成本。第三它是否与现有方案兼容。完全另起炉灶的方案迁移成本高能在现有基础上渐进式改进的方案更容易落地。第四它是否有明确的适用边界。一个方案如果在所有场景下都“稍微好一点”往往意味着它在任何场景下都不是最优选择。有明确适用场景的方案反而更有价值。7.3 三层架构的演进方向从工程实践的角度看三层架构本身也在演进。输入侧的趋势是更智能的上下文管理。从简单的拼接发展到动态选择、自动摘要、相关性排序目标是让每一段进入上下文的文字都有明确的价值。输出侧的趋势是更可靠的结构化输出。约束解码技术的成熟会让结构化输出变得越来越可靠后处理修复的需求会逐渐减少。编排层的趋势是更灵活的流程定义和更强大的状态管理。可视化编排、声明式流程定义、自动错误恢复这些能力正在成为标配。但无论怎么演进核心问题始终没变给模型什么输入、怎么处理模型的输出、怎么协调中间的调用过程。抓住这三个问题就不会在层出不穷的新概念中迷失方向。8. 我个人的一些实践体会做了这么多项目踩了这么多坑有几个体会我觉得值得分享。第一个体会是不要过早引入复杂编排。很多项目一开始就设计了一套复杂的多步推理流程结果发现单次调用加好的提示词就能解决大部分问题。我的建议是先用最简单的方案跑通遇到瓶颈再逐步增加复杂度。每增加一层编排调试难度都是指数级上升的。第二个体会是输入侧的投资回报率最高。在提示词优化、上下文管理、检索策略上花的时间往往比在模型选型和微调上花的时间回报更高。我见过太多团队花大量精力去折腾模型结果发现把提示词改好一点效果提升更明显。第三个体会是输出处理要留足容错空间。模型输出永远会有意外解析器要能处理各种边界情况重试机制要能自动恢复降级方案要能保证基本可用。把模型当成一个“大部分时候靠谱但偶尔会犯错”的合作伙伴而不是一个精确的执行器。第四个体会是日志和可观测性不是可选项。三层架构中任何一层出问题如果没有详细的日志排查起来就是大海捞针。从第一天就把日志体系建好记录每次调用的输入输出、耗时、token消耗、错误信息后面会感谢自己。第五个体会是定期回顾和精简。项目跑一段时间后提示词会膨胀、编排会复杂、输出格式会冗余。定期做一次“架构清理”删掉不再需要的逻辑合并重复的处理简化过度的设计。保持架构的简洁比不断添加功能更重要。这些体会没有什么高深的理论都是从一个个具体项目中积累出来的。三层架构这个框架本身也很朴素但它的价值在于提供了一个稳定的坐标系让你在面对层出不穷的新概念时能快速定位、快速判断、快速决策。