跳到主要内容

Agentic 网络搜索与 URL 抓取 🌐

Open WebUI 的网络搜索已经不再只是简单地注入结果片段，而是演进为完整的 agentic research system。当你启用 Native Function Calling (Agentic Mode) 后，高质量模型就可以自主探索网页、校验事实并继续跟进链接。

需要高质量模型

Agentic web search 最适合 GPT-5、Claude 4.5+、Gemini 3+、MiniMax M2.5 这类 frontier 模型，因为它们更擅长理解搜索结果并决定何时继续深挖。较小的本地模型可能难以完成这种多步骤推理。

中央工具文档

关于所有内置 agentic 工具（包括 web search、knowledge bases、memory 等）的完整说明，请参阅 Native/Agentic Mode Tools Guide。

Native Mode 与传统 RAG 的区别​

维度传统 RAG（默认）Agentic Search（Native Mode）
搜索决策由 Open WebUI 基于提示词分析决定是否搜索由模型自己决定是否需要搜索、何时搜索
数据处理拉取全部结果、切块并执行 RAG直接返回 snippets；不切块，也不使用 Vector DB
链接跟随将顶部结果的 snippet 注入上下文模型使用 fetch_url 直接读取整页内容
模型上下文仅获取相关片段（Top-K chunks）通过 fetch_url 获取整段文本（最高约 50,000 字符）
推理方式模型在系统注入数据后再处理模型可以搜索、阅读、核查，然后再次搜索

如何启用 Agentic 行为​

要解锁这些能力，你的模型必须支持原生工具调用，并具备较强推理能力（如 GPT-5、Claude 4.5 Sonnet、Gemini 3 Flash、MiniMax M2.5）。这些内置系统工具的管理员级配置请参阅 Central Tool Calling Guide。

  1. 全局启用 Web Search：确保已在 Admin Panel → Settings → Web Search 中配置搜索引擎
  2. 启用模型能力：前往 Admin Panel → Settings → Models，选中目标模型并启用 Web Search capability
  3. 启用默认功能：在同一模型设置中，找到 Default Features，勾选 Web Search。这决定 search_web 与 fetch_url 是否会默认出现在新聊天中
  4. 启用 Native Mode (Agentic Mode)：
    • 在同一模型设置的 Advanced Parameters 中，将 Function Calling 设为 Native
  5. 使用高质量模型：请确保你使用的是推理能力强的 frontier 模型，以获得最佳效果
通过环境变量进行配置

以上步骤使用的是管理面板（推荐方式）。如果你通过环境变量来管理实例，可使用 DEFAULT_MODEL_PARAMS: '{"function_calling": "native"}' 设置全局默认值——并没有独立的 FUNCTION_CALLING_MODE 变量。详情见中央工具指南。

Model Capability、Default Features 与聊天开关

在 Native Mode（当前受支持模式）下，search_web 与 fetch_url 工具要求同时满足：模型启用了 Web Search capability，且模型设置中的 Default Features 里也勾选了 Web Search（或在聊天中手动打开）。只要缺少其中任一项，这两个工具就不会被注入——即使其他 builtin tools 仍可能可用。

这里提到 Default Mode 下的 RAG 式注入行为，仅用于兼容历史部署。Default Mode 已不再受支持；所有模型都应配置为 Native Mode。

重要： 如果你关闭了模型的 web_search capability，但又使用 Native Mode，那么即使你在聊天中手动打开 Web Search，相关工具依然不会可用。

Native Tools 如何处理数据（Agentic Mode）​

🔗 需要特别理解的是：Native Mode（Agentic Mode）的工作方式，与标准模型中全局 “Web Search” 开关背后的机制完全不同。

search_web（仅返回摘要片段）​

当模型调用 search_web 时：

  • 动作：它会查询你的搜索引擎，并收到标题、链接和 snippet 列表
  • 结果数量行为：如果模型没有传入 count，Open WebUI 会使用管理员配置的 WEB_SEARCH_RESULT_COUNT。如果模型传入了 count，其值也会被限制在同一管理员上限内
  • 无 RAG：与传统搜索不同，不会有任何数据写入 Vector DB，也不会执行切块或 embedding
  • 结果：模型看到的内容，就像人类在搜索结果页上看到的东西一样。如果 snippet 已经包含答案，模型就会直接回答；如果不够，它就必须自己决定是否要“深挖”某个链接

fetch_url（整页上下文）​

如果模型判断搜索 snippet 不足以回答问题，它就会调用 fetch_url：

  • 直接访问：该工具会访问指定 URL，并使用你配置的 Web Loader 提取主要文本
  • 原始上下文：提取后的文本会被直接注入模型上下文窗口（硬编码截断为最多 50,000 字符，以防止上下文溢出）
  • Agentic 优势：由于不使用 RAG，模型拿到的是网页的“完整画面”，而不是零散片段。这使它能更好执行复杂页面级指令（例如：“Summarize the technical specifications table from this documentation link”）
提示

通过把 search_web 与 fetch_url 分离，并且不经过 RAG，模型就能像一个真正的 Information Retrieval agent 一样，自主判断哪些来源值得阅读全文。

深度研究与交错式思考 🧠​

