【免费下载链接】pinchtabHigh-performance browser automation bridge and multi-instance orchestrator with advanced stealth injection and real-time dashboard.项目地址https://gitcode.com/gh_mirrors/pi/pinchtab点击查看免费下载PinchTab 是一套高性能浏览器自动化桥接与多实例编排工具其仓库内置了一套结构化的 AI Agent 基准测试体系tests/benchmark/用于衡量 LLM Agent 驱动浏览器时的端到端 token 成本与任务完成率。本文聚焦其中第一个任务组Group 0: Basic Navigation Reading逐条拆解它的 5 个步骤——导航、快照、读取文本、点击链接、按 ref 提取数据——并结合tests/tools/下的 fixture 页面、Go runner 源码与 CLI skill 说明其运行机制与验证方式。读完本文你将掌握如何理解这套基准任务组、如何用 PinchTab CLI 手工复现每一步以及它在这套导航与阅读工作量上被如何打分。基准任务组的整体定位在 PinchTab 仓库中基准任务以 Markdown 分组文件的形式存放在tests/benchmark/目录下tests/benchmark/index.md是任务索引它明确了每个组的定位与步数组主题步数group-00.mdBasic Navigation Reading基础导航与阅读5group-01.mdForms Interactions表单与交互5group-02.mdSelect Dropdowns选择与下拉框3group-03.mdScrolling Pagination滚动与分页3group-04.mdAuthentication认证3group-05.mdE-commerce Flow电商流程5其中 Group 0 是所有 Agent 任务集的第一站它不涉及表单、下拉、滚动等复杂交互只验证 Agent 能否完成打开页面 → 观察页面 → 读取内容 → 点击导航 → 提取指定数据这条最基本的浏览器操作链路。整个仓库的基准测试docs/benchmark.md与docs/deep-dive/benchmark.md在对比 PinchTab 与 agent-browser 两条工具面lane时正是以 Group 0 Group 1 共 10 步作为基础范围basic scope的锚点任务集。Group 0 的五步任务详解tests/benchmark/group-00.md本身非常精简每个步骤只给出任务描述与一条验证标准Verify。但结合 fixture 页面、CLI 命令与 runner 代码每一步都能还原为一条可手工复现的操作。0.1 Navigate to page验证浏览器连通性Navigate tohttp://fixtures/to confirm browser connectivity.Verify: Page loads successfully and contains benchmark content.这一步是整个基准测试的启动动作Agent 通过 PinchTab CLI 导航到基准 fixture 首页http://fixtures/。该地址由 Docker Compose 中的fixtures服务提供对应的实际页面是tests/tools/fixtures/index.html其标题为 PinchTab Benchmark - Home正文包含可验证的标记文本VERIFY_HOME_LOADED_12345以及Welcome to the Benchmark Test Suite等内容。在 PinchTab 的 skillskills/pinchtab/SKILL.md中导航与观察被设计为一条命令完成pinchtab nav http://fixtures/ --snapnav url --snap会启动本地 server如需要、完成导航并在同一次调用中返回 tab ID 与一份可交互的快照——这正是 PinchTab 在基准测试中省 API 往返的关键设计。而在 runner 的 lane 配置里tests/tools/runner/internal/bench/prompt.go的LanePromptConfigPinchTab 的 bootstrap 命令同样是./scripts/pt nav http://fixtures/ --snap。验证含义页面成功加载且包含基准内容即首页中应出现PinchTab Benchmark Suite标题、Welcome to the Benchmark Test Suite与VERIFY_HOME_LOADED_12345标记证明 Agent 与浏览器工具之间的通路是通的。0.2 Take snapshot捕获带 ref 的可交互快照Capture a DOM snapshot with actionable refs.Verify: Snapshot returns structured content with ref IDs.第二步要求 Agent 捕获带可操作引用actionable refs的 DOM 快照。PinchTab 的快照机制是它的核心抽象快照把页面上的可交互元素链接、按钮、输入框、标题等压缩成紧凑格式并为每个元素分配一个稳定 ref 标识如e5、e12Agent 后续的所有点击、填充、提取都通过这些 ref 进行。对应的命令在 skill 中给出pinchtab snap # 默认紧凑交互格式interactive headings pinchtab snap -i -c # 命令行手册中展示的交互式紧凑变体 pinchtab snap --full # 调试用所有节点以 JSON 输出快照输出的典型形态来自 skill 的--snap-diff示例snap格式相同# Page Title | URL | 57 nodes | 2 ~1 -0 e0:link Home e5:button Submit [] e12:textbox valupdated [~] # removed: e99验证含义快照返回结构化内容且包含 ref ID。换句话说Agent 必须拿到至少一个eN形式的 ref才能证明它拥有后续步骤点击、提取的手柄。在基准环境里这一步对应 fixture 首页的快照——首页的导航区包含#nav-articles、#nav-search、#nav-form、#nav-dashboard、#nav-shop等链接都会以 ref 形式出现在快照中。0.3 Read page text提取页面主文本Extract the main text content from the current page.Verify: Text content is returned without errors.第三步是纯读取操作把当前页面的正文文本取出来。PinchTab 的 skill 明确指出当只需要文本、不需要对 ref 采取行动时使用pinchtab text而非snap——这是 read-only 观察最省 token 的路径pinchtab text此外--text观察标志也可用于click、fill、select、press、back、forward、reload但不支持nav与scroll在需要散文内容用于验证、且不想带出快照时使用。验证含义文本内容无错误地返回。对于 fixture 首页返回值应包含Welcome to the Benchmark Test Suite与Benchmark Fixtures v1.0等可见文本Agent 可以据此确认读取链路正常。0.4 Click a link点击导航链接并确认页面变化Click a navigation link on the fixtures page (e.g., a More Info or numbered link).Verify: Navigation occurs and page content changes.第四步要求 Agent 点击 fixture 页面上的一个导航链接例如 More Info 或编号链接并验证发生了导航、页面内容发生了变化。在 Group 0 的语境下导航链接通常就是首页nav区里的链接Articles、Search、Form、Dashboard、Shop它们分别指向tests/tools/fixtures/下的articles.html、search.html、form.html、dashboard.html、ecommerce.html。PinchTab 的点击与观察合并为一次调用这是它在基准测试中 token 优势的主要来源之一pinchtab click e3 --snap-diffclick ref按 ref 执行点击--snap-diff在同一次调用中返回仅变更元素的快照[]新增、[~]变更、移除的 ref 列在末尾Agent 无需再单独发一次snap就能确认导航结果。skill 中同时提醒导航触发型点击之后要用一次新快照验证不要对过期 ref 采取行动——导航会使旧 ref 失效这正是--snap-diff在此场景被强调的原因。验证含义导航发生且页面内容变化。例如点击Articles后URL 变为http://fixtures/articles.html页面内容从首页的欢迎文案切换为文章列表内容--snap-diff输出会显示大量[]新元素与旧 ref 的移除标记。0.5 Extract specific data按 ref 提取指定元素文本Read a specific elements text (e.g., a heading or paragraph by ref).Verify: Target elements text content is returned.第五步是精准读取根据 ref 读取某个指定元素如一个标题或段落的文本。PinchTab 的 selector 体系skills/pinchtab/SKILL.md的 Selectors 一节支持统一的选择器语法任何指向元素的命令都能使用Refe5—— 来自快照缓存最快CSS#login、.btn、[data-testidx]——document.querySelectorXPathxpath://button[idsubmit]—— CDP 搜索文本text:Sign In—— 可见文本匹配语义find:login button—— 自然语言经/find解析。自动识别规则裸eN→ ref#/./[...]→ CSS//→ XPath有歧义时使用显式前缀。具体到本步骤Agent 通常会直接使用第 0.2 步拿到的 refpinchtab text --ref e5 # 按 ref 读取元素文本示意形态验证含义目标元素的文本被正确返回。例如读取首页h1应返回PinchTab Benchmark Suite读取 hero 段落应包含Welcome to the Benchmark Test Suite——Agent 用返回值与任务描述比对即可确认提取正确。运行环境与工具链这 5 步如何在 Docker 中执行Group 0 不是孤立的手工脚本而是被tests/tools/下的完整基准测试工具链驱动。目录结构tests/tools/README.md如下tests/tools/ ├── runner/ # Go 基准测试 runnerAPI 循环、步骤记录、验证 ├── scripts/ # Shell 包装脚本 │ ├── runner # Go runner 的自构建包装 │ ├── pt # PinchTab Docker 包装 │ ├── ab # agent-browser Docker 包装 │ ├── baseline.sh # 确定性基线验证 │ └── ... ├── fixtures/ # 测试 HTML 页面经 http://fixtures/ 提供 ├── docker/ # 冒烟测试 Dockerfile ├── config/ # PinchTab 配置变体 ├── docker-compose.yml └── docker-compose.benchmark.yml关键环境约束来自tests/tools/README.md基准测试必须在 Docker 中运行端口9867token 为benchmark-tokenfixtures 通过http://fixtures/访问。Docker 环境保证每次运行可复现、无残留 profile/session、构建自当前源码、并与本地配置隔离。scripts/pt透明转发 PinchTab CLItests/tools/scripts/pt是一个透明包装脚本唯一职责是在基准 Docker 容器默认tools-pinchtab-1内运行原生pinchtabCLI并将宿主环境透传进去。它支持的可选环境变量变量作用默认值PINCHTAB_CONTAINERDocker 容器名tools-pinchtab-1PINCHTAB_SERVERPinchTab server 地址http://localhost:9867PINCHTAB_TOKENBearer tokenbenchmark-token设为空串表示不发送认证头PINCHTAB_SESSIONAgent session token未设置PINCHTAB_AGENT_IDAgent 标识未设置pt脚本还内置了step-end子命令的快捷转发当第一个参数是step-end时它自动注入--type pinchtab与--report-file从tests/benchmark/results/current_pinchtab_report.txt指针读取让 Agent 少打两个参数。Group 0 的每一步完成后Agent 都调用一次./scripts/runner step-end 0 1 answer ... pass verification notes这一步把记录答案与对照 oracle 验证合并为一次调用即 deep-dive 文档中所说的 step-end collapse本身就能为每次运行节省约 10~13 次 LLM 往返。scripts/runner自构建的 Go 步骤记录器tests/tools/scripts/runner是 Go runner 的自构建包装首次使用或源码变更后它把tests/tools/runner构建为scripts/.runner.bingitignored再转发参数。它转发step-end、record-step、verify-step、opt merge-reports、opt inject-usage、opt summarize等子命令完整的命令面在tests/tools/runner/main.go。fixture 页面任务的地基tests/tools/fixtures/下的每个 HTML 页面都内置了可验证的标记字符串作为 runner 的 oracle 判定依据。例如首页index.html含VERIFY_HOME_LOADED_12345article.html含VERIFY_ARTICLE_PAGE_41414登录成功页含VERIFY_LOGIN_SUCCESS_DASHBOARD。Group 0 的导航与阅读都发生在这些受控页面上——这也解释了 0.4 步点击导航链接后页面内容变化为何可被确定性地断言。如何复现 Group 0 的基准运行根据docs/benchmark.md与tests/tools/README.md从仓库根目录复现 Group 0 Group 1即 10 步基础范围的完整流程如下# 1. 确定性基线无需 API key约 30 秒验证基准环境本身可用 ./dev opt baseline # 2. PinchTab lane需要 Anthropic API key--groups 0,1 即选择 Group 0 与 Group 1 ANTHROPIC_API_KEY... ./dev bench pinchtab --groups 0,1 # 3. 对照 laneagent-browser同样需要 Anthropic API key ANTHROPIC_API_KEY... ./dev bench agent-browser --groups 0,1 # 4. 查看运行级 usage结果落在 tests/benchmark/results/ jq .run_usage tests/benchmark/results/pinchtab_benchmark_*.json jq .run_usage tests/benchmark/results/agent_browser_benchmark_*.json组选择逻辑在tests/tools/runner/internal/bench/tasks.go中--groups显式指定组号未指定时依次尝试 profile如common10 组 0~3、index 的 active 组、最后回退到扫描group-*.md文件。结果报告写入tests/benchmark/results/包括pinchtab_benchmark_YYYYMMDD_HHMMSS.json、_summary.md与命令追踪pinchtab_commands.ndjson。Agent 循环与测量方法这 5 步如何被计价docs/deep-dive/benchmark.md详细描述了 runner 驱动的 agent 循环每个步骤中runner 把任务描述与累积 transcript 发给 Anthropic模型输出 shell 命令./scripts/pt ...或./scripts/ab ...runner 在 lane 容器中执行并把结果追加进 transcript模型给出答案后由step-end记录并对照 oracle 验证循环直到全部步骤完成或达到--max-turns。Token 计量直接读取每次响应的 Anthropicusage对象并累加字段包括input_tokens未缓存输入、cache_creation_input_tokensprompt cache 写入、cache_read_input_tokenscache 命中、output_tokens与request_count。这是整个 agent 循环的端到端成本——系统提示、skill、工具调用、工具输出、推理与重试全部计入。**skill技能包**是两边 lane 都要注入的 Markdown 指令包教模型如何使用工具命令形态、ref 语法、快照格式、已知坑如点击后的导航 409、PinchTab 的--snap-diff格式。skill 位于每个请求的缓存前缀中按cache_read费率计费。为了公平基准只使用裁剪后的 skill 子集PinchTab 仅使用skills/pinchtab/SKILL.md约 14.5 KBagent-browser 由DownloadAgentBrowserSkill从 CLI 拉取后仅保留 header 与references/commands.md段见tests/tools/runner/internal/bench/prompt.go使两边的 skill 体积接近、聚焦工具面而非文档重量。上下文压缩也是控制成本的关键工具输出在回喂模型前被截断每次调用仅保留 2 行预览旧历史被压缩成基于基准报告的简短进度摘要lane setup 与 skill 被内联进缓存前缀避免 Agent 花未缓存的轮次去cat配置文件。Group 0 在整体基准结果中的位置Group 0 与 Group 1 共同构成 10 步的基础范围basic scopedocs/benchmark.md记录了 n5 的对比结果PinchTab 单次运行平均成本 $0.1024比 agent-browser$0.1132便宜9.5%API 请求数少23.0%30.2 vs 39.2总 token 少17.9%。差距的根源是结构性差异agent-browser 走先点击再快照的两步模式每个变更步骤要花两次 API 调用而 PinchTab 通过--snap/--snap-diff把动作与结果快照合并进一次往返同一步骤只花一次调用同时避免了每次多余往返对缓存前缀的重复读取cache-read 主导了 token 差距。当扩展到 6 组 24 步时docs/deep-dive/benchmark.md的 extended scope差距放大到19.6%Haiku 4.5与20.3%Sonnet 4.6请求数分别少 31.1% 与 29.4%——即点击→快照的额外往返随步数增长而复利放大且更强模型也无法规划掉这种工具面固有的开销。这也反过来印证了 Group 0 作为最少交互、最多观察的任务集是所有组中测量噪声最低、最适合作为对齐基准的起点。需要注意的是这些数字本身附带了任务集偏差、部分 skill 配置、样本量n5/n3/n2与 ~25–30% 的运行间方差等 caveats引用时应说明前提。小结Group 0 的五步任务导航 → 快照 → 读文本 → 点链接 → 按 ref 提取看似朴素实则是 PinchTab 基准测试体系的最小可行闭环它验证了浏览器连通性、快照 ref 机制、read-only 文本读取、点击后重新观察、以及按 ref 精准提取这五条 Agent 高频路径并全部建立在tests/tools/fixtures/的受控页面上、由tests/tools/runner驱动、按 Anthropicusage对象精确计价。如果你想亲手验证 PinchTab 的少往返、低 token设计从复现./dev bench pinchtab --groups 0,1开始再对照 group-00.md 用pinchtab nav --snap、pinchtab snap、pinchtab text、pinchtab click --snap-diff手工走一遍这 5 步是最直观的入门路径。赞分享【免费下载链接】pinchtabHigh-performance browser automation bridge and multi-instance orchestrator with advanced stealth injection and real-time dashboard.项目地址https://gitcode.com/gh_mirrors/pi/pinchtab点击查看免费下载相关推荐PinchTab 基准测试实战SPA 状态管理任务组Group 4的自动化验证全解PinchTab 基准测试实战SPA 状态管理任务组Group 4的自动化验证全解 本文围绕 PinchTab 项目内置的浏览器自动化基准测试中 SPAwgpu 保守光栅化实战用 CONSERVATIVE_RASTERIZATION 特性渲染被触碰到的每一个像素wgpu 保守光栅化实战用 CONSERVATIVE_RASTERIZATION 特性渲染被触碰到的每一个像素 本文以 wgpu 官方示例 conservDaft Parquet 基准测试实战本地与 S3 读取、Row Group、谓词下推与编解码的对比评测方法Daft Parquet 基准测试实战本地与 S3 读取、Row Group、谓词下推与编解码的对比评测方法 本文基于 Daft 的 Parquet 基准测试大数据数据分析数据工程AI 应用上一篇开源项目推荐sciplot下一篇HunyuanWorld-Voyager腾讯开源革命性3D场景生成框架完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PinchTab 基准测试实战解析：Group 0 基础导航与页面读取的五步任务集
【免费下载链接】pinchtabHigh-performance browser automation bridge and multi-instance orchestrator with advanced stealth injection and real-time dashboard.项目地址https://gitcode.com/gh_mirrors/pi/pinchtab点击查看免费下载PinchTab 是一套高性能浏览器自动化桥接与多实例编排工具其仓库内置了一套结构化的 AI Agent 基准测试体系tests/benchmark/用于衡量 LLM Agent 驱动浏览器时的端到端 token 成本与任务完成率。本文聚焦其中第一个任务组Group 0: Basic Navigation Reading逐条拆解它的 5 个步骤——导航、快照、读取文本、点击链接、按 ref 提取数据——并结合tests/tools/下的 fixture 页面、Go runner 源码与 CLI skill 说明其运行机制与验证方式。读完本文你将掌握如何理解这套基准任务组、如何用 PinchTab CLI 手工复现每一步以及它在这套导航与阅读工作量上被如何打分。基准任务组的整体定位在 PinchTab 仓库中基准任务以 Markdown 分组文件的形式存放在tests/benchmark/目录下tests/benchmark/index.md是任务索引它明确了每个组的定位与步数组主题步数group-00.mdBasic Navigation Reading基础导航与阅读5group-01.mdForms Interactions表单与交互5group-02.mdSelect Dropdowns选择与下拉框3group-03.mdScrolling Pagination滚动与分页3group-04.mdAuthentication认证3group-05.mdE-commerce Flow电商流程5其中 Group 0 是所有 Agent 任务集的第一站它不涉及表单、下拉、滚动等复杂交互只验证 Agent 能否完成打开页面 → 观察页面 → 读取内容 → 点击导航 → 提取指定数据这条最基本的浏览器操作链路。整个仓库的基准测试docs/benchmark.md与docs/deep-dive/benchmark.md在对比 PinchTab 与 agent-browser 两条工具面lane时正是以 Group 0 Group 1 共 10 步作为基础范围basic scope的锚点任务集。Group 0 的五步任务详解tests/benchmark/group-00.md本身非常精简每个步骤只给出任务描述与一条验证标准Verify。但结合 fixture 页面、CLI 命令与 runner 代码每一步都能还原为一条可手工复现的操作。0.1 Navigate to page验证浏览器连通性Navigate tohttp://fixtures/to confirm browser connectivity.Verify: Page loads successfully and contains benchmark content.这一步是整个基准测试的启动动作Agent 通过 PinchTab CLI 导航到基准 fixture 首页http://fixtures/。该地址由 Docker Compose 中的fixtures服务提供对应的实际页面是tests/tools/fixtures/index.html其标题为 PinchTab Benchmark - Home正文包含可验证的标记文本VERIFY_HOME_LOADED_12345以及Welcome to the Benchmark Test Suite等内容。在 PinchTab 的 skillskills/pinchtab/SKILL.md中导航与观察被设计为一条命令完成pinchtab nav http://fixtures/ --snapnav url --snap会启动本地 server如需要、完成导航并在同一次调用中返回 tab ID 与一份可交互的快照——这正是 PinchTab 在基准测试中省 API 往返的关键设计。而在 runner 的 lane 配置里tests/tools/runner/internal/bench/prompt.go的LanePromptConfigPinchTab 的 bootstrap 命令同样是./scripts/pt nav http://fixtures/ --snap。验证含义页面成功加载且包含基准内容即首页中应出现PinchTab Benchmark Suite标题、Welcome to the Benchmark Test Suite与VERIFY_HOME_LOADED_12345标记证明 Agent 与浏览器工具之间的通路是通的。0.2 Take snapshot捕获带 ref 的可交互快照Capture a DOM snapshot with actionable refs.Verify: Snapshot returns structured content with ref IDs.第二步要求 Agent 捕获带可操作引用actionable refs的 DOM 快照。PinchTab 的快照机制是它的核心抽象快照把页面上的可交互元素链接、按钮、输入框、标题等压缩成紧凑格式并为每个元素分配一个稳定 ref 标识如e5、e12Agent 后续的所有点击、填充、提取都通过这些 ref 进行。对应的命令在 skill 中给出pinchtab snap # 默认紧凑交互格式interactive headings pinchtab snap -i -c # 命令行手册中展示的交互式紧凑变体 pinchtab snap --full # 调试用所有节点以 JSON 输出快照输出的典型形态来自 skill 的--snap-diff示例snap格式相同# Page Title | URL | 57 nodes | 2 ~1 -0 e0:link Home e5:button Submit [] e12:textbox valupdated [~] # removed: e99验证含义快照返回结构化内容且包含 ref ID。换句话说Agent 必须拿到至少一个eN形式的 ref才能证明它拥有后续步骤点击、提取的手柄。在基准环境里这一步对应 fixture 首页的快照——首页的导航区包含#nav-articles、#nav-search、#nav-form、#nav-dashboard、#nav-shop等链接都会以 ref 形式出现在快照中。0.3 Read page text提取页面主文本Extract the main text content from the current page.Verify: Text content is returned without errors.第三步是纯读取操作把当前页面的正文文本取出来。PinchTab 的 skill 明确指出当只需要文本、不需要对 ref 采取行动时使用pinchtab text而非snap——这是 read-only 观察最省 token 的路径pinchtab text此外--text观察标志也可用于click、fill、select、press、back、forward、reload但不支持nav与scroll在需要散文内容用于验证、且不想带出快照时使用。验证含义文本内容无错误地返回。对于 fixture 首页返回值应包含Welcome to the Benchmark Test Suite与Benchmark Fixtures v1.0等可见文本Agent 可以据此确认读取链路正常。0.4 Click a link点击导航链接并确认页面变化Click a navigation link on the fixtures page (e.g., a More Info or numbered link).Verify: Navigation occurs and page content changes.第四步要求 Agent 点击 fixture 页面上的一个导航链接例如 More Info 或编号链接并验证发生了导航、页面内容发生了变化。在 Group 0 的语境下导航链接通常就是首页nav区里的链接Articles、Search、Form、Dashboard、Shop它们分别指向tests/tools/fixtures/下的articles.html、search.html、form.html、dashboard.html、ecommerce.html。PinchTab 的点击与观察合并为一次调用这是它在基准测试中 token 优势的主要来源之一pinchtab click e3 --snap-diffclick ref按 ref 执行点击--snap-diff在同一次调用中返回仅变更元素的快照[]新增、[~]变更、移除的 ref 列在末尾Agent 无需再单独发一次snap就能确认导航结果。skill 中同时提醒导航触发型点击之后要用一次新快照验证不要对过期 ref 采取行动——导航会使旧 ref 失效这正是--snap-diff在此场景被强调的原因。验证含义导航发生且页面内容变化。例如点击Articles后URL 变为http://fixtures/articles.html页面内容从首页的欢迎文案切换为文章列表内容--snap-diff输出会显示大量[]新元素与旧 ref 的移除标记。0.5 Extract specific data按 ref 提取指定元素文本Read a specific elements text (e.g., a heading or paragraph by ref).Verify: Target elements text content is returned.第五步是精准读取根据 ref 读取某个指定元素如一个标题或段落的文本。PinchTab 的 selector 体系skills/pinchtab/SKILL.md的 Selectors 一节支持统一的选择器语法任何指向元素的命令都能使用Refe5—— 来自快照缓存最快CSS#login、.btn、[data-testidx]——document.querySelectorXPathxpath://button[idsubmit]—— CDP 搜索文本text:Sign In—— 可见文本匹配语义find:login button—— 自然语言经/find解析。自动识别规则裸eN→ ref#/./[...]→ CSS//→ XPath有歧义时使用显式前缀。具体到本步骤Agent 通常会直接使用第 0.2 步拿到的 refpinchtab text --ref e5 # 按 ref 读取元素文本示意形态验证含义目标元素的文本被正确返回。例如读取首页h1应返回PinchTab Benchmark Suite读取 hero 段落应包含Welcome to the Benchmark Test Suite——Agent 用返回值与任务描述比对即可确认提取正确。运行环境与工具链这 5 步如何在 Docker 中执行Group 0 不是孤立的手工脚本而是被tests/tools/下的完整基准测试工具链驱动。目录结构tests/tools/README.md如下tests/tools/ ├── runner/ # Go 基准测试 runnerAPI 循环、步骤记录、验证 ├── scripts/ # Shell 包装脚本 │ ├── runner # Go runner 的自构建包装 │ ├── pt # PinchTab Docker 包装 │ ├── ab # agent-browser Docker 包装 │ ├── baseline.sh # 确定性基线验证 │ └── ... ├── fixtures/ # 测试 HTML 页面经 http://fixtures/ 提供 ├── docker/ # 冒烟测试 Dockerfile ├── config/ # PinchTab 配置变体 ├── docker-compose.yml └── docker-compose.benchmark.yml关键环境约束来自tests/tools/README.md基准测试必须在 Docker 中运行端口9867token 为benchmark-tokenfixtures 通过http://fixtures/访问。Docker 环境保证每次运行可复现、无残留 profile/session、构建自当前源码、并与本地配置隔离。scripts/pt透明转发 PinchTab CLItests/tools/scripts/pt是一个透明包装脚本唯一职责是在基准 Docker 容器默认tools-pinchtab-1内运行原生pinchtabCLI并将宿主环境透传进去。它支持的可选环境变量变量作用默认值PINCHTAB_CONTAINERDocker 容器名tools-pinchtab-1PINCHTAB_SERVERPinchTab server 地址http://localhost:9867PINCHTAB_TOKENBearer tokenbenchmark-token设为空串表示不发送认证头PINCHTAB_SESSIONAgent session token未设置PINCHTAB_AGENT_IDAgent 标识未设置pt脚本还内置了step-end子命令的快捷转发当第一个参数是step-end时它自动注入--type pinchtab与--report-file从tests/benchmark/results/current_pinchtab_report.txt指针读取让 Agent 少打两个参数。Group 0 的每一步完成后Agent 都调用一次./scripts/runner step-end 0 1 answer ... pass verification notes这一步把记录答案与对照 oracle 验证合并为一次调用即 deep-dive 文档中所说的 step-end collapse本身就能为每次运行节省约 10~13 次 LLM 往返。scripts/runner自构建的 Go 步骤记录器tests/tools/scripts/runner是 Go runner 的自构建包装首次使用或源码变更后它把tests/tools/runner构建为scripts/.runner.bingitignored再转发参数。它转发step-end、record-step、verify-step、opt merge-reports、opt inject-usage、opt summarize等子命令完整的命令面在tests/tools/runner/main.go。fixture 页面任务的地基tests/tools/fixtures/下的每个 HTML 页面都内置了可验证的标记字符串作为 runner 的 oracle 判定依据。例如首页index.html含VERIFY_HOME_LOADED_12345article.html含VERIFY_ARTICLE_PAGE_41414登录成功页含VERIFY_LOGIN_SUCCESS_DASHBOARD。Group 0 的导航与阅读都发生在这些受控页面上——这也解释了 0.4 步点击导航链接后页面内容变化为何可被确定性地断言。如何复现 Group 0 的基准运行根据docs/benchmark.md与tests/tools/README.md从仓库根目录复现 Group 0 Group 1即 10 步基础范围的完整流程如下# 1. 确定性基线无需 API key约 30 秒验证基准环境本身可用 ./dev opt baseline # 2. PinchTab lane需要 Anthropic API key--groups 0,1 即选择 Group 0 与 Group 1 ANTHROPIC_API_KEY... ./dev bench pinchtab --groups 0,1 # 3. 对照 laneagent-browser同样需要 Anthropic API key ANTHROPIC_API_KEY... ./dev bench agent-browser --groups 0,1 # 4. 查看运行级 usage结果落在 tests/benchmark/results/ jq .run_usage tests/benchmark/results/pinchtab_benchmark_*.json jq .run_usage tests/benchmark/results/agent_browser_benchmark_*.json组选择逻辑在tests/tools/runner/internal/bench/tasks.go中--groups显式指定组号未指定时依次尝试 profile如common10 组 0~3、index 的 active 组、最后回退到扫描group-*.md文件。结果报告写入tests/benchmark/results/包括pinchtab_benchmark_YYYYMMDD_HHMMSS.json、_summary.md与命令追踪pinchtab_commands.ndjson。Agent 循环与测量方法这 5 步如何被计价docs/deep-dive/benchmark.md详细描述了 runner 驱动的 agent 循环每个步骤中runner 把任务描述与累积 transcript 发给 Anthropic模型输出 shell 命令./scripts/pt ...或./scripts/ab ...runner 在 lane 容器中执行并把结果追加进 transcript模型给出答案后由step-end记录并对照 oracle 验证循环直到全部步骤完成或达到--max-turns。Token 计量直接读取每次响应的 Anthropicusage对象并累加字段包括input_tokens未缓存输入、cache_creation_input_tokensprompt cache 写入、cache_read_input_tokenscache 命中、output_tokens与request_count。这是整个 agent 循环的端到端成本——系统提示、skill、工具调用、工具输出、推理与重试全部计入。**skill技能包**是两边 lane 都要注入的 Markdown 指令包教模型如何使用工具命令形态、ref 语法、快照格式、已知坑如点击后的导航 409、PinchTab 的--snap-diff格式。skill 位于每个请求的缓存前缀中按cache_read费率计费。为了公平基准只使用裁剪后的 skill 子集PinchTab 仅使用skills/pinchtab/SKILL.md约 14.5 KBagent-browser 由DownloadAgentBrowserSkill从 CLI 拉取后仅保留 header 与references/commands.md段见tests/tools/runner/internal/bench/prompt.go使两边的 skill 体积接近、聚焦工具面而非文档重量。上下文压缩也是控制成本的关键工具输出在回喂模型前被截断每次调用仅保留 2 行预览旧历史被压缩成基于基准报告的简短进度摘要lane setup 与 skill 被内联进缓存前缀避免 Agent 花未缓存的轮次去cat配置文件。Group 0 在整体基准结果中的位置Group 0 与 Group 1 共同构成 10 步的基础范围basic scopedocs/benchmark.md记录了 n5 的对比结果PinchTab 单次运行平均成本 $0.1024比 agent-browser$0.1132便宜9.5%API 请求数少23.0%30.2 vs 39.2总 token 少17.9%。差距的根源是结构性差异agent-browser 走先点击再快照的两步模式每个变更步骤要花两次 API 调用而 PinchTab 通过--snap/--snap-diff把动作与结果快照合并进一次往返同一步骤只花一次调用同时避免了每次多余往返对缓存前缀的重复读取cache-read 主导了 token 差距。当扩展到 6 组 24 步时docs/deep-dive/benchmark.md的 extended scope差距放大到19.6%Haiku 4.5与20.3%Sonnet 4.6请求数分别少 31.1% 与 29.4%——即点击→快照的额外往返随步数增长而复利放大且更强模型也无法规划掉这种工具面固有的开销。这也反过来印证了 Group 0 作为最少交互、最多观察的任务集是所有组中测量噪声最低、最适合作为对齐基准的起点。需要注意的是这些数字本身附带了任务集偏差、部分 skill 配置、样本量n5/n3/n2与 ~25–30% 的运行间方差等 caveats引用时应说明前提。小结Group 0 的五步任务导航 → 快照 → 读文本 → 点链接 → 按 ref 提取看似朴素实则是 PinchTab 基准测试体系的最小可行闭环它验证了浏览器连通性、快照 ref 机制、read-only 文本读取、点击后重新观察、以及按 ref 精准提取这五条 Agent 高频路径并全部建立在tests/tools/fixtures/的受控页面上、由tests/tools/runner驱动、按 Anthropicusage对象精确计价。如果你想亲手验证 PinchTab 的少往返、低 token设计从复现./dev bench pinchtab --groups 0,1开始再对照 group-00.md 用pinchtab nav --snap、pinchtab snap、pinchtab text、pinchtab click --snap-diff手工走一遍这 5 步是最直观的入门路径。赞分享【免费下载链接】pinchtabHigh-performance browser automation bridge and multi-instance orchestrator with advanced stealth injection and real-time dashboard.项目地址https://gitcode.com/gh_mirrors/pi/pinchtab点击查看免费下载相关推荐PinchTab 基准测试实战SPA 状态管理任务组Group 4的自动化验证全解PinchTab 基准测试实战SPA 状态管理任务组Group 4的自动化验证全解 本文围绕 PinchTab 项目内置的浏览器自动化基准测试中 SPAwgpu 保守光栅化实战用 CONSERVATIVE_RASTERIZATION 特性渲染被触碰到的每一个像素wgpu 保守光栅化实战用 CONSERVATIVE_RASTERIZATION 特性渲染被触碰到的每一个像素 本文以 wgpu 官方示例 conservDaft Parquet 基准测试实战本地与 S3 读取、Row Group、谓词下推与编解码的对比评测方法Daft Parquet 基准测试实战本地与 S3 读取、Row Group、谓词下推与编解码的对比评测方法 本文基于 Daft 的 Parquet 基准测试大数据数据分析数据工程AI 应用上一篇开源项目推荐sciplot下一篇HunyuanWorld-Voyager腾讯开源革命性3D场景生成框架完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考