解構全天候自主 AI Agent 架構：從 Temporal 工作流、動態上下文工程到安全審查機制

摘要分析：本報告深入解構由 Lee Rob 於 Stanford CS146S 課程展示的全天候持久性人工智慧代理人（Always-on Persistent AI Agent）系統架構。面對傳統終端機 Harness 因硬體關閉即告中斷、缺乏長效記憶與無法主動觸發等技術瓶頸，該架構採用「薄客戶端 / 厚伺服器（Thin-Client / Thick-Server）」的解耦設計，結合開源 Temporal 耐用工作流（Durable Workflows）、動態工具搜尋（Dynamic Tool Discovery）、子代理人（Sub-agents）記憶體委派以及獨立 Auto-review AI 安全審查機制。這項突破性設計實現了模型跨越崩潰重啟、全天候自主背景執行的能力。對於 AI 產業與專業投資人而言，理解此架構不僅是評估軟體工程自動化的技術基準，更是研判未來 Token 流量經濟學、推理解算成本結構與企業自動化護城河的核心指標。

演進歷程與核心痛點：從終端機 Harness 到全天候代理人

開發者與人工智慧（AI）模型的互動模式，在短短幾年內經歷了四個本質性的演進時代：

1. 第一時代（Era 1：ChatGPT 手動複製貼上）：開發者手動將提示詞輸入 ChatGPT 介面，並將產出的程式碼複製貼回本地編輯器中。
2. 第二時代（Era 2：終端機 Harness 執行 Shell 命令）：開發者開始建構簡易的終端機 Harness（Terminal Harness），使模型具備讀寫本地檔案與直接執行 Shell 命令的能力，大幅提升了開發自動化程度。
3. 第三時代（Era 3：專用 App 與雲端多 Agent 並行）：Agent 進入專屬應用程式與雲端環境，開發者開始嘗試同時並行（Parallel）運行多個 Agent。然而，此階段的根本瓶頸在於使用者人力——開發者必須即時監控並審查 Agent 執行的每一條 Shell 指令，產生了極高的注意力負擔與人眼審查疲勞（Review Fatigue）。
4. 第四時代（Era 4：全天候代理人 Always-on Agent）：當前產業已正式邁入全天候運作階段。Agent 擁有獨立的雲端運算環境（如 Linux 虛擬機器）、專屬記憶庫與動態技能池，能夠在背景環境無障礙運作。即使使用者關閉電腦或入睡，Agent 仍能在背景自主執行長達數天、數週甚至數月的複雜任務。

傳統 Harness 的架構限制與運作痛點

傳統在本地終端機（Terminal）或個人電腦運作 Harness 的主要瓶頸在於：

• 環境依賴性高（State Volatility）：一旦使用者關閉筆電、網路連線中斷或本地程序崩潰，Agent 的執行迴圈（Agent Loop）即刻終止，未完成的任務被迫完全中斷。
• 被動應答與缺乏持久記憶：傳統系統僅能被動等待使用者手動輸入 Prompt，無法回應外部事件（如 Slack 訊息、電子郵件、會議紀錄或 Cron Job 定時任務），且無法建立跨會話（Session）的長效結構化記憶。
• 上下文視窗記憶體阻塞：將所有歷史命令、工具 Schema 與執行紀錄強行塞入單一對話視窗，導致 Token 空間快速耗盡、推理延遲激增與模型回應品質下滑。

系統架構解析：薄客戶端、厚伺服器與 Temporal 持久化工作流

為支援全天候持久運作，系統架構採用「薄客戶端 / 厚伺服器（Thin-Client / Thick-Server）」的解耦設計哲學。

