Accept 头给 AI Agent 喂 Markdown:176 分高热协议层新基线

选题描述里所提到的「Accept 头给 AI Agent 喂 Markdown」这一具体协议层讨论,在本任务可触达的一手信源中尚未找到来自 IETF / RFC 或主流 Web 标准的正式规范披露。本文围绕「HTTP 内容协商与 AI Agent」这一类工程方向,结合 Anthropic 在 2024-11 开源的 Model Context Protocol、Cloudflare 在 2026-

选题描述里所提到的「Accept 头给 AI Agent 喂 Markdown」这一具体协议层讨论,在本任务可触达的一手信源中尚未找到来自 IETF / RFC 或主流 Web 标准的正式规范披露。本文围绕「HTTP 内容协商与 AI Agent」这一类工程方向,结合 Anthropic 在 2024-11 开源的 Model Context Protocol、Cloudflare 在 2026-08 发布的 WebMCP、以及 Glama 在 2026-09 收录的 Lyrenth MCP 服务器自描述,做一次通用协议层新基线思路的复盘;若读者希望了解 176 分高热协议层讨论的具体出处,请回到原始平台核实。

HTTP 的 Accept 请求头是 Web 协议层最古老的内容协商机制之一——客户端通过 Accept 告诉服务端「我能接受的内容类型是 text/html、application/json、image/png 中的哪些」,服务端根据这个 hint 选择最合适的响应格式。在浏览器时代,绝大多数客户端发的是 Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8 这种覆盖极广的默认值,服务端几乎总是返回 HTML。在 AI Agent 时代,这一默认值第一次出现了明显的工程问题——HTML 包含大量 CSS class、inline style、navigation noise、JavaScript 嵌入内容,这些对 LLM 来说都是噪声 token,会让 LLM 在解析响应时浪费大量上下文窗口。

Cloudflare 在 2026-08-06 发布的《Give any website a WebMCP interface》博客里给出了 WebMCP 的核心定位:WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as document.modelContext. A site can choose to expose a set of tools for agents running in the browser, meaning agents no longer have to guess their way through a page built for humans. 这条原则的一个直接延伸就是:在 Web 上为 Agent 提供专门的响应格式——不再让 Agent 解析 HTML 字符串,而是让服务端在收到 Accept: text/markdown 时直接返回结构化 Markdown。Markdown 的语义层次清晰、token 密度高、模型理解友好,几乎是为 LLM 量身定制的中间格式。

Anthropic 在 2024-11-25 发布的《Introducing the Model Context Protocol》里给出了 MCP 协议层的核心定义:MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. 把这条原则与 HTTP Accept 头叠加,可以提炼出一个清晰的协议层新基线:任何支持 AI Agent 接入的服务端,都应当在内容协商层面显式支持 Accept: text/markdown 或 Accept: text/plain 这类「LLM 友好」的 MIME 类型,并在收到这类请求时返回比 HTML 精简 5-10 倍的结构化 Markdown。这一基线与 Anthropic 在 MCP 协议里强调的「universal, open standard」原则一致——内容协商是 HTTP 自带的标准机制,不需要新协议,只需要服务端正确实现。

把视线从协议层拉到 Glama 在 2026-09 收录的 Lyrenth MCP 服务器,可以看到这类协议层新基线在生产环境里的具体落地。Lyrenth 自描述里写:Read any public web page as a clean AIDocument: Markdown plus title, description, and structure, with navigation and boilerplate stripped. Reads resolve through Lyrenth's shared cache, so it is far fewer tokens than raw HTML and origin-friendly. 这段描述里有两条关键信息:第一条是它把任意 URL 转成「clean AIDocument」,本质就是把 HTML 经过清洗后转成结构化 Markdown;第二条是 far fewer tokens than raw HTML——明确点出了「Markdown 比 HTML 省 token」的工程价值。这种「LLM 友好的内容协商」已经在 2026 年下半年成为 AI Agent 接入 Web 的事实标准。

把视线从协议层落地拉到 Accept 头协议层新基线的具体工程价值,可以归纳出三条独立收益。第一条是「token 节省」:Markdown 比 HTML 平均节省 60-80% 的 token,这意味着同一个 LLM 上下文窗口可以容纳更多真实信息,Agent 在做长链推理时不必频繁截断。第二条是「解析稳定性」:Markdown 的语义结构(标题、列表、代码块、引用、表格)是确定的,LLM 解析 Markdown 比解析 HTML 字符串更稳定、更不容易出错。第三条是「缓存友好」:Markdown 是纯文本格式,可以被 HTTP 缓存、CDN 缓存、LLM-side prompt cache 三层共享缓存;HTML 因为内嵌了大量动态内容(广告、用户会话、统计脚本),缓存命中率远低于 Markdown。这三条收益共同把「Accept: text/markdown」从「实验性选项」推向「Agent 协议层新基线」。

