过去一段时间，我频繁遇到 ChatGPT 的一个问题：
消息流中的错误
英文界面通常对应：
Error in message stream
如果只是普通聊天，这个问题最多是让人重新发送一次消息。但我的使用场景不是普通聊天，而是长期让 ChatGPT 执行翻译生成、独立审核、代码分析、文档整理等长时间任务。
很多任务一次会持续 20 分钟以上。
因此，一旦在任务后半段出现「消息流中的错误」，损失就会非常明显。有时候前面已经进行了大量读取、分析和处理，最后却因为消息流中断而无法正常完成。
更麻烦的是，在错误最频繁的那段时间，我还同时观察到了另一种现象：
ChatGPT 的执行质量明显下降。
我平时把这种情况简称为「降智」。
例如，已经明确要求读取项目规范，却直接跳过；已经存在正式恢复路径，却突然从头重新生成；前面刚确认过的项目事实，后面又像完全不知道一样；开始询问原本完全不需要再次确认的问题；长任务中途失去上下文一致性。
到了后来，我把 ChatGPT 的并发使用方式调整了一下。
结果很意外：
消息流中的错误基本不再出现，“降智”也没有再明显出现。
现在看来，我大概率已经找到了一个对自己非常有效的解决办法。
一、问题最严重的时候：6 个 ChatGPT 标签页，3 个长任务并行
我的日常工作方式比较特殊。
我正在维护一个 Go 多语言本地化项目，经常会同时运行翻译生成、TranslationUnit 审核、Glossary Review、Locale Surface Review，以及代码和仓库分析等任务。
这些任务并不是几十秒就结束的请求。
很多时候，一次任务会持续二十多分钟。
问题最严重的时候，我的 Firefox 里大约同时开着 6 个 ChatGPT 标签页，其中最多会有 3 个标签页同时执行长时间、高强度任务。
这里真正重要的并不是“打开了 6 个网页”。
而是：
同一个 ChatGPT 账号，在同一时间有 3 个持续二十分钟以上的重任务并行执行。
那段时间，「消息流中的错误」开始频繁出现。
而且不是只发生在某一个 Conversation。
后来我还发现，即使新建一个 Conversation，同样可能很快出现消息流错误。
有时候，任务已经运行了很长时间，甚至已经完成了大量读取和处理中间步骤，最后才突然失败。
这也是为什么这个问题对我影响特别大。
对于几分钟的任务，失败后重新来一次也许还能接受。
但对于已经运行了二十分钟甚至更久的任务，重新开始的成本就完全不同了。
二、与此同时，我还感觉 ChatGPT 出现了“降智”
这里的“降智”不是一个官方技术术语，只是我对使用体验变化的描述。
最明显的特点不是“模型突然不会回答问题了”，而是复杂工作流中的执行稳定性明显下降。
例如，本来能够正常遵循的项目规则突然不读了；本来明确要求失败后 recover，却开始重新生成；已经给出的 exact scope 被扩大；原本稳定的 Reviewer / Generation 角色开始混淆；已经存在的项目事实被忽略。
这种变化有时候和消息流错误出现在同一时间段。
所以当时我的直觉是：
这两个现象可能不是完全独立的。
但仅凭体感当然无法证明原因。
真正让我开始怀疑限流，是后来在故障发生时捕获到了网络日志。
三、OpenAI Support 要求我捕获一次真实故障的 HAR
一开始联系 OpenAI Support 时，客服曾经把问题理解为某一个特定 Conversation 出现异常。
但我后来专门说明：
这个问题并不是某一个 Conversation 独有，而是会影响多个 Conversation，甚至包括新建会话。
客服随后要求我在下一次正常使用过程中，如果问题再次出现，就捕获一次 HAR 网络日志。
这一步本身没有什么问题。
而且我也不想为了测试故意制造错误，所以只是继续正常工作，等待下一次真实故障。
后来在一次 Gujarati 翻译生成任务中，「消息流中的错误」再次出现。
当时 Firefox Developer Tools 已经提前开启网络记录，并启用了 Persist Logs，因此我终于完整捕获到了当时的 HAR 和 Console Log。
四、Console 中出现了多个 HTTP 429
这一次故障最值得注意的地方，是浏览器 Console 中出现了多个 HTTP 429 响应。
于是我把 HAR、Console Log、具体发生时间、任务类型等信息一起提交给了 Support，并在邮件里明确提到：
控制台在错误发生前后记录到了多个 HTTP 429。
HTTP 429 通常意味着：
Too Many Requests
也就是请求受到 rate limiting / throttling。
但这里必须说明一下：
我没有服务端权限，因此无法证明这些 429 就是消息流错误的直接原因。
我也无法知道 ChatGPT Web 内部到底采用了怎样的账号级并发、token、模型调度或任务限流策略。
所以更准确的说法应该是：
在故障发生时，我观察到了 429；而后来降低并行重任务数量以后，429 相关现象、消息流错误和“降智”体感同时消失。它们具有很强的相关性，但我不能证明严格因果关系。
五、真正有效的解决办法：把 3 个并行长任务降到 2 个
后来，我没有继续折腾浏览器缓存、重装 Firefox、切换网络之类的东西，而是直接改变了工作方式。
原来的使用状态大致是：
6 个左右 ChatGPT 标签页，最多 3 个长任务同时执行。
后来改成：
4 个左右 ChatGPT 标签页，最多 2 个长任务同时执行。
需要特别强调的是：
单个任务并没有变短。
现在的 Generation、Reviewer、代码分析任务照样可能超过 20 分钟。
上下文也没有故意缩小。
模型也没有因为这个问题改成低 reasoning。
真正发生变化的，只有一个：
同时运行的重任务从 3 个减少成了 2 个。
结果到现在为止非常稳定。
「消息流中的错误」基本没有再出现。
而我之前感觉很明显的“降智”，也没有再出现。
所以目前我的结论很简单：
对我的工作方式来说，真正危险的可能不是“任务运行超过 20 分钟”，而是“同时存在太多长期、高负载任务”。
六、现在我的固定策略：可以开多个标签页，但最多两个重任务并行
我现在仍然会同时打开多个 ChatGPT 标签页。
但“打开”与“执行重任务”是两回事。
有些标签页只是放着备用，或者等待我下一步操作。
真正进入长时间生成、翻译、Reviewer、代码分析等状态的标签页，最多两个。
如果两个重任务都已经在跑，我不会再启动第三个同等级任务。
第三个任务要么等待，要么安排到别的执行环境，要么只做很轻量的查询。
这套方式目前比以前稳定得多。
所以，如果你也属于重度 ChatGPT 用户，尤其经常同时进行多个 High thinking 长任务，我现在最建议优先测试的，不是换浏览器，而是：
先把并行重任务数量降下来。
七、这是不是说明“3 个并行任务一定会触发 429”？
不能这么说。
我现在拥有的是实际观察，不是 OpenAI 内部限流机制的技术证明。
也可能同时存在其他变量，例如服务端负载、模型调度策略、账号状态、上下文规模，以及 OpenAI 后端在这段时间内是否做过调整。
所以我不会写成：
3 个任务一定触发 429。
更准确的说法是：
在我的使用场景中，6 个标签页、最多 3 个长期重任务并行时，消息流错误、429 和明显的执行质量下降频繁出现；降低到约 4 个标签页、最多 2 个长期重任务并行后，这些问题目前都没有再明显出现。
对于我来说，这已经足够指导实际工作。
我并不一定需要知道 OpenAI 内部到底是哪一个 limiter 被触发。
只要知道怎样使用最稳定，就已经解决了最核心的问题。
八、客服沟通的另一条主线：为了一个 HAR 来回折腾了很久
技术问题之外，这次经历还有一个让我非常失望的部分：
OpenAI Support。
为了让 Support 能真正分析问题，我已经提交了相当完整的信息。
包括错误截图、Conversation 情况、发生时间、模型、HAR、Console Log，以及 429 证据。
但后来大量沟通却不是围绕故障原因展开，而是在解决：
这个 HAR 到底应该怎样交给客服。
九、先让我直接附 HAR，但原始 HAR 太大
我最开始因为原始 HAR 文件太大，所以通过 Google Drive 提供。
结果 Support 后来回复：
不要通过 Google Drive，请直接把 HAR 文件作为邮件附件。
问题是：
原始 HAR 本来就是因为超过邮件附件大小限制，才放在 Google Drive 上的。
于是我想了一个折中的办法：
把同一个 HAR 压缩成 ZIP，然后作为邮件附件发送。
至少这样附件可以发出去。
十、结果 ZIP 又被拒绝
随后客服又告诉我：
ZIP 无法审核，必须发送原始
.har文件。
于是事情就变得非常荒谬。
原始 HAR 太大，无法直接附加。
Google Drive 一度被要求不要使用。
ZIP 又被拒绝。
也就是说，当时客服给出的三个条件组合到一起以后，我实际上已经没有可执行的传输方式了。
所以我只能再次回复客服，明确指出这个矛盾。
最让我无语的是，这件事后来证明根本没必要来回折腾。
十一、Support 最后终于确认：超过 25 MB 可以使用 Google Drive
到了后面的邮件里，Support 最终确认：
如果原始 .har 超过 25 MB 邮件附件限制，可以上传到 Google Drive 或 Dropbox，再通过 view-only link 提供。
于是我做了一件非常有喜剧效果的事情：
把最开始那个 Google Drive 链接重新发了一遍。
也就是说，为了把一个已经捕获好的 HAR 文件交给 Support：
Google Drive → 要求直接附件 → ZIP → ZIP 不接受 → 再确认 Google Drive 可以 → 再发原来的 Google Drive 链接。
这一圈沟通并没有产生任何新的诊断证据。
消耗的只是时间。
十二、最后一封邮件，甚至明确告诉我是 AI Support Assistant
再后来，我终于收到了最新回复。
这封邮件开头直接写着：
I’m an AI support assistant helping move your case forward.
这封回复里面有一个信息倒是值得注意。
它明确提到：
HTTP 429 typically indicates rate limiting/throttling.
而且说这种情况可能表现为：
slow responses or “Error in message stream” during long, high-effort generations.
这个判断和我的实际观察是高度一致的。
它给出的临时建议也是：
把长翻译任务拆得更小，并在发生错误后稍等再重试。
但是，到这里我对这个 Support case 已经没有太大期待了。
因为我原本真正希望得到的是：
有没有人工技术人员实际查看我的 HAR 和 Console Log，并判断这一批 429 到底来自哪里？
到目前为止，我没有得到这样的技术结论。
反而最后一封回复直接告诉我，它是 AI support assistant。
所以现在我对后续是否还会有人工真正介入，已经基本不抱希望。
十三、OpenAI Support 最让我失望的，不只是回复慢
如果只是慢，我其实可以理解。
支持团队请求量大，回复需要排队，这是正常情况。
真正让我失望的是整个过程中存在明显的流程混乱。
同一个 HAR 文件，先让我不要用 Google Drive，后来又确认超过 25 MB 本来就可以用 Google Drive。
先让我直接发送，文件太大以后压缩发送，接着又告诉我 ZIP 无法处理。
最后我不得不自己指出这些要求彼此矛盾。
而在我已经提供了 HAR、Console Log、429、时间戳、任务类型和截图以后，最新回复仍然只是比较通用的限流建议。
对于普通用户，这种支持也许还能接受。
但对于已经提供了完整技术诊断材料的 case，我原本期待的至少应该是：
有人真正查看日志，然后告诉我从日志里看到了什么。
目前没有。
十四、但有点讽刺的是：Support 还没解决，我自己已经解决了
最终真正让问题消失的，并不是客服提出的复杂排查流程。
而是我自己调整并发。
原来：
大约 6 个 ChatGPT 标签页，最多 3 个长任务并行。
现在：
大约 4 个 ChatGPT 标签页，最多 2 个长任务并行。
而且现在的任务仍然很重。
很多任务依然超过 20 分钟。
有时候 Translation Generation 本身就是几十个完整 Page。
Reviewer 也会一次审核几十个 TranslationUnit。
但是目前：
消息流中的错误没有再出现。
我之前感觉很明显的“降智”也没有再出现。
所以从实际工作角度讲，这个问题已经算是解决了。
十五、我现在给重度 ChatGPT 用户的建议
如果你只是偶尔用 ChatGPT 问问题，可能永远不会碰到我这种情况。
但如果你也会同时跑多个长时间任务，可以先试试下面这套做法：
- 可以打开多个 ChatGPT 标签页，但同时真正执行重任务的会话控制在两个以内；
- 如果已经出现 429、明显卡顿或消息流错误，不要继续启动新的重任务；
- 不要连续疯狂点击 Retry，先让并发降下来；
- 长时间任务最好设计 checkpoint 和恢复路径，避免一次 stream error 就从头重来；
- 遇到问题时，如果需要联系 Support，HAR、Console Log、时间戳和具体模型信息比单纯截图更有价值；
- 但不要因为看到 429 就直接断言根因已经被证明，除非你有服务端证据。
这套经验对我最重要的一点，是把“标签页数量”和“并行重任务数量”区分开。
真正值得控制的是后者。
十六、结论：问题基本解决了，但 Support 体验让我彻底降低了期待
这次事情最后形成了两个完全不同的结论。
第一个结论是好的：
「消息流中的错误」和我体感上的“降智”，目前已经基本不再出现。
我的实际工作方式已经从：
6 个左右标签页 / 最多 3 个并行重任务
调整为：
4 个左右标签页 / 最多 2 个并行重任务。
单个任务仍然可以运行 20 分钟以上，但整体稳定性明显提高。
所以目前我认为，降低并发重任务数量 是最值得保留的经验。
第二个结论就没有那么好了：
OpenAI Support 的实际体验，比我预期差很多。
我已经提供了足够详细的技术材料，但大量沟通却消耗在 HAR 文件传输方式这种本不该反复的问题上。
最后一封邮件甚至明确来自 AI support assistant。
所以现在，我已经不太期待这个 case 最终会由人工技术人员给出一个真正的 root cause。
好在，这件事已经不再阻塞我的工作。
对我来说，最终最有用的结论反而非常简单：
不要把 ChatGPT 的并行能力理解成“有多少标签页，就可以同时跑多少个重任务”。
至少在我的实际使用场景里：
两个并行长任务目前非常稳定，三个并行长任务则曾经频繁进入完全不同的状态。
这不是 OpenAI 给我的官方答案。
但它目前确实是一个有效的答案。