企业官网建设流程全解析

1. 问题现象与排查思路拆解

多轮对话系统在第一轮响应正常、第二轮直接抛出 500 错误，这个现象在工程实践中出现的频率远比想象中高。很多团队第一反应是"模型是不是不稳定"，然后花大量时间去调 prompt、换模型、加超时，结果问题依旧。我踩过这个坑之后最大的体会是：第二轮才 500，几乎从来不是模型本身的问题，而是三层工程问题在同一时刻叠加爆发。

先把现象拆开看。第一轮正常说明基础链路是通的——请求能到达服务端、模型能返回、响应能序列化。第二轮才挂，意味着问题出在"状态"上。第一轮和第二轮最大的区别是什么？是第一轮产生了需要被保存、传递、复用的上下文。所以排查方向应该立刻从"模型层"转向"状态层"。

我一般会按这个顺序定位：

• 第一层：会话状态存储。第一轮的对话历史存到哪里了？内存、Redis、数据库还是直接塞回客户端？第二轮读取时是否真的读到了？
• 第二层：上下文拼装与序列化。读到的历史如何拼进新一轮请求？有没有超长、编码、类型不匹配的问题？
• 第三层：并发与资源生命周期。多轮之间是否有连接池、锁、临时对象被提前释放？

这三层任意一层出问题都可能表现为 500，而"第二轮才出现"这个特征，恰恰说明是第一轮写入的状态在第二轮被消费时炸了。下面我逐层拆解，每一层都会给出我实际排查时用的方法和判断依据。

提示：遇到"第二轮 500"，先别动模型参数。把第一轮的完整请求和响应、第二轮的完整请求体都打出来对比，80% 的问题在对比中就能现形。

2. 第一层：会话状态存储的隐性陷阱

2.1 内存存储为什么在第二轮就崩

最常见的实现是拿一个全局字典或者进程内缓存来存会话历史，键是 session_id，值是消息列表。第一轮写入没问题，第二轮读取理论上也没问题——但实际部署中，服务往往是多实例的。第一轮请求打到实例 A，历史存在 A 的内存里；第二轮请求被负载均衡打到实例 B，B 的内存里根本没有这个 session_id。

这时候如果代码写得不严谨，比如直接history = store[session_id]而不做存在性判断，就会抛 KeyError，被全局异常处理器捕获后返回 500。这就是典型的"第一轮正常、第二轮 500"，而且它跟模型一点关系都没有。

我见过更隐蔽的写法：用store.get(session_id, [])兜底，看起来不会崩，但第二轮拿到的是空历史，模型基于空上下文回答，业务上表现为"失忆"，如果下游还有基于历史长度的校验逻辑，照样可能触发 500。所以兜底不等于正确，要区分"没崩"和"逻辑对"。

判断方法很简单：在第二轮入口打一行日志，输出 session_id 和读到的历史条数。如果条数是 0 或者直接抛异常，问题就锁定在存储层了。

2.2 分布式存储的读写一致性坑

换成 Redis 或数据库之后，内存问题解决了，但新的坑来了。第一轮写入 Redis 如果是异步的，或者写主读从、从库有复制延迟，第二轮紧接着读就可能读不到。多轮对话的特点是两轮之间间隔极短，用户点一下"继续"可能就几百毫秒，这个时间窗口刚好卡在复制延迟里。

我处理过一个案例：写入用的是SET不带过期，读取用的是另一个连接池，结果因为连接池配置里开了读写分离，第二轮读从库读到了空值。排查时单独测 Redis 读写都正常，一上量就偶发，最后是靠对比主从的 key 才定位到。

解决思路有两个方向：

• 强一致读：会话这种强依赖上一轮状态的场景，第二轮读取强制走主库，或者写入后立即用同一个连接读一次确认。
• 客户端回传：把历史直接放在客户端，每轮请求带上完整历史，服务端无状态。这样彻底绕开存储一致性问题，代价是请求体变大、有被篡改的风险。

