受管代理 vs 本地 harness：哪些該保留

Anthropic 與 OpenAI 正在把代理執行階段的基礎設施轉變為產品介面：託管會話、沙箱、追蹤、記憶、移交、評分標準與事件串流,現在更貼近模型供應商,而不是團隊內部那個私有的腳本資料夾。¹²

關鍵重點是什麼?

• 受管代理正成為執行階段層。當供應商達到團隊的安全標準時,會話、沙箱、追蹤、事件與非同步執行,愈來愈應該交給受管基礎設施處理。¹²
• 本地 harness 仍然重要。保留那些承載品味、證據、公開發表完整性、隱私邊界、來源驗證與專案記憶的部分。
• 遷移的單位是工作本身,不是命令本身。斜線命令、Codex 技能、SDK 移交、MCP 伺服器或受管成果,只要驗收標準保留下來,都能承載同一套工作流程。
• 不要把私有機制公開發布。公開貼文應該說明模式與驗收標準,而不是私有提示、確切的 hook 內容、帳號細節或內部評分規則。
• 晉升需要證據。先保持顯式呼叫,跑一次真實任務,記錄結果,只有當使用者可見的路徑確實改善時才晉升。

受管代理平台應該吸收那些屬於通用品的執行階段工作:沙箱執行、有狀態會話、事件串流、追蹤、檔案執行與非同步完成。本地 harness 仍有意義,但職責變得更小、更銳利。保留那些承載產品品味、證據門檻、公開發表完整性、隱私邊界、來源驗證與專案專屬操作記憶的部分。把那些只因為過去沒人封裝執行階段才存在的東西移走。

糟糕的遷移之一,是因為供應商推出了受管基礎設施,就把本地 harness 刪光。第二種糟糕的遷移,是因為某個本地命令、hook 或提示曾解決過真實問題,就全數保留。正確的遷移會對每個元件問一個問題:這承載的是我的標準,還是只是在操作機器?

關於更宏觀的架構,請參閱 AI 代理架構指南。關於本文背後實際運行的本地遷移模式,請參閱 Claude Code 到 Codex 遷移指南、AGENTS.md 模式 以及 Jiro 品質哲學。

關於這道分界中本地工具那一側的討論,Claude Code 作為基礎設施 說明了私有執行階段層為何會壯大,而 Claude Code vs Codex CLI 2026 則比較了兩者的啟動與安全介面。

受管代理改變了什麼?

Claude Managed Agents 為開發者提供一套預先建好、運行於受管基礎設施上的代理 harness。Anthropic 將其定位為適合長時間任務與非同步工作的方案,核心概念涵蓋代理、環境、會話與事件。¹ 同一份文件描述了一個受管環境,讓 Claude 能夠讀取檔案、執行命令、瀏覽網頁、執行程式碼、使用 MCP 伺服器,並在伺服器端持久化事件歷史。¹

Anthropic 的工程說明把這項架構決策講得比產品文件更清楚。Managed Agents 團隊把會話日誌、harness 與沙箱拆分開來,讓三者可以獨立失敗或變更。³ 這項分離之所以重要,是因為它把一個脆弱的單容器代理迴圈,轉化為一套擁有可恢復會話狀態、可替換執行環境、且憑證安全邊界更狹窄的系統。³

OpenAI 透過 Agents SDK 也在朝同方向前進。其 2026 年 4 月 15 日的更新加入了模型原生 harness、原生沙箱執行、工作空間 manifest 抽象,並支援 MCP、技能、AGENTS.md、shell 執行與 patch 套用等常見原語。² SDK 文件也揭露了支援多次執行記憶的會話、追蹤 LLM 生成、工具呼叫、移交、護欄與自訂事件,以及讓專家代理之間轉移工作的移交機制。⁴⁵⁶

這些是新聞。策略問題卻不同:一旦平台推出代理執行階段,本地 harness 還應該做什麼?

執行階段與判斷之間如何劃分?

大多數本地代理 harness 混雜了兩項不該總是擺在一起的工作。

第一項是執行階段的基礎設施。執行階段負責啟動會話、授予工具、準備工作空間、執行命令、儲存事件、處理中斷、恢復工作、串流狀態並記錄追蹤。這項工作從標準化中受益。它也從安全工程中受益,而多數獨立團隊除非有強烈理由,不該再從零打造一套。

第二項是判斷。判斷說明何謂好作品、哪些公開主張需要一手來源、何時某份指南過時到不該發布、何時某個 hook 吵雜到不該強制執行、何時某次來源掃描應該變成筆記而不是文章、何時代理該拒絕一個技術上正確但不值得發出的輸出。這項工作必須留在本地,因為它源自產品、團隊與讀者。