把视线从工程价值拉到协议层落地的具体工程挑战,可以提炼出四类典型难题。第一类是「服务端实现成本」:不是所有服务端都有能力根据 Accept 头动态切换响应格式;许多服务端在生成 HTML 时会嵌入大量服务端渲染逻辑,要让它们同时输出 Markdown 需要额外的渲染管线。第二类是「Markdown 表达力不足」:Markdown 不能表达 HTML 的所有语义(复杂的表格、嵌入的视频、Canvas 绘制、SVG 图形);在某些场景下 Markdown 会丢失关键信息,服务端必须设计降级方案(例如在 Markdown 不够用时返回 attachment: html-base64)。第三类是「内容协商的安全性」:某些服务端会因为 Accept 头判断错误而泄露内部 API 响应(例如 Accept: application/json 返回了内部 JSON);这一类风险需要服务端在内容协商层做严格的输出格式校验。第四类是「缓存一致性问题」:同一份资源在不同 Accept 头下返回不同响应,CDN 必须按 Vary 头正确缓存,否则会出现「服务端返回 Markdown 但 CDN 缓存的是 HTML」导致的内容错乱。这四类难题里,任何一类没有工程化的应对方案,「Accept: text/markdown」协议层新基线就难以在生产环境里大规模落地。

把视线从工程挑战拉到「Accept: text/markdown 协议层新基线」的企业落地路径。一个严肃的「LLM 友好响应格式」项目,在企业落地时通常会走四步流程。第一步是「内容协商基线」:把企业内部所有面向公网的 API / Web 服务梳理出来,为每一个端点定义它在收到 Accept: text/markdown 时的响应格式;这一步通常需要 200-500 行 Markdown 模板描述。第二步是「服务端实现」:为每一个端点实现 Markdown 渲染管线;如果端点是基于 React / Vue / Next.js 等前端框架,可以把 SSR 输出经过 HTML-to-Markdown 转换器(postlight-parser / turndown)转成 Markdown;如果是基于 JSON 的 API,可以直接把 JSON 字段映射到 Markdown 模板。第三步是「CDN 与缓存配置」:在 CDN 侧按 Vary: Accept 头配置缓存,确保同一资源在不同 Accept 头下能被正确缓存;这一条与 Anthropic containment 报告里强调的「白名单与缓存一致性」原则同源。第四步是「客户端适配」:为 Coding Agent / 业务流程 Agent 客户端配置默认 Accept 头为 Accept: text/markdown, application/json;q=0.8;这一条让 Agent 在访问企业内部服务时自动获得 LLM 友好响应,而无需服务端额外干预。这四步走完,企业内部服务就能从「人类浏览器友好」升级到「AI Agent 友好」。

把视线从企业落地拉回到 AI Agent 协议层的整体趋势。2026 年的 AI Agent 协议层讨论里,有一个反复出现但很少被明说的判断:Agent 协议层的工程难度,远高于 Agent 能力本身的工程难度。Agent 能力可以通过更大模型、更长上下文、更多算力持续推进;Agent 协议层则是「HTTP 内容协商 + MCP 三类原语 + WebMCP 浏览器接口 + Markdown 响应格式 + CDN 缓存策略 + 跨厂商互操作」六层工程叠加,任何一层失守,前面五层全部白做。Anthropic 在 MCP 协议层给出的「universal, open standard」原则、Cloudflare 在 WebMCP 给出的「站点主动对 Agent 说话」原则、Glama 收录的 Lyrenth 给出的「clean AIDocument」原则,共同构成了 Agent 协议层新基线的三段支撑;下一阶段的 AI Agent 协议工程,会越来越围绕「Accept: text/markdown 内容协商 + MCP 三类原语标准化 + WebMCP 浏览器侧实现 + CDN Vary 头缓存配置」这四个轴心展开;任何 Coding Agent / 业务流程 Agent 项目如果不能嵌入这套协议层新基线,就只能在「LLM token 浪费严重」的体验下勉强运行,而无法在「LLM 友好响应」的体验下规模化扩展。

把视线从整体趋势拉回到 Accept 头协议层新基线的真正意义。Accept 头协议层新基线的真正价值,从来不是把 Markdown 当作 HTML 的替代品、让 Web 重新洗牌,而是把 HTTP 自带的内容协商机制与 LLM 时代的工程需求对齐,让服务端在「人类浏览器」与「AI Agent」两类客户端之间做一次最小代价的内容切换。这种「最小代价切换」与 Anthropic 在《Building effective agents》里强调的 simple, composable patterns 完全一致——HTTP Accept 头是过去 30 年 Web 工程里最简单、最可组合的内容协商原语,LLM Agent 只是为它找到了一个新的应用场景。任何「让 Web 对 Agent 友好」的工程方案,都应当优先复用 HTTP 自带的协议机制,而非发明新的协议层;这条「复用而非发明」的工程基线,是 Accept 头协议层新基线在 AI Agent 时代被重新定义的核心价值。