返回博客

如何构建一个使用实时网络数据的代理RAG管道

Daniel Kim
Daniel Kim

Lead Scraping Automation Engineer

17-Aug-2026

TL;DR:

  • 代理RAG让代理决定何时以及如何检索证据。 检索循环可以重新构造查询、检查其他来源、评分证据,并在明确限制下停止。
  • 实时网络数据需要一个单独的获取层。 搜索找到候选来源,浏览器渲染展示客户端页面,归一化将页面内容转换为可追溯的文档。
  • 无废料的MCP服务器为MCP客户端提供了一个搜索、页面提取和云浏览器操作的工具界面。 代理可以从任务中选择这些工具,而不是硬编码一个检索路径。
  • 评估属于每一个边界。 独立测量来源相关性、提取完整性、引用支持、答案质量、延迟和成本。

代理RAG架构一览

代理RAG管道将检索决策置于代理循环中,而不是运行一个固定的先检索后生成的序列。

原始的 检索增强生成架构 将生成器与检索的外部记忆结合。代理RAG在这一基础上增加了规划和工具使用:

问题 → 计划 → 搜索 → 渲染或获取 → 归一化 → 评分 → 存储或回答 → 引用

每一个箭头都是一个合同。搜索返回候选项,而不是事实。渲染返回页面状态,而不是干净的记录。向量存储返回相似块,而不一定是足够的证据。代理应在当前文物通过下一个阶段的检查后再继续。

代理RAG优于固定管道的情况

当检索需求因问题而异时,代理RAG是有用的。

对于已知语料库、稳定分块和单一检索策略,固定管道通常更简单。代理控制在问题可能需要多个搜索、源比较、JavaScript渲染页面、新鲜度检查或在弱证据后进行二次检索时将其成本赚回来。

ReAct研究模式 将推理痕迹与行动和观察交错。在检索系统中,该模式变成一个有界循环:决定一个工具,检查其输出,更新证据状态,并继续或停止。

不要仅仅为重命名一个确定性序列而添加代理。如果每个请求都使用相同的查询、检索器、块计数和答案提示,那么一个普通的RAG管道更容易测试和操作。

前提条件

代理RAG构建在需要模型循环之前需要有一个工作的检索工具层。

  • Node.js和一个能够运行ECMAScript模块的项目。
  • 在项目中安装了@modelcontextprotocol/sdkscrapeless-mcp-server
  • 一个Scrapeless账户和SCRAPELESS_KEY环境变量。
  • 一个用于最终规划和答案生成循环的模型提供者密钥。
  • 一个文档存储,可以保留规范URL、标题、检索时间、内容哈希和块偏移。

注意:下面的MCP客户端握手需要SCRAPELESS_KEY。已运行包安装,而经过身份验证的握手和实时工具调用仍然是当该产品密钥在运行时不存在时的前提条件。

连接Scrapeless MCP服务器

Scrapeless MCP服务器通过本地标准输入过程或托管的可流式HTTP端点连接到任何符合标准的MCP客户端。

安装确切的客户端SDK和服务器包:

bash Copy
pnpm add @modelcontextprotocol/sdk scrapeless-mcp-server

创建一个客户端,通过标准输入连接,检查工具界面,并干净地关闭传输:

javascript Copy
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "pnpm",
  args: ["exec", "scrapeless-mcp-server"],
  env: {
    ...process.env,
    SCRAPELESS_KEY: process.env.SCRAPELESS_KEY,
  },
});

const client = new Client(
  { name: "agentic-rag-client", version: "1.0.0" },
  { capabilities: {} },
);

await client.connect(transport);
const { tools } = await client.listTools();
console.log(tools.map((tool) => tool.name));

// Attach `tools` to the tool adapter used by your agent framework.

await client.close();

MCP生命周期规范定义在正常操作前的初始化和能力协商。因此,列出工具是正确的烟雾测试:它证明客户端和服务器在代理依赖之前已经完成协议握手。

无废料的MCP启动文章 讲述了服务器的角色,而Mastra集成展示了附加到特定代理框架的相同工具界面。

如何实际使用:提示检索代理

代理应接收一个目标、一个证据合同和一个停止规则。

一个有用的提示是具体的:

寻找能够回答这个问题的当前主要来源。首先进行搜索,当获取的响应中缺少所需内容时才渲染页面,为每个主张保留规范URL,拒绝不直接支持答案的来源,在证据充足或检索预算耗尽后停止。
指令将源发现与证据接受分开。它还防止了一个开放式的浏览循环。

可调整的提示

检索任务 提示约束
产品变更跟踪 要求供应商自己的发布说明及其出版日期
标准研究 优先考虑标准机构并保留章节 URL
市场比较 要求等效字段并明确记录缺失值
技术故障排除 优先考虑官方文档和可重复配置

使用 Scrapeless 开始抓取

通过 Scrapeless 提升您的网络抓取和自动化工作流程!
今天注册并获得 5 美元的免费积分无需信用卡

立即在 Scrapeless Dashboard 领取您的免费积分。

Scrapeless Dashboard 显示团队信用为 5.00 美元

搜索和呈现新鲜来源

实时网页检索应从最便宜的可靠来源升级到更丰富的来源。

首先开始搜索以收集候选 URL 和片段。当响应的 HTML 包含答案时,获取干净的页面内容。仅在客户端执行控制相关页面状态时使用浏览器渲染。这可以保持获取层的快速,而不假装每个页面都是静态的。

记录每个接受的文档的检索封套:

