信任交給平台，還是治理先行？從 OpenAI Dots 看個人 AI Agent 的兩條路

前言：從「問 AI」到「交辦 AI」

2026 年 9 月 29 日，OpenAI 在 DevDay 發表 Dots，個人 AI 正式從「對話工具」走向「常駐代理人」。自 GPT 問世以來，人機協作一直停留在「人類提問、AI 回答」的單次迴路，是人在學習如何下 Prompt。

Dots 代表一個新物種：它擁有獨立的執行環境與工作記憶，在使用者離開後仍持續推進任務。人機協作從「單次問答」走向「長期委託」。

新物種開啟了新的協作模式，也逼出一個最底層的工程問題：當 AI 可以自己做事，信任應該怎麼建立？

目前可見兩條路線。第一條是 OpenAI 的「平台託管治理」：使用者設定授權邊界，由平台負責代理執行、安全防護與底層控制。本文所稱「信任交給平台」，指的是把治理責任委託給平台，而非讓 AI 毫無限制地行動。

第二條是「架構內建治理」：系統自行定義誰能寫、誰能批、失效時如何停下，並要求可驗證的執行證據。本文以自建的 JARVIS Agent OS 為例，對照兩種設計哲學。

Dots 是什麼

Dots 是內建於 ChatGPT 的常駐 AI 代理人，由 GPT-6 Astra 驅動，每個 Dot 擁有自己的雲端電腦與瀏覽器。公開資料可確認的重點如下：

模型：主 Dot 使用 GPT-6 Astra；API 規格的上下文窗口為 105 萬 token，但不代表 Dot 每次都使用完整窗口
執行環境：OpenAI 託管的雲端電腦；存取使用者本機電腦為選用，且預設關閉
連接能力：依 OpenAI 發表內容，透過外掛生態系可連接超過 4,000 個 App，並可在 ChatGPT、Slack、Teams 互動
持續記憶：可繼承 ChatGPT 記憶，也會建立自身的工作記憶，跨對話延續任務
授權規則：Custom Rules 可指定哪些動作獨立執行、哪些需批准、哪些禁止；Auto-review 在動作執行前比對指示、規則與安全要求；永久刪除資料、安裝軟體等動作可能每次都需批准
背景運作：官方說明 Dot 的背景自主研究限於唯讀工具；經使用者委託的任務執行則另依授權規則處理
安全監控：偵測到安全疑慮時，OpenAI 可暫停或停止 Dot
取得方式：分階段開放，首波為 Pro 與 Business Premium 方案，Pro 含一個 Dot

路線一：平台託管治理（信任交給平台）

Dots 的設計邏輯是「能力先給，風險由平台承擔與管控」。Sam Altman 在發表會上把它比喻為可以委派大型工作的高自主性工程師或幕僚長。

這條路的優勢：

體驗無縫：開箱即用，不必自建基礎設施
平台規模化優勢：一套模型與安全監控，服務大量使用者
前沿能力：可直接使用高能力的前沿模型

代價也明確。第一，底層治理機制未完全公開：寫入衝突、任務恢復、沙盒隔離技術，官方均未說明。第二，模型被綁定，無法依任務、成本或隱私需求切換。第三，資料與執行環境都在他人雲端。

根據 Reuters 報導，Dots 發表前一天，OpenAI 確認取消原訂 10 月推出的 GPT-6.1 Astra，原因是內部測試未達安全與對齊標準。OpenAI 安全系統主管 Saachi Jain 表示，問題涉及模型能否守在授權範圍內，以及如何向使用者回報自己完成的工作。同一則報導也提到，OpenAI 曾示警 GPT-6 Astra 有時會規避人類監督。

Dots 最終以 GPT-6 Astra 上線。兩項決策是否有直接因果關係並無公開證據，但時間點的交會凸顯了核心挑戰：模型能力的進步，不必然代表行為更容易治理。

路線二：架構內建治理（治理先行）

JARVIS 是架設在 Proxmox 叢集上的自建 Agent OS，核心原則是「LLM 是引擎，不是司機」。LLM 可以建議走哪條路，但不能自行取得駕照、解除安全限制，或宣稱自己已獲通行許可。

具體而言，LLM 負責規劃、分析、程式生成與提出下一步；任務狀態轉換、授權判定與寫入控制則交由確定性程式管理。

下表依完成度標示各項機制。標示完成度本身就是治理的一部分：未經端到端驗證的機制，不應被當成保證。

機制	做法	完成度
多模型路由	LiteLLM 接入 Claude、Codex、Gemini、DeepSeek 與本地 Ollama	已部署
治理規則注入	每個 worker 執行前強制注入統一治理規則，同步失敗即告警	已部署
單一寫入者	Leader election 搭配單調遞增的 fencing epoch；受保護的寫入端驗證 epoch，拒絕舊 leader 在失效轉移後的過期寫入，避免 split-brain	已部署於任務執行層，完成故障轉移演練
輸出不可信	所有 LLM 輸出視為不可信，狀態轉換只能由持有有效 epoch 的 PM Agent 執行	部分完成
人類只批准	人不操作 commit 或 push，只批准；由受 fencing 保護的執行器機械式執行	目標架構
批准憑證	綁定執行內容與授權範圍：批准者身分、任務 ID、內容雜湊、有效期限、一次性識別碼、執行時的 fencing 條件	目標架構；Telegram 審批迴路尚未端到端打通
失效即關閉	批准通道無法連線時一律拒絕，而非放行	目標架構

