通过内容协商向 AI Agent 提供 Markdown
通过内容协商优化面向 AI Agent 的 Web 内容
通过 HTTP 内容协商提供 Web 页面的 Markdown 变体,允许 AI Agent 绕过导航菜单、脚本和布局标记,使其能够直接消费核心内容。通过响应 Accept: text/markdown 请求头,服务器可以提供高信号、低噪声的版本,从而优化 Token 消耗并降低基于 LLM 的 Agent 的延迟。
Markdown 交付的技术优势
与提供标准 HTML 相比,为 AI 客户端提供专门的 Markdown 响应具有三个主要的技术优势:
- Token 效率:Markdown 移除了 DOM 包装器、CSS 样式和 JavaScript,确保 LLM 的上下文窗口用于实际的文本内容,而不是结构化标记。
- 改进检索 (RAG):通过消除广告、相关内容栏和模态叠加层,提高了信噪比,从而防止无关数据干扰检索增强生成 (RAG) 流水线中的嵌入过程。
- 降低延迟:更小的有效载荷意味着更快的获取和解析,从而缩短“首个 Token”响应时间,因为模型在生成开始前需要处理的数据更少。
AI 就绪型 URL 的实现要求
为了通过内容协商正确实现 Markdown 服务,URL 应遵循以下技术标准:
- 请求头支持:当请求包含
Accept: text/markdown时,专门提供 Markdown 内容。 - 缓存控制:设置
Vary: Accept请求头,以告知缓存(如 CDN)响应会根据请求的 Accept 请求头而变化。 - 错误处理:对于不支持的请求类型,返回
406 Not Acceptable状态码。 - 权重分配:遵循 Accept 请求头中定义的
q-values(质量值)以处理偏好权重。
社区辩论与技术反驳点
虽然该提案旨在简化 AI 消费,但它在开发者之间引发了关于 Web 标准以及客户端与服务器责任归属的重大辩论。
客户端转换论点
一些批评者认为,内容转换的负担应该落在 AI Agent 的“框架”上,而不是网站所有者身上。主流观点认为,既然 HTML 已经是结构化标记语言,AI Agent 应该使用现有的 HTML-to-Markdown 库来剥离噪声,类似于屏幕阅读器或基于文本的浏览器的工作方式。
缓存与基础设施挑战
技术层面的担忧主要集中在对内容分发网络 (CDN) 的影响上。具体而言,一些用户指出,某些 CDN(例如 Cloudflare)在没有经过特定配置的情况下,可能难以缓存同一 URL 的不同内容类型(JSON vs. HTML),这可能导致缓存的 JSON 被提供给 HTML 客户端。
可访问性与语义化 HTML
一些开发者认为,优先考虑语义化 HTML 和可访问性(ARIA 标签、屏幕阅读器兼容性)是更可持续的方法。他们主张,结构良好的、具有可访问性的 HTML 页面已经针对机器人和搜索引擎进行了优化,因此单独的 Markdown 层是多余的。
采用与激励机制
关于网站所有者实施该标准的激励机制一直是一个反复出现的问题。批评者指出,如果不提供互惠利益,仅向 AI 公司提供“干净”的数据而不获得回报,可能无法推动广泛的采用,除非主要的 AI Agent(例如 OpenAI, Google, Anthropic)明确开始请求 text/markdown 请求头。
观点总结
| 观点 | 论点 |
|---|---|
| 支持者 | 降低 Token 成本,降低延迟,并提高 RAG 准确性。 |
| 架构师 | 警告主动协商的复杂性以及 CDN 缓存问题。 |
| 务实主义者 | 建议 AI Agent 应该在本地处理从 HTML 到 Markdown 的转换。 |
| 可访问性倡导者 | 认为语义化 HTML 已经实现了机器可读性的目的。 |
Sources
相关
- Dispatch
- Dispatch
- 项目
- 项目