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

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

• 可以直接使用浏览器已有的登录状态
• 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 代理生态中最关键的基础设施之一。