你有沒有遇過這種情況：你用 Claude Code 或 Cursor 跑一個自動化任務，設定好提示詞讓它自己跑迴圈——抓取網頁、分析資料、寫程式碼、下指令。結果兩個小時後回來看，它卡住了。不是因為任務太難，而是因為它所在的容器掛了，連帶你的 session 也跟著一起報廢。

如果你是單人開發者，可能只覺得「喔，重跑一次就好」。但如果你的團隊有十幾個人共用同一個 AI Agent，事情就沒這麼簡單了。

一位開發者在分享自己團隊的架構實踐時，提出了一個看似簡單但影響深遠的問題：AI Agent 的驅動引擎（agent harness）到底該放在 sandbox 裡面，還是外面？

這個問題不是無聊的架構選擇。它決定了你的 Agent 能不能安全地處理敏感資料、能不能在半夜自動修復錯誤、以及最重要的事——當容器掛掉的時候，你的工作會不會一起消失。

兩種架構，兩種哲學

先來釐清什麼是「agent harness」。它其實就是驅動 LLM 的核心迴圈：送出提示詞、接收回應、執行模型請求的工具呼叫、把結果餵回去、重複這個過程，直到模型說「完成了」。每個上線運作的 Agent 都有這樣一個迴圈。問題只在於：這個迴圈跑在哪裡？

Harness inside the sandbox

這是大多數人最熟悉的模式。你把整個 Agent 迴圈、程式碼環境、工具執行器全部塞進同一個容器裡。LLM 的 API 呼叫從容器內發出，bash、read、write 這些工具也在容器內執行。技能（skills）、記憶（memory）、以及其他狀態資料，都存放在容器本機的檔案系統中。

這個模式的好處顯而易見：簡單。一個容器、一個程序樹、一個檔案系統、一個生命週期。你不需要額外的基礎設施，Claude Code SDK 拿來就能用，所有 off-the-shelf 的工具都假設你在同一個環境裡運作。

但這個簡單是有代價的。而且當你的 Agent 開始從「玩票」變成「生產力工具」時，這些代價會逐一浮現。

從開發者的角度看，inside sandbox 模式就像把自己的錢包放在公共置物櫃裡。在封閉的、單人的環境中這完全沒問題——置物櫃只有你有鑰匙。但一旦置物櫃變成了多人共用的 locker room，問題就來了。

Harness outside the sandbox

另一個選擇是把驅動迴圈放在你的後端伺服器上。當 Agent 需要執行工具時，它透過 API 呼叫一個 sandbox，sandbox 執行完工具後回傳結果。驅動迴圈永遠不進入 sandbox。

聽起來多了一道手續，但這正是讓 Agent 真正能夠「生產力上線」的關鍵。

為什麼要把發電機搬出去？

Mendral 團隊不是為了追求架構上的美感才做這個決定的。他們在 production 中實際遇到了問題，然後才意識到 inside sandbox 模式的天花板。根據他們的分享，把 harness 搬出去取得了幾個 inside 模式完全做不到的事情。

你的 API 金鑰永遠不會進到 sandbox

這可能是最直接也最重要的一點。當 harness 在外面時，LLM API 金鑰、使用者 token、資料庫存取權限，全部由外部的 harness 持有。Sandbox 裡面只有 Agent 執行工作時需要的環境，沒有任何敏感的 credential 可以讓 Agent 去「偷走」或「洩露」。

在 sandbox 內部模式下，你的 API 金鑰必須跟著容器走。如果 Agent 被 prompt injection 攻擊成功——這種事情在 production 環境中比你想象的更常見——攻擊者可以透過容器拿到你的 credential。這不是理論上的風險。2025 年已經有多起公開的 Agent 安全事件，攻擊者透過精心設計的輸入讓 LLM 執行有害指令，進而取得系統中的機密資料。

把 credential 和 sandbox 分開，等於是從根本上消除了這個攻擊面。不是「降低風險」，而是讓 credential 物理上不在 sandbox 中。即使 sandbox 被完全攻陷，攻擊者也拿不到你的 API 金鑰或資料庫權限。Mendral 團隊的說法很直接：「sandbox 裡沒有任何可以 escape 出去的東西，所以不需要設計權限模型，也不用擔心 credential 洩漏。」

