N-gram模型过时了？从Siri的早期纠错到ChatGPT的基石，聊聊语言模型的‘古董’与‘新贵’
2026/5/12 2:10:30
原文：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 客户端操作。
最简单的用法只需要三行代码：
// 创建一个仓库constrepo=awaitenv.AGENT_REPOS.create(name)// 把 token 和远端地址传给你的 Agentreturn{repo.remote,repo.token}# 像操作任何普通 Git 远端一样克隆它$gitclone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git一个空仓库，即刻可用，任何 Git 客户端都可以操作。
如果你想让 Agent 基于一个已有的 GitHub 仓库独立工作，可以直接导入：
exportdefault{asyncfetch(request:Request,env:Env){// 从 GitHub 导入const{remote,token}=awaitenv.ARTIFACTS.import({source:{url:"https://github.com/cloudflare/workers-sdk",branch:"main",},target:{name:"workers-sdk"},})// Fork 一个隔离的只读副本constrepo=awaitenv.ARTIFACTS.get("workers-sdk")constfork=awaitrepo.fork("workers-sdk-review",{readOnly:true})returnResponse.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