我们希望您在 Cloudflare 上构建下一个 Git 平台

GitHub 是为人类编写代码、将其组织到存储库中并通过分支、提交、问题和拉取请求进行协作的世界而构建的。但下一代软件的构建方式将会有所不同，因为它将由不同类型的开发人员（代理）构建。代理已经编写了比以往更多的代码 - 他们正在修复错误、构建功能、编写测试、审查更改、更新依赖项以及进行保持应用程序运行所需的例行维护。因此，在这个新世界中，有数百甚至数千个代理同时在同一个代码库上工作，基础是什么样的？代理如何知道其他代理正在做什么？当他们做出相互冲突的改变时会发生什么？您如何评价他们生产的所有产品？您如何不仅跟踪更改的内容，还跟踪更改的原因？因此，最紧迫的问题是：下一个 GitHub 会是什么样子？我们希望您通过构建它来帮助我们回答这个问题。今年早些时候，我们推出了 Artifacts，这是一个使用 Git 进行版本控制的文件系统，可以扩展到数百万个存储库。从一开始，我们就将 Artifacts 设计为一组可编程原语，开发人员可以使用它们来构建自己的产品、工作流程和抽象。 Artifacts 提供了基础：可以通过编程方式创建和分叉的存储库、代码和代理上下文的版本化存储，以及 Git 操作代理已经知道如何使用。有了这个基础，您就可以专注于它上面的层：代理如何协调他们的工作，如何审查和合并更改，以及当数百或数千个代理在同一代码库上工作时，开发人员的体验应该是什么样子。这就是我们希望您构建的层。现在 Artifacts 已进入公开测试阶段，我们正在举办一场竞赛，看看谁可以使用 Workers 和 Artifacts 在 Cloudflare 上构建下一个 Git 平台。 Artifacts 处于公测阶段。这就是为什么您应该在此基础上进行构建当我们推出 Artifacts 时，我们的目标是为每个代理、会话、任务或用户创建一个存储库 - 并按照代理所需的规模来实现。从那时起，我们看到开发人员以多种方式使用 Artifacts：Vibe 编码平台使用它来存储用户创建的项目。开发人员使用它来保存代理会话中的代码和上下文。其他人正在创建独立的存储库，因此多个代理可以从同一起点安全地工作，并在以后比较或合并结果。以下是我们自首次发布以来添加的一些新功能。将 Artifacts 存储库部署到 Workers 您现在可以通过 Workers Builds 将 Artifacts 存储库连接到 Worker。当您或代理将代码推送到 Artifacts 存储库时，Cloudflare 将构建项目，并为生产分支部署更新的 Worker。推送到其他分支会自动创建或更新 Workers Previews ，为您提供一个隔离的、可共享的 Worker 版本，您可以在更改生效之前在其中测试更改。您可以将现有 Worker 连接到 Artifacts 存储库，或者启动一个新项目并将其自动存储在 Artifacts 中。直接从 Workers 管理 Artifacts 您可以使用 Artifacts 绑定直接从 Worker 与 Artifacts 存储库进行交互，以创建或分叉存储库、检查文件和提交以及颁发存储库范围的 Git 令牌。这使得您的 Git 工作流程变得可编程。当新任务到达时，工作人员可以为代理分叉项目，读取上下文所需的文件，并为其提供一个可以使用的存储库。当代理推送更改时，您的自动化可以检查结果并开始审核。您可以在代码中定义这些步骤，以适应代理的工作方式。例如，以下是如何为新代理任务分叉一个项目并阅读其 AGENTS.md 以获取说明：使用project = wait env。文物。获取（“我的项目”）； const { defaultBranch } = 等待项目。信息（）； const 工作区 = 等待项目。 fork ( `task-${ crypto . randomUUID () }` );使用 repo = wait env.文物。 get(工作空间.名称); const 指令 = 等待 repo。 readFile ({ ref: defaultBranch, 路径: "AGENTS.md" , }); const agentTask = { 远程：workspace.remote，令牌：workspace.token，指令：指令？等待指示。文本（）：空，}；通过事件订阅对每个更改做出反应每当创建、导入、分叉、删除、推送、克隆或获取存储库时，Artifacts 都会发布事件。您可以订阅这些事件来决定接下来会发生什么：运行 CI、启动代码审查代理或部署更改。例如，您可以订阅 Artifacts 推送事件，并让 Worker 为每次推送启动代码审查工作流程。 Worker 将存储库、分支和新提交传递到工作流，为审核代理提供检查更改所需的上下文：