首页 / 资讯详情
Cursor Origin 上线，GitHub 的老玩法还够用吗？
摘要
代码仓库的主人，正在从人变成 Agent。 作者丨郑佳美 编辑丨岑 峰 8 月 17 日，GitHub 出现大范围服务异常。Web、API、Actions、Pull Requests、Git Operations、Webhooks 等核心链路陆续受到影响，部分时段 Web 与 API 请求错误率接近 20%。同一天前后，Cursor 开始向全部付费计划逐步开放 Origin early beta。repository、PR、checks、review、merge 和 Automations 开始被放进同一套体系里，Cursor 给出的定位也很明确：代码托管要开始为 “agent scale” 设计。好玩的是，这两件事都碰巧出现在同一个时间点，恰好把一个变化放大了出来：代码仓库正在接入越来越多持续运行的 Agent，而现有软件协作基础设施，长期适应的是人的工作节奏。人写几个小时代码，可能只产生几次 commit；Agent 可以在几分钟内连续修改、push、触发 checks，再根据结果继续下一轮。提交变快只是表面，更深的变化是整个软件生产系统的时间尺度正在被压缩。GitHub 面对的很多新问题，Origin 想解决的很多问题，或许都会从这里开始。01GitHub 没有突然变老GitHub 诞生时，软件协作有一个稳定的基本单位：人。工程师写几个小时代码，提交一次 commit；一项功能开发几天，形成一个 PR；评审可能半小时后出现，也可能第二天再进行；CI 跑几分钟通常可以接受，merge conflict 晚一点处理也不会让整个系统失去意义。围绕这种节奏，GitHub 建立了 Pull Request、Issue、Review、Actions、Webhook 和权限体系。即便放到 Linux Kernel 这种长期保持高提交量的工程里，这种节奏依然带着明显的人类时间尺度。雷峰网LWN 统计，Linux 7.0 整个开发周期共有 14251 个 non-merge commits，来自 2362 名开发者。这些提交发生在持续数周的开发周期里，中间还有邮件讨论、维护者审核、子系统整合和 release cycle。Cursor 在 6 月 Origin 发布演示中展示的则是另一种负载形态：单仓库 22.6 commit/s。这个数字属于现场 demo 数据，并非经过独立复现的生产 benchmark，不能证明 Origin 在真实业务里可以长期维持同等吞吐。但它足以说明 Origin 面向什么样的 workload：大量 Agent 持续对同一个代码状态进行写入。人类开发者天然存在限流。思考、写代码、开会和休息会在提交之间制造大量空白时间，因此围绕人设计的 forge 可以把不少系统压力交给时间吸收。Agent 没有这层限制。几十个 Agent 可以同时从同一个 base SHA 分叉，在相近时间修改关联文件，然后一起 push、开 PR、调用检查、读取 review、修改代码并再次 push。一次 commit 还可能继续触发索引更新、权限检查、Webhook、CI、代码扫描、review 状态刷新和 mergeability 计算。因此需要承受变化的并非 Git 对象模型本身，更关键的是 Git 上面的 forge control