摘要

  • GitHub于8月1日18:03:05.539 UTC创建事件sj1tzyrx599x，并在18:44:28.733 UTC解决。
  • 公开事件记录持续41分23.194秒。
  • GitHub最先报告特定上游AI模型提供商错误率升高，没有点名模型或公司。
  • 18:20:20.807 UTC，公司明确Fable 5在Copilot产品和IDE界面中的可用性下降，并建议其他模型或Auto。
  • 18:20:48.941 UTC，模型特定更新发布28.134秒后，GitHub标记缓解；Fable 5在18:23:40.021 UTC恢复可用。
  • 提供商、原因、请求分母、错误率、用户数和地域均未披露；GitHub承诺发布详细根因分析。

最初17分钟只能看到故障类别

18:03:15.483 UTC的更新使用“特定上游AI模型提供商”这一范围。它排除了“Copilot所有功能普遍故障”的说法，却没有告诉用户应该避开哪个模型。Fable 5在17分5.324秒后才被写入公开说明。

来源无法判断这段时间用于技术定位、与供应商确认、发布审核，还是几项工作同时进行。能够确认的只有公开信息逐步收窄：先是提供商类别，随后才是具体模型路由。

模型被点名后，状态几乎立即变化

Fable特定说明发布28.134秒后，GitHub称退化已经缓解并进入监控；再过2分51.080秒，公司明确Fable 5重新可用。时间差很短，但不能被解释成技术修复只用了28秒。

上游处理可能早已开始，只是模型名称尚未公开。状态页时间戳记录外部披露和状态转换，并不保存私下操作的完整起止时间。

绕行建议需要明确模型才能执行

面对“某些提供商出错”的笼统告警，用户知道风险存在，却未必知道该更改哪项选择。Fable被点名后，“选择另一模型或Auto”才成为针对性操作。

替代路由仍然不等于等价输出。页面没有Auto目标、切换成功率、响应延迟和行为比较。它证明了公司提出连续性选项，没有证明该选项对所有客户生效。

同一天发生不代表共同根因

当天更早时候，GitHub还处理过GPT-5.6 Luna与上游模型提供商相关的独立事件。相近用词和时间接近，不足以证明两次事件来自同一家提供商、同一基础设施或同一技术故障。

两起记录共同展示了模型供应链依赖，却不能合并成一次共同宕机。若没有GitHub后续确认，共因只能是猜测。

恢复可用后仍监控约21分钟

缓解时间为18:20:48.941，Fable恢复可用时间为18:23:40.021，正式关闭在18:44:28.733。也就是说，明确恢复后又监控20分48.712秒。

GitHub没有说明监控指标或关闭阈值。这段持续时间可以证明公司没有立即结束事件，却不能量化剩余错误。

企业应保存模型选择与回退记录

团队可以记录请求模型、错误类别、重试、可见情况下的Auto选择、响应延迟，以及输出是否进入下游流程。笼统上游告警出现时，临时调整允许模型列表应成为可审计的运营决策，而不是无痕界面操作。

现有证据不支持提示词泄露、代码暴露或输出损坏。GitHub公开的症状是可用性与错误率，而不是安全或完整性问题。

根因报告还要解释“何时认出Fable”

后续分析应说明GitHub何时确认Fable相关、如何把提供商健康状态映射到模型身份、什么信号触发缓解、Auto如何响应，以及影响了多少请求与用户。它也应明确与当天Luna事件是否存在依赖关系。

目前结论应保持边界：Fable 5在41分23.194秒的公开事件中发生退化，状态页在恢复前从笼统上游错误收窄到具体模型。提供商、原因、规模和与早先事件的关系仍未知。

来源