大模型火了之后，各种新概念、新玩法层出不穷，今天一个“智能体”，明天一个“思维链”，后天又冒出个“多模态融合”。很多人追着这些名词跑，越追越焦虑，感觉永远学不完。但如果你把市面上主流的大模型应用掰开揉碎看一遍，会发现一个让人踏实的事实：所有 AI 新花样，本质上只在两个地方做文章——输入什么，以及输出怎么处理。中间那个负责“思考”的模型本体，反而是最稳定的那一层。

这个判断不是拍脑袋来的。我过去两年折腾过不少大模型落地项目，从最简单的文档问答到稍微复杂点的自动化流程，踩了一圈坑之后回头看，真正决定一个应用好不好用的，往往不是换了多强的模型，而是输入侧喂了什么、输出侧怎么接。这篇文章就把这个三层架构彻底拆开讲清楚，不管你是刚入门想搞明白大模型应用到底怎么回事，还是已经做过一些项目但总觉得哪里没打通，都能从中找到可以直接抄作业的思路和避坑经验。

1. 三层架构到底怎么分：先建立全局视角

1.1 为什么是三层而不是两层或四层

把大模型应用拆成三层，是我试过多种分法之后觉得最顺手的一种。三层分别是：输入层、模型层、输出层。输入层负责把用户的原始需求翻译成模型能理解的格式，模型层负责推理生成，输出层负责把模型吐出来的东西变成用户能直接用的结果。

为什么不是两层？因为很多人会把输入和输出混在一起叫“应用层”，但实际操作中你会发现，输入侧的问题和输出侧的问题完全是两码事。输入侧出问题，表现为模型答非所问、理解偏差；输出侧出问题，表现为格式不对、没法对接下游系统。混在一起排查，效率极低。

为什么不是四层？有人会把“数据层”单独拎出来，但在大多数应用场景里，数据要么是输入的一部分（比如检索增强），要么是输出的一部分（比如写入数据库），单独拆一层反而增加了理解成本。三层足够覆盖绝大多数情况，而且边界清晰。

提示：这个分层不是学术定义，而是实操视角的划分。目的是让你在遇到问题时能快速定位到底是哪一层出了毛病。

1.2 模型层为什么反而最“无聊”

模型层就是那个真正跑推理的大模型本身。你可能会觉得这是最核心的一层，但实际上在应用开发中，它是最不需要频繁改动的一层。原因很简单：模型的能力边界在训练完成那一刻就基本确定了，你能做的只是通过输入输出来适配它，而不是改变它。

我见过不少团队花大量时间纠结“用哪个模型”，今天试试这个，明天换换那个，结果项目进度卡在选型上。但实际跑下来，同一个任务，不同主流模型的表现差异远没有想象中那么大，真正拉开差距的是输入侧有没有把需求说清楚、输出侧有没有做好后处理。

模型层还有一个特点：它的迭代是平台方的事，不是应用方的事。你今天用的模型版本，下个月可能就升级了，但你的输入输出逻辑不需要跟着大改。这就是为什么我说模型层最“无聊”——它稳定、被动，是整个架构里的常量，而不是变量。

1.3 输入层和输出层才是真正的战场

所有让人眼前一亮的 AI 应用，创新点几乎都集中在输入层和输出层。输入层的创新包括：更好的提示词设计、更精准的上下文检索、更合理的多轮对话管理、更丰富的多模态输入处理。输出层的创新包括：结构化输出解析、多轮结果聚合、格式转换、与外部工具的联动。

举个例子，同样一个模型，你直接问“帮我写个方案”，和先给它喂三篇参考文档再问“按照这三篇文档的风格写个方案”，输出质量天差地别。这个差异不来自模型，来自输入层。再比如，模型输出了一段 JSON，你直接扔给用户看，和解析后渲染成表格再展示，体验完全不同。这个差异来自输出层。

所以如果你想把 AI 应用做好，精力应该花在输入输出这两层上，而不是天天盯着模型排行榜。

2. 输入层拆解：决定模型“吃”到什么

