有些成本陷阱不是藏在模型价格表里，而是藏在一个看起来很无害的动作里：

“帮我打开这个网页看一下。”

这句话听起来像是一次普通浏览。人类打开网页，眼睛扫一遍标题、正文、引用、评论，觉得没什么。但 AI Agent 不一样。它不是“看”网页，它通常要先把网页变成一大坨文本，再塞进上下文窗口，然后才开始推理。

Hacker News 上今天有个帖子把这个问题戳得很直：一个普通 Wikipedia 页面，直接喂给 AI Agent，可能要 68,240 tokens。Nike 首页更夸张，raw HTML 可能到 353,000 tokens。帖子作者说，Claude Code 的内置 WebFetch 在简单页面上表现不错，可以把 Wikipedia 总结到大约 950 tokens；但遇到 JS 渲染、反爬、Cloudflare 或 403 页面时，就可能失败。更糟的是，有些 Agent 会把 raw HTML 直接倒回上下文，烧了一大堆 token，最后仍然没读懂网页。

这不是“模型贵”的问题。

这是 Agent 读网页的姿势错了。

我复测了一遍：同一个网页，差距可以是 400 倍

为了不只复述别人的数字，我在本机用 tiktoken 做了一个小复测。编码器用 cl100k_base，抓取页面后分别统计 raw HTML 和简单可见文本抽取后的 token 数。

结果如下：

这张表最吓人的地方，不是 Artificial intelligence 页面 raw HTML 到了 68 万 tokens，而是 同一个信息目标，可以有完全不同的读取成本。

如果目标只是回答“AI agent 是什么”，你根本不需要 176,990 tokens 的 HTML。Wikipedia 的 REST summary 返回 415 tokens 就够了。如果只要引言，MediaWiki API 的 intro extract 只有 111 tokens。哪怕要章节结构，也不到 1,000 tokens。

也就是说：

真正昂贵的不是 Wikipedia，而是“把网页当垃圾袋一样整袋塞给模型”。

AI Agent 的网页读取成本黑洞，正是从这里开始的。

raw HTML 为什么这么贵：网页不是文章，是一座脚手架

人眼看到的是正文。

Agent 看到的可能是这些东西：

• <script> 里的前端状态
• CSS class 和内联样式
• 导航栏、页脚、语言切换
• 引用、脚注、编辑按钮、目录
• JSON-LD、hydration data、埋点配置
• 广告位、推荐位、Cookie 弹窗
• 无障碍标签、SVG、图标、懒加载占位

网页不是一篇文章。现代网页更像一栋正在施工的大楼：正文只是房间，HTML 是钢筋、脚手架、电梯井、消防管、广告牌和物业公告栏。人类浏览器会把这些东西渲染掉，只给你看房间；Agent 如果拿 raw HTML，就等于把整栋楼的施工图纸吞下去。

Wikipedia 已经算相对干净的网站了。它至少是以内容为核心，不是纯前端应用。但即便如此，AI agent 词条 raw HTML 仍然有 176,990 tokens。HN 原帖里提到的平均 Wikipedia 文章 68,240 tokens，并不夸张；我这里测到的数字更高，主要取决于词条大小、页面版本、抓取方式，以及是否包含导航、引用、模板、语言链接等页面结构。

Nike 首页则是另一个典型：可见文本只有 3,994 tokens，raw HTML 却有 281,984 tokens。用户打开 Nike，是想看鞋；Agent 拿 raw HTML，可能先吃一肚子前端脚本。

这就是第一层误区：把“网页内容”误认为“网页源码”。

WebFetch 不总是错，错的是没有兜底策略

这里要公平一点：不是所有 WebFetch 都糟糕。

好的网页读取工具会做几件事：

• 抓取页面
• 清理 HTML
• 去掉导航、脚本、样式
• 提取正文
• 根据问题做摘要
• 只把摘要或相关片段交给模型

HN 原帖也承认，Claude Code 的内置 WebFetch 对 Wikipedia 这类简单页面处理得不错，可以把页面总结到大约 950 tokens。这个数字很合理：如果用户只是问一个具体问题，950 tokens 的相关摘要比 68,000 tokens 的完整页面更适合进入上下文。

问题出在失败路径。

失败路径一般长这样：

用户：帮我看这个网页
Agent：调用 WebFetch
WebFetch：JS 渲染失败 / 403 / Cloudflare / 没提取到正文
Agent：尝试读取原始 HTML
Agent：把几十万 tokens 的 HTML 塞进上下文
模型：上下文变胖、费用上升、答案还可能错

最荒谬的地方是：你付钱买了一堆失败信息。

