夜雨聆风每个极客和开发者每天都有大量重复的网页操作任务：登录特定社区抓取最新热帖、把电子票据信息手动录入报销系统、或者跨平台进行数据比对。传统的自动化方案通常需要编写 Selenium、Puppeteer 或 Playwright 脚本，不仅需要调试定位选择器，面对网页改版时维护成本极高。
美团整合“光年之外”（GN06 团队）后，于近期发布了其首款 AI 原生浏览器 Tabbit 1.0 版本。官方宣称，该浏览器深度融合了大模型与网页操作，内置的 Web Agent 任务成功率超过 90%，并且标准版基础功能永久免费。
今天，我下载了其最新客户端，配置了国际版 API，调用 Claude 4.8 引擎作为其 Web Agent 的大脑，进行了整整一天的实测。测试任务涵盖了简易的网页数据抓取与复杂的跨页面表单录入。以下是我的真实折腾记录和踩坑复盘。
为了评估 Tabbit 的真实水平，我将其安装在一台配置为 Windows 11 (23H2) / AMD Ryzen 7 7840HS / 32GB RAM 的主力开发机上。
冷启动 Tabbit 客户端时，内存占用约为 180MB，在多标签页常规浏览时上升至 450MB - 600MB，其资源消耗控制在基于 Chromium 架构浏览器的合理区间。
为了测试其 Web Agent 的能力，我设计了两个不同难度的自动化任务：
任务 A（数据抓取与归档）：
在 Tabbit 内部创建一个名为/scrape-daily-news的“妙招”指令。要求 Web Agent 每天定时打开一个指定的开发者社区热榜页面，自动识别前 10 条热门帖子标题、作者与链接，提取其核心文本，并以标准的 Markdown 格式追加写入到本地磁盘的wewrite/output/briefs/目录中。任务 B（自动报销与表单填写）：
这是一个复杂的跨系统任务。Agent 需要读取本地的一个 PDF 电子发票（包含消费金额、商户名称、日期等），然后打开我本地部署的一个模拟财务系统报销页面，自动点击“新建报销单”，将 PDF 中的字段精准填写到“消费金额”、“消费类别”和“商家名称”等输入框中，并最终点击“提交审核”按钮。
Tabbit 引入了一个类似 IDE 里的全能输入框（Omnibar），按下快捷键即可唤出。你可以直接通过自然语言命令 AI，或者通过输入 / 调用预设的自动化“妙招”。
对于任务 A（数据抓取），我在 Omnibar 中输入：打开 [社区 URL]，提取今日热榜前 10 条的标题和链接，以 Markdown 格式保存到本地
Web Agent 启动后，会在浏览器右侧生成一个执行步骤侧边栏。我观察到它的定位动作非常迅速。在检测目标网页的 DOM 结构时，它通过大模型的视觉与结构理解能力，准确辨识了列表容器。
在点击下一页、定位 title 类选择器时，AI 并没有因为类名模糊而迷失。执行完毕后，控制台输出了整理好的 Markdown 数据。
对于复杂的表单录入任务 B，我配置了 Tabbit 国际版的 Claude 4.8 引擎。
任务开始后，Agent 自动调起本地文件选择器读取发票 PDF。Claude 4.8 提取结构化数据非常精准：{ "amount": 128.50, "category": "餐饮服务", "merchant": "美团餐饮", "date": "2026-06-25" }
随后，Agent 自动导航到模拟报销系统的登录页面。由于我提前将 Cookie 状态保持为已登录，Agent 直接跳过了登录步骤（这是一个安全的做法，后面会提到）。
进入后台后，Agent 在 DOM 中寻找“新建报销单”按钮。在点击后弹出的模态框中，Agent 准确找到了文本输入框，并依次输入了金额 128.50 和商户信息。最后，它定位到页面底部的“提交审核”蓝色按钮，完成点击。
尽管上面的测试看起来很顺利，但在我不断加大测试难度后，Web Agent 遇到了几个难以逾越的技术坑点。如果你也打算用 Tabbit 来做办公自动化，必须提前注意防范。
当我尝试让 Web Agent 执行从零登录报销系统（输入用户名和密码）时，系统弹出了拼图滑动验证码。
此时，Web Agent 试图通过截取验证码图片并分析滑块缺口来模拟拖动。然而，由于 DOM 中 Canvas 绘制机制的复杂性，AI 无法精准计算出偏移像素值，拖动轨迹显得十分机械，导致连续 5 次被系统拦截并提示“安全风险”。
此时，Web Agent 在侧边栏进入了无限重试的死循环，CPU 占用率瞬间飙升至 85%，直到我手动强行中止任务。
🚨 踩坑提醒：Web Agent 目前完全不具备绕过高安保等级验证码（如滑动拼图、短信二次验证、网银 U 盾）的能力。任何涉及此类验证的流程，必须采用“人工辅助登录、AI 接管后续”的折腾策略。
在抓取一些无限滚动的瀑布流网页时，由于数据是滚动到视口后才通过 Ajax 异步加载的，Web Agent 往往在页面刚加载完前几项时，就急于宣布“任务已完成”，导致最终提取的数据严重缺失。
这是因为 Web Agent 在等待 DOM 变更时，其超时判定（Timeout）通常硬编码在浏览器底层。如果目标服务器响应较慢，AI 就会误判定网页已经加载完毕。
Web Agent 在执行操作时，必须拥有与当前浏览器标签页相同的 Session 和 Cookie 权限。这意味着大模型（无论是内置模型还是通过 API 接入的海外旗舰模型）在理论上都可以读取你当前登录站点的所有敏感凭证。
虽然 Tabbit 宣称内置了数据沙箱，但作为极客，我强烈建议：绝不要让 Web Agent 自动保存或代填你的支付密码、网银密码、以及涉及核心资产的秘钥。
通过今天的高强度实测，我整理了一份 Web Agent 与传统自动化方案（以 Puppeteer 为例）的成本与效能对比表：
| 开发部署成本 | 0 (自然语言直接描述即可执行) | |
| 任务 A 运行时间 | 32秒 | |
| 任务 B 运行时间 | 78秒 | |
| 稳定性与容错性 | ||
| 单次执行成本 | ||
| 验证码绕过能力 |
从数据中可以清晰看出，使用大模型驱动的 Web Agent 跑任务，虽然极大地降低了前期的代码编写门槛，但在执行效能、响应时延和运行成本上，与传统的硬编码脚本相比仍有数倍的差距。
与传统的 Selenium/Puppeteer 脚本相比，Tabbit 这类 AI 原生浏览器的最大优势在于极低的维护成本。你不需要去查看繁琐的 div.class_name，也不用担心网页微调导致脚本崩溃，AI 会自主在 DOM 树中重新寻找最匹配的元素。
但是，它的劣势也同样明显：执行的不确定性与高昂的 Token 成本。
用 Python 写一段抓取脚本，运行时间不到 2 秒，且每次执行的路径 100% 确定。而使用大模型驱动的 Web Agent 跑一次网页抓取，需要消耗数千 tokens，并且在面对滑块验证码或动态加载页面时，依然存在不低的失败率。
我的最终选择：
我不会用它来跑核心的财务数据录入或带有高额资金变动的敏感操作。但我会将 Tabbit 保留在我的日常辅助工具箱中，专门用于以下场景：
- 抓取非敏感、结构复杂的公开网页数据。
- 自动填写一些无需登录验证的常规注册表单或调查问卷。
- 作为 Puppeteer 脚本编写前的 DOM 解析和流程规划辅助工具。
素材来源：
- 美团 Tabbit 官网：https://virxact.com/tabbit