[外部事件驅動源: Slack / Email / Cron Job / Prompt]
                         │
                         ▼
                 ┌───────────────┐
                 │ 事件路由器     │ (去重 Dedupe & 優先級排序)
                 └───────┬───────┘
                         │
                         ▼
   ┌───────────────────────────────────────────┐
   │ 伺服器 (Thick Server)                     │
   │ ┌───────────────────────────────────────┐ │
   │ │ Agent 執行迴圈 (Agent Loop)            │ │ ◄── 狀態持久化 (Database)
   │ └───────────────────┬───────────────────┘ │
   └─────────────────────┼─────────────────────┘
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
┌───────────────┐         ┌───────────────────────────────┐
│ 薄客戶端      │         │ 專屬 Linux VM (Firecracker)   │
│ (Thin Client) │         │ ┌───────────┐ ┌─────────────┐ │
│ 僅傳送/接收   │         │ │ 檔案系統  │ │ Chrome 瀏覽器│ │
│ send_user API │         │ └───────────┘ └─────────────┘ │
└───────────────┘         └───────────────────────────────┘

薄客戶端與厚伺服器的分工邏輯

全天候 Agent 的核心邏輯（Agent Loop）必須託管於伺服器（Server）端，而非存放在虛擬機器（Virtual Machine, VM）或使用者客戶端（Client）。其第一性原理考量包含：

1. 無縫系統更新：軟體工程團隊能在伺服器端即時部署系統 Prompt、修正工具 Bug 或更新邏輯，完全無須等待 App Store 審核，亦無須中斷使用者端點的操作。
2. 高強度計算資源調配：語音轉文字（Transcription）、圖像與影片生成等高負載運算，在伺服器端能夠透過彈性算力池進行極致化優化，遠優於端點設備。
3. 生命週期完全解耦：若將 Agent Loop 放置於 VM 內部，當 VM 因應 Linux 核心安全性更新（Zero-day Patches）而需要重構或重開機時，Agent 的運作狀態將隨之遺失。將狀態與 Loop 存放在伺服器端與資料庫中，方能確保 VM 具備獨立重構與修復的能力。

系統三大模組分工如下： * 伺服器（Thick Server）：維護 Agent 執行迴圈、控制資料庫狀態持久化、處理事件路由分發並控管工具調用邏輯。 * 單一傳輸介面（send_user API）：客戶端與伺服器之間採用極簡的單一傳輸工具 send_user。無論前端介面是 iOS App、桌面軟體、Slack 還是 Email，均透過此 API 交換資料。客戶端接收到回應後，自主決定如何渲染富文本互動元件（如 1Password 密碼登入表單、Stripe 付款連結或草稿確認按鈕）。 * Firecracker 虛擬機器（VM）：為 Agent 提供隔離且安全的 Linux 運算環境，內建完整檔案系統、Chrome 瀏覽器與桌面環境，支援Snapshot 快照保存與即時休眠機制，避免無謂消耗雲端伺服器算力資源。

形象地說，全天候 Agent 就像是一位擁有專屬雲端電腦（Linux VM）與個人檔案庫的數位同事。它平時可在背景休眠，當收到 Slack 訊息、會議邀請或 Cron Job 定時任務時被自動喚醒，獨立完成瀏覽網頁或執行指令等工作。

耐用工作流 (Durable Workflows) vs 傳統任務佇列 (Job Queues)

長週期任務執行中最棘手的挑戰在於雲端基礎設施的暫時性故障。傳統任務佇列（Job Queues）與 Temporal 耐用工作流（Durable Workflows）在崩潰恢復機制上存在本質差異：

在傳統 Job Queue 架構中，若 Agent 執行一個包含步驟 1、步驟 2、步驟 3 的複雜任務，當系統在步驟 3 發生硬體故障崩潰時，佇列僅能選擇將整筆任務重頭重跑（Replay 步驟 1 到 3）。這會造成極為昂貴的重複 Token 浪費，且可能引發不可逆 API 的重複調用風險。

本架構採用開源的 Temporal 系統實現「耐用執行（Durable Execution）」。Temporal 能夠精確紀錄每一個執行步驟的持久化狀態。當基礎設施發生故障或重啟後， Temporal 允許程序繞過已完成的步驟 1 與步驟 2，直接從失敗的「步驟 3」無縫恢復執行，完全保障了長週期任務執行的可靠度。

事件路由去重與優先順序機制

外部事件（如使用者輸入、Slack 群組 @ 標籤、電子郵件通知或背景例行公事）會統一進入伺服器的路由器（Router）。路由器具備去重（Deduplication）與動態優先級排序功能：

