工具與子代理：構建有效AI代理而不過度工程化

在構建AI代理時，每個開發者最終都會面臨一個決策點：某個功能應該實現為工具還是子代理？選擇錯誤會導致代理臃腫或過度複雜。本文詳細解釋兩者的區別、適用場景以及如何做出正確選擇。

工具是代理與外部系統交互的能力，通常表現為函數、API調用、數據庫查詢等確定性操作。代理調用工具時，工具本身不進行推理，只執行預定義操作並返回結果。工具的優點是快速、確定且成本低。子代理則是一個獨立的LLM調用，擁有自己的系統提示、上下文窗口和工具集。它接收任務後獨立進行多步推理，返回結果給編排代理。子代理的優點是上下文隔離、能夠處理複雜推理任務，但代價是更高的延遲和成本。

關鍵區別在於：工具執行代碼，子代理執行推理。工具與編排代理共享上下文窗口，而子代理擁有獨立的上下文。子代理的推理循環完整，但編排代理只能看到最終結果。工具錯誤處理通常是結構化返回和重試，子代理的錯誤可能內部處理或上報。成本方面，工具只有執行成本，子代理需要額外LLM調用。延遲上，工具低，子代理高。

何時使用工具？當操作定義明確、行為確定且不需要多步推理時。例如API調用、數據驗證、文件讀寫、搜索等。如果可以用Python函數實現，且不需要多步推理，就應該用工具。

何時使用子代理？當任務需要多步推理、中間工作會對編排代理上下文造成噪音、或任務可並行執行時。例如研究競爭格局（需要多步搜索和綜合）、並行處理多個文檔、需要專用工具集的任務。上下文隔離還能提高可靠性，子代理在工作時不會被編排代理的累積歷史干擾。

決策框架基於三個問題：1. 任務是執行還是推理？2. 中間工作對編排代理是否重要？3. 任務能否獨立運行？工具適合執行，子代理適合推理。如果結果小且直接有用，用工具；如果產生大量中間結果，用子代理。如果任務可獨立或並行運行，子代理更合適。

常見陷阱是過早引入子代理。好的實踐是先從單一代理和少量工具開始，只有在工具無法簡潔解決問題時才引入子代理。回顧問題：“子代理真正給我帶來了什麼？”如果只是少量處理，工具足夠；如果需要獨立推理、上下文隔離、專門能力或並行執行，子代理才合理。

引入子代理的實際成本包括：編排代理必須明確定義任務，子代理不會自動繼承編排代理的上下文。需要清晰的交接：發送聚焦的任務，子代理獨立推理並使用工具，返回簡潔的結果。例如研究子代理可能返回“確定了三個競爭對手以及它們的定價模型和關鍵差異化因素”，而不是每個搜索查詢和中間觀察。保持邊界清晰能防止編排代理上下文被中間工作填滿，並使系統更易理解和調試。一個有用的原則是：將任務向下傳遞，將結論向上傳遞。