Artifacts：会说 Git 的版本化文件系统，专为 Agent 而生

2026-04-16

9 分钟阅读

Agent 正在改变我们看待源码管理、文件系统和状态持久化的方式。开发者和 agent 产出的代码量比以往任何时候都更大，未来 5 年写出的代码量将超过编程史上此前所有总和。这推动了系统规模的数量级变化。源码托管平台尤其吃力，因为它们原本是为人类设计的，不是为这种由 agent 驱动、规模提升 10 倍的场景设计的。agent 不睡觉、可以并行处理多个问题、也不会疲倦。

我们认为现在需要一个新的基础原语，一个分布式、可版本化、优先为 agent 设计的文件系统，能够支撑当下这类应用。

我们把它叫做 Artifacts，一个会说 Git 的版本化文件系统。你可以通过编程方式创建仓库，把它和 agent、sandbox、Workers 或其他任意计算范式放在一起使用，并且能从任何标准 Git 客户端连接。

想给每个 agent session 都配一个 repo？Artifacts 可以。每个 sandbox 实例一个？也可以。想从一个已验证的起点一次性创建 10,000 个 fork？还是 Artifacts。Artifacts 提供 REST API 和原生 Workers API，用于创建仓库、生成凭据、创建提交，适用于不适合使用 Git 客户端的环境（比如任意 serverless 函数）。

Artifacts 目前面向付费 Workers 计划的开发者开放私测，我们目标是在 5 月上旬开放公测。

// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }

# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

就是这样。一个裸仓库，随建随用，任何 Git 客户端都可以直接操作。

如果你想把现有 Git 仓库引导进 Artifacts，让 agent 可以独立工作并推送独立变更，也可以通过 .import() 做到：

interface Env {
  ARTIFACTS: Artifacts
}

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

    // Get a handle to the imported repo
    const repo = await env.ARTIFACTS.get("workers-sdk")

    // Fork to an isolated, read-only copy
    const fork = await repo.fork("workers-sdk-review", {
      readOnly: true,
    })

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

查看文档即可开始。如果你想了解 Artifacts 的实际用法、构建方式和底层实现，请继续往下看。

为什么是 Git？什么是“版本化文件系统”？

Agent 懂 Git。Git 深深存在于多数模型的训练数据里。无论是常规路径还是边界情况，agent 都很熟悉，尤其是代码优化模型（以及/或其 harness）在使用 Git 上表现非常好。

此外，Git 的数据模型不仅适合源码管理，也适合任何需要追踪状态、时间回溯、并持久化大量小数据的场景。代码、配置、session 提示词、agent 历史，这些都是你常常希望以小块（“commits”）存储，并能回退到历史状态（“history”）的“对象”。

我们当然也可以发明一个全新的私有协议，但会遇到冷启动问题。AI 模型不认识它，你就得分发技能、CLI，或者指望用户已经接上你的文档 MCP，这些都会增加摩擦。反过来，如果我们直接给 agent 一个带鉴权、可安全访问的 HTTPS Git remote URL，让它像操作普通 Git 仓库一样操作它，实际效果非常好。对于不直接使用 Git 的客户端，比如 Cloudflare Worker、Lambda 函数或 Node.js 应用，我们也提供了 REST API（以及即将上线的语言 SDK）。这些客户端也可以用 isomorphic-git，但很多时候更简洁的 TypeScript API 会进一步收敛 API 面。

不只是源码管理

Artifacts 的 Git API 容易让人以为它只用于源码管理，但实际上 Git API 和数据模型对于任意数据的状态持久化都很强大，尤其适合支持 fork、时间回溯和 diff。

在 Cloudflare 内部，我们用 Artifacts 支撑内部 agent：把文件系统当前状态和 session 历史自动持久化到每个 session 独立的 Artifacts 仓库。这样我们可以：

持久化 sandbox 状态，不需要额外预置并长期保留块存储。
与他人共享 session，并允许他们回溯 session（提示词）状态和文件状态，不受“真实”仓库（源码仓库）是否有提交的影响。
最棒的是，从任意时间点 fork 一个 session，让团队成员无缝接手。你在调试某个问题想找人一起看？发个 URL，对方 fork 一下就能接上。你想一起迭代一个 API？同事可以直接从你停下的位置继续。

我们也和一些团队交流过，他们使用 Artifacts 时并不要求 Git 协议本身，但非常需要它的语义能力（回滚、克隆、diff）。例如把每个客户的配置作为产品的一部分进行存储，并且希望随时可回退，Artifacts 就是一个很好的表示方式。