1. 最高優先級（High Priority）：使用者直接輸入的 Prompt 指令。當收到此類指令時，路由器會立即暫停（Stop）當前正在執行的背景例行任務，優先分配資源處理使用者需求。
2. 次要優先級（Medium Priority）： Slack 群組對話或電子郵件訊息。
3. 背景優先級（Background Priority）：例行性 Cron Job 或背景日誌整理任務。若短時間內湧入多條同類訊息，路由器會進行訊息合流批次處理（Batching），在單一對話回合（Turn）中統一完成運算。

上下文工程與動態工具調用：如何打造「無限上下文」的錯覺

隨著 Agent 連接的外部服務激增，若將所有模型上下文通訊協定（Model Context Protocol, MCP）伺服器、Google Drive、Gmail、YouTube 等工具的完整 Schema 強行塞入模型的上下文視窗（Context Window），將導致 Token 迅速填滿、推理成本飆升，且模型執行品質會顯著下滑。

動態上下文 (Dynamic Context / Tool Search Tool)

為解決 Context Window 空間遭巨量 Schema 佔據的問題，系統導入了「動態上下文（Tool Search Tool）」機制。

在對話初始化階段，系統僅將所有可用工具的「名稱列表」注入系統 Prompt 中。當模型在對話推理過程中評估需要調用特定工具（例如 Google Drive 搜尋）時，模型會主動發動 Tool Search 指令，按需（On-demand）從檔案系統中搜尋並動態載入該工具的詳細 Schema。此舉大幅減少了非必要工具 Schema 對 Token 空間的常駐佔用。

子 Agent (Sub-agents) 委派機制

主 Agent（Orchestrator）的核心職責是維持極簡的上下文，專注於維護高階待辦清單（To-do List）。當面對高 Token 消耗或具破壞性的具體任務時（例如執行數十條 Shell 命令、處理高解析度圖片或渲染示範影片），主 Agent 會將該任務委派給具備全新工作記憶體（Fresh Working Memory）的子 Agent（Sub-agent）。

子 Agent 在獨立環境中完成執行後，僅將最終產出的摘要結果回傳給主 Agent。主 Agent 的上下文完全不會被中途龐大的工具調用紀錄所污染，從而在使用者體感上實現了「實質無限上下文（Infinite Context）」的視覺與操作體驗。

┌────────────────────────────────────────────────────────┐
│ 主 Agent (Orchestrator)                                 │
│ - 維持極簡上下文視窗 (Sparse Context Window)             │
│ - 專注管理高階待辦清單 (To-do List)                     │
└──────────────────────────┬─────────────────────────────┘
                           │ 委派子任務 (Delegate)
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
      ┌────────────┐┌────────────┐┌────────────┐
      │ 子 Agent A ││ 子 Agent B ││ 子 Agent C │
      │ (Shell 執行)││ (影片生成) ││ (網頁抓取) │
      └─────┬──────┘└─────┬──────┘└─────┬──────┘
            │             │             │ 僅回傳最終執行結果
            └─────────────┼─────────────┘
                          ▼
            [寫入主 Agent 核心對話摘要]

快取優化 (Prompt Caching) 與預加載機制

由於 Agent 運作高度仰賴歷史對話脈絡的重複發送，快取命中率（Cache Hit Rate）直接決定了運算成本。模型提供商對快取 Token 提供高額折扣，因此架構針對 Prompt Caching 進行了極致化優化：

• 靜態順序維護與 Hashing：系統 Prompt 與工具定義（Tool Definitions）在對話頂端必須維持嚴格靜態的排序。即便進行 A/B 測試或功能更新，也必須透過雜湊（Hashing）排序確保靜態區段不被破壞，避免 Cache Miss 導致必須全額支付昂貴的未快取 Token 費用。
• 網頁預加載（Prefetch / Warm Cache）比喻：如同網頁開發中「滑鼠懸停於超連結（Hovering on a link）即預先讀取下一頁（Prefetch）」的優化邏輯，當使用者在客戶端介面開始輸入文字時，伺服器即可預先構建 Prompt 並發送給模型，提前「暖快取（Warm the Cache）」，顯著降低隨後發送訊息時的首字延遲（TTFT）。
• 背景動態壓縮 (Compaction)：模型提供商通常提供 10 分鐘至 60 分鐘的快取維持溫熱期（Warm Cache Window）。當對話 Token 累積過高（如超過 100,000 Tokens），系統會利用使用者離線的溫熱期背景空檔自動發動上下文壓縮（Compaction）與摘要。當使用者於 30 分鐘後返回時，即可直接基於高度壓縮後的快取摘要繼續對話，節省大量未快取 Token 的成本。

