夜雨聆风Kimi 发布了浏览器扩展 Kimi WebBridge，AI agent 可以在用户的 Chrome 里打开页面、点击按钮、填写表单、提取信息，把浏览器变成 agent 的执行层。Chrome Web Store 显示已有约 1 万用户安装，评分 5.0。但它需要读取你的浏览历史、鼠标行为和页面内容——便利和风险，这次同时摆上了台面。
浏览器，正在变成 AI 的手
过去一年，AI agent 的执行能力一直沿两条路线在推：一条走协议，MCP server、标准 API、工具 schema，稳定可控，但每接一个应用都要适配；另一条走浏览器，让 agent 直接在用户已有的登录态里操作网页——打开、点击、填写、提取。
Kimi WebBridge 走的就是后一条。
▲ Wes Roth 在 X 上介绍 Kimi WebBridge，称它让 AI agents 像人一样与网站交互（1.7K 次查看）
科技博主 Wes Roth 在 X 上发帖介绍了这个扩展：
"Kimi has launched Kimi Web Bridge, a browser extension that lets AI agents interact with websites more like humans do."
「Kimi 发布了 Kimi Web Bridge，一个让 AI agent 像人类一样与网站交互的浏览器扩展。」
他在帖子中列出了 WebBridge 能做的事：搜索、滚动、点击、输入、填表、收集信息、完成浏览器任务。还提到它支持 Kimi Code CLI、Claude Code、Cursor、Codex、Hermes 等多种 agent 工具——不过这个兼容列表来自 Wes Roth 的帖子，Chrome Web Store 和 Kimi 官网并没有给出完整的官方兼容矩阵。
关键信息：这个扩展把浏览器从"你看内容的地方"变成了"AI 替你干活的地方"。
Chrome Web Store 上的产品事实
打开 Chrome Web Store，搜 Kimi WebBridge，产品页开门见山：
"Kimi WebBridge — browser extension for AI agents. AI can open pages, click, fill forms, extract info, and automate web tasks."
「Kimi WebBridge——为 AI agent 设计的浏览器扩展。AI 可以打开页面、点击、填写表单、提取信息、自动化网页任务。」
▲ Chrome Web Store 发行页，显示 Kimi WebBridge 已有约 1 万用户，评分 5.0
采集时（2026 年 5 月），该扩展版本为 1.9.7，已有约1 万用户安装，体积只有 105KiB——相当轻量。评分 5.0，但只有 11 个评价，样本还很小。
中文介绍也明确写了：
"Kimi WebBridge 是一款专为 AI Agent 设计的浏览器插件。安装后，AI 可以帮你操作你的浏览器——打开网页、点击按钮、填写表单、提取信息等，为你自动化各种繁琐的网页操作。"
注意，1 万用户和 11 个评分说明它还在早期阶段，评分样本很小，不能据此判断产品成熟度。但它确实已经在 Chrome Web Store 正式上架，产品形态完整。
Kimi 的 Agent 版图：WebBridge 只是其中一块
Kimi 官网 Features 页面上，WebBridge 和 Websites、Slides、Sheets、Docs 并列，官方定位写得很明确：
"A browser extension for AI agents. It clicks, fills, navigates, and extracts. Tedious work, on autopilot."
「一个为 AI agent 打造的浏览器扩展。它点击、填写、导航、提取。重复工作，自动搞定。」
▲ Kimi 官网 Features 页面，WebBridge 是产品矩阵中的浏览器执行能力
这说明 WebBridge 在 Kimi 的产品体系里有明确位置：它负责的是浏览器侧的执行层。Kimi 做了聊天、做了代码（Kimi Code）、做了文档和表格——现在继续往"操作真实网页和工作流"推进。
▲ Kimi Code 页面，提供 CLI 安装命令，从编码到浏览器操作，Kimi 在把 agent 的手越伸越长
这条产品线的逻辑很清晰：从"会想"到"会写代码"到"会用你的浏览器做事"。
但是——它需要看到你浏览器里的一切
Chrome Web Store 的 Privacy practices 页面列出了 Kimi WebBridge 处理的三类数据：
Web history（浏览历史）：你访问过的网页列表、页面标题、访问时间。
User activity（用户行为）：网络监控、点击、鼠标位置、滚动、键盘记录。
Website content（网页内容）：文本、图片、声音、视频、超链接。
▲ Chrome Web Store Privacy 页面：Web history、User activity、Website content 三类数据全部涉及
开发者声明了三个"不会"：不会把数据卖给第三方，不会用于与核心功能无关的用途，不会用于信用或借贷判断。
但"声明不会"和"技术上做不到"之间有距离。一个能读取你浏览历史、记录你键盘输入、看到你页面所有内容的扩展，它的安全边界完全取决于开发者的自律和平台的审核。
你让 AI 替你填表，它得能看到表。你让它替你点按钮，它得知道按钮在哪。强能力，必然伴随强权限。
社区的冷思考：难点从来不是"能不能点"
X 上有一条值得注意的回复，来自用户 @parzival1213：
浏览器 agent 真正的难点在哪？拥有 live tabs（实时标签页）、读取 page state（页面状态）、保留 logs（操作日志），以及在任何高风险提交前暂停。
这句话点出了浏览器 agent 从 demo 到日常工具之间最大的鸿沟。
Demo 可以展示"自动点点点"。但当你把它用在真实场景——在登录态的 SaaS 里修改数据、提交表单、填写申请——你需要的是：
- 可审计
：它做了什么，能不能查？ - 可暂停
：执行到一半，能不能停？ - 可回滚
：点错了，能不能退？ - 可限权
：哪些页面能看，哪些操作需要确认？
再加上页面 DOM 随时变化、反自动化策略、权限弹窗、登录态过期——浏览器 agent 要面对的工程挑战远比"打开页面点个按钮"复杂得多。
为什么浏览器扩展可能是 Agent 执行层的最短路径
回到 Kimi WebBridge 的产品逻辑。
当 AI 编码工具、CLI agent、桌面 agent 都在争夺执行权时，浏览器扩展是一条很现实的中间路线。原因很简单：
大多数工作流的终点都在浏览器里。
你在 Google Sheets 里整理数据，在 CRM 系统里更新客户信息，在内部管理后台里审批流程，在 Google Forms 里创建问卷。这些工具不一定有 API，更不一定有 MCP server。但它们都有网页界面，而你的浏览器已经登录了。
浏览器扩展走的就是这个缝隙：不必等每个 SaaS 都提供标准接口，只要用户浏览器已经登录，agent 就可以通过浏览器层看到页面、操作页面。
当然，这条路线也有明确的弱点：页面结构变了 agent 可能就不认识了，反爬策略会拦截自动化操作，登录态会过期，权限弹窗需要人工处理。它降低了接入成本，但把更多信任问题推回给浏览器权限、用户确认和日志审计。
这条路线的意义在于：它证明 agent 执行层的竞争已经从"谁的模型更聪明"延伸到了"谁能更快碰到用户的真实工作流"。
最后看回这件事
Kimi WebBridge 的核心信号只有一个：大模型公司正在从"会聊天"推进到"会用你的浏览器替你干活"。
浏览器扩展是目前最贴近用户日常工作流的 agent 执行形态——它不需要 API，不需要 MCP，不需要每个网站单独适配。只要你浏览器打着，它就能动。
但它也同时把最敏感的问题摆上台面：当 AI 能看到你的浏览历史、记录你的键盘输入、读取你页面上的所有内容——你对它的信任边界在哪？
这个问题，Kimi 还没有完全回答。整个行业也还没有。
— END —
