AI Agent 读网页太烧 Token？用网站转 CLI 优化交互效率

我最近在调试一个用 AI Agent 批量查资料的小项目。Agent 需要从十几个网站抓取信息第一版实现得很直接把网页 HTML 全部丢给模型让它自己找答案。结果一次请求就烧掉了几万 token其中一半以上都花在了 CSS、JavaScript 和一堆无关的 DOM 节点上。后来我换了一个思路——与其让 Agent 去读网页不如先把网页变成它能直接调用的命令行接口。这个思路来自一个很直接的观察HTML 是给人看的不是给 AI 看的。有一类项目正在做这件事把任意网站转换成 AI 代理可以使用的 CLI项目标题甚至给出了一个很有冲击力的数字——相比直接传 HTML减少了 142 倍的 token 消耗。这个数字是否适用于所有网站我持保留态度但它指向的问题非常真实当我们越来越依赖 Agent 替我们上网时网页的原始格式并不是为机器阅读设计的。这篇文章想聊聊这个思路到底改变了什么实际用起来有哪些收益和坑以及如果你要自己做类似工具应该从哪里下手。1. 先搞清楚AI Agent 读网页钱到底花在哪里了1.1 HTML 的真实体积与有效信息占比现代网页的平均体积可以轻松达到几百 KB。大部分内容不是文章正文也不是商品参数而是嵌套的标签、内联样式、脚本片段、SEO 元信息、字体声明、广告追踪代码和各式各样的组件容器。LLM 处理文本时按 token 计费HTML 虽然对搜索引擎友好但对模型来说充满了噪声。我见过一个典型的商品详情页抓下来的 HTML 有接近 300 KB切分成 token 之后大概是 7 万到 8 万。可真正有用的信息只有价格、名称、规格、库存和几条评价加起来不到 500 token。也就是说Agent 每次访问这个页面绝大部分开销都在读取“为了渲染而存在”的代码而不是“为了理解而存在”的内容。更麻烦的是HTML 的结构并不稳定。电商网站经常改版一个 class 名变了整个选择器就失效。Agent 如果直接依赖 HTML 的 DOM 结构去提取信息那每次前端改动都可能让流程中断。这也是很多抓取脚本维护成本高的原因之一。1.2 从“读页面”到“调用接口”一条已经被验证的路径长期以来开发者给 Agent 提供的工具一般是 API。但互联网上大量网站没有开放 API或者有但限制严格。抓 HTML 给 Agent 自由阅读只是没有 API 时的权宜之计。不过最近一段时间我注意到一个有趣的现象Codex CLI、Claude Code CLI 这类终端工具流行之后大家发现 Agent 在命令行环境里的表现往往比在浏览器环境里更稳定。原因很简单命令行工具输入输出是结构化的你传入参数拿到结果没有复杂的视觉渲染和动态布局。Agent 不需要猜测“页面上那个按钮在哪”只需要知道命令叫什么、参数是什么、返回什么格式。于是有人想到如果网站也能被封装成一堆命令Agent 不就可以像使用本地工具一样使用整个网站了吗这正是这类“网站转 CLI”项目的核心逻辑。它不是简单地把 HTML 压缩成文本而是把网站重新设计成一套面向机器的接口。2. 网站转 CLI它在解决什么问题2.1 给 Agent 用的“CLI”长什么样这里的 CLI 不是指你在终端里敲ls、cd那种本地命令而是指一种“以命令行方式暴露出来的网站操作能力”。举个例子一个正常用户搜索商品时会打开电商网站在搜索框里输入关键词点击搜索然后阅读搜索结果列表。如果把这个流程封装成 CLIAgent 只需要调用web_shop search --query 机械键盘 --limit 5返回结果可以是纯净的 JSON 或紧凑文本[ {title: 客制化机械键盘 87 键, price: 399 元, stock: 有货}, {title: 办公机械键盘 104 键, price: 199 元, stock: 有货} ]Agent 不需要打开浏览器、不需要等到页面渲染完成、不需要从一堆 DOM 节点里寻找.product-title。它只需要知道这条命令的约定然后解析返回结果。这就是“网站变成 CLI”的含义。这类工具通常会把一个网站的多个能力拆分成几个命令比如搜索、查看详情、翻页、提交表单等。每个命令都经过封装原始 HTML 的内容被提前结构化Agent 拿到的是一份干净的数据。2.2 为什么比直接传 HTML 更省 Token答案其实不复杂HTML 里的信息密度太低了。一个网页里真正有用的内容可能只有 5%其余是装饰、样式、脚本和容器标签。CLI 的返回结果只把你关心字段吐出来其他一律丢弃。从这个角度看142 倍的 token 减少并不夸张。假设一个页面全部 HTML 是 100,000 token而封装后只返回 700 token 的核心数据那已经接近 142 倍了。但这里有一个很容易被忽略的细节token 的节省不只是“返回结果变短”还包括“上下文不再被污染”。如果 Agent 每次调用 Website 工具都塞入大量 HTML这些内容会长期保留在对话上下文中影响后续所有请求的注意力分配。用一个短小的 CLI 输出代替完整 HTML模型可以更专注于任务本身而不是反复排除噪声。2.3 不只是压缩它把网页变成了可操作的工具这是我认为最重要的点。如果网站转 CLI 只是“把 HTML 变短”那跟 HTML 转 Markdown 没有本质区别都是文本压缩。真正的差异在于它把“读网页”变成了“操作服务”。普通抓取方案中AI Agent 是旁观者它只能阅读页面内容如果要执行操作比如添加购物车、提交表单、翻页你必须另外写一套浏览器自动化脚本。而 CLI 封装把写操作也变成了命令web_shop add_to_cart --item_id 1024 --quantity 2web_shop submit_checkout --address_id 88这样一来Agent 的能力边界从一个“能读网页的模型”扩展成了“能操作互联网服务的执行器”。这个变化的影响远大于 token 数字本身。它会改变 Agent 的交互方式从“让模型去理解一个人类界面”变成“给模型一把经过设计的钥匙”。3. 实操视角这类工具怎么用起来3.1 一个最小流程从目标网站到 Agent 调用如果你也想把一个网站包装成 CLI可以先按下面的流程走一遍。这个流程不依赖某个特定工具更多是通用设计思路。第一步分析网站的交互模式。打开目标网站列出用户会做的核心操作。比如文档站有搜索、查看目录、打开文章商品站有搜索、看详情、加入购物车论坛有登录、浏览帖子、回复。不要一开始贪多选 3 到 5 个高频操作就够了。第二步定义命令和参数。为每个操作起一个名字确定它需要哪些参数、返回哪些字段。这一步尽量保持简单。例如site search --keyword 自然语言处理 --page 1 --size 10 site get_article --id 12345第三步实现适配器。写代码去请求目标网页从 HTML 中提取你需要的数据然后按约定的格式输出。如果目标网站有开放 API直接用 API 也行没有的话就只能写抓取逻辑。第四步启动本地服务。为了让 Agent 能调用CLI 通常会被包装成一个本地 HTTP 服务或者通过 MCP、JSON-RPC 等方式暴露给 Agent。你可以用一个简单的 Python 或 Node 服务把命令映射到 HTTP 接口。第五步接入 Agent。在 Codex CLI、Claude Code CLI 或自定义 Agent 的工具列表里注册这个服务。很多 Agent 框架支持“工具调用”只要返回的格式是 JSON 或纯文本就能直接接入。第六步用小样本验证。选 5 个真实查询跑一遍观察返回结果、token 消耗和失败率。不要一上来就批量执行。3.2 输入、输出与操作边界怎么定设计 CLI 命令时边界比功能更重要。我见过不少“网站转 CLI”项目功能倒是不少但用起来一团糟原因就是输入输出的设计没有约束。输入方面要注意几点参数尽量用显式命名不要依赖顺序。--query、--limit比query limit更不容易出错。参数值要做合法性校验。如果 Agent 传了一个超大的limit你应该截断它而不是把整个网站翻一遍。区分可空参数和必填参数。必填参数缺失时返回明确错误信息而不是假装成功。输出方面也要保持稳定优先返回 JSON因为 Agent 解析 JSON 的成功率最高。纯文本比较适合阅读但不适合程序处理。限制输出长度。即使搜索有 100 条结果也要允许通过--limit控制避免一次返回太多 token。不要在输出里附带无关解释。命令是给 Agent 用的不是给人看的所以 “这是搜索结果” 之类的句子没必要出现。操作边界是另一个容易踩坑的地方。如果一个网站支持写操作比如发帖、下单、删除数据那你在设计命令时必须非常谨慎。Agent 的执行能力往往比我们预期的强一个模糊的 “提交” 命令可能造成不可逆的后果。给写操作命令加上--confirm参数或者在代码里加一层人工审批钩子都是必要的保护。3.3 遇到问题怎么排查当你把网站挂到 Agent 上之后会遇到各种问题。我建议按下面的顺序排查而不是直接怀疑是模型不行。一看命令是否真的生效。先在终端里手动执行一遍 CLI确认返回结果符合预期。如果手动执行就报错问题一定出在适配器层跟 Agent 无关。二看输入是否被正确传递。检查 Agent 是否把参数传成了字符串、数组或者漏掉了某个必填项。很多时候问题出在 Agent 不知道命令应该接收什么参数这说明你的命令描述写得不够清楚。三看输出是否被截断。如果命令返回了很长很长的 JSONAgent 可能只使用了前半部分。这种时候要考虑精简输出或者让输出支持分页和定向提取。四看是否有会话和认证问题。很多网站需要登录才能访问。如果你的 CLI 没有处理好 cookie 或 token 的刷新Agent 调用几次之后就会遇到 401。排查时检查认证态是否过期、是否并发复用导致冲突。五看目标网站是否改版。HTML 结构是最不稳定的依赖。如果你的提取逻辑使用了选择器那网站一个 class 类名变化就可能让命令失效。日志里出现提取结果为空优先去网页里确认结构是否变了。4. 能力边界与选型判断4.1 适合改造的网站特征并不是所有网站都值得转成 CLI。从我的经验看适合的网站通常有这几个特征页面结构相对稳定不经常改版。核心操作是比较明确的查询或提交比如搜索、查看文章、查看价格。返回内容能够结构化比如列表、表单、数据卡片。网站本身有公开访问能力或者认证方式足够简单。你对这个网站的需求是重复性的不是一次性临时任务。典型的有文档站、技术博客、排行榜、公开数据库、产品目录、物流查询、汇率查询这类信息型站点。你只需要把“查询”这一件事封装好Agent 的价值就能立刻体现。4.2 不适合的网站与备选方案下面这些情况强行转 CLI 往往会得不偿失。高度依赖 JavaScript 渲染的网站。如果页面内容必须在浏览器执行完 JS 才会出现你的 CLI 就需要内置一个无头浏览器这会让 token 节省全部失去意义因为你要额外维护渲染环境。这时候更合理的方式是用 Playwright 或 Puppeteer 做的浏览器自动化或者直接用多模态模型截图理解页面。需要大量视觉判断的网站。比如图片素材站你需要根据图片颜色、构图来选择素材CLI 返回的 JSON 里只有 URL 和标题根本无法帮助决策。这种情况更适合用视觉模型来评估。反爬机制很强的网站。频繁请求会导致 IP 被封、验证码弹出。你当然可以在 CLI 里内置代理、限速、验证码识别但这已经不是“节省 token”的范畴而是一种高成本对抗。交互路径特别复杂的业务系统。比如一个多步骤的预订流程中间有各种条件分支把它们全部抽象成命令工作量会爆炸而且很难覆盖边界条件。这种场景更适合人工操作或者针对特定流程做定制化开发而不是通用“网站转 CLI”。4.3 和 MCP、浏览器自动化、HTML 转 Markdown 的区别这几个概念经常被混淆我简单做一个对比。MCP 本质上是给 AI 工具定义了一套标准协议它解决的是“不同工具如何接入 Agent”的问题。网站转 CLI 的工具可以通过 MCP 接口暴露但 MCP 本身不帮你压缩 token也不帮你解析 HTML。它更像是一个连接标准。浏览器自动化解决的是“如何让程序像人一样操作浏览器”的问题。它能处理动态渲染和复杂交互但它的每一步输入都来自选择器输出仍然是页面状态token 消耗和稳定性取决于你如何提取信息。CLI 方案可以借力浏览器自动化但目标不同CLI 想隐藏实现细节给 Agent 一个干净接口。HTML 转 Markdown 是最轻量的一层优化。它确实能去掉标签保留正文但 markdown 仍然是自然语言文本没有把网站操作变成命令。它适合“让模型读一个网页”不适合“让模型操作一个服务”。方案主要作用Token 优化操作能力稳定性适用场景直接传 HTML原始喂给模型无无差一次性查看HTML 转 Markdown去除标签保留文本中等无中等读取文章浏览器自动化模拟人操作较差强依赖提取逻辑动态交互网站转 CLI把网站变成命令接口高强高重复性查询和操作MCP工具接入标准看具体实现看具体实现看具体实现标准连接5. 长期使用建议不是跑通一次而是当成一条工作流5.1 先用小样本验证再扩展批量场景很多人的第一反应是把整个网站的几百个页面全部封装好让 Agent 一次性跑完。这是错误开头。正确做法是先用一个固定网站定义三五个命令跑十几个真实查询。观察几个数字平均每个查询消耗多少 token。和直接传 HTML 相比节省了多少。命令成功率有多高。有没有返回结果不完整或字段缺失的情况。确认这些指标稳定之后再考虑扩展到更多网站或更多操作。扩展时也不要一次性加很多命令而是一次加一两个每个新命令都经过同样的验证。这样即使出了问题你也能快速定位是网站问题、适配器问题还是命令设计问题。5.2 要进入工程化必须补上的几块拼图如果只是自己实验跑通流程就够了。但要放进真实项目长期使用还差几块关键拼图。日志是第一位。每次 Agent 调用都要记录使用的命令、参数、耗时、返回大小和错误码。否则出现问题后你根本不知道 Agent 在哪一步失败了。日志最好按网站、按命令分类方便统计。缓存很重要。同一个搜索词如果短时间内重复查询没必要每次请求目标网站。在 CLI 里加一层内存或文件缓存既能减少网站压力也能节省 token。注意设置合理的过期时间。错误重试要设计好。网站请求失败是常态网络抖动、限流、页面结构变化都会导致失败。你的 CLI 需要对临时错误进行重试但也要设置最大重试次数和退避策略避免无限循环。认证刷新是容易被忽略的坑。如果目标网站需要登录你的 CLI 要能检测 token 过期并自动执行刷新或重新登录。很多 Agent 任务执行到一半就挂在登录页上就是因为会话过期后没有自动恢复。输出大小限制和并发控制也很重要。不要让 Agent 一次性请求几百条数据也不要让多个 Agent 同时调用同一个网站。通过限制--limit、限制并发数、增加限流才能保证长期稳定。安全权限是最后一道防线。写操作要谨慎增加确认机制。禁用危险命令比如“删除账户”“清空购物车”。Agent 是聪明且直接的它会尝试用最小步骤完成任务如果命令足够多它可能会做出你没想到的操作。5.3 一个可复用的评估清单当你考虑把一个网站转成 CLI 时可以按下面这个清单快速判断是否值得做。检查项判断标准使用频率你是否会反复查询这个网站如果只查一次不值得封装。操作类型是查询为主还是复杂写操作查询优先写操作要谨慎。页面结构是否相对稳定如果每周改版维护成本会很高。返回内容能否结构化为字段纯图片和视频内容不适合。Token 收益原 HTML 是否大量冗余如果页面本身很小压缩价值有限。认证复杂度是否需要多因素认证或复杂验证码这会让封装成本倍增。安全风险命令是否可能造成不可逆操作必须有保护机制。合规性该网站的服务条款是否允许自动化访问要遵守站点规则。如果这八项里有六项以上是偏向肯定的那这个网站就值得投入时间做 CLI 封装。否则我更建议你先用一次性的抓取脚本解决不要过度工程化。回到本质token 效率背后是代理的工作流效率省 token 是一个很现实的指标它直接关系到成本和速度。但网站转 CLI 这类方案真正的长期价值不是省下了几个 token而是让 Agent 与互联网服务的交互从“模拟人类阅读”变成了“设计好的机器调用”。HTML 是为人的眼睛设计的CSS 控制样式JavaScript 控制交互DOM 结构描述视觉层级。当 AI Agent 需要消费这些信息时我们其实应该为它单独设计一种界面。CLI 就是一种非常自然的机器界面参数明确、输出简洁、身份清晰。过去我们把它用在本机操作上现在把它扩展到整个网站这是 Agent 工作流的一次重要变迁。如果你正在做 Agent 相关的项目我建议从自己最常用的一个查询网站开始花半天时间做一个小型的网站转 CLI 工具接入你的 Agent 跑几个任务。你大概率会发现Agent 的行为会变得更可控成本也会下降一个数量级。这个方向不需要等到工具完美再去用从最小场景开始本身就是最好的优化方式。