为 Agent 重新设计的 Git：Cloudflare Artifacts 是什么，怎么工作的

原文：Artifacts: versioned storage that speaks Git

发布时间：2026 年 4 月 16 日

作者：Dillon Mulroy、Matt Carey、Matt Silverlock

一个规模问题

有一个被反复引用的预测：未来 5 年内，人类将写出比过去整个编程历史还要多的代码。这个预测的驱动力不是程序员变多了，而是 Agent。

Agent 不需要休息，可以同时处理多个任务，不知道疲倦。代码生成的量级正在发生数量级的跳跃。

问题在于，今天所有主流的源码托管平台------GitHub、GitLab 乃至各类自托管方案------在设计之初面向的是人类开发者的工作节奏。一个团队每天提交几十次、几百次，这是它们的设计预设。

当 Agent 进来之后，这个预设就失效了。

Cloudflare 的这次发布，是他们对这个问题的回答：Artifacts，一个以 Agent 为第一用户、兼容标准 Git 协议的分布式版本化文件系统。

Artifacts 是什么

用一句话描述：Artifacts 是一个可以用代码动态创建的 Git 仓库托管服务，支持所有标准 Git 客户端操作。

最简单的用法只需要三行代码：

javascript 复制代码

// 创建一个仓库
const repo = await env.AGENT_REPOS.create(name)
// 把 token 和远端地址传给你的 Agent
return { repo.remote, repo.token }

bash 复制代码

# 像操作任何普通 Git 远端一样克隆它
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

一个空仓库，即刻可用，任何 Git 客户端都可以操作。

如果你想让 Agent 基于一个已有的 GitHub 仓库独立工作，可以直接导入：

typescript 复制代码

export default {
  async fetch(request: Request, env: Env) {
    // 从 GitHub 导入
    const { remote, token } = await env.ARTIFACTS.import({
      source: {
        url: "https://github.com/cloudflare/workers-sdk",
        branch: "main",
      },
      target: { name: "workers-sdk" },
    })

    // Fork 一个隔离的只读副本
    const repo = await env.ARTIFACTS.get("workers-sdk")
    const fork = await repo.fork("workers-sdk-review", { readOnly: true })

    return Response.json({ remote: fork.remote, token: fork.token })
  },
}

导入完成后，Agent 得到一个完全独立的副本，在上面任意修改、提交，不会影响上游仓库。

目前 Artifacts 处于私有测试阶段，计划在 2026 年 5 月初开放公开测试。

为什么用 Git，而不是发明新协议

这是一个值得认真回答的问题，因为 Git 并不是专为分布式大规模场景设计的，Cloudflare 完全可以设计一套全新的协议。

他们选择 Git 的理由有两条：

第一，AI 模型天然熟悉 Git。 Git 的用法、边界情况、最佳实践，大量存在于各类代码仓库、文档和论坛中，深度嵌入了大多数模型的训练数据。代码优化型模型对 Git 的掌握程度尤其高。如果给 Agent 一个 HTTPS 地址和认证 Token，它会把这个远端当成普通 Git 仓库来操作------这条路径已经被证明是可行的。

第二，Git 的数据模型适用范围远超源码管理。 Git 本质上是一个内容寻址的对象存储系统，天然支持版本追踪、历史回溯、状态对比。只要你有"需要记录变化、支持回滚"的需求，Git 的数据模型就适用：代码、配置文件、Agent 的会话历史，都可以用 Git 的方式来管理。

发明新协议意味着需要重新训练模型、分发 CLI 工具、接入文档 MCP------每一步都是额外的摩擦。沿用 Git，这些问题都不存在。

不只是源码管理：Cloudflare 内部怎么用

Cloudflare 团队自己是 Artifacts 的第一批用户，他们内部 Agent 的使用方式，很好地展示了这个产品超出"源码托管"的可能性。

每个 Agent 会话对应一个独立仓库。 会话的文件系统状态和对话历史（提示词、助手回复）都会自动持久化到这个仓库里。不需要单独维护块存储，会话结束后仓库留存，下次可以继续从任意历史节点恢复。

会话可以分享和 Fork。 调试一个棘手的问题，想让同事帮你看一眼？把仓库 URL 发给他，他 Fork 一个副本，从你停下来的那一刻接着往下做。所有的文件状态和对话历史都在，不需要重新描述背景。这在需要多人协作或交接工作的场景里非常实用。

非 Git 场景也适用。 有团队在考虑用 Artifacts 存储每个客户的配置文件------不需要 Git 协议本身，但需要版本追踪、回滚、变更对比这些语义。Artifacts 的底层数据模型能直接支持这类需求。

底层是怎么做的

Durable Objects：支撑数千万仓库的基础

Artifacts 的底层基于 Cloudflare 的 Durable Objects（DO）。DO 的核心特性是：可以创建数千万个互相隔离的有状态计算实例，每个实例轻量且启动快。这正好对应 Artifacts 的需求------每个命名空间下可能存在数百万个仓库，每个仓库是一个独立的 DO 实例。

用 DO 做这件事还有一个好处：这不是 Cloudflare 第一次在生产环境大规模使用 DO。Major League Baseball 的赛事直播、Confluence 的白板功能，以及 Cloudflare 自己的 Agents SDK，都在大规模使用 DO。技术成熟度有保障。

用 Zig 写 Git 服务器，编译成 Wasm

在 Cloudflare Workers 上运行一个 Git 服务器，需要一个足够小、足够完整、可以在 Wasm 沙箱里运行的 Git 协议实现。Cloudflare 选择用 Zig 从头实现，编译为约 100KB 的 Wasm 二进制文件。

