很多团队还在用 SEO 时代的思路做内容分发，只盯着“人类浏览器如何看页面”，却忽略了一个变化：越来越多流量入口已经是 AI crawler 和 agent。
Cloudflare 在 2026 年 2 月 12 日发布的 Markdown for Agents，本质不是“把 HTML 转一下格式”这么简单，而是在协议层给了 Agent 一个低成本、低歧义的内容接口。
我的判断很明确：
很多人以为 AI 抓网页的难点是“抓不到”，其实更常见的问题是“抓到了，但上下文被垃圾信息稀释”。
Cloudflare 在原文给了一个非常直观的数据：同一篇博客，HTML 约 16,180 tokens，Markdown 约 3,150 tokens。这不是小优化，是数量级差异。
| 版本 | Token 数 | 相对 HTML 占比 | 同等上下文可承载内容 |
|---|---|---|---|
| HTML | 16,180 | 100% | 1.00x |
| Markdown | 3,150 | 19.47% | 5.14x |
关键结论：
这对 RAG、Agent 浏览、检索增强都很关键。因为你不是在省几分钱，而是在提升“每个上下文窗口的有效信息密度”。
Cloudflare 这次设计最聪明的点，是没有发明一套“私有抓取协议”，而是复用 HTTP 的内容协商机制：
Accept: text/markdowncontent-type: text/markdown此外，响应头里有两个对工程非常实用的信号：
x-markdown-tokens：估算 markdown token 数，可直接用于 chunking 与上下文预算content-signal: ai-train=yes, search=yes, ai-input=yes：内容可用于训练、搜索与 agent 输入的声明信号这套链路有一个现实价值：你可以在不改源站 CMS 的前提下，把“给人看的网页”升级为“给 agent 读的高信噪比文档流”。
很多团队现在的做法是：
问题是，这条链路看似可控，实际维护成本很高，而且容易产生“语义偏移”。
| 维度 | 传统 HTML 清洗管线 | Markdown for Agents |
|---|---|---|
| 接入复杂度 | 高，需要维护解析和清洗逻辑 | 低，主要是请求头协商 |
| 语义稳定性 | 中，依赖你的解析规则质量 | 高，源侧直接转换输出 |
| Token 预算可观测性 | 低，需自行估算 | 高，响应头直接给 token 估算 |
| 维护成本 | 高，页面结构改动易引发回归 | 中低，协议稳定，逻辑更薄 |
如果你做的是多站点抓取平台，这个差异会直接体现在工程产能上：少一层解析，就少一层 bug surface。
Accept: text/markdown，却以为自己在用如果请求头不带 Accept: text/markdown，服务端可能仍返回 HTML。你表面上“支持了”，实际链路没变。
改进方式：把协商头作为 SDK 默认值，并在日志中强制记录 content-type。
x-markdown-tokens很多人拿到 markdown 就直接入库，不做预算。结果是 chunk 尺寸拍脑袋，召回质量漂移。
改进方式：把 x-markdown-tokens 纳入分块策略，例如按 token 阈值动态切片，而不是固定字符数切分。
content-signal 当成“唯一治理手段”content-signal 很有价值，但它不是合规与授权的全部。你仍需结合 robots、站点条款、数据许可策略统一治理。
改进方式：把策略治理分层，协议信号只是其中一层，不是全部。
根据 Cloudflare 官方文档，当前边界很清楚：
这意味着：
Accept: text/markdown, text/html。content-type、x-markdown-tokens、content-signal。content-signal 与 robots/条款的职责边界。SEO 时代优化的是“被人找到”，而 AEO 时代优化的是“被 agent 正确理解”。
Cloudflare 这次做对的一点，在于它没有把问题做成一个花哨产品，而是把它放回了最该在的位置：内容协商与分发协议层。
谁先把这层打通，谁就更早拿到 AI 流量时代的确定性。