llms.txt vs NLWeb vs WebMCP vs 远程 MCP 服务器

速览

四个接口面，按它们在规划会上被提出的顺序排列。地位与日期均截至 2026 年 10 月。

llms.txt——一条提示，也是唯一有反面证据的接口面

它是什么

Answer.AI 的 Jeremy Howard 在 2024 年 9 月提出了 llms.txt，并在 llmstxt.org 配了一份规范：放在站点根目录的一个 markdown 文件，里面有一个写项目名的 H1、一段引用块摘要，以及若干 H2 小节，列出带注释的链接，指向模型应当视为权威的那些页面。配套的 /llms-full.txt 把那些页面的正文内联进来，而提案还建议为每个页面发布一份 markdown 副本，URL 相同、后面加上 .md。

实际发生了什么

这是四者中唯一一个「有东西读它吗？」已经被实证回答过的，而答案并不客气。被引用最多的那份研究，是一份 2026 年 6 月发布的、跨约 13.7 万个域名的服务器日志分析：它报告在被测的那个月里，97% 已发布的 llms.txt 文件抓取次数为零；而在确实被抓取的那少数里，GPTBot 占了 4.51% 的请求，ClaudeBot 占 0.80%，DeepseekBot 占 0.02%。更小规模的单站日志复盘指向同一个方向，其中几份在一到两周的窗口里完全没有记录到针对该文件的 AI 爬虫请求。采用率的估计彼此矛盾——一份约 30 万域名的分析给出接近 10%，而一个覆盖 219 个知名主机的追踪器发现 57.6% 提供了该文件——但报出高数字的样本池严重偏向技术公司，所以这两个数字与其说是互相冲突，不如说是在量两个不同的人群。

谷歌的立场值得完整地读，因为它按产品分裂。Search Central 关于 AI 功能的指引说，站点所有者不需要创建机器可读的 AI 文本文件才能出现在搜索的生成式功能里，因为搜索并不使用它们；John Mueller 还公开把这个文件比作当年的 keywords meta 标签。与此同时，Chrome 的 Lighthouse 13.3 在 2026 年 5 月发布，把一个「Agentic Browsing」审计类别从实验状态提升进了默认配置，而那个类别里就包含一项 llms.txt 检查。有一个细节把这件事定了调：当文件缺失时，该审计返回不适用；文件存在且格式良好时通过；只有在服务器抓取出错时才失败。就连那个去找它的工具，也拒绝因为你没有它而扣你分。

该怎么对待它

发布一份只要一个下午，所以这个决定的成本那一侧不是问题所在——问题在于一个没人读的文件会无声地过期，而当最终真有东西来读时，一份过期的站点地图比没有地图更糟。提案里真正站住了的是另一半：为每个页面提供干净的 markdown。那是会被抓取的，因为它就是那个页面本身，而它对从爬虫到浏览器智能体的每一类消费方都有帮助。如果你只从本节做一件事，就做那些 .md 副本，把索引文件当成可选项。

NLWeb——形状是对的，在等一个消费方

它是什么

微软在 Build 2025 上把 NLWeb 作为一个 MIT 许可的项目发布：你把它指向你已经在发布的内容——schema.org 标注、RSS、一份商品目录——它就在其上立起一个自然语言的 /ask 端点，而每个实例同时作为一个 MCP 服务器暴露出来，好让智能体把它当成工具来调。发布时的说法是「智能体网络的 HTML」：每个站点一个端点，回答关于这个站点自有数据的问题。

实际发生了什么

早期采用者名单——Shopify、TripAdvisor、Eventbrite、O'Reilly、赫斯特旗下站点——自发布以来几乎没有动过，而到 2026 年中的报道把采用描述为停滞。仓库仍把自己的实现代码定性为概念验证式的演示，而非一个生产级答案；在主流云上的托管部署当时仍标着「即将推出」；.NET 实现被标为实验性，于是 Python 成了唯一一个被人称为可部署的参考实现。Cloudflare 在 2026 年初通过其 AI Search 产品加入了 NLWeb 支持，这让该协议在 Azure 之外多了一个基础设施背书方。分析师的评论耐心而非看多，Constellation Research 的 Michael Ni 把「实质性采用」放在了两三年之后。