选择 Zig 有三个原因：

零依赖，纯 Zig 实现。整个 Git 协议引擎不依赖 libc，自己实现了 SHA-1、zlib 压缩/解压、delta 编解码、pack 文件解析，以及完整的 Git smart HTTP 协议。
手动内存控制。DO 的内存上限约为 128MB，Zig 允许精确控制内存分配，避免在受限环境里出现意外的内存溢出。
可独立测试。Wasm 模块通过一个只有 11 个函数的接口和 JS 宿主通信（存取对象、流式输出），完全可以脱离宿主单独测试。

文件存储细节

文件对象存储在 DO 内置的 SQLite 数据库中，使用同步 KV API（state.storage.kv）
DO 的单行存储上限是 2MB，超过这个大小的 Git 对象会被分片存储到多行
Git delta（差量压缩）的原始数据和 base hash 一起持久化，取数据时如果客户端已有 base 对象，直接发 delta 而不是完整对象，节省带宽和内存
同时支持 Git 协议 v1 和 v2，包括浅克隆、增量拉取等常用特性

git-notes 支持：Agent 可以附加元数据而不污染历史

Artifacts 原生支持 git-notes，这是 Git 的一个机制，允许给任意 Git 对象（提交、文件等）附加额外的注释，且这些注释不会改变对象本身的哈希值。

对于 Agent 场景，这意味着 Agent 可以把提示词、归因信息、执行日志等元数据写到 notes 里，随仓库一起存储和传递，但不会影响代码提交的历史记录。

ArtifactFS：大仓库快速挂载（已开源）

Git 协议有一个固有的问题：对于大型仓库，克隆操作会阻塞 Agent 的启动。

以一个广受欢迎的 Web 框架为例，仓库体积 2.4GB，历史记录很长，完整克隆需要接近 2 分钟。对于人类开发者，等 2 分钟还好；对于 Agent 驱动的沙箱任务，这是每次启动都要付出的固定成本。

如果每月运行 1 万次这样的沙箱任务，每次节省 90 秒，累计能减少约 2778 小时的计算时间。

Cloudflare 为此开源了 ArtifactFS ，一个专门设计给 Agent 和沙箱场景的文件系统驱动，核心思路是异步克隆 + 按需水合：

启动时先做 blobless clone------拉取文件树结构和引用，但不下载文件内容，这一步很快
后台并发地把文件内容下载到本地（"水合"过程）
优先处理 Agent 最可能先读的文件类型：package.json、go.mod 等包管理文件，配置文件，源代码文件，把二进制文件（图片、可执行文件）放到最后
如果 Agent 在某个文件水合完成之前尝试读取它，读操作会等待，直到内容就绪

Agent 不需要学任何新的 API。写完代码之后，像操作普通 Git 仓库一样 commit 和 push 就行。

ArtifactFS 不只支持 Cloudflare 自己的 Artifacts，对 GitHub、GitLab 以及任何标准 Git 远端都同样适用。

项目地址：https://github.com/cloudflare/artifact-fs

定价：为 Agent 规模设计

Artifacts 的计费模型只有两个维度：操作次数 和存储量。

	单价	每月免费额度
操作次数（克隆、Fork、Push、Pull 等）	$0.15 / 1,000 次操作	前 1 万次免费
存储	$0.50 / GB·月	前 1 GB 免费

没有"闲置费"。一个仓库创建之后，只要不产生操作、不消耗存储，就不收费。这对于可能同时存在数百万个仓库、但大多数处于冷状态的 Agent 场景来说，是一个合理的定价结构。

随着测试推进，Cloudflare 也会把 Artifacts 接入 Workers 免费套餐，并提前通知任何定价变化。

路线图

目前已在开发中、将在测试期间陆续推出的功能：

事件订阅：在 Push、Fork、Clone 等操作发生时触发事件，可用于驱动 webhook、CI/CD 流程或通知
多语言 SDK：原生 TypeScript、Go、Python 客户端
仓库搜索 ：按文件内容或文件名在命名空间内搜索仓库，比如"找出所有包含 package.json 的仓库"
Workers Builds 集成：在 Agent 驱动的工作流上直接运行 CI/CD 任务

小结

Artifacts 解决的问题可以用一句话概括：现有的源码管理基础设施是为人类的工作节奏设计的，而 Agent 的工作节奏和人类完全不同。

Cloudflare 的解法没有另起炉灶，而是选择以 Git 协议为接口，用 Durable Objects 做规模化底座，在上面构建了一套针对 Agent 场景重新优化的版本化存储系统。Agent 熟悉 Git，开发者熟悉 Git，现有工具链也都兼容 Git------这让 Artifacts 的接入成本几乎为零。

更有意思的地方在于，它的使用场景并不局限于源码。只要你有"需要版本追踪、支持回滚、需要 Fork 隔离"这类需求，Artifacts 的数据模型就能派上用场------配置管理、会话状态持久化、沙箱环境快照，都是它可以覆盖的领域。

参考链接

原文：https://blog.cloudflare.com/artifacts-git-for-agents-beta/
官方文档（快速上手）：https://developers.cloudflare.com/artifacts/get-started/workers/
REST API 示例：https://developers.cloudflare.com/artifacts/api/rest-api/
ArtifactFS 开源仓库：https://github.com/cloudflare/artifact-fs
私有测试申请：https://forms.gle/DwBoPRa3CWQ8ajFp7