AI Agent 读网页很多时候是在花钱买垃圾。HTML 页面里真正对任务有用的信息可能只占几个百分点其余全是导航、脚本、样式和布局代码。Agent 每访问一个页面都要为这些无关内容支付一次 token 成本页面一多成本就变得相当可观。最近 Hacker News 上有一个项目很有意思标题也很直接Turn any website into a CLI for AI agents号称比原始 HTML 少消耗 142 倍 token。我第一反应是“又是个标题党”但仔细想了想这个方向其实戳中了很多 AI Agent 落地时真正头疼的问题不是模型不够聪明而是喂给模型的网页太“脏”。这篇文章我会从三个层面展开先讲清楚为什么 HTML 对 Agent 来说这么“贵”再拆解 Website-to-CLI 这种思路的核心原理和实现路径最后给出在真实项目中接入这类方案时的对比建议、常见坑和最佳实践。1. 这篇文章真正要解决的问题先问一个问题你让 AI Agent 去查一个商品价格、读一篇文档、或者从某个管理后台提取数据Agent 第一步做什么大部分情况下它是直接抓取网页 HTML把整段内容塞给大模型。小页面还好几 KB 几十 KB 的 HTML 不算什么一旦遇到电商页面、SaaS 控制台、数据看板这类“浑身都是脚本和埋点”的站点一个页面可能轻松上到几百 KB甚至几 MB。这里出现的第一个问题是成本。按照 token 的换算逻辑1 个英文字符大约对应 0.25 到 0.3 个 token一个 500 KB 的 HTML 页面换算下来大概是 12 万到 15 万 token。当前主流模型每百万 token 输入价格从几美元到几十美元不等Agent 跑一个多步骤任务光读取页面就能消耗掉大量预算。第二个问题是噪音。HTML 里含有script、style、svg、iframe、注释、埋点代码、CSS 类名……这些内容对大模型理解页面语义没有任何帮助反而会干扰生成结果。你可以理解为让一个人去一栋堆满杂物的房间里找一个特定文件他不是找不到而是找得很慢、很容易被无关东西带偏。第三个问题是结构不稳定。很多现代网站是 JavaScript 动态渲染的直接抓 HTML 拿不到核心内容必须用无头浏览器。而无头浏览器渲染出来的 DOM 又特别庞大进一步加剧 token 浪费。这个问题如果用一个工程术语来概括就是“给 Agent 的输入形态不对”。HTML 是给人眼和浏览器设计的不是给大模型做推理设计的。项目想做的一件事就是把这个输入形态从“完整的网页源码”变成“紧凑的结构化命令接口”——也就是把网站变成 CLI。2. 基础概念Website-to-CLI 到底是什么意思传统的网页使用方式是浏览器访问CLI 的使用方式是命令交互。把网站变成 CLI并不是说要在终端里模拟出一个浏览器而是指把一个网站的核心功能提取出来描述成一组可执行的命令、参数和说明文本让 AI Agent 通过读取这段紧凑的文本就能理解“这个网站能做什么、怎么做”然后调用对应命令获取结果。举个最简单的场景。假设有一个天气网站原始 HTML 页面可能是 200 KB包含大量 CSS、图片链接、广告脚本。变成 CLI 之后它的“说明书”可能长这样weather-cli - 查询全球主要城市天气 用法: weather-cli get --city 城市名 查询指定城市当前天气 weather-cli forecast --city 城市名 --days 1-7 查询未来几天预报 weather-cli alerts --region 地区代码 查询气象预警 示例: weather-cli get --city Beijing weather-cli forecast --city Shanghai --days 3 输出格式: JSON包含 temperature, humidity, wind_speed, condition 等字段这段说明文字可能只有 300 个 token而原始 HTML 需要 3 万甚至更多的 token。这就是题目里“142x fewer tokens”想表达的意思——不是每个网站都能压缩这么多但结构性越强、包含越多模板代码的页面压缩比就越显著。从技术性质来看Website-to-CLI 并不是一个全新的概念它更像是三种老思路的结合API 网关思想把网页能力包装成标准接口隐藏后端复杂性。文档生成思想像man page一样为每个网站生成一份给机器读的手册。MCP 工具注册思想让 Agent 知道有什么工具可以用、怎么用。区别在于API 网关需要网站方提供接口而 Website-to-CLI 是从已有网页中提取接口描述。这更像是一种“逆向 API 工程”。为什么这个方向对 AI Agent 特别重要因为 Agent 不能像人一样“看”网页它必须先把网页转成文本才能理解。而 HTML 是人类和机器之间的妥协产物——浏览器可以渲染它但大模型不需要那些渲染信息。CLI 格式相当于把“渲染后的结果”和“操作方式”直接抽出来省去了大模型自行理解 DOM 的负担。3. 为什么 HTML 对 Agent 来说如此“昂贵”项目标题里的 142x 虽然是一个具体数字但它背后反映的是一个通用规律。我们可以从三个维度来看 HTML 为什么贵。3.1 信息密度极低一份标准的 HTML 文档通常包含doctype、html、head、meta、link、script、style、body等结构。其中大部分内容不是业务数据而是页面框架和布局代码CSS 样式定义JavaScript 逻辑和埋点图片地址和媒体资源SEO 元信息广告和推荐位占位社交分享组件真实业务数据通常只占全文的很小比例。给大模型喂整个 HTML等于让它在噪音里找信号。3.2 DOM 结构冗余同样一段文本在 HTML 里可能被包裹在很多层级里div classproduct-wrap div classproduct-info div classproduct-info__main span classproduct-price¥199/span /div /div /div这段代码真正有用的只是¥199这个价格。但大模型要读完所有标签、类名、层级关系才能定位到它。如果页面里有一百个商品这个冗余量就放大一百倍。3.3 动态渲染的额外代价现在的网站大量使用前端框架很多内容需要执行 JavaScript 之后才能在 DOM 里出现。这意味着 Agent 要做的事情更重启动无头浏览器加载页面等待异步请求完成序列化渲染后的 DOM再把 DOM 转成 markdown 或纯文本给模型每一步都有时间成本和 token 成本。而 Website-to-CLI 的思路是提前把网站的核心能力分析清楚生成一份静态的、紧凑的操作手册Agent 拿到手册后按命令执行即可不需要每次重新解析整个页面。这里有一个容易误解的地方不是说以后 Agent 完全不能碰 HTML而是说高频、重复、结构固定的网页访问场景应该走 CLI 化通道低频、开放性的网页浏览才值得直接读 HTML 或者用视觉模型。4. 传统方案与 Website-to-CLI 的对比现在 AI Agent 对接网页常见的有几种方案各有优劣。方案基本思路Token 消耗结构完整度适用场景HTML 全文直接喂给模型抓取源码交给模型理解很高完整但噪音大原型、一次性任务HTML 转 Markdown用工具抽取正文转为 md中等丢失部分结构新闻、博客、文档无头浏览器 视觉模型截图给模型看高视觉完整细节不可靠复杂页面、登录态页面站点 API 对接使用官方接口低最可靠但站点不一定提供有公开 API 的场景Website-to-CLI提取能力为命令接口很低保留核心操作去除展示层高频访问、操作型网站值得展开对比的是 Website-to-CLI 和“HTML 转 Markdown”的区别因为它们看起来相近但设计目标完全不同。HTML 转 Markdown 的目标是“保留正文可读性”它适合文档、博客、新闻但面对 SaaS 控制台、数据后台这类需要“操作”的页面它就无能为力了。你无法通过一段 markdown 去让 Agent 完成“查询订单状态”或“创建新的部署任务”。Website-to-CLI 的目标是“让 Agent 能操作系统”。它输出的不是一篇阅读材料而是一组命令。Agent 理解“这个网站可以执行哪些操作、需要哪些参数”之后通过执行命令来完成任务。从交互模式上看它更像 API而不是文档。另外还要注意到 MCP 协议的发展。MCPModel Context Protocol模型上下文协议解决的问题是“Agent 如何接入工具”。Website-to-CLI 做成 CLI 之后可以通过 MCP 的 tool 包装层快速接入 Agent这是两者天然契合的地方。5. 技术原理怎么把任意网站变成 CLI这个项目没有公开完整的源码细节但我们可以基于“功能提取 命令生成”的通用实现思路来拆解它大概需要几步。5.1 第一步站点分析与功能识别要让一个网站“变成 CLI”首先得知道这个网站能做什么。常见路径是抓取首页和主要子页面分析链接结构识别页面中的表单、按钮、搜索框等交互元素根据页面 URL 规律推断资源类型比如 GitHub 仓库页面的链接规律是/owner/repoIssue 列表是/owner/repo/issues一个简单的 CLI 描述就可以把这三层拆成三个子命令。5.2 第二步命令与参数设计这一步是把“网站的交互方式”翻译成“CLI 的交互方式”。核心原则是一个页面或一个操作对应一个子命令页面里的筛选条件、分页参数对应命令的选项表单输入对应命令参数输出结果统一为 JSON比如一个典型电商网站CLI 可能是这样设计的shop-cli ├── search --keyword 关键词 --page 页码 ├── product --id 商品ID ├── cart --action add --product-id 商品ID --qty 数量 ├── checkout --address 地址 --payment 方式 └── order --id 订单ID这个命令列表的定义过程其实就是对网站做一次“接口抽象”。5.3 第三步紧凑文本渲染命令设计好之后要把它们渲染成一段适合大模型读的文本。这个文本的目标是用最少的 token让模型知道这个 CLI 怎么用、能返回什么。一个紧凑的 CLI 描述包括命令层级参数和值域输出格式说明一个或两个典型示例不需要完整的英文长句用类似 man page 或 help 命令的格式即可。5.4 第四步命令执行层这一步是真正去操作网站获取数据。实现方式通常有两种如果网站有公开或可逆推的 API直接请求对应的 JSON 接口如果没有 API则需要用无头浏览器自动化操作页面需要明确的是第四步的复杂度取决于目标网站本身。如果一个网站完全靠 JavaScript 渲染并且没有稳定的内嵌 API那么即便生成了 CLI 描述执行层依然要依赖浏览器自动化只是 Agent 的调用入口变得更干净了。6. 一个最小化示例演示 Website-to-CLI 的效果虽然我们无法直接运行这个项目的代码但“把页面变成 CLI 描述”的核心思路可以用一个最小示例来演示。假设我们要让 Agent 查询某一个文档站点的内容。原始 HTML 可能是这样的结构已大幅简化!DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 titleAPI 文档 - 获取用户信息/title link relstylesheet href/assets/main.css script src/assets/app.js/script /head body nav classsidebar ul lia href/docs文档首页/a/li lia href/docs/auth认证/a/li lia href/docs/users用户/a/li lia href/docs/orders订单/a/li /ul /nav main classcontent h1获取用户信息/h1 p通过用户 ID 获取指定用户的公开信息。/p h2请求方式/h2 precodeGET /v1/users/{id}/code/pre h2参数/h2 table trth名称/thth类型/thth必填/thth说明/th/tr trtdid/tdtdstring/tdtd是/tdtd用户 ID/td/tr trtdfields/tdtdstring/tdtd否/tdtd返回字段列表/td/tr /table h2返回示例/h2 precode{id: u_123, name: Alice, email: aliceexample.com}/code/pre /main /body /html如果直接把这个 HTML 喂给模型token 消耗主要花在标签和类名上。而如果转换成 CLI 描述内容会变成docs-cli - API 文档查询 用法: docs-cli page --path 路径 查询文档页面 docs-cli search --keyword 关键词 搜索文档 页面内容: 路径: /docs/users 标题: 获取用户信息 说明: 通过用户 ID 获取指定用户的公开信息。 接口: GET /v1/users/{id} 参数: id string 必填 用户 ID fields string 可选 返回字段列表 返回示例: {id: u_123, name: Alice, email: aliceexample.com}如果再把这份描述转成 JSON 传给 Agent会更加结构化{ command: docs-cli page --path /docs/users, page_title: 获取用户信息, api: { method: GET, path: /v1/users/{id} }, params: [ {name: id, type: string, required: true, desc: 用户 ID}, {name: fields, type: string, required: false, desc: 返回字段列表} ], response_example: { id: u_123, name: Alice, email: aliceexample.com } }对比一下 token 数。上面的 HTML 源码大约有 1.5 KB转换为纯文本后的 token 数大约是 400 到 500 个而 CLI 描述版本大约只有 150 到 200 个 token。如果是完整的大型网站页面差距会被放大到几十倍甚至上百倍。这就是项目标题里“142x fewer tokens”的直观来源。在网络热词里“HTML 转换”相关的搜索量一直很高其实很多开发者都已经意识到 HTML 存在大量冗余只是一直缺少一种“面向 Agent 的转换目标格式”。Markdown 是面向阅读的JSON 是面向数据的而 CLI 是面向操作的。Website-to-CLI 这个方向正好补上了“操作接口”这个位置。7. 实际接入Agent 如何调用这类 CLI要让 Agent 使用一个网站 CLI通常有三种接入方式。7.1 方式一作为工具函数直接调用如果 Agent 运行框架支持自定义工具可以把 CLI 的每个子命令注册为一个工具函数。例如在 Python 中import subprocess import json def docs_cli_search(keyword: str) - dict: 搜索文档站点内容 result subprocess.run( [docs-cli, search, --keyword, keyword], capture_outputTrue, textTrue, timeout30 ) if result.returncode ! 0: return {error: result.stderr} return json.loads(result.stdout)然后把这个函数作为 tool 注册给 Agent 框架模型就会在需要时自动调用它而不是自己去抓网页。7.2 方式二通过 MCP 包装MCP 协议现在是 Agent 工具接入的主流标准。通过 MCP 的 stdio 传输方式可以直接把一个 CLI 包装成 MCP 工具。思路是Agent 与 MCP server 用 JSON-RPC 通信MCP server 再调用 CLI 命令。这种方式的好处是Agent 框架只需要按规范实现一次就能接入任意符合规范的 CLI 工具不需要为每个网站写定制逻辑。7.3 方式三给 Agent 一段“使用说明”最轻量的方式是把 CLI 的帮助文本直接作为上下文给模型。比如在 System Prompt 里写你可以通过调用 docs-cli 来查询文档网站内容。 用法: docs-cli page --path 路径 docs-cli search --keyword 关键词 示例: docs-cli search --keyword 用户信息模型读到这段说明后如果框架支持执行代码它就会自己在终端里调用docs-cli命令。这种方式对框架要求最低也是最快验证“CLI 化思路”是否有效的方式。从开发趋势看2025 年以来国内外的 Agent CLI 工具热度一直在上升。Codex CLI、Claude Code 这类编程 Agent 天然就是终端环境它们最喜欢的就是命令式工具而不是需要解析 HTML 的内容抓取。Website-to-CLI 这类项目正好契合了这个趋势。8. 常见问题与排查思路问题现象可能原因排查方式解决方案CLI 描述生成后Agent 调用报错生成的命令参数与源站不匹配查看实际抓取的页面检查表单和 URL 参数名工具链中增加站点结构变更检测定时重新生成 CLI 描述网站改版后 CLI 命令失效页面结构变化功能提取结果过期对比改版前后的页面源码建立页面结构指纹变化时触发重新生成输出 JSON 不完整或被截断调用超时、输出有非法字符检查 stdout 大小和退出码增加超时处理格式化原始输出为 JSON登录后才能获取数据未处理 Cookie、Token 等认证检查请求是否携带认证信息接入统一凭据管理由 CLI 执行层处理认证不把敏感信息给模型动态渲染页面拿不到数据请求的数据依赖 JavaScript 执行用无头浏览器单步调试降低频率使用浏览器渲染入口并缓存结果关于认证这一点需要特别提醒如果你的网站 CLI 需要登录设计时应该把认证信息放在 CLI 工具这一层让 Agent 只负责传业务参数而不是把完整 Cookie 或 API Key 放进上下文里。这样既降低了 token 消耗也减少了敏感信息泄露的风险。另外一个很容易踩的坑是不要对所有网站都做 CLI 化。很多站点一次性的、低频的页面直接抓取 markdown 或 HTML 反而更简单。CLI 化应该专注于那些 Agent 会高频访问、操作路径固定、重复调用价值高的网站比如内部的运维平台、数据平台、项目管理后台。9. 最佳实践与工程建议如果要在自己的项目里落地“网站转 CLI 给 Agent 用”这个思路下面几条建议可以直接参考。9.1 优先做高频、低复杂度的网站不需要一上来就挑战大型 SaaS。先从结构清晰的公司官网、文档站点、内部工具页面开始把流程跑通。一个页面能稳定生成可用的 CLI 描述再扩展到第二个页面比“做了一大堆用不了”要强得多。9.2 保持输出格式稳定无论目标是哪种格式CLI 描述都应该保持稳定结构。建议至少包含命令名称参数列表参数类型与是否必填输出格式一个示例输出稳定Agent 才能稳定。如果每次生成的 CLI 格式都不一样模型每次都要重新理解token 优势就会被吃回去。9.3 建立失效检测机制网站改版是常态。建议定期对已生成的 CLI 进行“冒烟测试”调用一次核心命令确认返回结果非空、结构符合预期。一旦失败自动标记为失效并触发重新生成而不是等 Agent 调用时报错才发现。9.4 缓存结果减少重复抓取同一个页面的 CLI 描述如果网站结构没有变化就不需要每次重新生成。把生成结果按 URL 做缓存带有 hash 校验能显著降低成本和延迟。9.5 注意授权与合规边界必须强调一点把某个网站转成 CLI 并给 Agent 自动调用这个行为本身需要你有权访问该网站并且符合网站的服务条款。尤其是涉及登录、交易、后台管理等敏感操作的网站更要谨慎。内部系统优先公开数据站点次之涉及隐私和资金操作的网站不建议在没有明确授权的情况下做自动执行。9.6 结合 MCP 和 Agent 框架演进不要把自己的实现绑定死在某一个 Agent 框架上。优先把 CLI 描述输出为“工具层”再通过 MCP server 或 stdout 暴露给上层 Agent。这样未来换 Agent 框架、换模型都不需要重新做一遍网页解析。10. 总结与后续学习方向Website-to-CLI 这个项目最值得关注的不是那 142 倍的 token 节省数字而是它揭示了 AI Agent 与网页交互的一个新方向Agent 不需要“读”网页Agent 需要的是“操作”网页的接口。从实践角度来看如果你正在开发 Agent 应用并且发现 token 成本高企、网页解析不稳定可以往这个方向想一想能不能先把高频访问的网站抽象成一组命令不需要一开始就做一个通用工具先从你自己的内部系统、文档库、常用数据页面开始做成半自动化的 CLI 提取流程就能看到明显的收益。后续可以继续深入的方向包括学习 MCP 协议了解如何把自有工具包装成 Agent 可调用的标准接口研究网页结构识别算法提升自动提取功能的准确性了解无头浏览器的高效调度方式解决动态页面的执行成本问题关注更多 Agent 原生的工具链追踪行业对“网页交互”这一问题的标准化尝试这个领域的核心矛盾是把人友好的网页界面改造成机器友好的操作接口。HTML 会继续存在但 AI Agent 会更倾向于命令、JSON、MCP 这类结构化协议。对开发者来说提前把一部分常用网站的“CLI 化”做起来就是在为 Agent 时代的工程化做储备。