GitHub 是给人用的：Cloudflare 悬赏 2.5 万美元，请你为 Agent 重写 Git

开场白很直接：GitHub 是给人准备的

Cloudflare 在 2026 年 10 月 1 日的 Birthday Week 博客里，开篇就把话挑明了：GitHub 是为「人写代码、人把代码组织成仓库、人通过分支、提交、Issue 和 Pull Request 协作」的世界设计的。但下一代软件的构建方式会完全不同，因为构建者换了——是 Agent。

博客里列了一串 Agent 已经在做的事：修 bug、写功能、写测试、做 code review、更新依赖、做维持应用运转的日常维护。都不新鲜。真正的问题在下一句：当几百甚至几千个 Agent 同时工作在同一个代码库上时，地基长什么样？

Agent 怎么知道别的 Agent 在干什么？改出冲突怎么办？它们产出的所有变更谁来 review？除了「改了什么」，「为什么改」要怎么记录？最后博客抛出了那个燃烧的问题：下一个 GitHub 长什么样？——然后说：我们想请你亲手把它造出来。

注意这个动作的性质。过去一年，整个行业都在卷「Agent 写代码有多快」：SWE-bench 榜单、各种 coding agent 的 benchmark、谁家的模型一次性能写多少行。这是第一次有一家基础设施大厂把「Agent 写代码的地基」本身当成公开命题提出来，并且不是发一篇愿景稿，而是直接掏出产品（Artifacts open beta）加真金白银（竞赛奖金）请你来造。

Artifacts 进入 open beta：给每个 Agent 一个仓库

Artifacts 是 Cloudflare 今年早些时候发布的产品，定位是一个「会说 Git 的版本化文件系统」，设计目标是扩展到数百万个仓库。从一开始它就被设计成一套可编程的原语（programmable primitives），让开发者在上面构建自己的产品、工作流和抽象。这次 Birthday Week，它正式进入 open beta。

它的核心设计哲学一句话：为每个 agent、每个 session、每个 task、每个 user 创建一个仓库，并且做到 Agent 所需的规模。这就是所谓的 repo-per-agent 模式。博客里提到，开发者已经在用它做几类事：vibe-coding 平台用它存用户创建的项目；开发者用它持久化 agent session 的代码和上下文；还有人创建隔离仓库，让多个 agent 从同一起点安全地并行工作，之后再比较或合并结果。

这次 open beta 带来了一批新能力，每一个都冲着「agent 原生工作流」去的：

• Artifacts 仓库直连 Workers 部署。通过 Workers Builds 把 Artifacts 仓库连到一个 Worker 上：agent（或人）push 代码后，Cloudflare 自动构建项目，生产分支直接部署更新后的 Worker；其他分支的 push 则自动创建或更新 Workers Previews——一个隔离的、可分享的 Worker 版本，改动上线前先在这里验证。push 即部署，分支即预览环境。
• 在 Worker 里直接操作 Artifacts。通过 Artifacts binding，Worker 可以编程式地创建或 fork 仓库、查看文件和提交、签发仓库级别的 Git token。Git 工作流从此可编程：新任务到来时，Worker 为 agent fork 出一个项目副本，读它需要的上下文文件，给它一个可以工作的仓库；agent push 变更后，自动化检查结果并启动 review。步骤全部写在代码里，按你家 agent 的工作方式定制。
• 事件订阅。Artifacts 会在仓库被创建、导入、fork、删除、push、clone、fetch 时发布事件。你可以订阅这些事件决定下一步：跑 CI、启动一个 code review agent、部署变更。博客给的例子是订阅 push 事件，让 Worker 为每次 push 启动一个 code review workflow，把仓库、分支和新提交传给 review agent 做检查。
• 数据辖区选择。创建 namespace 时可以选择 US 或 EU 辖区，该 namespace 下的所有仓库自动遵守同样的数据存放与处理限制。对出海和合规敏感的团队，这是个实在的功能。
• 指标可视化。Dashboard 里能看到每个仓库的操作总数、pull、push、错误数和错误率，也可以直接查询指标 API 自建监控面板。

最值得细品的是博客里的代码示例：用 env.ARTIFACTS 为新任务 fork 一个分支，然后读取它的 AGENTS.md 作为 agent 指令。这相当于把 AGENTS.md 变成了一个 API：agent 的工作规范不再是散落在仓库里的 markdown，而是可以在运行时被程序读取、注入、分发的结构化输入。vibe coder 都熟悉 AGENTS.md，但把它当成「可编程协作协议」来用的，Cloudflare 是第一个把它写进官方示例的大厂。

竞赛细则：10 月 14 日截止，第一名 2.5 万美元

配合 open beta，Cloudflare 发起了一场开发者竞赛：用 Workers 和 Artifacts，造出你心中的「Agent 时代的 Git 平台」。博客明确说：我们要的不是「今天的 GitHub 加上 agent」。你可以重新发明仓库、分支、Pull Request、worktree、code review、合并冲突——或者发明全新的东西：保存 agent 上下文的新方式、同时比较多个变更的新方式、决定哪个变更该上线的新机制。

参赛门槛有意思：「至少要展示多个 agent 并发地处理变更」（at a minimum, multiple agents working on changes concurrently）。注意这个措辞——并发协作不是加分项，是入场券。Cloudflare 的判断很明确：下一代代码平台的及格线，就是能让一群 agent 同时干活而不打架。

参赛方式：提交一段 5 到 10 分钟的演示视频（讲清楚你造了什么、它让 agent 和开发者能做什么、怎么工作的），附上开源代码链接（必须是 MIT、Apache、BSD 这类宽松许可证），再加一份运行/试用说明。截止日期是 2026 年 10 月 14 日——从今天（10 月 8 日）算起，还有不到一周。

