Question 1

Sub-agent Pooling 為什麼重要？

Accepted Answer

Sub-agent Pooling 和「每個任務直接建立新的 Sub-agent」相比，具體省下的是哪些成本？是不是所有場景都值得做資源池化？

資源池化省下的成本可以拆成三類,但不是所有場景都值得投入資源做池化,需要衡量池化本身的實作和維護成本,是不是划算。

**節省的成本類型一:連接建立成本**。如果 Sub-agent 需要連接外部服務(例如前面 MCP Server 詞條提到的,連接一個資料庫或 API 服務),每次重新建立這個連接,通常涉及網路握手、身份驗證等步驟,這些步驟本身需要時間(可能是幾十毫秒到幾百毫秒不等),資源池化讓連接只需要建立一次,之後重複使用,省下的是這個重複建立連接的時間。

**節省的成本類型二:設定載入成本**。如果 Sub-agent 初始化時需要載入一些相對龐大的設定或資源(例如載入一份規則清單、一份白名單資料),重新建立實例代表這個載入過程要重複跑,資源池化把這個載入過程也只需要做一次。

**節省的成本類型三:間接的併發控制價值**(前面卡片重點提到的)，這個價值不是直接的時間或金錢節省,而是系統穩定性的提升——即使技術上重新建立 Sub-agent 的成本很低,固定大小的池子依然提供了一個簡單有效的併發上限機制,這個價值在任務量可能突然暴增的場景裡特別重要。

**不值得做資源池化的場景**:如果 Sub-agent 的初始化成本本身很低(例如它只是一個純函式邏輯,不涉及任何外部連接或大量資料載入),資源池化能節省的初始化成本微乎其微,但池化本身的實作(管理借用/歸還邏輯、處理狀態清理)會增加額外的程式碼複雜度,這種情況下,池化的維護成本可能高於它能節省的效能成本,不值得做;如果系統的任務量本身很穩定、很低(例如一天只處理幾十個任務),重新建立 Sub-agent 帶來的效能負擔本身就不顯著,併發控制的價值也不大(因為任務量本來就不會暴增),池化帶來的邊際效益有限。

**判斷是否值得池化的實務訊號**:如果你發現 Sub-agent 的初始化過程本身，佔了整個任務處理時間裡不小的比例（例如初始化要 200 毫秒，而任務本身的核心處理只要 100 毫秒），或者你的系統經常面臨任務量的突發尖峰，這兩個訊號都指向資源池化值得投入實作；如果初始化成本相對整體任務處理時間微不足道，且任務量穩定可預測，池化的投資報酬率通常不高。

Question 2

Sub-agent Pooling 如何運作？

Accepted Answer

文章卡片提到「歸還時的狀態清理」是最容易被忽略的問題，具體來說，一個 Sub-agent 內部有哪些東西需要清理，怎麼確保沒有漏掉？

需要清理的內容,可以按照「這個資訊如果洩漏到下一個任務,傷害有多大」來分類優先順序,而不是漫無目的地想清理所有東西。

**高優先級:任何和使用者身份或機密資料相關的上下文**。如果 Sub-agent 在處理任務 A 時,暫存了使用者 A 的個人資訊、API 金鑰、或任何機密資料在記憶體或內部狀態裡,如果沒有清空就直接借給任務 B 使用,任務 B 可能會意外讀取到使用者 A 的機密資訊(例如 Sub-agent 的推理過程,可能會引用「上一輪對話提到的內容」，如果沒有正確重置對話歷史,舊的機密內容可能被錯誤地帶入新任務的推理脈絡)——這是最需要優先確保清理乾淨的類別,因為錯誤會直接造成資料外洩,對應到資安層級的嚴重問題。

**中優先級:業務邏輯相關的暫存狀態**。例如前面 LangGraph 詞條提到的「查詢次數」「累積成本」這類計數器,如果 Sub-agent 內部有類似的暫存計數,沒有在歸還時重置,下一個任務借用這個 Sub-agent 時,可能會從一個非零的計數開始(而不是應該有的從零開始),導致前面重試策略、Circuit Breaker 討論過的次數上限或成本上限計算出現偏差——這類錯誤不會直接洩漏機密資料,但會讓前面提到的防護機制失效或誤判。