我个人的选择是：短会话用客户端回传，长会话用 Redis 强一致读。短会话（比如三五轮）回传成本低、最稳；长会话回传会让请求体膨胀到几 KB 甚至几十 KB，这时候必须服务端存。

2.3 存储层的参数与容量陷阱

还有一个容易被忽略的点：单条会话的存储上限。Redis 单 value 有大小限制，数据库字段有长度限制，如果第一轮的历史里包含了很长的模型输出，第二轮写入时可能就超限了。表现同样是第一轮正常、第二轮 500，因为第二轮才需要把"第一轮历史 + 第二轮输入"一起写回去。

排查时我会重点看这几个参数：

注意：历史截断策略一定要在写入前做，而不是读取后做。写入前截断能保证存储不超限，读取后截断只是让模型少看几条，存储该炸还是炸。

3. 第二层：上下文拼装与序列化的细节

3.1 消息格式在第二轮为什么变了

第一轮请求通常只有一条 user 消息，格式简单。第二轮要把历史拼进去，变成[system, user, assistant, user]这样的结构。问题往往出在assistant 消息的来源上——第一轮模型返回的原始响应，和拼进历史时需要的格式，往往不是一回事。

模型返回的可能是带 markdown 代码块、带特殊字符、带换行的长文本，直接塞进 JSON 数组里，如果序列化库对某些字符处理不当，第二轮请求体就是非法 JSON，服务端解析失败直接 500。我遇到过模型输出里带了未转义的控制字符，第一轮响应能返回（因为只是字符串），第二轮拼装时序列化就炸了。

判断方法：把第二轮实际发出的请求体完整打印出来，用 JSON 校验工具过一遍。如果校验不过，问题就在序列化。

3.2 角色顺序与消息校验

很多模型服务对消息顺序有强校验：必须 user 开头、user/assistant 交替、最后一条必须是 user。第一轮天然满足，第二轮如果拼装逻辑写错，比如把两条 user 消息连在一起，或者历史里混入了空的 assistant 消息，服务端校验不通过就会返回错误。

我见过最典型的 bug 是：第一轮模型返回为空（比如被内容过滤拦截），代码仍然把这条空 assistant 消息存进了历史。第二轮拼装时出现[user, assistant(空), user]，某些服务端会认为 assistant 内容为空是非法请求，直接 500。

所以拼装前必须做消息清洗：

• 过滤掉 content 为空或纯空白的消息
• 确保 user/assistant 严格交替
• 确保最后一条是当前轮的 user 消息
• 系统消息只保留一条且放最前

这几步看起来琐碎，但能挡掉大量"第二轮才出现"的 500。

3.3 上下文长度与 token 计算

第二轮开始，上下文长度是累加的。第一轮可能只有几百 token，第二轮加上历史可能就逼近模型上限了。如果代码里没有做 token 预算控制，直接把超长上下文发给模型，服务端会因为超出最大长度而报错。

这里的关键是提前计算 token 而不是等模型报错。我的做法是维护一个粗略的 token 估算函数（中文按字符数近似，英文按词数近似），在拼装完成后先估算总长度，超过阈值就按策略截断：

• 优先保留 system 消息
• 从最旧的历史开始丢弃
• 保留最近 N 轮完整对话
• 对超长的单条消息做中间截断

提示：token 估算不需要精确，宁可保守一点。估算值留 10% 余量，比精确计算后卡在边界上要稳得多。

4. 第三层：并发与资源生命周期的暗雷

4.1 连接池在第二轮被耗尽

第一轮请求占用了一个到模型服务的连接，如果这个连接在响应返回后没有被正确释放（比如流式响应没读完就中断、异常路径没走 finally），连接就泄漏了。第一轮泄漏一个，第二轮再要连接时池子空了，获取连接超时，抛异常返回 500。

这种问题的特征是：单次测试正常，压测或连续多轮才出现。因为单次测试时池子里还有空闲连接，连续请求才会把泄漏累积到耗尽。

