用内容协商打造对 Agent 友好的网页：同一 URL 同时服务人类与机器

2 分钟阅读

2026 年 2 月 3 日

Agent 也会浏览网页，但它们的“阅读方式”和人类不同。它们不需要 CSS、客户端 JavaScript 或图片。这些标记内容会占满它们的上下文窗口，消耗 Token，却不提供真正有价值的信息。Agent 真正需要的是干净、结构化的文本。

因此，我们升级了博客和更新日志页面：在继续为人类读者提供完整 HTML 与 CSS 体验的同时，也让 Agent 能直接访问 markdown。实现方式是内容协商（content negotiation）——一种 HTTP 机制，服务器会根据客户端请求返回同一内容的不同格式。无需重复内容，也不需要拆分成独立站点。

Link to headingAgent 如何请求内容

Agent 会使用 HTTP Accept 请求头来声明自己偏好的内容格式。以 Claude Code 为例，它在抓取页面时会发送这样的请求头：

Accept: text/markdown, text/html, */*

把 text/markdown 放在第一位，表示在可用时优先选择 markdown 而非 HTML。现在越来越多 Agent 都开始以这种方式显式偏好 markdown。

你可以用 curl 亲自试一下：

curl https://vercel.com/blog/self-driving-infrastructure -H "accept: text/markdown"

我们的中间件会检查入站请求中的 Accept 头并识别这些偏好。当检测到优先 markdown 时，请求会被路由到 Next.js 的 route handler，将我们在 Contentful 中的 rich-text 内容转换为 markdown。

这种转换会保留内容结构：代码块保留语法高亮标记，标题层级保持不变，链接也可正常使用。Agent 接收到的信息与 HTML 版本一致，只是换成了更节省 Token 的格式。

Link to heading性能收益

一篇典型博客文章，连同 HTML、CSS 和 JavaScript 通常有 500KB；而同样内容转换成 markdown 后只有 2KB，负载体积减少 99.6%。

对于受 Token 限制的 Agent 来说，更小的负载意味着每次请求能读取更多内容，把预算花在真正的信息上而不是标记本身。它们处理更快，也更不容易触达限制。

我们使用 Next.js 16 remote cache 和共享 slug 来保持 HTML 与 markdown 版本同步。当 Contentful 中的内容更新时，两个版本会同时刷新。

Link to headingAgent 如何发现可用内容

Agent 需要先知道“有哪些内容可读”。我们实现了一个 markdown sitemap，用更适合 Agent 消费的格式列出全部内容。这个 sitemap 包含每条内容的元数据，包括发布日期、内容类型，以及 HTML 与 markdown 两个版本的直达链接。这样 Agent 就能拿到完整的信息地图，并按自身需求选择最合适的格式。

想看看实际效果？在本页 URL 末尾加上 .md，即可获取 markdown 版本。