Kimi WebBridge，AI 操作浏览器更好的一把铲子
上期给大家介绍了 Playwright 浏览器自动化实战指南，给 AI 装上了“眼睛和手”。没看过的同学可以先回去翻翻：给 AI 装上"眼睛和手"——Playwright 浏览器自动化实战指南。
那篇文章里，我介绍了我对 Playwright 的两种使用方式，各有优劣。
今天我们聊一个"轻装备"：Kimi WebBridge。如果你觉得 Playwright 太重、登录态管理太烦、代理配置太绕，那这东西可能就是你要找的。
Playwright 的两个"真疼"
先说痛点，不然你不知道 WebBridge 好在哪。
玩过 Playwright 的同学应该都有体会，最烦的不是写脚本，是两件事：
第一，登录态管理。
Playwright 启动的是一个"干净的"浏览器实例——没有你的 Cookie，没有你的登录态。想让它访问你的 GitHub、知乎、小红书？不好意思，先手动登录一遍，然后 state-save 保存到 auth.json，下次再 state-load 加载回来。登录态过期了？再来一遍。
说白了就是：你明明浏览器里已经登着，Playwright 非要让你再登一次。
第二，环境配置。
Python Playwright 要先 pip install playwright，再 playwright install chromium，下载一个独立的 Chromium 浏览器。如果你的网络需要代理，还得配 HTTPS_PROXY 环境变量。如果你的系统没装 Node.js，Playwright CLI 还用不了。
一句话：为了拿 10KB 的数据，你得先折腾 200MB 的环境。
有没有更轻的方式？有。Kimi WebBridge 的思路是：别折腾了，直接用你现在的浏览器。
Kimi WebBridge 是什么
Kimi WebBridge 是月之暗面推出的浏览器操作工具。核心卖点一句话：寄生在你的真实浏览器上，AI 操控它的时候，自动继承你的登录态、Cookie 和代理配置。
不需要装额外的浏览器，不需要管理 auth.json，不需要配代理——你浏览器什么样，AI 拿到的就是什么样。
它的架构长这样：
图：Kimi WebBridge 三层架构 — AI Agent 通过 HTTP API 调用本地守护进程，守护进程通过浏览器扩展操控真实浏览器
三层协作：
- AI Agent 通过 HTTP POST 发指令到
127.0.0.1:10086 - 本地守护进程（一个 Go 写的后台程序）接收指令，通过 WebSocket 转发给浏览器扩展
- 浏览器扩展 通过 Chrome DevTools Protocol（CDP）操控你的真实浏览器
关键设计：HTTP API。 任何能发 curl 的工具都能用，不依赖 Python、Node.js 或者某个特定 SDK。LLM 直接在 bash 里 curl 就能操作浏览器，不需要额外装任何东西。
这也是它和 Playwright 最大的架构差异——Playwright 是 SDK 绑定的（Python、JS、Java），WebBridge 是语言无关的（HTTP）。
10 分钟上手
安装不复杂，三步走。
第一步：一键安装守护进程。
curl -fsSL https://cdn.kimi.com/webbridge/install.sh | bash
这个脚本会自动检测你的系统和架构，下载二进制文件到 ~/.kimi-webbridge/bin/，然后启动后台守护进程。
第二步：安装浏览器扩展。
打开 Chrome 或 Edge，访问 www.kimi.com/features/we…，点击安装扩展。装完后打开任意网页，扩展图标显示"Connected"就说明桥接成功了。
（Brave 浏览器也能用——它是 Chromium 内核，支持 Chrome Web Store 扩展，实测 OK。但官方只声明了 Chrome 和 Edge，Brave 属于"能跑但不保证"的范畴。）
第三步（openCode 用户）：迁移 SKILL 配置。
Kimi 官方安装脚本默认会把 SKILL 安装到 ~/.claude/ 目录下（面向 Claude Code 用户）。openCode 用户需要手动将 SKILL 从 ~/.claude/skills/kimi-webbridge/ 移动到 openCode 的配置目录：
cp -r ~/.claude/skills/kimi-webbridge ~/.config/opencode/skills/kimi-webbridge
安装完成后，openCode 里的 AI Agent 就能自动调用 WebBridge 来操作浏览器了。日常管理用这几个命令：
kimi-webbridge status # 检查守护进程和扩展连接状态
kimi-webbridge start # 启动守护进程
kimi-webbridge stop # 停止守护进程
kimi-webbridge restart # 重启守护进程
小小实战测试：V2EX 热榜数据采集
光说不练假把式。我用 WebBridge 做了一个真实测试：让 AI 操控我的 Brave 浏览器，去 V2EX 抓热榜数据。
测试环境：
- 模型：DeepSeek V4 Pro
- 平台：openCode
- 浏览器：Brave（日常使用的）
- 任务：抓取 V2EX 当日热榜 TOP 20 + 5 个精选话题的正文和前 10 条评论
整个流程不需要我做任何登录操作——V2EX 的登录态浏览器里本来就有，WebBridge 自动继承了。
AI 的操作流程很直接：打开 V2EX 热榜页面 → 用 JS 提取页面数据 → 并行打开 5 个话题详情 → 提取正文和评论 → 整理输出为结构化 Markdown。
结果：6 个页面全部成功抓取，成功率 100%。
更让人舒服的是费用，以下是我 DeepSeek 后台的账单数据，总费用 0.19 元，可以说十分便宜了：
图：DeepSeek V4 Pro + Kimi WebBridge 完成 V2EX 热榜数据采集的实际账单，总费用 0.19 元
任务完成后 OpenCode 显示 Context 大约为 35K tokens 左右。对比如果用 Playwright CLI 逐步操作（每步都要 snapshot → LLM 分析 → 决定下一步 → 再 snapshot），预计token 消耗估计翻 3-5 倍，还有网络等问题都需要处理。
Kimi WebBridge 为我解决了什么问题
测试下来，WebBridge 最让我舒服的地方有三个。
不再需要"再登一次"。
GitHub、Google、知乎、小红书、V2EX……只要我浏览器里登着，AI 直接用。不需要扫码，不需要保存 auth.json，不需要担心登录态过期——我每天打开浏览器正常上网，登录态自然续着。
代理配置零门槛。
我日常用的 Brave 浏览器配了代理（办公网络环境）。WebBridge 操控 Brave 的时候，代理自动生效——不需要在脚本里配 HTTPS_PROXY，不需要在 curl 里加 --proxy。它就是直接用我浏览器的网络通道。
Token 效率意外地高。
WebBridge 获取页面信息默认用 Accessibility Snapshot——不是截图，而是文本化的"页面可访问性树"。每个交互元素带上 @e 编号，AI 可以用编号来定位和操作。
这种文本化的方式比截图省 token 得多——截图需要视觉模型逐像素分析，消耗惊人；Snapshot 只返回页面结构化的文本描述，一个量级的差距。也比直接塞原始 HTML 高效，因为 Snapshot 过滤掉了 <script>、<style> 等噪音标签，只保留真正有用的交互元素。
而且如果页面的数据结构简单（比如 V2EX），可以直接用 evaluate 执行 JS 提取数据，省掉 Snapshot 的消耗。实际测试中，V2EX 抓取全程用 evaluate 返回结构化 JSON，非常高效。
坑也要说
不过缺点也得摊开讲，不能光说好的。
最大的坑：验证码搞不定。
我在测试中尝试让 WebBridge 自动登录 Gitee，结果卡在了滑动验证码上。
原因是一个叫 isTrusted 的浏览器安全机制：用户真实的鼠标点击 → isTrusted = true，CDP 合成的点击 → isTrusted = false。Gitee 的验证码检测了这个字段，直接判定为机器人，验证失败（也有可能是滑动操作太久导致页面验证码失效）。
这个问题不是 WebBridge 的 bug——Playwright 也有同样的问题，因为两者底层都是通过 CDP 合成事件。它是浏览器的安全模型限制，目前无解。
不能无人值守。
WebBridge 操控的是你的真实浏览器，所以浏览器必须开着。你不能在睡觉前跟 Agent 说"帮我半夜抓一批数据"然后去睡觉——窗口关了它就停了。
这是取舍：它牺牲了"无人值守"换来了"零配置登录态"。如果你需要 24/7 定时任务，还是得用 Playwright 的无头模式。（对我来说这一点还好，日常我的浏览器也是一直打开的）
截图需要视觉模型。
WebBridge 支持截图，但要"理解"截图内容，需要能处理图片的视觉模型（GPT-4o、Claude 3.5 Sonnet 等）。纯文本模型拿到截图也没用。不过我通常用 evaluate 和 snapshot 就够了，截图不是刚需。
总结：暂时都要，倾向 WebBridge
上期聊完 Playwright，这期聊完 WebBridge，工具多了，选哪个？
先看优缺点一览：
图：Kimi WebBridge 与 Playwright 全方位对比
我的选择是：日常临时操作用 WebBridge，固定批量抓取保留 Playwright。
WebBridge 适合的场景非常明确：临时让 AI 帮你查个东西、操作一下某个已经登录的网站、快速抓一批不需要验证码的数据。随手可用，零配置，token 也省。它就是一把"更轻的铲子"，放在手边，随时能用。
但如果你有固定化的数据采集需求——每天定时从某网站抓一遍数据——我还是建议用 Python 写 Playwright 脚本。因为固定流程写成脚本之后，反复执行的 token 成本更低（只有抓取本身的资源消耗），不需要每一步都让 LLM 做决策。LLM 实时驾驶虽然灵活，但灵活是有价格的。
目前看来，我认为 WebBridge 比 Playwright CLI 轻，比 Python 脚本定制灵活，是日常使用最顺手的那一档。
如果你也被 Playwright 的环境配置和登录态管理折腾过，试试 WebBridge。十分钟装好，然后对着 Agent 说一句"帮我查个东西"，看看它用你自己的浏览器帮你搞定——那感觉挺妙的。
工具地址：www.kimi.com/features/we… 上期回顾：给 AI 装上"眼睛和手"——Playwright 浏览器自动化实战指南
内容第一时间更新到我的公众号，欢迎关注
