代理式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管道构建为工具，你部署的每个代理——今天和未来——都可以使用它，无需一行集成代码。