以 Anthropic Managed Agents 的架構為例，理解持久化事件歷史、可重啓 Harness 和可替換執行環境的職責，以及解耦怎樣影響故障恢復、憑證隔離、啓動延遲和橫向擴展。
上一篇討論了權限和執行記錄怎樣進入組織治理。繼續往運行時內部看，這些記錄、負責調度的 Harness，以及真正執行命令的環境，也有各自的生命週期。一個容器停止，不應該就意味着整個任務從此無法繼續。
Anthropic 的《Scaling Managed Agents: Decoupling the brain from the hands》討論的正是這個架構問題。本文先區分 Session、Harness 與執行環境，再解釋狀態恢復，隨後分析解耦對安全、啓動延遲和擴展的影響，最後回到穩定接口與工程代價。
下面仍用一個假設任務説明：Agent 修復 CSV 解析錯誤、補測試並整理結果。任務需要保存請求和執行經過，也需要代碼文件與測試環境；如果中途進程退出，系統必須知道哪些東西還在、哪些需要重建，而不是籠統地説一句“恢復 Agent”。
一、運行時的組件怎樣拆分h2
1. 單容器架構：共享環境與生命週期耦合h3
把 Harness、工作目錄和會話狀態放進同一個容器，是很自然的起點。讀寫文件可以直接調用系統接口，啓動測試也不用跨服務通信。對於規模有限、任務較短的系統，這樣的簡單性很有價值。
問題出現在不同職責被同一個容器的生命週期綁住以後。容器失去響應時，可能同時失去執行能力、任務進度的訪問入口，以及負責報告狀態的進程。此時看到“沒有新事件”，並不能立即分清是程序卡住、連接斷開，還是環境已經失效。
在 CSV 任務裏，解析腳本報錯本來只是一次工具失敗。如果連會話記錄與調度程序都依賴這個環境存活，局部故障就可能變成整項任務無法接續。
另一類耦合來自位置假設：Harness 默認所有資源都在身邊，接入其他網絡或不同執行設備時，就需要改變它所在的環境。組件共享一台機器不一定有問題；把“必須共存”寫進接口，才會限制替換和擴展。
2. Session、Harness 與 Hands：記錄、決策和執行h3
原文把核心職責拆為 Session、Harness 和 Sandbox，並用 brain / hands 説明決策與行動的關係。Brain 包含模型和驅動它的 Harness；Hands 則泛指承載行動的工具與執行環境，不只是一台容器。
| 組件 | 主要職責 | CSV 任務中的例子 |
|---|---|---|
| Session | 獨立保存追加的任務事件 | 用户請求、工具調用及返回結果 |
| Harness | 調用模型、組織上下文、路由工具並記錄進展 | 把報錯交給模型，路由後續讀文件與測試請求 |
| Sandbox / Hands | 接收動作並在相應環境中執行 | 修改源碼、啓動測試、返回輸出 |
拆分後，Harness 通過接口調用執行環境，不再要求自己住在那個環境裏。環境返回測試失敗或執行錯誤，Harness 將結果納入後續處理，並把相應事件寫入 Session。
Session 因而不是“正在運行的那個進程”的別名。它保存的是任務能夠接續的歷史；Harness 是當前推進任務的執行者；Sandbox 是本次行動使用的工作環境。三者可以協作，但不必擁有相同的存活時間。
這裏説的接口是職責邊界，不要求每個組件都必須拆成一套遠程服務。它們可以先同機部署，但代碼不應依賴“只有這一個進程和容器能夠繼續任務”。
二、故障後任務怎樣繼續h2
3. Session Log 與 Context Window：歷史保存和當前輸入h3
Session 保存發生過什麼，Context Window 決定模型這一輪看到什麼。可以取回一段歷史，不等於每輪都要把完整歷史塞給模型。
CSV 任務可能已經執行了多輪測試，產生大量重複輸出。Harness 可以只為當前推理選擇相關錯誤、最近修改和必要背景；較早的事件仍保留在 Session 中，需要核對時再讀取。壓縮當前輸入，不應該順手破壞唯一一份可恢復記錄。
這也是 append-only log 的作用：新的請求、動作與結果作為新事件追加，而不是用最新摘要覆蓋全部執行經過。順序記錄能支持從某個位置繼續讀取，也能回看某次動作之前的背景。
當前官方事件文檔也將實時事件流與歷史查詢分開。連接斷開後，客户端需要結合歷史和新事件恢復觀察，並處理事件重複；觀看進度的連接不是任務狀態的唯一存儲位置。來源：Session event stream
但事件日誌也不是磁盤鏡像。記錄“修改瞭解析器”可以幫助恢復執行背景，卻不能代替那份修改後的文件。理解恢復機制時，至少要分清三類狀態：
- 任務事件： 請求、調用、結果與進度，保存在 Session 一側。
- 當前推理上下文： Harness 從歷史中組織出的輸入，可以重新構造。
- 環境狀態： 文件、依賴、運行中的進程及中間產物，需要相應的保存或重建機制。
這三類狀態會互相引用，但不能用“會話還在”推斷它們全部完好。
4. Failure Recovery：重啓 Harness 與替換執行環境h3
Harness 可以無狀態重啓，指的是任務接續不依賴舊進程的內存繼續存在，並不是説它運行時不保存變量、緩衝區或當前上下文。
原文的恢復過程，是由外部編排層喚起新的 Harness，讀取獨立保存的 Session 事件，然後從已記錄的位置接着處理。運行期間持續寫入進展，才能讓替代者知道此前做了什麼，而不是隻拿到最初的用户請求。
Sandbox 失效則走另一條路徑：Harness 接到執行錯誤，把失敗反饋給模型；需要繼續時，再按資源配置準備新的環境。這裏替換的是執行能力，不是換一個全新的任務。
| 故障位置 | 可以保留什麼 | 繼續前需要確認什麼 |
|---|---|---|
| 客户端事件連接 | 服務端已經保存的歷史 | 補取遺漏記錄，避免重複展示 |
| Harness 進程 | 獨立 Session 中的進展 | 重建上下文，確認未完成調用 |
| Sandbox | Session 和未受影響的組件 | 恢復所需文件、依賴與資源，再核對環境 |
用 CSV 任務舉例：如果僅 Harness 退出，而執行環境仍在，替代 Harness 可以先檢查文件和測試結果；如果環境也丟失，就需要從可靠保存的源碼與產物恢復。只存在舊的測試成功事件，卻沒有對應版本的代碼，不能直接宣稱當前環境已經通過測試。
從這個架構還能推導出一個重要限制：恢復記錄，不自動提供外部操作的“恰好執行一次”。 假設提交結果的請求已經被遠程服務接受，但返回途中斷開，日誌中可能只有調用請求，沒有成功結果。此時直接重發可能產生重複提交，需要查詢實際狀態，或由接口提供冪等機制。
這是分佈式執行的恢復問題，不是原文已經承諾解決的全部語義。把故障隔離開，是為了能夠定位並繼續處理，而不是把所有失敗都變成無條件重試。
三、解耦後怎樣管理執行與擴展h2
5. Security Boundary：執行環境與憑證訪問h3
執行用户代碼的環境，與管理模型調用和外部服務認證的組件，承擔不同信任職責。把它們放進同一環境，並讓代碼能讀取運行時憑證，會讓一次錯誤執行擁有更大的影響範圍。
原文將憑證訪問移到執行環境之外，並以 MCP 代理和 Vault 説明：調用者提出工具請求，受控組件取得對應憑證，再與外部服務交互，而不是把真實憑證交給生成的腳本。來源：原文的安全邊界設計
官方 Vault 文檔也將憑證註冊與會話引用分開，MCP 憑證在連接對應服務時注入。這個接口讓“任務可以使用某項服務”與“模型可以讀取憑證正文”成為兩件事。來源：Authenticate with vaults
對於 CSV 任務，腳本讀取項目數據，並不意味着它應該拿到創建其他任務的管理憑證。即使需要訪問一個外部工具，也可以由受控入口完成認證。
不過，憑證不可見不等於調用沒有風險。Agent 仍然可能請求工具執行不合適的操作，因此工具權限、網絡範圍與審批仍然要落實。解耦縮小了憑證暴露面，沒有取消行動授權問題。
6. Lazy Provisioning：執行環境與啓動關鍵路徑h3
把 Brain 放在容器裏，還會讓模型開始工作依賴容器先準備好。如果啓動會話必須依次等容器創建、資源裝載、倉庫準備和 Harness 啓動，用户在第一段回答出現前就承擔了整條準備鏈的耗時。
解耦後，Harness 可以先讀取 Session 並開始模型交互。只有確實需要執行代碼或操作文件時，再準備相應環境。一個只需要分析已提供資料的任務，也不必為了一個不會用到的 Shell 先啓動容器。
可以用兩條簡化路徑理解這個變化：
耦合启动：接收任务 → 准备容器与资源 → 启动 Harness → 首次推理按需准备：接收任务 → Harness 读取事件 → 首次推理 → 需要执行时再准备环境這裏優化的是 TTFT（Time to First Token）：從接收工作到出現首個響應 Token 的等待。Anthropic 報告，在它們這次架構調整中，p50 TTFT 下降約 60%，p95 下降超過 90%。這是該系統改造後的結果，原文沒有給出可直接推廣到任意工作負載的統一收益。來源：原文的性能結果
按需準備沒有讓環境創建成本消失。CSV 任務一旦要跑測試，仍需等待必要環境就緒；如果第一步就必須使用 Shell，收益也取決於實際關鍵路徑。首個 Token 更早出現，與整項任務更早完成，是兩項不同指標。
7. Many Brains / Many Hands：計算擴展與執行目標h3
Brain 與 Hands 不再一一綁定後，兩邊可以按不同需求擴展。
Many Brains 關注推進任務的 Harness：多個任務可以由多個可替換實例承接，不必每啓動一個實例，就同時啓動一台專屬容器。原文討論的是這類橫向擴展能力，不意味着多個 Harness 可以毫無協調地同時改寫同一任務。
Many Hands 關注行動目標：一個 Brain 可以把不同工作送到不同環境或工具。CSV 修復可能在代碼環境中改解析器，在另一套環境中執行兼容性測試，再通過專門工具保存結果。一個目標失敗，不必連帶毀掉其他環境和會話歷史。
這也對模型和接口提出了新要求。模型需要分清當前操作應該送到哪裏，Harness 需要把請求路由到正確目標，結果則要能對應回原來的調用。否則，“文件不存在”可能只是讀錯了環境，而不是文件真的丟失。
因此，統一執行接口的價值不是抹平所有環境差異，而是讓調用方式穩定，同時保留目標身份、能力和結果語義。能夠連接多個執行環境，與能夠可靠協調這些環境，是兩個不同層次的能力。
四、穩定接口怎樣支持 Harness 演進h2
Harness 包含上下文組織、工具調度、停止判斷等策略。這些策略與模型能力有關：某個模型需要的補救流程，換一個模型後可能成為額外負擔。若策略和會話存儲、執行環境綁在一起，更換策略就會牽動整個運行時。
原文用 Meta-harness 描述承載不同 Harness 的基礎設施。它不是再增加一個更聰明的 Agent 來指揮所有 Agent，而是固定相對穩定的契約：如何取得事件、如何記錄進展、如何準備資源，以及如何提出執行請求。具體 Harness 可以在這些契約之上變化。
對 CSV 任務而言，舊 Harness 可以使用一種歷史整理方式，新 Harness 使用另一種；只要事件語義和執行接口兼容，就不必為了修改上下文策略，連同任務記錄和測試環境一起推翻。
但穩定接口不等於沒有工程成本。組件分開以後，需要處理調用延遲、超時、重複消息、版本兼容，以及跨組件定位故障。獨立 Session 也成為需要保證可用性與持久性的基礎設施，而不是把數據移出去就自動獲得可靠性。
這些是從解耦結構得到的工程取捨：小型系統可以保持同機部署，長任務或多環境需求增加後再逐步分離。判斷架構是否有價值，應看它是否讓狀態、執行和策略能夠獨立演進，而不是隻看服務數量有沒有增加。
幾個關鍵問題，串起狀態、恢復與擴展h2
Session 與 Context Window 都保存交互信息，為什麼還要分開？
前者保存可恢復、可查詢的任務歷史，後者是模型當前推理的輸入。Harness 可以壓縮或選擇輸入，而不刪除歷史原件。這樣既控制每輪信息量，也保留回看舊事件的能力。
Harness 無狀態，是否意味着每次都從零開始？
不是。它從外部 Session 讀取進展並重建上下文。“無狀態”強調不依賴某個進程的內存長期存活，不是任務沒有狀態，也不是每次只拿最初的用户請求重新做一遍。
Sandbox 可以替換，為什麼文件還可能丟失？
可替換描述的是組件生命週期，不承諾所有臨時狀態都自動持久化。源碼、產物和依賴需要相應保存或重建；內存與運行中的進程也不能只靠事件文字還原。恢復後還要核對實際環境與日誌所指向的版本是否一致。
日誌裏沒有成功結果，就可以重試工具調用嗎？
不一定。遠程動作可能已經發生，只是響應丟失。查詢狀態、調用標識和冪等機制用於處理這種不確定性；單純重放事件不能保證不重複產生副作用。
按需創建 Sandbox 為什麼改善 TTFT，卻不保證縮短總耗時？
它把環境準備從首次模型交互的必經路徑中移出，讓不需要環境的工作先開始。但需要執行時仍要支付準備成本。應該分別測量首個響應、首次工具可用和任務完成的時間。
Many Brains 與 Many Hands 是在説同一種擴展嗎？
不是。前者擴展負責模型交互與調度的實例，後者擴展行動所作用的環境和工具。二者解耦後不必按固定比例增長，但多執行者的協調、多環境的狀態對應仍需單獨設計。
把 Runtime 拆成多個服務，就算完成解耦了嗎？
不算。若某個服務退出仍會丟掉任務唯一狀態，或所有組件必須同步重啓，生命週期依舊耦合。真正要檢查的是：哪個組件可以替換、替換後從哪裏恢復、接口是否保留了必要語義，以及故障會影響哪些職責。