代理在本機跑完一次任務，畫面上看起來只要模型、指令和幾個工具就能完成。但任務若要持續數小時、由不同成員接手，或在使用者關閉筆電後繼續執行，問題會轉到另一層：工作狀態存在哪裡、代理用誰的權限、程序中斷後如何恢復，團隊又如何追溯它做過什麼？Stacklok 推出的 Mecatl，正是試圖把 AI agent harness 從桌面流程延伸到雲端與 Kubernetes（容器編排平台）的開源方案。這項架構主張值得評估，產品功能和實際治理成效仍要分開檢視。
一、AI 代理要離開桌面，先看 harness 承載什麼
AI agent harness（代理執行框架）是模型呼叫周邊的執行層，涵蓋代理迴圈、工具調用、權限、執行環境與工作狀態。代理需要長時間工作或交由團隊共同管理時，這些部分會決定任務能否恢復、授權能否追蹤。
模型負責依上下文產生下一步，harness 則負責讓這個步驟進入真實工作流程。常見元件包括代理迴圈、工具派送、對話或工作狀態保存、執行程式碼的環境、操作權限及與前端或其他服務的介面。少了其中某一項，短任務或許仍能完成；任務延長後，錯誤重試、程序更新和人員交接就會暴露設計缺口。
單機流程把模型用戶端、工作目錄、憑證和執行程序放在同一個使用者環境裡，狀態有時只保存在記憶體或本機檔案。關掉程序、電腦休眠或檔案被移動，都可能讓下一次執行無從判斷前次進度。多人各自安裝工具，則會出現版本、權限與紀錄分散的問題。根因是執行生命週期和人的桌面生命週期綁在一起，任務的需求卻可能超出單一工作階段。
這不表示本機執行不可靠或必須搬上雲端。個人開發、可快速重跑、資料不宜離開設備的任務，桌面流程反而更容易理解和控制。真正要先問的是任務是否需要離開使用者環境，以及團隊是否有足夠的狀態保存、身分管理與稽核能力接手。
二、Stacklok 的雲端 harness 主張如何處理持續執行
Stacklok 將 Mecatl 設計為可組裝的開源 agent harness，主張同一代理迴圈可在本機、遠端或 Kubernetes 執行，並透過外部狀態與事件紀錄支援程序替換後恢復工作。這是產品設計方向，尚不能單憑官方說明推論每種任務都會更可靠。
「持續執行」不能只理解為讓程序一直開著。雲端工作負載可能重啟或被重新排程，因此代理當前的會話、工具執行結果、待處理動作與錯誤資訊，需要寫入程序外部的持久儲存。恢復時還要避免同一工作被兩個副本同時處理，或重複執行會產生副作用的工具。這些條件涉及狀態模型、鎖定、冪等性和故障恢復策略，單有容器或叢集不會自動補齊。
Stacklok 的 GitHub 專案說明列出 Mecatl 的持久工作階段、附加式事件紀錄，以及 Kubernetes 參考執行環境。該環境使用 Redis（記憶體鍵值資料庫）保存會話狀態與事件，並以 Kubernetes Lease（租約協調資源）協調同一會話的寫入者，另外設有 Pod（容器執行單位）退場流程。這能說明專案如何設計一種參考部署，不足以證明不同團隊的工作負載都能無損恢復；團隊仍須測試程序被中止、儲存短暫不可用、工具已執行但回應未寫回等情境。
多人和多代理協作也涉及身份與責任。若操作記錄只有「代理呼叫了工具」，管理者仍需要知道是哪位使用者或服務發起、代理獲准使用哪些能力、何時要求人工核准，以及動作結果寫到哪裡。Mecatl 專案描述權限、歸屬資訊、核准流程及稽核軌跡等設計；同一份 README 也提醒，身份和稽核紀錄是建構元件，不等同完整的租戶隔離邊界，跨程序的密碼學證明等工作仍在發展。這個限制會直接影響高敏感資料或多租戶服務的採用判斷。
「Mecatl keeps the agent loop independent of the client and execution environment.」Stacklok 在專案文件中以這句話描述其設計目標：讓代理迴圈與用戶端、執行環境分離。這說明了架構方向，不能替代部署測試或安全評估。
Mecatl 將自身描述為元件庫，而非要求應用整套採用的框架。專案包含代理迴圈、工具派送、權限、模型供應商介面，以及 gRPC、HTTP/SSE（遠端呼叫與伺服器推送介面）和 TypeScript SDK（軟體開發套件）等整合入口；應用團隊仍需選擇模型、狀態儲存、檔案系統、使用者介面與執行環境。可組裝帶來選擇空間，也代表整合責任不會消失，還要確認所需元件在目前版本的成熟度和相容範圍。
三、雲端執行增加管理切入點，也增加系統邊界
雲端部署可以把代理工作當作服務或叢集工作負載管理，讓團隊集中處理資源調度、狀態儲存、存取政策與操作紀錄；這些能力來自部署架構和所接服務的組合，不能只靠採用 Kubernetes 或某一套 harness 保證。
Kubernetes 的工作負載控制器可以協助維持指定數量的 Pod、安排重建或執行批次工作，但 Pod 被重建時，應用狀態是否留存仍由外部儲存和程式邏輯決定。Kubernetes 官方文件將工作負載描述為在叢集上執行的應用，並分別說明 Deployment、StatefulSet、Job 等資源用途。工程團隊可沿用既有的監控、部署與資源管理經驗，同時必須自行設計代理會話如何對應這些資源，以及任務失敗後如何通知和補償。
Kubernetes 官方文件指出，工作負載是「an application running on Kubernetes」。這句定義提醒工程團隊，代理服務進入叢集後仍是需要部署與管理的應用；工作排程本身不會提供代理所需的任務語意、權限規則或狀態恢復政策。
| 面向 | 本機單機執行 | 雲端或 Kubernetes 執行 |
|---|---|---|
| 適合任務 | 個人開發、短任務、可重跑工作 | 長時間任務、共用服務、需要集中管理的工作 |
| 狀態管理 | 常依賴本機程序或檔案 | 可連接外部資料庫或持久儲存，仍須設計恢復規則 |
| 權限與稽核 | 由使用者設備和工具各自處理 | 可集中整合身分、政策和記錄，設定仍需團隊完成 |
| 維運責任 | 個人更新、設備和憑證管理 | 叢集、網路、儲存、可觀測性及成本均須維護 |
雲端執行也會讓信任邊界變多。模型供應商、代理服務、工具、檔案系統、身分提供者和使用者介面可能分屬不同系統；提示內容可能包含敏感資料，工具又可能修改程式碼或呼叫內部 API。團隊要界定哪些資料能送往模型、工具可使用哪種身份、代理是否能接觸主機憑證，以及何種操作必須經人核准。若執行環境和控制迴圈分開，隔離效果還取決於網路規則、憑證傳遞方式與沙箱配置。
四、導入前盤點整合成本、隔離與維運責任
導入前要先盤點既有身分系統、資料服務、模型供應商、工具鏈和安全政策，再確認誰負責叢集、狀態資料、憑證與稽核。若這些責任尚未有人承接，換到雲端只會把未解決的工作移到更多服務之間。
身分接合要回答具體問題：代理使用發起者的授權，還是專用服務帳號？使用者離職或權限被撤銷時，已執行中的任務如何處理？代理轉交子任務時，子任務是否只能取得原任務授權的子集合？這些設計會影響追責和最小權限。即使產品支援 OIDC（OpenID Connect 身分驗證協定）、角色或操作歸屬，團隊仍須決定身份映射、權限週期與人工覆核門檻。
執行隔離則要針對代理可能讀寫的範圍測試。產生的程式碼或 Shell 命令是否在獨立沙箱內執行？沙箱能連到哪些網域和內部服務？代理是否能讀取環境變數或其他會話的檔案？日誌是否會記錄秘密？這不是提示詞能獨自解決的風險，需配合容器或虛擬機隔離、網路政策、短效憑證、秘密遮罩和事件留存。Stacklok 的說明提及代理迴圈與執行環境分離，也有本機微虛擬機後端等做法；具體安全邊界要依團隊選用的部署組合檢查。
成本也不只在模型 token。遠端代理可能增加長時間運算、持久儲存、日誌保留、網路傳輸與閒置資源費用；故障排查需要同時理解代理步驟和雲端基礎設施。開源授權能讓團隊檢視與修改程式，卻不等於零維運或沒有供應商依賴。模型 API、資料庫、叢集平台和身份服務仍可能形成替換成本，應確認資料匯出方式、版本相容、升級節奏與服務中斷後的復原路徑。
資料保存週期也要先定義。事件紀錄可能包含使用者輸入、工具參數、程式輸出或系統錯誤，留得越完整越有利於追查，卻也增加個資與秘密資料暴露的機會。團隊需要設定紀錄欄位、遮罩規則、保留期限和可讀取角色，並實際抽查紀錄是否能回答「誰在什麼授權下觸發哪個工具」。若記錄過度精簡，無法復原決策；若所有原始內容永久保存，也可能超過組織的資料治理需求。
模型切換與工具整合同樣要做相容性測試。代理提示、工具輸入格式和模型輸出的差異，可能改變任務完成路徑；抽象介面能降低程式耦合，不能保證各模型對同一指令有相同表現。驗證時可固定任務樣本，記錄完成條件、人工介入次數、錯誤類型和資源消耗，再比較本機與遠端執行的差別。這些資料能協助定位改善來自狀態管理、服務部署或模型本身，避免把整體結果錯歸給 harness。
部署方式可以從本機原型、單一服務或小規模叢集逐步驗證。重要的是先定義測試案例，而非只確認程式「跑得起來」：中止程序後是否能恢復；重複送出請求是否產生重複副作用；使用者權限撤銷後代理是否停止；工具呼叫能否回溯發起者；工作延長一倍時資源與費用如何變化。這些觀察能把產品功能列表轉成與團隊現況相關的驗證結果。
五、從任務需求判斷是否需要雲端 harness
當任務必須在使用者離線後繼續、需要多人接手、要保存長期狀態，或需集中稽核時，雲端 harness 值得進入評估；若工作短、可由人員重跑、資料限制使其不能離開本機，則保留桌面流程可能更合適。
工程團隊可以用任務時長、協作者數量、狀態保存要求、工具影響範圍和稽核義務作為初始判斷。接著對照現有平台：是否已具備佇列、工作排程、狀態資料庫、身份授權與操作紀錄？若核心需求已有既有服務承接，再引入新 harness 的理由要能指出具體缺口；若需把這些元件逐一新建，成本就必須納入採用評估。
- 選一項確實需要長時間執行或跨人協作的代理任務，記錄中斷、交接和權限撤銷時的預期行為。
- 盤點狀態保存、身份權限、工具存取、隔離邊界、稽核留存及雲端成本由誰負責。
- 以小規模部署測試程序中斷、重複呼叫、權限變更與資料復原，依結果決定是否擴大使用。
Mecatl 提供一種把代理迴圈、執行環境和雲端工作負載管理分開思考的架構選項。它是否降低流程摩擦，要看團隊手上的任務、現存平台和治理要求；評估焦點應放在工作能否安全持續、出問題能否復原、每次動作能否追溯，而非只比較功能清單。當這些條件能以實際部署驗證，工程團隊才有依據決定代理是否該離開桌面。
- AI agent harness 管理模型周邊的迴圈、工具、權限、執行環境和工作狀態。
- 雲端部署提供集中管理的切入點，但恢復、安全與治理仍需搭配外部服務和團隊政策。
- 採用前以中斷復原、權限追蹤、隔離和成本測試確認需求是否成立。
常見問題
Q1：AI agent harness 和 AI 模型有什麼不同？
AI 模型依輸入產生回應或下一步；harness 管理代理迴圈、工具派送、權限與執行狀態，讓模型輸出能進入應用流程。
Q2：使用 Kubernetes 就能讓 AI 代理自動恢復任務嗎？
不能只靠 Kubernetes。叢集能管理工作負載，任務狀態要能恢復仍仰賴外部儲存、應用程式的檢查點與重試設計，以及避免重複副作用的措施。
Q3：Mecatl 是否必須部署在 Kubernetes？
Stacklok 專案說明支援本機、遠端服務與 Kubernetes 參考執行環境。實際選擇需依目前版本文件、團隊基礎設施及整合需求確認。
Q4：導入雲端代理前，最先要盤點什麼？
先盤點任務是否需要長時間執行或多人交接，再確認狀態儲存、身份權限、工具隔離、稽核紀錄與維運成本各由誰負責。
