代理人作為工具

上一頁展示了上下文提供者如何為代理提供記憶體和動態知識——這些資訊會在每次呼叫前主動注入。 此時，你 只有一個代理 能使用工具、載入技能、運行中介軟體，並利用豐富的上下文。 這很強大，但仍然是同一個人在做所有事情。

當你的代理人的責任超出單一指示所能處理的範圍時，會發生什麼事？ 隨著代理人累積工具， 工具選擇會逐漸退化 ——模型更擅長從少數描述良好的工具中挑選，而非在數十種中篩選。 隨著指令範圍擴大， 焦點逐漸下降 ——一個試圖涵蓋旅遊預訂、費用報告和行事曆管理的系統提示，讓模型角色過多難以同時處理。

代理作為工具解決了這個問題，讓你可以組合代理：一個代理（外部代理）可以呼叫另一個代理（內部代理），就像呼叫一般函數工具一樣。 每個內在代理人都有明確的範圍——有自己的指示、工具和專長。 外部代理人決定何時委派、要求什麼——就像決定何時呼叫其他工具一樣。

何時使用

當以下情況使用代理人作為工具：

  • 你想將 專門的子任務委派 給專注的客服人員——例如，當使用者詢問航班時，會打電話給專屬的「旅遊訂位代理人」的一般助理。
  • 外部代理人應根據對話決定 何時及是否 讓內層代理人參與——委派是以模型驅動，而非硬編碼。
  • 你不需要明確控制代理人之間的執行順序 ——外部代理人透過自身的推理安排事情，你可以接受這樣的安排。

小提示

每位代理人也可依其專業化與需求使用不同型號。 較複雜的代理人可能會使用較大的模型來推理，而較簡單的代理人則可能使用較小且較快速的模型以提高效率。

考慮事項

考量事項 詳細資料
簡單 最輕量的多代理模式是代理即工具。 你將一個代理人轉換成工具，然後交給另一個代理人。 當一個代理人不夠時，這是自然的下一步。
Latency 每個委派都是完整的代理調用：外部代理調用內部代理，進而調用LLM，而LLM則可能調用其自身的工具。 巢狀召喚累積起來。 讓內在代理人保持專注，讓他們能快速解決問題。
路由是模型驅動的 外部代理的大型語言模型決定何時呼叫內代理，就像它決定何時呼叫任何工具一樣。 這表示路由可能難以預測——如果工具描述模糊，模型可能會呼叫錯誤的代理或完全跳過。 清晰且具體的描述至關重要。
能見度有限 外在代理人看到的是內在代理人的最終文本回應——它看不到內在代理人的中間推理、工具呼叫或上下文。 如果你需要觀察內在代理行為，就用 追蹤。
情境隔離 內部代理器以自己的指令和工具運行。 它不會自動繼承外部代理人的對話歷史或上下文。 你透過工具呼叫參數與它溝通，就像其他函式工具一樣。

運作方式

代理作為工具是在你已經知道的工具 調用循環 上建立起來的。 唯一的差別是，被呼叫的「函數」本身就是一個代理人。

┌──────────────────────────────────────────────────────────┐
│  User: "Book me a flight to Paris and file the expense"  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent reasons about the request                   │
│  → decides to call the travel-booking agent first        │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (travel-booking) runs as a tool:            │
│  • receives: "Book a flight to Paris"                    │
│  • uses its own tools (search_flights, book_flight)      │
│  • returns: "Booked Flight AF123, $450"                  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent receives the tool result                    │
│  → decides to call the expense-filing agent next         │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (expense-filing) runs as a tool:            │
│  • receives: "File expense for Flight AF123, $450"       │
│  • uses its own tools (create_expense, attach_receipt)   │
│  • returns: "Expense report filed"                       │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent synthesizes both results:                   │
│  "Done! Booked Flight AF123 to Paris for $450 and filed  │
│   expense report."                                       │
└──────────────────────────────────────────────────────────┘

關鍵點：

  1. 內部代理看起來像是一個函數工具。 從外在代理人的角度來看，呼叫內在代理人與呼叫 get_weather() 或 search_database()並無不同。 框架負責將代理轉換成帶有名稱、描述和輸入參數的工具。
  2. 內在代理人獨立運作。 它有自己的指令、工具和大型語言模型（LLM）呼叫。 它不會看到外部代理的完整對話——只看到透過工具呼叫傳遞的輸入。
  3. 外部代理人只看到最終結果。 內在代理人的中間步驟（工具呼叫、推理、重試）對外代理來說是看不見的。 它會收到文字回應，就像任何工具的結果一樣。

下一步

現在你可以在單一流程中組合代理，下一步是代理 對代理（Agent-to-Agent，A2A） ——讓代理能利用標準協定跨越服務與組織邊界進行通訊。

代理對代理（A2A）

深入探討：

  • Last updated on