我们同样期待团队探索 Artifacts 的非 Git 用例，不仅仅是 Git 场景。

底层实现

Artifacts 构建在 Durable Objects 之上。Durable Objects 天生支持创建数百万（甚至上千万）个带状态、隔离的计算实例，这正是我们在单个 namespace 下支撑数百万 Git 仓库所需要的能力。

Major League Baseball（实时比赛分发）、Confluence Whiteboards，以及我们自己的 Agents SDK 都在大规模使用 Durable Objects，因此我们这次是基于一个已经在生产环境长期验证过的基础原语来做的。

不过我们确实需要一个能在 Cloudflare Workers 上运行的 Git 实现。它要足够小、尽量完整、可扩展（notes、LFS）、并且高效。所以我们用 Zig 实现，并编译成 Wasm。

为什么用 Zig？有三个原因：

整个 Git 协议引擎完全用纯 Zig 编写（无 libc），编译后 Wasm 二进制约 100KB（还有优化空间）。它从零实现了 SHA-1、zlib inflate/deflate、delta 编解码、pack 解析，以及完整的 git smart HTTP 协议，除标准库外零外部依赖。
Zig 让我们可以手动控制内存分配，这在 Durable Objects 这类受限环境里很关键。Zig Build System 还让我们可以在 WASM 运行时（生产）与 native 构建（对照 libgit2 做正确性验证）之间复用代码。
WASM 模块通过一层薄回调接口和 JS host 通讯，共有 11 个 host import 函数处理存储操作（host_get_object、host_put_object 等），再加 1 个用于流式输出（host_emit_bytes）。WASM 侧可以完全独立测试。

在这之下，Artifacts 还使用了 R2（做快照）和 KV（追踪鉴权 token）：

*Artifacts 的工作方式（Workers、Durable Objects 和 WebAssembly）*

一个 Worker 作为前端，负责鉴权与授权、关键指标（错误、延迟）统计，并按需查找每个 Artifacts 仓库（Durable Object）。

具体来说：

文件存储在底层 Durable Object 的 SQLite 数据库里。
- Durable Object 存储单行最大 2MB，所以较大的 Git 对象会被切块后跨多行存储。
- 我们使用了同步 KV API（state.storage.kv），其底层同样由 SQLite 支撑。
DO 的内存上限约 128MB，这意味着我们可以生成上千万个实例（它们足够轻量），但也必须在这个限制内工作。
- 在 fetch 和 push 路径上我们大量使用流式处理，直接返回由原始 WASM 输出块构建的 ReadableStream<Uint8Array>。
- 我们不自行计算 Git delta，而是把原始 delta 与 base hash 和解析后的对象一起持久化。fetch 时，如果请求方已有 base object，Zig 会返回 delta 而非完整对象，从而同时节省带宽和内存。
同时支持 Git 协议 v1 与 v2。
- 我们支持 ls-refs、浅克隆（deepen、deepen-since、deepen-relative）、以及带 have/want 协商的增量 fetch 等能力。
- 我们构建了完整测试套件，包含针对 Git 客户端的一致性测试，以及对照 libgit2 server 的校验测试，用于验证协议支持完整度。

除此之外，我们原生支持 git-notes。Artifacts 是为 agent 优先设计的，notes 让 agent 可以把注释（元数据）附着到 Git 对象上，包括提示词、agent 归属等信息，而且不会修改对象本身。

大仓库，大问题？来认识 ArtifactFS。

大多数仓库并不大，Git 在存储效率上本来就非常高。绝大多数仓库的克隆只需几秒，瓶颈通常是网络建立、鉴权和校验。在大多数 agent 或 sandbox 场景里，这能接受，sandbox 启动时克隆仓库，然后立即开工。

但如果是多 GB 仓库，或者包含数百万对象的仓库呢？怎么才能快速克隆，又不让 agent 为此阻塞数分钟并额外消耗计算资源？

一个流行的 Web 框架仓库（2.4GB 且历史很长）克隆大约需要接近 2 分钟。浅克隆会快一些，但还不够快，无法降到个位数秒，而且我们也不总是希望省掉历史（agent 往往会用到历史）。

我们能把这类大仓库的启动时间压到大约 10 到 15 秒，让 agent 立即开始工作吗？可以，用一些技巧就行。

