这周 Git 圈的消息估计你已经刷到了：GitHub 又宕了，而 Cursor 真的开始做代码托管了。评论区照例分两派，一派喊「GitHub 护城河塌了」，另一派嘲讽「又一个 PPT 托管平台」。这事关大家的代码放在哪，我把 GitHub 官方复盘、Cursor 的技术博客和几篇全网讨论翻了一遍，帮你把情绪过滤掉，只留和决策有关的部分。
先把时间线对齐：一个月两次大宕机，Origin 同日开放
美东时间 8 月 17 日，GitHub 出了一次很重的故障。官方复盘确认：github.com、认证、Actions、API、PR、Issues 和 Copilot 全部受影响，前后拖了 7 小时 47 分。GitHub官方博客宕机高峰时网页和 API 错误率约 20%，归档和原始文件下载的失败率一度冲到约 50%。知乎
这不是 8 月的第一次。就在 8 月 6 日，GitHub 刚出过一次以 Actions 为主的故障，总影响窗口超过 10 小时。知乎官方对这两次事故的定性很直接：都不是代码或配置变更引起的，本质都是容量问题——流量冲上新峰值，Central US 数据中心的关键基础设施组件没能跟着扩容。GitHub官方博客
8 月 17 日这次最值得琢磨的是恢复过程：部分 Copilot 服务恢复较慢，错误又触发了客户端重试循环，反过来继续放大流量。GitHub官方博客按 GitHub 披露的细节，一个潜伏的客户端重试缺陷把流量放大了约 10 倍，Copilot Token Service 的请求量从平时每秒 7000～9000 涨到 70000～100000。知乎GitHub 最后是在负载均衡器上临时阻断会触发重试的响应，才敢逐步恢复流量。而按 The Register 的统计，今年 4 月到 7 月，GitHub 状态页每月记录的事故都在 20 起以上。知乎
Cursor 的代码托管平台 Origin 的 early beta，恰好就在同一天向所有 Pro、Teams、Enterprise 付费用户开放。知乎不过要说明白：Origin 年初就已公开宣布并挂了候补名单，8 月 17 日开放是既定排期，和宕机没有因果关系——虽然这个时间点确实让人很难不多想。知乎
Origin 现在到底能干什么
把宣传语剥掉，early beta 的交付清单其实很克制：
已交付：仓库托管、PR 与代码评审、代码浏览、与 GitHub 双向同步（评论和回复双向实时同步）、CLI 直接推送；接入 Vercel、Depot、Buildkite，可以承接现有的 GitHub Actions 工作流。知乎
没交付：Issues、原生 CI（目前依赖第三方）、免费档；而被宣传得最多的 agent 原生能力，官方口径只有「很快推出」。知乎
性能口径（官方 demo 数字，暂无独立复现）：每小时 296,000 次克隆、81,000 次推送、单仓库每秒 22.6 次提交、全球同步延迟低于 400 毫秒。知乎
这里有个比参数重要得多的细节：从 GitHub 同步过去的仓库，GitHub 仍然是权威数据源，推送最终写回 GitHub。知乎也就是说，现在试用 Origin 不用搬家、不用改工作流，最坏的结果不过是多开一个标签页。
底层的 Continuity：为什么敢说为 Agent 时代设计
Cursor 同步发了一篇技术博客《Git at any scale》，讲 Origin 的存储底座 Continuity。要看懂它在做什么，得先知道 Git 托管到底难在哪。
Git 把所有数据压缩存在 packfile 里，优化目标是体积最小，不是读取效率。知乎对象之间大量以 delta 增量存放，读一个对象常常要先解码一串别的对象；逻辑上的提交 DAG 和物理存储完全脱节，Git 操作天然是大量随机 I/O。这在本地 NVMe 上没问题，放到网络存储上就是灾难——GitHub 早年试过 NFS、GFS、DRBD，全部失败。
2013 年起，GitHub 用的是 Spokes 方案：仓库以原生 Git 格式存在本地 NVMe，至少 3 副本，用三阶段提交保证强一致。知乎这套架构撑了 13 年，是行业事实标准，但有两个死穴：副本越多推送越慢，每次推送都要等最慢的节点；每个仓库都是需要路由表、健康检查和持续修复的「宠物」。而 Agent 时代的负载是两极的——少数超大单体仓库要几百个读副本扛 CI 流量，海量 AI 生成的一次性小仓库又几乎没人访问，Spokes「每仓库至少 3 副本」的下限两头都不够用。
Continuity 的答案很直接：S3 是唯一事实来源，本地磁盘降级为热缓存。推送在完整持久化到 S3 上的预写日志（WAL）之前绝不确认，所以任何一台服务器报废都丢不了数据；没有共识协议、没有路由表，任何节点都能服务任何仓库，挂了就从 WAL 还原。知乎副本数因此可以在 0 到几百之间自由伸缩，空闲小仓库的成本趋近于零。
代价同样写在明面上：整套系统的正确性押在 S3 上，S3 挂了推送全停；写入受 S3 PUT 延迟约束，吞吐上限是标准版 120 push/s 或 Express One Zone 的 300 push/s，对超大型单体仓库的高频推送可能仍是瓶颈；冷仓库从 WAL 重放恢复，可能要几秒到几分钟。知乎有知乎答主总结得准确：降级时始终正确，健康时始终快速。
要不要搬？分三种情况说
你是谁 | 建议 | 理由 |
|---|---|---|
已在用 Cursor 付费版的个人/小团队 | 可以试，从非关键项目开始 | 同步模式下 GitHub 仍是数据源，试错成本约等于零 |
带团队、有合规审计需求 | 先别搬，保持关注 | Origin 还没回答审计、导出、权限粒度、恢复承诺四个问题 |
只想继续用 GitHub | 不用搬，但有三件事值得做 | 这次宕机的教训可以直接变成动作 |
想试水的，先搞清楚同步范围：仓库内容、分支、PR 会同步过去，Issues 和 Actions 工作流留在 GitHub 这边，入口在 cursor.com/codebase。{{{CUSTOM_HTML_TAG_17}}}
留在 GitHub 的三件事，都来自这次宕机的实况：
检查你的客户端和 CI 的重试策略。一个重试缺陷能把流量放大 10 倍，而 Agent 工具天生爱重试：模型超时重试、鉴权过期重试、工具没回重试。给调用链设总预算、指数退避、随机抖动和熔断，别让「礼貌地再试一次」变成十万人一起敲门。
给关键仓库做镜像备份。`git clone --mirror` 加定期 `git bundle`，平台挂的时候至少代码还拿得出来。
订阅 GitHub 状态页。这次不少团队是 CI 堆积了才发现出事的。
一个比宕机更冷的数据
差不多同一时间，Linear 发了一份团队数据报告：在 6,887 个固定样本团队里，接入编码 Agent 的团队，每周新开的 PR 两年间从 21 个涨到 65 个；没接入的团队只从 8 个涨到 10 个。知乎Linear 自己也踩了刹车——统计口径是打开的 PR，不含合并状态，样本也只覆盖付费工作区，但方向大概率靠谱：代码产出的瓶颈正在从写转移到评审。
另一项针对 2,807 个仓库、33,596 个 Agent PR 的研究也看到同样的压力：40.2% 的仓库出现过时间上重叠的 Agent PR，被抽样重放的并发修改里，跨 Agent 的文本冲突率达到 41.7%。知乎所以哪怕 Origin 永远替代不了 GitHub，它瞄准的问题——堆叠式 PR、合并队列、机器可读的评审状态——都是真的。
接下来值得盯三件事
Origin 的 agent 原生能力何时落地，「让 Agent 直接读写评审状态」是否兑现。
Origin 什么时候把审计、导出、权限、恢复四件事讲清楚——这决定企业用户能不能正眼看它。
GitHub 的补救进度：官方已经加了 300 多万个 CPU 核心和 120PB 高速存储，并预告先从最大的单体仓库开始，上线「读容量随读者数线性扩展」的新架构。GitHub官方博客
代码托管有竞争，对开发者是好事。但在新平台把退出路径讲清楚之前，代码的家，还是放在随时能搬走的地方最踏实。
