企业官网建设流程全解析

Kimi WebBridge 发布约 4 个月后，被改头换面重新命名为Kimi 浏览器扩展，并在原有能力之上做了两处关键升级：

1. 在浏览器侧边栏可以直接登录对话，让 Kimi 操作当前网页；
2. 新增将网页操作录制成 Skill 的能力，方便下次一键复用。 从产品形态看，新版延续了「网页桥梁」的设计——一头连接本地 Agent，一头连接 Chrome 或 Edge 扩展。Agent 发出指令后，扩展在用户真实浏览器中跳转页面、执行操作并回传结果。改版之后，旧版由本地 Agent 调用扩展的链路继续保留，新版侧栏入口则让普通用户不用配置本地环境就能直接上手。

这次升级改了什么

改名：Kimi WebBridge → Kimi 浏览器扩展

新增侧边栏入口：
登录 Kimi 账号即可直接对话操作当前网页，免去本地 Agent 配置

新增 Skill 录制：演示一遍操作，AI 提炼成技能，下次输入/直接调用复用

新增网页 → 指令：把常用网站的操作拆成 CLI 式命令

保留本地 Agent 链路：Claude Code / Codex / Cursor / Kimi Work 等照常远程驱动

Skill 录制是怎么工作的

它不是录像回放式的 RPA 录制，而是AI 提炼：

• 像平常一样手动操作一遍，Kimi 记录每一步；
• 点击「停止并生成」，Kimi 把过程提炼成技能；
• 确认技能的名称、步骤和参数后保存，密码等敏感信息可设为保密参数，回放时再填写；
• 之后输入/选择该技能，Kimi 就会照着做一遍；
• 技能的步骤和内容随时可以修改。 本质是把「一次性操作」变成「流程资产」——浏览器自动化的竞争焦点，正在从「能不能执行」转向「能不能沉淀」。

对用户的核心价值

第一，降低 Agent 操作浏览器的使用门槛。旧版依赖本地 Agent 调用扩展，新版在浏览器侧边栏直接可用，省去客户端配置步骤，普通用户登录账号即可使用。

第二，把一次性操作变成可复用流程。例如每天打开同一个站点查询新闻并导出数据，下次直接调用即可，省去重复描述步骤。顺利完成的会话本身也能保存为 Skill。

第三，与 Kimi Code Desktop 形成互补。Code Desktop 为 Agent 提供项目工作台与内置浏览器，适合改完网页立刻查看效果；浏览器扩展则面向用户日常使用的 Chrome / Edge，处理跨站点的常规网页任务。两者结合，覆盖了 Agent 在桌面端项目工作与浏览器端日常操作两类场景。

适用场景

重复性网页流程：每天、每周固定在某些网站执行相同步骤，例如抓取公开数据、填写固定表单、汇总页面信息，这类任务最能从 Skill 录制中受益；

跨站点信息处理：在多个网站之间跳转、对比或汇总信息的轻量任务，例如竞品价格对比、商品信息归档；
个人浏览器的轻量自动化：不想专门搭建脚本或 RPA，只希望用对话方式让浏览器替自己完成一些机械操作；
配合 Kimi Code Desktop 做项目验证：开发或修改网页项目时，让 Agent 在内置浏览器里预览效果，再用扩展在用户日常浏览器中验证真实站点。

什么情况下值得用

任务高度重复且步骤相对固定：Skill 的价值在于复用，任务越规律收益越大；如果每次任务目标和路径都不同，录制 Skill 的意义有限；

目标网站结构稳定：页面改版、动态加载、登录态变化都会让操作中断，遇到复杂页面时可能需要截图确认页面状态再调整指令；

对实时性与准确性要求适中：浏览器自动化天然受限于网络与页面渲染，遇到反爬或风控严格的站点，成功率会下降；

已有 Kimi 账号与日常使用的 Chrome / Edge：扩展依赖 Kimi 账号登录，浏览器侧的兼容性目前以 Chrome 和 Edge 为主。

挤进了一个什么赛道

当前浏览器自动化分三个流派：

云端 Agent：OpenAI Operator、Manus、Perplexity Comet，云侧虚拟浏览器，并行能力强；

桌面 Computer Use：Claude Computer Use，操作整个操作系统，桌面级操作；

浏览器扩展：Claude in Chrome、Kimi、Browser Use 生态，住在用户真实浏览器里，复用真实登录态。

Kimi 的差异有两个关键点：

一是不绑模型，对 Claude Code、Codex、Cursor 全部开放，定位是「浏览器的 Agent 中间层」；

二是把 Skill 录制做成核心卖点——竞品普遍有执行、没沉淀。

亮点与隐忧

亮点

双入口同时吃大众（侧边栏）与开发者（本地 Agent）两类人群，基本盘和增量都不丢；

隐私设计有意识：保密参数避免技能库变成密码库，官方也提示失败时先截图确认页面状态；
与 Kimi Code Desktop 形成「开发验证 + 日常使用」闭环，覆盖 Agent 的两大高频场景。

隐忧

确定性与弹性的悖论：Skill 是刚性步骤，页面改版、动态加载、登录态过期都会打断；官方让「失败先截图再调指令」，其实是承认了这个张力；

跨站可移植性存疑：录制的步骤若依赖选择器或页面结构，换个站点即失效，Skill 库的复用价值会被站点多样性稀释；

隐私暴露面比表面更大：保密参数只保护密码输入，运行在真实浏览器里，Cookie、浏览痕迹、已登录账号全在 Agent 触达范围内，涉资金、权限、对外发布的操作人工复核不能省；

平台锁定效应：侧边栏绑定 Kimi 账号，Skill 库绑定 Kimi 生态，用户沉淀的流程资产越多，离开成本越高——这既是护城河，也是用户要承担的绑定成本；

反爬与风控是硬边界：验证码、风控严格的站点成功率下降，这条边界短期难突破，决定了它不适合所有网页任务 ；

落地建议

从最痛的一两个重复任务开始：先挑一两个每天都在做、机械步骤最多的网页流程，试着录成 Skill 跑几次，再逐步扩展；

遇到失败先截图再调整：页面结构变化或动态加载是常见卡点，失败时先截图确认页面状态，再调整指令；

Skill 命名与归档要规范：随着录制的 Skill 数量增加，建议按业务或网站命名并打标签，便于后续检索；

关键任务保留人工复核：浏览器自动化对验证码、登录态、页面改版都比较敏感，涉及资金、权限或对外发布的操作建议保留人工确认环节；

关注成本与隐私边界：任务在真实浏览器中执行，浏览器里已登录的账号、Cookie、缓存都会被涉及，使用前应确认不会触碰到敏感系统或受合规约束的数据。

结论

把这次升级看作「把 Agent 的一项技能变成用户的一份资产」。它更适合结构稳定、步骤规律的轻量场景，当成能慢慢积累的「网页流程库」，比指望它一次解决所有网页任务更现实。对开发者而言，浏览器自动化的竞争焦点正在从「执行能力」转向「沉淀能力」——谁能让用户的操作变成可复用、可积累的流程资产，谁就握住了下一个增长点。