排查方法：在获取连接前后打日志，记录池子的活跃连接数和空闲连接数。如果活跃数只增不减，就是泄漏。修复的核心是确保所有路径（正常、异常、超时、取消）都能释放连接，用 try-finally 或者上下文管理器包住。

4.2 会话锁与超时

为了防止同一会话的并发请求互相覆盖历史，很多实现会加会话级锁。第一轮加锁、处理、解锁，没问题。第二轮如果第一轮的锁因为异常没释放，第二轮就会一直等锁直到超时，返回 500。

锁的问题在于异常路径。正常流程 unlock 很容易写对，但一旦中间抛异常，没有 finally 就会死锁。我建议用带超时的锁，并且把锁的获取和释放都放在 try-finally 里。

另外要注意锁的粒度。如果锁的是全局而不是单个 session_id，那所有会话都会互相阻塞，第一轮稍微慢一点，第二轮就全堵住了。锁一定要按 session_id 分片。

4.3 临时对象与异步任务的生命周期

如果多轮对话里涉及异步任务（比如后台生成摘要、异步写日志），第一轮启动的任务可能持有对会话对象的引用。第二轮如果这个对象已经被回收或重置，异步任务再访问就会出问题。这类 bug 最难查，因为它是时序相关的，复现不稳定。

我的经验是：异步任务只传值，不传对象引用。需要什么数据就在启动任务时拷贝一份传进去，避免跨轮次共享可变状态。

5. 常见问题速查与排查清单

把上面三层的问题整理成一张速查表，遇到"第二轮 500"时按顺序过一遍，基本能覆盖九成以上的场景。

排查时我遵循一个原则：先复现，再定位，最后修。不要看到 500 就改代码，先想办法稳定复现，复现不了的问题改了也不知道有没有改对。复现的手段包括：固定 session_id 连续请求、模拟多实例、注入延迟、构造超长输入。

注意：日志一定要打全。第一轮的请求、响应、写入的存储内容，第二轮的请求、读取的存储内容、拼装后的最终请求体，这五样缺一不可。很多团队只打最终请求体，结果定位时发现根本不知道历史是从哪来的。

6. 我的实操心得与避坑建议

做了这么多轮对话系统，我最大的心得是：多轮对话的复杂度不在模型，而在状态管理。模型是无状态的，你给它什么它就基于什么回答。所有"第二轮才出现"的问题，本质都是状态在轮次之间传递时出了岔子。

几个我反复验证有效的做法：

第一，把每一轮当成独立请求来设计。服务端尽量无状态，需要的历史由客户端带上或者从存储显式读取。无状态的服务天然没有跨轮次的资源泄漏和锁问题。

第二，存储层和模型层解耦。历史存什么格式、怎么截断、怎么清洗，这些逻辑独立成模块，不要和调用模型的代码混在一起。这样出问题时能快速判断是存储的锅还是拼装的锅。

第三，给会话加一个全局的 trace_id。从第一轮开始就带上，每一轮的所有日志都打这个 id。排查时按 id 一搜，整条链路清清楚楚，比在茫茫日志里捞要快十倍。

第四，上线前做连续多轮压测。单轮测试永远发现不了第二轮的问题。至少模拟十轮连续对话，并且用多个 session 并发跑，才能把连接池、锁、存储一致性这些问题暴露出来。

最后说一个我踩过的坑：有一次排查了半天，最后发现是网关层对请求体大小有限制，第一轮请求小没事，第二轮带上历史超了网关限制，网关直接返回 500，根本没到应用层。所以排查时别忘了看网关和负载均衡的日志，问题不一定在你自己的代码里。

这个方向后续还可以继续深挖，比如流式响应下的多轮状态管理、跨设备会话同步、历史压缩与摘要生成，每一个都是独立的工程话题。但万变不离其宗：先把状态管明白，再谈模型效果。