原因是一个「先有鸡还是先有蛋」的问题，而不是技术缺陷，而它值得被精确地点名：没有助手在规模上去查询 /ask，发布方就没有理由跑一个；而没有发布方在跑，任何助手也就没有理由投入。那正是M×N 互操作问题所描述的同一个死锁，而 MCP 之所以打破了它，仅仅因为消费方那一侧——那些编码智能体——先动了，而且是成规模地动。

该怎么对待它

对于「让智能体能就我的目录提问」这件事，NLWeb 的形状是对的；而如果你已经有 schema.org 数据，把它立起来确实很便宜。请把它当成一次「押消费方会到来」的下注，照这个尺度安排投入；并注意真正有价值的产物是底下那个检索索引——它同时服务你自己的站内搜索与你自己的 MCP 服务器，所以就算这个协议停滞，这份工作也不算白做。索引新鲜度与失效才是长期真会花你钱的那一块。

WebMCP——唯一会动手的那个，也是唯一没有调用方的那个

它是什么

WebMCP 让一个页面用自己的 JavaScript 向浏览器注册工具，于是在该标签页里操作的智能体可以去调一个类型化的函数，而不必去驱动 DOM。它是 W3C Web Machine Learning 社区组的一份「社区组报告草案」，编者来自微软与谷歌；那份在 2026 年 10 月 20 日修订过的规范页面直白地写着：它既不是 W3C 标准，也不在 W3C 标准轨道上。Chrome 已在 chrome://flags 后面发布了一个早期预览，据报道落在 2026 年 2 月的 146 版里；Edge 的支持被它自己的合著者描述为「预期」而非已发布，而 2026 年中的一次复盘没有找到可靠证据表明智能体客户端里存在一条普遍可用的 WebMCP 调用路径。

实际发生了什么

它还很早，而这是故事里较小的那一半。结构性的问题在于：一个注册过的工具是以你页面自己的 JavaScript 身份执行的，就在那位已登录用户既有的会话里——于是你的服务器收到的，是一个它无法与一次点击区分开的请求。调用方没有自己的身份，这意味着你无法给它授权、无法单独给它限流、也无法在不吊销那位用户的前提下吊销它。那正是《WebMCP 把你的页面变成了 API》里的论证，也是 WebMCP 不能整齐地摆在另外三者旁边的原因：它是一个比 DOM 更好的驱动面，而它完全不是一道授权边界。

该怎么对待它

当你有一块智能体确实需要操作的界面时再建它——一个多步表单、一个配置器、一个状态就住在页面里的东西——并把每一个注册过的工具都当成一个「标签页里的任何东西都能到达」的公开端点。这意味着服务端校验要放在真正那次变更上，而不是放在工具处理函数里；也意味着没有任何工具可以在缺少「人类点击同样会得到的那道确认」的情况下执行不可逆动作。工具的模式与契约照旧适用；安全地渲染智能体输出讲返回路径。

远程 MCP 服务器——那个正在赢的乏味选项

它是什么

一个暴露类型化工具、带鉴权的端点，任何 MCP 客户端都能连上来。MCP 的治理在 2025 年 12 月转到了 Linux 基金会的 Agentic AI Foundation，这件事对协议设计的意义不如它的另一重意义：它不再是某一家厂商的项目。平台厂商随后跟上：Google Cloud 在 2025 年 12 月 10 日宣布了面向 Google 与 Google Cloud 服务的全托管远程 MCP 服务器——首批是 Maps Grounding Lite、BigQuery、Compute Engine 与 GKE，并点名了接下来几个月的 Cloud Run、Cloud Storage、AlloyDB、Cloud SQL、Spanner、Looker、SecOps 等——访问通过 Cloud IAM 管理，带审计日志，并用 Model Armor 来对付间接提示注入。第三方服务器在持续上线；与本文同一周的一个例子是 Notified 在 2026 年 10 月 21 日为其公关与投资者关系平台开放了一个 MCP 测试版。