页面没读出来，任务没完成，但 token 已经烧掉了。更坏的是，这些无关 HTML 进入上下文后，还会污染后续推理。模型不是数据库，它不会自动把垃圾输入隔离在一边。上下文越胖，注意力越分散，答错的概率越高。

所以，WebFetch 的关键不是“能不能抓网页”，而是：

失败时，是否能停下来，而不是把失败结果继续喂给模型。

这和运维里的日志处理很像。日志很有价值，但你不会把 2GB 的日志直接贴进工单。你会先 grep、tail、按时间过滤、按错误码聚合。Agent 读网页也一样，必须先过滤，再推理。

一次网页读取，可能在 Agent 循环里被放大十倍

很多人估 token 成本时，只估“一次调用”。比如，一个网页 68,000 tokens，按某个模型输入价算一下，觉得也没多少钱。

这是低估。

Agent 的真实成本来自循环。

一个典型研究任务可能不是一次读取，而是这样：

第 1 轮：搜索相关网页
第 2 轮：打开第一个结果
第 3 轮：总结页面
第 4 轮：发现缺引用，再打开第二个结果
第 5 轮：对比两个页面
第 6 轮：补充第三个来源
第 7 轮：生成大纲
第 8 轮：写正文
第 9 轮：自检事实
第 10 轮：修改输出

如果每一轮都带着前面的大段网页内容走，成本不是 68,000 × 1，而是像滚雪球一样增长。

这也是 Agent 和普通 Chatbot 的区别。Chatbot 多数时候是一问一答；Agent 会调用工具、观察结果、再决定下一步。每一轮工具输出如果都保留在上下文里，前面网页的垃圾 HTML 会在后面反复付费。

可以把它理解为“上下文利息”：你第一次把 68,000 tokens 塞进去，只付一次本金；但后面每轮调用都继续携带它，就开始付利息。循环越长，利息越吓人。

这也是为什么我不喜欢“上下文窗口越大越好”这个说法。大窗口当然有价值，但它也会纵容坏习惯：以前 32K 窗口塞不进去的垃圾，现在 200K、1M 窗口能塞了，于是系统不报错了，账单开始报错。

成本差异来自“信息粒度”，不是来自模型聪不聪明

回到前面的复测数据：

• raw HTML：176,990 tokens
• 可见文本：13,934 tokens
• REST summary：415 tokens
• intro extract：111 tokens
• sections：984 tokens

这些不是同一种东西。

它们代表四种信息粒度：

多数 Agent 任务根本不需要 raw HTML。甚至多数任务也不需要全文。用户问“这篇文章讲什么”，摘要够了；问“有没有提到某个观点”，关键词检索加相关段落够了；问“这家公司官网有没有价格”，只要价格区域，不要全站脚本。

所以网页读取的第一原则应该是：

先问任务需要什么粒度，再决定抓什么内容。

这句话听着像废话，但很多 Agent 框架默认不是这么干的。它们默认是“工具给什么，我就塞什么”。这在 demo 里没问题，在生产里就是账单炸弹。

一套更稳的网页读取策略：先轻后重，逐级加码

如果让我给 AI Agent 设计网页读取流程，我不会让它第一步就抓整页。我会让它像侦察兵，而不是像铲车。

第 1 层：只拿搜索结果和摘要

先用搜索引擎 snippet、页面标题、描述判断相关性。很多问题在这一层已经够用了。

适合：

• 判断主题方向
• 找官网 / 文档入口
• 快速筛掉无关页面
• 对比多个候选来源

不要一上来就打开 10 个网页。先看 10 个标题，再决定打开哪 2 个。

第 2 层：调用站点 API 或结构化接口

Wikipedia 这类站点有成熟 API。不要抓 HTML。

比如：

https://en.wikipedia.org/api/rest_v1/page/summary/AI_agent
https://en.wikipedia.org/w/api.php?action=query&prop=extracts&exintro=1&explaintext=1&titles=AI_agent&format=json
https://en.wikipedia.org/w/api.php?action=parse&page=AI_agent&prop=sections&format=json

我复测里，AI_agent 的 REST summary 是 415 tokens，intro extract 是 111 tokens，sections 是 984 tokens。对很多问答任务来说，这已经够了。

第 3 层：提取正文，而不是读取源码

如果 API 不够，再做正文抽取。可以用 Readability、Trafilatura、Jina Reader、Tavily Extract，或者自己写 HTML 清洗器。

这一步目标不是“拿到网页所有内容”，而是拿到正文主体。

复测里 AI agent Wikipedia raw HTML 是 176,990 tokens，简单可见文本抽取后是 13,934 tokens。虽然还不完美，但已经少了 92% 左右。

