AI Agent 是怎么读网页的：Markdown 内容协商、WebMCP 与 10 秒自检

AI Agent 通过普通 HTTP 读取你的网页。讲清 Accept: text/markdown 内容协商的原理、哪些 Agent 真正支持、WebMCP 带来什么改变，以及如何 10 秒检查任意 URL。

Aug 30, 2026URL to Any

AI Agent 从来不会欣赏你的首页大图。当浏览代理、编码助手或 RAG 管线需要你的页面时，它只会发一个普通的 HTTP 请求，读回收到的字节，再把它们塞进上下文窗口。今天大多数网站返回的是 HTML：导航栏、统计脚本、Cookie 横幅、布局容器，全都要先被剥掉，真正的内容才能进入模型。Web 的两个新层级正在改变这件事。第一个让 Agent 可以用 HTTP 头请求干净的 Markdown；第二个——WebMCP——让页面声明自己能做什么，Agent 不必再猜你的按钮。这篇文章讲清这两个层级，列出今天真正支持它们的 Agent，并给你一个十秒钟的 URL 自检方法。

要点速览

AI Agent 读页面的方式是：通过 HTTP 抓取 URL，把响应转成文本——通常是剥 HTML，这会为模型根本用不上的标记浪费 token。
Accept: text/markdown 约定用标准 HTTP 内容协商，让同一个 URL 对浏览器出 HTML、对 Agent 出 Markdown——更省 token、检索更干净、响应更快。
支持是真实的，但不均衡：Claude Code、GitHub Copilot、Cursor 这类编码 Agent 会主动发这个头；ChatGPT 浏览、Gemini 这类消费级助手目前仍然只抓 HTML。
正确实现的关键大多在缓存：少了 Vary: Accept，缓存会把 Markdown 发给浏览器、把 HTML 发给 Agent。
WebMCP 走得更远：页面注册带类型定义的工具，Agent 在用户已登录的会话里直接调用。它从 Chrome 149 开始开放 origin trial——方向明确，但仍是草案。

Agent「读」你的页面时，到底发生了什么

去掉科幻滤镜，Agent 的「阅读」就是普通的 HTTP。Agent 的抓取工具请求你的 URL，收到响应，把它变成模型能用的文本。因为大多数网站返回 HTML，Agent（或它前面的抽取层）要去标签、删脚本和样式，然后祈祷剩下的部分是正文而不是导航菜单。

这条管线能用，但它浪费一种特定资源：token。HTML 携带的字节远多于它包裹的正文——class 属性、内联脚本、无障碍标记、布局容器。一个读十页的 Agent，在模型开始推理第一句话之前，就已经把相当一部分上下文窗口花在了标记上。同样的浪费也出现在检索里：RAG 管线若把带 Cookie 横幅残留和相关文章推荐的页面文本做向量化，向量里就混进了噪声。

还有第二种模式值得区分：操作（actuation）。驱动浏览器的 Agent——点按钮、填表单的那类——读的可能是无障碍树或屏幕截图，而不是原始 HTML。这是它们「操作」页面的方式。但操作从阅读开始，而阅读正是下一个层级要解决的问题。

阅读层：`Accept: text/markdown`

「同一个资源，不同格式」这件事，HTTP 早有标准答案：主动内容协商（RFC 9110 §12.5.1）。客户端声明自己接受什么，服务器选择返回哪种表示。text/markdown 媒体类型从 RFC 7763 起就已注册。acceptmarkdown.com 推广的约定把两者接了起来：请求带 Accept: text/markdown 时返回该 URL 的 Markdown 版本；浏览器要 HTML 时照常出页面。URL 保持不变——没有 /index.md 的两套地址，也没有重复内容问题。

该站的指南把经济账算得很具体：

Token——Markdown 去掉导航、样式、脚本和布局包装，Agent 的上下文花在你的文字上，而不是你的 DOM 上。
检索——没有广告和弹窗残留污染 RAG 管线的向量。
延迟——抓得更少、解析更少、塞进上下文的更少，模型更早开始思考。

