別等官方功能了：自建代理層才是決定 AI Agent 系統天花板的關鍵
AI Agent 系統的天花板，往往不由官方功能列表決定，而取決於你是否願意補出自己的代理層與協調層。本文從產品與系統整合角度出發，說明為什麼 orchestration proxy 才是掌握 session、觀測性與擴展能力的關鍵。
許多人評估 AI Agent 平台時，習慣聚焦於官方功能列表，但這往往會錯估系統的真實潛力。一個 agent 系統的真正天花板，其實不在於平台「給了」你什麼，而在於你是否敢於在它之上，建立一層自己的代理與協調層（Orchestration Proxy）。這個看似額外的工序，卻是掌握 session 管理、系統觀測性與功能擴展性的關鍵。從產品與系統整合的角度來看，與其被動等待原廠的 roadmap，不如主動自建這層中介，這才是決定你最終應用能否落地的核心。
為什麼官方工具鏈時常不夠用？
以 Anthropic 的 Claude Tools (Code Interpreter) 為例，它提供了強大的程式碼執行環境，但其官方 CLI 工具的設計，主要是為單一、互動式的任務服務。當我們試圖建構更複雜的多 Agent 協作系統時，很快就會碰到天花板。例如，在一個需要多個 Claude Code 實例分工合作的場景中，官方工具的限制就暴露無遺：
- Session 與 Process 強綁定： 每個 agent 的 session 狀態直接與作業系統的程序 ID (PID) 綁定。這意味著一旦某個程序因故崩潰或結束，整個對話歷史與工作狀態就會遺失，無法輕易恢復。這對於需要長時間運行的任務是致命的。
- 缺乏內建觀測性： 在一個 session 進行中，我們很難從外部得知 agent 的內部狀態，例如剩餘的 token 數量。尤其在處理像 Claude 3 Opus 這種擁有 200K context window 的模型時，精準的 token 管理是控制成本與避免錯誤的關鍵，但官方工具並未提供即時的監控介面。
- 功能擴展性受限： 如果我們想在 agent 執行過程中注入一些自訂邏輯，例如定期心跳檢查、超時自動終止（如執行超過 300 秒）、或是在特定條件下觸發外部通知，官方工具幾乎沒有提供這樣的掛鉤（hooks）。
這些限制並非平台本身的缺陷，而是其設計哲學所致——它們提供的是一個「工具」，而非一個「可維運的系統」。當我們的需求從「單一任務執行」演進到「多任務協調系統」時，就必須自己動手補上缺失的環節。
自建代理層，如何成為系統觀測、管理與擴展的樞紐？
解決上述問題最有效、也最靈活的方法，就是在我們的應用程式與 AI Agent 平台之間，建立一個自訂的代理伺服器（Proxy Server）。這個代理層讓我們能攔截、分析甚至改寫兩者之間的通訊，從而獲得近乎無限的控制力。日本開發者 hummer 在他打造多 agent 協調系統的實踐中，便深刻體會到這一點。
具體來說，透過設定環境變數（如 Anthropic 的 ANTHROPIC_BASE_URL 或 OpenAI 的 OPENAI_BASE_URL）將所有 API 請求導向我們的代理伺服器，我們可以輕易實現以下目標：
- 實現精準的狀態觀測： 代理層可以解析 API 的回應，從中提取出官方 SDK 不會直接暴露的資訊。例如，透過攔截回應，我們可以計算出每次呼叫後剩餘的 token 數量，並將其記錄到監控系統中，實現對 token 耗損的即時觀測。
- 解耦 Session 與 Process： 我們可以在代理層實作自己的 session 管理機制。為每個 agent 任務分配一個獨一無二的 session ID，並由代理層負責維護 session ID 與底層 Claude Code 程序之間的對應關係。如此一來，即使某個程序崩潰，我們也能夠透過 session ID 重新啟動一個新程序並恢復先前狀態，大幅提升系統的容錯能力。
- 動態注入自訂功能： 代理層給了我們在不修改 agent 核心邏輯的情況下，注入新功能的能力。例如，我們可以設計一個特殊的指令，當 agent 在回應中包含這個指令時，代理層就攔截它並執行對應的動作，像是「儲存當前工作成果並自我終止」，或是向監控系統發送心跳訊號。
這種模式的轉變，是從一個單純的「API 消費者」轉變為一個「系統整合者」。你不再只是使用工具，而是在圍繞工具建構一個更強大的、符合自身業務邏輯的系統。
何時應該考慮自建代理層？
並非所有專案都需要這樣的複雜度。但當你的 AI agent 系統出現以下任何一種情況時，就應該認真考慮自建代理層的價值：
| 情境 | 自建代理層的價值 |
|---|---|
| 多 Agent 協作 | 集中管理多個 agent 的狀態、通訊與生命週期。 |
| 長時程任務 | 提供 session 持久化與故障恢復能力，確保任務不中斷。 |
| 對成本與效能敏感 | 精準監控 token 消耗與 API 延遲，進行細緻優化。 |
| 需要與既有系統深度整合 | 作為轉接器，注入自訂的認證、日誌、監控等邏輯。 |
建構這樣的代理層，並不像聽起來那麼遙不可及。你可以使用輕量的 Web 框架（如 Python 的 FastAPI 或 Node.js 的 Express）快速搭建，或是利用現成的反向代理工具（如 mitmproxy）進行原型開發。
其核心價值在於，它將系統的控制權從平台供應商手中，拿回了我們自己手裡。這與學術界在探討大型語言模型自主代理（Autonomous Agents）時，強調的「控制」與「協調」架構不謀而合。
總結來說，當我們在建構複雜的 AI Agent 系統時，真正的瓶頸往往不是模型的能力，而是我們對系統行為的控制力。與其等待平台釋出我們需要的功能，不如主動透過自建代理層來突破限制。這不僅能解決眼前的技術難題，更是打造一個穩健、可擴展、可觀測 AI 應用的策略性投資。這層看似「多餘」的抽象，最終會成為你系統中最有價值的部分。
延伸閱讀
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。