NLWeb：微软的AI网站搜索协议

推荐语

微软开源NLWeb协议，让任何网站都能轻松实现对话式搜索，彻底改变人机交互方式。

核心内容：
1. NLWeb协议如何利用Schema.org数据构建标准化对话界面
2. 多轮上下文对话机制解决传统搜索痛点
3. 50+精准LLM调用的创新架构设计优势

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

NLWeb 创建了一个标准协议，将任何网站转变为人类和人工智能代理都可以自然查询的对话界面。

微软最近开源了 NLWeb ，这是一种用于向网站添加对话界面的协议。它利用许多网站已有的 Schema.org 结构化数据，并包含对 MCP（模型上下文协议）的内置支持，从而支持人际对话和代理之间的通信。

NLWeb 解决了什么问题？

目前，网站拥有结构化数据（Schema.org），但缺乏供人工智能代理或对话界面访问的标准方法。所有实现都是定制的。传统的搜索界面难以应对上下文感知的多轮查询。

NLWeb 为对话式访问 Web 内容创建了一个标准协议。如同 RSS 为内容聚合所做的那样，NLWeb 也为 AI 交互提供了标准协议——一个实现既支持人机聊天界面，也支持程序化代理访问。

NLWeb 不是为每个站点构建自定义 NLP，而是利用 LLM 对 Schema.org 的现有理解来创建即时对话界面。

真正的力量来自于保留上下文的多轮对话：

“寻找晚宴食谱”

“仅提供素食选择”

“不到一小时就能准备好”

每个查询都建立在先前的上下文之上——这是传统搜索界面所难以解决的问题。

NLWeb 的工作原理

双组分系统

协议层 ：REST API（ /ask 端点）和 MCP 服务器（ /mcp 端点），接受自然语言查询并返回 Schema.org JSON 响应

实现层 ：协调多个 LLM 调用以进行查询处理的参考实现

查询处理管道

用户查询 → 并行预处理 → 向量检索 → LLM 排序 → 响应

              ─ 相关性检查

              ─ 去语境化

              ─ 内存检测

             └─ 快速通道

在此流程中，单个查询可能会触发 50 多个有针对性的 LLM 调用：

• 基于对话历史的查询去语境化

• 根据网站内容进行相关性评分

• 根据内容类型自定义提示进行结果排名

• 可选的后处理（摘要/生成）

“快速通道”优化在预处理时启动了一条并行的检索路径（步骤 3），但结果会被阻止，直到相关性检查完成 。

为什么要调用 50 多次大语言模型（LLM）

NLWeb 不会使用一个大提示来处理所有内容，而是将每个查询分解为数十个小的、具体的问题：

“这个查询是关于食谱的吗？”

“它是否引用了之前提到过的东西？”

“用户是否要求记住饮食偏好？”

“这个具体结果有多相关？”

这种方法有两个主要优点：

• 没有幻觉 - 结果仅来自您的实际数据库

• 更高的准确性 ——每个 LLM 调用都有一个明确的任务可以做好

可以将其想象为拥有一支专家团队，而不是一名通才。

即使您不使用 NLWeb，这种模式（使用许多集中的 LLM 调用而不是一个复杂的提示）也值得借鉴。

快速入门

理解 NLWeb 的最好方法就是尝试一下。

微软提供了使用Behind The Tech RSS 提要设置示例 NLWeb 服务器的快速入门指南 。

＃ 设置git clone https://github.com/microsoft/NLWebcd NLWebpython - m venv myenv源 myenv / bin / activateCD 代码pip install -r 要求 .txt# 配置 （ 复制 .env . 模板 → .env ， 更新 API 密钥 ）# 加载数据python - m 工具 .db_load https://feeds.libsyn.com/121695/rss Behind-the-Tech＃ 执行python 应用程序 - 文件 .py

转到 localhost:8000 您应该有一个可以正常运行的 NLWeb 服务器。

我还注意到，该存储库包含一个 CLI ，用于简化应用程序的配置、测试和执行。然而，我很难让它工作。

服务器运行后，您可以询问以下问题：

curl - X POST http : //localhost:8000/ask \-H “ 内容类型：application/json ” \-d ' {“ 查询 ” ： “ 告诉我有关第一个的更多信息 ” ，“ 上一页 ” ： “ 查找有关人工智能的播客，它们涵盖哪些主题 ”} '

返回的 JSON 响应如下：

{" 查询 ID " ： " abc123 " ，“ 结果 ” ： [{" url " : " https://... " ,“ name ” ： “ Stuart Russell 的人工智能安全 ” ，“ 得分 ” ： 85 ，“ 描述 ” ： “ 关于对齐挑战的讨论... ” ，“ schema_object ” ：{ “ @type ” ： “ PodcastEpisode ” ， ... }}]}

Glama NLWeb 服务器

