Cloudflare Artifacts：每個 Agent Session 都有自己的 Git 倉庫

為什麼 Agent 需要版本控制原語

Cloudflare 的出發點很直接：未來五年人類寫出的程式碼，將超過過去所有程式設計歷史的總和。這不是誇張，而是當 agent 不需要睡覺、不需要開會、不受時區限制時，純粹可能發生的事。

問題是，現有的版本控制平台是為人類設計的。GitHub、GitLab 的 UI 假設用戶會打開瀏覽器、思考、輸入 commit message、等待、再 push。它們不是為了應對 10 倍、100 倍的 agent 流量而建造的——尤其是每個 agent session 都可能需要自己的 fork、自己的 branch、自己的歷史紀錄時。

但拋棄 Git、另起爐灶，會面臨一個根本問題：模型不認識新協定。

核心洞見

Git 是 Agent 已知的語言——大量真實 Git 使用案例存在於模型的訓練資料中。git clone、git commit、git merge、git rebase的正常路徑和邊緣案例，模型都懂。與其發明新協定然後面臨 bootstrap 問題——模型不認識它，必須從頭教——不如給 agent 一個帶憑證的 HTTPS Git remote URL，讓它像操作普通 Git repo 一樣工作。

Artifacts 的設計哲學就是這樣：Git 語意保持不變，基礎設施重新設計。API 優先、programmatic 建立、為大量短暫 session 設計的儲存架構，但 agent 面對的永遠是一個它已知的 Git remote URL。

毫秒

建立新 repo
的延遲

1行

程式碼
得到完整 Git remote

任意

Git client 相容
標準 HTTPS 協定

核心 API：三行程式碼，一個完整 Git 倉庫

Artifacts 的設計是徹底 API-first 的。你不需要登入任何控制台建立 repo，也不需要手動配置權限——一切透過程式碼完成。核心操作只有三個：create、import、fork。

建立 repo 並交給 agent

// 建立 repo
const repo = await env.AGENT_REPOS.create(name)

// 把 token 和 remote 傳給 agent
return { repo.remote, repo.token }

Agent 端：像操作普通 Git remote 一樣

# Agent 拿到 remote URL 和 token 後，標準 git 操作
git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

# 所有標準 git 指令都可以用
git add .
git commit -m "agent checkpoint: refactored auth module"
git push origin main

除了從零建立，Artifacts 支援從任意 Git remote 匯入，並從任意 commit point fork 出隔離副本：

從 GitHub 匯入並 fork 成唯讀沙盒

// 從 GitHub 匯入（帶完整 history）
const { remote, token } = await env.ARTIFACTS.import({
  source: { url: "https://github.com/cloudflare/workers-sdk", branch: "main" },
  target: { name: "workers-sdk" },
})

// Fork 成隔離的唯讀副本
// 適合 code review agent 或需要「不修改原始碼」的分析任務
const fork = await repo.fork("workers-sdk-review", { readOnly: true })

三個核心操作構成了 Artifacts 的完整原語集：

create()

從零建立裸 repo 毫秒內可用。適合每個 agent session 需要獨立工作空間的場景——每次任務開始時建立一個 repo，session 結束後可保留歷史或自動清除。

import()

從 GitHub / GitLab / 任意 Git remote 匯入帶完整 commit history 匯入到 Artifacts 管理的 repo。之後可以在此基礎上進行 fork、修改，與原始 remote 完全解耦，不影響上游。

fork()
              從任意 commit point fork，獨立、隔離，選擇性設唯讀
              這是 Artifacts 最強大的原語。可以從任意歷史狀態 fork 出一個完全隔離的副本。readOnly: true 讓 fork 的 repo 只能讀取，無法推送——適合 code review agent 或需要分析但不應修改程式碼的場景。
            

Token 安全性

每個 repo 的 token 是獨立生成的，scope 只覆蓋那一個 repo。即使某個 agent session 的 token 外洩，攻擊者也只能存取那個 session 的 repo，無法橫向移動到其他 repo 或你的整個 namespace。

不只是源碼控制：Git 作為通用狀態持久化

Cloudflare 工程師在推廣 Artifacts 時分享了三個他們自己內部的使用案例——這三個案例都不是傳統意義上的「源碼版本控制」，卻讓人立刻看到 Git 語意作為通用狀態持久化工具的潛力。

Session 狀態持久化自動把每個 agent session 的當前檔案系統狀態加上 session history 持久化在 per-session Artifacts repo。不需要塊儲存（block storage），不需要管理快照——Git 的 commit 機制就是天然的狀態快照，而且自帶 diff 能力。你可以回到任意 checkpoint，看到「那一刻 agent 工作目錄的完整狀態」。

