2026 年 8 月 17 日，周一，中国时间晚上 9:40 左右，GitHub 开始大面积宕机。

这次宕机持续了超过 7 个小时，直到 8 月 18 日凌晨 5:15（北京时间）才宣告完全恢复。受影响的服务覆盖了 GitHub 几乎全部核心功能：网站、API、Pull Request、Actions、Webhooks、Issues、Git Operations，以及 GitHub Copilot。

这是 GitHub 今年以来最严重的一次中断。

不到 24 小时后，刚被马斯克收购的 Cursor 宣布推出 Origin，一个面向 AI agent 时代的代码托管平台——时机精准得让人怀疑是不是提前了发布日期。

Origin 目前是早期 beta，对所有付费用户开放。基础功能覆盖了代码托管的核心需求：仓库、Pull Request、代码浏览、GitHub 同步。除此之外，Cursor 把 agent 直接放进了仓库里 —— 你可以在浏览代码时让 Cursor 回答问题、修改代码、更新 PR 或推送分支。

目前它更像一个 GitHub clone，而不是范式级创新。但 Cursor 团队的意图很明确 —— 先用同等功能站稳，再围绕 agent 做差异化。

但到同一天下午，Cursor 自己的 status 页面也亮了红灯。

我们正在调查一起影响 Automations、Cloud Agents、Review Agents 和 Codebase 的服务降级事件，该事件与 GitHub 的状态降级相关。

Origin 也在受影响的服务列表中。

Cursor 的 status 页面显示，受影响的不仅仅是「同步 GitHub 仓库」这个功能。Automations（自动化）、Cloud Agents（云端 Agent）、Review Agents（代码审查 Agent）——全部因为 GitHub 的降级而受影响。

工程师解释了其中的技术细节：

Cursor 构建了一个代码审查 bot（类似 Greptile/CodeRabbit），它和 GitHub 深度集成。Origin 需要从 GitHub 导入已有仓库来引导用户上手。Automation 和 Cloud Agent 就更不用说了。

换句话说，Cursor 目前不是一个独立的代码托管平台，而是一个长在 GitHub 之上的“壳”。

有人把这句话说得更直白：

所以他们宣布这个产品来试图抢 GitHub 的用户，但自己又依赖 GitHub？

代码托管平台最核心的承诺是「你的代码随时都能访问」。GitHub 这次打破了这条承诺，花了 7 个半小时才修好。而 Cursor 的 Origin 甚至还没给出这个承诺——它自己还要依赖 GitHub 才能完整运行。

并非没有人想离开 GitHub。有人表示：「我们团队昨天讨论过，所有人都想离开，正在找最佳替代方案。」

还有人说：「我知道有至少几家大公司受不了了，直接迁到了本地部署，连 Slack 都换了。」

这些讨论说明了一件事：GitHub 的宕机确实动摇了用户对单一托管平台的信任。但替代方案要真正替代 GitHub，至少得先做到不依赖 GitHub。

Origin 目前还做不到这一点——

没错，此处应该推荐：https://gitee.com/

参考来源：

• GitHub degradation affecting some Cursor services — Cursor Status
• HN 讨论