配合 Artifacts 发布，我们也开源了 ArtifactFS。这是一个文件系统驱动，目标是尽可能快地挂载大型 Git 仓库，文件内容按需后台补水，而不是在初始克隆阶段阻塞。它很适合 agent、sandbox、容器等对启动时延敏感的场景。如果每个大仓库启动能节省 90 到 100 秒，而你每月跑 10,000 个这类 sandbox 任务，相当于节省 2,778 小时 sandbox 时间。

你可以把 ArtifactFS 理解成“异步版 Git clone”：

ArtifactFS 会对 Git 仓库做无 blob 克隆，先拿到文件树和 refs，不拉文件内容。这个动作可以在 sandbox 启动阶段完成，agent harness 随后就能先开工。
在后台，它会通过轻量 daemon 并发补水（下载）文件内容。
它会优先处理 agent 通常最先访问的文件，如 package 清单（package.json, go.mod）、配置文件和代码；同时尽量延后二进制 blob（图片、可执行文件和其他非文本文件），这样 agent 能在文件逐步补水时先扫描文件树。
如果 agent 读取某个文件时该文件尚未完全补水，读操作会阻塞直到补完。

这个文件系统不会尝试把文件“同步”回远端仓库。对于成千上万乃至上百万对象的仓库，这样做通常很慢，而且既然本身就是 Git，就没必要。agent 只需要像普通仓库那样 commit 并 push，不必学习新 API。

更重要的是，ArtifactFS 适用于任何 Git remote，不只我们的 Artifacts。无论你从 GitHub、GitLab 还是自建 Git 基础设施克隆大型仓库，都可以使用 ArtifactFS。

接下来会有什么？

今天发布的是 beta，我们已经在推进接下来几周会陆续上线的一批能力：

扩展我们暴露的可观测指标。当前我们已提供关键操作计数（按 namespace、repo）和每个 repo 的存储字节量指标，方便管理数百万 Artifacts 而不至于变成体力活。
支持 Event Subscriptions 订阅 repo 级事件，这样我们可以把 push、pull、clone、fork 事件发送到 namespace 内任意仓库。你也可以消费这些事件、实现 webhook、通知终端用户、驱动产品生命周期流程，或者触发 push 后任务（如 CI/CD）。
原生 TypeScript、Go、Python 客户端 SDK，用于调用 Artifacts API。
repo 级与 namespace 级搜索 API，例如“找出所有包含 package.json 的仓库”。

我们还计划推出 Workers Builds API，让你能在任意 agent 驱动工作流上运行 CI/CD 任务。

这要花多少钱？

Artifacts 还处于早期，但我们的定价目标是适配 agent 规模：拥有数百万仓库也应当成本可控，闲置或低频仓库不该成为负担，定价应匹配 agent 的“海量单租户”特性。

你也不该为了仓库会不会被用到、是热是冷、或 agent 会不会唤醒它而分心。我们会按你实际使用的存储量，以及每个仓库上的操作（如 clone、fork、push、pull）收费。

$/unit

Included

Operations

每 1,000 次操作 $0.15

每月前 10k 次免费

Storage

$0.50/GB-月

前 1GB 免费。

无论你有 1,000、100,000 还是 1,000 万个仓库，体量大且活跃的仓库会比小且低频仓库成本更高。

随着 beta 推进，我们也会把 Artifacts 带到 Workers Free 计划（会有合理限制）。若定价调整，我们会在 beta 期间持续同步，并在任何计费生效前提前告知。

我从哪里开始？

Artifacts 目前处于私测阶段，我们预计 5 月上旬进入公测（没错，就是 2026 年）。接下来几周我们会逐步放量，可以在这里登记私测意向。

这期间你可以通过以下方式了解 Artifacts：

阅读文档中的入门指南。
访问 Cloudflare dashboard（Build > Storage & Databases > Artifacts）。
查看 REST API 示例。
深入了解 Artifacts 底层工作方式。

关注changelog即可持续追踪 beta 进展。

在 Cloudflare TV 观看

Cloudflare 的 connectivity cloud 保护整个企业网络，帮助客户高效构建互联网规模应用，加速任意网站或互联网应用，抵御 DDoS 攻击，让黑客难以得手，并助你推进Zero Trust 之旅。

在任意设备访问 1.1.1.1 即可开始使用我们的免费应用，让你的网络更快、更安全。

想了解我们“帮助建设更好互联网”的使命，从这里开始。如果你正在寻找新的职业方向，看看我们的职位。

Agents Week Agents GitHub Cloudflare Workers Storage Developer Platform Developers