2026年10月1日，Cloudflare（Cloudflare）呼吁开发者在其全球网络上构建下一个 Git 平台，随着 Cloudflare Workers、D1 与 R2 等服务的成熟，如今已具备将源代码托管、持续集成与边缘部署无缝融合的基础，让团队能够直接管理仓库并运行协作开发，而无需依赖传统第三方服务。
正文
GitHub 是为这样一个世界构建的：人类编写代码，将其组织进仓库，并通过分支、提交、议题和拉取请求协作。
但下一代软件将以不同方式构建，因为构建者变成了另一种开发者：智能体（agents）。
智能体已在编写比以往更多的代码——它们修复 bug、构建功能、编写测试、审查变更、更新依赖，并执行保持应用运行所需的日常维护。
那么在这个新世界里，当成百上千个智能体同时在同一代码库上工作时，基础架构该是什么样？
智能体如何知道其他智能体在做什么？当它们做出冲突的更改时会发生什么？如何审查它们产出的所有内容？如何不仅记录改了什么，还记录“为什么”要改？
因此紧迫的问题是：下一代 GitHub 长什么样？
我们希望你帮忙回答这个问题，把它构建出来。
今年早些时候，我们推出了 Artifacts，一个支持 Git 的版本化文件系统，可扩展到数百万个仓库。从一开始，我们就将 Artifacts 设计成一组可编程原语，开发者可用其构建自己的产品、工作流和抽象。
Artifacts 提供了基础：可程序化创建和 fork 的仓库、用于代码和智能体上下文的版本化存储，以及智能体已经会用的 Git 操作。
有了这个基础，你可以专注其上的一层：智能体如何协调工作、更改如何审查合并，以及当成百上千智能体在同一代码库上时开发者体验该是什么样。
这正是我们要你构建的那一层。
如今 Artifacts 已开放公测，我们正在举办一场竞赛，看谁能用 Workers 和 Artifacts 在 Cloudflare 上构建下一代 Git 平台。
Artifacts 已开放公测。以下是你应在其上构建的原因
我们推出 Artifacts 的目标，是让每个智能体、会话、任务或用户都能拥有一个仓库，并达到智能体所需的规模。
自那以后，我们看到开发者的多样用法：Vibe-coding 平台用它存储用户创建的项目；开发者用它持久化智能体会话的代码和上下文；还有人创建隔离仓库，让多个智能体从同一起点安全工作，事后比较或合并结果。
以下是我们自初步发布后新增的一些能力。
将 Artifacts 仓库部署到 Workers
现在你可以通过 Workers Builds 将 Artifacts 仓库连接到 Worker。当你或智能体向 Artifacts 仓库推送代码时，Cloudflare 会构建项目，并在生产分支上部署更新后的 Worker。推送到其他分支会自动创建或更新 Workers Previews，给你一个隔离、可共享的 Worker 版本，供你在上线前测试更改。
你可以将现有 Worker 连接到 Artifacts 仓库，或启动新项目并自动存入 Artifacts。
直接从 Workers 管理 Artifacts
你可以使用 Artifacts binding 从 Worker 直接操作 Artifacts 仓库，创建或 fork 仓库、检查文件和提交、发放仓库级 Git 令牌。这让 Git 工作流变得可编程。新任务到达时，Worker 能为智能体 fork 项目、读取所需上下文文件，并给它一个工作仓库。智能体推送更改后，你的自动化可检查结果并启动审查。你用代码定义这些步骤，以适配智能体的工作方式。
例如，可以为新智能体任务 fork 项目并读取其 AGENTS.md 获取指令：先获取项目，取默认分支，fork 出带随机 UUID 的工作区，再读取默认分支下的 AGENTS.md 文本作为指令，组合成代理任务对象。
通过事件订阅对每次更改做出反应
每当仓库被创建、导入、fork、删除、推送、克隆或获取时，Artifacts 都会发布事件。你可以订阅这些事件来决定下一步动作：运行 CI、启动代码审查智能体，或部署更改。
例如，订阅 Artifacts 推送事件，让 Worker 为每次推送启动代码审查工作流，将仓库、分支和新提交号传给工作流，使审查智能体获得检查变更所需的上下文。
Artifacts 仓库的数据管辖权
你现在可以选择 Artifacts 存储和处理仓库数据的位置。创建命名空间时设置美国或欧盟管辖权，该命名空间内创建的每个仓库都会自动遵循相同限制。
例如，通过 API 创建命名空间时指定 jurisdiction 为 eu 即可。
查看 Artifacts 指标
你现在能在 Cloudflare 仪表板中看到 Artifacts 仓库的指标。每个仓库可查看总操作数、拉取、推送、错误和错误率，帮你了解使用情况并发现故障。你也可以直接查询 Artifacts 指标来构建自己的仪表板或监控。
定价
Artifacts 定价基于仓库操作次数和存储数据量。我们将在 2026 年 10 月 15 日开始对 Artifacts 用量计费。
竞赛：在 Cloudflare 上构建下一代 Git 平台
我们希望你用 Cloudflare Workers 和 Artifacts 构建智能体时代 Git 平台的愿景。
你可以重新思考仓库、分支、拉取请求、工作树、代码审查和合并冲突——或者构建新方法来保留智能体上下文、同时比较多个更改，并决定哪个该发布。
我们不想要一个在现有 GitHub 上加了智能体的东西。至少，我们希望看到多个智能体并发处理更改。除此之外，我们希望你发挥创意——思考接下来该是什么。
如何参赛
提交内容：
- 一段 5 到 10 分钟的视频，演示你构建的内容、它让智能体和开发者能做什么，以及工作原理
- 源代码链接，必须在宽松开源许可（MIT、Apache、BSD）下提供
- 运行或试用项目的说明
截止日期
提交开放至 2026 年 10 月 14 日。
为何要参与？
我们将选出前三名项目，并承担每队最多两名成员飞往旧金山参加 Cloudflare Connect 展示成果。
第一名团队还将获得 $25,000 的 Cloudflare 额度，以及 Connect 周一晚 VIP 演讲晚宴的邀请。
开始使用
Artifacts 已向 Workers 付费计划客户开放公测。
用你的编码智能体开始：复制提示来设置首个 Artifacts 仓库并开始推送代码。
你可以在仪表板中查看或创建 Artifacts 仓库，若想深入了解，可查阅文档。
评论
社区普遍嘲讽 Cloudflare 借“为代理构建下一代 Git 平台”竞赛白嫖开发者创意且赏金侮辱性，少数人则认真探讨代理时代版本控制的技术形态与去中心化路径。
认为竞赛是中心化平台白嫖创意的侮辱性套路
- 大量评论指出 2.5 万美元赏金对比潜在企业价值极低，且要求参与者贡献想法给巨头，类似无偿 spec 工作，规则中仅美加居民可参与也显矛盾（较多人） > 为市值千亿公司建下一个 GitHub 就给这点钱，真是慷慨（@camcil）
呼吁去中心化并减少对 Cloudflare 的依赖
- 多位用户强调应在自有设备或去中心化协议上自建版本控制，避免单点故障与政治技术风险，吸取过往中心化教训（较多人） > 我们想要的是更少而非更多对 Cloudflare 的依赖，它是技术与政治上的单点故障（@Animats）
质疑数千代理并发工作的价值，主张人机结对
- 有开发者基于实践经验认为，高质量生产代码来自一人搭配一至三个代理来回结对，而非上百代理自由放任产生垃圾；质疑竞赛前提本身（少数人） > 质量代码不是一个由上千代理自治的软件工厂生产的，而是一个人带着几个代理结对编程出来的（@embedding-shape）
有价值的补充
- 回顾 Google Wave 的实时协作与联邦架构，认为如今 CRDT 与智能合并技术可复兴其思想，为版本控制带来行为可审计与实时演化结合（@btown）
- 指出 Git 协议本身可能难以支撑千级代理并发，需要在多人编辑与提交之间寻找新模型，但也担忧垃圾代码泛滥（@zamalek）
- 提出 Fossil 这类基于 SQLite 的系统天然适合存储代理所需全部上下文，可作为代理时代 SCM 候选（@jester997）
- 分析竞赛实质可能是设计类似 entire.io 的多元代理活动记录系统，而非传统 Git 提交历史（@cs1996）