對台灣的開發團隊來說，這點尤其值得注意。台灣有許多團隊在協助金融、醫療、半導體等高度監管產業導入 AI Agent。這些產業對資料安全的要求非常嚴格。如果你的 Agent 會接觸到客戶資料或內部敏感資訊，outside harness 的設計不只是「比較好」，而是合規的要求。

Sandbox 不再是你的 session

在 inside 模式下，sandbox 就是 session。容器掛了，session 跟著掛。

在 outside 模式下，sandbox 變成可以被任意調度、暫停、重啟的資源。Agent session 的生命週期和 sandbox 的生命週期完全脫鉤。

這意味著：

Mendral 團隊遇到一個具體痛點：他們的 Agent 有時候需要跑數小時的任務，中間可能經歷好幾次 rolling deploy。如果 harness 在 sandbox 裡面，每次部署都是 session 終結。但在 outside 模式下，session 是 durable 的——中間可能有十個不同的 sandbox 輪流上場，使用者完全無感。

多人協作不再是分散式檔案系統問題

單人開發者跑 Agent，技能和記憶都存放在筆電本機。但一旦你讓一個團隊的十幾個人共用同一個 Agent，事情就變得複雜了。

假設團隊的工程師星期一教會了 Agent「這個專案總是從 release branch 部署」。星期五另一個工程師在同一個 Agent 上遇到一樣的問題——如果 Agent 的記憶是存在 sandbox 本機的，它什麼都不記得了。

你可能會說：「那就把 sandbox 當成長期運行的容器，不要殺掉就好了。」這確實是一個解法。但這樣一來，你又回到了「照顧一個容器」的套路——它掛了你得重來，它重啟了你失去狀態。更別提每次部署新版本時，這個容器該怎麼辦？

真正的痛苦是：多人協作本質上是「共享狀態」問題，而 shared filesystem 是這個問題最古老的解法之一。用 sandbox 本機檔案來管理 Agent 的記憶和技能，相當於在多個編輯器同時編輯同一個檔案時，期待不會有人覆蓋別人的修改。

Mendral 團隊的答案很乾脆：不要再假裝 sandbox 有本機檔案系統了。 把記憶和技能放在資料庫裡，讓 harness 從資料庫讀取。Agent 仍然可以像操作檔案一樣看待這些東西——只是在後端，它們的實際儲存位置已經改變了。

他們進一步提出了「單一介面、雙重後端」的概念。對 Agent 來說，它讀寫的仍然是檔案。但 harness 在背後做了路由：原始碼和執行環境的檔案走 sandbox，而技能和記憶走資料庫。Agent 不需要知道差異，它只需要知道「我需要這個檔案」和「檔案在這裡」。

把理論變成現實：他們是怎麼做到的

把 harness 搬出 sandbox 聽起來很有道理，但實際執行起來有三個核心問題要解決。

問題一：Durable execution

Agent loop 是一個長時間執行的函式。幾分鐘是基本，幾小時是常態。它必須能存活過 rolling deploy、scale event 和 instance failure。

Mendral 團隊選擇了 Inngest 作為他們的 durabale execution 平台。每個 loop turn 是一個 step，Inngest 會為每個 step 建立 checkpoint。伺服器重啟時，loop 從上次中斷的地方繼續執行。

選擇 Inngest 而不是更通用的 Temporal，原因是他們已經在 CI 管線上使用了 Inngest，且不需要 Temporal 的完整功能。對多數台灣團隊來說，這也是一個務實的建議：從你已經用過的基礎設施出發，而不是為了一個新問題引入全新的技術棧。無論是 AWS Step Functions、Redis queues、還是單純的 PostgreSQL 輪詢，只要能實現「checkpoint + resume」的模式，都比引入一個全新的基礎設施要務實。

這裡有一個台灣團隊可以參考的做法：如果你的 Agent 目前還在使用同步式的請求回應模式（使用者發送訊息，等待 Agent 回覆），可以先考慮加入最基本的 durabule execution——把 Agent 的 state 序列化存入資料庫，讓它在重啟時能恢復。這不需要任何新的基礎設施，只需要一個資料庫表格和一個 worker 程序。從最簡單的方案開始，等需求明確了再升級到更完整的解決方案。

問題二：Sandbox 冷啟動

