技能介绍

问题：重复浏览器操作的成本与信任困境

很多需要登录的浏览器任务（比如每周批量导出内部报表、重复提交社交动态）有两个绕不开的痛点：一是每次都要驱动实时模型重新解析页面，token 消耗像无底洞；二是登录会话和页面内容会被送到远端浏览器池，凭据不得不跨越信任边界。就算用 Playwright-MCP 这类工具，也逃不过"每次重跑实时模型"的逻辑——当任务从"偶尔做一次"变成"每周都要来"时，成本和风险都会指数级上升。

Tap 的工作逻辑：录制一次，确定性重放

Tap 的核心思路是把"实时模型驱动"变成"编译后的计划重放"，整个过程分为三个关键步骤：

先查注册表：已保存的 tap 以 tap://{site}/{name} 的形式存储为 Resources。调用 resources/list 查询，若存在匹配项，直接用 resources/read 查看参数 schema，然后通过 run({ ref, args }) 执行——全程不需要 AI 参与。
首次录制（capture）：如果没有现成 tap，用 capture { url, intent, site, name } 录制。此时 AI 仅在解析页面意图时介入，最终会把操作逻辑编译成 ~/.tap/plans/{site}/{name}.plan.json 文件，存储在本地。
重放与验证：后续执行时直接调用 run({ ref, args })，系统会在用户真实的 Chrome 浏览器中按计划执行，零 token 消耗。若担心网站改版导致计划失效，可先运行只读的 verify 命令确认——它不会执行任何写操作。

适用边界与注意事项

不是所有任务都需要 Tap：一次性的公开页面操作（比如偶尔查一次天气），用实时驱动或普通抓取更轻量，没必要录制。
已登录站点的前置条件：银行、内部后台等需要登录的网站，必须先通过 tap-setup 配置 Chrome 桥接——这一步会注册本地二进制并打开扩展页，用户只需在 Chrome 商店添加扩展并授权，认证完全依赖浏览器已有的登录状态，Tap 从不索取或传输凭据。
读写类 plan 的差异：读类 plan（比如查询订单状态）会返回诚实的结果（{ outcome, reason }），不能把 outcome:"empty" 当作成功；写类 plan（比如发帖、提交表单）需要额外的确认步骤和后置条件——ok:true 仅代表执行完成，不代表操作生效，必须用后置条件验证结果。
错误处理：所有操作都会返回错误信封 { ok:false, kind, message, next? }，如果有 next 字段就按指示重试，否则直接上报用户。