代理式RAG：如何建構一個AI代理自動發現並呼叫的檢索工具

大多數RAG實作都是硬編碼在應用程式碼中的。使用者提出問題，應用程式拆分查詢，搜尋向量資料庫，組裝上下文，然後將所有內容傳遞給語言模型。檢索邏輯直接嵌入在編排層中，與單一工作流程緊密耦合。

這在你引入AI代理之前一直有效。

代理的運作方式不同。它們接收一個目標，推理應該使用哪些工具，然後動態呼叫這些工具。代理不遵循固定的管線。它透過工具呼叫規格發現可用功能，決定何時需要檢索，並像呼叫任何其他函式一樣呼叫它。如果你的RAG管線埋藏在應用程式碼中，代理就無法找到它，無法呼叫它，也無法推理何時檢索會有幫助。

從嵌入式檢索到代理式RAG的轉變不是一次小型重構。它是AI系統知識存取架構方式的根本性變化。

什麼使RAG成為「代理式」的

傳統RAG是一個管線：查詢進入，上下文輸出，模型產生回應。應用程式控制每一步。模型對檢索是否發生、檢索什麼、或管線執行多少次沒有發言權。

代理式RAG管線反轉了這種控制。檢索管線變成了代理可以按自己的條件發現和呼叫的工具。代理決定：

• 是否檢索（某些查詢不需要外部知識）
• 搜尋什麼（代理制定自己的檢索查詢）
• 何時再次檢索（如果第一個結果不充分，代理可以用最佳化後的查詢第二次呼叫該工具）
• 如何將檢索與其他工具結合（搜尋知識庫，然後呼叫計算器，然後再次搜尋）

這就是代理式RAG管線背後的核心理念：檢索不是工作流程中的固定步驟。它是代理透過標準工具呼叫介面呼叫的一種能力。

為什麼嵌入式檢索程式碼在代理演進時會失效

考慮一個典型的RAG整合。你有一個Python函式，它接收使用者查詢，產生嵌入，搜尋Pinecone或Weaviate，將top-k結果組裝成上下文字串並傳回。這個函式在應用程式邏輯中的特定點被呼叫。

現在你希望AI代理使用同樣的檢索能力。問題立即出現：

與單一工作流程緊密耦合。 檢索函式假設它將在特定序列中被呼叫。代理不遵循序列。它推理目標並動態選擇工具。你的嵌入式函式沒有讓代理發現它的機制。

代理無法理解的架構。 代理使用工具呼叫規格——描述工具功能、接受哪些參數以及傳回什麼的結構化描述。你的嵌入式檢索函式沒有這些。代理無法推理它看不到的工具。

無法獨立部署。 檢索邏輯存在於你的應用程式內部。如果你想讓不同的代理、不同的框架或不同的編排層使用同一個知識庫，你必須複製程式碼。每個副本獨立漂移。

沒有版本控制或可替換性。 當你更新嵌入模型、改變分塊策略或切換向量資料庫時，檢索邏輯的每個消費者都必須更新。沒有抽象邊界。

隨著AI系統的成長，這些問題不斷疊加。一個代理變成三個。一個知識庫變成五個。一個編排框架被另一個取代。嵌入式檢索程式碼變成了隨每個新消費者線性增長的維護負擔。

工具呼叫規格如何運作

現代AI代理透過結構化規格發現工具。兩種主導格式是OpenAI函式呼叫和Anthropic工具使用，但概念在兩者中相同：一個JSON schema，描述工具的名稱、用途、參數和預期輸出。

RAG管線的工具呼叫規格可能如下所示：

{
  "name": "search_knowledge_base",
  "description": "Search the internal knowledge base for information relevant to a query. Returns ranked passages with source citations.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Natural language search query"
      },
      "max_results": {
        "type": "integer",
        "description": "Maximum number of passages to return",
        "default": 5
      },
      "filter_category": {
        "type": "string",
        "description": "Optional category filter to narrow search scope"
      }
    },
    "required": ["query"]
  }
}

當代理收到此規格時，它理解工具做什麼、需要什麼輸入、以及何時可能有用。代理不需要知道工具內部如何運作——無論它使用密集嵌入、稀疏檢索還是混合方法。規格就是契約。實作是隱藏的。

這就是AI代理的RAG工具呼叫與嵌入式檢索根本不同的原因。代理將知識庫視為可以呼叫的黑盒服務，就像它呼叫天氣API或資料庫查詢工具一樣。