Loop 大部分時間是暫停的——在等 LLM 回應、在等外部 API、在等 CI 執行結果。如果 sandbox 也跟著暫停，當 Agent 需要執行指令時再喚醒，可以大幅節省資源。但問題是冷啟動。一個從頭建立 sandbox 的冷啟動需要好幾秒，這在互動式回合中是永恆。

Mendral 用 Blaxel 解決這個問題——25ms 的 resume from standby，快到 Agent 完全感覺不到 sandbox 曾經被暫停過。想像一下你在跟 Agent 對話，你下了一條指令，Agent 決定叫 sandbox 執行某個工具——然後你等了五秒鐘。這種體驗在開發階段或許可以接受，但在生產環境中完全不及格。Mendral 的策略是讓 sandbox 保持一個「熱待命」狀態，隨時可以喚醒。

對多數台灣團隊來說，不一定需要 Blaxel 這樣的專門服務。關鍵是理解這個需求：你的 sandbox 管理方案需要有接近零的喚醒延遲，否則使用者體驗會大打折扣。Docker 的 paused/unpause 或 Kubernetes 的原地升級都是可以思考的方向。

問題三：檔案系統的抽象

這是最棘手的問題。現代 Agent 不只是 bash 和 LLM——它有技能（按需讀取的提示片段）、記憶（Agent 為自己或使用者寫的筆記）、子 Agent、計畫、待辦事項。全部假設本機檔案系統存在。

Mendral 的解法是單一介面、雙重後端。Agent 看到的仍然是一個檔案系統，但實際讀寫操作被路由到不同的後端：技能記憶走資料庫，原始碼檔案走 sandbox。

這裡還有一個值得一提的細節：當 Agent 在 sandbox 中操作原始碼時——比如修改檔案、執行 git push——這些操作確實需要真實的檔案系統，所以它們走 sandbox。但當 Agent 說「記住這個 deployment 的 SOP 是什麼」時，這寫的不是程式碼，而是認知。認知應該共享，不該困在一個臨時容器裡。

「停止假裝」是他們的核心哲學。不要為了維持相容性去建立一個分散式檔案系統，然後處理無盡的衝突和一致性問題。直接換掉後端，讓 harness 用資料庫溝通。

對台灣團隊的啟示：不是所有 Agent 都需要這麼做

看到這裡，你可能覺得「哇，這規格太高了，我們只是一個五人團隊而已」。

這正是關鍵：不是所有 Agent 都需要 outside harness。

如果你是單人開發者，在自己的筆電上用 Claude Code 或 Cursor 寫程式，inside harness 完全夠用。它的簡單就是最大的優點。你不需要擔心多人協作、容器掛掉、credential 洩漏——風險可控，收益沒差。

但以下幾種情況，你應該開始考慮把 harness 搬出來：

結尾

Mendral 團隊的選擇——把 harness 搬出 sandbox——說到底不是什麼炫技的架構設計。它是一個工程團隊在面對真實問題後，一步一步想清楚 tradeoff 後做出的決定。

每次看到這類工程分享，我總覺得最有價值的不是他們的答案，而是他們提出問題的方式。「Agent 的驅動引擎應該放在哪裡？」這個問題，在很多人還在忙著讓 Agent 能跑起來的時候，他們已經在思考讓 Agent 能跑得久、跑得穩、跑得安全。

對於正在搭建 AI Agent 的台灣團隊來說，這或許是最好的提醒：先確認你遇到的問題是什麼，再決定需不需要把發電機搬出去。不需要為了一個五人團隊做 TikTok 的架構。

但如果你發現 Agent 開始頻繁卡死、credential 開始亂竄、團隊開始因為記憶不同步而吵架——或者更關鍵的，你開始覺得「好像哪裡不對勁」但說不上來——那或許是時候重新審視你的架構了。不一定得一次到位。可以先從 credential 分離開始，再慢慢把記憶搬到資料庫，最後再處理 sandbox 生命週期。一步一步來，總比等到出了資安事故再補救好。

Mendral 團隊的分享最可貴的地方，在於他們把一個原本只屬於 infra 團隊的討論，變成了一個每個 Agent 開發者都該關心的問題。畢竟，當你的 Agent 開始處理真實的工作、存取真實的資料、影響真實的使用者時，它的引擎放在哪裡，就不再只是工程師的品味問題了。