記憶分層結構

系統將 Agent 記憶體劃分為四個明確的邏輯層級：

1. 核心事實 (Facts)：包含使用者的核心偏好與關鍵設定（如簡訊偏好採用小寫英文字母格式），此區段於每次對話 Prompt 中強制常駐。
2. 帶日期的日誌 (Dated Logs)：按日期排序的歷史工作紀錄，允許模型在需要時透過指令檢索過去的工作進度。
3. 臨時草稿筆記 (Scratchpad Notes)：僅在當前任務執行期（如未來 30-60 分鐘內）有效的短期臨時記憶，任務結束後即自動清理釋放。
4. 檔案系統 (Files)：將大量資料直接存儲於 Linux VM 的檔案系統中，模型透過執行 grep 或 Shell 指令自主進行高性能檔案搜尋。

自主執行與安全防護機制：階梯式解決方案與 Auto-review AI 審查

全天候 Agent 在執行任務時，必須遵循成本與可靠度最佳化的階梯式解決方案（Ladder of Execution）。

        ┌────────────────────────────────────────┐
        │  1. 自身上下文與歷史對話 (最便宜/最快)  │
        └───────────────────┬────────────────────┘
                            │ 資訊不足
                            ▼
        ┌────────────────────────────────────────┐
        │  2. 外掛 / MCP / API (如 Plaid API)     │
        └───────────────────┬────────────────────┘
                            │ 無 API 可用
                            ▼
        ┌────────────────────────────────────────┐
        │  3. 網路搜尋 (Web Search)              │
        └───────────────────┬────────────────────┘
                            │ 網頁結構複雜
                            ▼
        ┌────────────────────────────────────────┐
        │  4. 電腦操作 Computer Use              │
        │     (Accessibility Tree ──► 像素點擊)  │
        └───────────────────┬────────────────────┘
                            │ 遭遇 CAPTCHA / 2FA
                            ▼
        ┌────────────────────────────────────────┐
        │  5. 尋求使用者協助 (最後手段)           │
        └────────────────────────────────────────┘

問題解決階梯 (Ladder of Execution)

當 Agent 接獲任務時，會嚴格按照以下優先順序嘗試解決問題，僅在低成本手段無效時才升級至高成本手段：

1. 自身上下文與歷史紀錄：優先從現有的對話歷史與載入的偏好事實中檢索解答。
2. 外掛 / MCP / API：調用結構化 API（如透過 Plaid API 讀取金融數據）。
3. 網路搜尋 (Web Search)： API 無法存取時，執行搜尋引擎查詢（如查詢昨晚體育比賽比分）。
4. 電腦操作 (Computer Use)：若目標 SaaS 軟體未提供 API，啟動 Linux VM 中的 Chrome 瀏覽器進行 Headless 自主操作。
5. 尋求使用者協助：僅在上述所有自主手段均宣告失敗（如遇到二階段驗證 CAPTCHA）時，才向使用者發出通知尋求輸入。

Computer Use 技術細節：Accessibility Tree 的 Token 效益

在電腦操作（Computer Use）環節中，若直接對全頁截圖進行多模態視覺分析，將消耗極為龐大的 Token 數量。

系統優化機制優先讀取瀏覽器的「無障礙樹（Accessibility Tree）」。Accessibility Tree 能將網頁結構精簡為極小 Token 量的文字樹狀圖，精確提供按鈕與連結的 DOM 節點位置；僅當遇到彈出式模態視窗（Modals）或無障礙樹失效的情境時，系統才會降級至像素點擊（Pixel-clicking）模式。這使得無 API 的傳統 SaaS 軟體也能在極低 Token 成本下被自動化操控。

