Kimi WebBridge：无需云端浏览器，AI 代理也能直接操控你的 Chrome 和 Edge

• 收集招聘网站的职位信息
• 对比多个电商平台的商品价格
• 搜索资料并整理研究内容
• 自动完成重复的网页行政流程

这些能力让 AI 代理能够真正参与日常互联网工作流程。

本地优先架构：不再依赖云端浏览器

很多 AI 自动化系统采用 云端浏览器（cloud browser） 模式：用户把登录和浏览行为放到远程环境，AI 在那里执行自动化。

Kimi WebBridge 的设计思路完全不同。

它由两个部分组成：

• 浏览器扩展
• 本地桥接服务（local bridge service）

AI 代理把指令发送给本地服务，本地服务再通过 Chrome DevTools Protocol 控制浏览器执行操作，例如读取页面、截图、点击元素或跳转页面。

因为所有执行都在本地完成：

• 可以直接使用浏览器已有的登录状态
• Cookies 和会话数据不会离开设备
• 页面内容无需发送到远程自动化环境

Moonshot 的文档明确表示，登录状态和网页内容都会保留在用户机器上，不会被导出到云端。

对于需要登录的网站（例如企业系统、社交平台或内部工具），这大大降低了自动化部署的复杂度。

面向多代理生态的设计

Kimi WebBridge 不是只为某一个 AI 应用设计的功能。

它被定位为 通用的浏览器控制层（agent‑agnostic interface），可以与多种 AI 代理工具配合使用。

官方列出的支持环境包括：

• Kimi Code
• Claude Code
• Cursor
• Codex
• Hermes
• OpenClaw

这种设计意味着 WebBridge 更像是一个 浏览器执行基础设施层：

• AI 模型负责推理与决策
• WebBridge 负责执行网页操作

不同的代理系统都可以调用这层能力。

Kimi K2.6 模型在其中的角色

在 WebBridge 的工作流程中，真正负责“思考”的是 Moonshot AI 的 Kimi K2.6 模型。

Kimi K2.6 是一个面向代理任务设计的多模态模型，采用 混合专家（MoE）架构，总参数规模约 1 万亿，在推理时激活约 320 亿参数，并支持约 256K token 的上下文窗口。

该模型的重点能力包括：

• 多步骤推理
• 工具调用与协调
• 长时间运行的代码与自动化任务

Moonshot 平台表示，K2.6 在 长周期代码生成和自主执行能力方面进行了强化，使 AI 代理能够更稳定地完成复杂工作流程。

在实际系统中，两者的分工通常是：

• Kimi K2.6： 负责规划、推理和决策
• WebBridge： 在真实网页中执行具体操作

例如，一个 AI 代理可能先制定计划：研究某类产品、访问多个网站、收集数据、整理结果；而 WebBridge 负责完成这些浏览器操作。

为什么这次发布值得关注

Kimi WebBridge 的意义不仅在于一个浏览器扩展，而在于 AI 代理基础设施的变化。

许多 AI 代理需要访问真实网站，其中大量服务都需要登录身份验证。云端自动化通常会带来一些现实问题：

• 需要传输账户凭证或会话 Cookie
• 企业合规和数据安全风险
• 远程浏览器环境的管理成本

通过让 AI 在用户自己的浏览器中工作，WebBridge 避开了这些问题，同时保持数据在本地设备上。

如果这种架构被广泛采用，AI 代理在很多场景会变得更实用，例如：

• 网络调研与信息收集
• 企业内部工具自动化
• 表单填写与行政事务
• 登录网站的数据监控与整理

AI 行业正在争夺“代理基础设施”

Kimi WebBridge 也反映了 AI 行业的一种趋势：竞争不再只发生在模型能力上，而是在 完整的代理技术栈（agent stack）。

这一技术栈通常包含三个层次：

• 模型：负责推理与规划
• 工具：执行具体任务
• 连接层：把 AI 接入真实软件环境

在 Moonshot 的体系中：

• Kimi K2.6 提供推理能力
• WebBridge 提供浏览器执行能力

浏览器仍然是互联网最重要的应用入口之一，因此谁能掌握这一层执行能力，谁就更有机会构建下一代 AI 工作流平台。

随着 AI 从“回答问题”走向“完成任务”，浏览器控制层很可能成为 AI 代理生态中最关键的基础设施之一。