# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Hunter Leath (@jhleath) · 平台：X (Twitter) · 日期：2026-06-09

> 原始來源：https://x.com/jhleath/status/2064006387454349411

## 中文摘要

# 檔案系統即 Agent

幾週前，我們討論了檔案系統如何成為 AI 時代最重要的狀態管理基礎。因此，檔案系統必須為了這個新現實進行演進。我們提到的第一個演進方向，是讓它成為 Agent 可以執行程式碼的地方（首次以 Serverless 的方式），從而消除了 Agent 技術堆疊中對沙盒（Sandbox）的需求。但事實證明，這還不夠激進。今天，我想談談檔案系統實際上是如何「成為」Agent 本身的。

### 沙盒

首先談談沙盒。我的預測是，檔案系統將不再被視為硬碟上用於組織資料的儲存庫（例如 XFS/ZFS），而更像是作為工具提供給 Agent 的服務。舉例來說，如果你建立了一個檔案系統，並匯出如 `getFile`、`writeFile`、`searchFiles` 和 `runContainer` 等 API——作為不同 AI 框架可以使用的工具——那麼你實際上就消除了 Agent 對沙盒的需求，因為檔案系統本身就已經包含了執行不受信任程式碼所需的基礎功能，並且能持續在 Web UI 等介面上呈現相同的資料。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970033429-iaHKTIBa3akAAYSn0png.png)

從根本上說，將「沙盒提供者」視為堆疊中獨立部分的思維存在一個問題：(a) 它成為了你需要明確管理的資源 [你什麼時候要在對話中啟動它？什麼時候要關閉它？] 以及 (b) 它成為了你堆疊中的一個資料孤島，你需要擔心如何將資料移入或移出。

這是一個非常令人興奮的發展，而釋出 Serverless Execution 對於那些被建構生產級 Agent 所需的複雜性壓得喘不過氣的 Agent 團隊來說，簡直是一股清流。

然而，當我們與開發者交談時，Serverless Execution 有一個反覆出現的關鍵問題：真正「呼叫」這些指令的系統在哪裡執行？我們的使用者一直在努力整合其他服務——如果 Archil 是 Serverless 沙盒，那麼 Agent 是在 Render 上執行嗎？是在 Exe.dev 上執行嗎？還是在另一個沙盒提供者上執行？

我們不希望使用者需要處理這類問題，因此我們開始思考：一個 Serverless 的 Agent 應該是什麼樣子。建構 Serverless 產品比傳統產品更困難，因為你需要將服務的輸入和輸出抽象化，所以我們必須與那些正在建構頂尖 Agent 的團隊（如 Clay、Browserbase 和 Wordware）交流，以了解「他們」是怎麼做的。

我們對所發現的結果感到非常興奮。

### 什麼是 Agent？

當你開始建構 Agent 時，第一件事就是規劃該 Agent 需要存取的內容（Context）。Agent 是第一種需要存取多種不同資料來源的應用程式，這樣它才能綜合這些資料來源的洞察。這些內容可能來自工程團隊擁有的資源（如 S3 buckets），也可能來自其他記錄系統（如 Salesforce）。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970034003-iaHKTKkGCa4AAnPg9png.png)

現在，你可以將「沙盒」基礎功能視為一個允許我們「操作」這些內容的函式。在 Linux 環境中執行指令，要麼是用於從內容中「提取」資訊（讓模型有能力在檢視前透過程式碼對資料進行切割與分析），要麼是用於「編輯」內容中的資訊（透過對它能看到的檔案執行如 `sed` 之類的指令）。

驅動沙盒並操作內容的核心是 Agent 迴圈（Agent loop），它負責重複呼叫 LLM，詢問 LLM 下一步應該進行什麼操作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970033865-iaHKTLeuEbsAACrZYpng.png)

即便如此，這仍然不夠，因為還需要有東西來「觸發」Agent 迴圈本身。如果深入探究，這個觸發器通常是某種使用者或系統互動。它可以是 Web 聊天介面中的訊息、iMessage、計時器或 Webhook。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970033512-iaHKTL6v2bIAACuglpng.png)

