企业官网建设流程全解析

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 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 的 skill（skills/pinchtab/SKILL.md）中，导航与观察被设计为一条命令完成：

pinchtab nav http://fixtures/ --snap

nav <url> --snap会启动本地 server（如需要）、完成导航，并在同一次调用中返回 tab ID 与一份可交互的快照——这正是 PinchTab 在基准测试中省 API 往返的关键设计。而在 runner 的 lane 配置里（tests/tools/runner/internal/bench/prompt.go的LanePromptConfig），PinchTab 的 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、e12），Agent 后续的所有点击、填充、提取都通过这些 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 val="updated" [~] # 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-diff

• click <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 element's text (e.g., a heading or paragraph by ref).Verify: Target element's text content is returned.

第五步是精准读取：根据 ref 读取某个指定元素（如一个标题或段落）的文本。PinchTab 的 selector 体系（skills/pinchtab/SKILL.md的 "Selectors" 一节）支持统一的选择器语法，任何指向元素的命令都能使用：

• Ref：e5—— 来自快照缓存，最快；
• CSS：#login、.btn、[data-testid="x"]——document.querySelector；
• XPath：xpath://button[@id="submit"]—— CDP 搜索；
• 文本：text:Sign In—— 可见文本匹配；
• 语义：find:login button—— 自然语言，经/find解析。

自动识别规则：裸eN→ ref，#/./[...]→ CSS，//→ XPath；有歧义时使用显式前缀。具体到本步骤，Agent 通常会直接使用第 0.2 步拿到的 ref：

pinchtab 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 基准测试 runner（API 循环、步骤记录、验证） ├── 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 中运行，端口9867，token 为benchmark-token，fixtures 通过http://fixtures/访问。Docker 环境保证每次运行可复现、无残留 profile/session、构建自当前源码、并与本地配置隔离。

scripts/pt：透明转发 PinchTab CLI

tests/tools/scripts/pt是一个透明包装脚本，唯一职责是在基准 Docker 容器（默认tools-pinchtab-1）内运行原生pinchtabCLI，并将宿主环境透传进去。它支持的可选环境变量：

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.bin（gitignored）再转发参数。它转发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_12345，article.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. 对照 lane：agent-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_tokens（prompt cache 写入）、cache_read_input_tokens（cache 命中）、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 KB），agent-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 scope），docs/benchmark.md记录了 n=5 的对比结果：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 配置、样本量（n=5/n=3/n=2）与 ~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 步，是最直观的入门路径。