關上電腦 AI 繼續幫你工作！SpaceX 成員揭露 Grok Bot 是如何工作的
SpaceX 團隊成員 Lee Robinson 近日在一場約 44 分鐘的技術演講中，深入解析 Grok Bot 背後的系統架構，涵蓋持久化工作流程（Durable Workflows）、雲端虛擬電腦、長期記憶、子代理協作，以及如何透過 Context Engineering 降低 AI 運作成本。他更預測，未來 6 至 12 個月，AI Agent 的自主工作時間有望從數小時延長至數週，甚至數個月。
Agent 正進入第四個時代
Lee 在演講中將開發者使用 AI 的演進歸納為四個階段。
第一階段是開發者從 ChatGPT 複製程式碼，再手動貼進編輯器。第二階段則是 Coding Agent 開始能夠直接編輯檔案、執行 Shell 指令，並透過簡單的工具呼叫迴圈完成工作。
廣告 - 內文未完請往下捲動
第三階段，AI Coding Agent 逐漸發展成獨立應用程式，開發者可以同時啟動多個 Agent，甚至讓它們在雲端平行執行。然而，人類依然是整個工作流程的瓶頸，必須不斷審查 AI 提出的指令、確認執行結果。
如今，產業正進入第四階段：Always-on Agent（常駐型 AI 代理）。
這類 Agent 不再依賴使用者持續輸入 Prompt，而是擁有獨立的電腦、記憶及工具，可以根據預先設定的工作流程，或 Slack 訊息、電子郵件等外部事件，自主啟動任務。
與過去需要使用者不斷提示 AI、等待結果的互動方式不同，新一代 Agent 更接近真正的同事。例如，使用者可以要求 Agent 查看某個討論串，接著立刻補充「其實改成週四處理」。系統不需要等待前一項任務完成，就能理解新的指令、調整優先順序。
而且，這些 Agent 不一定會在完成每個步驟後立即回報。它們可以自行判斷哪些事情值得通知使用者，哪些只需要默默完成。Lee 認為，這也是為什麼 AI Agent 的介面反而越來越簡單。相比複雜的工作流程控制台，使用者其實只需要像傳訊息給朋友一樣，就能指派工作給 AI。
AI 不必真的 24 小時開機：Grok Bot 如何打造永不下線的代理？
常駐型 Agent 聽起來意味著電腦必須全天候運行，但 Grok Bot 採用了不同的設計。
Lee 解釋，Grok Bot 的核心架構主要分為三個部分：負責接收訊息的用戶端（Client）、管理 Agent 執行邏輯的伺服器（Server），以及真正操作軟體的雲端電腦（Computer）。
其中，雲端電腦運行在 Firecracker 虛擬機器之上，擁有 Linux 系統、瀏覽器、桌面環境與檔案系統，能像人類使用電腦一樣執行命令、點擊網頁或使用應用程式。
但關鍵在於，這台虛擬電腦不需要一直開著。當使用者發出指令，或某個外部事件觸發 Agent 時，系統才會啟動必要的運算資源。工作結束後，電腦就能進入休眠狀態，並將對話歷史、記憶及工作進度保存至資料庫。等到下一次任務出現，Agent 就能重新載入先前狀態，繼續工作。這種架構不只降低長期運行成本，也能讓 AI Agent 在電腦關機、程式崩潰或系統更新後繼續執行任務。
Lee 特別強調，Agent 的核心執行迴圈不應直接綁定在虛擬電腦上，否則每次需要更新 Linux 系統，或重新建立虛擬機器時，都可能影響 AI 的工作狀態。
為了解決長時間任務可能中斷的問題，團隊還採用了開源工作流程引擎 Temporal。傳統工作佇列在發生故障時，可能需要重新執行已完成的步驟；持久化工作流程則能記錄任務進度，讓系統在恢復後從適當的步驟繼續，而非一切重來。這也是 Always-on Agent 與一般聊天機器人的根本差異：真正重要的不只是 AI 有多聰明，而是它能不能可靠地完成需要數天、數週才能結束的工作。
一個主要 Agent 管理多個助手，讓 AI 擁有近乎無限的工作記憶
除了執行環境，Lee 也談到另一個限制 AI 長期工作的瓶頸：Context Window（上下文視窗）。即使模型能夠處理數十萬個 Token，當 AI 持續工作數小時或數天，累積的訊息、工具執行結果與任務記錄仍然可能超出模型的上下文容量。
Grok Bot 的做法，是將主要 Agent 設計成協調者（Orchestrator），再把複雜工作分配給多個子代理（Subagents）。例如，使用者要求 AI 製作一份產品展示影片，主要 Agent 可以將影片製作交給專門的子代理。子代理獨立使用自己的上下文視窗、執行工具、處理檔案，最後只向主要 Agent 回報結果。
如此一來，數百次工具呼叫與大量中間資訊，就不需要全部塞進主要 Agent 的對話紀錄。Lee 形容，這讓使用者感受到的 AI 系統彷彿擁有無限上下文。不過，他也強調，真正的無限 Context 並不存在。系統只是透過分工、檔案儲存、摘要與資訊檢索，讓有限的上下文容量可以支援更長時間的工作。
他進一步表示，這套運作方式其實與管理工程團隊相當類似：主要 Agent 負責協調工作、追蹤待辦事項；不同子代理各自處理專業任務，並在必要時回報進度。
AI 的記憶不必全部塞進 Prompt：Markdown 與檔案系統成為關鍵
在長期記憶方面，Lee 分享了一個相當務實的觀點：與其不斷擴大 Prompt，不如善用檔案系統。Grok Bot 將不同類型的資訊分層保存，包括使用者的重要偏好、歷史工作日誌，以及只在短時間內有用的暫存筆記。
例如，假設使用者習慣所有英文訊息都使用小寫字母，這種偏好可能需要在每次與模型互動時提供。但如果只是今天下午某個專案的臨時工作進度，就不一定需要永久留在主要上下文中。至於過去數週的工作紀錄，Agent 可以直接透過 Linux 指令搜尋檔案，找到需要的資訊。
另一方面，使用者還能將特定工作的標準作業流程寫成 Markdown 格式的 Skills，讓 Agent 在未來執行相似任務時重複使用。Lee 認為，模型已經越來越擅長操作檔案與命令列工具，因此檔案不只是儲存資料的地方，也能成為 Agent 的記憶、技能與工作流程載體。
更進一步，未來 AI 甚至可能觀察使用者如何完成某項工作，然後自動將這套方法轉換成可重複使用的技能。這意味著，Agent 不再只是執行一次性的 Prompt，而是能逐漸累積工作經驗，形成自己的操作習慣。
Token 成本是 Always-on Agent 最大的工程挑戰之一
隨著 Agent 開始自主執行長時間任務，Token 消耗也成為不可忽視的成本問題。Lee 在演講中花了相當大的篇幅解釋 Prompt Caching（提示快取），並指出一個好的 Agent Harness，必須盡可能保留快取命中率。
一般而言，AI Agent 每次呼叫模型時，經常需要重新傳送前面的對話紀錄、系統提示與工具定義。如果這些內容保持一致，模型供應商便有機會利用 Prompt Caching，降低重複處理相同 Token 的成本。反過來說，如果系統頻繁調整工具定義、變動 Prompt 順序，就可能破壞快取，讓原本能以較低成本處理的內容重新計費。
因此，Grok Bot 採用了多項 Context Engineering 優化方式。其中之一是動態工具探索（Dynamic Tool Discovery）。當使用者安裝 Gmail、Google Drive 或其他 MCP 工具時，系統不會把每項工具的完整說明都放進模型上下文，而是先提供精簡的工具資訊，等到 Agent 真正需要使用時再讀取詳細定義。
另一個方法則是將冗長的工具執行結果直接存入檔案，而非全部留在對話中。此外，當 Agent 累積大量上下文後，也必須透過 Compaction（上下文壓縮），將冗長的歷史紀錄轉換成更精簡的摘要。Lee 提到一個有趣的優化策略：假設使用者剛結束一段超過十萬 Token 的對話，而模型供應商的 Prompt Cache 仍然有效，系統就可以趁快取尚未失效時先完成摘要。
如此一來，等使用者稍後回到對話，就能直接從較短的上下文繼續工作，不必重新負擔整段歷史紀錄的成本。不過，Lee 也承認，任何摘要都可能造成資訊損失，因此如何在壓縮過程中保留最重要的事實，仍是非常困難的工程問題。
讓另一個 AI 審查 Agent，比人類逐一核准指令更安全？
當 AI Agent 開始擁有電腦操作權限、安全問題自然也更加重要。Lee 提到，Grok Bot 類型的系統可以透過 Auto Review 機制，讓另一個 AI 模型審查 Agent 即將執行的指令。他認為，當使用者必須連續審查數百個 Shell 指令時，很容易因疲勞而忽略風險。相較之下，專門負責安全審查的模型，在某些情況下反而能提供更可靠的檢查。
不過，這不代表所有操作都能完全交給 AI。例如，發送電子郵件、傳送 Slack 訊息等可能無法撤回的操作，仍然應該設置額外的確認機制。系統也必須避免 Prompt Injection（提示注入）攻擊，特別是防止 Agent 將惡意電子郵件、外部網頁內容或 Webhook 資訊誤判為使用者的直接指令。
此外，密碼及其他敏感憑證應盡可能保留在模型對話之外，透過專門的身分驗證與授權機制處理。Lee 強調，AI Agent 越能獨立工作，確保它不會被惡意第三方接管，就越是重要。
未來 6 至 12 個月，AI Agent 可能連續工作數週甚至數月
談到下一階段的發展，Lee 提出幾項預測。首先，Agent 能夠獨立工作的時間將大幅延長。目前許多 AI Agent 的工作仍然以數小時或一天為單位，但他認為，未來 6 至 12 個月內，這個時間尺度可能延長至數週甚至數月。
其次，AI 將更擅長從過去的對話及工作紀錄中找回資訊。無論底層採用檔案、知識圖譜或其他記憶架構，使用者都不需要反覆向 AI 解釋相同的背景。
第三，Agent 會越來越擅長在工作過程中學習新技能，並將這些技能轉換成可重複執行的工作流程。
不過，長期自主工作也帶來新的評估難題。Lee 舉例，如果一個 Agent 需要連續工作一個月才能完成任務，但 AI 公司每個月就會推出新模型，那麼開發者要如何在模型更新之前，確定這個長期工作流程依然可靠？這代表 AI 評測方法也必須改變，不能只看單次回答、程式碼生成或短時間任務的表現。
另一個尚未解決的問題，是 Agent 應該在什麼情況下主動聯繫使用者?如果 AI 發現使用者錯過某堂課，主動整理課程錄影與筆記，可能是貼心的協助；但如果它對每件小事都發送通知，反而可能成為干擾。
Lee 認為，如何在主動協助與避免打擾之間取得平衡，將是下一代 Agent 產品的重要課題。
模型越聰明，軟體介面反而應該越簡單
演講最後，Lee 分享了他在 Cursor 與 SpaceX 工作時的一項產品開發原則：Delete the Product（刪掉產品）。這並不是指真的將產品下架，而是開發者應該假設今天使用的 AI 模型，可能已經是未來最不聰明的一個版本。
隨著模型能力持續進步，許多今天必須透過複雜介面、工作流程與規則才能實現的功能，半年後可能只需要一段自然語言指令就能完成。因此，開發團隊不應過度依賴現有模型的限制設計產品，而應盡可能保持系統簡潔，替下一代模型預留發揮空間。
Lee 也引用 OpenRouter 相關人士的觀點指出，如今不少 AI 應用程式看起來都十分相似，幾乎都有側邊欄、聊天視窗與 Agent 介面。
但這未必代表產品缺乏創新。就像早期網路應用程式普遍需要伺服器、資料庫與基本的資料操作介面一樣，Agent、持久化工作流程、沙盒、雲端電腦、記憶、Skills、支付、身分驗證與安全評測，也正在成為下一代軟體的基礎元件。他認為，未來每個產品可能都需要具備某種 Agentic 能力，或者成為其他 Agent 能夠存取的資料與服務。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。
