用 Playwright 代码直接驱动 AI Agent 才是降低 Token 成本的正确姿势
最近在实测 Browser Tools SDK 后发现，它解决成本问题的逻辑非常简洁：不再尝试通过一层层抽象的 API 来传指令，而是直接把执行权交给模型去写 Playwright 代码。
这个方案的核心在于它只暴露了 6 个精简的工具，其中最关键的是 browser_snapshot（高效快照）和 browser_exec（直接执行代码）。由于主流大模型（如 Claude 3.5 或 GPT-4o）在训练阶段接触过海量的 Playwright 源代码，它们写脚本的能力其实远强于通过 API 传递“点击某个 ID 的元素”这种指令。直接让模型生成代码并执行，反而比通过中间层转换要稳得多。
从实测数据来看，这种方案在 26 个真实场景任务中的通过率能够与目前顶级的浏览器工具持平，但最惊人的是成本控制——单个任务的成本比次优方案低了约 55%。对于需要大规模部署的生产环境 Agent 来说，这 55% 的成本下降直接决定了项目是否具有商业可行性。
在实际部署时，它的集成路径非常短。如果你使用的是 TypeScript，只需要几行代码就能将浏览器能力挂载到 AI SDK 中。例如，通过 LocalBrowserProvider 调用本地的 Chromium 实例，配合 createAiSdkBrowserTools 即可快速完成配置：
import { createAiSdkBrowserTools } from "libretto-browser-tools/ai-sdk";
import { LocalBrowserProvider } from "libretto-browser-tools";
const { tools } = createAiSdkBrowserTools(new LocalBrowserProvider());
const result = await generateText({
model: anthropic("claude-sonnet-4-5"),
tools,
prompt: "Go to Hacker News and tell me the top story",
});这里有几个技术细节值得关注。首先是快照机制的优化，它通过精简 DOM 信息的过滤算法，避免了冗余 HTML 标签在上下文中的刷屏，这也是 Token 占用量大幅下降的主因。其次是灵活的提供者模式，虽然示例中使用的是本地运行，但它同样支持接 Browserbase 等云端浏览器服务，这意味着你可以根据任务的并发量在本地和云端之间无缝切换。
此外，该 SDK 原生支持 AI SDK 和 Pi，兼容性处理得很好。如果你厌倦了调试那些笨重的浏览器插件，或者在尝试构建一个能够低成本运行的自动化 Agent 工作流，这种“以代码执行代替 API 指令”的轻量化路径非常值得尝试。
对于开发者而言，你可以直接参考 https://libretto.sh/docs/browser-tools/quickstart 快速开始。在实际运行中，建议重点观察 browser_snapshot 返回的页面片段，你会发现它在保留关键结构的同时，剔除了大量干扰模型判断的冗余代码。
