2026 年 2 月 27 日，OpenAI 與 Amazon 宣布為 Frontier 代理推出有狀態運行環境（Stateful Runtime Environment）——持久化的檔案系統與記憶，可在代理會話中跨工具調用存續。這是一項重要能力。每次執行後就遺忘一切的代理，在根本上是受限的。
但僅有持久記憶對企業 AI 而言遠遠不夠。問題不在於代理是否應該記住——而在於誰控制它們記住的內容，以及誰能看到。
持久代理記憶的前景與風險
持久記憶讓代理能力大幅提升。一個能記住團隊偏好溝通語氣、審批閾值、客戶分群的代理——每次執行都會更好。
風險同樣明確。一個不受控的持久記憶代理可能：
- 累積過時或不正確的事實，隨時間降低輸出品質
- 在部門間洩漏資訊，當記憶未做範圍限定時
- 抵抗合規審計，當無法追溯學到了什麼、何時學的、從哪裡學的
- 建立隱藏依賴，當下游工作流程依賴不透明的代理狀態
對受監管行業——醫療、金融服務、政府——不透明的持久記憶不僅是治理缺口，更是致命傷。
14 項有狀態能力中的 13 項：JieGou 已涵蓋
當我們將 Frontier 的有狀態運行環境與 JieGou 現有架構對照評估時，發現 14 項有狀態能力中已有 13 項被涵蓋：
| 能力 | JieGou 覆蓋方式 |
|---|---|
| 結構化輸入/輸出狀態 | Recipe I/O 結構定義與驗證 |
| 步驟間資料流 | 工作流程執行器中的 previousStepOutputs |
| 基於狀態的條件分支 | ConditionStep 表達式評估 |
| 迴圈狀態管理 | LoopContext 迭代追蹤 |
| 並行執行狀態 | Promise.allSettled 與失敗串聯 |
| 審批閘門狀態 | ApprovalPauseError 與檢查點恢復 |
| 共享記憶（多代理） | StepExecutionContext 上的 sharedMemory |
| 收斂迴圈狀態 | ConvergenceLoop 與評估回饋注入 |
| 檢查點/恢復 | WorkflowCheckpointV2 逐步追蹤 |
| 知識檢索狀態 | RAG 上下文與自動上下文解析 |
| 品牌語調狀態 | 品牌語調設定檔含部門範圍限定 |
| 詞彙表狀態 | 依部門注入詞彙表上下文 |
| 少樣本學習狀態 | 從執行歷史策展少樣本範例 |
唯一的缺口：跨工作流程持久代理記憶——在不同工作流程執行之間持續存在的事實。
第 14 項能力：Agent Workspaces
我們建構了 Agent Workspaces 來補足這個缺口——但有一個關鍵設計決策：每一項持久狀態預設即受治理。
Agent Workspace 是一個結構化的鍵值儲存，範圍限定於帳戶內的代理。每個條目追蹤：
- Key：描述性識別碼（例如
preferred_tone、primary_contact、approved_budget） - Value：學習到的事實（JSON 可序列化，最大 10 KB）
- Source：條目建立方式——
auto（LLM 自動提取）、user（手動設定）或step_output（從工作流程步驟擷取） - Run ID：產生此條目的工作流程執行 ID
- Timestamp：最後更新時間
這些來源中繼資料正是治理型狀態與原始持久記憶的關鍵差異。
運作方式
-
上下文注入：當 Recipe 在關聯了 Agent Workspace 的工作流程中執行時，工作區條目會被格式化為
<agent_workspace>區段，注入提示上下文——與詞彙表、少樣本範例和 RAG 文件並列。 -
自動擷取：工作流程步驟完成後，選擇性的擷取步驟使用輕量 LLM 調用，從輸出中提取持久事實。僅保存跨未來執行有價值的事實——不包含瞬態細節。
-
手動策展：使用者可透過 API 檢查、編輯、新增和刪除工作區條目。這不是黑盒子——而是受治理的資料儲存。
設計約束
- 每個工作區最多 100 個條目——防止記憶無限增長
- 每個條目值最大 10 KB——保持條目精簡且可檢索
- 提示注入約 2,000 token 預算——工作區上下文不會排擠實際任務
- 部門範圍限定——工作區繼承 JieGou 其餘部分的存取控制
為什麼治理型狀態優於原始持久記憶
| 維度 | 治理型狀態（JieGou） | 原始持久記憶（Frontier SRE） |
|---|---|---|
| 可見性 | 每個條目有來源追蹤（source、run ID、timestamp） | 狀態存在於代理運行時內部 |
| 可審計性 | 與審計日誌整合；合規團隊可檢查 | 運行時狀態未暴露給治理層 |
| 範圍限定 | 部門範圍限定並強制 RBAC | 會話範圍限定；跨工作流程範圍不明確 |
| 大小控制 | 硬性限制（100 條目，每條 10 KB） | 檔案系統持久化——無固有限制 |
| 過時管理 | 時間戳 + 手動策展實現事實維護 | 無內建事實到期機制 |
| 合規性 | API 存取支援自動化合規檢查 | 需自行開發工具檢查代理狀態 |
根本差異：Frontier 的有狀態運行環境讓代理更有能力。JieGou 的治理型狀態讓代理更有能力，同時更可審計。
與 Frontier 有狀態運行環境的比較
Frontier 的有狀態運行環境是令人印象深刻的工程成就。持久檔案系統、跨工具調用記憶，以及與 Amazon 基礎設施的整合，為自主代理創造了強大的執行環境。
但它是為代理能力設計的，而非企業治理。運行時狀態針對代理使用進行了優化——不是為合規團隊檢查，不是為部門邊界強制執行，不是為審計軌跡擷取。
JieGou 從相反方向看待持久狀態：治理優先，能力其次。Agent Workspaces 比完整檔案系統更受限——這正是重點。約束（結構化條目、硬性限制、來源追蹤）是功能，不是限制。
對於建構實驗性 AI 代理的團隊，Frontier 的方案很有吸引力。對於在受監管環境中部署 AI、且每一項代理狀態都必須可解釋和可審計的團隊，治理型狀態是唯一可行的路徑。
開始使用 Agent Workspaces
Agent Workspaces 現已透過 JieGou API 提供：
- 建立工作區——為帳戶中的任何代理建立
- 關聯工作流程——執行時自動注入工作區上下文
- 啟用自動擷取——讓系統從步驟輸出中提取持久事實
- 審查與策展——檢查條目、編輯值、移除過時事實
工作區與 JieGou 現有治理堆疊整合：審計日誌、RBAC、部門範圍限定和合規匯出，全部適用於工作區操作。
結論：治理才是差異化因素
持久記憶是有能力的 AI 代理的基本要求。每個平台很快都會擁有。
差異化因素不在於代理是否能記住——而在於你是否能看到、控制和審計它們記住的內容。對企業 AI 而言，治理型狀態不是錦上添花，而是將生產部署與科學實驗區分開來的關鍵要求。
JieGou 的治理型狀態架構涵蓋 14/14 項有狀態能力——每次狀態變更皆可見、可審計、可範圍限定。這正是企業 AI 所需的基礎。
進一步了解 JieGou 的治理架構或與 OpenAI Frontier 比較。