在撰写本文的过程中，我使用 Node.js 构建了一个简单的 NLWeb 服务器。您可以使用它来查询我们的 MCP 服务器目录：

curl - X POST https://glama.ai/nlweb/ask \-H “ 内容类型：application/json ” \- d ' {"query": "用于 GitHub 的 MCP 服务器"} '

据我所知，这是第一个公共 NLWeb 端点！由于 LLM 呼叫量较大，因此需要几秒钟才能做出响应。

或者，如果您想继续对话：

curl - X POST https://glama.ai/nlweb/ask \-H “ 内容类型：application/json ” \-d ' {" query " : " 可以创建 PR 的服务器 " ," prev " : " 用于与 GitHub 协作的 MCP 服务器 "} '

或者，如果您想总结结果：

curl - X POST https://glama.ai/nlweb/ask \-H “ 内容类型：application/json ” \-d ' {" query " : " 用于与 GitHub 协作的 MCP 服务器 " ,“ 模式 ” ： “ 总结 ”} '

当您想要概览而不是结果列表时很有用。

或者，如果您想生成响应：

curl - X POST https://glama.ai/nlweb/ask \-H “ 内容类型：application/json ” \-d ' {" query " : " 用于与 GitHub 协作的 MCP 服务器 " ,“ 模式 ” ： “ 生成 ”} '

此模式尝试使用检索到的结果来回答问题（如传统的 RAG），使其易于实现的事情：

• 为每个 MCP 服务器和向量存储提供了现有的嵌入

• 已经有办法调用 LLM

当我实施这个时我想到了一些问题：

• NLWeb 似乎没有规定 /ask 端点需要托管在哪里——它必须是 https://glama.ai/ask 还是可以是 https://glama.ai/nlweb/ask ？

• 我不太清楚哪种 Schema.org 数据最适合描述 MCP 服务器。

毫不奇怪，管道中最慢的部分是 LLM 调用。

REST API

目前，NLWeb 在 /ask 和 /mcp 端点上支持两个 API。这两个 /mcp 的参数相同，大部分功能也相同。/mcp /mcp 以 MCP 客户端可以使用的格式返回答案。/mcp 端点还支持核心 MCP 方法（ list_tools 、 list_prompts 、 call_tool 和 get_prompt ）。

/ask 端点支持以下参数：

与 MCP 集成

由于 NLWeb 默认包含 MCP 服务器，因此您可以配置 Claude for Desktop 来与 NLWeb 通信。

如果您已运行 NLWeb 服务器，则只需将以下内容添加到您的 ~/Library/Application Support/Claude/claude_desktop_config.json 配置即可：

{" mcp 服务器 " : {“ ask_nlw ” ：{“ 命令 ” ： “ /Users/yourname/NLWeb/myenv/bin/python ” ，" 参数 " : [“ /Users/你的名字/NLWeb/code/chatbot_interface.py ” ，“ - 服务器 ” ，“ http://localhost:8000 ” ，“ --endpoint ” ，“ /mcp ”]，" cwd " : " /用户/你的名字/NLWeb/code "    }  }}

实施基础

文档表明，如果您有现有的 Schema.org 标记或 RSS 提要，您可以快速运行基本原型。

其实很简单：

• 加载 RSS 源或 Schema.org 数据

• 提供提示的基本搜索功能

• 使用 Qdrant 进行本地开发

需要更多努力的是：

• 大规模生产部署

• 优化每个查询 50+ LLM 调用（文档中提到）

• 为您的域名定制提示工程

• 保持向量存储和实时数据之间的数据新鲜度

我已经准备好了很多组件，所以能够在一小时内就运行一个基本的原型。然而，为了让它投入生产，我需要花更多时间考虑 LLM 调用的成本。

你应该关心吗？

是，如果：

• 您已经拥有结构化数据（Schema.org、RSS）

• 您希望启用超越关键词的对话式搜索

• 您需要通过 MCP 编程访问 AI 代理

• 你可以尝试早期技术

如果：则否

• 你需要经过实战检验的生产代码

• 你无法承担高昂的 LLM API 成本

• 您的内容结构不太好

• 您期望即插即用的简便性

结论

NLWeb 作为一个战略方向比作为现有技术更有趣。NLWeb 由 RV Guha（Schema.org、RSS 和 RDF 的创建者）构思和开发，他现在是微软的 CVP 和技术研究员。这可谓资历深厚。

O'Reilly 的原型证明了它对于内容密集型网站来说是可行的。快速上手也表明它对开发者来说很容易上手。但“几天内完成原型”并不意味着“几周内就能投入生产”。

可以将其视为一项投资，旨在让您的内容原生对话化。其技术基础扎实——REST API、标准格式、成熟的矢量存储。愿景令人瞩目。代码尚需改进。

想尝试一下吗？克隆代码库并尝试上面的快速入门。