用 Accept Headers 向 AI Agents 提供 Markdown
Serve Markdown to AI Agents with Accept Headers
你的网站内容其实已经存在，只需通过 Accept Headers 提供 Markdown 版本，就能让 AI Agents 直接读取核心内容，跳过导航、脚本和布局等冗余代码。这不仅大幅减少了 Token 消耗，让模型将上下文集中在你的正文上，还能提升 RAG 管道的信噪比，避免广告和弹窗干扰。更关键的是，更小的数据量意味着更快的首字延迟，让 AI 能更快开始思考。通过检查 URL 是否支持 text/markdown 响应，你可以快速评估网站的 AI 就绪程度，并参考 Nginx、Cloudflare Workers 等平台的配置指南进行优化。
你的网站已经拥有内容，提供 Markdown 变体能让 AI 客户端跳过导航、脚本和布局标记，直接读取内容。
HN 评论区
106- k1m
我同意 Roy Fielding 的观点：
> 在每个请求中发送一堆头部字段，仅仅为了告诉服务器用户可能拥有的所有偏好变体，这是一个糟糕的设计权衡，尤其是当这些维度中的任何一个适用于目标资源的可能性微乎其微时。自从 1993-94 年那个短暂的时期（当时人们不知道哪种图像格式能在所有 UA 上使用，且没有 CSS 或 JavaScript 允许客户端自适应）以来，这一直是个糟糕的设计权衡。
> ……主动协商对缓存的影响远比每个站点多一次往返的被动协商要糟糕得多，而且即使在支持客户端自适应的格式中，连那一次往返也是不必要的。
关于缓存影响，Simon Willison 写道：
> ……你无法将使用 Accept 头部进行内容协商的应用程序部署在 Cloudflare CDN 之后——例如，根据传入的 Accept 头部为同一 URL 提供 JSON 或 HTML。如果你这样做，Cloudflare 可能会向 HTML 客户端提供缓存的 JSON，反之亦然。
注：我在另一条评论中发布了这两段引文及其链接，当时无法轻松复制，稍后会补上。
- lo_fye
别告诉我，我们宁愿让 AI 更容易阅读我们的内容，也不愿让人类更容易阅读我们的内容。
更好的主意是：让你的 UI 始终优先考虑内容本身。
- lekevicius
除非四大 AI 聊天机器人中的任何一个表示将开始使用这个头部发起请求，否则我不会这么做。在那之前，这只是一个没人采用的好点子。
我也认为，四大聊天机器人中任何一个选择以这种方式加载网站的可能性都极低。即使多年后，为了 0.01% 的采用率去冒这么大的风险也是不值得的。
- collimarco
那干净、语义化的 HTML 呢？
它早就已经为机器人和搜索引擎（本身就是机器人）优化过了，而且已经使用了数十年。为什么我们现在需要以 Markdown 形式提供服务？
HTML 中还有许多部分，比如导航栏（navs），对机器人和 AI 很有用，但在 Markdown 版本中可能会被移除。
- joshum97
我觉得我要疯了。谁在神志清醒的情况下会直接把原始 HTML 喂给 LLM 呢？
HTML 是一种标记语言。用户代理（User Agents）会以对用户有意义的方式呈现它——无论是视觉上还是通过辅助技术。引入 LLM“用户”不应该改变这一点——它们的用户代理（即 harness）应该以 LLM 原生理解的方式呈现 HTML，也就是将其转换为 Markdown。
我们不会仅仅因为 harness 开发者太懒或太笨，不愿从 npm 上拉一个 HTML 转 Markdown 的包，就重写整个互联网。如果有些网站确实想这么做，那对他们来说是好事，在很多情况下，我也很乐意跳过 CSS/JS 直接阅读 Markdown（或者更好，是格式优美的内容）。但别怪网站作者，是你们自己的 harness 浪费了 token。
- theletterf
看到这个线程里的所有问题，我强烈推荐 Dachary Carey 关于“面向代理的文档”的文章：https://dacharycarey.com/2026/02/18/agent-friendly-docs/
- kaangiray26
希望这个能成为主流，这样我就能在没有广告、JS 和臃肿代码的情况下直接查看页面了。
- LunicLynx
你好……想要更容易获取数据的 AI 公司。