受管基礎設施可以跑出更好的迴圈。它無法決定你的品味該是什麼。

哪些東西該移到受管代理?

把那些不承載產品標準的元件移走。

Anthropic 的 Outcomes 功能展示了這股趨勢的下一步。開發者定義評分標準,受管 harness 佈建一個獨立的評分器,代理則依評分器的回饋反覆迭代。⁷ 這並沒有取消本地標準。它只是給這些標準一個執行階段的位置。

同樣的模式也適用於 OpenAI 的追蹤。SDK 預設會追蹤整次執行、代理 span、生成、函式工具呼叫、護欄與移交,並提供關閉追蹤的控制與導向其他目的地的處理器。⁵ 本地腳本可以模擬這套機制。但生產系統通常更該選擇標準化的追蹤,並送往團隊既有的除錯場域。

哪些該留在本地?

保留那些定義你的標準、你的讀者、或你私有運作脈絡的元件。

產品品味。平台能執行任務,卻無法判斷結果是否讓整體產品更好。保留那些拒絕忙碌、平庸、低尊嚴輸出的品味規則。

證據門檻。保留那些要求當次會話證據、使用者路徑驗證、明指缺口與根因分析的規則。受管追蹤告訴你發生了什麼;由你的標準決定證據是否足夠。

公開發表完整性。把引用規則、來源等級規則、私有邊界檢查、SEO/AIO 檢查與發布門檻都緊靠網站本身。模型供應商不該決定哪些私有工作流程細節可以安全公開。

專案記憶。把精煉的專案準則、風格決策、已知風險、發布邊界與運作日誌放在團隊能檢視的地方。只有當受管會話儲存確實提升耐用性時,才把儲存層移走。

來源情報。保留編輯路由層。掃描器找到 14 則好條目,仍可能輸出零篇貼文,因為正確動作可能是監測、指南維護或一則私人筆記。

晉升政策。保留分階段規則。某項技能可以先設為僅顯式呼叫,某個 hook 可以先以影子模式執行,某個外掛可以停在安裝試行階段,直到真實工作證明它的助益超過干擾。

這份清單才是真正的 harness。檔案與命令只是其中一種實作方式。

團隊該避開哪種遷移錯誤?

毀掉這次遷移最容易的方式,就是保留外形而非工作。

Claude Code 斜線命令、Codex 技能、SDK 工具、受管成果與 MCP 伺服器,並非同一件事換上不同語法。它們是不同的啟動介面。某個斜線命令可能變成一項技能。某項技能可能變成一份受管成果評分標準。某個 hook 可能變成一個追蹤處理器。某段本地腳本可能因為平台揭露了會話或 webhook,直接就不再需要了。

Anthropic 的長時間代理說明從反方向講了同一件事:單靠壓縮並未產出生產等級的作品,因此有效模式還加上了功能清單、進度產物、乾淨的移交狀態與端對端測試。⁸ 這些不是 UI 慣例。它們是證明義務。

遷移時不該問:「我把 /scan-intel 放哪?」應該問:「來源情報工作流程做的是哪份工作?」

對來源掃描器而言,工作不是「執行一個命令」。工作是掃描已設定的來源、證明來源可達、為候選評分、拒絕那些低訊號量的廣泛寫入、把有用的筆記私下保留下來,並把可公開的機會路由到編輯審查。確切的啟動詞可以變,工作流程不會因此流失。

同樣的規則也適用於品質準則。不要把私有的提示集公開發布。把準則轉化為可觀察的完成門檻:證據、使用者路徑驗證、私有邊界審查,以及拒絕削弱產品的工作的權利。

這套思維如何套用到來源情報掃描器?

來源情報掃描器讓這道分界更具體。

執行階段那一側可以移走。受管平台可以執行排程任務、儲存會話、執行瀏覽器或饋送抓取工具、發出事件並保留追蹤。如果一次掃描超時,受管會話應該知道哪些步驟跑過、哪些來源失敗、下一次應該從哪裡接續。

判斷那一側則應該留在本地。掃描器仍需要私有的來源圖譜、評分閾值、重複檢查、寫入量限制與一條編輯路由。當一次掃描找到 14 則候選,不該自動發布 14 則筆記或一篇文章。正確動作可能是一則私人筆記、一項指南維護任務、一條監測佇列,或拒絕公開發出任何東西。

這道區分把吵雜的自動化變成有用的工作流程:

同樣的邏輯也適用於程式設計、指南維護、翻譯與公開發表的工作流程。當平台執行得更好時,把執行機制移走。保留決定該輸出是否值得存在的標準。

移動 harness 前該用哪份檢查清單?

