智能体用请求头要纯文本版本时，站点的转换该由哪一层做

智能体用请求头要纯文本版本时，转换该由哪一层做——多数托管型边缘方案的答复是：由边缘节点代做，源站不用改代码。机制是一套内容协商：客户端在请求头里表达「我想要 Markdown」，边缘从源站取回原始网页，动态转换后返回，浏览器仍拿常规 HTML、地址不变。源站的角色退回到「提供权威原始内容」，转换的清理范围由边缘决定。

协商头怎么表达偏好

关键在请求头里的 Accept 字段。有文档说明，带 Accept: text/markdown 的请求会得到 Markdown 响应，而普通浏览器不带这个偏好，依旧返回常规 HTML，地址也不改变。也就是说，同一份内容、同一个地址，按调用方的偏好返回不同表示，这是这套机制的核心。有的托管平台对文档类域名默认就开启了这个能力，无需额外配置；有的则需要用户在控制台或配置规则里显式打开，并且受套餐档位限制。

边缘转换会去掉什么、留下什么

代做转换的清理范围是固定动作，不看源站脸色。以一套主流边缘方案为例，转换过程是这样处理的：

值得注意两条：转换有体积上限，解压后的网页超过约六百万字节量级就可能失败，超大页面拿不到 Markdown；返回的类型头是「Markdown 文本」而非原始 HTML，调用方按这个头决定怎么解析。安全头透传意味着源站原有的安全策略仍生效，但标识类头被去掉，靠这些头做缓存校验的链路要重新评估。

源站还要不要自己出纯文本

要看你对「给什么」的控制要求有多高。边缘代做的优点是零改造、覆盖全站；缺点是清理范围、体积上限、返回结构都由转换方定，源站没法精确规定「哪些字段保留、哪些去掉」。当站点结构复杂、正文里有关键的自定义字段，代做可能把有用信息也当噪音清掉。这时源站自己维护一份受控的纯文本表示更稳。

和模型说明文件怎么分工

这件事和站内生成模型可读清单是两条互补的路。协商转换处理的是「单个页面按需返回纯文本」，是响应时行为；模型说明文件（llms.txt 这类）处理的是「告诉抓取方整站有哪些内容、从哪读起」，是一份静态清单。GEO 模块里这两者各管一段：站内可自动生成面向大语言模型的站点清单，回答「有什么、在哪」；Markdown 协商回答「这一页现在给我纯文本」。一个管地图，一个管单页呈现。若站点通过 MCP 等接口对外暴露内容能力，还能让外部智能体走结构化调用而不是纯抓取。

常见问题

问：不改动源站就能让智能体拿到纯文本吗？ 答：用边缘代做的方案可以，源站不改代码；但清理范围、体积上限和返回结构由转换方决定，控制粒度有限。

问：转换会不会破坏原有安全策略？ 答：安全与缓存类响应头一般透传保留，原有策略仍生效；被移除的是长度、实体标识与修改时间这类头，依赖它们做校验的链路需要调整。

问：已经有了页面级纯文本协商，还要模型说明文件吗？ 答：要，两者不重叠。协商是单页按需转换，模型说明文件是全站内容地图，抓取方先看地图再逐页请求，配合才完整。