Session 分叉與協作把 session URL 傳給同事，讓他從任意 checkpoint 接手。Debug 卡住了？Fork session 讓另一個人（或另一個 agent）從你停下的地方繼續，帶著完整的 prompt 歷史和工作目錄狀態。這把個人化、短暫的 agent session 變成可協作、可時間旅行的工作空間。

Customer Config 版本控制把每個客戶的配置存成 Artifacts repo，自然支援 rollback、diff、history——用 Git 語意管理結構化配置。想知道「這個客戶的配置在三週前長什麼樣？」一行 git log 就有答案。部署出問題？git revert 到上一個已知好狀態。

通用原語

任何需要 fork / revert / diff 語意的資料——不只是源碼。Artifacts 的 Git 語意適合任何需要追蹤狀態變化的資料：config、session prompt history、per-customer 上下文、實驗結果、生成的文件。只要你需要「回到過去某個時間點」或「對比兩個時間點的差異」，Git 就是對的工具，而 Artifacts 讓這個工具變成 programmatic API。

這三個案例的共同點是：它們利用的不是 Git 作為「源碼管理工具」的能力，而是 Git 作為有版本歷史的鍵值儲存的能力。這個視角轉換很重要——一旦你這樣看 Git，你會發現很多需要「版本化狀態」的問題都可以用它解決，而且不需要發明新的資料格式或協定。

ArtifactFS：超大 repo 的秒啟方案

Git clone 最大的問題是：等待時間隨 repo 大小線性成長。一個流行的 Web 框架 repo 大約 2.4GB，完整 clone 需要接近 2 分鐘。如果每次 sandbox 啟動都要等 2 分鐘，agent 的使用成本和延遲都會高到無法接受。

ArtifactFS 的設計思路是：Git clone，但非同步。把「取得 repo 結構讓 agent 開始工作」和「下載完整 file contents」這兩件事分開，讓 agent 在完整資料到齊之前就能啟動。

1

Blobless Clone — 只取結構，不取內容 sandbox 啟動時，ArtifactFS 只下載 file tree 和 refs，不下載 file contents。這讓 agent harness 在秒級內就能看到完整的目錄結構、知道哪些檔案存在、可以開始規劃任務——即使檔案內容還沒到。

2

背景 Hydration — daemon 並行下載 file contents agent harness 啟動後，背景 daemon 開始並行下載所有 file contents。這個過程對 agent 透明——agent 正常工作，daemon 在背景默默填充。

3
              智慧優先級 — 重要檔案先下載
              hydration 不是隨機順序，而是按照「agent 最可能先讀哪些檔案」來排優先級：package manifests（package.json、go.mod、Cargo.toml）、設定檔（tsconfig、.eslintrc）、源碼檔案優先；binary blobs、build artifacts、test fixtures 最後。這讓 agent 需要的資料幾乎總是先到。
            

4

On-demand Block — 按需阻塞等待如果 agent 讀取了一個尚未 hydrate 的檔案，讀取操作會 block 直到該檔案的 hydration 完成。從 agent 的角度看，這是一個普通的（稍慢的）檔案讀取。從用戶角度看，等待時間被限制在「剛好需要那個檔案的那一刻」，而不是「啟動時一次等完所有東西」。

實際效果是顯著的：2.4GB 的大型 repo，啟動時間從約 120 秒降到 10-15 秒。

成本計算

10,000 sandbox jobs / 月 × 節省 90–100 秒 = 節省約 2,778 sandbox 小時。這只是一個中型 CI/CD 使用場景的數字。對於大量使用 agent sandbox 的團隊，ArtifactFS 的節省效益會遠遠超過 Artifacts 的儲存費用。

重要說明

ArtifactFS 可以與任何 Git remote 搭配使用，不只限於 Cloudflare Artifacts。GitHub repo、GitLab repo、自架 Gitea——只要是標準 HTTPS Git remote，ArtifactFS 都能加速它的 clone 過程。Artifacts 讓你能程式化建立和管理 repo，ArtifactFS 讓你能快速 clone 任何 repo，兩者可以獨立使用。

技術架構：Zig 編譯的 WASM Git Server

Artifacts 的技術決策從一開始就不是「用現有的 Git server 加層包裝」，而是從零開始在 Cloudflare Workers 和 Durable Objects 的約束下重新實作 Git。核心引擎是用 Zig 編譯成 WASM 的 Git 實作。

層	技術	職責
Frontend Worker	Cloudflare Worker	鑑權、metrics 收集、Durable Object 路由。所有 Git HTTP 請求的入口點，負責驗證 token 並把請求轉發給對應的 DO。
Git Engine	Zig → WASM (~100KB)	SHA-1 計算、zlib 壓縮/解壓、delta encoding、git smart HTTP protocol（v1 和 v2）、shallow clone 支援。零外部相依，純 Zig，無 libc。
物件儲存	DO SQLite	Git 物件（blob、tree、commit、tag）儲存在 Durable Object 的 SQLite 中。2MB 以上的大型物件自動分塊（chunked）儲存。
Snapshot / Export	R2	大型 snapshot 和匯出操作存到 R2，避免 DO 的儲存限制。定期 compaction 也使用 R2 作為臨時儲存。
Token 管理	KV	auth token 追蹤，支援 token revocation。每個 repo 獨立 token，支援批量操作時的 token 生命週期管理。