2.1 提示词工程只是输入层的一部分

很多人一提到输入层就想到提示词工程，觉得把提示词写好就万事大吉了。但提示词只是输入层的一个子集。完整的输入层至少包括四个部分：系统指令、上下文信息、用户输入、历史对话。

系统指令是给模型定角色的，比如“你是一个专业的法律顾问”。上下文信息是你额外喂给模型的参考资料，比如检索到的文档片段。用户输入是当前这一轮的问题。历史对话是之前几轮的交互记录。这四部分怎么组合、怎么排序、怎么控制长度，都是输入层要解决的问题。

我踩过的一个坑是：早期做文档问答时，把检索到的文档片段直接拼在用户问题前面，结果模型经常把文档里的内容当成用户说的话来回应。后来改成用明确的分隔符把文档和问题隔开，并加上“以下文档仅供参考，请回答用户问题”的指令，问题就解决了。这就是输入层设计不到位导致的。

2.2 上下文检索：输入层最值钱的能力

如果说输入层有什么能力最值得投入，那一定是上下文检索。大模型本身的知识是固定的，但通过检索把外部知识注入到输入里，就能让模型回答它原本不知道的事情。这就是检索增强生成的核心思路。

检索增强生成听起来复杂，拆开看就三步：把用户问题转成向量，在向量库里找最相似的文档片段，把找到的片段塞进输入里。难点不在模型，而在检索质量。检索不准，喂进去的上下文就是噪音，模型反而会被带偏。

我在实际项目里总结了几条检索优化的经验。第一，文档切分粒度很重要，切得太碎会丢失上下文，切得太大会引入无关信息，一般按语义段落切分效果比较好。第二，向量模型的选择比大模型的选择更影响检索效果，因为检索不准后面全白搭。第三，检索数量不是越多越好，一般三到五条最相关的结果就够了，多了反而干扰模型判断。

注意：检索增强生成不是万能药。如果外部知识本身质量差、结构乱，检索出来的东西也是垃圾。输入层的质量上限取决于你的数据质量。

2.3 多轮对话管理：别让历史拖垮输入

多轮对话是输入层里最容易被忽视的部分。很多人做对话系统时，把全部历史对话都塞进输入里，结果 token 消耗飞快，模型还容易被早期无关内容干扰。正确的做法是有选择地保留历史。

我的做法是：只保留最近三到五轮对话，并且对历史对话做摘要压缩。比如用户前面聊了十分钟的需求背景，不需要把原话全带上，用一两句话概括就行。这样既保留了上下文连贯性，又控制了输入长度。

还有一个技巧是“对话状态追踪”。把多轮对话中提取到的关键信息（比如用户提到的日期、地点、偏好）单独存成一个结构化状态，每轮输入时把这个状态带上，而不是带原始对话。这样输入更干净，模型也更容易抓住重点。

2.4 多模态输入：图片、音频怎么喂给模型

多模态输入是近两年的热点，但实操中要注意：不是所有模型都支持多模态，支持的模型对输入格式也有要求。图片一般需要转成 base64 编码或者提供 URL，音频需要先转成文字再输入，视频更复杂，通常要抽帧成图片序列。

我做过一个图片理解的小项目，经验是：图片分辨率不是越高越好，太高的分辨率会消耗大量 token，而且模型对图片的理解能力有限，关键信息清晰可见就够了。另外，图片和文字的排列顺序会影响模型理解，一般把图片放在相关文字旁边效果最好。

音频输入目前最稳妥的方案还是先做语音转文字，再把文字输入模型。直接端到端的语音理解模型虽然有，但稳定性和可控性还不如转文字方案。视频输入同理，抽关键帧加字幕转文字，比直接喂视频靠谱得多。

3. 输出层拆解：决定用户“拿”到什么

3.1 结构化输出：让模型吐出来的东西能用

模型默认输出的是自然语言文本，但很多应用场景需要的是结构化数据。比如你要把模型输出存进数据库，就需要 JSON；要展示成表格，就需要二维数组；要触发下游动作，就需要特定的指令格式。这些都需要在输出层做处理。

