AI Agent 的隱形圍牆：為何模型再聰明，也跨不過執行環境的邊界？

在開發 AI Agent 時，我們常將失敗歸咎於模型智能不足或指令不夠清晰。然而，真正的癥結點往往深藏於執行環境的邊界。許多 Agent 的不穩定，源於開發者將命令列（CLI）、本機、隔離虛擬機（VM）或遠端沙盒等截然不同的 runtime 視為同一個世界。這種假設性的對稱，會導致權限、檔案路徑與環境副作用的預期全面失效。我認為，穩固的 Agent 系統設計，必須先承認這些邊界，並針對每一層限制設計工具與能力，而非期望模型能神奇地「跨越」它們。

Claude Code Plugin：為何一個插件，卻有兩種執行模式的落差？

最近，日本 StoreHero 公司 CPO 永田（Nagata）先生分享的一個技術案例，完美印證了這個觀點。他們在開發 Anthropic Claude 的 Code Plugin 時，發現一個插件在兩種不同模式下的行為截然不同。這兩種模式分別是：

• CLI 模式：直接在開發者的終端機環境中執行，擁有與使用者幾乎相同的權限與檔案系統視圖。
• Cowork 模式：整合在 Claude Desktop 應用程式（macOS / Windows）中的 agentic 執行模式。在此模式下，所有程式碼都在一個本地端的 Linux VM 沙盒中執行，與主機作業系統（Host OS）完全隔離。

表面上，這只是執行位置的差異，但對 Agent 而言，這代表著兩個完全不同的「物理世界」。在 CLI 模式下，Agent 可以輕易讀寫 ~/Documents 下的檔案、呼叫系統已安裝的工具；但在 Cowork 模式中，它的世界僅限於那個短暫存在、與世隔絕的 VM。任何試圖存取主機檔案系統的指令，例如 fs.readFileSync('/Users/maki/Desktop/report.txt')，都會因為路徑不存在而失敗。Agent 看不見 VM 之外的世界，也無法觸及。

為什麼執行環境的「不對稱」是致命傷？

這種執行環境的不對稱性，是導致許多 Agent 在「從開發到部署」過程中頻繁失效的核心原因。問題不僅僅是檔案路徑，而是三大基本假設的崩潰：

1. 權限假設（Permission Assumption）：Agent 在開發環境（如本地 CLI）中可能擁有 root 或使用者等級的權限，可以安裝套件、修改設定檔。但在沙盒化的生產環境中，它可能只是一個無法寫入檔案系統、無法建立網路連線的低權限使用者。這種權限降級，會讓許多依賴環境設定或外部資源的工具直接癱瘓。
2. 狀態假設（State Assumption）：開發時，Agent 執行的環境是持續存在的。安裝的函式庫、建立的暫存檔都會保留下來。然而，許多沙盒環境（例如 OpenAI 的 Advanced Data Analysis）是短生命週期的（ephemeral），每次執行都是一個全新的、乾淨的開始。依賴前次執行所留下狀態的任務鏈，自然會中斷。
3. 副作用假設（Side Effect Assumption）：在本地執行時，一個腳本產生的檔案或啟動的服務，會直接影響主機環境。但在 VM 或容器中，這些副作用被侷限在圍牆之內。如果後續步驟需要在主機上驗證這些副作用（例如，檢查某個檔案是否成功建立），就會得到錯誤的結果。

這種不對稱性，與傳統軟體開發中的「環境變數」或「設定檔」問題有本質上的不同。對傳統軟體而言，環境是可預測的被動背景；但對 AI Agent 而言，環境是它感知與互動的「世界模型」的一部分。當這個世界模型與現實脫節，Agent 的決策鏈就會崩潰，這不是靠更強的 LLM 推理能力就能解決的。這種環境邊界的模糊，不僅影響功能，更可能帶來嚴重的安全隱患。有研究指出，若缺乏嚴格的環境控制，LLM Agent 甚至能自主利用一日漏洞（one-day vulnerabilities），凸顯了執行環境治理的重要性。

許多研究已經指出，確保大型語言模型工具使用的安全性與可靠性，關鍵在於嚴格的環境控制與隔離。如 Google Research 的一篇論文所討論的，必須將不可信的程式碼置於沙盒中執行，以限制其潛在危害。

如何打造真正穩固的 Agent？從承認邊界開始

既然無法消除邊界，那我們就必須擁抱它。一個更穩健的 Agent 架構設計，應該從一開始就將執行邊界視為核心設計元素，而非事後的部署細節。這意味著我們需要重新思考工具（Tool）的設計哲學。

與其給予 Agent 一個看起來無所不能、但實際上卻充滿隱形圍牆的「通用 shell」，不如為它設計一系列「跨邊界」的原子能力（atomic capabilities）。這些能力在設計上就已經內建了對環境邊界的認知，讓 Agent 能在不同「世界」間安全、有效地運作。例如：

• 明確的檔案 I/O 工具：不要讓 Agent 直接操作檔案系統，而是提供如 upload_file_to_sandbox(local_path) 或 download_file_from_sandbox(sandbox_path) 這類明確的工具。這讓 Agent 知道檔案需要在不同「世界」之間傳遞。
• 狀態管理 API：如果 Agent 需要跨任務儲存狀態，應提供一個外部的、持久化的 key-value store API，而不是讓它假設檔案系統是持久的。
• 環境自省能力（Introspection）：賦予 Agent 一個能查詢自身執行環境限制的工具，例如 get_environment_info()，讓它能知道自己「身在何處」，有哪些權限，網路是否可達。這有助於它在規劃階段就避開不可行的路徑，而不是等到執行時才發現失敗。

這種設計理念，本質上是從「授權 Agent 自由探索」轉向「賦予 Agent 可靠的、邊界感知的能力」。這不僅提升了系統的穩定性與安全性，也讓 Agent 的行為變得更可預測、更易於除錯。正如Anthropic 在其工具使用文件中所強調的，清晰、結構化的工具定義是引導模型產生可靠行為的關鍵。

從 Claude Code Plugin 的案例中，我們學到的不只是一個技術上的踩坑紀錄。它揭示了一個更深層的議題：在建構日益複雜的 AI Agent 系統時，我們必須成為優秀的「世界設計師」。我們不僅要定義 Agent 的能力，更要清晰地劃定它所在世界的邊界與物理法則。唯有當 Agent 的內在世界模型與外部執行環境的現實達成一致時，我們才能建立真正可信任、可依賴的自主系統。

延伸閱讀

• ハーネスエンジニアなら知っておきたい Claude Code Plugin の落とし穴（Cowork 編）：本文參考的原始技術分析文章。
• Anthropic Developer Docs: Tool Use：Claude 官方關於工具使用的最佳實踐文件。
• OpenAI: Advanced data analysis：了解 OpenAI 如何透過沙盒環境來執行程式碼，是另一個重要的參考案例。
• arXiv: LLM Agents can Autonomously Exploit One-day Vulnerabilities：一篇探討 LLM Agent 安全性與自主漏洞利用的研究，凸顯了執行環境治理的重要性。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。