架構：RAG作為可替換的工具

建構代理式RAG管線意味著將檢索分解為具有工具呼叫介面的獨立服務。架構有五個元件，形成一個清晰的管線：

1. API端點。 接收來自任何代理的工具呼叫的進入點。這是一個標準HTTP端點，接受工具呼叫規格中定義的參數並傳回結構化結果。關鍵的是，這個端點還提供工具呼叫規格本身——代理可以透過請求其規格來發現工具的功能。

2. 查詢嵌入器。 將傳入的自然語言查詢轉換為向量表示。該元件是管線內部的。代理永遠不會直接與它互動。你可以替換嵌入模型——從OpenAI嵌入到本地託管的模型——而無需更改工具呼叫規格。

3. 向量搜尋。 對你的向量資料庫執行相似性搜尋。同樣，是管線內部的。代理不知道也不關心你使用的是Pinecone、Weaviate、Qdrant還是本地FAISS索引。API端點的抽象邊界意味著你可以遷移資料庫而不破壞任何代理整合。

4. 上下文組裝器。 取得原始搜尋結果並將其組裝為結構化回應：排序的段落、相關性評分、來源引用、中繼資料。該元件控制代理接收內容的品質。你可以在這裡新增重新排序、去重或引用格式化，而無需觸及外部介面。

5. API回應。 以代理期望的格式傳回組裝的上下文。回應架構是工具呼叫規格的一部分，因此代理確切知道要解析什麼結構。

這個五節點管線——API端點、查詢嵌入器、向量搜尋、上下文組裝器、API回應——可以作為獨立服務部署。任何支援工具呼叫的代理都可以發現它並立即開始使用。無需自訂整合程式碼。無需框架特定的轉接器。

自動產生工具呼叫規格

使RAG可被AI代理呼叫的最繁瑣部分是撰寫和維護工具呼叫規格。每次新增參數、變更過濾選項或修改回應格式時，規格都必須更新。手動維護規格容易出錯且很快會失去同步。

這就是自動產生的重要之處。在Ertas中，API端點節點自動以OpenAI函式呼叫格式和Anthropic工具使用格式產生工具呼叫規格。當你透過視覺化建構器定義管線的輸入和輸出時，相應的工具呼叫規格作為建構產物產生。更新管線，規格隨之更新。

自動產生的規格消除了一類錯誤：工具實際接受的內容與規格告訴代理它接受的內容之間的不匹配。它們還使維護多個RAG管線變得切實可行——每個知識領域一個、每個存取等級一個、每種語言一個——而無需為每個手動撰寫規格。

當檢索成為工具時會發生什麼變化

將RAG視為可呼叫工具而非嵌入式程式碼，改變了你對知識基礎設施的思考方式：

代理變得與框架無關。 你的RAG管線可以與任何支援工具呼叫的代理配合使用——LangChain、CrewAI、AutoGen、自訂編排器，或一個簡單的迴圈呼叫OpenAI API。工具呼叫規格是通用介面。

知識庫變得可組合。 代理可以存取多個RAG工具，每個連接到不同的知識庫。法律研究代理可能呼叫一個工具處理判例法，另一個處理監管文件，第三個處理內部備忘錄。每個都是具有自己規格的獨立管線。

升級變得不可見。 將嵌入模型從text-embedding-3-small替換為微調的領域特定模型。改變分塊策略。新增重新排序器。這些變更對代理都不可見。工具呼叫規格保持不變。API契約有效。

測試變得簡單直接。 具有定義輸入架構和輸出架構的工具可以獨立測試。你可以評估檢索品質、延遲和相關性，而無需啟動整個代理框架。整合測試驗證規格。單元測試驗證管線。

入門指南

如果你有一個嵌入在應用程式碼中的現有RAG管線，遷移路徑很清晰：將檢索邏輯提取到API端點後面，為端點定義工具呼叫規格，並將該規格註冊到你的代理框架中。

如果你從零開始建構，從上述管線架構開始。Ertas提供視覺化管線建構器，你在其中連接五個節點——API端點、查詢嵌入器、向量搜尋、上下文組裝器、API回應——然後部署。工具呼叫規格自動產生，隨時可供任何代理發現和呼叫。

RAG的未來不是更聰明的檢索演算法。而是檢索系統與需要它們的代理之間更好的介面。工具呼叫規格就是那個介面。將你的RAG管線建構為工具，你部署的每個代理——今天和未來——都可以使用它，無需一行整合程式碼。