一句话看懂：有人提出让网站通过 HTTP Accept 标头直接向 AI Agent 返回 Markdown 格式内容，但这一思路在 Hacker News 引发激烈争论。多数开发者认为，这会破坏 HTTP 缓存机制，且相比改动全网协议，让 Agent 自行将 HTML 转成 Markdown 才是更务实的方案。
事件核心：发生了什么
这场讨论源于 Hacker News 上的一则技术提议：服务器端依据请求中的 Accept 标头，为 AI 爬虫或 Agent 直接返回 Markdown 格式的页面内容，以降低 Token 消耗并提升解析效率。然而，HTTP 内容协商的资深开发者迅速指出了该方案的结构性缺陷。HTTP 协议作者之一 Roy Fielding 曾明确表示，通过 Accept 标头进行主动内容协商的缓存代价，远高于一次额外往返请求，且该机制自 1993-94 年后便不再适用于 Web 常规场景。
开发者 Simon Willison 在 2023 年也指出，Cloudflare CDN 长期未能正确支持基于 Accept 标头的 Vary 响应，若站点对不同客户端返回 HTML 与 JSON 或 Markdown，缓存系统可能向错误客户端返回错误格式，造成串线问题。虽然 Cloudflare 后来已发布相关支持文档，但社区共识是：这套机制在缓存不兼容的系统上可能依然存在隐患。
为什么重要
这一争论折射出 AI Agent 生态扩张中一个根本矛盾：是修改 HTTP 语义与全网基础设施，还是让 Agent 的“浏览器框架”（Harness）主动适应现有内容格式。主流技术人士倾向于后者——HTML 本身是语义化标记语言，Agent 完全可以通过开源 npm 包或微格式提取工具，在本地将 HTML 转成 Markdown 后再送入大模型。反对声音认为，让网站作者为省 Token 修改协议，本质上是把优化成本转嫁给内容生产方，不具公平性与可扩展性。
这关系到未来 AI 搜索引擎、信息抓取工具与内容分发平台的基础架构选型。若“按客户端返回格式”的策略成为流行做法，CDN 厂商、缓存层和反向代理都需要同步升级，否则会出现严重的缓存污染事故。
对用户/开发者/创作者的影响
对开发者：不要盲目在 Web 服务中根据 User-Agent 或 Accept 标头切换 HTML/Markdown 返回格式。若确实需要为 AI Agent 提供纯净内容，建议使用独立端点（如 /page.md），或依赖 Cloudflare 等已支持 Vary 机制的 CDN 做精细缓存配置，避免因缓存错配导致线上事故。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对创作者与站点运营者：目前无需专门为了 AI 爬虫重构站点。提升现有 HTML 的语义化与结构化程度，比维护一份额外的 Markdown 版本成本更低，且能兼容更广泛的工具生态。
对 AI 应用开发者：训练 Agent 的浏览器环境自行做 HTML→Markdown 转换是更成熟的路径，目前多数主流 Agent 框架已内置该能力，不必依赖站点端适配。
值得关注的后续
1. 云厂商跟进情况：Cloudflare 已作出支持声明，但 AWS CloudFront、Akamai 等主流 CDN 是否会对 Accept 标头协商提供完善的 Vary 支持，将直接影响该方案的可用性边界。
2. Agent 框架的适配策略：观察主流开源 Harness（如基于 Playwright 或 Puppeteer 的工具）是否持续优化本地 HTML 转 Markdown 的保真度，而非推动协议变更。
3. 检索增强生成（RAG）新实践：目前公开信息显示，多数 AI 搜索引擎已采用独立抓取与清洗链路，不会依赖 Accept 标头。若未来有头部搜索厂商尝试推广此类内容协商，需密切关注其对缓存稳定性的实际影响。
来源：hackernews
