HTML才是AI代理需要的格式

2026年5月8日，在Anthropic从事Claude Code工作的工程师Thariq Shihipar发布了一个个人网站，收录了代理在9类知识工作中生成的20个HTML成品。他的论点很明确：当答案承载空间结构、交互或视觉证据时，HTML胜过Markdown。¹²

对于代理输出，HTML优于Markdown，因为空间结构、交互和视觉证据承载着线性文字会压平的信息。代理输出的格式，就是人类用来检查它的控制界面，而不是包裹它的外层容器。

这篇文章发布6天后，5月14日的一篇arXiv论文指出，代理搜索质量取决于执行环境，而不是检索器。³两者呈现出同一种模式：格式和执行环境是底层基础，不是外层包装。只有当组件周围的界面能把模型输出转化为可验证内容时，组件本身才真正有意义。

TL;DR

Thariq Shihipar发布了一个配套网站，展示20个HTML示例，覆盖代码审查、设计系统、原型制作、探索、图表、研究、报告和编辑器界面等场景。¹核心论点是：Markdown会把原本以空间方式呈现的信息线性化。差异对比、调用图、并排比较和交互式原型都承载意义，而纯文字会把这些意义压平。8K-token的GPT-4发布时代让Markdown成为节省token的默认选择；如今Claude上下文窗口文档列出了200K-token和1M-token模型，许多成品尺寸下的取舍已经改变。⁴⁵对于FastAPI加HTMX这类服务器渲染、无构建Web技术栈，这篇文章给出了代理侧的理由：HTML是模型想要生成的格式，也是浏览器本来就能渲染的格式。绕道Markdown会多出一次转换，并在两端都损失保真度。⁶

关键要点

给代理构建者： - 当答案是比较、差异、流程图或可导航结构时，不要再默认使用Markdown输出。直接要求HTML，让代理明确给出空间布局。¹ - 把模型输出格式视为工具界面的一部分。一个已渲染的成品，比一段不断滚动过去的转录文本更便于检查。⁷

给界面设计师： - HTML就是您的设计系统已经交付的媒介。先转成Markdown会引入一次失真转换，渲染时又要再转换一次。¹ - 代理生成什么，什么就是控制界面。如果人类看不到代理看到的内容，这个界面就是坏的。⁷

给运行服务器渲染无构建技术栈的团队： - 选择HTML而不是构建流水线，如今也得到了代理侧的验证。模型想生成的格式，与浏览器已经能渲染的格式，是同一个。⁶ - 服务器渲染网站会移除两层转换：一层在构建步骤，一层在代理输出步骤。两者叠加，收益会放大。

Thariq真正主张了什么

Shihipar在Anthropic从事Claude Code工作；这篇文章发布在他的个人网站上，而不是Anthropic官方博客。²配套示例集包含20个由代理生成的独立HTML文件，分为9类工作。在这些场景中，HTML从结构上胜过Markdown。¹

他的核心主张如下：

第二条主张对任何构建Web基础设施的人都最关键。如果设计系统交付的是HTML，代理就应该生成HTML。其他做法都会引入有损的往返转换。

这20个示例本身就是论证

Shihipar示例集中的类别，覆盖了现在大多数人会交给编码代理处理的工作：¹

• 代码审查：带严重程度编码内联备注的差异；高亮调用路径的模块图。
• 探索：并排展示的代码方案；可直接选择的视觉设计选项，而不是只能按顺序阅读。
• 设计：可运行的设计系统页面；真正渲染各个变体的组件变体表。
• 原型制作：带真实缓动曲线的动画沙箱；能响应点击的交互流程。
• 图表：内联SVG图形；带注释的流程图；框线式架构草图。
• 研究：可折叠章节；带现场演示的交互式概念解释器。
• 报告：结构本身承载意义的格式化时间线和图表。
• 编辑器：把导出功能嵌入成品的自定义界面。

每个示例都是模型一次性生成的HTML页面。共同模式是：答案具有空间性或交互性，而渲染后的成品保留了Markdown回应只能用文字描述的内容。

为什么默认格式曾经是Markdown

Markdown之所以成为代理输出的默认选择，有两个原因，但它们已经不再成立。

第一，在聊天输出惯例成形的时期，GPT-3.5和GPT-4一代的上下文窗口通常只有4K到8K。⁴Markdown的简洁确实是一种硬约束：花在<div class="...">上的一个token，就不能再用于分析。Claude当前上下文窗口文档显示，许多模型已有200K-token上下文，Opus 4.1和Sonnet 4.6则有1M-token上下文。⁵对于许多审查型成品而言，token效率这一论据已经减弱。

