Responses 流报 transport close failed，可能盖住了更早的供应商错误

流式调用结束时只看到：

RuntimeError: transport close failed

如果日志更早已经出现供应商终态错误，就值得检查异常是否在清理连接时被替换。否则排障很容易只盯着 HTTP 连接，漏掉真正导致生成失败的错误码。

哪一段生命周期出了问题

Agents SDK #5181 在 main 588826c、openai 3.0.0 上记录了一条具体路径：供应商发出 error 终态事件，随后传输层 teardown 又失败，最终调用者只收到清理异常。

#5187 于 2026 年 9 月 27 日合并了完整修复。修复保留供应商终态信息，同时处理流关闭过程，使调用者能够拿到对应的 ModelBehaviorError。本文没有把合并日期当作发行版本，部署前仍需确认所选安装包包含该 PR。

为什么不建议只补一行事件名

issue 中指出终态事件集合漏了 error，但合并 PR 进一步说明：只把这个名称加进集合，仅覆盖部分 cleanup callback 失败。真实 HTTP 流在迭代期间发生的 teardown 异常，还需要额外处理。

如果项目维护自己的 SDK 分支，回移植时应检查完整修复和测试，不要只复制最显眼的一行。一般应用优先采用已包含完整修复的兼容版本。

诊断日志应保存事件类型、供应商错误码和必要的脱敏信息，并分别记录连接清理失败。不要为了排障直接记录包含用户输入或完整模型输出的原始事件。

如何确认错误没有再次被覆盖

测试传输可以按顺序产生一个终态错误，再在关闭时抛出异常。修复后的断言应针对“调用者仍能获得供应商诊断”，而不是断言所有异常都被吞掉。

还需要一个对照场景：终态事件到来前就发生网络故障，该故障仍应正常上抛。否则为了保住原错误而无条件忽略传输异常，会引入另一种漏报。

这项修复改善的是诊断可靠性，供应商原本失败的请求仍然失败。若流程中包含外部写入工具，不能因为现在能读到错误码，就直接重放整个流程。