Kimi WebBridge：把你的浏览器交给 AI Agent 来操作

预计阅读时间：9 分钟

月之暗面刚发布的 Kimi WebBridge，解决了一个长期卡住 AI Agent 生态的问题——AI 能生成代码、能调用 API，但一旦需要操作需要登录的网页，就束手无策。WebBridge 让 AI 带着你的登录态去点击、输入、提取信息，相当于给 Agent 发了一张你的浏览器"通行证"。

为什么需要"带登录态的浏览器操作"

大部分有价值的网页操作都发生在登录之后：提交 JIRA 工单、填写内部系统表单、查看 CRM 数据、跨平台对比价格。这些场景里，API 往往不存在或者文档不全，唯一可靠的操作路径就是"像人一样用浏览器"。

现有的 Agent 方案要么走无头浏览器（Puppeteer / Playwright），要么走官方 API。前者没有你的 Cookie，碰到登录墙就停；后者覆盖面窄，且每个平台对接成本高。Kimi WebBridge 的思路是：直接复用你已经在浏览器里的登录态，让 Agent 以你的身份操作，省掉认证这一步。

工作机制

从公开信息看，WebBridge 的核心流程大致如下：

浏览器插件常驻——安装后，插件在后台监听来自 AI Agent 的操作指令。
携带用户登录态——插件读取当前浏览器的 Cookie、Session、localStorage，Agent 的每一步操作都带着这些凭证发起。
执行浏览器动作——点击、滚动、输入文本、填写表单、截图提取信息，覆盖人能做的大部分页面操作。
跨站点整合——Agent 可以在多个站点之间跳转，把分散的信息拼在一起返回。

支持的 Agent 列表已经覆盖了主流编码/Agent 工具：Kimi Code、Claude Code、Cursor、Codex、Hermes Agent、OpenClaw 等。这意味着你不需要换工具，只需要装一个插件。

实际能做什么：几个典型场景

场景一：自动填表提交

Agent 接到指令"在某某后台创建一条记录"，WebBridge 打开对应页面，定位表单字段，逐项填入内容，点击提交。整个过程不需要你手动打开浏览器。

场景二：跨站信息聚合

"对比 A 站点和 B 站点上同一款产品的价格和库存"。Agent 分别访问两个站点（带着你的登录态），提取数据，汇总成表格返回。

场景三：定时巡检

配合 Cron 或 Agent 调度，每天自动登录内部监控面板，截图关键指标，异常时推送通知。

动手试一下：用 Claude Code + WebBridge 自动提取页面数据

以下示例展示如何用 Claude Code 配合 Kimi WebBridge，自动登录一个内部系统并提取数据。假设你已经安装了 WebBridge 插件和 Claude Code CLI。

第一步：安装 Kimi WebBridge 浏览器插件

在 Chrome/Edge 扩展商店搜索 "Kimi WebBridge" 安装，安装后插件会自动与本地 Agent 服务建立连接。

第二步：用 Claude Code 发出浏览器操作指令

在终端启动 Claude Code，直接用自然语言描述你要做的操作：

# 启动 Claude Code
claude

# 在 Claude Code 交互界面中输入指令（以下为示例 prompt）
> 请帮我操作浏览器：打开 https://internal-dashboard.example.com/orders，
> 登录后提取今天所有订单的编号和金额，汇总成表格返回。
> 使用 Kimi WebBridge 执行浏览器操作。

Claude Code 会通过 WebBridge 的本地通道把操作指令发给浏览器插件，插件带着你的登录态执行页面操作，再把提取结果回传给 Agent。

第三步：用 Python 脚本封装成可复用的自动化任务

如果你想把这类操作变成定期运行的脚本，可以这样组织：

"""
Kimi WebBridge + Agent 自动化示例
假设：WebBridge 插件已安装，本地 Agent 服务端口为 8765
以下为伪代码，展示调用流程，实际 API 以官方文档为准
"""

import requests
import json
from datetime import datetime

WEBBRIDGE_ENDPOINT = "http://localhost:8765/execute"

def extract_daily_orders():
    """通过 WebBridge 让 Agent 操作浏览器，提取订单数据"""
    task = {
        "action": "browse_and_extract",
        "url": "https://internal-dashboard.example.com/orders",
        "steps": [
            {"type": "wait_for_login", "timeout": 5},      # 等待登录态生效
            {"type": "click", "selector": "#date-filter"},  # 点击日期筛选
            {"type": "input", "selector": "#date-input",
             "value": datetime.now().strftime("%Y-%m-%d")},
            {"type": "click", "selector": "#apply-filter"},
            {"type": "extract_table",
             "selector": "#orders-table",
             "fields": ["order_id", "amount"]}
        ],
        "return_format": "json"
    }

    resp = requests.post(WEBBRIDGE_ENDPOINT, json=task, timeout=30)
    data = resp.json()

    # 汇总输出
    total = sum(float(row["amount"]) for row in data["rows"])
    print(f"今日订单数: {len(data['rows'])}, 总金额: {total}")
    return data

if __name__ == "__main__":
    orders = extract_daily_orders()
    # 可进一步写入数据库或推送通知

注意：上述 Python 调用接口为假设性示例，WebBridge 的实际本地通信协议以月之暗面官方文档为准。核心思路是——Agent 通过本地端口向插件发送结构化操作指令，插件在浏览器中执行后返回结果。

需要留意的风险和边界

把登录态交给 Agent，便利性大幅提升，但安全边界必须认清：

权限即风险：Agent 拿到你的 Cookie，等于拿到你在该站点的全部权限。指令描述要精确，避免 Agent 误操作（比如删数据而非读数据）。
操作可审计性：建议在内部系统中开启操作日志，记录哪些动作是 Agent 通过 WebBridge 发起的，便于事后追溯。
敏感站点慎用：涉及支付、转账、权限变更的站点，不建议直接交给 Agent 全权操作。可以先在只读/低权限账号上验证流程。
插件更新与兼容性：浏览器插件更新可能影响 Cookie 读取方式，长期运行的自动化任务需要关注版本兼容。

上手建议

先从只读场景开始——信息提取、数据对比，不涉及写入操作，风险最低。
逐步放开写入权限——确认流程稳定后，再让 Agent 填表、提交，并加上人工确认环节。
搭配现有 Agent 工具——你已经在用 Claude Code 或 Cursor，不需要换工具，装插件即可接入。
关注官方协议文档——WebBridge 刚发布，本地通信协议和 API 格式还在迭代，动手前先查最新文档。

Kimi WebBridge 的意义不只是"又一个浏览器自动化工具"，而是把 AI Agent 生态里缺失的那块——真实用户的浏览器身份——补上了。Agent 终于能走到登录墙后面去干活，这才是自动化从"能跑脚本"到"能替你办事"的关键一步。