第二，终端渲染器和聊天窗口可以轻松渲染Markdown，而HTML需要Webview或浏览器标签页。即使token论据已经失效，界面便利性仍让Markdown保留为阻力最小的路径。

Shihipar的文章之所以有分量，是因为作者在Anthropic从事Claude Code工作。那20个示例是具体成品，而不是抽象论断。²Simon Willison同一天的报道也复现了这一模式：一个Linux安全漏洞解释器被渲染成了交互丰富的HTML页面，而不是Markdown说明文。⁸

HTML保留了什么，而Markdown丢掉了什么

论证依赖4个属性：

每个属性都对应一类代理任务。一旦把输出压平成文字，这些任务就会变难。差异是空间比较，流程图是图结构，设计系统审查是视觉判断。强行塞进Markdown，相当于要求读者重建渲染器本来可以直接展示的东西。

与执行环境的关系

代理搜索质量取决于执行环境，而不是检索器。那篇文章主张，检索方法不如周围的代理框架重要：提示形态、工具界面、转录格式、结果交付、重试行为。³

HTML论点把同一框架延伸到输出层。模型可以用任何格式生成正确答案。但您要求的格式，是执行环境契约的一部分。不同格式会产生不同的可验证界面：

• Markdown交付：用户从头读到尾，自行判断重点，并在脑中重建结构。
• HTML交付：模型承诺一种结构，渲染器让结构便于扫读，用户进行检查，而不是通读。

同样的数据，不同的控制界面。代理式设计就是控制界面设计。代理输出的格式属于这个界面的一部分，而不是外层包装。⁷

这对无构建技术栈意味着什么

本站关于FastAPI加HTMX的指南主张用服务器渲染HTML替代JavaScript构建流水线。⁶Shihipar的文章补上了代理侧论据：

• 模型想生成HTML。
• 浏览器想渲染HTML。
• 在两者之间插入Markdown或JSX，会增加两次有损转换。

无构建的服务器渲染网站移除了构建时转换。代理直接生成HTML，则移除了输出时转换。叠加后的收益是：同一种格式可以从模型经过路由一路进入浏览器，中间无需其他形态。

这并不是说React或Markdown在所有场景都错。重点在于，转换步骤的成本如今已经从两端同时显现；能避开两端转换的技术栈，会按比例变得更简单。

格式重要。执行环境重要。二者都是底层基础。

代理搜索论文和HTML文章相隔8天发布，却呈现出同一种论证形态：¹³

• 检索器是组件。执行环境是底层基础。
• 模型是组件。输出格式是底层基础。

组件思维不断提供局部升级：更换检索器、添加记忆、替换模型、优化提示。底层基础思维则改变用户看到的界面，以及代理生成的界面。本周这两项发现，都把工作推向了第二种框架。

实际做法很简单：当代理答案承载空间信息时，要求输出HTML。当代理运行在框架中时，先对框架做观测，再对模型做观测。两者会相互放大。单独任何一个都不是万能药。

FAQ

这篇文章是Anthropic发布的吗？

不是。Thariq Shihipar把它发布在自己的个人网站thariqs.github.io/html-effectiveness/上。¹他在Anthropic从事Claude Code工作，因此权威信号很强，但这篇文章不是Anthropic的官方发布。²

这个论点适用于所有代理任务吗？

不适用。文章明确针对的是空间结构、交互或视觉证据承载意义的工作。对于简短事实回答或受限于终端的输出，Markdown仍然是不错的默认选择。¹

token成本怎么办？

Markdown的成本优势与小上下文窗口绑定。Claude当前上下文窗口文档列出了200K-token和1M-token模型，这改变了文章中那些成品尺寸下HTML更冗长所带来的取舍。⁵

这会破坏Claude Code现有的Markdown默认行为吗？

不会。这个论点讨论的是您按需要求模型生成、用于审查的输出，而不是转录文本或终端输出。仍然可以在单个提示中要求HTML，并获得一个自包含成品。¹

这与代理搜索执行环境论文有什么关系？

两个论点都指向模型周围的底层基础，而不是模型本身。搜索质量取决于代理框架；输出质量取决于格式。组件是必要的；底层基础让组件变得可靠。³

使用FastAPI加HTMX的团队应该怎么做？

把HTML视为所有AI功能的一等输出目标。同一种格式可以从模型经过路由进入浏览器，而无构建技术栈本来就已经为这条路径做了优化。⁶

参考资料