先声明：这篇文章本身就是一次实操。 由 Codex 通过 Tabbit CLI 操控 Tabbit 浏览器，完成掘金文章的正文填写、配图上传和发布信息准备；最后一步「确认发布」留给我手动点击。你现在读到的，就是这套自动化发文流程的产物。
以前，AI 写完内容之后，剩下的粘贴、上传、检查图片和填写发布信息，往往还得自己来。接上 Tabbit CLI 后，这些网页操作也能交给 Agent。
Codex、Claude Code、WorkBuddy 负责理解任务，Tabbit 负责让操作落到真实浏览器里。 这次实际执行用的是 Codex；另两个工具也可以通过各自的 tabbit Skill 使用同一套 CLI。
这篇会做出什么？先跑通网页读取，再把本地文章和配图填进掘金草稿。macOS 命令可直接复制，关键数据和完整命令都保留。
01 / 为什么选 Tabbit？先看这张图
官方给出了一组同题对照。按总消耗 ÷ 答对题数计算，相比 Agent Browser，Tabbit 的输入 Token 少约 61%，工具调用约减半；相比 Codex Chrome，输入 Token 少约 49%。
同一指标的条形从 0 开始。数据来自 Tabbit 官方评测，详细数值保留在文末。
测试使用 BrowserBench 的 25 道题，每题 3 次；统一 GPT-5.6-Luna、Max 思考强度，由另一个 Reviewer 模型判定。
正确次数分别为 48 / 75、47 / 75、45 / 75。我更关注的是：在这组题里，Tabbit 用较少的上下文和工具调用交付了相近数量的正确结果。
口径提醒：这是官方评测，包含失败尝试的消耗；不是本文发文任务的复测，也不能把输入 Token 降幅直接等同于账单降幅。表中的 Codex Chrome 是评测使用的浏览器方案，和本文「Codex 调用 Tabbit CLI」的组合不同。
下面开始动手，先让浏览器确实响应一条指令。
02 / 三个 Agent，先选你正在用的那个
准备 Codex、Claude Code、WorkBuddy 中任意一个，以及支持 CLI 的新版 Tabbit。国内可以从 Tabbit 官网 下载，海外使用 国际官网。WorkBuddy 的入口是 腾讯 WorkBuddy。
先安装并启动一次你选的 Agent，再安装或更新 Tabbit，启动浏览器。当前 Tabbit 集成会检测这三个宿主，安装 CLI、共享 Skill 和对应宿主的技能接入；WorkBuddy 还会登记相应插件。回到 Agent 新建对话，确认它能发现 tabbit 技能。
用 Codex：直接点名 tabbit Skill
本文采用的是这条路。在对话里直接说「使用 tabbit Skill 操作 Tabbit 浏览器」即可。在 Codex CLI 或 IDE 扩展中，也可以输入 $tabbit 点名技能，或通过 /skills 选择。不同界面的选择入口以实际显示为准。Codex 官方技能说明
用 Claude Code：让它加载同名技能
启动 Claude Code 后，直接要求「使用已安装的 tabbit Skill，通过 Tabbit CLI 操作浏览器」。如果技能菜单中已经出现 tabbit，也可以从菜单调用，再附上任务目标。
用 WorkBuddy：从 /tabbit 开始
在 WorkBuddy 新对话里找到 tabbit 技能或插件，输入 /tabbit 后描述任务。如果应用一直开着，重新打开，让新对话加载刚安装的技能。
流程示意，展示角色分工。
三个工具都可以先输入同一个小任务：
请使用 tabbit Skill，通过 Tabbit CLI 操作 Tabbit 浏览器。
请打开 https://example.com，读取页面标题和主标题。
返回实际访问的 URL、页面标题、主标题，不需要扩展搜索。
看到什么算跑通？ 标题和主标题均为
Example Domain，返回 URL 为https://example.com/，浏览器里能找到对应页面。
如果 Agent 没有开始操作，补充一句：
先运行 diagnose 检查连接，再打开 https://example.com 读取标题。
如果 Agent 仍然找不到 Skill，先检查 Tabbit 是否已更新、两个应用是否都启动过，再重开 Agent 对话。先确认技能被发现，再检查 CLI 的连接结果。
03 / 想看底层怎么跑？复制这组命令
下面这组命令适合 macOS，也是本文实际核对的命令路径。终端不认识裸命令 tabbit-cli 时，使用完整路径即可：
tabbit_cli="$HOME/.local/bin/tabbit-cli"
"$tabbit_cli" diagnose
正常响应里会有 ok: true，以及当前运行时支持的命令和能力。版本号会随浏览器更新，不必和某张截图完全一样。
接着打开一个页面：
"$tabbit_cli" nodejs --task juejin-demo --request-id open-demo-01 <<'JS'
await page.goto('https://example.com', {
waitUntil: 'domcontentloaded'
});
return {
url: page.url(),
title: await page.title(),
heading: await page.getByRole('heading', { level: 1 }).innerText()
};
JS
page 是运行时提供的页面对象。第一次执行需要页面的任务时，Tabbit 会提供一个页面，不需要再额外启动一份浏览器。
返回结果采用 JSON 包装；看 status 和 result.value 就能找到状态及业务结果。别把文章里展示的三个字段误认为完整 CLI 响应。
同一个任务后续继续读取这个页面：
"$tabbit_cli" nodejs --task juejin-demo --request-id inspect-demo-01 --read-only <<'JS'
return {
url: page.url(),
paragraphs: await page.locator('p').allTextContents()
};
JS
"$tabbit_cli" finish --task juejin-demo
普通 finish 释放任务对标签页的占用，并保留有用的页面和分组，方便自己核对。--discard 会关闭任务拥有的标签页，日常阅读任务通常不需要加它。
Windows 对应的启动入口如下；这部分按当前集成路径给出，本文没有做 Windows 端实测：
$tabbitCli = "$env:LOCALAPPDATA\Tabbit\LocalAgent\bin\tabbit-cli.exe"
& $tabbitCli diagnose
04 / 真正的任务：把这篇文章填进掘金
网页读取跑通后，就可以把任务换成本文的发布准备。给 Codex 的要求可以写得很具体，Claude Code 和 WorkBuddy 也可以复用这份任务描述：
请使用 tabbit Skill，通过 Tabbit CLI 操作 Tabbit 浏览器。
读取工作区内这篇 Markdown 文章和它引用的配图，准备掘金草稿。
1. 打开掘金创作入口；需要登录时让我完成登录。
2. 填写标题和正文，保留代码块、引用来源和文末邀请链接。
3. 上传正文配图，把本地图片路径换成掘金图片地址。
4. 使用文章封面，填写摘要，并选择与内容相符的分类和标签。
5. 检查图片是否显示、链接是否完整、草稿是否保存成功。
停在最后一步「确认发布」，不要点击。
保留编辑页面，告诉我核对后该点哪个按钮。
把真实的文章位置一起提供给 Agent，它才能找到文件。这里有个容易漏掉的细节：本地 Markdown 能看到图，不代表贴进掘金后也能看到。 本机目录/封面.png 必须真正上传，并替换成平台生成的图片地址。
这也是让 Agent 直接操作浏览器有用的地方：它可以在编辑器里上传图片、查看预览、继续填写发布信息。执行完后，你看到的是待确认的草稿和表单。
发布前看四处： 标题和摘要是否准确；正文图片是否加载；代码块与来源链接是否完整；两个邀请入口是否仍包含完整参数。最后确认分类和标签，再由自己点击发布。
同样的方法还能用来整理资料：给出三条文档链接，让 Agent 实际读取，再交付带来源的 Markdown。任务换了，仍然是「读取材料 → 操作网页 → 核对结果」这条路径。
05 / 已登录的页面，也能继续用
很多真实工作发生在已登录的网页里。Tabbit CLI 提供标签页清单与显式接管：
"$tabbit_cli" tabs --task reading-notes --state available --limit 20
# 123 是示例，请替换为上一步确认过的目标标签页 ID。
"$tabbit_cli" claim --task reading-notes --tab 123
tabs 只列清单，claim 才把选中的标签页交给当前任务。Agent 的 context.pages() 能看到的是它已拥有的页面。
对于 Codex、Claude Code、WorkBuddy，通常不必亲自输入这两条命令。直接说明要使用哪个页面，要求它先匹配标题和 URL，再接管目标即可。例如：「使用我已经登录的掘金编辑页，先核对标题和地址。」
如果下一步需要批量填表，建议把目标写成“先填好并检查，提交前停下”。这样第一次验证就有明确终点。
收尾前，记住这三个参数
--task 用于把一组操作归在同一个任务里。任务换了名字，不能假设还能继续使用上一个任务的页面。
--request-id 标识一次提交。修改代码后应使用新的 ID；执行状态不明确时，应先核对回执和页面状态，不要直接重跑可能已经发生的填写或提交。
--read-only 用来声明只读程序。读取标题符合这一约定，导航、点击和填写则不属于只读操作。
本文的执行环境是 macOS，实际由 Codex 调用 Tabbit CLI。Claude Code 与 WorkBuddy 的接入说明依据当前集成机制核对，本文没有把同一篇文章在三个工具里重复上传，也没有做三者的独立速度对比。模型、网络和页面结构都会影响最终结果。
值得尝试的点很具体：继续用熟悉的 Agent，把网页执行交给 Tabbit，在浏览器里检查结果。对这篇文章来说，AI 的交付从一份 Markdown 延伸到了图片已经上传、信息已经填好的发布前页面。
附录：完整评测数据与统计口径
数据来源：Tabbit 官方发布文章。这里只整理公开数据，没有重新运行该评测。
先看完成情况与耗时分布：
| 指标 | Tabbit CLI | Codex Chrome | Agent Browser |
|---|---|---|---|
| 答对次数 | 48 / 75 | 47 / 75 | 45 / 75 |
| 正确率 | 64.0% | 62.7% | 60.0% |
| 耗时中位数 | 121.0 秒 | 141.2 秒 | 209.6 秒 |
| P90 耗时 | 220.6 秒 | 224.2 秒 | 489.0 秒 |
正确率上，Tabbit 分别多答对 1 次和 3 次。对日常使用更值得关注的，还有完成任务要付出多少消耗。
原文把各方案的总耗时、总 Token 和总工具调用除以答对题数，得到下面这组数据。它包含失败尝试的消耗，不是只对成功任务取平均：
| 每个正确答案分摊的消耗 | Tabbit CLI | Codex Chrome | Agent Browser |
|---|---|---|---|
| 耗时 | 219.3 秒 | 227.9 秒 | 422.9 秒 |
| 输入 Token | 803K | 1,575K | 2,058K |
| 输出 Token | 7,417 | 7,686 | 10,266 |
| 工具调用次数 | 20.1 | 24.8 | 41.7 |
按这个口径，Tabbit 相比 Agent Browser 的输入 Token 少约 61%，完成效率约为其 1.9 倍，工具调用约减半；相比 Codex Chrome，输入 Token 少约 49%。这些比例按上表计算，K 表示千 Token。数据来源
体验入口
以下是我的邀请链接：
适用资格、有效对话要求及赠送时长以活动页面为准；完成后按页面提示领取奖励。
