# I tried letting my scheduled agents deliver only HTML, and I'm not going back
**作者**: Vox
**日期**: 2026-05-19T15:45:08.000Z
**来源**: [https://x.com/Voxyz_ai/status/2056763091052843350](https://x.com/Voxyz_ai/status/2056763091052843350)
---

A couple weeks ago Thariq published "Using Claude Code: The Unreasonable Effectiveness of HTML," and it hit 12.6M views. His argument: Markdown has become the bottleneck for agent output, and he's almost completely switched to HTML.
I read it at the time and shrugged. Markdown is simple, diffable, greppable, cheap on tokens, and easy to hand off between agents. I figured this was a taste thing, not worth touching, and I left it alone.
Then yesterday I came across a repo called html-anything. The tagline: "Markdown is the draft, HTML is what humans read." That hit a nerve. So I just tried it, lol.
Today I changed the output format on a few cron jobs inside X Manager (the X content management agent I run myself). Instead of pasting Markdown into Telegram, each job now delivers one HTML report. I expected this to be heavy: new rendering scaffolding, storage paths to wire up, maybe a rebuild of the downstream review flow. I even ran a benchmark first.
Turns out the entire cost was 51ms of extra render time per run.
Way easier on the eyes.
## The original mess

My X Manager cron runs more than a dozen stages a day: scan timeline, check mentions, aggregate key accounts, generate draft packs, surface decisions for me. After each stage, the agent dumps about 2,000 words of source data, cron history, risks, and next actions into Telegram all at once.
The content was all correct. The problem was I couldn't read it. The chat turned into one long wall of text, important state buried, and the next stage had to guess what the previous one said.
At first I thought it was a length problem and wanted to give the agent stricter summary constraints. After a while I realized output length was secondary. The real block was that the chat surface itself wasn't supposed to be doing this job. I also really wanted every final decision to be mine, which meant I had to actually read all the output. Telegram is an IM tool, built for 5-line notifications. Cramming a 2,000-word technical report into it just breaks it.
My blind spot was never really about Markdown itself. Markdown as source is fine. The problem was I'd been using it as a review surface, forcing myself to read long Markdown reports the agent generated. That drains real energy.
## The new delivery contract

I changed the output contract for the agent's cron jobs. Each real run now produces three things:
- A 5-line chat summary into Telegram: verdict, stage state, next action. Nothing more.
- A persistent Markdown file under content/memory/daily/, the source of truth and the input for the next agent.
- An HTML report into the gateway's outbound directory, the review surface for humans.
Markdown stays the source. HTML is for humans. Telegram is just for notifications.
## The 51ms cost

I benchmarked it on the 12:30 stage. Source Markdown 22.4KB, local read in 0.000016 seconds, Markdown-to-HTML render in 0.0508 seconds. That works out to about 51ms extra per run.
For an agent task that runs for minutes, that overhead is below the noise floor.
I thought the expensive part would be the rendering. Turns out rendering is only tens of milliseconds. What was actually eating my energy was the cognitive cost of opening Telegram every day and staring at that wall of text. My brain felt like mush by the end of the day.
## Markdown and HTML do different jobs

Once that clicked, the rule was clear:
- Markdown is the source. The next agent reads it, greps it, indexes it, version-controls it.
- HTML is the handoff. Humans open it, scan it, forward it, confirm the next step.
Use both, and one agent run leaves behind two things: the source material, and a finished product humans can read directly.
## Pretty HTML isn't enough. You need an artifact contract.

Just rendering the output as HTML isn't enough. A usable agent report has to preserve these fields:
- Source chain: what the previous stage saw and which sources it used.
- The latest direction from the user that day.
- Current stage state.
- Risks and factual guardrails.
- Budget and tools used.
- Whether public actions need confirmation (this one matters a lot to me, since posting on X requires my manual approval).
- Next action.
Pretty HTML plus this contract is what counts as delivery. Without the contract, you've just got a nicely formatted piece of waste paper.
## The same rule for any long-running agent

I ended up applying this rule to every scheduled agent I run. Claude Code on long tasks, Codex on batch refactors, subagents on multi-step reasoning. Anything where the run takes more than a minute or two shouldn't end with a wall of text in a chat box.
It should be an artifact contract. Three pieces:
- Source = Markdown
- Report = HTML
- Summary = chat
## Where I landed

I thought figuring out a new framework would eat my whole afternoon. The actual work: change the cron output function, add an HTML template, write the artifact to the outbound directory. Three steps. 51ms of extra render per run, and the most annoying part of my day is gone.
Reading the output now feels great.
I'm not going back.
Everything I'm writing as I build: voxyz.ai/insights.
## References
- Thariq, "Using Claude Code: The Unreasonable Effectiveness of HTML," X, 2026-05-08.
- html-anything: github.com/nexu-io/html-anything.
## 相关链接
- [Vox](https://x.com/Voxyz_ai)
- [@Voxyz_ai](https://x.com/Voxyz_ai)
- [42K](https://x.com/Voxyz_ai/status/2056763091052843350/analytics)
- [html-anything](https://github.com/nexu-io/html-anything)
- [voxyz.ai/insights](https://voxyz.ai/insights)
- [Using Claude Code: The Unreasonable Effectiveness of HTML," X, 2026-05-08](https://x.com/trq212/status/2052809885763747935)
- [github.com/nexu-io/html-anything](https://github.com/nexu-io/html-anything)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:45 PM · May 19, 2026](https://x.com/Voxyz_ai/status/2056763091052843350)
- [42.1K Views](https://x.com/Voxyz_ai/status/2056763091052843350/analytics)
- [View quotes](https://x.com/Voxyz_ai/status/2056763091052843350/quotes)
---
*导出时间: 2026/5/20 13:38:29*
---
## 中文翻译
# 我试着让我的定时代理只输出 HTML,我回不去了
**作者**: Vox
**日期**: 2026-05-19T15:45:08.000Z
**来源**: [https://x.com/Voxyz_ai/status/2056763091052843350](https://x.com/Voxyz_ai/status/2056763091052843350)
---

几周前,Thariq 发表了《使用 Claude Code:HTML 的非同凡响的效果》,这篇文章获得了 1260 万次浏览。他的观点是:Markdown 已经成为代理输出的瓶颈,他几乎完全转向了 HTML。
我当时读了一下,耸了耸肩。Markdown 简单、可比较、可搜索、token 成本低,而且易于在代理之间传递。我认为这只是个人口味问题,不值得折腾,也就没管它。
然后昨天,我偶然发现了一个叫 html-anything 的仓库。它的标语是:“Markdown 是草稿,HTML 是人类阅读的。”这戳到了我的痛点。于是我就试了一下,哈哈。
今天,我修改了 X Manager(我自己运行的 X 内容管理代理)中几个定时任务的输出格式。不再是往 Telegram 里粘贴 Markdown,每个任务现在会交付一份 HTML 报告。我预想这会很麻烦:需要新的渲染脚手架,要配置存储路径,可能还需要重建下游的审核流程。我甚至还先跑了一个基准测试。
结果发现,全部的额外成本仅仅是每次运行增加了 51 毫秒的渲染时间。
看着舒服多了。
## 原本的乱局

我的 X Manager 定时任务每天要跑十几个阶段:扫描时间线、检查提及、聚合关键账号、生成草稿包、向我展示决策。每个阶段之后,代理会将约 2000 词的源数据、定时任务历史、风险和后续动作一次性全部丢进 Telegram。
内容都是正确的。问题在于我根本读不下来。聊天界面变成了一堵长长的文字墙,重要的状态被淹没,下一阶段只能靠猜上一阶段说了什么。
起初我以为这是个长度问题,想给代理设定更严格的摘要限制。过了一会儿我意识到,输出长度是次要的。真正的障碍在于,聊天界面本身就不是为了干这活儿设计的。而且我真的希望每一个最终决策都由我做出,这意味着我必须读完所有的输出。Telegram 是个即时通讯工具,是为五行通知设计的。硬塞进一份 2000 词的技术报告,只会把它搞得一团糟。
我的盲点其实从来不在 Markdown 本身。Markdown 作为源格式没问题。问题是我一直把它当作审核界面,强迫自己去读代理生成的长篇 Markdown 报告。这真的很消耗精力。
## 新的交付合约

我修改了代理定时任务的输出合约。现在每次实际运行会产生三样东西:
- 一份发到 Telegram 的五行聊天摘要:结论、阶段状态、下一步动作。仅此而已。
- 一个存放在 content/memory/daily/ 下的持久化 Markdown 文件,这是真相的来源,也是下一个代理的输入。
- 一份发到网关出站的 HTML 报告,这是供人类审核的界面。
Markdown 保持作为源文件。HTML 是给人看的。Telegram 只负责通知。
## 51ms 的成本

我在 12:30 的阶段上做了基准测试。源 Markdown 22.4KB,本地读取耗时 0.000016 秒,Markdown 转 HTML 渲染耗时 0.0508 秒。算下来大约是每次运行额外增加 51 毫秒。
对于一个运行数分钟的代理任务来说,这个开销基本可以忽略不计。
我本以为昂贵的部分会是渲染。结果发现渲染只需要几十毫秒。真正消耗我精力的是每天打开 Telegram 盯着那堵文字墙所带来的认知成本。等到一天结束时,我的大脑感觉像一团浆糊。
## Markdown 和 HTML 各司其职

一旦想通了这一点,规则就很清晰了:
- Markdown 是源文件。下一个代理来读取它、搜索它、索引它、进行版本控制。
- HTML 是交付物。人类打开它、浏览它、转发它、确认下一步。
两者都用,一次代理运行会留下两样东西:源材料,以及一份人类可以直接阅读的成品。
## 漂亮的 HTML 还不够。你需要一份工件合约。

仅仅把输出渲染成 HTML 是不够的。一份可用的代理报告必须保留这些字段:
- 源链路:上一阶段看到了什么以及它使用了哪些源。
- 当天用户给出的最新指令。
- 当前阶段状态。
- 风险和事实护栏。
- 预算和使用的工具。
- 公开操作是否需要确认(这对我很重要,因为在 X 上发帖需要我手动批准)。
- 下一步动作。
漂亮的 HTML 加上这份合约,才算得上是交付。没有合约,你拥有的只是一张格式精良的废纸。
## 任何长时间运行的代理都适用同样的规则

我最终把这条规则应用到了我运行的每一个定时代理上。用于长任务的 Claude Code,用于批量重构的 Codex,用于多步推理的子代理。任何运行时间超过一两分钟的任务,都不该以聊天框里的一堵文字墙作为结束。
它应该是一份工件合约。包含三部分:
- 源文件 = Markdown
- 报告 = HTML
- 摘要 = 聊天
## 我的落脚点

我原以为搞清楚这个新框架会花掉我整个下午。实际的工作量:修改定时任务输出函数,添加一个 HTML 模板,将工件写入出站目录。三步。每次运行 51 毫秒的额外渲染,我一天中最烦人的环节就消失了。
现在读输出感觉好极了。
我不回去了。
我在构建过程中写下的所有东西:voxyz.ai/insights。
## 参考资料
- Thariq,《使用 Claude Code:HTML 的非同凡响的效果》,X,2026-05-08。
- html-anything: github.com/nexu-io/html-anything。
## 相关链接
- [Vox](https://x.com/Voxyz_ai)
- [@Voxyz_ai](https://x.com/Voxyz_ai)
- [42K](https://x.com/Voxyz_ai/status/2056763091052843350/analytics)
- [html-anything](https://github.com/nexu-io/html-anything)
- [voxyz.ai/insights](https://voxyz.ai/insights)
- [Using Claude Code: The Unreasonable Effectiveness of HTML," X, 2026-05-08](https://x.com/trq212/status/2052809885763747935)
- [github.com/nexu-io/html-anything](https://github.com/nexu-io/html-anything)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:45 PM · May 19, 2026](https://x.com/Voxyz_ai/status/2056763091052843350)
- [42.1K Views](https://x.com/Voxyz_ai/status/2056763091052843350/analytics)
- [View quotes](https://x.com/Voxyz_ai/status/2056763091052843350/quotes)
---
*导出时间: 2026/5/20 13:38:29*