大模型应用三层架构：输入与输出工程化实战

最近好多朋友跑来问我说现在AI的花样实在太多了——今天出一个能画图的明天出一个能写代码的后天又冒出一个能自己调用工具干活的。看着热闹但总觉得雾里看花不知道这些新玩法背后到底是什么逻辑。其实把大模型相关的技术拆开来看本质上就一层窗户纸所有的所谓「新花样」基本都围着「输入什么」和「输出怎么处理」这两件事打转。我用一个三层架构的视角把这堆东西归了归类。这个拆法不是教科书里的标准分层是我自己在实际落地项目、接API、调优、排查问题过程中慢慢琢磨出来的一个特别实用的理解框架。今天彻底掰开揉碎了讲一遍希望能帮你把脑子里那团关于大模型的乱麻理出一条清晰的线。1. 三层架构先搭起来模型内核、交互会话、应用编排很多人一上来就盯着模型参数、排行榜、微调技巧这些当然重要但都属于「模型内核」这一层。真正让你觉得AI变聪明了、能干事了、好用了的往往是外面那两层在起作用。我习惯把整个大模型应用拆成三个层次模型内核层、交互会话层、应用编排层。1.1 第一层模型内核层——底层的「智力核心」这一层就是通常说的基座大模型本身。不管是开源社区里下载的权重还是通过API调用的大模型服务比如各类国内大模型平台的接口本质上都是一个巨大的神经网络参数集合。这一层回答的问题是给定一段文字或者图片、音频下一个最可能出现的文字是什么。就这么朴素所有炫酷的智能感都源于这种高级的「接龙」能力。这一层的特点是做一次推理需要大量算力响应速度受限于模型参数量、推理框架优化程度、GPU性能。在大规模应用里这一层你基本不碰——你碰的是模型产出的结果而不是模型内部的权重。如果非要动这一层那就是微调、继续预训练、蒸馏压缩那些重活了属于专业团队才搞的事。1.2 第二层交互会话层——你「喂养」什么它「拉」出什么第二层是绝大多数开发者和创作者每天打交道的地方。这一层决定了你喂给模型的上下文是什么、以及如何把模型吐出来的原始文本转化成对用户有意义的信息。我这句话信息量很大拆开看就有两个方向输入方向提示词工程、上下文工程、向量检索RAG、系统提示词、多模态输入图片文字、结构化参数输入JSON Schema……这些技术本质上都在做同一件事——把你要问的问题、要用的背景资料、要约束的格式用一种模型最容易理解的方式组织好塞进它的输入通道里。同样一个开源模型有人拿去只能聊天有人拿去能写合同、做分析报告差别就在输入组织能力上。输出方向流式输出SSE、格式化输出JSON Mode、思维链让模型先想后说、工具调用让模型输出一个特定的动作指令……这些技术都在做另一件事——把模型原始的token流变成用户能快速理解、程序能便捷解析、下游能自动执行的格式。模型输出一千字的思考过程没人想看你告诉它「最后只输出JSON不包含其他文字」它就能规规矩矩给你吐出结构化数据。1.3 第三层应用编排层——把「模型」变成「产品」第三层才是用户真正感知到的「AI应用」。这一层用代码把多轮对话、工具调用、状态管理、权限控制、业务逻辑串起来让模型不再是孤零零的一个对话框而是一个能干活、能出错、能纠错的智能体Agent。比如让AI查天气、订机票、写文档、发邮件背后其实都是应用编排层在多轮调用交互会话层的能力。为什么要这样分层因为每一层的复杂度和迭代节奏完全不同。模型内核层更新缓慢几个月出一版交互会话层调整频繁每个项目都要不停地调试提示词与输出解析应用编排层则是没完没了跟业务需求强绑定。把这三个层拆开看你就能明白为什么大模型行业会有那么多「工程化」的岗位和工具——因为绝大部分的创新和优化空间都集中在中间层和上层。2. 输入侧拆解所有聪明的回答都源于讲究的提问输入侧是大模型应用里最容易被低估的部分。很多人觉得不就是打字提问吗有什么讲究的实际做下来输入侧的差异能直接决定一个AI功能的成败。我把输入侧分成四个模块来讲。2.1 提示词工程把模糊需求翻译成模型指令提示词工程的核心不是「写一段漂亮的咒语」而是把用户的意图拆解成模型能够严格遵循的步骤和约束。举个例子如果只是说「帮我写个活动策划」模型会给你一个泛泛的八股文。但如果你在提示词里加上明确身份定位「你是拥有十年线下活动运营经验的主理人」指定输出框架「按目标人群、活动主题、预算分配、时间线、风险预案五个板块输出」加入约束条件「预算不超过50万目标人群为25-35岁城市白领」指定格式要求「每个板块内使用小标题和列表总字数控制在2000字以内」模型输出的质量瞬间就上了一个台阶。这背后的原因在于大模型的预测逻辑是概率分布约束条件越多、越具体它在可能性空间里游走时就越容易命中你想要的那条路径。实操心得有一条很重要提示词里不要用否定句。比如「不要写得啰嗦」模型反而会在「啰嗦」这个词附近打转改成「请用简洁的短句每点不超过五行」效果会好得多。我试过很多次凡是带「不要」的约束大概率会向反方向跑偏。2.2 上下文工程给模型配一个「可检索的工作记忆」上下文工程比提示词工程更进一步。提示词解决的是「怎么问」上下文工程解决的是「喂什么背景材料」。这里就不得不提RAG检索增强生成了。它的核心逻辑很简单当模型不知道或记不牢某个具体信息时比如你的公司内部制度、某份行业报告数据、某本书的细节先从向量数据库中检索出相关片段拼接到提示词里再让模型基于这些片段回答问题。这个概念听上去很学术落地起来也不复杂先把文档切片用嵌入模型转成向量存入向量数据库用户提问时把问题也转成向量做相似度检索取Top K片段把问题和片段一起发给大模型生成答案。实际部署时最坑的地方在查准率。向量检索不是万能的它经常把「语义相似」但「不是用户要问的内容」的片段捞出来。我踩过的坑是某次做内部规章制度问答员工问「年假可以累积吗」向量数据库返回的是「婚假规定」——因为两者在「假期」语义上相近。后来我在检索前加了一层关键词过滤把制度分类标签作为硬性条件再向量检索准确率才有了质的提升。2.3 多模态与结构输入不再局限于「打字的对话框」现在的模型普遍支持图片、音频、甚至视频输入。这意味着输入侧不再是一段纯文本提示词而是多模态信息的混合体。比如让模型看一张电路图并解释工作原理或者在对话里插入一份PDF截图让它提取关键字段。做这类应用时有几个小细节值得留意。图片分辨率过低的输入模型识别精度会大幅下降建议在输入端约束最小尺寸并做好压缩上传文档类图片时提前做方向矫正和裁剪能让OCR识别的准确率高很多如果模型API支持图片URL与base64两种传法按理说base64更稳避免走网络传输时出现图片加载失败。结构输入也是输入侧的一大趋势。很多API支持用户传一个JSON Schema告诉模型输出的数据应该长什么样。这其实就把提示词工程中的「约束」给编程化了模型不用去理解自然语言里绕来绕去的约束描述直接按照结构定义生成。2.4 输入侧的隐患全局系统提示词的「权力」太大我做实际项目时发现一个很有代表性的问题系统提示词写得太死会把用户的输入空间锁死。比如给客服AI设定了一套极为严格的话术逻辑它连用户随口问「你们公司规模多大」都无法回答。这不是模型笨而是你的输入侧给它加了一层层「思想钢印」。所以我建议在设置系统提示词时把「强制规则」和「建议规则」分开写。前者如「必须使用礼貌用语」「不得编造信息」是硬约束后者如「可以适当推荐相似商品」「语气可以更亲切」给模型留一点自由发挥的余地。这样既能保证产品的底线质量也保留了大模型的灵活优势。3. 输出侧处理从流式打印到结构化落地的完整链路输出侧在我看来是最体现工程能力的一层。模型生成的是token但用户看到的是文字、表格、按钮、图表程序接收到的是JSON、函数调用指令、状态码。把这些打通需要一套完整的输出处理链路。3.1 流式输出SSE让用户感觉「快」的技术魔法大模型推理一个长答案通常要几秒甚至几十秒如果等它全部生成完再一次性显示用户的耐心早就耗光了。所以实际应用里基本都用SSEServer-Sent Events服务端推送事件实现打字机效果——模型每生成一个token服务器就通过HTTP长连接实时推给前端。技术原理不复杂传统HTTP请求是一问一答服务器处理完才返回SSE则允许服务器建立连接后源源不断地推送数据流直到结束。大模型服务商一般都会提供流式接口返回的数据是「data: {生成的那段增量文字}」这种格式前端在EventSource或者fetch的ReadableStream里逐段解析。这里有个非常关键的细节SSE连接的文件描述符和并发连接数限制。我踩过一次生产事故用户高峰期时Nginx默认的worker_connections被占满导致部分用户页面一直转圈。后来调整了Nginx的proxy_buffering设置为off让SSE数据不经过缓冲层直接透传同时调大了连接超时时间问题才缓解。做流式输出一定要改掉Nginx对长连接的超时默认配置。前端还有一个坑fetch接口的流式读取很多人以为用response.text()可以拿到全量数据再解析那就等于舍弃了流式优势。必须用response.body.getReader()逐块读再通过TextDecoder解码字符串按行切分处理SSE格式。3.2 中断机制Abort用户点了「停止」到底发生了什么流式输出的另一面是如何支持用户随时打断。大模型回答太长用户不想等或者发现AI跑偏了想马上终止重新提问。这时前端就需要向服务器发出取消请求的指令。实现方式有两条路线。前端fetch里使用AbortController用户在界面上点击「停止生成」按钮时触发controller.abort()浏览器就会断开当前请求。但注意这只断开了浏览器到服务器的连接服务器那边可能还在请大模型继续推理——因为模型生成是异步的后端的SSE循环可能尚未感知连接已断开。如果不做处理模型token还在继续生成白白浪费算力。根治办法是在后端把流式生成和请求上下文绑定当客户端断开连接时通过context取消信号通知大模型调用方比如OpenAI SDK里的abort参数及时终止生成。我自己实践时是把SSE的ResponseWriter包装了一层检测到客户端断连ctx.Done()后主动调用一次模型的cancel接口这样能显著降低无用token消耗实测在高频调用场景能省下20%左右的成本。3.3 结构化输出与函数调用让模型从「说人话」变成「干实事」流式输出解决了「快」的问题而结构化输出解决了「准」的问题。很多业务场景根本不需要模型输出完整句子只需要它返回一个JSON对象比如意图识别{intent: 查天气, city: 北京, date: 2025-06-01}信息抽取{name: 张三, phone: 138xxxx, company: 某某科技}内容审核{risk_level: 0, risk_types: [], summary: 无风险内容}现代的模型接口普遍支持JSON Mode你在输入侧用JSON Schema定义好输出字段、类型、枚举值模型就会按照这个结构生成。但你以为这样就万事大吉了吗不是的。实践中经常遇到JSON解析失败。模型偶尔会在JSON前后多输出一段解释性文字哪怕你明确说「只输出JSON」。稳妥方案是拿到输出后先做一次清洗提取第一个{到最后一个}之间的子串再做JSON.parse如果解析失败再补一次带错误提示的重试请求。字段值不符合枚举约束。比如定义了status只能是success或error模型偏给你输出successful。办法是在解析后加校验不合法就用规则映射表处理实在不行走人工兜底。永远不要把模型的输出当成绝对可靠的输入去用这点放在生产环境尤其重要。函数调用Function Calling本质上也是结构化输出的升级版模型返回的不是普通JSON而是一个「请调用某个函数、参数是XXX」的指令。应用编排层解析这个指令去执行实际代码查数据库、调天气接口、发邮件再把结果返回给模型组织成自然语言。Agent自主决策的底层逻辑就建立在这个机制上。3.4 多模态输出图文混排与结果渲染输出侧不仅是文本和JSON。现在大模型支持生成图片通过调用图片生成模型、语音通过TTS转语音甚至生成可交互的HTML页面。做AI报告助手时很多产品会引导模型输出Markdown格式前端渲染成漂亮的卡片、表格、图表。这里要特别注意渲染安全性。如果模型输出包含HTML代码你直接通过v-html或dangerouslySetInnerHTML渲染会带来XSS跨站脚本攻击风险。稍微懂行的人都知道模型生成的代码同样可能是恶意代码比如提示词注入。对模型输出做合规检测和白名单过滤是必须做的一道工序。4. 微调、Agent与传统架构三层体系只是「骨架」工程化才是「血肉」写到这里肯定有朋友会问那微调呢Agent呢这些热词和三层架构怎么对应答案很简单微调改变的是一层模型内核Agent则同时用到三层。4.1 微调的定位不是在「输入输出」上打补丁而是改「思维方式」微调本质上是在修改模型内核层的参数分布让模型在特定任务上「重新学习」概率分布。但很多人把微调和提示词工程搞混了能用提示词解决的事情压根没必要微调。提示词就像你给一个见多识广的顾问详细交代了背景、要求、格式他按你的规矩办微调则像把这个顾问送去参加专门的培训班让他天生就懂这一行的行话和禁忌。微调的适用场景有清晰的边界模型的输出风格必须完全一致比如品牌调性基础模型对专业术语的理解能力严重不足比如医疗、法律、代码数据隐私要求极高无法通过API传参暴露给第三方。如果只是一般性的格式要求、内容偏好、少量示例别轻易动微调量大成本高不说还容易引入灾难性遗忘——模型会记住新知识同时忘掉一部分旧能力。4.2 传统三层架构与大模型三层架构的类比后台系统常说的MVC三层架构控制器、服务、数据库和物联网三层架构感知、传输、应用本质思想与我讲的这套大模型三层架构完全一致隔离复杂度、明确边界、独立演进。大模型三层架构里的模型内核层对应后台系统的数据库层底层能力交互会话层对应服务层业务逻辑与数据处理应用编排层对应表现层用户交互与流程控制。理解了这一层类比你会发现大模型的工程化并不是什么全新领域很多后端架构经验照样能用。4.3 Agent的定义与实现拆解三层架构协同的典型场景Agent智能体是目前最火的概念。用三层架构去拆解一个能自主完成任务的Agent通常需要模型内核层提供推理能力交互会话层维护对话历史、调用工具函数、格式化输出应用编排层定义执行流程任务规划→工具选择→结果验证→决策下一步实际在做Agent时最难的并不是模型能力而是状态管理和错误恢复。Agent在连续执行多步操作时任何一步返回异常整个链路就可能失控。我的方案是每一步都强制模型输出一个结构化日志包括当前目标、已执行步骤、工具返回结果、下一步计划这样既方便用户追溯也方便系统在出错时定位问题并重试。5. 从真实项目中提炼的常见问题与排查方法讲了一大堆理论最后来点实战经验。我把做AI应用这大半年踩坑的典型问题整理成一份速查表按频率排序排名靠后的可能冷门但遇到了会很头大。5.1 高频问题速查表问题现象可能原因排查与解决办法流式输出突然断流代理层缓冲、超时设置过短关闭Nginx proxy_buffering调大proxy_read_timeoutJSON解析总是报错模型输出带杂质文字先截取首尾花括号再做解析失败后触发一次带错误信息重试回答内容胡编乱造上下文资料不足或检索不到优化RAG检索策略增加关键词预过滤提示词里加「仅基于引用内容回答」用户点停止后仍持续计费后端未感知断连用context绑定请求生命周期断连时主动终止上游调用多轮对话越聊越糊涂上下文窗口塞入过多垃圾文本做历史消息裁剪优先保留最近的对话与关键摘要同样的提示词输出不稳定模型temperature参数过高调低temperature通常0.2-0.5必要时设置seed如API支持输入侧图片识别不准图片分辨率不足或方向错误统一压缩后预处理检测EXIF方向并矫正5.2 一次令我一晚上没睡好的排查实录之前做客服机器人时遇到过一桩怪事白天一切正常一到晚上九点后回答质量直线下降用户问东它答西而且响应速度也慢了不少。一开始怀疑是服务器性能瓶颈但监控上CPU、内存都挺正常。后来查日志才发现晚高峰时段用户问的问题特别刁钻复杂上下文长度剧增输入侧拼接的RAG片段加历史记录已经把上下文窗口挤爆了模型只能勉强在碎片信息里瞎猜。解决办法是我加了一道「上下文压缩」工序每轮对话结束后提取关键信息用户诉求、已确认信息、待跟进事项缓存进一个短摘要里新对话来临时历史消息仅保留摘要加最近两轮内容。改完后晚间回答质量立刻回升。经验就是大模型应用系统的瓶颈往往不在模型本身而在你给它输送的上下文的组织方式。输出质量不过关先别急着换模型回去检查输入侧是不是塞了一堆没用的垃圾进去。5.3 三层各自的监控与预警策略工程化系统离不开监控。我对三层分别有对应的观测指标模型内核层主要看响应时延、错误率、Token消耗交互会话层看上下文长度分布、RAG检索命中率、JSON解析失败率、重试次数应用编排层看业务成功转化率、并发量、资源开销。特别要提的是Token消耗的观测。很多人只盯着大模型的API账单却不清楚钱具体烧在哪。实测下来长对话场景里相当比例的Token都浪费在重复拼接的系统提示词和历史记录上。通过上述的摘要压缩机制能有效把Token消耗降下来而且几乎没有体验损失。6. 进阶玩法把「输入输出」推向极致的小技巧这篇内容已经很长但最后我还是想单开一个篇幅分享三个我个人测试下来效果拔群、但文档里通常不会写的小技巧按难度从低到高排。6.1 用「连问带答」法替代单调追问有的任务需要模型连做几件事比如「先判断用户情绪再根据情绪生成回复」。直觉做法是让模型在两个步骤里分别输出再人工拼接。但实测下来直接让模型在一个回答里完成含中间推理但只输出最终结果的效果更好例如这样设计输出格式{ user_emotion: frustrated, confidence: 0.95, reply: 非常抱歉给您带来不便我立刻为您核实处理。 }模型链式思考后输出结构化结果比拆成多轮调用更稳定响应也更省Token。当然如果你需要向用户展示思考过程那就得两说了。6.2 输出解析时永远做「磨平处理」模型输出的JSON字段值往往带有莫名其妙的空格、换行、特殊字符直接入库或比较会翻车。我习惯在解析后做一层清洗去首尾空格、统一换行符、过滤控制字符、去除零宽字符。这一招能解决很多诡异的匹配bug。检查下你的字符串是否裹了一层你看不见的特殊字符——这个问题困扰我很久后来用ASCII码校验才发现。6.3 善用「输入尺寸」约束让模型更听话输入尺寸是热词但我这里说的不是图片尺寸而是输入内容的长度与结构。有实验表明模型在接收比较短的指令时遵循度高指令越长、越复杂遵循度越差。所以我会把复杂的业务需求拆成多个短指令分别放在系统提示词和用户提示词里而不是一股脑全塞进一段长文字里。实测拆分后的可靠性和遵循度确实比一整段长文本高不少。这是一个反直觉但很有效的小技巧少即是多。长提示词看着内容全面实际上是在跟模型的注意力机制作对拆成短小清晰的指令反而各条都能被严格执行。最后再分享一点个人体会从三层的视角去看大模型行业这些年的变化本质上就是围绕「输入什么」和「输出怎么处理」做文章输入侧从纯文本进化到多模态、RAG、结构化约束输出侧从流式打印到函数调用、Agent编排。模型内核本身的进展当然重要但真正让AI从「新鲜玩具」变成「生产力工具」的恰恰是那些默默无闻的输入输出工程。我自己实际做AI应用这么久最深的体会就是别指望模型一步到位。把输入打磨到极致、把输出处理得干净利落再复杂的业务场景也能凭借同一个模型内核支撑起来。如果下一次你又看到什么令人眼花缭乱的AI新功能不妨拆一拆它在输入侧做了什么改造又在输出侧加了什么处理拆完之后你多半就不再觉得神秘了。