表示层优化：为什么 Markdown 是 LLM 时代的语义中间表示

当内容消费者从人类迁移到 AI Agent，表示层本身就成为上下文工程的核心变量。

在上下文工程里，我们经常把注意力放在「写什么」（Prompt）、「取什么」（Retrieval）、以及「如何约束输出」（Format / Eval）。但在 Agent 时代，一个更基础、也更容易被忽视的问题变得关键：

上下文以什么格式进入模型？

Web 世界以 HTML 为基础构建，HTML 的目标是浏览器渲染（presentation + interaction），而不是模型理解（semantic consumption）。当内容消费者从人类用户逐步迁移到 AI crawler 与 agent 时，表示层（Representation Layer）本身就会成为上下文工程的一部分：它直接影响 token 成本、分块边界、embedding 稳定性，以及最终的推理与检索效果。

本节将 Markdown 视为一种 语义中间表示（Semantic IR）：介于纯文本与结构化数据之间、足够表达层级与块结构、同时又具备极高 token 密度的 AI 友好格式。

Token 经济学：表示层决定上下文成本

对大语言模型（LLM）而言，token 是最基本的计费与计算单位。HTML 的结构性冗余会被模型一视同仁地编码进上下文窗口：标签、属性、嵌套容器、导航与脚本等，即便对任务语义没有贡献，也会消耗 token 预算。

以一个简单标题为例，Markdown 的写法通常是：

## About Us

而 HTML 的等价形式往往是：

<h2 class="section-title" id="about">About Us</h2>

差异不在“是否能表达标题”，而在于 HTML 需要携带展示层元数据（class / id），并在真实页面里被大量 wrapper、导航、脚本与追踪代码包裹。对 agent 而言，这些结构不是信息，而是噪声。

更关键的是：token 数量不仅影响输入成本，还会影响推理的整体计算开销。Transformer 的注意力计算在长度维度上会快速增长（工程上可近似理解为随 token 长度显著放大）。因此，当我们把 HTML 转换为 Markdown 并显著降低 token 数量时，得到的不只是成本节省，而是更直接的系统收益：

• 更大的有效语义占比（Semantic Density）
• 更高的上下文窗口利用率（Context Utilization）
• 更低的推理计算压力（Inference Pressure）
• 更可控的截断风险（Truncation Risk）

从上下文工程角度看，表示层是成本模型（Cost Model）的一部分：输入格式选择，会影响你能装进窗口的有效信息上限。

HTML 与 Markdown 的 Token 对比：

如上图所示，HTML 结构中的嵌套标签、属性、导航栏和脚本代码都会消耗大量 token，而 Markdown 仅保留语义内容，实现了约 20 倍的 token 效率提升。

线性语义更契合 LLM：Markdown 是可流式解析的结构

HTML 的本体是树（DOM Tree），它是一种为渲染而设计的层级结构表达；而 LLM 接受的是线性 token 流。虽然模型能够从序列中学习结构，但当结构信息通过成对标签与深层嵌套表达时，模型需要花费更多注意力来重建层级关系，并在噪声中定位语义边界。

Markdown 则天然是线性结构表达：

• 标题层级通过前缀符号显式编码（# / ## / ###）
• 列表、引用、代码块等通过局部标记形成明确块边界
• 不依赖闭合标签，不需要 DOM 还原

这带来的效果是：模型更容易在 token 流中识别"章节—段落—列表—代码"的块结构，并把注意力预算花在内容而不是结构复原上。换句话说：

在 Agent 场景中，这个差异会放大：agent 往往需要在页面中定位特定段落、抽取关键要点、或按标题层级进行导航与总结。Markdown 的结构显式性会显著降低这一类任务的提示复杂度与失败概率。

RAG 视角：Markdown 天然提供分块边界与索引稳定性

即便你不做检索增强生成（RAG，Retrieval-Augmented Generation），任何面向生产的 agent 系统最终都会面临上下文容量限制的现实，从而需要引入：

• 文档切分（Chunking）
• 层级摘要（Hierarchical Summarization）
• 索引与路由（Indexing & Routing）

Markdown 在这一链路上具备天然优势：

分块边界自然存在

标题、列表、代码块等标记本身就是良好的分块边界。相比之下，HTML 需要先经过 DOM 清洗、去噪、正文抽取，才能得到可切分的干净文本。

索引更稳定

HTML 中的 class/id、动态容器与页面布局变动，可能导致抽取结果波动，进而影响 embedding 与索引一致性；Markdown 的结构变动通常更语义化，局部修改更容易被定位，适合增量更新与缓存复用。

更接近作者意图的结构

很多文档作者在 Markdown 中表达的章节、列表与代码块本身就是内容意图。先写 Markdown 再渲染为 HTML 的链路，往往保留了更纯粹的语义结构，这对检索与摘要都更友好。

因此，把 Markdown 作为语义中间层，会让 RAG 与上下文工程的上游处理从文本清洗工程转向语义编排工程。

协议层信号：从 HTML-first 到 Agent-first 的内容协商

当越来越多 agent 在抓取内容时，如何把内容提供给 agent 会从工程技巧演进为协议能力。一个典型方向是通过 HTTP 内容协商（Content Negotiation）让客户端表达偏好，例如请求 text/markdown 作为返回格式。

这类机制的意义不在于又多一种格式，而在于它暗示了一个趋势：

当内容生产端能够直接提供 Markdown（或可稳定转换的语义表示），agent 就可以减少复杂的 DOM 解析、减少转换成本、降低解析误差，并把算力预算投入到更高层的任务规划与工具调用上。

对上下文工程而言，这意味着：你不仅是在做 prompt 与 retrieval，你也在设计一条语义供给链路（Semantic Supply Chain）。

工程实践建议：把 Markdown 放进上下文编译流水线

如果你把上下文工程理解为一个编译模型（Compile Model），那么表示层转换与规范化就是编译前端的一部分。以下是典型的处理流水线：

上下文工程流水线：Markdown 作为语义中间表示

如上图所示，Markdown 作为语义中间表示（IR），连接了原始输入和下游处理。这种架构确保了从输入到输出的一致性，减少了格式转换带来的语义漂移。

• 输入：HTML / PDF / DOCX / logs / API docs
• 规范化：去噪、抽取、结构对齐
• IR：Markdown（或 Markdown-like）
• 下游：chunk / embed / index / route / assemble
• 输出：Markdown（可渲染、可 diff、可复用）

在这个流水线中，Markdown 的价值不是写作格式，而是：

• 最小结构表达：以较低 token 成本显式表达层级与块结构
• 可控变换：便于做 lint、normalize、diff、版本管理
• 端到端闭环：输入 / 输出统一为 Markdown，减少格式转换与语义漂移

你可以把它类比为：源码到中间表示（IR）再到优化 IR 的过程。上下文工程的目标，是在有限窗口与有限预算下，把可行动信息编译进模型的工作记忆中。

总结

当系统的主要消费者从人变成 agent，内容格式会从体验问题变成成本与可靠性问题。HTML 更像渲染协议，JSON 更像数据交换协议，而 Markdown 正在成为一种面向模型与 agent 的语义消费协议。

Markdown 作为语义中间表示，在上下文工程中具备以下核心价值：

• Token 效率：显著降低上下文成本，提高信息密度
• 结构显式性：线性化的语义表达，降低模型解析负担
• 分块友好性：天然的块边界与索引稳定性，适配 RAG 场景
• 协议演进性：从 HTML-first 到 Agent-first 的内容协商新范式
• 工程可控性：端到端的 IR 流水线，减少格式转换与语义漂移