Agent 共享的是環境，而非資料

現今的 Agent 發展，就像是 2000 年代末期的軟體開發領域，當時 Google、Amazon 和 Facebook 在擴展工程團隊與服務方面的秘訣尚未普及。如今，Agent 仍是單體式（monolithic）架構，且它們處理的資料量（通常）很小。

現在，讓我們做個思想實驗。想像一下現在是 2017 年，你的組織已經建立了一個由微服務（microservices）組成的系統，正在處理來自使用者的大量資料（每份大於 1 GB）。你要如何將這些資料傳遞給你的微服務？

由於資料太大，無法塞進 SQL 資料庫，所以你幾乎肯定會將資料上傳到 S3，保留 URL，然後將該 URL 存入 SQL 資料庫，或是透過 Kafka 叢集進行傳送。

你共享的是指標（pointers），而不是資料本身。

這正是 2015 年到 2025 年間系統設計的骨幹，並將 S3 置於所有架構的核心。當時的工作單位是一個物件（object）：你進行攝取（ingest）、上傳，然後處理它。

快轉到 2026 年，現在一切都圍繞著建構 Agent。關於 Agent 有趣的一點是，它們看起來與我們過去所做的非常相似。

想像你是一家在法律領域工作的 AI 新創公司，並請了一位知名演員擔任代言人。你的使用者正將一份又一份的法律資訊文件上傳到你的系統中，以便讓你的 Agent 從中學習。

然而，這與過去的系統有很大的不同。我們過去是在單一文件的規模上運作，但現在，這些 Agent 是透過發現文件之間的關聯，並使用專業工具從中提取資訊來創造價值。

Agent 並非在處理單一的資料片段，它是在處理整個環境——也就是它的 context。每一份資料單獨來看都沒有用，價值僅在於綜觀整個客戶的環境。

時至今日，人們嘗試管理這種情況的方式，幾乎與我們過去所做的如出一轍。我看到開發者們拚命地嘗試將整個檔案系統壓縮並上傳到 S3，或是將所有資料推送到單一的 SQLite 文件中。

這對某些人來說目前還行得通，因為資料規模很小，且 Agent 是單體式的——屬於單人遊戲。但可以合理推斷，Agent 的發展軌跡將會遵循 2010 年代軟體發展的軌跡：一切都會變得更大。更多的資料、更多的團隊、更多的協調。

我們該如何思考一個團隊的「微型 Agent (micro-agent)」將資料交接給另一個團隊的微型 Agent 呢？

我們必須給予第二個 Agent 所有東西：所有的文件、所有的工具、所有的 Cookie、所有的 SQLite 檔案、所有先前進度的資訊，缺一不可。否則，我們無法期待它能產生自己的洞察。

在 Archil，我們對此有深刻的思考：共享的是環境，而非資料。

將所有這些資料上傳到 S3 的某個地方，再下載給另一個 Agent，並配置它所使用的所有沙盒，最後才讓它開始執行，這是不切實際的。

相反地，Agent 的環境應該就是它所使用的磁碟（檔案系統）。

這個磁碟包含了：你安裝的專業二進位檔案、每個使用者的所有文件、輕鬆推導這些文件之間連結的能力，以及與使用者相關、以 SQLite 資料表形式存在的任何結構化資料。

你該如何在不花費大量時間將磁碟上傳與下載到 S3 的情況下，實現這種共享？

事實上，在 Archil 的 Serverless Execution 出現之前，並沒有很好的解決方案。

你看，資料是有「重力」的。如果你將檔案系統儲存在本機磁碟上，那麼如果你之後想存取它，你就必須……在同一個本機磁碟上工作。這對於資源使用率，或是跨團隊共享整個環境以執行不同 Agent 的能力來說，並不是好事。

如果你將檔案系統抽象化一層——作為一個接收 Linux 機器指令並回傳結果的服務——那麼該服務突然之間就能以近乎常數的時間（near-constant time）回應，無論請求來自何處——這與 SQL 資料庫類似。

這在實務上是如何運作的？

你使用 Archil 製作一個 bash 工具，程式碼看起來像這樣：

const bash = tool({
  description: "Run a shell command inside the workdir.",
  inputSchema: z.object({
    command: z.string(),
  }),
  execute: async ({ command }) => {
    const { stdout, stderr, exitCode } = await disk.exec(command);
    return `exit ${exitCode}\n${stdout}${stderr ? `\n${stderr}` : ""}`;
  },
});

現在，最酷的部分來了——如果你的 Agent 可以直接與你合作的任何其他 Agent 共享該工具（以及磁碟上完全相同的檔案），會怎樣？把它想像成一個像這樣的元函數（meta-function）：你提供一個 diskId，就能得到一個 bash 工具——這可以在世界上的任何地方運作。

const buildBashTool = (disk) => tool({
  description: "Run a shell command inside the workdir.",
  inputSchema: z.object({
    command: z.string(),
  }),
  execute: async ({ command }) => {
    const { stdout, stderr, exitCode } = await disk.exec(command);
    return `exit ${exitCode}\n${stdout}${stderr ? `\n${stderr}` : ""}`;
  },
});

buildBashTool(customerDisk1)

對於建構專業 Agent 來說，這具有極大的威力，它們可以在世界上的任何角落，以常數時間在彼此之間交接 context。

我們將此視為「Agent 交接 (agent hand-off)」。我們預期下一代 Agent 將會是多人協作的，處理的資料集比我們今天所考慮的還要龐大，而將 context 從一個 Agent 完全交接給另一個 Agent 的能力，將是建構這些應用程式的關鍵要素。

如果你有興趣嘗試，歡迎透過 https://console.archil.com 啟動磁碟，或是使用 npx disk create，立即體驗 Archil 的 Serverless Execution。