**低優先級,但仍值得注意:快取資料**。如果 Sub-agent 為了效能,暫存了一些查詢結果(例如上一次查詢的市場數據),這類快取如果沒有適當處理,下一個任務可能會不小心用到過期的快取資料,而不是重新查詢即時資料——這呼應了前面滑點容忍度文章討論過的「資料時效性」問題,快取沒清理乾淨,可能導致 Sub-agent 用舊資料做出不合時宜的判斷。

**確保沒有漏掉的具體做法**:與其在每次歸還時手動一項項清理(容易漏掉新加的欄位或狀態),更穩健的做法是,把 Sub-agent 的內部狀態明確定義成一個結構化的物件(呼應前面 Structured Output 的思路),歸還池子時,不是「清理已知欄位」,而是「直接把整個狀態物件重設成一個全新的、預先定義好的初始狀態」,這樣即使之後新增了某個欄位,只要它是這個狀態物件的一部分,重設邏輯就會自動涵蓋到它,不需要每次新增欄位都手動去補一行清理邏輯,大幅降低「忘記清理某個欄位」這種疏漏發生的機率。

Question 3

Sub-agent Pooling 如何實際應用？

Accepted Answer

如果任務到達的速度突然遠超池子的大小，所有 Sub-agent 都被借用完，這時候新任務該怎麼處理？直接拒絕嗎？

直接拒絕是一種選項,但不是唯一選項,實務上有幾種常見的處理策略,選哪一種取決於任務本身的性質(能不能等、有沒有時效性)。

**策略一:排隊等待**。如果任務不是特別緊急、可以稍微延遲處理也不影響最終結果,新任務可以進入一個等待佇列,等到有 Sub-agent 被歸還、變成空閒狀態時,依序處理佇列裡等待的任務。這個策略的關鍵設計是要有一個合理的等待逾時機制——如果佇列裡的任務等待超過某個時間門檻,還沒輪到它被處理,應該主動放棄排隊、回報「系統目前負載過高,請稍後再試」,而不是讓任務無限期地卡在佇列裡等待,這呼應了前面重試策略文章討論過的「不是每次失敗都要無限想辦法解決」的降級思路。

**策略二:直接拒絕,回報明確的過載狀態**。如果任務本身有很強的時效性(例如前面滑點容忍度文章討論過的,市場數據隨時可能過期,排隊等待可能導致任務完成時,市場條件已經完全不同),排隊等待反而可能造成更大的問題(用過時的資料執行了一個已經不再合理的操作),這種情況下,直接拒絕新任務、明確回報「目前資源已滿,請稍後重試」,反而是更安全的做法,把「要不要延遲重試」的決策權交還給呼叫方,而不是系統自己決定要排隊多久。

**策略三:動態擴充池子大小(彈性池化)**。如果底層資源(例如 API 額度、運算資源)允許,系統可以設計成在偵測到池子持續滿載時,動態建立額外的臨時 Sub-agent 實例來應付當下的尖峰負載,等尖峰過去、任務量降回正常水準後,再把多餘的臨時實例釋放掉,回到原本的池子大小。這個策略能提供更好的彈性,但實作複雜度也更高,而且要注意「動態擴充」本身,不能完全沒有上限(否則又回到了前面 Circuit Breaker 詞條討論過的、沒有上限的資源消耗風險),通常會設定一個「最大擴充倍數」，避免無限擴充。

**選擇哪種策略的判斷依據**:核心問題是「這個任務,排隊等待造成的傷害,和直接拒絕造成的傷害,哪個更大」——如果排隊等待本身不會讓任務的結果變差(任務不涉及時效性敏感的判斷),排隊通常是使用者體驗較好的選項;如果排隊等待可能讓任務用過時資料做出不恰當決策(尤其是涉及金錢操作的任務),直接拒絕、把決策權交還使用者,通常是更安全的選項。這個判斷,應該根據任務類型分別設定策略,而不是整個系統只用單一策略處理所有任務。