lean-reader

Lean Reader

将任意 URL 转换为精简 token、适合大模型的纯文本，并在每次调用时附上 token 节省凭证。MCP 服务 + 库。

大模型不需要导航栏、Cookie 横幅、<script> 标签或 200 KB 的内嵌 SVG，但原始网页 HTML 会让它们为所有这些内容付费。Lean Reader 会将网页精简为文章内容，并准确告知你节省了多少 token（以及多少钱）。

231,276 → 15,735 tokens (93% saved · 14.7× vs raw HTML · ~$0.54 on gpt-4o) · cleaned by lean reader

用作 MCP 服务

添加到客户端的 MCP 配置中（Claude Desktop/Code、Cursor 等）：

{
  "mcpServers": {
    "lean-reader": { "command": "npx", "args": ["-y", "lean-reader"] }
  }
}

然后，lean_read(url, format?) 工具会返回纯文本和节省凭证。

用作库

import { leanRead } from 'lean-reader/lib/core.js';

const r = await leanRead('https://example.com/article', { format: 'markdown' });
console.log(r.content);   // token-minimized text
console.log(r.receipt);   // { beforeTokens, afterTokens, savedPct, ratio, estCostSavedUsd, ... }

能节省多少？

以实测为准，而非宣传——公开基准测试提供测试语料、分词器和所有原始输出，并标出 Lean Reader 表现较差的情况：

• 与标准提取器 Mozilla Readability 相比，中位数 token 数减少约 29%，同时保留约 99% 的正文。坦诚地说，这一优势来自 minimize 后处理（剔除链接、图片、脚注和空白），而非提取更智能——两者都经过 minimize 处理后，结果大致相当。Lean 实际上也将 Readability 用作两个提取器之一（见“坦诚说明局限”），因此它不会输给 Readability。
• 与原始网页 HTML相比，缩减幅度大得多（中位数约为 8.7 倍；对于已经整洁的博客正文，缩减至约 3.1 倍；对于脚本繁多的文档，则超过 100 倍）——但没人会把这种 HTML 输入大模型，因此应将其理解为“不要直接倾倒原始网页”，而不是竞争优势。
• 与 Jina Reader 相比（实测，匿名层级）：在正文内容相同的情况下，token 数减少约 1.6 倍；若将 Jina 还会返回的导航和引用内容也计算在内，则减少约 4.3 倍。Firecrawl 尚未实测（需要 API 密钥）。

凭证使用 o200k_base 分词器（GPT-4o/4.1 级别）；始终会显示模型和分词器，且计数以原始网页 HTML 为基准，方便你核对计算结果。

坦诚说明局限

• 仅支持静态 HTML（v1）。 对于正文由客户端渲染的网页（部分 SPA、GitHub 仓库主页），返回的内容会很少——Lean Reader 会标记为 partial，而不是输出空文本。Jina/Firecrawl 会渲染 JS，在这类网页上表现会更好。
• 两个提取器，选择正文最多的结果。 Defuddle 和 Mozilla Readability 都会在不同网页上悄悄丢弃正文（Defuddle 会在部分篇幅较长的 Wikipedia 文章上出现此情况，Readability 则会在部分文档/SPA 上出现）。Lean 会同时运行两者，并保留正文内容更多的结果，因此两者的盲点都不会导致内容悄悄丢失。已对 14 个手工标注样本完成 ROUGE-L 真实内容对照测试：参考正文召回率为 0.99，与 Readability 在相同真实内容对照测试中的结果相同，因此字数差距来自噪声清理，而非正文丢失（见基准测试仓库）。
• token 计数使用 o200k_base；Claude/Gemini 的分词方式不同。

开放核心

提取和 token 精简核心（lib/）以及 MCP 服务（src/）采用 MIT 许可。托管服务、分享界面和计量功能则单独提供。

MIT © 2026