1. 从一次线上告警说起为什么第二轮对话必崩线上服务刚上线那会儿监控面板上出现了一个极其规律的现象单轮对话的接口成功率稳定在 99.9% 以上可只要用户连续发第二条消息服务端就大概率返回 500。更诡异的是这个 500 不是偶发的而是第二轮必崩——第一轮正常返回第二轮请求打进来日志里立刻出现异常堆栈。当时团队里第一反应是模型服务不稳定有人提议加超时重试有人建议换一个推理后端。但我盯着日志看了半小时发现一个被忽略的细节第一轮请求的响应体里模型返回的字段结构和第二轮请求体里我们回传的字段结构根本不是同一套 schema。也就是说问题不在模型而在我们自己的工程链路上。这个标题里说的3 个工程问题叠加没有一层该由模型背锅就是这次排查的真实写照。多轮对话看起来只是把历史消息再发一遍但真正落地时会牵扯到会话状态管理、上下文序列化、请求体构造三个独立层面任何一层出问题都会在第二轮集中爆发。这篇文章我会把这三次踩坑的完整链路拆开讲包括每一层为什么会在第二轮才暴露、怎么定位、怎么修以及我后来总结出的一套多轮对话自检清单。适合正在做对话类应用、被多轮问题折磨过的后端和全栈同学参考。2. 第一层坑会话状态被无状态接口吃掉了2.1 现象第一轮正常第二轮历史为空最开始的接口设计是纯无状态的客户端每次请求带上完整的messages数组服务端不做任何存储收到就直接转发给模型。听起来很干净但实际跑起来第二轮请求里的messages只有一条——就是用户刚发的那句话第一轮的问答记录凭空消失了。排查下来发现前端在拼接历史时用了一个useState存对话列表但每次发送请求后调用了setMessages([])做清空输入框结果把整个历史列表也一起清掉了。这是一个非常典型的前端状态管理误用把清空当前输入和清空对话历史混成了一个操作。// 错误写法一次 setState 把历史和输入框都清了 const handleSend async (text) { const res await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages: [...messages, { role: user, content: text }] }) }); setMessages([]); // 本意是清空输入框实际把历史也清了 };正确的做法是把输入框内容和对话历史拆成两个独立状态const [input, setInput] useState(); const [history, setHistory] useState([]); const handleSend async (text) { const nextHistory [...history, { role: user, content: text }]; const res await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages: nextHistory }) }); const data await res.json(); setHistory([...nextHistory, { role: assistant, content: data.reply }]); setInput(); // 只清输入框 };2.2 为什么这个坑偏偏在第二轮才炸第一轮请求时messages数组里只有用户刚输入的一条即使历史被清空也看不出来因为本来就没有历史。到了第二轮用户期望带上第一轮的问答但历史已经被清掉了服务端收到的只有孤零零一条新消息。模型本身没问题它老老实实回答了这条消息但用户看到的是它忘了刚才说过什么体验上等同于崩溃。这里有个容易被忽视的点很多团队会用单轮测试通过来验收多轮功能。测试同学发一句你好返回正常就认为接口没问题。但多轮对话的核心价值恰恰在第二轮之后单轮测试根本覆盖不到状态传递这条链路。我后来强制要求所有对话类接口的测试用例必须包含连续三轮以上的场景就是为了堵这个漏洞。2.3 状态该放前端还是后端一次架构层面的取舍修完前端状态后我们讨论了一个更根本的问题会话历史到底该由谁维护两种方案各有代价。方案优点缺点适用场景前端维护完整历史服务端无状态易水平扩展请求体随轮次线性增长易被篡改轻量应用、轮次少的场景后端维护会话请求体小历史可控需要存储层有状态难扩展长对话、多端同步场景我们最终选了折中方案后端只存最近 N 轮的摘要前端传最近 3 轮的完整消息。这样既控制了请求体大小又保证了短期上下文的连贯性。这个取舍没有标准答案但如果你的应用轮次普遍超过 10 轮纯前端维护历史迟早会遇到请求体过大和 token 超限的问题。3. 第二层坑上下文序列化时的角色字段错位3.1 一个看不见的字段让模型失忆前端状态修好之后第二轮请求终于带上了完整历史。但新的 500 又来了这次错误信息变成了invalid message role。抓包看请求体发现历史消息的role字段全是undefined。原因在于我们前端存历史时用的是{ type: user, text: ... }这种自定义结构而转发给模型时需要的是{ role: user, content: ... }。中间少了一层转换导致role字段直接丢失。模型服务收到没有 role 的消息无法判断哪句是用户说的、哪句是助手说的直接报错。// 前端内部结构 { type: user, text: 帮我写个函数 } // 模型需要的结构 { role: user, content: 帮我写个函数 } // 缺失的转换层 const toModelFormat (msg) ({ role: msg.type user ? user : assistant, content: msg.text });3.2 序列化层的三种常见错位这个坑的本质是内部数据结构和外部协议结构不一致。我后来复盘发现序列化错位至少有三种典型形态第一种是字段名不一致就像上面type对role、text对content。这种最容易发现因为报错明显。第二种是角色枚举值不一致。有的系统内部用human/ai有的用user/bot转发时没做映射模型收到human这种非标准角色行为不可预期。标准协议里通常只认user、assistant、system三种多一个都不行。第三种最隐蔽消息顺序错乱。历史数组本应是[user, assistant, user, assistant]交替出现但某次合并操作把两条 user 消息拼在了一起模型收到连续两条 user上下文逻辑就断了。这种不会报错但回答质量会明显下降排查起来非常痛苦。3.3 用一层显式的 Adapter 把协议隔离掉吃过这次亏之后我在项目里强制加了一层MessageAdapter所有进出模型服务的消息都必须经过它转换业务代码不允许直接构造模型请求体。class MessageAdapter { static toModel(messages) { return messages.map((m, idx) { if (!m.role || ![user, assistant, system].includes(m.role)) { throw new Error(Invalid role at index ${idx}: ${m.role}); } return { role: m.role, content: String(m.content ?? ) }; }); } static validate(messages) { // 检查是否 user/assistant 交替system 只能在开头 for (let i 0; i messages.length; i) { if (messages[i].role system i ! 0) { throw new Error(system message must be first); } } return true; } }这层 Adapter 的价值不只是转换字段更重要的是把校验前置。以前是模型服务报错我们才知道格式不对现在是请求发出前就在本地抛异常定位成本从翻模型日志降到看本地堆栈。这个改动上线后同类 500 直接归零。提示Adapter 里一定要做content的非空和类型校验。我遇到过content传了null导致整个请求体序列化异常的情况模型服务返回的 500 里根本看不出是哪个字段的问题。4. 第三层坑请求体构造时的 token 与超时叠加4.1 第二轮请求体突然翻倍前两层修完多轮对话基本能跑通了。但压测时发现一个性能问题第一轮请求平均 200ms 返回第二轮开始响应时间飙升到 2s 以上偶尔还会超时返回 500。抓包对比请求体大小第一轮约 300 字节第二轮直接到了 1.5KB第三轮 3KB呈线性增长。原因很简单每一轮都把之前所有轮次的完整消息原样带上历史越长请求体越大模型处理时间越长。这里有个计算需要说清楚。假设每轮对话平均 200 个 token模型处理速度是每秒 50 个 token那么第 1 轮200 token约 4 秒含网络和排队第 5 轮1000 token约 20 秒第 10 轮2000 token约 40 秒这还没算上模型输出本身的 token。所以如果不做上下文裁剪多轮对话的响应时间会随轮次线性恶化最终必然超时。4.2 上下文窗口不是能塞多少塞多少很多人以为只要不超过模型的最大上下文窗口就没事但实际上有效上下文和最大上下文是两回事。模型在超长上下文里的注意力会稀释早期信息容易被忽略回答质量反而下降。而且请求体越大网络传输和序列化的开销也越大。我们后来定了一套裁剪策略按优先级保留system 提示词永远保留放在最前最近 3 轮完整对话保证短期连贯更早的历史做摘要用一次额外的模型调用把早期对话压缩成一段摘要超出预算的部分直接丢弃从最老的开始丢function buildContext(history, maxTokens 3000) { const system history.filter(m m.role system); const recent history.filter(m m.role ! system).slice(-6); // 最近3轮 const older history.filter(m m.role ! system).slice(0, -6); let context [...system]; if (older.length 0) { context.push({ role: system, content: 早期对话摘要${summarize(older)} }); } context.push(...recent); // 粗略估算 token超了就继续裁 while (estimateTokens(context) maxTokens context.length 2) { context.splice(1, 1); // 从摘要后开始删 } return context; }4.3 超时设置里的一个反直觉结论排查超时的时候我们一开始把超时时间从 10s 调到了 30s想着给模型多点时间。结果 500 反而更多了。原因是超时时间调长只是把失败从快速失败变成了慢速失败用户等待更久连接池被占满后续请求排队雪崩更快。正确的做法是反过来给单次请求设一个合理的短超时比如 8s超时后立即降级——要么返回当前对话过长请开启新会话要么用裁剪后的短上下文重试一次。我们最终用的是8s 超时 裁剪重试一次的策略500 率从 12% 降到了 0.3%。策略超时设置500 率用户平均等待原始10s12%6.2s调长超时30s18%15.4s短超时降级8s0.3%2.1s这张表是我们实测三轮压测的结果第三行才是可用的方案。调长超时那次的 500 率不降反升就是因为连接池被慢请求拖垮了。5. 三层问题为什么会叠加在第二轮爆发5.1 第一轮是幸运路径第二轮才是真实路径把三层问题放在一起看会发现一个共同规律它们都只在有历史上下文时才暴露。状态被清空第一轮本来就没历史看不出来序列化错位第一轮只有一条消息role 字段即使丢了也可能被默认处理请求体膨胀第一轮请求体最小永远在超时阈值内所以第一轮的成功是一种幸运路径它恰好绕过了所有需要历史才能触发的逻辑。这也是为什么很多团队上线时觉得没问题用户一用就崩——因为验收测试只走了幸运路径。5.2 排查顺序从外到内从显到隐我后来总结的排查顺序是这样的按这个顺序走能最快定位先看请求体抓包确认第二轮请求里到底带了什么历史在不在、字段对不对再看服务端日志确认收到的和发出的请求体是否一致有没有被中间件改写最后看模型响应如果前两步都正常才怀疑模型侧这个顺序的核心逻辑是越靠近客户端的层越容易出低级错误也越容易验证。直接怀疑模型是最没效率的做法因为模型侧的问题通常最难复现、最难定位。5.3 一个反直觉的经验模型往往是最稳的那一层这次排查最大的收获是在 500 错误里模型服务本身出问题的概率远低于工程链路。模型服务通常有完善的输入校验和错误码格式不对它会明确告诉你哪里不对。真正难查的是我们自己拼装请求体时的各种想当然。我后来在团队里立了个规矩任何对话类接口报 500先假设是工程问题把请求体完整打印出来看三遍再考虑模型。这个规矩执行之后平均定位时间从半天缩短到了半小时。6. 多轮对话上线前的自检清单6.1 状态层自检对话历史和输入框状态是否分离有没有一处setState同时清空两者的代码历史是前端维护还是后端维护如果是前端请求体大小有没有上限保护刷新页面后历史会不会丢如果会是否需要持久化到本地存储6.2 序列化层自检内部消息结构和模型协议结构之间有没有显式的 Adapterrole 字段有没有做枚举校验非法值是在本地拦截还是等模型报错消息顺序有没有校验连续两条同角色消息会不会被放行6.3 请求构造层自检有没有上下文裁剪策略裁剪的优先级是什么token 预算是多少超预算时是丢弃还是摘要超时时间设了多久超时后是直接失败还是有降级重试// 上线前跑一遍这个自检函数 function preflightCheck(history) { const issues []; if (!Array.isArray(history) || history.length 0) { issues.push(history is empty); } history.forEach((m, i) { if (![user, assistant, system].includes(m.role)) { issues.push(invalid role at ${i}: ${m.role}); } if (typeof m.content ! string || m.content.length 0) { issues.push(empty content at ${i}); } }); const tokens estimateTokens(history); if (tokens 3000) { issues.push(token budget exceeded: ${tokens}); } return issues; }这个自检函数我放在请求发送前调用开发环境直接抛异常生产环境打日志并触发裁剪。上线三个月多轮相关的 500 再没出现过。6.4 测试用例必须覆盖的三种场景最后说测试。单轮测试通过不代表多轮没问题我要求所有对话接口的测试用例必须包含连续 5 轮以上的完整对话验证状态传递和请求体增长中途刷新页面后继续对话验证历史持久化超长对话20 轮以上验证裁剪和超时降级这三种场景覆盖了这次踩的所有坑。尤其是第三种很多团队根本不会测但它恰恰是生产环境最容易出问题的场景——真实用户就是会一直聊下去聊到你的上下文爆掉为止。我个人在实际操作中的体会是多轮对话的复杂度不在模型而在把历史正确地、经济地、安全地传给模型这条链路上。把这条链路当成一个独立的工程模块来设计而不是随手拼个数组就发出去能省掉后面 90% 的排查时间。