json Copy
{
  "canonicalUrl": "https://example.com/primary-source",
  "title": "Primary source title",
  "retrievedAt": "illustrative timestamp",
  "contentHash": "illustrative hash",
  "retrievalMethod": "search_then_render",
  "text": "Illustrative normalized page text"
}

上述值是一个说明性示例;字段是合同。即使标准化文本移动到另一个存储,也应保留原始 URL。

标准化、分块和存储

标准化将页面内容转换为稳定的文档,而不抹去来源。

去除导航重复、不可见的 UI 界面和无关的样板。保留标题、列表、表格和代码边界,因为它们传达意义。在分块之前按规范 URL 和内容哈希去重。

首先根据文档结构进行分块,然后强制执行模型的上下文约束。每个块应保留文档标识符、规范 URL、标题路径、字符偏移和检索时间。Self-RAG 研究 演示了为什么检索和批评信号应属于生成过程中,而不是被视为不可见的预处理步骤。

将原始标准化文档与嵌入分开存储。这种分离使团队可以更改嵌入模型或分块策略,而无需重新获取每个来源。

检索、评分和回答

评分步骤决定检索到的证据是否可以支持所请求的答案。

根据直接性、来源权威、时效性、与其他证据的一致性和提取的完整性对每个候选人评分。高的向量相似度评分并不能证明文本回答了问题。

答案节点应仅接收接受的证据,每个段落附有源标识符。如果证据不足,代理会重新制定查询或选择另一个获取工具。如果检索预算耗尽,它会返回一个有界的“证据不足”结果,而不是用不支持的模型记忆来填补空白。

单代理与多代理设计

单个检索代理是默认配置,因为一个状态机更容易追踪。

只有在角色确实具有不同的工具、政策或评估标准时才拆分工作流程。一名代理可以负责源获取,另一名负责证据评分,最后一名负责答案合成。多代理设计增加了协调状态、重复的上下文和更多的故障边界,因此每次交接需要明确的架构。

当工作流程需要能够操作网络工具的代理时,使用 Scrapeless AI Agent 作为产品表面。当现有的代理框架已经拥有规划且只需要实时网络功能时,使用托管的 MCP 端点。

评估和可观察性

代理 RAG 评估应隔离获取、检索和答案质量。

跟踪搜索是否找到了预期的主要来源,渲染是否暴露了所需的内容,标准化是否保留了支持段落,评分是否接受了正确的证据,以及最终声明是否得到该证据的支持。

还要记录工具选择、查询重构、源 URL、文档哈希、块标识符、停止原因、经过时间和成本。这个追踪使得较弱的答案可诊断。如果没有它,每个问题都看起来像模型问题。
审查 Scrapeless 价格 与预期的搜索、获取和渲染组合,并保持 MCP 客户端设置与当前的 Scrapeless 文档 一致。

结论:使证据成为一流的文物

当检索必须适应时,主动 RAG 管道是有用的,但代理循环并不会消除合同的必要性。

搜索、渲染、规范化、评分和生成应分别产生可检验的文物。首先连接 MCP 工具层,验证握手,然后添加带有检索预算和基于证据的停止规则的模型循环。


准备构建主动 RAG 管道了吗?

加入我们的社区以索取免费计划,并与构建实时网络检索系统的开发者连接:Discord · Telegram

请在 app.scrapeless.com 注册,并在添加模型驱动的规划循环之前连接 Scrapeless MCP 工具层。


常见问题解答

Q: 什么是主动 RAG?

主动 RAG 是一种检索增强生成设计,其中代理选择检索行为,评估证据,并决定是否继续或回答。该循环在明确的工具、时间和成本限制下运行。

Q: 主动 RAG 与标准 RAG 有何不同?

标准 RAG 通常在生成之前运行固定的检索步骤,而主动 RAG 可以重新制定查询、选择不同的工具、评分结果并执行另一个有界的检索步骤。

Q: 主动 RAG 是否需要向量数据库?

主动 RAG 不需要向量数据库。代理可以使用关键字搜索、结构化数据库、实时网络工具或混合检索器,只要证据合同是明确的。

Q: 为什么在 RAG 管道中使用实时网络数据?

当答案依赖于在模型训练截止后或静态内部语料库之外变更的信息时,实时网络数据是有用的。管道必须保留源 URL 和检索元数据,以便可审核新鲜度。

Q: MCP 为主动 RAG 系统添加了什么?

MCP 为客户端提供了发现和调用服务器工具的标准生命周期。Scrapeless MCP 服务器通过该工具边界暴露搜索、页面提取和浏览器操作。

Q: 代理应该在浏览器中渲染每个来源吗?

不。代理只有在响应内容不暴露所需信息或需要交互时,才应渲染来源。以 HTTP 为先的检索使管道运行更快且更易操作。

Q: 如何防止无尽的检索循环?

对工具调用、经过时间、接受的来源、查询重新制定和总成本设置限制。停止策略应允许“证据不足”的结果。

Q: 多代理设计是否更适合主动 RAG?

多代理设计仅在不同角色需要不同工具、政策或评估标准时更好。从一个代理开始,在踪迹显示出明确界限后再拆分角色。

在Scrapeless,我们仅访问公开可用的数据,并严格遵循适用的法律、法规和网站隐私政策。本博客中的内容仅供演示之用,不涉及任何非法或侵权活动。我们对使用本博客或第三方链接中的信息不做任何保证,并免除所有责任。在进行任何抓取活动之前,请咨询您的法律顾问,并审查目标网站的服务条款或获取必要的许可。

最受欢迎的文章

目录