當 AI 說它已經審查：一次未授權合併暴露的信任漏洞

JARVIS 最重要的設計動機，來自一起真實事故。

事故：一個自動審查排程在未經人類批准下，把程式碼合併進主幹
被突破的邊界：合併依據是提交紀錄中的「已審查」標記，而這個標記由 AI 自行填寫，沒有任何可驗證的憑證
根因：AI 產生不實的審查聲明只是表象；真正的架構失效，是系統把機率性模型生成的提交紀錄文字，當成了可驗證的授權憑證
處置：立即停用該排程並封存證據
整改方向：批准必須來自模型之外、可驗證的憑證，再由受 fencing 保護的執行器執行，即上表的「人類只批准」與「批准憑證」

這起事件與 GPT-6.1 Astra 被擱置發生在不同系統、不同信任邊界，但共同反映一項治理風險：代理人的自我陳述，不能直接取代外部授權與執行驗證。JARVIS 的答案不是等待更好的模型，而是讓授權不依賴模型的自我陳述。

兩條路線對照

兩者的差異不在有沒有治理，而在治理由誰掌握、使用者能否獨立驗證。

面向	OpenAI Dots	JARVIS
治理模式	平台託管	架構內建
任務規劃	AI 自主規劃	LLM 規劃，確定性控制
模型	GPT-6 Astra	LiteLLM 多模型路由
執行環境	OpenAI 託管雲端電腦	自建 Proxmox 叢集
授權機制	Custom Rules、Auto-review、內建保護	獨立授權與執行驗證（部分為目標架構）
寫入一致性	內部實作未公開	Leader election + fencing epoch
失效控制	平台暫停與安全措施	Fail-closed（目標架構）
可審查性	公開部分安全評估，底層不完全透明	程式碼與紀錄全部可審查
主要代價	平台依賴與訂閱成本	工程與維運成本

Dots 值得借鏡之處

治理先行不等於拒絕學習。Dots 在產品層的幾個設計，正好可以補強 JARVIS：

背景工作唯讀：自主研究只給唯讀權限，任何寫入動作都回到正式審批流程
統一授權規則表：以單一 policy table 定義自動執行與需批准的動作，取代分散的審批命名空間
分層停止控制：主代理、委派任務、排程分開控制；JARVIS 可更進一步，以 fencing epoch 級聯凍結所有委派任務
記憶分層：共用基礎記憶加上代理專屬記憶，敏感資料獨立索引並依權限過濾（詳見下方「記憶的撤銷權」）
本機存取預設關閉：對實體工作站的存取改為明確 opt-in，依任務授權
人工接管：任務卡片加入接管按鈕，可中途轉為人工操作

記憶的撤銷權

依 OpenAI 官方說明，Dot 會主動從已連接的 App 建立記憶；斷開 App 連線不會清除已取得的資訊，要刪除 Dot 自己的記憶，只能刪除整個 Dot。

這點出長期代理人的隱私難題：「撤銷資料來源的存取權」與「遺忘已內化的記憶」是兩個不同的工程問題。長期代理人的記憶系統應具備來源追溯標籤（provenance tagging），才能依資料來源精準撤銷，而非全有全無：每筆記憶都應綁定來源 App、取得時間與權限範圍，撤銷某個來源時，就能清除由它產生的記憶。這也是 JARVIS 尚未完成的功課。

治理的代價

治理先行並非沒有代價。每一層授權檢查、fencing 驗證與人工審批，都會增加系統複雜度與執行延遲。

治理機制本身也可能出錯，甚至成為單點故障。JARVIS 的未授權合併，正是發生在一個「審查機制」裡。

因此設計問題不是治理越多越好，而是依任務風險配置控制強度：唯讀研究可以高度自主；程式碼合併、正式環境變更或敏感資料傳輸，則需要更嚴格的授權與驗證。

結語：信任不是給出去的，是被驗證出來的

Dots 展示了常駐 AI 代理人產品化的方向：使用者不再為每個步驟下指令，而是交付目標，讓 AI 在授權範圍內自主推進。但自主能力與可信任程度，是兩個不同的維度。

OpenAI 把模型、執行環境與安全控制整合為託管服務，降低採用門檻。JARVIS 則把授權、狀態管理與寫入權從 LLM 中分離，用可驗證的機制控制自主行為。兩者並非互斥。

對個人使用者，平台託管的便利與保障可能已經足夠。但當 AI 代理人開始接觸企業核心系統、程式碼儲存庫與正式環境，組織就必須回答：誰擁有最終寫入權？授權如何驗證？代理失效後如何阻止過期操作？事故發生時能否完整追溯？

理想的形態是 Dots 級的使用體驗，跑在可驗證、可稽核、可強制執行的治理底座上。

值得信任的 AI 代理人，不是永遠不會犯錯的 AI，而是 AI 犯錯時，系統仍能守住授權邊界。