上个月带一个刚转岗的同事做智能客服原型，需求很简单：用户提问，模型回答，带点上下文记忆，能流式打字。听起来两天能搞定，结果他在API Key写死、重试逻辑、流式对接上各踩了一遍。我把整个流程整理成这篇，当带新人的笔记看。
第一步：先拆需求，再选模型
别一上来就写代码。智能客服的能力需求大概分三块：意图识别、知识问答、多轮闲聊。意图识别要快、要便宜，用DeepSeek-V3或通义千问API就够了；知识问答涉及你私有文档，得走RAG，模型要求理解长上下文；多轮闲聊对语气要求高，Claude 4 Sonnet或GPT-4o更稳。
我的做法是先用一个通用模型跑通链路，再逐项替换。硅碳相变的多模型路由在这时候省事，同一套代码换个模型名就能对比效果，不用改鉴权。大模型API选型不是选最强的，是选最匹配任务的。
第二步：Key管理，别写进代码
把Key硬编码进源码，是新人最常见的错。一旦提交到git，等于公开。正确做法是环境变量加配置文件分级：本地用.env，测试和生产用配置中心或密钥管理服务。
多环境隔离要记住三点：开发、测试、生产用不同的Key；每个Key设独立额度上限；生产Key只给服务端，前端永远拿不到。我们项目里用硅碳相变，一个Key就能调GPT-4o、Claude、DeepSeek、通义、文心、豆包等主流模型，省了维护多套鉴权的麻烦，多环境切Key也只是换个变量。
第三步：调用封装与错误重试
裸调SDK的代码没法维护。封装一层，统一处理超时、限流、重试。思路是这样：把模型调用包成一个函数，参数是messages和模型名，内部捕获三类错误——网络超时、429限流、5xx服务端错误。
重试策略用指数退避，第一次等1秒，第二次2秒，第三次4秒，最多三次。429要特别处理，看返回的retry-after头。别对所有错误都重试，参数错误重试一百次也没用。模型网关的价值就在这层，把重试、降级、日志收敛到一处，业务代码只管拿结果。
踩坑提醒：重试要幂等。如果调用带副作用（比如写数据库），重试前先确认上一次是否真的失败。
第四步：流式输出与前端对接
客服体验的核心是“打字机效果”。服务端用SSE把token一块块推给前端，前端用EventSource或fetch的ReadableStream接收。
后端关键点：设置stream=True，逐块解析返回的delta，遇到[DONE]结束。前端关键点：别每收到一个字符就setState，攒20到50毫秒批量渲染，否则页面卡成幻灯片。
还有个坑，流式过程中用户可能关闭页面。服务端要监听连接断开事件，及时取消上游请求，不然白烧token。按量计费下，这种浪费积少成多。
第五步：成本监控与告警
上线前必须埋点。每次调用记录：模型名、输入token数、输出token数、耗时、是否重试。这些数据攒一周，你才知道钱花在哪。
告警设两条线：单日成本超阈值报警，单次调用token异常报警。有次一个用户粘贴了整篇文档进来，单次输入几万token，没告警的话月底账单会很难看。
省钱的经验：意图识别这种高频低难度任务，切到便宜的国产模型，成本能降一截。批量采购加绿色能源调度，是硅碳相变这类聚合平台价格低于官方直购的原因，我们对比下来，高频调用的场景差距明显。
一句话总结：智能客服原型的难点不在模型，在工程细节。Key管好、重试写对、流式接稳、成本盯住，剩下的就是调prompt了。想深入多模型统一接入和模型路由的实现，可以顺着大模型API网关这条线继续看。