安全與 Auto-review 審查機制

在長週期自主運行的情境下，若要求人類手動審查數百條 Shell 命令，極易引發「審查疲勞（Review Fatigue）」，最終使安全機制形同虛設。

為解決此問題，架構採用了獨立的 Auto-review AI 審查模型。正如 Lee Rob 所指出：「盲測顯示，獨立的 Auto-review AI 模型在檢查指令安全性上的表現，大多數時候比人類審查更加出色。」

安全防護架構由三大柱石組成： * 獨立 Auto-review AI 審查：在 Shell 命令送入 Linux VM 執行前，由專門訓練的獨立 AI 模型進行安全威脅評估。 * Prompt Injection 隔絕：非信任輸入（如收件匣中的外來電子郵件或外部 Webhook）會被嚴格標註與隔離，防止惡意指令注入被模型誤判為使用者授權。 * 不可逆操作防護：針對發送 Email、發布 Slack 訊息等不可逆行為，系統強制中斷並產出草稿，要求使用者人眼審查核准後方可發出。密碼與敏感金鑰則完全隔離於模型上下文之外。

模型訓練飛輪與未來 6 到 12 個月的產業挑戰

Agent 架構的成功高度仰賴基底模型能力與 Harness 設計的雙向協調迭代。

   ┌─────────────────────────────────────────────────────────┐
   │                    外迴圈 (Outer Loop)                  │
   │           (每數月推出新模型，提升 Evals 基準)            │
   └────────────────────────────┬────────────────────────────┘
                                │
                                ▼
 ┌─────────────────────────────────────────────────────────────┐
 │                    內迴圈 (Inner Loop)                      │
 │                                                             │
 │  ┌──────────────┐     ┌──────────────┐     ┌─────────────┐  │
 │  │ 每日發現 Bug │ ──► │ 修復 Prompt  │ ──► │ 部署測試與  │  │
 │  │ 與失誤案例   │     │ 與 Harness   │     │ Evals 驗證  │  │
 │  └──────────────┘     └──────────────┘     └─────────────┘  │
 └──────────────────────────────┬──────────────────────────────┘
                                │
                                ▼
   ┌─────────────────────────────────────────────────────────┐
   │                    模型訓練飛輪 (Flywheel)               │
   │  - SFT: 微調 Harness 運作架構與工具調用格式             │
   │  - RL: 強化指令遵循、技能選擇與點擊精確度               │
   └─────────────────────────────────────────────────────────┘

模型訓練飛輪 (Training Flywheel)

• SFT (監督微調)：訓練模型精確理解特定 Harness 的運作架構、工具調用 Schema 格式與對話壓縮邏輯。
• RL (強化學習)：訓練模型在面對數百種可用技能時選擇最佳決策路徑，並提升在網頁 UI 操作中的點擊精準度與指令遵循能力。

推理延遲與成本的分級優化 (Main Agent vs. Helper Sub-agents)

系統架構針對不同的 Agent 任務屬性實施了嚴格的推理（Inference）成本分級策略： * 主 Agent（Main Agent）：直接與使用者互動，要求極低延遲（Low Latency），必須在毫秒級別內回應使用者，採用高性能低延遲的推理配置。 * 輔助子 Agent（Helper Sub-agents）：委派至背景執行的任務通常需要運作數小時，執行時間為 10 分鐘或 12 分鐘的差異對使用者體驗微乎其微。因此，可針對 Sub-agents 採用極致化成本優化的推理方案，顯著降低雲端算力開銷。

雙迴圈機制與多 Agent 失控風險

• 內迴圈 (Inner Loop)：工程團隊每日運作。發現 Agent 執行失誤後，立即將案例轉化為評測（Evals）標竿，修復 Prompt 或 Harness 程式碼，並在部署前通過 Evals 驗證。
• 外迴圈 (Outer Loop)：模型提供商每隔數月推出新一代模型。新模型吸收了歷史失敗資料，使基準測試表現產生階躍式提升。