選擇 Zig 有三個具體原因，每個都與 Workers 的執行環境有直接關係：

原因 1

純 Zig，無 libc，~100KB WASM Zig 可以在不連結 libc 的情況下編譯成 WASM。完整的 Git 實作（SHA-1、zlib、delta encoding、git smart HTTP protocol）壓縮成約 100KB 的 WASM module，沒有任何外部相依。Workers 的 startup 時間不受影響，module 載入幾乎是瞬間的。

原因 2

手動記憶體控制，在 DO 限制內工作 Durable Objects 的記憶體上限約 128MB。Git 操作（尤其是 packfile 處理和 delta reconstruction）可能涉及大量臨時記憶體分配。Zig 允許精確控制記憶體佈局和生命週期，確保大型 push/pull 操作不會觸及 DO 的記憶體上限。這在 GC 語言中幾乎不可能做到。

原因 3

11 個 host-imported callback 函式，完全可獨立測試 WASM 模組透過 11 個 host-imported callback 函式與 JS 宿主通訊（讀取物件、寫入物件、查詢 ref 等）。這個設計讓 WASM Git engine 可以完全脫離 Workers 環境、在 Node.js 測試框架中獨立測試。Git 協定的正確性測試和 Workers 整合測試完全分離。

除了 WASM 架構，Artifacts 還支援幾個通常被忽略的 Git 功能：git-notes（讓 agent 附加 metadata 而不改變 commit hash、不污染 commit history）、v1 和 v2 協定（確保所有標準 git client 相容）、shallow clone（只取最近 N 個 commit 的 history，減少初始下載量）。

定價與路線圖

Artifacts 目前處於 Private Beta 階段，預計 5 月進入 Public Beta。定價結構相對簡單，分 operations 和 storage 兩個維度：

項目	單價	免費包含
Operations	$0.15 / 1,000 次	首 10,000 次 / 月免費。Operations 包括 clone、push、pull、fork 等 Git 操作，以及 API 呼叫（create、import 等）。
Storage	$0.50 / GB-月	首 1 GB 免費。Git 物件的壓縮儲存，delta encoding 減少實際佔用空間。

路線圖上，Cloudflare 公開承諾了四個方向的後續功能：

Event Subscriptions push、pull、clone、fork 事件可觸發 webhook，讓你把 Artifacts 接入現有的 CI/CD pipeline 或 agent orchestration 系統。一個 agent push commit，觸發另一個 agent 開始 code review——這個 loop 可以完全自動化。

TypeScript、Go、Python 原生 SDK 目前的 API 是透過 Workers binding 呼叫的。原生 SDK 讓你從任何執行環境（不只是 Workers）以 idiomatic 方式使用 Artifacts，降低在現有 agent 框架中整合的摩擦。

Repo 層級和 Namespace 全局搜尋 API 讓 agent 可以在 repo 內搜尋（語意搜尋或關鍵字搜尋），或跨越整個 namespace 的所有 repo 搜尋。對於「在所有 customer config repos 中找包含某個 setting 的 repos」這類查詢特別有用。

Workers Builds 整合 Artifacts push 可以直接觸發 Workers Builds，實現 agent-driven CI/CD。Agent 寫程式碼 → commit → push 到 Artifacts → 自動觸發 build → 部署到 Workers。整個 pipeline 在 Cloudflare 的基礎設施上完成，agent 是第一公民。

OAO Studio 觀點

Artifacts 最讓人興奮的不是 Git API 本身，而是 session forking：把你卡住的 debug session 的 URL 發給同事，讓他從你停下的地方接手，包含完整的 prompt 歷史和檔案狀態。這把個人化、短暫的 agent session 轉成可協作、可時間旅行的工作空間。「把 Git repo URL 傳給同事」這個動作我們已經做了幾十年，現在它可以代表一個 agent session 的完整狀態——這個習慣可以直接遷移，零學習成本。Artifacts 最聰明的地方或許就是這個：讓工程師已有的直覺繼續工作，只是背後的基礎設施換了一套。

如果你正在建構需要持久化 agent 工作狀態、或需要讓 agent 之間共享和接力任務的系統，Artifacts Private Beta 報名在 developers.cloudflare.com/artifacts。5 月的 Public Beta 開放後，這個原語會讓很多現在需要複雜自訂解決方案的問題變成幾行程式碼。