Caveman Browse 基准测试详解：从 39.8 万 token 原始 AX 树到 121 token 聚焦快照的压缩账本

Caveman Browse 基准测试详解：从 39.8 万 token 原始 AX 树到 121 token 聚焦快照的压缩账本

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman

Caveman 的browse模块是一个本地浏览器交互 MCP 服务器，其核心卖点是通过压缩 Accessibility（AX）树来降低 agent 的 token 成本。本篇以仓库中的 browse/BENCHMARK.md 为主体，完整解读其 2026-08-10 版效率基准的测量口径、两组语料上的量化结果与可复现步骤，并结合 browse/session.go、browse/cdp.go 等源码说明每个数字是怎么算出来、以及哪些结论被刻意不宣称。

测量环境与计数口径

基准文档开头即声明了三项测量前提，这三条决定了如何解读后面所有数字：

• 实测时间 2026-08-10，浏览器为 Google Chrome 151.0.7922.108，Playwright 基线锁定@playwright/test1.56.1；
• token 计数使用 Caveman 的离线o200k_base计数器。从源码看，这是一个真实的 BPE 分词器，词表内嵌于引擎，定义在 engine/tokens/tokens.go 中，因此不依赖任何在线计费接口；
• 所有数字都是单份快照的inferred（推断）token 数，不是provider 实际用量或计费值。

另外，每组数据来自5 次独立 Chrome 运行，表中报告的是中位数与[min–max]。文档解释了为何 Caveman 侧存在极小波动区间：随机的 CDP 节点 id 与 CCR（内容恢复存储）句柄本身会占用少量 token，而 Playwright 基线在 5 次运行中完全稳定。

大页面语料：200 行订单运营表格

第一个语料是 browse/testdata/order_dashboard.html——一张 200 行的运营表格，包含一个被查询的目标订单动作。从 fixture 源码看，页面用 JS 循环生成ORD-0000到ORD-0199共 200 行，每行带一个aria-label="Review ORD-XXXX"的按钮，正好构成"大表中找一条记录"的典型 agent 场景。

基准结果（5 次运行的中位数与区间）：

这里的关键对比点是第三行：Caveman 的"完整结果"并不只是压缩后的树，而是完整的 agent 可见交付物，包含紧凑 AX 文本、UID 列表、CCR 恢复句柄、精确的 agent 可见 token 计数与诚实性元数据（honesty metadata）。文档特别指出这一对比的不对称性：Playwright 基线只计其 ARIA 文本本身，不含 MCP 封装、动作引用（action refs）、恢复句柄或任何账目信息——这种不对称对 Playwright 有利，Caveman 在此仍小幅胜出。

而真正的量级差异出现在第四行：带query的聚焦结果只有 121 token，比原始 AX 树小 129.8 倍。

小页面语料：结算表单——一次诚实的"输"

第二个语料是 browse/testdata/agent_checkout.html：一个含 Email 输入框、Plan 下拉框和 Save order 按钮的小型结算表单。从 fixture 源码看，保存按钮带margin-top: 1400px样式，被刻意放到折叠线（fold）之外，以验证动作前的自动滚动。

结果：

基准文档没有回避这个结果，反而将其作为重要结论：当页面本身极小时，Caveman 的恢复句柄、精确计数器、诚实性依据与动作 UID 的开销会超过裸 Playwright ARIA 文本。文档的定性是：即使输给了裸 ARIA 文本，它相对原始 AX 仍节省 97.35%，且携带足以完成输入、选择、点击、验证与字节级恢复的状态；因此不宣称存在"仅凭快照的普适性胜利"。

序列化回归锁：更小的捕获 fixture

基准还锁定了一个小捕获 fixture 的序列化回归数据，用于防止紧凑格式悄悄膨胀：

• 此前的 Caveman JSON-lines 视图：380 token；
• 紧凑缩进视图：58 token（比旧视图少 84.7%）；
• 精确交付负载（含 CCR/账目）：126 token；
• 原始 AX：5,351 token；
• 四工具 MCP 目录（四个工具的 schema 描述）：287 token。

"四工具 MCP 目录 287 token"这一数字单独锁定，因为它是每次会话的固定隐性成本——在解读快照数字时应当把它计入总账。

复现步骤

基准文档给出的复现路径分三步，均依赖本机 Chrome 路径环境变量CAVEMAN_BROWSE_CHROME。

第一步，运行 Caveman 的实 Chrome 基准与功能回路（集成测试）：

CAVEMAN_BROWSE_CHROME="/path/to/Chrome" \ go test -tags=integration -run 'TestCDPQueryScales|TestCDPFullTokenEfficient' -count=5 -v ./browse

第二步，用同一分词器计数锁定版本的 Playwright ARIA 基线：

CAVEMAN_BROWSE_CHROME="/path/to/Chrome" \ node browse/scripts/playwright-aria-baseline.mjs | \ CAVEMAN_CCR_DB=/tmp/caveman-browse-bench.db \ go run ./engine/cmd/caveman-engine compress --type no-such-type >/dev/null

第三步，向基线脚本传入agent_checkout.html作为参数即可复现小表单那一行结果。基线脚本 browse/scripts/playwright-aria-baseline.mjs 的逻辑很直接：读取browse/testdata/下指定 fixture，对order_dashboard.html会先等待tbody tr达到 200 行再输出page.locator("body").ariaSnapshot()，保证渲染完成后再计数。四工具 MCP 目录的 287 token 成本是另行锁定的。