奖励：评出前三名，每个团队最多两名成员，飞到旧金山参加 Cloudflare Connect 现场展示；第一名额外获得 25,000 美元的 Cloudflare credits，以及 Connect 周一晚 VIP speaker dinner 的邀请。顺带两个现实细节：Artifacts 将从 2026 年 10 月 15 日开始计费（按仓库操作数和存储量），open beta 要求 Workers Paid 计划用户才能用。

我们的判断：vibe coder 的下一个分水岭不是模型，是协作基础设施

先说结论：这篇博客值得 vibe coder 逐字读，不是因为它发了新功能，而是因为它第一次有人替行业把下一阶段的题目写了出来。

过去两年，vibe coding 的叙事主线一直是「模型越来越强」：上下文窗口从 8k 到 1M，agent 从单文件补全进化到能跑完整项目。但如果你真让十个 agent 同时改一个仓库，立刻会撞上一堵墙——不是模型不够聪明，而是协作层是给人设计的：分支是人开的，PR 是人看的，合并冲突是人解的，code review 的节奏是按人的工作日排的。Agent 不睡觉、不开会、不读 Slack，它们的协作瓶颈不在智力，在协议。

Cloudflare 的 repo-per-agent 是对「共享分支模型」的一次正面挑战。传统 Git 的世界观是：一个仓库是真相源，所有人（包括 agent）在分支上协作。但当 agent 的数量从个位数变成成百上千，「一个仓库 + N 个分支」的模型会先在认知上崩掉——没有哪个 reviewer 能看完一千个 agent 一天产生的 PR。repo-per-agent 反过来想：仓库不再是稀缺的真相源，而是廉价的、可编程的工作单元。每个 agent 有自己的 repo，fork 便宜到可以按任务随手创建，合并从「日常操作」变成「需要专门设计的仲裁机制」。这和当年 GitHub 把「fork + PR」变成开源协作标准协议，有异曲同工的野心。

所以竞赛要求「多个 agent 并发工作」是最低门槛，一点不奇怪：Cloudflare 认定，并发协作就是下一代平台的入场券。谁先把「一千个 agent 同时写代码还不打架」的协作协议做出来，谁就定义了下一个十年的开发体验。这也是为什么博客里反复强调「programmable primitives」——Cloudflare 不想自己定义答案，它想卖铲子，让开发者替它试出一百种答案。

对 VibeFix 的读者来说，有两层现实意义。第一层是机会：这个竞赛是现成的练兵场。如果你在做 agent 工具、多 agent 编排、AI code review，10 月 14 日的截止日期还留了一周左右的窗口；5 到 10 分钟的演示视频加开源代码，门槛是「做出来」，不是「写论文」。退一步说，就算不参赛，照着「多个 agent 并发协作」这个题目给自己的产品做一次 review，也值回票价——你的工具经得起十个 agent 同时调用吗？

第二层是方向：vibe coder 的下一个分水岭，可能真的不是更好的模型，而是 agent 原生的版本、协作与评审基础设施。模型能力现在是所有人的公共水位，拉不开差距；真正的差距会出现在「谁能让 100 个 agent 稳定地产出可合并的代码」这种工程问题上。今天的 vibe coder 还在比拼 prompt 技巧，明天的 vibe coder 可能要比拼的是：你的 agent 舰队有没有像样的协作协议。

风险视角：Cloudflare 在下一盘什么棋

当然，也别只看到浪漫的一面。把这篇博客放在 Cloudflare 的商业版图里看，算盘声很响。

第一，时间点是精心设计的：竞赛 10 月 14 日截止，Artifacts 10 月 15 日开始计费。先用奖金和旧金山之旅把全世界的 agent 工具开发者吸引进来做 demo，等热度起来，第二天就开始收操作费和存储费。Open beta 的免费红利期，满打满算也就两周。这不是批评——这是标准的平台冷启动策略，但参与者心里要有数：你现在写的每一行 demo 代码，都是在为 Cloudflare 的生态做免费的概念验证。

第二，锁定效应是真实存在的。Artifacts 的 binding、Workers Builds、事件订阅、Preview——整套链路深度绑定 Workers 生态。一旦你的 agent 工作流跑在上面，迁移成本会指数上升。repo-per-agent 听起来很美，但「每个 agent 一个 repo」乘以「按操作数和存储计费」，账要自己算过：一个高频运行的 agent 舰队，一天能产生多少次 fork、push、fetch？博客没有给出定价细节，10 月 15 日之后见分晓。

第三，最难的问题博客其实没有回答：当一千个 agent 并发改代码时，合并冲突的语义是什么？「决定哪个变更该上线」听起来很酷，但谁来做这个决定，依据什么标准，错了谁负责？博客把这些问题优雅地抛给了参赛者——「we want you to get creative」。翻译一下：最难的部分，Cloudflare 自己也没想好。这反而说明机会是真实的：题目是开放的，先交卷的人有定义权。

一句话总结：Cloudflare 用一篇博客、一场竞赛和 2.5 万美元，买下了「agent 时代代码协作」这个命题的定义权开场白。不管你看好还是看衰，这个命题本身已经成立了——接下来几年的 vibe coding 基础设施，会围绕它展开。而 10 月 14 日之前，是你以最小成本参与定义它的窗口。

（本文基于 Cloudflare 官方博客原文撰写，关键事实——发布时间、竞赛截止日期、奖金、计费日期——均已对照原文核实。竞赛详情与报名入口以 Cloudflare 官方页面为准。）