超越平行化：為何子代理（Subagent）是 AI 開發中不可或缺的上下文治理模式
在大型專案中，AI 代理的上下文視窗常被瑣碎的調查過程佔滿，導致核心任務效能下降。本文探討如何利用子代理（Subagent）設計模式，將探索與雜訊隔離在獨立的「邊界上下文」中，確保主決策流程的乾淨與可控，這不只是為了加速，更是為了建立可持續、可治理的 AI 協作系統。
在與大型語言模型協作開發時，真正的瓶頸往往不是模型的推理速度，而是上下文視窗的管理。當調查、搜尋、試錯等探索性任務的雜訊不斷湧入主對話，將迅速污染上下文，導致模型決策品質下降。本文將論證，子代理（Subagent）的核心價值，並非僅是平行化帶來的效率提升，而是一種關鍵的「上下文治理」（Context Governance）設計模式。透過將探索過程隔離在獨立的邊界內，我們能確保主決策鏈的乾淨、可控與可延續，這對建立長期、可信任的 AI 協作系統至關重要。
為什麼大型專案總讓 AI 代理的上下文不堪重負？
近期，日本開發者 Eris 分享了一個極具代表性的場景：在使用像 Claude 這樣的程式碼專用模型分析一個大型程式庫時，他習慣在主對話視窗中依序下達 Grep 和 Read 指令來追蹤程式碼。這個過程看似直觀，卻隱藏著巨大的成本。大約 15 分鐘的調查後，主對話的上下文（Context）就已經被大量的程式碼片段、檔案路徑和搜尋結果填滿。
當他試圖基於這些混亂的資訊，開始進行真正的實作或重構任務時，模型的反應速度明顯變慢，回應品質也隨之下降。這就是所謂的「上下文污染」（Context Pollution）。即使是擁有 Claude 3.5 Sonnet 的 200K token 或 Gemini 1.5 Pro 的 1M token 這樣巨大的上下文視窗，問題依然存在。研究如 《Lost in the Middle》 所示，模型在處理長上下文時，容易忽略中間部分的資訊。因此，問題的本質不在於容量，而在於治理——我們如何主動管理湧入上下文的資訊品質與密度。
在一個複雜的開發任務中，充斥上下文的往往是探索過程中的「雜訊」，例如：
- 失敗的搜尋嘗試
- 不相關的程式碼片段
- 已過時的函式定義
- 冗長的日誌或錯誤訊息
這些雜訊稀釋了真正重要的「信號」，讓模型難以專注於核心決策，最終導致整個協作流程變得昂貴且低效。
如何利用子代理實現上下文治理？
為了解決這個問題，Eris 採用了模型的 Agent 工具功能，也就是我們常說的「子代理」（Subagent）。他將原本需要 20 分鐘的手動、循序調查，改寫成數個可以並行處理的子任務，並交由子代理執行。最終，整個調查時間被壓縮到僅僅 3 分鐘。這 85% 的時間縮短固然驚人，但其背後更深層的價值，在於它實現了一種優雅的「上下文隔離」。
子代理真正的價值，是將「探索的過程」與「決策的依據」分離。主代理的上下文應該只保留後者，前者則被封裝在短暫、一次性的子代理執行緒中。
這個概念類似於軟體架構中的領域驅動設計（Domain-Driven Design）的「邊界上下文」（Bounded Context）。每個子代理都在自己的沙盒環境中運作，擁有獨立、短暫的上下文。它們負責執行具體的、探索性的任務——例如在整個程式庫中搜尋特定 API 的所有用法，或驗證某個重構方案的可行性。在這個過程中產生的大量程式碼、中間結果與失敗路徑，都被限制在子代理的邊界內。
當子代理完成任務後，它不會將混亂的過程全盤托出，而是提煉出最關鍵的結論——可能是幾個關鍵檔案的路徑、一段精簡的程式碼範例，或是一個「此路不通」的明確回覆——然後才回報給主代理。如此一來，主代理的上下文就能保持極度乾淨，只包含用於高階決策的、經過預處理的資訊。主決策鏈因此變得清晰、可控，且易於追溯與延續。
何時該引入子代理設計模式？
將子代理視為一種設計模式，意味著我們需要有意識地在特定情境下應用它。它並非萬靈丹，但在以下幾種情況下，它能發揮極大的作用：
1. 廣泛的程式碼或文件調查： 當任務需要從多個檔案、模組甚至外部文件中收集資訊時，可以為每個調查目標指派一個子代理。例如，一個子代理負責掃描後端程式碼，另一個負責查詢前端 API 文件，主代理則等待它們的綜合報告。
2. 多路徑方案的假設與驗證： 當解決一個問題存在多種可能的方案時，與其在主對話中逐一嘗試，不如讓每個方案成為一個子代理的任務。它們可以並行測試，只有成功或最有前景的方案結果會被回傳。這在演算法優化、錯誤修復等場景中尤其有效。
3. 外部工具或 API 的整合： 任何需要與外部系統互動的任務，都適合封裝在子代理中。這不僅能隔離上下文，還能將與特定工具互動的邏輯（如認證、錯誤處理）與主決策邏輯解耦。
我們可以簡單比較兩種工作流程的差異：
| 傳統單一對話模型 | 子代理設計模式 | |
|---|---|---|
| 上下文狀態 | 混亂、充滿雜訊，信噪比低 | 乾淨、專注於決策，信噪比高 |
| 流程效率 | 循序執行，耗時長 | 可並行化，效率高 |
| 可治理性 | 難以追溯，容易偏離主題 | 決策鏈清晰，任務邊界明確 |
諸如 LangChain Agents 或 Microsoft AutoGen 這類框架，已經為實現這種多代理協作提供了成熟的工具。它們讓我們不僅能定義工具，更能設計代理之間的溝通協定與工作流程，將上下文治理從一個被動的補救措施，提升為主動的架構設計。
總結來說，將子代理僅僅看作是提升效率的技巧，是低估了它的潛力。它是一種強大的上下文治理模式，讓我們能將 AI 協作中的混亂與秩序、探索與決策進行有效分離。對於任何致力於打造複雜、長期、可信任 AI 系統的開發者而言，掌握這種設計思維，將是提升人機協作天花板的關鍵一步。
延伸閱讀
- Liu, N. F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." arXiv.
- Anthropic's Documentation on Tool Use
- Microsoft AutoGen Official Documentation
- Martin Fowler on Bounded Context
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。