让模型输出结构化数据有两种思路。一种是在提示词里明确要求模型按 JSON 格式输出，另一种是让模型自由输出，然后用解析器提取结构化信息。第一种思路更直接，但模型有时会不听话，输出带 markdown 代码块的 JSON 或者格式错误的 JSON。第二种思路更灵活，但解析器要写得足够健壮。

我的经验是两者结合：提示词里要求 JSON 输出，同时输出层加一个容错解析器，能处理常见的格式偏差，比如去掉代码块标记、补全缺失的括号、修正常见的键名拼写错误。这样既保证了结构化，又不会因为模型偶尔不听话就整个流程崩掉。

3.2 格式转换与渲染：从文本到用户界面

模型输出的文本要变成用户能看的东西，中间需要一层格式转换。最简单的场景是纯文本展示，复杂一点的场景包括：把 markdown 转成 HTML 渲染、把 JSON 转成表格、把列表转成卡片、把代码块加上语法高亮。

这一步看起来是前端的事，但实际上输出层就要考虑好。比如模型输出的 markdown 里可能有表格，你的渲染器要能正确处理；可能有代码块，要能识别语言类型；可能有数学公式，要能渲染成公式而不是纯文本。这些如果输出层不做处理，前端就要做，但前端做的话，不同端（网页、App、小程序）就要各做一遍，不如在输出层统一处理。

我一般会在输出层做一个“标准化”步骤：把模型输出的各种格式统一转成一种中间格式，比如 HTML 片段或者结构化 JSON，然后各端再基于中间格式做渲染。这样逻辑集中，维护成本低。

3.3 结果校验与兜底：别让模型胡说八道直接出去

模型会胡说八道，这是常识。输出层的一个重要职责就是校验和兜底。校验包括：事实性校验（输出内容是否和已知事实矛盾）、格式校验（输出是否符合预期格式）、安全校验（输出是否包含不当内容）。兜底就是当校验不通过时，给用户一个合理的降级回复，而不是直接把错误内容展示出去。

事实性校验最难做，因为你需要一个可信的知识源来比对。我的做法是：对于关键事实，在输入层就把可信信息喂给模型，输出层再检查模型输出是否引用了这些信息。如果模型输出和输入信息矛盾，就触发重新生成或者降级回复。

格式校验相对简单，就是检查输出是否符合预期的结构。安全校验可以用关键词过滤加模型自检的方式。兜底策略要根据场景设计，比如客服场景可以回复“这个问题我暂时无法回答，建议您联系人工客服”，而不是硬答。

3.4 输出与外部系统的联动

输出层不只是给用户看的，很多时候还要触发外部动作。比如模型判断用户意图是“查天气”，输出层就要调用天气接口；判断意图是“下单”，输出层就要调用订单系统。这就是所谓的“工具调用”或“函数调用”。

工具调用的关键是意图识别和参数提取。模型输出一段文本，输出层要从中解析出用户想调用哪个工具、参数是什么。我的做法是让模型直接输出结构化的调用指令，比如{"tool": "weather", "params": {"city": "北京"}}，然后输出层解析这个指令并执行。这样比让模型输出自然语言再解析要可靠得多。

提示：工具调用的参数校验一定要做。模型可能提取出错误的参数，比如把城市名提取成省份名，输出层要能识别并纠正，或者返回错误让模型重新提取。

4. 实操：从零搭一个三层架构的问答应用

4.1 场景定义与技术选型

假设我们要做一个“内部文档问答助手”，用户可以用自然语言提问，系统从内部文档库里找答案并回复。这个场景足够典型，覆盖了输入层的检索、模型层的推理、输出层的格式化。

技术选型上，模型层选一个主流的中等规模模型就够了，不需要追求最大最强的，因为我们的重点在输入输出。输入层的向量检索用一个轻量级的向量模型加一个向量数据库。输出层用一个简单的 Web 框架做接口，前端用最基础的 HTML 加 JavaScript。

