Cloudflare Artifacts:专为 AI Agent 打造的 Git 版本化存储
当 Agent 遇上版本控制
AI Agent 正在重塑软件开发的节奏。一个 Agent 可以同时处理多个 issue、不知疲倦地持续工作,代码生成的速度和规模远超人类。但随之而来的问题是:现有的源代码管理平台——GitHub、GitLab 这些为人类设计的系统——正在被这种量级的需求所冲击。
想象一下这样的场景:你的 Agent 需要为每次会话创建一个独立仓库,或者从一个已有项目 fork 出一万个副本来并行实验。传统 Git 托管平台的 API 限流和成本结构根本无法支撑这种用法。
Cloudflare 在 2026 年 4 月的 Agents Week 上给出了自己的答案:Artifacts——一个兼容 Git 协议的版本化文件系统,专为 Agent 场景从零设计。
Artifacts 是什么
简单说,Artifacts 是一个分布式版本化文件系统,它说的是 Git 的语言。你可以通过 API 动态创建仓库,然后用任何标准 Git 客户端来操作它——clone、push、pull,一切照旧。
| |
| |
就这么简单。一个空仓库在毫秒级别被创建出来,任何 Git 客户端都能直接使用。
为什么选择 Git 协议
Cloudflare 团队的思路很务实:Agent 天然懂 Git。Git 操作深深嵌入在大模型的训练数据中,无论是常规操作还是边界情况,代码优化模型都能很好地处理。如果发明一个全新协议,就会面临冷启动问题——模型不认识它,你得分发技能包、CLI 工具或者指望用户接入了你的文档 MCP……这些都在增加摩擦。
Further, Git’s data model is not only good for source control, but for anything where you need to track state, time travel, and persist large amounts of small data.
Git 的数据模型不仅适用于源代码管理,对任何需要追踪状态、时间旅行和持久化大量小型数据的场景都很有效。代码、配置、会话 prompt、Agent 历史记录——这些都可以用 commit 来做快照,用 history 来回溯。
对于不方便使用 Git 客户端的环境(比如 Serverless 函数),Artifacts 同时提供了 REST API,后续还会推出 TypeScript、Go 和 Python 的原生 SDK。
不止于源代码管理
Artifacts 最有意思的地方在于,它的应用场景远超传统的代码托管。Cloudflare 内部已经在这样使用它:
- 持久化沙箱状态:自动将文件系统状态和会话历史保存到每个 Agent 会话的独立 Artifacts 仓库中,不再需要为每个沙箱维护块存储。
- 会话共享与时间旅行:团队成员可以在 prompt 状态和文件状态之间自由穿梭,无论当时是否有正式的 commit。
- 会话 fork:调试遇到瓶颈?发个链接让同事 fork 你的会话,从你停下的地方继续。
还有一些非典型用例也很值得关注——比如把每个客户的配置存储在 Artifacts 中,利用 Git 的语义实现回滚、diff 和版本追踪,即使完全不需要 Git 协议本身。
技术架构:Zig + WebAssembly + Durable Objects
Artifacts 的底层架构相当有特色:
认证 & 路由] B --> C[Durable Object
每个仓库一个实例] C --> D[Zig→Wasm
Git 协议引擎] C --> E[SQLite
对象存储] C --> F[R2
快照] B --> G[KV
Token 管理]
几个关键设计决策:
Durable Objects 作为底座。每个仓库对应一个 Durable Object 实例,天然支持数百万甚至上千万级别的仓库规模。Durable Objects 已经在 MLB(棒球大联盟直播)、Confluence Whiteboards 和 Cloudflare 自家的 Agents SDK 中经受了大规模验证。
Zig 编写的 Git 引擎,编译为 Wasm。整个 Git 协议引擎用纯 Zig(不依赖 libc)实现,编译后的 Wasm 二进制仅约 100KB。它从零实现了 SHA-1、zlib 压缩/解压、delta 编解码、pack 解析以及完整的 Git Smart HTTP 协议,零外部依赖。选择 Zig 的三个原因:
- 可以精确控制内存分配,这在 Durable Objects 128MB 内存限制下至关重要
- Zig 的构建系统便于在 Wasm(生产环境)和原生构建(用 libgit2 做一致性验证测试)之间共享代码
- Wasm 模块通过 11 个主机导入函数与 JS 宿主通信,接口精简且可独立测试
流式处理应对内存约束。在 fetch 和 push 路径中大量使用流式处理,直接返回 ReadableStream<Uint8Array>。为了节省带宽和内存,如果请求方已有 base object,引擎会发送 delta 而非完整对象。
此外,Artifacts 原生支持 git-notes,允许 Agent 在不修改 Git 对象本身的情况下附加元数据——比如 prompt 内容、Agent 归属信息等。
ArtifactFS:让大仓库秒级可用
对于大型仓库(数 GB、数百万对象),传统的 git clone 可能需要好几分钟。一个流行的 Web 框架仓库(2.4GB)clone 耗时接近 2 分钟。Agent 等不起这么久。
为此,Cloudflare 开源了 ArtifactFS——一个专为快速挂载大型 Git 仓库设计的文件系统驱动:
- Blobless clone:只拉取文件树和 refs,不下载文件内容,沙箱可以在几秒内启动
- 后台异步 hydrate:由后台守护进程并发下载文件内容
- 智能优先级:优先 hydrate Agent 最可能先用到的文件——
package.json、go.mod、配置文件和代码,推迟二进制文件 - 按需阻塞读取:如果 Agent 读取一个尚未 hydrate 的文件,读操作会阻塞直到内容就绪
值得一提的是,ArtifactFS 兼容任何 Git 远程仓库,不限于 Cloudflare 的 Artifacts。即使你的仓库在 GitHub 或 GitLab 上,也可以直接使用。
定价与成本
Artifacts 的定价设计围绕 Agent 规模场景展开——百万级仓库不应该成为负担,闲置仓库不应该持续产生费用:
| 项目 | 单价 | 免费额度 |
|---|---|---|
| 操作(clone/push/pull/fork) | $0.15 / 千次 | 每月前 10,000 次 |
| 存储 | $0.50 / GB·月 | 首 1GB |
关于"操作"的粒度,原文并未明确定义。根据 HN 社区讨论中的推测,这里的一次操作大概率对应 git clone、git push 这样的高层操作,而非单个 Git 对象的读写。
社区对定价的反馈值得注意:有开发者指出操作单价比 S3 的 PUT/POST 高出约 30 倍,不过考虑到每次操作的粒度差异,实际使用中通过批量操作可以有效控制成本。另外也有人关注到 Durable Objects 128MB 的内存上限,对于历史记录较长的仓库,在 push 时的 delta 解析阶段可能会遇到压力。
社区怎么看
这个发布在 Hacker News 上引发了不少讨论。支持者认为这是一个填补了真实空白的产品:
API-first git repos without the limitations of a git service like GitHub that are built primarily for humans.
也有开发者持更审慎的态度。用户 gavinray 的观点颇具代表性——对于大多数团队来说,GitHub + 分支/worktree 已经够用了,Artifacts 的核心价值在于"突破传统平台在海量仓库创建和 API 限流方面的瓶颈"以及 ArtifactFS 的懒加载能力。如果这两点恰好命中你的痛点,那它是个好工具;否则市场可能偏小众。
也有比较尖锐的批评:有人认为 Git 的数据模型在非行导向 diff 的场景下表现糟糕,用它做通用数据存储是对问题的误判。
这些不同声音恰恰反映了这个产品的定位——它不是要替代 GitHub,而是瞄准了一个 GitHub 设计之初未曾考虑的规模和使用方式。
路线图
Artifacts 目前处于 Private Beta 阶段(需要付费 Workers 计划),Public Beta 预计 2026 年 5 月上旬开放。近期计划包括:
- Event Subscriptions:仓库级别的事件订阅,支持 push/pull/clone/fork 事件通知和 Webhook
- 原生 SDK:TypeScript、Go、Python 客户端库
- 搜索 API:仓库级和命名空间级的搜索,比如"找出所有包含
package.json的仓库" - Workers Builds 集成:在 Agent 驱动的工作流上运行 CI/CD
- 免费计划支持:后续会向 Workers Free 用户开放(有合理限制)
写在最后
Artifacts 的有趣之处不在于它做了什么全新的事情——版本控制、对象存储、文件系统这些概念都不新鲜。它的价值在于用一个 Agent 原生的视角重新组合了这些能力:让创建仓库像调用一个函数一样简单,让百万级仓库不再是架构噩梦,让 Git 这个 Agent 已经熟悉的协议成为交互界面。
至于它能否真正成为 AI Agent 基础设施的关键一环,取决于 Agent 驱动开发的规模是否如 Cloudflare 预期的那样增长。但至少在今天,它代表了一种值得关注的方向:不是为 Agent 适配人类工具,而是用人类已有的协议为 Agent 构建专属基础设施。