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/cavemanCaveman 的browse模块是一个本地浏览器交互 MCP 服务器其核心卖点是通过压缩 AccessibilityAX树来降低 agent 的 token 成本。本篇以仓库中的 browse/BENCHMARK.md 为主体完整解读其 2026-08-10 版效率基准的测量口径、两组语料上的量化结果与可复现步骤并结合 browse/session.go、browse/cdp.go 等源码说明每个数字是怎么算出来、以及哪些结论被刻意不宣称。测量环境与计数口径基准文档开头即声明了三项测量前提这三条决定了如何解读后面所有数字实测时间 2026-08-10浏览器为 Google Chrome 151.0.7922.108Playwright 基线锁定playwright/test1.56.1token 计数使用 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-labelReview ORD-XXXX的按钮正好构成大表中找一条记录的典型 agent 场景。基准结果5 次运行的中位数与区间表示方式Token 数相对原始 AX相对 Playwright原始Accessibility.getFullAXTreeJSON398,494[398,493–398,497]n/an/aPlaywrightlocator(body).ariaSnapshot()15,704少 96.06%n/aCaveman 完整 agent 可见结果13,368[13,367–13,368]少 96.65%少 14.88%Caveman 聚焦结果查询ORD-0173121[121–122]少 99.97%少 99.23% / 小 129.8×这里的关键对比点是第三行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之外以验证动作前的自动滚动。结果表示方式Token 数相对原始 AX相对 Playwright原始Accessibility.getFullAXTreeJSON4,186[4,183–4,188]n/an/aPlaywrightlocator(body).ariaSnapshot()67少 98.40%n/aCaveman 完整 agent 可见结果157[156–159]少 96.25%大 2.34×Caveman 聚焦结果查询Email Plan Save order111[110–113]少 97.35%大 1.66×基准文档没有回避这个结果反而将其作为重要结论当页面本身极小时Caveman 的恢复句柄、精确计数器、诚实性依据与动作 UID 的开销会超过裸 Playwright ARIA 文本。文档的定性是即使输给了裸 ARIA 文本它相对原始 AX 仍节省 97.35%且携带足以完成输入、选择、点击、验证与字节级恢复的状态因此不宣称存在仅凭快照的普适性胜利。序列化回归锁更小的捕获 fixture基准还锁定了一个小捕获 fixture 的序列化回归数据用于防止紧凑格式悄悄膨胀此前的 Caveman JSON-lines 视图380 token紧凑缩进视图58 token比旧视图少 84.7%精确交付负载含 CCR/账目126 token原始 AX5,351 token四工具 MCP 目录四个工具的 schema 描述287 token。四工具 MCP 目录 287 token这一数字单独锁定因为它是每次会话的固定隐性成本——在解读快照数字时应当把它计入总账。复现步骤基准文档给出的复现路径分三步均依赖本机 Chrome 路径环境变量CAVEMAN_BROWSE_CHROME。第一步运行 Caveman 的实 Chrome 基准与功能回路集成测试CAVEMAN_BROWSE_CHROME/path/to/Chrome \ go test -tagsintegration -run TestCDPQueryScales|TestCDPFullTokenEfficient -count5 -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 tokenbrowser_snapshot.query保留与查询最匹配的可达节点及其祖先同时 CCRengine/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-exactTestCDPActionabilityRejectsDisabledButton与TestCDPStaleUIDFailsClosedAfterDOMReplacement分别验证禁用控件被拒、DOM 被替换后旧 UID 的 backend node id 必须 fail-closed其余门槛覆盖类型输入、下拉选择、离屏自动滚动点击、动作后聚焦验证、禁用控件拒绝、陈旧 UID 拒绝、字节级实时恢复、fresh-home 启动、跨进程直接 CLI 重附着与显式 Chrome 关闭。其中settled:false是刻意的设计browse/cdp.go 的dispatchedAction注释说明CDP 确认了分发不等于应用状态已稳定声称settledtrue会让 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考