第 4 层：按问题检索片段

全文仍然太大时，不要直接喂给模型。先分块，做关键词或 embedding 检索，只取相关段落。

例如用户问“AI agent 的安全风险是什么”，就只拿 Security、Concerns、Threat modeling 附近段落。不要把历史、应用、参考文献、语言导航全塞进去。

第 5 层：raw HTML 只给专门任务

raw HTML 应该是特权操作，不是默认操作。

只有这些场景才值得读源码：

• 调试爬虫选择器
• 分析前端结构
• 找隐藏字段
• 排查 403 / JS 渲染问题
• 写页面解析规则

而且即便读，也应该有硬上限：比如最多 20,000 tokens，超过就保存到文件，让 Agent 用工具按需检索，不要直接进入模型上下文。

给 Agent 加一道“网页预算闸门”

真正工程化的 Agent，不应该只会 fetch(url)。它应该在读取前先估算预算。

可以设计一个简单策略：

web_read_budget:
  max_tokens_per_page: 12000
  max_tokens_per_task: 40000
  prefer_api: true
  prefer_summary: true
  raw_html_default: false
  raw_html_max_tokens: 20000
  on_extract_failure: "ask_or_skip"
  keep_failed_fetch_out_of_context: true

这里最关键的是最后两条：

on_extract_failure: "ask_or_skip"
keep_failed_fetch_out_of_context: true

意思是：正文抽取失败时，不要把失败页面原样塞进上下文。要么换工具，要么跳过，要么问人。失败结果可以存文件、记日志，但不要进入模型脑子里。

我更喜欢把网页读取拆成两个阶段：

阶段 A：采集层
- 抓网页
- 解 JS
- 过反爬
- 清洗 HTML
- 抽正文
- 保存原文和元数据

阶段 B：推理层
- 只读摘要
- 只读相关片段
- 必要时回查原文位置
- 不直接吞 raw HTML

这其实就是传统搜索系统的思路：爬虫归爬虫，索引归索引，查询归查询。Agent 不应该每次回答问题都从“抓取整个互联网”开始。

不要迷信长上下文：窗口越大，越需要节制

现在很多模型开始支持 128K、200K、1M tokens。听起来像豪宅：空间大了，终于可以随便放东西。

但用久了你会发现，大房子也会变成杂物间。

长上下文真正适合的是这些场景：

• 一次性审阅长合同
• 对比多个完整文档
• 分析大型代码文件
• 处理不能拆分的连续材料
• 保留复杂推理链的必要证据

它不适合拿来装网页垃圾、重复日志、失败抓取结果、完整历史对话。

更准确地说：长上下文是安全气囊，不是垃圾桶。

一旦 Agent 有了“大窗口兜底”，开发者很容易懒得做检索、过滤、摘要和缓存。短期 demo 很爽，长期成本很难看。真正成熟的 Agent 系统，应该在 32K 窗口内也能优雅工作；长上下文只在必要时加码。

我的判断：未来 Agent 的核心能力不是会浏览网页，而是会少读网页

早期我们夸一个 Agent 强，会说它“会用浏览器”“会搜索网页”“会打开链接”。这当然重要。但下一阶段，更重要的能力是：

它知道什么时候不该打开网页，什么时候只读摘要，什么时候必须深读，什么时候应该停下来。

这就像一个成熟程序员不会一上来 cat 整个 2GB 日志。他会先看错误时间、错误码、最近 200 行、相关 request id。AI Agent 也应该有这种职业习惯。

今天这个 68,000 tokens 的 Wikipedia 案例，表面上是 token 成本问题，底层其实是上下文工程问题：

• 上下文不是越多越好，而是越相关越好
• 工具输出不是都该进模型，而是要先过筛
• 网页不是文章，而是信息矿石
• Agent 不该吞矿石，应该先冶炼

如果你在搭自己的 AI Agent，尤其是带联网搜索、网页阅读、资料研究的 Agent，我建议先加三条硬规则：

1. raw HTML 默认不进上下文
2. 每个网页进入模型前必须先估 token
3. 抽取失败时停止，不把失败内容喂给模型

这三条不性感，但很救命。

因为 AI Agent 真正的成本黑洞，往往不是它想太多。

是它读太多。

参考来源

• Hacker News: One Wikipedia page costs your AI agent 68,000 tokens
• PromptZone: Wikipedia Pages Cost AI Agents 68K Tokens
• MindStudio: Token Reduction Strategies for AI Agents
• 本文复测：tiktoken + cl100k_base，页面抓取时间为 2026-07-13