这个选型的逻辑是：把复杂度和成本控制在输入输出层，模型层保持简单稳定。这样整个系统更容易调试，也更容易替换组件。

4.2 输入层实现：文档切分与检索

文档切分我按语义段落来，每段控制在 300 到 500 字。太短了上下文不够，太长了噪音太多。切分的时候保留段落标题，这样检索到片段后还能知道它属于哪个章节。

向量化用的是一个开源的中文向量模型，把每个段落转成向量存进向量数据库。检索时把用户问题也转成向量，算余弦相似度，取 top 3 的段落。

这里有个细节：用户问题往往很短，直接拿短问题去检索长文档，相似度计算容易不准。我的做法是先让模型把用户问题扩展成几个相关查询，分别检索后合并结果。比如用户问“报销流程”，模型扩展成“报销需要什么材料”“报销审批要多久”“报销在哪里提交”，这样检索覆盖面更广。

4.3 模型层调用：提示词模板设计

提示词模板我分成三部分：系统指令、上下文、用户问题。系统指令写清楚角色和输出要求，上下文放检索到的文档片段，用户问题放原始提问。

模板大概长这样：

你是一个内部文档问答助手。请根据以下文档片段回答用户问题。 如果文档中没有相关信息，请直接说“文档中没有找到相关信息”，不要编造。 文档片段： {context} 用户问题：{question} 请用简洁的中文回答，并在回答末尾标注引用的文档片段编号。

这个模板的关键点是：明确要求不编造、要求标注引用。标注引用是为了输出层能做校验，如果模型说了一个文档里没有的信息，输出层可以检查引用编号对应的片段里有没有这个信息。

4.4 输出层实现：解析、校验与展示

模型输出后，输出层先做解析：提取回答正文和引用编号。然后做校验：检查引用编号是否有效，检查回答内容是否能在引用片段中找到依据。校验通过就展示，不通过就降级回复“抱歉，我暂时无法确认这个问题的答案”。

展示时把引用片段也一并展示出来，让用户能看到答案的来源。这样既增加了可信度，也方便用户自己判断。如果用户点击引用片段，还能展开看完整段落。

整个流程跑下来，你会发现真正花时间的是输入层的文档处理和输出层的校验逻辑，模型调用本身只是几行代码的事。这再次印证了那个判断：新花样都在输入输出，模型层只是执行者。

5. 常见问题与排查技巧实录

5.1 模型答非所问怎么排查

答非所问是最常见的问题，排查思路是从输入层往模型层查。先看输入里有没有把用户问题说清楚，再看上下文有没有干扰信息，最后才怀疑模型能力。

我遇到过一次典型情况：用户问“年假怎么算”，模型回答了一堆考勤制度。查下来发现检索到的文档片段里有一大段考勤制度，和年假无关，但向量相似度很高，被检索出来了。解决办法是在检索后加一个重排序步骤，用更精细的模型对候选片段做二次排序，把真正相关的排前面。

5.2 输出格式不稳定的处理

模型输出 JSON 时经常带 markdown 代码块标记，或者键名大小写不一致，或者少个括号。这些都要在输出层做容错处理。

我的容错解析器大概做这几件事：去掉首尾的代码块标记、尝试用 JSON 解析、解析失败就用正则提取键值对、键名统一转小写、缺失的括号自动补全。这套组合拳下来，百分之九十五的格式问题都能自动修复。

5.3 检索不准的优化路径

检索不准的表现是：明明文档里有答案，但检索不到；或者检索到的片段和问题无关。优化路径按优先级排：先优化文档切分粒度，再优化向量模型，再优化检索策略，最后才考虑换向量数据库。

文档切分是最容易被忽视但影响最大的。我见过一个项目，文档按固定字数切分，结果一个完整的流程被切成三段，检索到其中一段根本看不懂。改成按标题和段落切分后，检索准确率直接上了一个台阶。

5.4 多轮对话中上下文丢失的解决

多轮对话中，用户经常用代词指代前文内容，比如“它”“那个”“上面说的”。如果历史对话没带全，模型就不知道指代什么。