因为模型可以多次调用 search_web，并且自主决定何时进一步深挖，它实际上可以通过 Interleaved Thinking 完成真正的 “Deep Research”。这会形成一个强大的研究闭环，让模型像研究助手一样工作。

Interleaved Thinking 如何运作​

Interleaved Thinking 指的是模型在连续循环中交替执行 推理 与 行动。它不会只搜索一次然后直接回答，而是可以：

📖 详细研究流程示例

用户提问： “React 生态系统中最新的安全漏洞有哪些？”

步骤 1：初步分析 🤔

  • 模型思考：“我需要关于 React 安全问题的最新信息，先做一个宽泛搜索。”

步骤 2：第一次搜索 🔍

Model calls: search_web("React security vulnerabilities 2026")
  • 收到若干 snippets，数量取决于管理员配置的 WEB_SEARCH_RESULT_COUNT（或模型提供的更小 count）
  • 发现结果中提到了 npm 包和 CVE 数据库

步骤 3：缺口分析 🤔

  • 模型思考：“这些 snippets 提到了 CVE，但细节不够，我应该抓取某个具体安全公告页面。”

步骤 4：定向抓取 📄

Model calls: fetch_url("https://example.com/react-security-advisory-2026")
  • 读取完整的 50k 字符安全文档内容
  • 识别具体漏洞类型（XSS、注入等）

步骤 5：细化方向 🤔

  • 模型思考：“我已经找到服务端漏洞信息，再专门搜索一下前端侧问题。”

步骤 6：二次精确搜索 🔍

Model calls: search_web("React client-side XSS CVE 2026")
  • 获得更具体的跨站脚本问题结果
  • 识别对应缓解策略

步骤 7：综合整理 🤔

  • 模型思考：“我已经从多个权威来源获得了足够信息，现在可以综合回答。”

步骤 8：最终回答 ✅

  • 给出带来源依据的详尽回答
  • 包括具体 CVE 编号、受影响版本和缓解步骤

Agentic 研究闭环​

模型会持续循环以下阶段，直到掌握足够信息：

  1. 🤔 THINK：分析当前知识缺口，判断还缺什么
  2. 🔍 ACT：执行 web search 或抓取特定 URL
  3. 📊 EVALUATE：评估获取信息的质量与完整度
  4. ❓ DECIDE：判断是否还需要继续研究，还是已经足够回答
  5. 🔄 ITERATE：若仍有缺口，则返回第 1 步，并以更精确方向继续搜索
  6. ✅ SYNTHESIZE：当信息足够后，综合整理并输出最终答案

这个循环会自动持续，直到模型有足够、可靠的信息来高置信度回答你的问题。

关键优势​

🎯 自适应精度：模型不会只搜一次然后直接接受表面结果。它会根据已发现的信息不断优化搜索策略。如果最初的宽泛搜索只得到浅层信息，模型会自动收缩范围，转向更具体的技术术语、产品名、版本号或专业词汇。每轮搜索都会越来越精确，从广义概念逐步深入到具体细节，使最终答案兼顾广度与准确度。

🔗 深度跟链与发现能力：不同于只使用 snippet 的传统 RAG 系统，模型在 snippet 不够时可以阅读整页内容。更强的是，当模型用 fetch_url 阅读一个页面时，它还能发现页面中提到的新 URL，并继续抓取这些新链接。例如，一个页面引用了技术规格文档、官方 changelog 或研究论文时，模型可以再次调用 fetch_url 深挖这些新资源。这让模型呈现出类似“网页浏览”的自然行为：沿着引用链深入阅读，探索相关资源，并像人类研究者一样通过多来源建立完整理解。

✅ 事实核验与交叉验证：模型可以自主通过多个独立来源交叉验证信息。如果一个来源提出某项说法，模型可以继续搜索权威来源进行佐证、对照官方文档中的版本号，或回溯到一手来源验证事实。这种多源校验显著减少幻觉，提高答案可靠性。

🧩 智能补全信息缺口：如果初始搜索结果缺少关键内容，或只覆盖了问题的一部分，模型会识别这些缺口，并用不同关键词、不同表达方式或更精确的问题自动发起后续搜索。例如，搜索 “React performance issues” 如果没覆盖某个特定优化技术，模型就可能进一步搜索 “React useMemo optimization” 或 “React.memo vs useMemo comparison” 来补齐知识缺口。这让复杂问题能够通过多轮搜索被完整覆盖。

🌐 多源综合：模型不会只返回单一来源的信息，而是把多个网页、文档站点、论坛和文章中的信息综合起来，形成更完整、更平衡的回答。

📚 上下文感知式来源选择：模型会智能判断：什么时候 snippet 已足够，什么时候必须抓整页内容；也能判断何时该停止继续研究，从而在效率与完整性之间取得平衡。

这种 Thought → Action → Thought 的循环会持续下去，直到模型有足够信息以最高准确度回答你的请求。

深入了解 Interleaved Thinking

若要进一步了解 Interleaved Thinking 如何在所有 agentic 工具中工作（不仅限于 web search），请参阅 Interleaved Thinking Guide。

下一步​

本内容仅供参考，不构成任何保证、担保或合同承诺。Open WebUI 按“现状”提供。请参阅您的许可协议 以了解适用条款。