我們交談過的人越來越多地表示，他們認為從長遠來看，使用者驅動的事件（如 Slack 訊息）最終只會佔 Agent 觸發器的一小部分，因為系統事件的數量（例如自動化的 Datadog 警報、收到 email、看到 LinkedIn 更新、來自另一個 Agent 的交接）將遠遠超過使用者能發送給這些系統的流量。

然而，如果你看看這張架構圖，會發現為了支援僅僅一個生產級 Agent，其複雜度實在太高了！讓我們依序看看每個部分：

- 你需要一個地方來執行你的 Agent 迴圈
- 你需要一個沙盒提供者來操作你的內容
- 你需要將想要使用的內容「複製」到沙盒提供者中
- 你需要設定某種觸發系統來啟動這整個流程
- 理想情況下，你還得在不使用時關閉這些資源，以免在使用者沒使用你的產品時產生巨額費用

這種複雜性在目前大多數 Agent 都是在矽谷、在那些熱衷於建構新基礎設施的公司內部開發時還能接受，但這將阻礙 AI 在企業界的推廣，因為那些團隊不想為了讓系統運作，而拼湊出一大堆基礎設施。

解決這些問題的方案始終是託管式的 Serverless 解決方案。

### 那麼，理想的 Serverless Agent 是什麼樣子？

我認為它看起來更像是這樣。讓我們逐一拆解。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970033832-iaHKTQPwhbgAAH4VPpng.png)

讓我們從內容開始，因為這是傳統 Agent 和我們新的「Serverless Agent」之間相同的部分。你顯然需要先定義 Agent 將存取什麼，並將其設定為一個「workspace」，讓它能以迭代的方式去探索。這就是檔案系統目前在 Agent 中所扮演的角色。

我們也可以看到像 Serverless Execution 這樣的工具，如何允許 Agent harness 啟動大量並發容器，以隔離的方式執行 Linux，而不會影響 Agent harness 本身。

但還有第三個部分——即 Agent harness。今天，它通常在真實的、長時間執行的伺服器上執行（無論是在沙盒內還是沙盒外）。但其實沒有理由非得這樣。如果我們的 Agent 服務允許我們自動獲得一個連網的 Webhook 指向 Agent，那麼我們就可以用 Serverless 函式的方式（執行一輪後退出）或「流動運算」（fluid compute）的方式（持續執行直到閒置夠久而關閉）來定義我們的 harness，並處理 Agent 的工作負載。

由於檔案系統/內容是持久化的，我們可以用它來儲存對話歷史和 Prompt，這樣任何 harness 的「重啟」都能讓我們精確地從使用者中斷的地方繼續，而無需擔心狀態問題。

### 這與檔案系統有什麼關係？

此架構的關鍵組件在於擁有一個儲存層，它能夠：跟上不斷湧入的 Agent 互動量、在沒有外部服務的情況下自行執行程式碼，並透明地與記錄系統同步。如果你擁有該組件（我認為我們在 Archil 中已經做到了），那麼你就可以設想一個完全在檔案系統上執行的 Agent，看起來就像這樣：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780970033456-iaHKTQtD5boAAWlBWpng.png)

當我意識到通用運算的深層解鎖在於「你執行的可執行檔只是資料，與儲存在電腦上的其他資料沒有區別」時，發生了一些神奇的事情。

在這個世界觀中，同樣發生了一些神奇的事。Harness 本身就是資料，它可以儲存在檔案系統上——同樣也在內容中。對話歷史只是資料。與記錄系統的連線也只是資料。

Archil 目前提供了我們所謂的「Agent 工具集」，這是與檔案系統內容互動與操作所需的最小工具集，但很快 Archil 就會具備更酷的功能。

你可以指定執行 Agent harness 的程式碼在檔案系統中的位置，並直接呼叫它——無論是透過 REST API 進行整合，還是如果你想將其連線到其他上游服務，則透過 Webhook 呼叫。

我認為基礎設施層正在迅速崩塌並收斂到這個架構圖中。團隊不會再向 10 個不同的供應商購買單點解決方案來執行 Agent 堆疊的不同部分，他們將會整合到一個執行堆疊所有部分的單一服務中。我認為這源於持有這些內容的持久化儲存層。我認為這就是一個你的 Agent 可以執行的檔案系統。我認為這就是 Archil。

## 標籤

Agent, 自動化, 其他, File System, Agentic Workflow