解决办法是在输入层做指代消解：把用户当前问题中的代词替换成具体指代的内容。比如用户上一轮问“报销流程”，这一轮问“它需要多久”，输入层把“它”替换成“报销流程”，变成“报销流程需要多久”。这样即使历史对话带得少，模型也能理解。

指代消解可以用规则做，也可以用模型做。规则做简单场景够用，复杂场景还是得靠模型。但模型做会增加一次调用，成本和延迟都会上升，需要权衡。

5.5 常见问题速查表

这张表是我在实际项目中反复用到的一个速查工具，遇到问题先对号入座，能省不少排查时间。

6. 三层架构的扩展思路

6.1 输入层的扩展：从文本到多模态

输入层往多模态扩展是趋势。图片输入可以做图文问答，音频输入可以做语音助手，视频输入可以做内容摘要。但扩展时要注意：多模态输入的 token 消耗远大于纯文本，成本控制是关键。

我的建议是：多模态输入先做预处理，图片压缩到合适分辨率，音频转文字，视频抽关键帧。预处理后的输入再喂给模型，既控制了成本，也提高了理解准确率。

6.2 输出层的扩展：从展示到行动

输出层往行动扩展就是工具调用和自动化流程。模型输出不只是给人看，还能触发一系列动作。比如模型判断用户要订机票，输出层就调用订票接口、填表单、发确认邮件。

扩展的关键是定义好工具接口和参数规范。每个工具要有清晰的描述和参数 schema，模型才能正确调用。输出层要做好参数校验和错误处理，工具调用失败要有降级方案。

6.3 模型层的扩展：多模型路由

虽然我说模型层最稳定，但也不是完全不能动。多模型路由就是一个扩展方向：简单问题用小模型，复杂问题用大模型，特定任务用专用模型。这样能在成本和效果之间取得平衡。

路由逻辑可以放在输入层，根据问题类型选择模型；也可以放在输出层，根据模型输出质量决定是否换模型重试。我一般放在输入层，因为这样延迟更低，用户体验更好。

7. 我踩过的几个印象深刻的坑

第一个坑是过度依赖模型能力。早期做项目时，总觉得换个更强的模型就能解决问题，结果换了一圈发现，问题出在输入层的检索不准。后来把精力放在检索优化上，效果立竿见影。这个教训让我明白：模型是常量，输入输出是变量。

第二个坑是忽视输出校验。有一次做自动回复，模型输出了一段看起来很像那么回事但实际上是编造的内容，直接发出去了，造成了不好的影响。从那以后，我在输出层加了强制校验，关键信息必须能在输入中找到依据才允许输出。

第三个坑是上下文塞太多。为了“让模型知道更多”，把大量历史对话和文档片段都塞进输入，结果模型反而抓不住重点，响应也慢。后来学会了做减法，只保留最相关的信息，效果反而更好。

第四个坑是格式处理想当然。以为模型会乖乖按 JSON 输出，结果各种格式偏差。后来写了容错解析器，才把这个问题解决。这件事让我意识到：输出层的健壮性和输入层的准确性同样重要。

8. 给不同阶段从业者的建议

如果你刚开始接触大模型应用，建议先从输入层入手，把提示词写好，把检索做准。这两件事做好了，效果提升最明显，也最容易看到成果。

如果你已经做过一些项目，建议重点优化输出层。输出层的校验、格式化、工具调用，是区分“玩具”和“产品”的关键。很多项目输入层做得不错，但输出层粗糙，导致用户体验差。

如果你在带团队做项目，建议把输入层和输出层分开专人负责。输入层的人关注数据质量和检索效果，输出层的人关注格式稳定性和系统对接。模型层不需要专人盯，定期评估一下就行。

最后分享一个我常用的判断方法：当你拿到一个新 AI 应用时，先看它的输入设计，再看它的输出处理，基本就能判断它的技术含量和实用价值。那些只会在提示词里堆花活的，往往输出层很粗糙；那些输出层做得很精细的，输入层通常也不会差。这个判断方法帮我省了很多研究新工具的时间。