BrowserBC克隆人类点击：一次操作即可让所有智能体获得能力

从零摸索到一次复用：BrowserBC如何将人类操作“蒸馏”为Agent核心技能

今天我们来深入探讨 BrowserBC 这一项目，它解决了一个非常实际的问题。

Agent 操作浏览器本身已经不再是难点——像 Claude、Codex 这类 Agent 能够读取页面、识别按钮和输入框，并执行点击、输入、跳转、提交等动作。但它们真正被卡住的地方在于另一个核心瓶颈：

每当接手一个新任务、或者面对一个陌生的网站，几乎都需要调用最强、也最昂贵的模型，从头到尾把整个流程重新摸索一遍。

而这种“从零开始”的探索过程，往往容易出各种差错：

陷入死循环，在几个页面之间反复跳转；逐渐偏离最初的意图，越走越远；在搜索结果中来回切换却始终未能完整获取信息；或者明明已经接近答案，却提前收手、草率结束。

更棘手的是，即便这次侥幸完成了任务，这些经验也会随着这一轮对话而消散。下次遇到同类任务，换个 Agent，依然得从头试错，再次踩进同样的坑。

于是，一个朴素的问题浮出水面：能不能做一次、复用很多次？

更进一步——能不能让人把任务认真执行一遍，将这一遍操作中的“门道”完整打包，然后交给一个更便宜、更小型的模型，让它照着做就能完成同一类任务？

Einsia AI 旗下 Na vers Lab 发布的开源项目 BrowserBC 给出的答案，是一条三步范式：录制→转写为Skill→交付执行。

• 录制：在浏览器里执行任务时，将全过程完整记录下来——包括任务指令、每一步的页面观察（既包含渲染截图，也包含结构化的DOM/可访问性树快照）、用户的每一个动作（点击、输入、跳转、提交，并附带对应的元素定位）、页面给出的反馈（页面跳转、校验与报错信息、完成信号），以及任务最终所落到的状态。
• 转写：关键之处在于，系统并非将操作存为一段“回放脚本”，而是由模型将其转写成一份自然语言的Skill——一份说明书式的“技能卡”，清晰阐述这类任务该怎么做、如何判断做对了。
• 执行：然后，将这份Skill交给任意一个模型去读取。模型据此在真实页面上自主落地操作，而非机械复刻某一次的点击坐标。

通俗来说，BrowserBC 有点像Agent时代的“按键精灵”。

传统的按键精灵能录制鼠标点击与键盘敲击并回放——但录的是写死的坐标和按键，页面一变、布局一动，整段脚本立刻失效。

BrowserBC 录的不是坐标，而是将这一遍操作转写成一份讲清“该做什么、怎么算做完”的技能：

它能够被另一个模型读懂，能在已经变化的页面上举一反三，还能被不断合并、复用——这是一种会“理解”、能迁移、且能直接交给别人使用的按键精灵。

这也揭示了 BrowserBC 的核心——技能从哪里来，和技能由谁来执行，可以彻底分离。

人在浏览器里把任务做一遍，这一遍操作被转写成技能；之后照着技能把同类任务做下去的，是另一个、甚至更小、更便宜的模型。技能一旦被转写成自然语言，就能在模型之间自由传递、复用、组合。

这正是通往“通用网页浏览”的关键一步：把人类日常的浏览器行为蒸馏给Agent去执行。

BrowserBC将人类的浏览器操作轨迹蒸馏成可复用的自然语言技能，为Agent访问陌生网站提供“决策先验”。

Github：https://github.com/Einsia/Browser-BC
Blog：https://lab.einsia.ai/browserbc/
Paper：https://lab.einsia.ai/browserbc/paper

研究团队录制了一个典型案例：

任务很常见：旅行前想在目的地找一处安心、方便、实惠的民宿，需要在预订网站输入时间、地点、预约人数，按照网站评分、评分数量筛选，并排序找出最优选项。

这类任务看起来简单，但小模型经常栽在上面——要么不理解任务流程，要么不会使用筛选功能，要么产生幻觉输出虚构信息假装完成。

第一步，录制。研究团队先让一个人完整执行一遍：进入网站→输入时间地点人数→应用合适的筛选器→阅读所有搜索结果→找到最佳选项。整个过程被原样记录下来。

第二步，转写成Skill。系统将这段操作转写成一张技能卡，而非一段坐标回放。卡片上书写的是这一类任务的通用门道：

• 意图：在预订网站找到最佳的住宿选项；
• 关键步骤：先填写基本信息，搜索之后逐项应用筛选器——这正是小模型最不容易理解或做不到的地方；
• 完成判据：最后输出可人工核查的版本；
• 要避免的坑：官方筛选器可能与用户实际需要的标准不一致，如有需要则需自行编写脚本筛选。

第三步，交付给一个小模型执行。这张卡片被交给一个明显更小的模型，让它去完成另一次旅程的信息检索，执行同类型任务。

没有这张卡片时，它要么跌跌撞撞卡死或很久才能勉强完成，要么直接输出幻觉；拿到卡片后，它立刻明白要输入什么信息、要核查哪些界面、哪些依赖网站官方、哪些需要自己判断——于是稳定地完成了任务。

就这样，BrowserBC把“操作浏览器”这一日常行为，变成了能被Agent复用的技能。人把路趟通一次，系统将其转写成说明书，Agent型则负责照着说明书把同一类路走顺。

而且，这一路径天然具有可复用、可扩展的特性。

人类访问网站的分布服从幂律分布：常见站点构成了人类访问的大部分，对于这些站点，使用的人越多，Skill库就会收敛得越完备；更关键的是，针对稀疏的长尾分布，BrowserBC让用户再也不需要等待那些落后的旧网站自己提供MCP（或官方Agent接口）了。

现实是，大量老网站永远不会专门为Agent开放一套干净的机器接口；而BrowserBC直接复用人类在“为人设计的界面”上积累的操作经验——只要人能用浏览器将其用起来，Agent就能借助蒸馏出的技能将其用起来。

换句话说，一个网站能否被Agent高效访问，不再取决于网站方是否愿意配合、是否肯升级，而取决于有没有人已经在这个网站上成功走通过路径。

这恰恰是“通用”二字的底气所在。

BrowserBC将嘈杂的浏览轨迹清洗、蒸馏为可复用的自然语言技能，并进一步组织成可扩展的技能图，最后检索相关技能指导Agent完成新任务。

BrowserBC的方法部分，其实回答了这两个问题：一段操作该如何总结、总结时要注意什么；以及总结出来的成千上万个Skill，该如何管理。

原始的浏览器轨迹往往非常嘈杂——包含误点击、无意义的等待、重复尝试、临时的页面状态，还可能夹带隐私信息。因此，在转写之前，BrowserBC会先做清洗，并按照语义将轨迹切分成一段段连贯的子过程，而非按固定长度硬切。

每一段会先被抽取成一份“证据（evidence）”：保留任务指令、这段操作前后的页面状态、用户采取的关键步骤、页面给出的反馈，以及成功或失败的信号。

然后，将证据转写成结构化的自然语言Skill卡，用固定字段说明“该做什么、怎么判断进展、怎么算完成、失败了怎么办”，以及它从哪来、在什么场景下适用。

这样一张卡，既能直接喂给语言模型作为上下文，又方便人类审阅和修改。

这里有一个最应遵守的原则：只保留“可迁移的过程性知识”，剥离“会变、会泄露的细节”。

• 要剥掉的：精确坐标、DOM选择器、临时ID、登录态、隐私文本，以及任何指向具体答案、针对评测checker的内容；
• 要留下的：在语义层面“该做什么、怎么判断进展、怎么算完成”。

举个例子，一张“填表单”技能卡写的是“按语义标签找到对应字段、把任务给定的值原样填进去、提交后确认页面出现成功状态”，而不是“点 (x, y)、再点那个id是某串字符的按钮”。

原因很直接：网页时刻在变，布局、DOM、版本、登录态都会变化，克隆坐标和选择器极其脆弱；而克隆“做什么 + 怎么判断完成”才真正具有迁移性。

还有两点值得一提：

其一，一条成功轨迹就足以蒸出一个可用技能（它本身就刻画了一种可行解的结构）；

而将同一任务的多次尝试（包含失败）放在一起，技能会更稳健——成功的运行强化执行步骤，失败的运行则暴露缺失的前置条件，催生出显式的恢复策略。

其二，转写时需做一次泄露检查：技能卡只应记录可复用的过程，不应将具体答案夹带进去。

如果每条轨迹都生成一个互相独立的技能，库很快就会失控：重复、冗余、甚至互相冲突。

BrowserBC的做法是将库组织成一张技能图（skill graph）。

每当产生一个候选技能，系统就判断应该将其新增（add）为一个新节点、合并（merge）进已有技能，还是登记为某个更通用技能的特化（specialize）：

• 当两个技能在意图、前置条件、步骤、效果、终止证据上彼此相容时，就合并；
• 当它们适用条件不同、所需信息不同、或约束互相冲突时，就保持分开。

图中的节点是技能，边是技能之间的关系——时间依赖、特化、同一子目标下的替代方案，以及同一状态下的互斥。于是，一个通用过程（比如“填表单”）可以连接到它的各种特化（支付、改资料）和对应的失败恢复技能，而不必将它们压成一条扁平的条目。

这张图带来三件事，也正体现了BrowserBC所说的scalable的真正含义：

将重复的演示合并成可复用的节点，而非无限堆叠样本；让检索和更新仅作用于相关的局部区域；支持增量精炼——来一条新轨迹，只更新受影响的技能及其邻居。

需要强调的是，这张图的价值在于“组织”：学习与复用的基本单元始终是那张自然语言技能卡，而图将这些卡片有序地存放、检索和更新起来，这正是技能库能持续扩张却不失控的关键。

到了执行端，检索也刻意做得很轻：按照语义相似度（有额外信息时再叠加与当前页面上下文的兼容性）挑选出一小撮相关技能，塞进Agent的上下文，剩下的落地交给Agent自己读取当前页面来完成。

技能既不是可执行脚本，也不是需要照搬的演示，它只是将Agent引导到蒸馏出的行为模式上，而每一个具体动作仍然是对着当前页面现选的。

BrowserBC首先在WebArena-Hard上接受检验：

258个经人类核验的任务，覆盖GitLab、电商及其后台、论坛、跨站点组合等六类自托管站点。

实验严格控制变量——Agent、动作接口、步数与时间预算全部固定，唯一变量是是否注入BrowserBC检索到的Skill。

结果是：base agent成功率为60.5%（156/258），注入技能后提升到81.4%（210/258），提升了20.9个百分点，挽回了基线原本失败的54个任务。

更强的检验来自ClawBench：

152个任务跑在真实线上网站上，页面布局与操作流程会随不同运行而变化，且以写操作为主。

这个设定抽掉了“靠记忆取巧”的可能——任何编码精确坐标、DOM选择器或缓存页面状态的技能，在这里只会越用越糟。

结果是：skill-free基线只解出50/152（32.9%），注入技能后解出104/152（68.4%），提升35.5个百分点，几乎将解出的任务数翻了一倍，且在全部八个类别上普遍成立。

BrowserBC在WebArena-Hard与ClawBench上的性能表现。

事实上，技能不仅提升了成功率，还缩短了完成任务所需的交互。

在WebArena-Hard任务上，Agent的平均工具调用次数从31.2降至22.7（−27.3%）。

这与“技能作为流程性先验”的定位一致：

它削减了试探性导航与反复的页面查看，而将底层grounding留给执行时的实时页面状态。

BrowserBC既能提升交互效率，又能让蒸馏出的技能在不同模型间迁移。

讨论一：Skill是一份“带置信度的先验”，而非一条命令。

有一个细节很能说明问题：

在WebArena-Hard上，如果强制Agent逐字照搬检索到的技能——哪怕当前页面证据与它矛盾——成功率只有77.5%；而允许它选择性使用、在与页面冲突时以页面为准，才达到81.4%。

更进一步，约3.9%（10/258）的任务里，盲目照搬技能反而把本来能做对的做坏了。

这恰恰印证了那条核心判断：自然语言技能的价值在于“提示策略”，落地永远要交给执行模型去读当前页面。

讨论二：技能是“蒸馏一次、便宜复用”的模型无关对象。

BrowserBC的一个设计主张是：

技能可以由一个强模型蒸馏一次，再交给另一个更便宜的Agent在执行时复用。

团队在WebArena-Hard任务上，将“蒸馏技能的模型”与“执行技能的模型”交叉组合，得到了两点结论。

其一，技能质量主要在蒸馏阶段决定：Sonnet-4.6蒸馏出的技能能同时大幅提升两个执行器（+24与+20个百分点），而Qwen-3.7蒸馏的技能只带来微弱增益。

其二，高质量技能能跨执行器迁移：装备了Sonnet-4.6技能的小Agent达到77%，逼近大Agent的80%，直接坐实了“蒸馏一次、便宜复用”的设想。

讨论三：剩下的难，难在“执行”而非“缺知识”。

对仍然失败的案例进行人工审计后发现，瓶颈大多落在执行精度，而不是缺少知识：

长表单漏掉某个字段、目标对象有歧义、长程任务将预算耗在中间页、或者模型自身推理过长“跑飞”。

这些情况里技能本身是对的、也用上了，限制因素是“按流程执行的保真度”——也就是底层模型的能力。

这也划出了“小模型执行”的可行边界：技能能补“该怎么做”，补不了“手稳不稳”。

讨论四：迁移到浏览器之外——OSWorld案例研究。

论文还在30个OSWorld风格的Ubuntu桌面任务上做了一次诊断性的迁移研究——

需要说明的是，这并非将其当作一项完整的OSWorld刷榜，而是考察“方法的哪一部分能迁移”。

30个任务里，17个在配上匹配技能后得到改善，说明过程性先验确实能跨过浏览器的边界发挥作用。

真正可迁移的并不是浏览器专属的动作序列，而是那份过程性先验——前置条件、语义状态如何转移、进度里程碑、终止证据、失败如何恢复。在浏览器里它落在页面、链接、表单上；在桌面上则落在窗口、文件、对话框、持久设置上。

剩下的案例则划出了方法的边界：少数任务本来就足够简单、不需要技能；一部分卡在GUI控制本身（窗口焦点、模态弹窗、文件选择器状态）而非缺知识；还有个别案例因为检索到错配的技能而被“自信地带偏”。

也就是说，当缺的是“流程结构”时，技能最有用；当缺的是底层GUI grounding、或检索喂错了先验时，技能帮不上忙，甚至会添乱。

BrowserBC不是一个炫技的方法。

它真正重要的地方在于，它指明了人类浏览器轨迹的价值：

这是人类群体在浏览器迷宫中走出来的高效操作路径。

BrowserBC做的事情，就是将这些隐含经验的轨迹蒸馏成Agent可用的skill。

核心启发在于：

第一，提升Agent的Browser Using能力，关键是要为其补齐完备的网页逻辑知识。

第二，人类与虚拟世界的交互过程，本身就是一种尚未被充分利用的数据资源。

第三，如果这些轨迹可以被持续蒸馏和管理复用，那么Agent就可以从“可以操作网页”，逐渐走向“高效”操作网页。

所以，BrowserBC的核心不是教Agent点击网页——它是在信息不完备的环境里，用人类轨迹为Agent补上决策所需的先验。

在这个意义上，真正决定Web Agent上限的，从来不是“是否能够复现某个浏览器操作流程”，也不是“是否快速拼装出一个看似可运行的系统”或是“Demo出一个热门概念”，而是是否真正构建了可以持续积累、可复用、可迁移的经验结构。

这可能是让Web Agent从能用走向好用的临门一脚。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：BrowserBC克隆人类点击：一次操作即可让所有智能体获得能力要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题