返回 Markdown 变体不难，做对才是大多数实现栽跟头的地方：

发送 Vary: Accept。 没有它，CDN 和浏览器会缓存一种表示并发给所有人——Chrome 拿到 Markdown，Agent 拿到 HTML。RFC 9110 §12.5.5 就是为这个存在的。
正确处理 q 值。 Agent 发来的是带优先级的列表，比如 text/markdown, text/html;q=0.9, */*;q=0.7。匹配意味着排序，而不是子串查找。
不要轻易返回 406。 只要精确媒体类型不匹配就回 406 Not Acceptable，会弄坏那些本可以接受 HTML 的客户端。只在真正无法满足时才拒绝。

你还得有 Markdown 可返回。三条路线覆盖所有技术栈：从事实源头渲染（CMS 里存的本来就是 Markdown）、构建期双份渲染、运行时把 HTML 转 Markdown。Cloudflare 甚至提供了托管的 Markdown for Agents 功能，在边缘完成协商，源站零改动。

哪些 Agent 真的发这个头

乐观要拿数据校准。acceptmarkdown.com 维护了一张带核验日期的支持矩阵，基于对实际行为的观察：

Agent	发送 `Accept: text/markdown`？	备注
Claude Code（Anthropic）	是	`text/markdown, text/html, /`
GitHub Copilot（Chat 与 CLI）	是	2026 年 6 月核验
Microsoft Copilot	是	2026 年 6 月核验
Cursor	是	`text/markdown, text/plain;q=0.9, /;q=0.8`
OpenClaw、OpenCode	是	2026 年 5 月核验
Codex CLI（OpenAI）	部分	先抓 HTML，再跟随 `<link rel="alternate" type="text/markdown">` 找到 `.md` 副本
ChatGPT（浏览）、Claude.ai 网页版、Gemini 网页版与 CLI、Aider、Cline、Devin	否	只抓 HTML

两个实际推论。第一，如果你的受众是使用编码 Agent 的开发者，Markdown 内容协商今天就能触达他们。第二，Codex CLI 那一行——先抓 HTML、再跟随 <link rel="alternate" type="text/markdown" href="…page.md"> 指针的客户端——是一个免费的兼容性加分项：在文档 <head> 里标注 Markdown 副本，就能覆盖仅靠请求头覆盖不到的客户端。

十秒检查任意 URL

想知道 Agent 看到什么，不需要什么面板，两条 curl 命令就够：

# 看响应头：服务器是否协商？
curl -sI -H "Accept: text/markdown" https://example.com/page

# 看响应体：实际返回什么？
curl -s -H "Accept: text/markdown" https://example.com/page

写这篇文章时我跑了这两条命令。对 acceptmarkdown.com 自身——一个在线的实现——头检查返回 content-type: text/markdown; charset=utf-8，以及最关键的 vary: Accept；响应体以干净的 # 标题开头，而不是 <!DOCTYPE html>：

$ curl -sI -H "Accept: text/markdown" https://acceptmarkdown.com/
HTTP/2 200
content-type: text/markdown; charset=utf-8
vary: Accept

对没有实现协商的 example.com，同样的请求返回 200 和 content-type: text/html——服务器直接忽略这个头，这对未实现协商的站点是正确的默认行为（也有配置不当的服务器会返回错误，那反而弄坏了本可以接受 HTML 的 Agent）。acceptmarkdown.com 还提供在线检测器，从协商、Vary、406 处理到 q 值给 URL 打分。

操作层：WebMCP

阅读层解决 Agent 对你页面知道什么，WebMCP 解决它们能在页面上做什么。按 Chrome 官方文档的定义，WebMCP 是「一个帮你为 AI Agent 构建并暴露结构化工具的提议 Web 标准」——由 Google（Chrome）与 Microsoft（Edge）的贡献者在 W3C Web Machine Learning 社区组中推进。Agent 不再逆向工程你的界面，页面自己注册带名称、描述和 JSON Schema 的工具；Agent 发现它们、用结构化参数调用，然后由你自己写的 JavaScript 执行——在标签页里、用户真实的登录会话中、看得见地运行。

设计由三块支撑：发现（列出页面工具的标准方式）、模式（带类型的输入输出，Agent 传参不再是猜）、状态（页面此刻到底有什么）。由于接口是工具契约而不是布局，改版不会弄坏 Agent。又因为执行发生在用户看得见的地方、敏感操作有显式确认把关，站点始终控制着 Agent 能做什么。

成熟度检查：真实可运行，但很早期。WebMCP 是社区组草案，官方文档自己都说「可能变化」。Chrome 提供 Chrome 149 起的 origin trial和本地开关（chrome://flags/#enable-webmcp-testing）。OpenAI 在 2026 年 8 月宣布 ChatGPT 桌面浏览器支持 WebMCP——这让它是两个厂商共同的方向，而不再只是 Chrome 的实验。早期部署里有个值得学的设计习惯：给工具分层——只读工具不设门，可逆操作轻确认，真正重大的行为（支付、提交）才要求显式人工批准。

你该上哪一层？

文档、博客、参考资料 → Markdown 内容协商便宜且已标准化：实现 Accept: text/markdown，带上 Vary: Accept，再加 <link rel="alternate"> 指针覆盖先抓 HTML 的客户端。静态 llms.txt 是更弱但零风险的保底。
带操作的应用——结账、预订、后台面板 → 这是 WebMCP 的地盘。当下：在开关后面做原型，注册一个只读工具，看 Agent 调用它。生产化等草案稳定。
所有站点 → 用十秒 curl 检查跑一遍自己的 URL。知道 Agent 现在从你站点拿到什么，是两个层级共同的前置条件。

从还不协商的页面拿 Markdown

大多数网站还不协商，而你经常现在就要 Markdown——进知识库、进 RAG 管线、做引用存档。实用的桥是一座转换器：它渲染页面，交给你干净的 Markdown。粘贴 URL，得到带标题、列表和表格的正文，样板内容已被剥掉。URL to Any 的 URL 转 Markdown 工具就在浏览器里做这件事，免费、无需注册——正是 Agent 最想收到的那种输出，按需可得。

用 URL to Any 免费的 URL 转 Markdown 工具转换 https://acceptmarkdown.com/（截图来源：urltoany.com/url-to-markdown，访问于 2026-08-30）。

常见问题

所有 AI Agent 都发 Accept: text/markdown 吗？ 不是。编码 Agent 走在前面（Claude Code、GitHub Copilot、Cursor、OpenCode），ChatGPT 浏览、Gemini 这类消费级助手仍只抓 HTML——所以把这个头当作渐进增强，而不是干净 HTML 的替代品。

返回 Markdown 会伤 SEO 吗？ 按标准内容协商来做就不会：同一个 URL，搜索爬虫仍拿到 HTML，因为它们不发 Markdown 偏好。要避免的失败模式是不带 Vary: Accept 的缓存——它可能把错误的变体发给任何人。

我现在需要上 WebMCP 吗？ 多数站点暂时不需要。它还是 Chrome origin trial 里的草案标准——如果你的站点重操作，值得做原型；无论如何都值得现在理解，因为「声明，而不是被抓取」正是 Agent 交互的走向。

结论

Agent 通过普通的 HTTP 读你的页面，返回什么是你的选择。阅读层——Accept: text/markdown——已经标准化、成本低，而且开发者每天在用的 Agent 已经在支持它。操作层——WebMCP——更早期，但正快速走向「声明工具，而不是被扒取」。两者之间有一个人人能跑的检查：带上 Accept: text/markdown 请求你自己的 URL，看看回来的是什么。如果答案是 HTML 糊成一团，至少你确切知道了机器在读什么——而现在，你也有了改变它的工具。