GitHub AI Agent 流量冲击：微软被迫将流量路由至 AWS 以维持可用性

2026 年 6 月，GitHub 可用性跌至 88.4%——远低于企业客户期望的 99.9% SLA 基准——微软随即做出了一个两年前难以想象的决定：将 GitHub 流量路由至亚马逊网络服务（AWS），也就是其最大的云计算竞争对手。驱动这一决策的不是迁移计划，也不是成本优化，而是 AI 编程 Agent。

发生了什么

2026 年 6 月 16 日，Business Insider 报道称，微软正在向 GitHub 追加 AWS 算力，以应对 AI 驱动的开发活动激增导致平台频繁中断的问题。微软发言人证实了这一安排，表示："去年底以来，Agent 化开发的爆炸式增长已对我们的基础设施造成极大压力。"

数字揭示了这场危机的规模：GitHub 提交量预计在 2026 年达到 140 亿次，而 2025 年全年仅为 10 亿次。GitHub Actions 每周计算时长从 2023 年的 5 亿分钟飙升至 2026 年初单周 21 亿分钟。AI Agent 发起的 PR 数量从 2025 年 9 月的 400 万次激增至 2026 年 3 月的逾 1700 万次。仅 2026 年 5 月，平台就发生了九次影响服务的故障。

HashiCorp 联合创始人 Mitchell Hashimoto 公开写道，GitHub 已经"不再是认真工作的地方，如果它每天都让你停工好几个小时"。GitHub 自己的 CTO 在 2 月和 3 月也承认，平台已突破三个九的可用性承诺。

微软原计划在 2027 年前将 GitHub 完全迁移至 Azure，但 AI 需求的增速已超过 Azure 的消化能力——于是亚马逊来填补了这一空缺。

为何对 AI 工程团队至关重要

这个故事本质上不是关于微软与亚马逊的竞争，而是关于 AI Agent 采用速度超越支撑它的基础设施时会发生什么。

大多数在 GitHub Actions 上运行 Claude Code、Copilot、Cursor 或自定义编程 Agent 的团队，都建立在 GitHub 是可靠企业级平台这一假设之上。这一假设现在已被公开证伪——而且是在微软不得不向竞争对手借调算力的规模上。

对于在 GitHub 上搭建自动化部署、测试或代码审查工作流的团队，影响是直接的：

• SLA 风险敞口：如果生产部署管道运行在 GitHub Actions 上，88.4% 的可用性意味着每月约 130 小时的潜在停机——远超大多数工程团队对关键基础设施的容忍阈值。
• Agent 流量放大不稳定性：提升开发效率的 AI 编程 Agent，同时也是产生海量提交和 PR 的源头，而正是这些流量压垮了平台。对同一仓库并行部署多个 Agent 的团队，实际上在加剧导致中断的负载。
• 单云 CI/CD 已成为有据可查的风险：多年来，多云讨论集中在 AI 模型路由层面。GitHub 的危机表明，这一原则延伸至 AI 增强开发栈的每一层——包括代码仓库和管道基础设施本身。

Router/Operator 视角

GitHub 中断序列提供了一个可迁移的工程教训：AI 栈中任何单一提供商的依赖，在 Agent 规模下都是可用性隐患。

人工编写代码时，提交量受限于人类工作时间。AI Agent 自动编写、审查并发起 PR 时，提交量受限于 API 配额和模型吞吐。将 CI/CD 提供商视同模型提供商——没有 fallback——的团队，终将面临微软正在处理的相同可用性问题。

运行大量 GitHub Actions 工作流的 Operator 应评估以下几点：

1. 管道 fallback 路径：当 GitHub Actions 降级时，CI/CD 作业能否切换到备用 runner（GitLab CI、Bitbucket Pipelines、自托管 Actions runner、Buildkite）？维护热备用的成本现在已是合理的预算项。
2. Agent 并发限流：并行 Agent PR 会叠加平台负载。团队应审查 Agent 调度逻辑，评估同时发起 PR 并触发 Actions 的并发 Agent 数量，以及在 Agent 层引入限流是否合理。
3. 提交去重：Agent 生成的提交对每个增量变更触发完整测试套件，不仅低效，在规模化场景下更会直接加剧平台负载——正是这一问题引发了 GitHub 的可用性危机。
4. 关键管道的基于 SLA 的路由：若某些部署工作流属于业务关键，考虑将其路由至自托管 runner 或具备独立 SLA 的第二 CI 提供商——正如团队将延迟敏感型模型调用路由至有可靠性保证的专用提供商一样。

无论是路由 AI 模型流量还是 CI/CD 管道流量，底层架构问题是相同的：你的设计是假设单一提供商始终可用，还是将每个上游依赖视为独立的故障域？

TheRouter 用户应关注或尝试的事项

已通过 TheRouter 将 AI 模型请求路由至多家提供商的团队，早已在模型层理解了多提供商可靠性原则。GitHub 事件将这一逻辑向上延伸至管道层。

如果你在 GitHub Actions 中通过 CI/CD 管道部署 Claude Code 或 Copilot，现在正是审视管道本身是否具备与模型路由相同 fallback 思路的时机。一个在模型提供商中断时能切换到备用模型，但 CI/CD runner 毫无 fallback 的编程 Agent，只实现了一半的弹性。

对于正在评估多云管道策略的团队，AWS CodeBuild 和 GitLab CI 是目前生产环境中最常见的 GitHub Actions 备用目标。两者都无需迁移代码仓库——可通过 OAuth 访问托管在 GitHub 上的代码运行管道，在无需完整平台迁移的前提下提供基础设施层的冗余能力。

自托管 Actions runner 也值得重新评估。若微软将 GitHub 迁至 Azure 的计划已推迟至 2027 年后，GitHub 与 Azure 基础设施的预期融合比许多团队预想的更为遥远。