随着越来越多的 Agent 开始直接操作浏览器，很多人开始关心：从 Codex 的 Chrome 控制到 Tabbit CLI，不同的 Browser Use 方案如何影响任务的执行效率与使用体验？它们背后的实现原理又是什么？
本文从浏览器自动化的技术演进讲起，介绍 Tabbit CLI 的设计思路与工程实践，以及我们如何让 Tabbit CLI 相比 Codex Chrome，不仅在耗时与准确度上占优，还将输入 token 用量减少了 47.2%，工具调用减少了 16.8%。
我们希望通过分享这些经验，与社区共同探索如何提高 Agent 的能力，让用户获得更好的 Tabbit CLI 使用体验。
全文目录如下，可选自己感兴趣的部分跳读：
1. 从浏览器自动化到 Agent
1.1 WebDriver 与 CDP
1.2 自动化工具、扩展接口与浏览器内置能力
1.3 现有工具与日常使用之间的距离
2. Tabbit CLI 的设计
2.1 从 Agent 到任务页面
2.2 浏览器持有运行时与任务边界
2.3 Agent 如何工作
3. 工作实例：处理快递丢件订单
4. Tabbit CLI 与 Skill 的实践经验
5. 评测结果与适用范围
5.1 评测设置与结果
5.2 从模型能力到任务效率
参考资料
作者：薄佑思，Tabbit 工程师
1. 从浏览器自动化到 Agent
1.1 WebDriver 与 CDP
让程序控制浏览器，一直是网页测试、数据采集和重复操作的常见需求。
Agent 出现之前，开发者就已经通过自动化脚本打开网页、查找元素、填写表单并核对结果。浏览器自动化最早服务于网页测试。
WebDriver 源自 Selenium 项目，后来成为 W3C 标准。测试程序通过 HTTP 发送「打开网址」「查找元素」「点击」这样的命令，由各浏览器自己的驱动程序执行。Chrome 的驱动程序被称为 ChromeDriver，它在内部把 WebDriver 命令翻译成 CDP（Chrome DevTools Protocol） 调用。
CDP 是 Chromium 为开发者工具准备的调试协议，DevTools 面板里的页面结构、网络请求和控制台都经由它获得。
图 1 - CDP 客户端发送创建新页面命令 Target.createTarget 打开新标签页，浏览器创建标签页并开始加载，返回其 targetId。图中的标识和端口号为示例值。
1.2 自动化工具、扩展接口与浏览器内置能力
传统 WebDriver 以请求和响应为主，不主动推送页面事件；CDP 提供的命令则较为底层，表达复杂操作时需要组合多条命令。
以发送鼠标输入为例，调用方要计算坐标，再分别发送按下和抬起。按钮何时可以点击、页面是否已经刷新，也要由调用方自行判断；页面内的跨进程 iframe 还需单独建立会话管理。
Puppeteer（2017 年，Chrome 团队）和 Playwright（2020 年，微软）将这些底层能力封装为页面、元素和动作接口，把定位、等待等工作做进库里。下面的 Playwright 代码在对话框中按角色和名称找到「确认补发」的按钮，等它可以点击时再点击，然后等待页面显示成功：
这里的 Locator 保存的是查找规则，而不是某个节点或坐标，每次操作时重新定位，页面重排后依然有效（图 2）。
图 2 - 页面重排后，Locator 在操作时重新查找目标。
除了通过外部程序控制浏览器，Chrome 也提供扩展接入和浏览器内置的路径。浏览器内置的路径以 Chromium 的 Actor 框架为代表，由浏览器自身组织并执行网页操作。chrome.debugger 是扩展调用 CDP 的接口：扩展取得调试权限并附着到目标标签页后，就能发送命令、接收事件，无需用户另开远程调试端口。
1.3 现有工具与日常使用之间的距离
这些工具已经能完成打开网页、点击、输入等操作，但通常面向由程序管理浏览器的测试和采集环境。
以 Playwright 为例，脚本可以启动一个没有用户现有登录状态的新环境，按需切换标签页、调整页面尺寸，结束后关闭自己启动的浏览器。
这适合独立运行的测试，但不适合需要与用户共用浏览器的 Agent。
Tabbit CLI 的初衷，是让用户继续使用熟悉的 Agent 和模型，直接在日常使用的 Tabbit 浏览器中完成网页任务，也尽量不打断正常浏览。
2. Tabbit CLI 的设计
2.1 从 Agent 到任务页面
在 Agent 中，模型通过工具调用（tool call）操作外部环境，由宿主程序执行后把结果交回。
工具可以是执行 bash 命令的 shell 工具，也可以是扩展或 MCP 服务注册的专用工具（如 js ）；Skill 则是供模型按需读取的工具使用说明。
因此，让 Agent 操作浏览器，关键在于提供什么样的工具，以及这个工具怎样连接浏览器。
前文介绍的 CDP 可以直接控制浏览器，但通过远程调试端口连接时，需要先以相应配置启动浏览器、开放端口，再把连接地址交给调用方。
对于用户日常使用的浏览器，这增加了配置成本，也受到默认 Profile 的调试限制：Chrome 自 136 版起，不再允许对默认 Profile 开启远程调试端口。
因此，Browser Use 等产品通常会封装连接过程，或通过扩展等方式接入，避免让用户和 Agent 直接管理底层连接。几种典型路径如下：
通过浏览器扩展接入 —— Codex 的 ChatGPT 浏览器扩展。
Agent 调用 js 工具，程序在 Codex 会话的 Node REPL 中执行，再通过 Native Messaging（浏览器扩展与本机程序的通信机制）把操作交给扩展。扩展使用 chrome.debugger 控制标签页，无需用户开放远程调试端口。
通过本机守护进程连接调试端口 —— Browser Use CLI。
Agent 调用命令行，由常驻的本机进程管理浏览器连接，再经 CDP 操作本机 Chrome，也可以接入云端浏览器。这条路径封装了连接细节，但连接本机 Chrome 时仍依赖调试端口。
通过命令行与扩展配合接入——BrowserSkill。
Agent 调用 bsk 命令，请求经本机守护进程和 WebSocket 送到 Chrome 或 Edge 中的扩展，再由扩展操作页面。命令行提供通用调用入口，扩展负责连接浏览器。
Tabbit 采用 CLI 加 Skill 作为入口，但把持续执行环境放在浏览器侧，由浏览器经私有通道控制任务页面。这样，不同 Agent 可以使用同一个入口，任务状态也不必依附于某个 Agent 会话。
Agent 始终调用同一个 tabbit-cli，由它选择目标浏览器实例。Tabbit 会检测本机已安装的 Agent，把 Skill 安装到它们的 Skill 目录，覆盖 Claude Code、Codex、Cursor、Gemini CLI 等 25 类产品，不修改这些 Agent 的配置。选择 CLI 作为入口，主要基于以下两点：
兼容多数 Agent 的现有调用能力。
多数 Agent 已支持通过 bash 等 shell 执行命令，无需单独配置 MCP 服务或安装插件。训练数据中丰富的 shell 代码也让模型更熟悉这类调用方式，有助于减少命令编写错误。
由 CLI 封装浏览器通信，降低接入与权限管理的复杂度。
部分 Agent 的工具接口或沙箱不支持直接访问 Unix socket；直接开放浏览器控制 socket，如果缺少身份校验和任务范围限制，还可能带来越权操作风险。Tabbit 由 CLI 统一提交请求，浏览器校验任务与页面归属，Agent 无需直接连接底层控制接口，也不依赖扩展或公开调试端口。
图 3 - 同一个工作循环，不同的接入与运行时归属。图中省略内部通信细节，箭头同时表示请求和结果往返。
Agent 通过命令行 heredoc（here-document） 把一段 JavaScript 交给用户自己的 Tabbit 执行，程序里默认调用原版的 Playwright 代码。每个任务在浏览器里对应一组页面和一个持续的执行环境，在任务有效期内，多次调用之间的页面和状态可以保留；每次调用返回一份结构化结果。下面是一段完整的调用示例：
将程序提交与结果查询分开。 浏览器任务可能比 Agent 的一次工具调用持续得更久：命令行已经超时，页面上的操作却仍在执行。如果直接重试，就可能重复提交订单。因此，Tabbit 由浏览器持有执行状态和结果，让 Agent 在调用中断后继续查询，并在同一任务内通过请求标识避免重复执行同一次提交。这样，任务执行不必依赖命令行连接始终保持，也为异常后的核对与恢复提供了依据。
2.2 浏览器持有运行时与任务边界
浏览器管理执行服务，各任务分别保存状态。
Tabbit 由浏览器启动并维护 CLI 执行服务，为每个任务分配独立的 Worker，分别保存程序变量、页面对象和执行结果，避免多个任务混用状态。
单个任务超时后，可以停止其执行；服务异常退出时，浏览器会尝试重新启动，Agent 无需自行维护后台进程。
这种隔离针对任务的执行状态，并不意味着每个任务拥有独立的浏览器或账号环境；服务重启后，页面可以重新接手，但内存中的进度不会自动恢复，需要先核对业务状态。
图 4 - 执行环境与页面边界：左侧 Worker 保存各自的程序状态，右侧浏览器管理真实页面并校验归属；「虚拟浏览器」是任务可见的对象范围，并非另开一个浏览器。
按任务限定页面范围。 Tabbit 为每个任务构建一个「虚拟浏览器」：它只包含当前任务的页面，这些页面仍在用户的真实浏览器中运行。Agent 只能操作虚拟浏览器内的页面，关闭整个浏览器等管理命令也受到限制。用户的其他标签页在这个虚拟浏览器中不可见、不可操作。这样设计有三个好处：任务复用用户登录态；用户可以照常浏览；执行环境独立于 Agent 会话，在任务有效期内，即使 Agent 重启或更换，也能继续使用原有页面和状态。
任务生命周期与边界。 命名任务空闲 90 秒后会释放页面归属、清空 JavaScript 变量；排队或执行中的程序不按空闲过期。页面会保留，可重新认领。Agent 也可以主动结束任务，并释放执行环境、回执和结果资源；浏览器或运行时重启后，内存中的进度不会自动恢复。任务隔离约束 Agent 的访问范围，用户仍可操作同一页面，人工改动后，Agent 需重新观察、核对，然后继续提交。
2.3 Agent 如何工作
Agent 通常通过「观察—执行—核对」的循环操作网页：先观察页面，由模型决定下一步，再由工具执行动作，最后核对结果。
观察、操作和核对可以通过三种方式完成：
语义方式读取页面提供的控件信息，例如「角色是按钮、名称是确认补发」，按角色和名称找到目标，再模拟点击或输入；
视觉方式查看页面截图，识别目标在画面中的位置，再按坐标点击或拖动；
脚本方式在网页里执行 JavaScript，直接查询页面的元素结构（DOM），读取数据或调用元素的点击等方法。
同一个任务中通常组合使用这几种方式，例如先按按钮名称进入列表，再用脚本批量读取数据。图 5 以同一个「确认补发」按钮为例，对照三种方式怎样观察、怎样操作。
图 5 - 同一个按钮的三种执行方式。三者各有局限：语义方式依赖页面提供正确的角色和名称，遇到同名控件要先限定范围；视觉方式需要图像输入支持，页面滚动或重排后坐标可能失效；脚本方式依赖 DOM 结构，页面改版后查询规则可能需要调整，脚本触发的点击也不等同于真实输入。
在设计 Tabbit CLI 的过程中，我们分析了 Playwright MCP、Browser Use、Codex 浏览器扩展等同类产品，也在 Chromium 内部实验了 Actor 框架。
在此基础上，我们选择让模型用熟悉的 Playwright 写程序，由用户自己的浏览器持有执行环境和任务边界，每次调用返回结构化结果。上述语义、视觉和脚本方式，都可以在这套环境中组合使用。
保留原生 Playwright 的语法，在现有能力上增补。 沿用 Playwright，既能让模型复用熟悉的写法，减少理解自定义接口所需的上下文，也能复用它在元素重新定位、操作时机和可操作性检查等方面的成熟能力。
Actor 是 Chromium 内置的新网页操作框架，我们曾尝试以 Actor 作为 Playwright 的执行后端，代替 CDP 引擎在浏览器内部执行具体的页面操作。
实验表明，重新实现操作层，仍需解决 Playwright 已经较好解决的各类问题，且与基于 CDP 的实现存在行为差异，需要大量适配工作。
我们在实验中还发现，模型使用非标准 Playwright API 时更容易出错。提示词中对新接口的说明，不一定能覆盖模型在训练中形成的使用习惯。我们将这一经验概括为：「What’s in the training data has more influence than what’s in the prompt.」 因此，Tabbit 尽量沿用原有调用语法，将适配集中在模型获取信息和接收结果的环节。
前面的工作循环要求模型根据观察决定操作。原生接口提供的信息不足以支持这个决定时，Tabbit 优先补充信息或调整交付方式。下面两项改动体现了这一选择：
页面快照增补操作线索。
在语义方式中，Playwright 的 page.ariaSnapshot({mode: 'ai'}) 把页面的无障碍结构转成文本，描述控件的角色、名称和状态。但有些复选框本体被隐藏，用户实际点击的是旁边的可见标签。Tabbit 在原始快照后追加 DOM 提示，指出隐藏控件与可见标签的关系，并给出标签选择器。模型据此选择操作入口，实际点击仍由 Playwright 执行，并通过原生的可操作性检查。
给截图补上交付方式。
在视觉方式中，模型需要实际看到图像，原生 page.screenshot() 返回的图片字节却不能直接通过 CLI 文本回执成为图像输入。Tabbit 将截图保存为独立文件，返回路径、尺寸和加载提示，由宿主按需提供给支持图像输入的模型。模型仍沿用熟悉的截图写法，改变的是返回值和图像的交付方式。
需要额外协调时，再增加显式能力。 有些需求仅靠补充返回信息还不够。例如，模型未必知道一次点击会打开新页面还是更新当前页面，观察需要在动作之前开始，才能捕获过程中发生的事件。
Tabbit 为此提供 tabbit.triggerAndObserve()，把动作与观察放在一起协调；tabbit.observe() 则汇总任务中的页面、frame 和焦点信息。它们与 Playwright 共用页面对象，可以嵌入同一段程序。
额外观察由模型按需调用，从而避免给每次原生点击隐式增加等待、改变其耗时与失败条件。
返回结构化结果，让模型知道执行中发生了什么。 在「执行—核对」的环节，模型需要了解的往往超出程序主动返回的内容：页面是否跳转、是否打开新页、有没有弹窗或请求失败。模型未必能预见这些变化，也未必在程序中写入相应的检查。因此，Tabbit 由运行时统一记录可观测变化，按需与程序结果一起返回，并在失败或中断时提示可能已经产生的修改及后续处理建议。模型据此决定继续操作、补充观察或交还用户，不必在每段程序中重复编写通用的状态收集逻辑。
这些反馈帮助模型核对结果，但程序成功返回并不等同于业务完成，执行中断也不代表此前没有产生修改。结果不明时，仍应先检查页面或业务记录，再决定下一步。
综上，Tabbit 不重新发明模型已经学会的语言，也不重新设计、实现经社区广泛检验的自动化框架与浏览器控制抽象，而是让它们适应 Agent 的使用。 模型继续用 JavaScript 与 Playwright 组织操作；Tabbit 将程序放进用户浏览器中的任务环境，补充观察与执行反馈，使一次调用的结果能够支持下一轮判断。下一节通过一个完整任务说明这些设计如何协同工作。
3. 工作实例：处理快递丢件订单
下面以电商运营处理售后订单为例，说明这些能力如何配合完成任务。
假设一批待处理订单中，有些因快递丢件需要重新发货，另一些则涉及其他售后原因。运营人员希望把查找丢件订单、核对物流和提交补发的重复操作交给 Agent，遇到需要判断的情况再由自己接手。
此时，用户已经登录供应商后台，订单页开在浏览器里。用户给 Agent 的指令是：
「把快递丢件的订单按原地址补发，如果提示地址变了，先留给我确认。其他原因不动，做完后核对记录。」
后台中有 26 条待补发订单，共 3 页，其中 9 条是丢件；第 5 笔目标订单会出现地址变更提示。订单和情节为演示设计，页面编号、截图与处理结果来自实际运行。
图 6 - 操作前的原始网页截图。
1. 找到用户已有的页面，接手它。 Agent 先获取标签页清单，按标题和网址找到「待补发订单」。此时浏览器中共有 10 个标签页，目标页编号为 770865107，状态为 available。随后用 claim 将它纳入当前任务：
回执里的ownedPageCount: 1表示任务现在只持有这一页。订单页的登录态直接可用，其他 9 个标签页仍由用户照常使用。 claim 的作用是确定接下来可以操作哪些页面；它不会另开空白浏览器，也无需用户重新登录。
2. 批量读取并筛选目标订单。 Agent 读取表格列和「下一页」按钮，确定筛选规则，再交给 Tabbit CLI 一段程序，连续读完 3 页。实际返回为 scanned: 26、pagesRead: 3、targetCount: 9，以及 9 个订单号。完整表格在程序中处理，模型直接拿到目标清单；程序把这份清单和处理进度保存在任务运行时里，供后续调用继续使用。
以下命令均复用「丢件补发演示」任务，每次提交只展示 4 行核心代码；变量初始化和页面定位已在此前调用中完成。resendAndVerify是封装补发与成功核对的业务函数，遇到异常返回 false。
3. 接入物流新页，核对后批量补发。 Agent 点击第一笔订单的「查看物流」，网站打开新标签页。Tabbit 将新页自动纳入本任务，回执中的页面数从 1 变为 2，并返回新页地址。Agent 读到「运输途中丢失，已确认」，再回订单页处理。确认框和成功提示的规则明确后，程序连续完成前 4 笔：按订单号找到当前行，确认补发，等待「提交成功」，再处理下一笔。用户正在看的页面不必随之切换。
4. 地址变化时暂停提交，留待人工确认。 处理订单SO261018416时，页面弹出「收货地址已变更，是否按新地址补发？」程序发现确认内容与预期不同，停在提交前，将弹窗文字、该订单号和「已完成 4 笔、剩余 5 笔」的进度一起返回。模型结合用户「地址变了先留给我确认」的要求，决定取消这次补发，将该订单记入待确认清单。
5. 下一次调用，从已有进度继续。 订单页、物流页、9 个目标和已完成的 4 笔都还在同一个任务中。Agent 让程序取消弹窗、暂缓这一笔，继续处理其余 4 笔，最后打开「补发记录」逐项核对。核对结果为 8 笔补发完成，1 笔因地址变更留待用户确认。
图 7 - 在本地模拟后台的实跑截图上标出点击与观察位置；五种颜色对应正文步骤，虚线框表示观察区域，实线框表示点击控件。物流页、弹窗和记录页为局部放大。
本次运行没有替用户确认新地址，而是完成其余订单并留下待确认项。用户随后可以在同一浏览器中处理这一笔；Agent 若继续接手，需要重新观察并核对页面状态。若任务已超过空闲期限，则重新认领页面，并从业务记录恢复进度。
4. Tabbit CLI 与 Skill 的实践经验
工具提供能力，而 Skill 则引导模型使用这些能力。在同时迭代工具与 Skill 的过程中，我们有以下发现：
1. Skill 本身也会带来输入开销（overhead）。 主文档从 154 行扩充到 724 行后，其占输入 token 的比例由约 4.0% 增至 6.6%。我们因此采用分层设计：常用流程放在主文档；特定场景的详细步骤放在参考文档，并说明何时读取；随运行状态变化的指引，则由回执中的 transition、issues、nextAction 等字段提供。
2. 示例比文字指引更容易被采用。 在我们的测试中，当 Skill 用文字建议「对独立来源使用并发」时，采用并发的运行只占 4%；换成代码示例后，比例提高到 63%。因此，Skill 应该尽量展示可直接改写的示例，以说明工具已有的能力和推荐的执行流程。
3. 引导批量执行，减少模型轮次。 Tabbit 支持在一次调用中执行完整程序，Skill 则引导模型把规则明确的动作与核对写进同一段程序，例如一次完成翻页、读取和筛选。这样可以减少模型逐步接收结果、判断并生成下一次调用的往返。指引同时说明何时停止：遇到新的业务判断或预期之外的状态，应返回相关信息，再决定下一步。
4. 利用缓存，鼓励有针对性的观察。 实验中，输入 token 的缓存命中率约为 89% 到 93%。稳定的指令和历史上下文可以被复用，新增观察则需要兼顾信息是否充分与返回范围。Skill 据此说明观察时机：首次进入页面时识别区域与控件；出现新页面或弹窗时读取变化后的目标；提交业务操作后检查成功提示及对应记录。工具通过 tabbit.observe() 的 frames、maxChars 等参数控制返回范围，指引帮助模型判断何时需要更多信息；已知步骤中的检查则随批量操作完成。
5. 用 JavaScript 处理数据，明确返回范围。 批量执行减少模型往返，程序内的数据处理则减少每次交给模型的信息量。面对长列表，我们在 Skill 中鼓励模型通过 page.evaluate() 批量读取记录，再在运行时中筛选、去重和统计，只返回候选与统计结果；需要理解语义或作业务判断的部分，再交给模型。示例同时展示计算过程与返回范围：
JavaScript 适合数据提取和计算；点击、输入等交互仍使用 Playwright 的 Locator 方法，以保留等待与可操作性检查。
这些经验也可作为编写任务提示词（prompt）的参考：提供少量有代表性的示例，写清目标、停止条件和核对要求，限制篇幅，约定返回内容，并可主动引导 Agent 使用 JavaScript。这样能更具体地表达希望 Agent 如何完成任务。
5. 评测结果与适用范围
5.1 评测设置与结果
我们用 Browser Use 发布的 BU Bench V1 中的 25 道题，比较了 Tabbit CLI 与 Codex 的 ChatGPT 浏览器扩展。
题目来自 WebBench、Online-Mind2Web 2、交互测试、GAIA 和 BrowseComp 五个来源，覆盖信息检索、跨网站整理、复杂页面操作和多步推理。
两者运行在同一个 Agent 宿主（Codex CLI 0.144.1）中，使用同一个模型（gpt-5.6-luna，medium），分别使用两套浏览器操作方案，包括各自的接口、操作指引与结果返回方式。
每题运行三轮，执行顺序事先登记；答案由一个不知晓来源的模型评分。
75 次运行汇总（Tabbit CLI / ChatGPT 浏览器扩展）：答对 48 次（64.0%）/ 47 次（62.7%）；每个正确答案输入 80.3 万 / 157.5 万 token；每个正确答案工具调用 20.1 / 24.8 次；中位耗时 121.0 / 141.2 秒。
图 8 - 8 月评测：答对次数接近，输入消耗差异更明显。每个正确答案的输入量以全部 75 次运行的总输入除以答对次数，包含失败运行开销，未按缓存价格折算。
5.2 从模型能力到任务效率
两套方案在 75 次运行中分别答对 48 次与 47 次，完成数量接近，更明显的差异体现在执行开销上。
在双方均答对的 40 组同题配对中，Tabbit CLI 的输入 token 和工具调用更少，输出量基本持平：
40 组共同正确结果（Tabbit CLI / ChatGPT 浏览器扩展）：输入 token 2,024.3 万 / 3,835.8 万（−47.2%）；工具调用 516 / 620 次（−16.8%）；输出 token 17.99 万 / 18.70 万（−3.8%）。
这些数据反映整套方案的差异；下面结合运行记录与相关工程实践，分析可能的原因。
一次生成的代码可以表达需要重复执行的规则。 循环、条件和变量让模型先写出处理方法，再由程序反复应用，中间结果也可以直接传给后续步骤。Cloudflare 的 Code Mode 讨论了同样的思路：多次工具调用之间的数据传递，可以由代码完成，减少模型为衔接调用而读取和复制数据的需要。本组运行中，输入量下降而输出量基本持平，说明观察到的节省没有以更多的总输出为代价。两套方案都支持 JavaScript，因此值得分析的是模型实际生成了怎样的程序，以及 Skill 如何引导它使用这些能力。
保留任务状态，不等于把全部状态反复交给模型。 Tabbit 可以在任务有效期内通过程序变量和结果资源保存中间数据，供后续按需读取。进入模型上下文的内容则会影响后续每一轮：只要工具结果仍保留在对话历史中，就可能被再次输入。因此，先在程序中筛选数据，收益会延续到后续轮次；较早返回的大段无关内容，则会在更多轮次中被重复计入。精简返回应保留来源和继续读取的路径，让模型在发现例外时仍能补充信息。
图 9 展示了这种差异。任务是找出 Stack Exchange 上每日提问量最高的 5 个社区，Tabbit 的一次提取调用在执行环境中读取并排序 183 条记录，只返回前 10 条候选。模型保留了核对候选的机会，完整列表则没有进入对话历史。
图 9 - 一次返回候选，还是逐段返回快照。左侧源自 Tabbit 的一次真实提取，右侧说明逐段读取快照的开销。
观察可以按需生成，执行仍可复用成熟语义。 Browser Use 在 The Bitter Lesson of Browser Agents 中讨论了从固定页面表示转向由模型自行编写观察代码的变化。这给我们的启发是：保留 Playwright 的操作语义，并不要求给所有任务预设同一种观察结果。模型可以根据问题组合快照、截图和 DOM 查询，常用交互的定位与等待仍交给成熟框架处理。Tabbit 因而既保留模型选择观察与组织程序的空间，也复用既有的执行能力。
Tabbit CLI 的具体优势会随模型和任务变化，返回粒度、示例和批量执行范围也需要持续验证与调整。它的核心价值，是充分利用模型越来越强的编程与判断能力，将其转化为日常工作的执行效率，让浏览器成为用户与 Agent 协同完成任务的工作环境。
泛在计算（Ubiquitous Computing）的提出者、计算机科学家 Mark Weiser 在 1991 年写道：「最深刻的技术是那些会消失的技术。它们融入日常生活，直到与生活本身无法区分。」
浏览器技术正是如此：从 WebView、Electron 到小程序，浏览器内核早已融入各类应用当中。我们希望 Tabbit 沿着同样的路径，成为 AI 与 Agent 工作环境的一部分。
如果你还没有尝试过 Tabbit CLI，可在 Codex、WorkBuddy 等 Agent 工具中输入 /tabbit ，直接驱动 Tabbit 接管真实浏览器操作。
未安装 Tabbit 浏览器的朋友，可以访问官网 www.tabbit.com 或点击「阅读原文」免费下载电脑端试用。
体验手机端 Tabbit，可在各应用商店搜索「Tabbit」下载。登录同一账号，你的书签、标签页以及其他浏览数据都可在云端同步。
参考资料
产品版本：Tabbit Browser Dev 1.20.5（演示）、Tabbit 1.13.8（8 月评测）；Codex CLI 0.144.1；浏览器端的 ChatGPT 扩展版本为 1.26.1005 与 1.26.1015（运行记录），Codex 侧的 chrome 插件版本为 26.1007.30912（接口文档）。
