別再給你的代理工具了，給它一個沙箱——Arize AI 的 Mikyo King

Arize AI 開源團隊負責人 Mikyo King 主張，與其塞給代理（agent）一份龐大的工具清單，不如給它一個沙箱，讓它自行撰寫並執行程式碼來呼叫這些工具——他把這種架構稱為 Code Mode（程式碼模式）。他回報，將 Arize 自家代理改用此做法後，Token 用量減少 43%、成本降低 31%，延遲則大致持平。整場演講大多為實務工作者現身說法，說明這次遷移的打造與衡量方式：Arize 新增了哪些執行介面（Bash、Python 沙箱、CRUD 端點、SQL、瀏覽器端 worker），以及生成程式碼所帶來的營運成本——沙箱資源、網路、機密、許可權、除錯與耐久性。標題的定調相當公允；沙箱確實是全場的主軸，但演講在評估框架上的時間並不亞於架構本身，而此框架正是用來證明效益的。

King 以第一手經驗說明：他的團隊打造了此代理，並在 Arize Phoenix（公司開源可觀測性平臺）中執行，再用一套名為 Harbor 的內部框架測試——它讓代理在斷網的沙箱中執行，並以通過／不通過為每項任務評分。讀者閱讀後應能帶走具體的前後對比數字、Code Mode 能減少上下文膨脹的具體原因，以及一份不粉飾的失敗模式清單——包括 King 坦言至今仍未解決的那些。

Code Mode 用程式環境取代工具選單

核心論點是：傳統的工具呼叫型代理每呼叫一次工具，就在上下文視窗（context window）中累積負載，導致延遲與成本上升，使用者要等到有價值結果的回合數也跟著拉長。Code Mode 用兩項能力取代工具選單：代理可搜尋特定工具，也可在程式環境中執行工具。由於此環境即為程式碼，代理能一次呼叫多個工具、依序或並行執行、加上條件判斷來控制流程，並且只將模型真正需要的那一小段輸出送回上下文視窗。

King 把這件事放進軟體發展 30 年的脈絡來看。為工程師寫的軟體（一支 50 行指令碼，從信箱抓出帳單與附件），對比為非工程師寫的軟體（受制於採購來的介面，只能手動上傳）。他說，寫程式的代理打破了這條界線，因為使用者需要什麼，代理就能即時打造出來——而基礎模型實驗室正是透過 SWE-bench 這類基準測試，朝這個方向訓練模型。

他提出 Code Mode 奏效的四個理由：

Arize 的實作：從 Bash 到瀏覽器，五種執行介面

Arize 從 Bash 起步。King 稱它是絕佳工具，因為它把 sed、grep 這類 Linux 基本工具與公司自家的 CLI 結合在一起，還能將結果輸出成檔案供後續使用。團隊接著加入 Python 沙箱，並把其餘所有 CRUD 端點——取得追蹤資料、操作資料集——一併遷程序式環境，統一了建立／讀取／更新／刪除等操作。再來是 SQL，因為並非所有需求都符合 CRUD 的形狀：像「告訴我 X、Y、Z 所有 LLM 的延遲範圍與 P95 延遲」這類彙總查詢，需要模型直接查詢，而不是逐筆翻遍每一條追蹤紀錄。

最特別的介面是前端。Arize 把一套程式設計範式放進 web worker，與瀏覽器做雙向資料繫結，讓代理能變更時間範圍、從前端資料儲存區讀取，並執行複雜的 UI 互動。King 形容這像是靠湧現行為「免費得到一臺電腦」，還說看著代理自行準備的過程，實在很有意思。

實測結果：Token 少 43%、成本低 31%

Arize 用 Harbor 評估這次遷移。這套內部框架會把代理放進斷網的沙箱環境，每項任務重複執行多次（以試驗版本進行）以濾除不穩定因素，再由 Harbor 的驗證器以 1 或 0 為結果評分。King 把這套做法連結到強化學習（RL）框架，並說多次試驗之所以重要，是因為系統本身不具決定性——每次執行的軌跡都不一樣——所以團隊會針對每項預期完成的任務，追蹤其在第 K 次試驗時的完成率。

King 提出的前後對比：

他說，這些效益在受測的各個介面上都成立——Claude Code、MCP 與 CLI 皆然。評估資料也會回饋到改進流程：當新實作的工具反而拉低成效時，團隊能告訴寫程式的代理，它的指令中哪些部分在特定情境下把它帶偏了，進而拉高分數。

生成程式碼帶來安全與營運負債

King 講得很明白，Code Mode「顯然不是免費的」。他列舉的風險包括：

• 資源——託管沙箱需要管理 CPU、記憶體，以及沙箱存活多久。
• 網路——代理可能需要上網，但你永遠不知道它會在那裡做什麼，因此對外流量（egress）必須嚴加控管。
• 機密——每家沙箱供應商的儲存策略都不同；King 提到在沙箱內執行類似耐久執行引擎（durable execution engine）的東西（他引用近期一個「durable」版本）來快速做決策，但堅持機密絕不能迴流到上下文視窗。
• 許可權——通常給得太寬。前五個操作可能許可權範圍都設對了，第六個卻沒有；或者組合能力可能整個繞過許可權模型。
• 營運複雜度——沙箱不見得每次都能乾淨載入，失敗必須處理；除錯變成在除錯程式碼，而不是除錯個別工具；工具引數的準確度變成更大的問題，因為引數現在是程式碼；工具探索還需要一次模型以前不必做的握手（handshake）。
• 雙重沙箱——沙箱回傳的是序列化 JSON，必須解析後再轉譯進另一層 code mode，形成雙重執行。

未解難題：耐久性、數學、二進位檔與小模型

King 列出的開放問題，他說看起來比較像摩擦，而非阻礙。最棘手的是耐久性：一大段生成的程式碼若中途出錯，無法從失敗的那一步接續執行。決定性與數學能力可能促使團隊重新考慮語言選擇——JavaScript 是 LLM 非常擅長、但數學很不擅長的語言。多模態工作也很彆扭，因為你不會想把整張圖片或二進位檔序列化進上下文視窗；他提到的變通做法之一是簽章式圖片傳輸。此外，能力不會向下滲透到低階市場：前沿模型在 Code Mode 中表現極佳，但為了省錢而選用的小模型，可能根本扛不住。

「我們真的很喜歡這種編碼模式，因為在我們看來，這個模式產生的輸出比較少。我們希望你能提供任何模型給我們用。所以我們要它更便宜，而我們的代理能展現的湧現行為與長期任務，讓我們非常興奮。」

評估框架為何與架構同等重要

King 的結語是：同時捕捉軌跡與評估結果，就等於給你一個環境，可以觀察代理行為並加以指導。Arize 就是這樣抓到新工具反而拖累效能的情況，也是這樣靠修正指令拉高分數。他的結論是：給你的代理一個沙箱，然後用評估工具檢查它在裡面做了什麼。

尚未化解的張力在於：這些亮眼數字來自 Arize 自家的框架、測試 Arize 自家的代理，而 King 自己也指出非決定性、軌跡多變與不穩定性。43%／31% 的效益能否推廣到其他工具清單、其他模型或更小的模型，正是這場演講留下的問題——也是當 Code Mode 從內部框架走進 MCP 與基礎模型供應商本身時，值得持續關注的關鍵。