把任何本地 harness 元件移到受管代理平台之前,使用以下檢查清單。

晉升路徑應該乏善可陳:

1. 盤點元件。
2. 為它命名其執行的工作。
3. 將它歸類為執行階段、判斷、記憶、發布、來源情報或安全。
4. 移植最小可用版本。
5. 在一項真實任務上跑它。
6. 記錄發生了什麼。
7. 晉升、修訂或移除。

任何更繁複的做法,通常都是在隱藏不確定性。

團隊今日該如何拆分一套真實的 harness?

對於一套認真的程式設計與寫作配置,我會這樣拆分。

供應商或受管層:

• 沙箱建立
• 檔案執行
• 持久化會話
• 事件串流
• webhook
• 追蹤與 span
• 長時間工作節點復原
• 基本多代理委派
• 供應商支援時的評分標準執行

本地或專案層:

• AGENTS.md 或等效的專案政策
• 公開發表標準
• 引用與來源等級規則
• 產品品質準則
• 私有運作記憶
• 站台專屬的 SEO/AIO 檢查
• 來源情報路由
• 最終發布門檻
• 適用於外掛與共享套件的發布邊界政策

分界線不是「受管 vs 自架」。分界線是「通用執行階段 vs 產品判斷」。

受管代理在哪些地方仍需謹慎?

受管代理平台沒有移除困難的部分。它們只是把這些部分搬了個位置。

你仍需要為工具、檔案、網路存取與憑證設計安全模型。Anthropic 的架構明確把憑證與執行生成程式碼的沙箱分開,方向是對的,但團隊仍需要正確設定資源、保險庫與存取邊界。³

你仍需要可觀察性。追蹤能呈現呼叫圖,卻無法告訴你這份工作值不值得發出。評分器能評估評分標準,卻無法判斷這份評分標準是否表達了正確的品味。

你仍需要內容邊界。公開的遷移文章可以描述模式,卻不該倒出私有提示、確切的 hook 內部、私有檔案路徑、來源清單、帳號細節或專屬編輯評分。

你仍需要分階段策略。Anthropic 指出 Managed Agents 仍處於 beta 階段,所有端點都需要 managed-agents-2026-04-01 這個 beta header,部分功能還需要 preview 存取權。¹ beta 執行階段可以有用,但不必成為每條工作流程的預設路徑。

團隊該帶走什麼?

對工程主管:

• 當平台達到你的安全門檻時,把執行階段工作推往受管會話、沙箱、事件與追蹤。
• 為證據、來源品質、產品品味與發布邊界保留本地標準。
• 把受管評分標準視為承載你既有標準的執行槽,而不是它們的替代品。

對代理打造者:

• 不要一對一移植命令。移植的是待辦的工作。
• 先設為僅顯式呼叫,等真實任務證明價值後再晉升。
• 優先採用追蹤、會話日誌與公開產物,而非私有提示考古。

對公開寫作者:

• 把私有流程轉成公開的驗收條件。
• 引述官方產品文件來描述當下行為。
• 當更好的文章是決策框架時,拒絕只做回顧。

簡短摘要是什麼?

受管代理平台讓本地 harness 變得更小,卻不會讓它失去意義。當平台贏得這份信任時,把執行階段工作移到受管會話、沙箱、追蹤、事件與編排之中。保留那些定義品質、證據、隱私、公開發表完整性,以及哪些工作值得發出的本地標準。

FAQ:受管代理與本地 harness

受管代理會取代本地 AI agent harness 嗎?

不會。受管平台取代的是更多執行階段層:會話、沙箱、事件串流、追蹤與工具執行。本地 harness 在承載產品標準、證據門檻、公開發表規則、隱私邊界、來源情報與專案專屬記憶時,仍然重要。

AGENTS.md 或 CLAUDE.md 裡該保留什麼?

把耐久的專案規則放在那裡:產品看重什麼、完成如何驗證、哪些私有細節不能發布、公開寫作如何審查,以及哪些使用者可見的路徑必須能跑通,任務才算完成。不要把短暫的工具輸出或私有的提示內容塞進永久指示檔案裡。

團隊何時該採用受管代理平台?

當工作需要長時間執行、安全容器、耐久會話、事件串流、非同步完成、追蹤或受管多代理編排,且供應商的安全、成本與資料控管符合用例時,使用受管基礎設施。¹²

哪些東西不該移進公開的 harness 套件?

不要公開私有提示、確切的 hook 內容、敏感檔案路徑、帳號識別碼、token 處理方式、私有來源清單、專屬評分規則,或任何能讓陌生人重建你內部運作系統的東西。要公開的是模式與驗收條件。

參考文獻