实际发生了什么

这是这份清单上唯一一个消费方那一侧不属于假设的接口面，而且差距并不接近。它也是唯一一个回答了另外三者都回避掉的那个问题：是谁在调用？一个令牌标识出客户端，于是你可以限定它能做什么、给它计量、给它记日志、把它关掉——而这正是「暴露一项能力」与「祈祷没人滥用它」之间的差别。MCP 鉴权讲当下的授权故事，生产环境中的 MCP 运维讲运维现实——它比协议文档读起来要不愉快些。

代价是实打实的工作，而不是一个周末。你在运营一个 API：版本管理、下线窗口、限流、鉴权，以及一个会被智能体以你没测过的组合方式使用的工具面。那些具体的坑现在已经被标记得很清楚了——过大的返回结果撑爆上下文窗口（大体积结果与分页）、工具太多稀释了选择（MCP 工具设计），以及工具描述本身就是一个注入面（工具投毒）。

该怎么对待它

如果智能体本该在你的产品里做任何事，那该建的就是这一个，而其余几样最多是补充。请从覆盖你最常被要求的那几项集成的三到五个工具开始，而不是机械地把你整个 REST 面包一层——一百个单薄的工具是比五个形状良好的工具更差的产品。

真正把它们区分开的那根轴是权限

按「标准化地位」去比较这四样，会得出一个什么都预测不了的排名，因为它们并不互为替代品。改按「智能体想做什么」来排，重叠就消失了。读你的内容是一次没有调用方、也没有责任归属的公开操作：服务它的东西是稳定 URL 上的干净 markdown，而 llms.txt 是关于这件事的一条提示，而不是做这件事的办法。问一个关于你数据的问题，会让你对那个答案负责，所以它需要一个你保持新鲜的索引与一个你划定的范围——NLWeb 的形状，或者你自己那个藏在 MCP 工具后面的搜索端点。代表用户动手，需要知道是谁在要求、以及代表谁，而那是一个令牌问题。WebMCP 坐在这个框架之外，而不是坐在第三列里面：它会动手，但它动手所用的权限属于那个被它借用了会话的人。

对任何在规划这项工作的人来说，有两个推论。第一，一个只产出了「已发布文件」的智能体就绪项目，什么可测的东西都没产出；能够被验证的交付物，是一次从真实客户端发出并成功的调用。第二，如果你想知道到底哪些智能体正在到达你，该上仪表的接口面是你的日志、你的 robots.txt 以及你的 bot 验证姿态，而不是你的 llms.txt——bot 验证与智能体访问讲的是识别那一侧，而它是决定其余任何事情的前提。

什么时候该选哪个

还有一个框架要留住：这里的不对称并不关乎质量。llms.txt、NLWeb 与 WebMCP 都是一群把一个真实问题想清楚了的人做出的合理设计。不对称之处在于：MCP 的消费方那一侧先到了，而且是成规模地到了——而那是唯一曾经让一种面向 Web 的格式值得发布的东西。盯消费方，别盯规范。

延伸阅读

本站相关：

• agents.json 与面向智能体的 OpenAPI——本文略去的那个相邻提案，以及为什么。
• WebMCP 把你的页面变成了 API——权限问题的细说。
• MCP 鉴权——一个调用方怎么拿到身份。
• MCP 工具设计——为什么五个工具胜过一百个。
• 生产环境中的 MCP 运维——跑一个究竟要花多少。
• bot 验证与智能体访问——搞清哪些智能体在到达你。
• M×N 互操作问题——为什么必须由消费方先动。

项目来源：

• llmstxt.org——llms.txt 规范
• GitHub 上的 microsoft/NLWeb
• WebMCP——W3C Web Machine Learning 社区组草案
• Google Cloud——宣布对 Google 服务的官方 MCP 支持（2025 年 12 月 10 日）
• Linux 基金会——Agentic AI Foundation 成立