源码级解读：数字从哪里来

token 计数为什么是"精确"的

tokens_after的含义是agent 实际可见的 JSON 结果的精确 token 数，而不是压缩后树的 token 数。browse/session.go 中的finalizeSnapshotPayload实现了一个不动点迭代：将snapshotPayload（含uids、recovery_handle、tokens_before、view_tokens、tokens_after、ratio、basis字段）序列化为 JSON 后用默认计数器计数，把计数结果回填进tokens_after再重新序列化，最多 8 轮直至自洽。这正是基准表中 Caveman 数字区间极窄的原因——交付物里包含了对自身的精确账目。同时view_tokens单独隔离了紧凑树本身的成本，与tokens_after区分开。

压缩管线与 fail-closed 语义

browser_snapshot的调用链是：CDP 驱动拉取原始树 → 引擎a11y类型压缩 → 交付。browse/cdp.go 的Snapshot直接调用accessibility.GetFullAXTree()并 JSON 序列化，这就是表中"原始 AX"一行的来源；browse/session.go 的snapshotTool则把它交给eng.Compress(raw, engine.Options{Mode: engine.ModeCompress, Type: engine.TypeA11y, Query: a.Query})，query参数即"聚焦渐进披露"的入口。

值得注意的防御性设计：如果压缩后没有产出恢复句柄支撑的 UID 视图，或 agent 可见快照没有比原始 AX 更小，snapshotTool会拒绝把数百 KB 的原始树透传给 agent，返回cave_browser_snapshot_uncompressed错误并保留上一份快照的 UID 缓存——宁可让这次快照失败，也不交付比"不用 Browse"更差的结果。

聚焦快照为什么能到 121 token

browser_snapshot.query保留与查询最匹配的可达节点及其祖先，同时 CCR（engine/ccr/store.go 支撑的恢复存储）保留完整原始树；紧凑输出使用[uid] role "name"格式的行，且 UID 只分配给可操作或未知自定义角色节点。因此聚焦视图不是"全树再裁剪"，而是按需重建的最小可操作视图。

集成测试门槛：数字背后的功能回路

基准的"Reproduce"一节还列出集成测试覆盖的门槛，这些对应 browse/cdp_integration_test.go 中的具体断言：

• TestCDPQueryScalesOnTwoHundredRowDashboard：断言聚焦交付物比完整交付物至少小 10 倍、聚焦tokens_after ≤ 160且ratio ≥ 0.99，并验证聚焦结果仍持有可点击的Review ORD-0173目标；
• TestCDPFullTokenEfficientReadActVerifyRecoverLoop：完整跑通"读取 → type → select → 折叠线下按钮的自动滚动点击 → 动作后聚焦验证"回路，断言每个动作都报告settled:false并要求重新快照验证，且恢复工具返回的字节与驱动捕获的原始 AX逐字节一致（byte-exact）；
• TestCDPActionabilityRejectsDisabledButton与TestCDPStaleUIDFailsClosedAfterDOMReplacement：分别验证禁用控件被拒、DOM 被替换后旧 UID 的 backend node id 必须 fail-closed；
• 其余门槛覆盖：类型输入、下拉选择、离屏自动滚动点击、动作后聚焦验证、禁用控件拒绝、陈旧 UID 拒绝、字节级实时恢复、fresh-home 启动、跨进程直接 CLI 重附着与显式 Chrome 关闭。

其中settled:false是刻意的设计：browse/cdp.go 的dispatchedAction注释说明，CDP 确认了分发不等于应用状态已稳定，声称settled=true会让 agent 信任未经验证的结果——聚焦快照才是廉价的、携带证据的验证步骤。集成测试甚至断言交付物中不能出现"verified"字样，强制 Browse 路径保持inferred-only 的诚实口径。

声明边界：结论的适用前提

基准文档最后一段划定了结论边界，复用时必须遵守：

• 结果仅适用于本语料与本工具链（Chrome 151 + 锁定版 Playwright + 离线计数器）；
• Phase 1 只覆盖同源、控件可预期的页面；OOPIF（跨域 iframe）、对话框、下载、任意站点的可操作性问题均被推迟；
• 对大页面，query 聚焦渐进披露是默认策略；当任务意图未知时仍可提供全量快照。

配套的功能说明与安装方式见 browse/README.md：构建命令为go build ./browse/cmd/caveman-browse，可直接 CLI 使用（caveman-browse snapshot <url> [query]、act、recover、close），也可作为 MCP 服务器运行。需要注意的是browse的源码与二进制以 BSL 1.1 发布，属于 source-available 而非 OSI 开源，第三方托管/托管服务/嵌入用途需要商业许可。

总结

这篇基准的价值不在单一数字，而在于一套完整的"token 账本"方法论：锁定浏览器与基线版本、用同一离线分词器计数、报告多次运行的中位数与区间、明确声明每份交付物的构成差异、诚实呈现小页面上的劣势，并用集成测试把"聚焦视图 ≤160 token、至少 10× 缩减、字节级恢复"固化为可回归的断言。对引用 Caveman Browse 压缩数据的读者，最可靠的做法是照搬 BENCHMARK.md 的两条复现命令在本机重跑，而不是直接采信任何未经工具链验证的转述数字。

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman