Kimi把浏览器操作做成Skill
近日，Kimi浏览器扩展新增网页操作录制、网页转Skill和会话转Skill功能。AI Agent开始从生成代码，走向直接使用浏览器完成调研、填表、比价和后台操作，Skill也从提示词模板变成了可复用的网页执行流程。
Kimi把浏览器操作做成Skill：AI Agent开始直接使用网页
近日，Kimi浏览器扩展新增了“把网页变成技能”“把操作录成技能”和“把会话存成技能”等功能。它的变化不在于又多了一个能帮你点网页的浏览器插件，而在于：一次成功的网页操作，现在可以被提炼成一个可重复调用的Skill。
**Skill是一种可复用的AI工作流程，它把任务目标、操作步骤、判断规则和输入参数封装在一起，供Agent在后续任务中反复执行。**过去，Skill更多出现在代码编辑器和终端Agent里，用来保存项目规范、部署流程或调试方法；Kimi这次把它延伸到了浏览器，让网页操作也具备了类似软件函数的复用能力。
这意味着，AI Agent的工作边界正在发生变化。它不再只负责写一段脚本、生成一份报告或修改一个代码文件，而是开始直接进入用户已经登录的浏览器，打开网页、点击按钮、填写表单、读取数据，最后把结果交付出来。
一、Kimi这次更新了什么
**Kimi浏览器扩展是一款让AI Agent通过本地浏览器完成网页导航、点击、输入和内容提取的工具。**它原本被称为Kimi WebBridge，后来更名为Kimi浏览器扩展，并增加了浏览器侧边栏入口、网页操作录制和网页结构拆解等能力。
用户可以在浏览器侧边栏中输入“/”，然后选择对应功能。核心路径有三条：
- 把网页变成技能：让Kimi分析一个网站的结构、使用方式和常见操作，把它封装成可调用的Skill。
- 把操作录成技能：用户手动完成一次固定网页流程，Kimi记录操作步骤，再将其整理成可复用流程。
- 把会话存成技能：如果一次对话已经完成了复杂任务，可以把这次任务的上下文、步骤和输出要求保存下来，后续直接调用。
这三种方式解决的是不同问题。
“网页转技能”适合网站级流程。例如，一个数据看板每天都需要按照固定筛选条件导出报表；一个电商平台需要反复搜索商品、筛选价格并提取评价；一个内部系统需要按照固定路径打开页面、选择日期和下载文件。用户不需要从零描述全部步骤，Agent可以先理解网页结构，再生成一套操作能力。
“操作录成技能”则更像浏览器版的宏。用户亲自操作一遍，系统记录点击、输入、跳转和提取动作。下次只要调用这个Skill，再补充日期、关键词或文件名等参数，就可以重跑流程。
“会话存成技能”适合那些难以提前标准化，但已经成功执行过一次的任务。比如，让Kimi搜索多个来源、筛选可信信息、按照固定格式输出一份竞品报告。保存之后，下一次不需要重新解释所有要求。
从产品形态看，这不是简单的“收藏提示词”。提示词通常只保存了应该做什么，Skill还要进一步保存怎么做、在哪个页面做、遇到不同网页状态时如何判断，以及最终结果要以什么格式交付。
二、从写代码到操控网页，Agent的手伸得更长了
**浏览器Agent是能够理解网页内容并代表用户执行浏览器操作的人工智能代理。**它和传统聊天机器人最大的区别，是输出不止是一段文字，而是会对外部界面产生连续动作。
过去两年，AI Agent的主战场明显偏向代码。Cursor、Claude Code、各类终端Agent都在强化文件读写、命令执行、代码搜索和自动测试能力。原因很现实：代码环境结构清晰，有文件系统、终端和版本控制，Agent可以通过工具调用获得较稳定的反馈。
网页环境更混乱。页面会动态加载，按钮可能因为权限、登录状态或网络状况发生变化；同一个动作在不同网站上的实现方式也不一样。传统自动化一般要使用Selenium、Playwright或Puppeteer编写脚本，开发者需要处理元素定位、等待时间、异常重试和页面变化。
Kimi的思路是把这些细节交给Agent和浏览器扩展处理。用户只需要描述目标，或者手动完成一遍流程，系统再将过程抽象成可复用的操作能力。它的价值并不是让浏览器自动化从此不需要工程能力，而是把一次性脚本开发，转向了“先示范、后复用”。
这是一种接近“教会Agent做事”的交互方式：
- 用户完成一次真实任务。
- Agent观察页面结构和操作顺序。
- 系统提取关键步骤、参数和输出格式。
- 用户确认或修改生成的Skill。
- 后续通过自然语言或“/”命令再次调用。
对于开发者而言，这个过程类似把一段临时脚本封装成函数；对于普通办公流程而言，它又更像录制一个宏，只是宏的输入不再局限于固定坐标，而是可以结合网页内容进行判断。
三、底层不是远程控制，而是本地浏览器桥接
**Chrome DevTools Protocol，也就是CDP，是浏览器提供的一套调试与自动化协议，允许外部程序控制页面、读取DOM、截取屏幕并监听浏览器事件。**Kimi浏览器扩展的本地执行链路，正是建立在这类浏览器自动化能力之上。
根据Kimi公开说明，Kimi浏览器扩展由本地桥接服务和浏览器扩展协同工作。Agent将任务发送给本地服务，扩展再通过Chrome DevTools Protocol连接当前使用的Chrome或Edge，完成页面跳转、点击、截图和内容读取，最后把结果返回给Agent。
简化来看，链路大致是：
Kimi Work / Kimi Code CLI
|
v
本地桥接服务
|
v
Chrome或Edge浏览器扩展
|
v
当前网页、登录状态与页面内容
这种架构有一个重要特点：网页操作发生在用户本机的浏览器中，而不是另起一个完全隔离的云端浏览器。用户已经登录的网站可以直接被使用，不需要再次输入账号，也不需要把每个网站的登录流程重新交给Agent。
这对复杂网页任务很关键。很多工作并不是“打开一个公开网页然后抓取文本”，而是进入企业后台、项目管理系统、数据平台或电商商家中心。真正有价值的数据，往往藏在登录后的页面里。
但本地执行不等于没有风险。只要Agent拥有当前浏览器标签页的操作权限，它理论上就可能看到页面上的敏感信息，也可能误点删除、提交或付款按钮。因此，Kimi这类产品能否提供清晰的权限边界、敏感操作确认和执行日志，比“能不能完成点击”更值得关注。
四、它到底适合哪些任务
**网页Skill最适合步骤相对固定、输入参数经常变化、结果格式可以标准化的重复性任务。**这类任务此前通常由人每天手动完成，或者由开发者编写并维护一套脆弱的自动化脚本。
1. 多网站信息整理
例如，用户可以让Kimi在多个租房平台搜索指定区域的房源，按照预算、户型和通勤距离筛选，然后输出统一表格。旅行规划也类似：Agent可以在机票、酒店和攻略网站之间跳转，整理价格、时间和限制条件。
这里的重点不是“帮你搜索一次”，而是把搜索条件和输出格式保存下来。下次只需要修改城市、日期或预算，原来的流程仍然可以复用。
2. 电商比价与商品研究
电商比价是比较适合浏览器Agent的场景。用户可以指定商品型号、价格区间、配送要求和评价阈值，让Agent在多个平台读取价格、规格和评论，再给出排序结果。
与传统搜索摘要相比，浏览器Agent能够进入详情页，处理动态加载内容，并提取搜索结果页没有展示的字段。不过，电商页面经常存在促销规则、会员价、地区库存和登录后价格，Agent输出的结果仍需要用户复核，尤其是涉及购买决策时。
3. 后台数据导出
这是网页Skill更有实际价值的一类任务。很多公司每天都要登录后台，选择日期、部门或业务线，导出一份CSV或Excel文件。流程本身没有技术含量，却会占用大量时间。
用户可以手动演示一次“打开后台、选择条件、点击导出、下载文件”的完整流程，把账号密码设置为保密参数。之后每天只需要提供日期范围，Skill就能完成大部分重复工作。
4. 研究与文献整理
Kimi也可以自动浏览搜索结果，进入论文或报告页面，提取摘要、方法、实验数据和结论，最后按照指定结构生成综述。相比单页问答，这种工作需要多个网页之间持续跳转，更接近研究助理的工作方式。
不过，网页阅读不等于事实核验。Agent能够帮你扩大信息覆盖面，却不应直接替代来源确认。论文是否为原始研究、数据是否被断章取义、网页是否更新过，都需要进一步检查。
五、Skill和传统自动化脚本，谁更可靠
**传统浏览器自动化脚本是由开发者预先定义定位器和执行逻辑的确定性程序，而网页Skill是由Agent结合页面内容动态决定下一步动作的半确定性流程。**两者不是简单的替代关系。
| 对比维度 | 传统脚本 | Kimi网页Skill | 更适合的场景 | |---|---|---|---| | 创建成本 | 需要编写和调试代码 | 可通过示范或自然语言生成 | 临时流程、非技术用户 | | 页面变化适应性 | 依赖定位器，页面改版后可能失效 | 可结合页面语义重新判断 | 页面结构经常变化的网站 | | 执行稳定性 | 流程固定时较高 | 受模型判断和网页状态影响 | 需要人工复核的流程 | | 复杂分支 | 需要工程师显式编写 | 可根据内容动态选择路径 | 信息检索和筛选 | | 可审计性 | 日志、版本和测试体系成熟 | 需要完善执行记录 | 财务、运营和企业后台 | | 长期维护 | 维护成本较高但可控 | 初期轻量，边界情况需修正 | 中低频、变化较快的任务 |
对于每天运行数千次、结果必须完全一致的生产级流程，传统自动化仍然更稳。对于流程变化快、页面数量多、任务需要理解内容的场景，网页Skill的灵活性更有吸引力。
Kimi的优势在于降低了自动化的起步门槛，并且把“写脚本”变成“先做一遍”。但它也继承了Agent的典型问题：页面变化可能导致误判，模型可能遗漏字段，连续操作越长，累积错误的概率越高。
因此，网页Skill更像一个适合人机协作的执行层，而不是完全无人值守的替代品。查询、整理、草拟和下载可以自动化；发送邮件、提交审批、修改关键数据和下单付款，则应保留确认环节。
六、Kimi的产品判断：Skill正在成为Agent的中间层
**Agent工作流的中间层，是连接自然语言目标与具体工具执行的一层可复用能力。**Skill正在承担这个角色。
如果没有Skill，每次任务都需要从头开始解释目标、网页路径、筛选条件和输出格式。Agent虽然能够理解自然语言，但上下文越长，越容易出现遗漏。Skill把这些稳定部分提前固化，只把每次变化的参数留给用户输入。
这和软件工程中的函数、命令行工具以及自动化流水线有相似之处。它们都把一次解决方案转化成后续可以调用的能力。不同的是，Skill的接口通常是自然语言，内部执行可以同时涉及浏览器、文件、搜索和模型判断。
Kimi还支持把Word、PDF、Excel和演示文稿中的流程转换为Skill。这说明它试图处理的不只是网页动作，也包括企业内部已经存在的标准操作流程。过去，SOP通常是一份供人阅读的文档；现在，产品希望把它变成Agent可以执行的工作规范。
这条路线的商业价值很明确：企业里大量低效工作并不需要重新开发一套系统，它们只是把人训练成了“网页机器人”。如果Agent可以读取规则、复现操作并在关键节点请求确认，企业就能用更低成本自动化一批碎片化流程。
但Skill生态最终能否成立，取决于三个问题：Skill能不能跨网站稳定执行，能不能被人理解和修改，能不能在权限和数据安全上让企业放心。只有把这三件事做好，Skill才会从“方便的提示词收藏夹”变成真正的生产工具。
七、开发者和深度用户应该怎么看
第一，网页Skill适合用来验证自动化机会，而不是直接替代所有工程系统。一个重复任务如果每周只执行几次、页面还经常改版，先用Skill验证收益很划算；如果任务涉及高频大规模处理，再考虑用Playwright、Selenium或内部服务重构。
第二，创建Skill时要把输入参数和失败条件写清楚。只告诉Agent“导出本月数据”不够，还应该说明日期口径、文件命名、需要排除的字段、下载后如何检查，以及遇到登录失效时停止执行。Skill越接近生产流程，边界条件越重要。
第三，敏感操作必须设置人工确认。读取数据和整理信息可以自动完成，但涉及删除、提交、发送、支付或修改权限的动作，应要求用户在最后一步确认。对企业用户来说，这不是保守，而是最低限度的控制面。
第四，不要把一次成功误认为长期稳定。Skill需要像代码一样维护。网站改版、字段改名、登录方式变化、验证码出现，都可能让原来的流程失效。Kimi提供了修改、复制和下载.md文件的能力，这使Skill具备一定的可读性，但真正的版本管理和测试机制仍有待完善。
结语：下一场竞争是让Agent真正会做事
Kimi把浏览器操作封装为Skill，表面上是浏览器扩展的一次功能更新，实际上是在重新定义Agent的交互方式：用户不必每次都写提示词，也不必一开始就编写自动化代码，而是可以先完成一次任务，再把经验沉淀成可调用能力。
这条路线比“让模型写更多代码”更接近普通工作现场。现实中的大量工作发生在浏览器里，发生在登录后的后台、表格、管理系统和多个互不相连的网站之间。谁能让Agent稳定地穿过这些页面，谁才真正掌握了从信息生成到任务执行的下一段链路。
Kimi目前最值得关注的地方，不是它能不能自动点击一个按钮，而是它是否能把一次网页操作变成可理解、可修改、可复用、可审计的Skill。前两项已经有了产品雏形，后两项则决定它能否从个人效率工具走向企业级工作流。
对开发者来说，浏览器不再只是Agent读取信息的窗口，也开始成为Agent执行任务的操作系统。对深度用户来说，真正值得尝试的不是让Kimi替你完成一个孤立动作，而是把那些每周重复、规则明确、但一直没人愿意写脚本的流程，逐个沉淀成自己的Skill库。
参考来源
- Chrome DevTools Protocol 官方仓库：用于了解浏览器调试协议、页面控制和自动化能力。
- Playwright 官方仓库：用于对比传统浏览器自动化框架的定位、执行和测试方式。
- Selenium 官方仓库：用于了解经典浏览器自动化方案与网页脚本执行模式。
