你花一个下午调通了大模型API，做一个智能客服Demo，发到工作群里，大家纷纷点赞，说你牛逼。然后呢？然后就没有然后了。这是太多刚开始接触大模型应用开发的人撞过的同一堵墙——Demo能跑，不代表它能在生产环境里被几十个真实用户同时折腾。作为已经在AI应用开发这条路上踩过不少坑的人，我想把从Demo到生产的完整实战路径摊开来讲。这篇指南是给那些还在“跑通接口”阶段挣扎的小白程序员看的，也是给那些把所有希望押在“换一个更聪明的模型”上、结果照样翻车的人看的。1. 为什么你的大模型Demo总是在“能跑”和“能上线”之间卡住1.1 大多数小白程序员的第一版，其实都是“API贴皮程序”“我接好了，能聊了，为什么还不上线？”当身边的同事第一次把大模型接进项目时，几乎每个人都会这么说。拆开看，所谓“接好了”，往往是拿到一个密钥，在文档里写一段系统提示词，写个循环发请求，把打印出来的回复拼接成聊天记录。这其实不是应用，而是一个API贴皮程序。它只证明了一件事——模型服务商的接口是通的，除此之外什么都证明不了。贴皮程序和真正的应用之间，隔着一整套工程基础设施。举个例子：你的Demo里一个用户聊天，上下文全靠一个全局数组装着，所有请求串行发出，模型响应慢一点，整个界面就卡住。这在本地验证时毫无感觉，一旦同时进来二十个请求，队列会越排越长，最先进入的对话可能五六秒都没反应。小白阶段最容易犯的错，就是把模型的输出当成项目的全部，把请求层、会话层、数据层、监控层统统忽略掉，而这些层恰恰是生产环境真正考验你的地方。1.2 真正的问题：不是模型不行，而是你还没把工程约束当回事很多人在大模型答错的时候，第一反应就是换更大的模型，仿佛模型的参数量是解决一切问题的万能钥匙。可我接过的某个内部知识问答项目就是个典型反例：上线第一天确实有大量答非所问，团队第一反应是换更大规模的模型，结果成本翻了几倍，问题依旧。后来把日志打开才发现，将近四成的请求根本没把用户问题送进模型，而是被前面一层关键词过滤规则误杀，或者被缓存的旧答案命中。问题出在应用代码的编排逻辑上，跟模型智商没有半点关系。这件事给我最大的教训是：大模型应用开发的生产力瓶颈，从来不是模型接口本身能不能给出高质量回答，而是你能不能围绕“不一定正确、不一定稳定、不一定便宜”的输出，搭起一套校验、兜底、回退机制。生产环境看的是延迟、错误率、成本、合规、可观测性，这些约束在Demo阶段几乎不存在。你提前把它们当回事，才能在真正上线那天少熬夜。否则你写的每一个页面、每一个接口，都会在第一次真实流量冲刷下现出原形。1.3 认清“大模型应用开发”和“调接口”的区别如果只能用一句话概括两者的差别，我会说：调接口的目标是“拿到一次回答”，做应用的目标是“反复、大规模、稳定地拿到符合业务约束的回答”。前者是一次性的快乐，后者是重复性的工程。一个对话应用从职责上可以被拆成五层：接入层负责协议和鉴权；编排层负责调用顺序、工具选择、上下文组装；模型层负责真实的大模型调用；数据层负责用户画像、历史会话、外部知识检索；观测层负责记录每一次调用的输入、输出、耗时和成本。理清这五层之后，你会发现“接入哪一个模型”只是其中一个决策点，而不是全部。所有你在Demo里用一行代码糊弄过去的事情——会话怎么存、提示词怎么管、流式怎么推、超时怎么兜底、失败怎么重试——到了生产环境都会变成绕不开的课题。这篇实战指南后面所有内容，都是围绕这些“糊弄过去的事”展开的，希望你能带着这个意识往下看。2. 动手之前先定盘：模型接入、框架选型、上下文方案的取舍2.1 模型接入的三条路：没有完美的方案，只有合适的取舍现在做应用，接入模型无外乎三条路。第一条是走商业模型API，开发速度快、效果稳定、按量付费，但你要接受数据出域、成本随调用量线性上升、可用性受制于上游服务。第二条是拿开源权重模型本地部署，数据自主可控、没有单次token计费，可你需要GPU资源，维护和调优门槛不低，效果也未必比商业API好。第三条是混合路由，简单请求走轻量模型，复杂请求走更强的服务，兼顾成本、性能与体验，但架构复杂度会明显上升。我做项目时经常看到这样的现象：几个人明明只有几十个用户，却花了两周时间搭本地模型集群，美其名曰“数据安全”，最后因GPU资源不够，推理速度惨不忍睹。而另一个团队一上来就走商业API，在线率很高，但数据合规没过审，被迫返工。所以我的建议是：如果你还在验证阶段，不用纠结，直接走商业API，把产品逻辑跑通最重要。等用户量起来、数据要求变严，再逐步加入本地部署或路由策略，这是性价比最高的路径。在模型选择上还有一个容易被忽视的点：不要一门心思只盯“能力最强的模型”。中文长文本、代码生成、多轮指令跟随、工具调用，不同模型在不同子任务上有各自的强项。最好把你业务里的真实输入做成几十个样例，挨个跑一遍，按准确率、格式合规率、成本三项打分，再决定主用哪一个。这个过程不复杂，却能避免上线后因为模型能力和业务需求错配而反复返工。2.2 编排框架要不要用，怎么选才不会变成新的黑盒市面上已经有不少编排类框架，帮你把模型调用、工具调用、记忆管理串起来，对新手来说看起来很诱人。我的态度很明确：快速验证创意可以大胆用，生产环境要克制。框架帮你省掉的“胶水代码”，往往也是你最需要掌控细节的地方。框架封装得越深，线上出问题时，你越不知道它内部替你做了什么，排错难度反而更大。如果你的业务比较复杂，需要很多工具调用、多步推理，那用框架确实能省下大量工作量，但建议只把框架当作调度器，核心业务逻辑自己写，外部工具函数也由你定义好清晰的入参出参。不管你用不用框架，都必须在调用链路上留好原始输入输出的日志，这是所有排错工作的地基。我见过太多人用了框架以后，日志彻底变成黑盒，最后只能把出问题的那条消息一遍遍重放猜原因，效率极低。2.3 上下文与记忆：先分清短期和长期，再决定怎么存做对话应用最容易踩的坑，就是“一股脑把历史全塞给模型”。短期记忆是指近几轮对话，把它作为上下文传给模型，这是保证多轮连贯性的基础。长期记忆则是用户的偏好、历史事实，这部分应该存在数据库或向量检索系统里，只在需要时检索出来拼进提示词，而不是每次都把所有历史全量带上。从成本角度也很好理解：输入token是要花钱的，历史越长，每一轮对话的固定开销就越高，而且无关的旧消息还会干扰模型对当前意图的判断。我通常采用的策略是“会话摘要加最近N轮原文”：系统定期把已经过去的对话压缩成一段摘要，同时只保留最近六到十轮的完整消息。这样既不会丢掉太久远的用户偏好，也不会让上下文无限膨胀。判断这个N到底取多少，没有统一标准，要在成本、效果和开发复杂度之间做实验，而不是拍脑袋写一个固定值。3. 从零手写一个能扛住真实请求的对话后端3.1 目录结构先搭好，才不会被后续的需求改崩很多人写大模型应用，习惯把所有逻辑塞进一个文件里：接口、提示词、会话存储、模型调用全混在一起。一两个接口还好，一旦业务扩展，加一个工具调用、加一种会话清理策略，代码立刻变成一团乱麻。我常用的目录结构长这样，它把上面说的五层对应关系直接落到文件上：app/ entrypoints/ # HTTP接口、流式接口 chat.py services/ # 业务编排 dialogue.py intent.py gateways/ # 模型调用、外部工具 llm_client.py tool_client.py stores/ # 会话存储、向量检索 session_store.py vector_store.py prompts/ # 提示词文件，按版本管理 chat_v1.py observability/ # 日志、追踪、指标 middleware.py这样拆的好处是，排查问题时你能顺着“入口到编排到模型到存储”的路径上下追，而不会在一坨互相调用的函数里迷路。提示词单独放一个目录尤其重要，因为提示词是生产环境里变更最频繁的东西，把它写死在代码里，每次修改都要重新发版，线上失误概率会高很多。每次改动都应该像改业务代码一样走评审、留记录，而不是在聊天调试窗口里复制粘贴临时拼串。3.2 核心接口：请求校验、模型调用、异常兜底接口层的第一件事不是调用模型，而是校验输入。用户标识、消息长度、会话标识、调用频率都要在进入模型前拦一道。很多Demo翻车，就是因为把大模型当成数据库用，用户发一段超长文本就原样塞进去，几千个token被白花掉，还拖慢整个通道。我建议在接口层做三层拦截：格式校验、业务校验和频率限制。格式校验保证请求体合法；业务校验确认这个用户有没有权限发这个请求；频率限制用来挡住异常点击和恶意刷量。异常兜底要分层设计。模型超时或报错时，最忌讳的不是报错本身，而是没有预案。我会在模型调用层设置一个较短的超时时间，第一次超时就重试一次，如果还是失败，就返回一个“服务开小差了，请稍后再试”的兜底文案，同时把完整调用链信息写入日志。这里要记住：给用户看的是体验文案，给排查者看的是完整真相，两者不要在代码里混在一起。我见过不少项目把内部堆栈直接返回给前端，既不安全，也无助于用户理解问题。3.3 多轮对话的会话管理：从全局变量到带过期时间的存储会话管理是所有对话应用逃不开的基础设施。Demo阶段很多人用全局变量保存聊天记录，进程一重启全丢，多实例部署时数据还会串台，用户A发的消息莫名其妙出现在用户B的上下文里。生产环境至少要有一个带过期时间的会话存储，推荐用缓存中间件的哈希结构，以会话标识为key，把最近N轮对话按顺序存进去，同时设置合理的过期时间。这里有个容易被忽略的点：会话过期策略要跟业务匹配。客服场景可能需要保留几天，闲聊机器人可能十几分钟不活跃就该清理。不要觉得“存得久没坏处”，存储成本、恢复后的上下文长度、数据合规问题都会随之而来。另外，多实例部署时一定不要让会话存储依赖进程内存，否则负载均衡把你路由到另一个实例，上下文就全断了。一个简单的会话存储接口，不需要多高的技术含量，但它决定了你的“多轮对话”到底是真多轮，还是形式上的多轮。3.4 流式响应：让用户的等待感从5秒变成0.5秒如果你没有做过流式输出，第一次把模型接入前端，大概率会被一个体验问题困扰：用户在输入框敲完回车，看到光标转了四五秒，然后一整段文字突然刷出来。这在Demo里可以忍，在生产环境会被用户直接骂。解决思路是让模型的输出以流式方式一点一点送到前端，这就是SSE（Server-Sent Events）的思路：后端边接收结果边推送，前端逐字渲染，整个界面看起来就像模型在“打字”。流式输出的坑在于：不是所有模型服务都支持流式，不支持的你需要自己做缓冲；支持的话，你要正确处理编码、错误中断、连接断开。前端收到的不是一个完整的JSON，而是多段以特定前缀开头的文本块，最后通常有一个结束标记。这种做法能把首字返回时间压缩很多，配合“打字机”效果，用户感知的质量会明显好于一直空转等待。# 伪代码：流式对话接口示意 async def chat_stream(session_id, user_message): history = await session_store.fetch(session_id) prompt = build_prompt(history, user_message) yield sse_format({"delta": ""}) async for text in llm_client.stream_completion(prompt): yield sse_format({"delta": text}) yield sse_format({"done": True}) await session_store.append(session_id, user_message, full_text)流式还有一个副作用要注意：它会让你的错误处理变复杂。普通接口发现模型报错，可以直接返回一个错误JSON；流式接口可能已经吐出去一段文字，这时候再返回错误就来不及了。所以异常检测要前置，在开始推送之前尽可能完成输入校验和权限判断，把中途失败的概率降到最低。3.5 结构化输出：让模型的回答可以被程序消费对话后端除了给人看的内容，还要有一块给程序看的内容。比如客服机器人判断“用户是否满意”、导购机器人把推荐的商品名称提取出来，这些如果靠解析自然语言文本，会非常脆弱，模型换个说法你就识别不了。比较稳妥的做法是要求模型按JSON结构返回，并且在后端做字段校验，失败就让模型重新生成一次或走兜底分支。结构化输出不会百分百成功，所以一定要预留校验环节。我的经验是：先让模型返回格式明确的结果，后端用Schema校验，不通过就重试一次，再不行就走降级逻辑。这套“格式约束加校验重试”的组合，是区分大模型Demo和生产应用的分水岭之一。有些团队绕过这一步，靠正则表达式从文本里提取信息，短期能跑，长期维护成本高得惊人。4. 从Demo到生产要过的五道关4.1 并发与限流：别让一次慢响应把整个服务拖垮把Demo部署上线，第一关就是并发。模型的调用和常规数据库查询不一样，单次响应按秒计，一个慢请求会把连接占住很久。如果你的服务用线程池一个请求对应一个线程，并发一上来，线程数会飞快打满，整个进程都可能假死。正确的姿势是给上游调用设置连接池，限制最大并发，并用队列削峰，超过容量的请求直接返回限流提示，而不是无限等待。限流算法里，计数器最简单但容易被突发流量打穿，滑动窗口更平滑一些，令牌桶则是常见做法。实操上我会按用户维度做漏斗限流，避免单个用户把整体配额吃掉。上线之前，你需要跟业务方确认两个数字：单用户每秒允许的请求数、整服务每分钟的模型调用数。没有这两个数字，限流配置就是拍脑袋，要么限制过严影响正常用户，要么限制过松起不到保护作用。4.2 安全与合规：先做数据分级，再做功能开发大模型应用里，安全不只是防注入，更是防数据泄露。任何对话内容在进入模型之前，都要做一次数据分级：用户名、手机号、内部文档里的敏感字段，该脱敏脱敏，不该进模型的坚决不让进。这里要特别提醒：不要以为只有调商业API才有风险，本地部署模型同样可能通过日志和聊天记录把内部信息暴露给不该看到的人。输出侧也要做审查。模型的回答有时候会出现不合规或违反伦理的内容，生产环境至少要挂一层输出过滤规则。这不是为了限制自由度，而是给“模型不可控”这件事上一道保险。权限模型要独立于对话逻辑，一个用户能问什么、能看到哪些知识库内容，应当在请求进入模型前就完成判断，而不是等模型输出之后再做补救。4.3 成本与模型路由：每一轮对话都是要花真金白银的很多人做大模型应用，成本估算基本靠拍脑袋。其实每一轮对话的成本是可以精确算出来的：一次请求成本约等于输入token数乘以单价，再加上输出token数乘以单价。如果用户持续聊天，又有历史上下文，那么每一轮的输入token会不断增长，整体成本绝不是“一次调用一次钱”那样线性简单。如果你的用户每天产生上万轮对话，成本差异就非常可观了。一个降低成本的有效手段是模型路由。并不是所有问题都需要最贵的模型，意图识别、关键词回复、常见FAQ这类任务，用小模型或开源模型完全够用；只有少数复杂推理问题才值得动用更强的模型。路由层可以先做硬规则，比如按任务类型、输入长度来分流，跑一段时间后再用线上数据来调整阈值。还有一个容易忽视的点：给相似问题加结果缓存，命中缓存时根本不进模型，能省下不少开销。做路由时不要追求一开始就完美，先用简单规则跑起来，再逐步优化。4.4 可观测性：没有日志和追踪，线上问题就只能靠猜生产环境里的模型应用，如果没有观测，等于蒙眼开车。每一层都应该有日志：谁在什么时间发了什么请求、最终拼出的提示词长什么样、模型返回了什么、耗时多少、消耗多少token、有没有走重试或降级。其中提示词日志最容易被忽视，但价值极高，线上提示词一旦改了，效果波动可以直接在日志里对比，不用靠猜。另外，给每个请求分配一个追踪标识，让日志可以串联起网关、业务编排、模型调用、存储操作。否则线上报一个问题，排查起来要翻好几套日志，效率非常低。指标侧至少要关注三类：接口层面的请求量、错误率、延迟分位数；模型层面的调用成功率、平均token数、成本；存储层面的命中率、延迟。这组指标够你应对大多数线上问题。很多人对大模型的监控不知道从何做起，其实核心就一句话：把每次模型交互的输入输出都记录下来，再对上业务结果。4.5 评测与回归：模型的输出无法保证正确，但你可以保证流程大模型应用和传统应用有一个很大的不同：没有单元测试能完全覆盖模型的输出。但这不是不做测试的理由。我建议每个项目从第一天就攒一个评测集，里面放几百条带标准答案或评分规则的问题，覆盖业务的典型场景、边界情况和历史翻车案例。每次改提示词、换模型、调参数，都跑一遍评测集，对比整体得分，再决定是否发布。评测集的价值会随着时间越来越大。你会发现很多“玄学”问题，比如某个提示词改了看起来没变化，结果召回率掉了；某个模型升级了，中文长文本能力却变差了。如果没有评测集，这些变化只能靠用户骂你才能知道，损失就太大了。建立评测集不需要什么高级系统，一开始用一个数据文件配一个评分脚本就够用了。真正难的是坚持，每次改动都跑一遍，别因为嫌麻烦跳过。5. 上线不是结束：持续迭代中的典型坑和对应排查思路5.1 线上问题排查链路：从一个答非所问的客服案例说起以我最近处理的一个客服问答为例：用户反馈机器人回答得驴唇不对马嘴。第一步，从追踪系统里找到那条会话记录，确认请求有没有成功打到模型层。第二步，把当时拼出来的提示词原样恢复，重放一遍，发现模型本身能给出正确回答。第三步，对比线上与重放的差异，最后定位到会话管理模块：上下文存储只保存了用户消息，没有保存系统提示词和工具结果，导致多轮之后关键的限定条件丢失，模型自然越聊越偏。这个案例说明，大模型应用的排查思路不能停留在“重新问一次”，而要按数据流逐层比对请求、提示词、上下文、输出。真正有价值的排查工具，不是某个神秘的调试器，而是你在上线前就埋好的完整日志和追踪。没有它们，百分之八十的线上问题你都只能靠猜。这也是我在前文反复强调可观测性的原因——它不是附加功能，而是生产环境里的生命线。5.2 模型升级和降级：别把上游行为变化当成偶然大模型版本升级比普通代码升级风险更高。你可能只改了提示词里的几个字，或者上游模型悄悄调整了参数，线上效果就变了。所以模型服务的版本升级也要走灰度。最简单的做法是：让一小部分用户或流量继续走老版本，剩下的走新版本，跑几天对比评测集得分和线上反馈，没问题再全量切换。这里要特别留意“上游悄悄升级”的情况。商业模型API经常会在你不注意的时候调整行为，同一段提示词昨天还能用，今天返回格式就变了。所以你的代码不能把模型的任何行为当成永久契约，输出解析要有校验和容错，一旦发现格式漂移，日志和监控要能第一时间告警。我见过不少团队因为没做这个准备，某天醒来发现线上大面积解析失败，一脸茫然。5.3 几个反复出现的高频坑，你迟早会碰上第一个坑，温度参数过度调整。很多小白一遇到回答重复就把随机性系数调高，结果输出越来越乱。实际上采样系数影响的是随机性，不是创造力，调整前要先想清楚，你要解决的是多样性问题还是准确性问题。第二个坑，把模型当成数据库。让模型直接回答具体事实问题，它容易一本正经地胡说，正确做法是让模型调用工具查数据库，把检索结果放进上下文，再由模型组织语言。第三个坑，无限制地加长上下文。每轮都塞完整历史，会导致成本和延迟双双上升，还稀释关键信息，要对历史做截断、摘要和相关性选择。第四个坑，提示词改动不走变更管理。提示词是代码，它应该进版本管理、走评审、留记录，不要在线上随手改一个词测试效果，改完还忘了改了什么。第五个坑，只测正例不测反例。评测集里一定要有边界输入和恶意输入，否则你永远不知道系统在极端情况下会输出什么。这五个坑我在不同项目里反复遇到，每次都能带出一串连锁故障，建议你提前记下来。最后说一下我现在的体会。大模型应用开发的本质，是把一个“聪明但不太靠谱的模型”变成“一套在业务边界内稳定工作的系统”。模型的能力会持续提升，但工程约束——校验、缓存、路由、监控、评测——才是你自己真正积累的资产。希望这份从Demo到生产的实战指南，能帮你把踩过的坑变成自己的工具箱。如果你刚开始做，别追求一步到位，先按这个脉络把一个最小闭环跑通，再逐项补齐，后面会顺很多。
你花一个下午调通了大模型API，做一个智能客服Demo，发到工作群里，大家纷纷点赞，说你牛逼。然后呢？然后就没有然后了。这是太多刚开始接触大模型应用开发的人撞过的同一堵墙——Demo能跑，不代表它能在生产环境里被几十个真实用户同时折腾。作为已经在AI应用开发这条路上踩过不少坑的人，我想把从Demo到生产的完整实战路径摊开来讲。这篇指南是给那些还在“跑通接口”阶段挣扎的小白程序员看的，也是给那些把所有希望押在“换一个更聪明的模型”上、结果照样翻车的人看的。1. 为什么你的大模型Demo总是在“能跑”和“能上线”之间卡住1.1 大多数小白程序员的第一版，其实都是“API贴皮程序”“我接好了，能聊了，为什么还不上线？”当身边的同事第一次把大模型接进项目时，几乎每个人都会这么说。拆开看，所谓“接好了”，往往是拿到一个密钥，在文档里写一段系统提示词，写个循环发请求，把打印出来的回复拼接成聊天记录。这其实不是应用，而是一个API贴皮程序。它只证明了一件事——模型服务商的接口是通的，除此之外什么都证明不了。贴皮程序和真正的应用之间，隔着一整套工程基础设施。举个例子：你的Demo里一个用户聊天，上下文全靠一个全局数组装着，所有请求串行发出，模型响应慢一点，整个界面就卡住。这在本地验证时毫无感觉，一旦同时进来二十个请求，队列会越排越长，最先进入的对话可能五六秒都没反应。小白阶段最容易犯的错，就是把模型的输出当成项目的全部，把请求层、会话层、数据层、监控层统统忽略掉，而这些层恰恰是生产环境真正考验你的地方。1.2 真正的问题：不是模型不行，而是你还没把工程约束当回事很多人在大模型答错的时候，第一反应就是换更大的模型，仿佛模型的参数量是解决一切问题的万能钥匙。可我接过的某个内部知识问答项目就是个典型反例：上线第一天确实有大量答非所问，团队第一反应是换更大规模的模型，结果成本翻了几倍，问题依旧。后来把日志打开才发现，将近四成的请求根本没把用户问题送进模型，而是被前面一层关键词过滤规则误杀，或者被缓存的旧答案命中。问题出在应用代码的编排逻辑上，跟模型智商没有半点关系。这件事给我最大的教训是：大模型应用开发的生产力瓶颈，从来不是模型接口本身能不能给出高质量回答，而是你能不能围绕“不一定正确、不一定稳定、不一定便宜”的输出，搭起一套校验、兜底、回退机制。生产环境看的是延迟、错误率、成本、合规、可观测性，这些约束在Demo阶段几乎不存在。你提前把它们当回事，才能在真正上线那天少熬夜。否则你写的每一个页面、每一个接口，都会在第一次真实流量冲刷下现出原形。1.3 认清“大模型应用开发”和“调接口”的区别如果只能用一句话概括两者的差别，我会说：调接口的目标是“拿到一次回答”，做应用的目标是“反复、大规模、稳定地拿到符合业务约束的回答”。前者是一次性的快乐，后者是重复性的工程。一个对话应用从职责上可以被拆成五层：接入层负责协议和鉴权；编排层负责调用顺序、工具选择、上下文组装；模型层负责真实的大模型调用；数据层负责用户画像、历史会话、外部知识检索；观测层负责记录每一次调用的输入、输出、耗时和成本。理清这五层之后，你会发现“接入哪一个模型”只是其中一个决策点，而不是全部。所有你在Demo里用一行代码糊弄过去的事情——会话怎么存、提示词怎么管、流式怎么推、超时怎么兜底、失败怎么重试——到了生产环境都会变成绕不开的课题。这篇实战指南后面所有内容，都是围绕这些“糊弄过去的事”展开的，希望你能带着这个意识往下看。2. 动手之前先定盘：模型接入、框架选型、上下文方案的取舍2.1 模型接入的三条路：没有完美的方案，只有合适的取舍现在做应用，接入模型无外乎三条路。第一条是走商业模型API，开发速度快、效果稳定、按量付费，但你要接受数据出域、成本随调用量线性上升、可用性受制于上游服务。第二条是拿开源权重模型本地部署，数据自主可控、没有单次token计费，可你需要GPU资源，维护和调优门槛不低，效果也未必比商业API好。第三条是混合路由，简单请求走轻量模型，复杂请求走更强的服务，兼顾成本、性能与体验，但架构复杂度会明显上升。我做项目时经常看到这样的现象：几个人明明只有几十个用户，却花了两周时间搭本地模型集群，美其名曰“数据安全”，最后因GPU资源不够，推理速度惨不忍睹。而另一个团队一上来就走商业API，在线率很高，但数据合规没过审，被迫返工。所以我的建议是：如果你还在验证阶段，不用纠结，直接走商业API，把产品逻辑跑通最重要。等用户量起来、数据要求变严，再逐步加入本地部署或路由策略，这是性价比最高的路径。在模型选择上还有一个容易被忽视的点：不要一门心思只盯“能力最强的模型”。中文长文本、代码生成、多轮指令跟随、工具调用，不同模型在不同子任务上有各自的强项。最好把你业务里的真实输入做成几十个样例，挨个跑一遍，按准确率、格式合规率、成本三项打分，再决定主用哪一个。这个过程不复杂，却能避免上线后因为模型能力和业务需求错配而反复返工。2.2 编排框架要不要用，怎么选才不会变成新的黑盒市面上已经有不少编排类框架，帮你把模型调用、工具调用、记忆管理串起来，对新手来说看起来很诱人。我的态度很明确：快速验证创意可以大胆用，生产环境要克制。框架帮你省掉的“胶水代码”，往往也是你最需要掌控细节的地方。框架封装得越深，线上出问题时，你越不知道它内部替你做了什么，排错难度反而更大。如果你的业务比较复杂，需要很多工具调用、多步推理，那用框架确实能省下大量工作量，但建议只把框架当作调度器，核心业务逻辑自己写，外部工具函数也由你定义好清晰的入参出参。不管你用不用框架，都必须在调用链路上留好原始输入输出的日志，这是所有排错工作的地基。我见过太多人用了框架以后，日志彻底变成黑盒，最后只能把出问题的那条消息一遍遍重放猜原因，效率极低。2.3 上下文与记忆：先分清短期和长期，再决定怎么存做对话应用最容易踩的坑，就是“一股脑把历史全塞给模型”。短期记忆是指近几轮对话，把它作为上下文传给模型，这是保证多轮连贯性的基础。长期记忆则是用户的偏好、历史事实，这部分应该存在数据库或向量检索系统里，只在需要时检索出来拼进提示词，而不是每次都把所有历史全量带上。从成本角度也很好理解：输入token是要花钱的，历史越长，每一轮对话的固定开销就越高，而且无关的旧消息还会干扰模型对当前意图的判断。我通常采用的策略是“会话摘要加最近N轮原文”：系统定期把已经过去的对话压缩成一段摘要，同时只保留最近六到十轮的完整消息。这样既不会丢掉太久远的用户偏好，也不会让上下文无限膨胀。判断这个N到底取多少，没有统一标准，要在成本、效果和开发复杂度之间做实验，而不是拍脑袋写一个固定值。3. 从零手写一个能扛住真实请求的对话后端3.1 目录结构先搭好，才不会被后续的需求改崩很多人写大模型应用，习惯把所有逻辑塞进一个文件里：接口、提示词、会话存储、模型调用全混在一起。一两个接口还好，一旦业务扩展，加一个工具调用、加一种会话清理策略，代码立刻变成一团乱麻。我常用的目录结构长这样，它把上面说的五层对应关系直接落到文件上：app/ entrypoints/ # HTTP接口、流式接口 chat.py services/ # 业务编排 dialogue.py intent.py gateways/ # 模型调用、外部工具 llm_client.py tool_client.py stores/ # 会话存储、向量检索 session_store.py vector_store.py prompts/ # 提示词文件，按版本管理 chat_v1.py observability/ # 日志、追踪、指标 middleware.py这样拆的好处是，排查问题时你能顺着“入口到编排到模型到存储”的路径上下追，而不会在一坨互相调用的函数里迷路。提示词单独放一个目录尤其重要，因为提示词是生产环境里变更最频繁的东西，把它写死在代码里，每次修改都要重新发版，线上失误概率会高很多。每次改动都应该像改业务代码一样走评审、留记录，而不是在聊天调试窗口里复制粘贴临时拼串。3.2 核心接口：请求校验、模型调用、异常兜底接口层的第一件事不是调用模型，而是校验输入。用户标识、消息长度、会话标识、调用频率都要在进入模型前拦一道。很多Demo翻车，就是因为把大模型当成数据库用，用户发一段超长文本就原样塞进去，几千个token被白花掉，还拖慢整个通道。我建议在接口层做三层拦截：格式校验、业务校验和频率限制。格式校验保证请求体合法；业务校验确认这个用户有没有权限发这个请求；频率限制用来挡住异常点击和恶意刷量。异常兜底要分层设计。模型超时或报错时，最忌讳的不是报错本身，而是没有预案。我会在模型调用层设置一个较短的超时时间，第一次超时就重试一次，如果还是失败，就返回一个“服务开小差了，请稍后再试”的兜底文案，同时把完整调用链信息写入日志。这里要记住：给用户看的是体验文案，给排查者看的是完整真相，两者不要在代码里混在一起。我见过不少项目把内部堆栈直接返回给前端，既不安全，也无助于用户理解问题。3.3 多轮对话的会话管理：从全局变量到带过期时间的存储会话管理是所有对话应用逃不开的基础设施。Demo阶段很多人用全局变量保存聊天记录，进程一重启全丢，多实例部署时数据还会串台，用户A发的消息莫名其妙出现在用户B的上下文里。生产环境至少要有一个带过期时间的会话存储，推荐用缓存中间件的哈希结构，以会话标识为key，把最近N轮对话按顺序存进去，同时设置合理的过期时间。这里有个容易被忽略的点：会话过期策略要跟业务匹配。客服场景可能需要保留几天，闲聊机器人可能十几分钟不活跃就该清理。不要觉得“存得久没坏处”，存储成本、恢复后的上下文长度、数据合规问题都会随之而来。另外，多实例部署时一定不要让会话存储依赖进程内存，否则负载均衡把你路由到另一个实例，上下文就全断了。一个简单的会话存储接口，不需要多高的技术含量，但它决定了你的“多轮对话”到底是真多轮，还是形式上的多轮。3.4 流式响应：让用户的等待感从5秒变成0.5秒如果你没有做过流式输出，第一次把模型接入前端，大概率会被一个体验问题困扰：用户在输入框敲完回车，看到光标转了四五秒，然后一整段文字突然刷出来。这在Demo里可以忍，在生产环境会被用户直接骂。解决思路是让模型的输出以流式方式一点一点送到前端，这就是SSE（Server-Sent Events）的思路：后端边接收结果边推送，前端逐字渲染，整个界面看起来就像模型在“打字”。流式输出的坑在于：不是所有模型服务都支持流式，不支持的你需要自己做缓冲；支持的话，你要正确处理编码、错误中断、连接断开。前端收到的不是一个完整的JSON，而是多段以特定前缀开头的文本块，最后通常有一个结束标记。这种做法能把首字返回时间压缩很多，配合“打字机”效果，用户感知的质量会明显好于一直空转等待。# 伪代码：流式对话接口示意 async def chat_stream(session_id, user_message): history = await session_store.fetch(session_id) prompt = build_prompt(history, user_message) yield sse_format({"delta": ""}) async for text in llm_client.stream_completion(prompt): yield sse_format({"delta": text}) yield sse_format({"done": True}) await session_store.append(session_id, user_message, full_text)流式还有一个副作用要注意：它会让你的错误处理变复杂。普通接口发现模型报错，可以直接返回一个错误JSON；流式接口可能已经吐出去一段文字，这时候再返回错误就来不及了。所以异常检测要前置，在开始推送之前尽可能完成输入校验和权限判断，把中途失败的概率降到最低。3.5 结构化输出：让模型的回答可以被程序消费对话后端除了给人看的内容，还要有一块给程序看的内容。比如客服机器人判断“用户是否满意”、导购机器人把推荐的商品名称提取出来，这些如果靠解析自然语言文本，会非常脆弱，模型换个说法你就识别不了。比较稳妥的做法是要求模型按JSON结构返回，并且在后端做字段校验，失败就让模型重新生成一次或走兜底分支。结构化输出不会百分百成功，所以一定要预留校验环节。我的经验是：先让模型返回格式明确的结果，后端用Schema校验，不通过就重试一次，再不行就走降级逻辑。这套“格式约束加校验重试”的组合，是区分大模型Demo和生产应用的分水岭之一。有些团队绕过这一步，靠正则表达式从文本里提取信息，短期能跑，长期维护成本高得惊人。4. 从Demo到生产要过的五道关4.1 并发与限流：别让一次慢响应把整个服务拖垮把Demo部署上线，第一关就是并发。模型的调用和常规数据库查询不一样，单次响应按秒计，一个慢请求会把连接占住很久。如果你的服务用线程池一个请求对应一个线程，并发一上来，线程数会飞快打满，整个进程都可能假死。正确的姿势是给上游调用设置连接池，限制最大并发，并用队列削峰，超过容量的请求直接返回限流提示，而不是无限等待。限流算法里，计数器最简单但容易被突发流量打穿，滑动窗口更平滑一些，令牌桶则是常见做法。实操上我会按用户维度做漏斗限流，避免单个用户把整体配额吃掉。上线之前，你需要跟业务方确认两个数字：单用户每秒允许的请求数、整服务每分钟的模型调用数。没有这两个数字，限流配置就是拍脑袋，要么限制过严影响正常用户，要么限制过松起不到保护作用。4.2 安全与合规：先做数据分级，再做功能开发大模型应用里，安全不只是防注入，更是防数据泄露。任何对话内容在进入模型之前，都要做一次数据分级：用户名、手机号、内部文档里的敏感字段，该脱敏脱敏，不该进模型的坚决不让进。这里要特别提醒：不要以为只有调商业API才有风险，本地部署模型同样可能通过日志和聊天记录把内部信息暴露给不该看到的人。输出侧也要做审查。模型的回答有时候会出现不合规或违反伦理的内容，生产环境至少要挂一层输出过滤规则。这不是为了限制自由度，而是给“模型不可控”这件事上一道保险。权限模型要独立于对话逻辑，一个用户能问什么、能看到哪些知识库内容，应当在请求进入模型前就完成判断，而不是等模型输出之后再做补救。4.3 成本与模型路由：每一轮对话都是要花真金白银的很多人做大模型应用，成本估算基本靠拍脑袋。其实每一轮对话的成本是可以精确算出来的：一次请求成本约等于输入token数乘以单价，再加上输出token数乘以单价。如果用户持续聊天，又有历史上下文，那么每一轮的输入token会不断增长，整体成本绝不是“一次调用一次钱”那样线性简单。如果你的用户每天产生上万轮对话，成本差异就非常可观了。一个降低成本的有效手段是模型路由。并不是所有问题都需要最贵的模型，意图识别、关键词回复、常见FAQ这类任务，用小模型或开源模型完全够用；只有少数复杂推理问题才值得动用更强的模型。路由层可以先做硬规则，比如按任务类型、输入长度来分流，跑一段时间后再用线上数据来调整阈值。还有一个容易忽视的点：给相似问题加结果缓存，命中缓存时根本不进模型，能省下不少开销。做路由时不要追求一开始就完美，先用简单规则跑起来，再逐步优化。4.4 可观测性：没有日志和追踪，线上问题就只能靠猜生产环境里的模型应用，如果没有观测，等于蒙眼开车。每一层都应该有日志：谁在什么时间发了什么请求、最终拼出的提示词长什么样、模型返回了什么、耗时多少、消耗多少token、有没有走重试或降级。其中提示词日志最容易被忽视，但价值极高，线上提示词一旦改了，效果波动可以直接在日志里对比，不用靠猜。另外，给每个请求分配一个追踪标识，让日志可以串联起网关、业务编排、模型调用、存储操作。否则线上报一个问题，排查起来要翻好几套日志，效率非常低。指标侧至少要关注三类：接口层面的请求量、错误率、延迟分位数；模型层面的调用成功率、平均token数、成本；存储层面的命中率、延迟。这组指标够你应对大多数线上问题。很多人对大模型的监控不知道从何做起，其实核心就一句话：把每次模型交互的输入输出都记录下来，再对上业务结果。4.5 评测与回归：模型的输出无法保证正确，但你可以保证流程大模型应用和传统应用有一个很大的不同：没有单元测试能完全覆盖模型的输出。但这不是不做测试的理由。我建议每个项目从第一天就攒一个评测集，里面放几百条带标准答案或评分规则的问题，覆盖业务的典型场景、边界情况和历史翻车案例。每次改提示词、换模型、调参数，都跑一遍评测集，对比整体得分，再决定是否发布。评测集的价值会随着时间越来越大。你会发现很多“玄学”问题，比如某个提示词改了看起来没变化，结果召回率掉了；某个模型升级了，中文长文本能力却变差了。如果没有评测集，这些变化只能靠用户骂你才能知道，损失就太大了。建立评测集不需要什么高级系统，一开始用一个数据文件配一个评分脚本就够用了。真正难的是坚持，每次改动都跑一遍，别因为嫌麻烦跳过。5. 上线不是结束：持续迭代中的典型坑和对应排查思路5.1 线上问题排查链路：从一个答非所问的客服案例说起以我最近处理的一个客服问答为例：用户反馈机器人回答得驴唇不对马嘴。第一步，从追踪系统里找到那条会话记录，确认请求有没有成功打到模型层。第二步，把当时拼出来的提示词原样恢复，重放一遍，发现模型本身能给出正确回答。第三步，对比线上与重放的差异，最后定位到会话管理模块：上下文存储只保存了用户消息，没有保存系统提示词和工具结果，导致多轮之后关键的限定条件丢失，模型自然越聊越偏。这个案例说明，大模型应用的排查思路不能停留在“重新问一次”，而要按数据流逐层比对请求、提示词、上下文、输出。真正有价值的排查工具，不是某个神秘的调试器，而是你在上线前就埋好的完整日志和追踪。没有它们，百分之八十的线上问题你都只能靠猜。这也是我在前文反复强调可观测性的原因——它不是附加功能，而是生产环境里的生命线。5.2 模型升级和降级：别把上游行为变化当成偶然大模型版本升级比普通代码升级风险更高。你可能只改了提示词里的几个字，或者上游模型悄悄调整了参数，线上效果就变了。所以模型服务的版本升级也要走灰度。最简单的做法是：让一小部分用户或流量继续走老版本，剩下的走新版本，跑几天对比评测集得分和线上反馈，没问题再全量切换。这里要特别留意“上游悄悄升级”的情况。商业模型API经常会在你不注意的时候调整行为，同一段提示词昨天还能用，今天返回格式就变了。所以你的代码不能把模型的任何行为当成永久契约，输出解析要有校验和容错，一旦发现格式漂移，日志和监控要能第一时间告警。我见过不少团队因为没做这个准备，某天醒来发现线上大面积解析失败，一脸茫然。5.3 几个反复出现的高频坑，你迟早会碰上第一个坑，温度参数过度调整。很多小白一遇到回答重复就把随机性系数调高，结果输出越来越乱。实际上采样系数影响的是随机性，不是创造力，调整前要先想清楚，你要解决的是多样性问题还是准确性问题。第二个坑，把模型当成数据库。让模型直接回答具体事实问题，它容易一本正经地胡说，正确做法是让模型调用工具查数据库，把检索结果放进上下文，再由模型组织语言。第三个坑，无限制地加长上下文。每轮都塞完整历史，会导致成本和延迟双双上升，还稀释关键信息，要对历史做截断、摘要和相关性选择。第四个坑，提示词改动不走变更管理。提示词是代码，它应该进版本管理、走评审、留记录，不要在线上随手改一个词测试效果，改完还忘了改了什么。第五个坑，只测正例不测反例。评测集里一定要有边界输入和恶意输入，否则你永远不知道系统在极端情况下会输出什么。这五个坑我在不同项目里反复遇到，每次都能带出一串连锁故障，建议你提前记下来。最后说一下我现在的体会。大模型应用开发的本质，是把一个“聪明但不太靠谱的模型”变成“一套在业务边界内稳定工作的系统”。模型的能力会持续提升，但工程约束——校验、缓存、路由、监控、评测——才是你自己真正积累的资产。希望这份从Demo到生产的实战指南，能帮你把踩过的坑变成自己的工具箱。如果你刚开始做，别追求一步到位，先按这个脉络把一个最小闭环跑通，再逐项补齐，后面会顺很多。