為什麼治理型狀態優於持久記憶：企業 AI 的正確選擇

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：最後更新時間

這些來源中繼資料正是治理型狀態與原始持久記憶的關鍵差異。

運作方式

1. 上下文注入：當 Recipe 在關聯了 Agent Workspace 的工作流程中執行時，工作區條目會被格式化為 <agent_workspace> 區段，注入提示上下文——與詞彙表、少樣本範例和 RAG 文件並列。

2. 自動擷取：工作流程步驟完成後，選擇性的擷取步驟使用輕量 LLM 調用，從輸出中提取持久事實。僅保存跨未來執行有價值的事實——不包含瞬態細節。

3. 手動策展：使用者可透過 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 提供：

1. 建立工作區——為帳戶中的任何代理建立
2. 關聯工作流程——執行時自動注入工作區上下文
3. 啟用自動擷取——讓系統從步驟輸出中提取持久事實
4. 審查與策展——檢查條目、編輯值、移除過時事實

工作區與 JieGou 現有治理堆疊整合：審計日誌、RBAC、部門範圍限定和合規匯出，全部適用於工作區操作。

結論：治理才是差異化因素

持久記憶是有能力的 AI 代理的基本要求。每個平台很快都會擁有。

差異化因素不在於代理是否能記住——而在於你是否能看到、控制和審計它們記住的內容。對企業 AI 而言，治理型狀態不是錦上添花，而是將生產部署與科學實驗區分開來的關鍵要求。

JieGou 的治理型狀態架構涵蓋 14/14 項有狀態能力——每次狀態變更皆可見、可審計、可範圍限定。這正是企業 AI 所需的基礎。

---

進一步了解 JieGou 的治理架構或與 OpenAI Frontier 比較。