在多 Agent 協作場景中，當前模型因缺乏群組對話（Group Chat）的訓練資料，容易出現相互通訊失控的風險。歷史上著名的 multbook 事件以及 Hugging Face 偶發的 Agent 迴圈通訊故障，均揭示了缺乏嚴格協定時多 Agent 系統崩潰的危險性。因此，外迴圈訓練必須加速注入多 Agent 協作行為的約束資料。

「刪除產品 (Delete the Product)」哲學

借鑑 Cursor 與 SpaceX 的開發經驗，架構團隊必須建立「當前模型是未來最差版本」的認知共識。六個月前的 Harness 設計在今日可能已完全過時。產品 UI 應保持極簡，避免針對當前模型的特定缺陷進行過度工程化（Over-engineering），隨時準備在基底模型能力躍升時「刪除舊產品程式碼」。

未來 6 到 12 個月的產業挑戰

1. 長周期評測困境（Long-horizon Evals Paradox）：當 Agent 任務執行週期延長至數週甚至一個月，而基底模型每月都在發布更新時，如何建構高效率的長週期評測成為業界核心難題。
2. Token 流量爆發與 Harness 效率極致化：預計明年全球 Token 流量將呈現爆發式增長，針對背景運行的輔助子 Agent 進行推理與 Harness 效率優化，將是商業化落地（ROI）的關鍵決戰點。

關鍵數字

• 2,500 - 4,000 字：本篇 DeepValues 研究分析報告之目標字數範圍。
• 4 個時代：開發者與 AI 互動演進的四個階段（ChatGPT 複製貼上 $\rightarrow$ 終端機 Harness $\rightarrow$ 專用 App 與雲端多 Agent $\rightarrow$ 全天候持久 Agent）。
• 200,000 Tokens：大型語言模型常見的上下文視窗（Context Window）上限範例。
• 100,000+ Tokens：觸發系統在快取溫熱期執行背景上下文壓縮與摘要（Context Compaction）的對話長度門檻。
• 10 分鐘至 60 分鐘：模型提供商維持快取溫熱（Warm Cache Window）的時間範圍。
• 6 到 12 個月：預估 Agent 執行任務週期從數小時擴展至數週/數月、以及產品 UI 架構需重新構建的產業演進時間週期。
• 1 句：引用來源資料時，單次直接引述的最大長度限制。

什麼情況會改變這個局面

以下為基於當前技術發展脈絡，可能改變全天候 Agent 產業格局的四個關鍵發展方向：

1. 長週期 Agent 評測架構（Long-horizon Agent Evals）的突破：若業界開發出能在數小時內精確模擬並評估運轉數週至數月 Agent 行為的新評測方法，企業將加速釋放高級系統存取權限與核心業務託管。
2. 專屬硬體與語音介面的深度融合：若專屬語音硬體裝置（如 Jony Ive 參與設計的全新設備概念）走向成熟，使用者互動模式將從純文字對話框大幅轉變為全天候語音隨身助理。
3. 多 Agent 協作 (Multi-agent Systems) 通訊協定的建立：為解決 Agent 在群組對話中相互通訊失控（如 multbook 或 Hugging Face 歷史事件）的風險，成熟的多 Agent 溝通與權限控制協定若能確定，將釋放跨企業 Agent 協作的龐大價值。
4. 推理（Inference）成本與延遲的大幅下降：若模型提供商針對長尾 Helper Sub-agents 推出極低成本推理方案，將使企業規模化部署全天候 Agent 的投資報酬率（ROI）顯著提升，進一步加速傳統 SaaS 軟體的替代進程。

---

欲深入瞭解更多關於前沿 AI 系統架構、動態上下文工程與企業級 Agent 部署的開源研究與專業分析，歡迎前往 DeepValues Research 官方網站閱讀最新技術報告，或下載體驗 DeepValues App 所提供的智慧科技分析工具。

資料來源

• Stanford CS146S: How always-on agents work — 講者：Lee Rob (上傳管道：leerob YouTube 頻道)

---

[教育用途聲明]：本文為教育用途，不構成投資建議。