BrowserBC：克隆人类点击，让一次网页操作转化为所有Agent的能力

允中 发自 凹非寺量子位 | 公众号 QbitAI

Agent从来不是不会用浏览器，只是浪费太多时间在探索——BrowserBC把人类轨迹蒸馏成可复用Skill来完成Behavior Cloning，用户点一遍，Agent照着就能跑通。

今天的Web Agent，已经不缺「会操作」这件事。

Claude、Codex这类Agent能看页面、能识别按钮和输入框，能点击、输入、跳转、提交。

真正卡住它们的，是另一个问题：

每接一个新任务、每换一个新网站，几乎都要让最强、也最贵的那个模型，从零开始再把整个流程摸索一遍。

而这种「从零摸索」，常常摸着摸着就出岔子：

陷进死循环，在几个页面之间反复横跳；慢慢偏离最初的任务意图，越走越远；在搜索结果里来回切换却始终没读全；或者明明已经很接近答案，却提前收手、草草交差。

在摸索一遍之后呢？就算这次侥幸做成了，这点经验也往往随着这一轮对话一起蒸发。下一次同类任务，再换一个Agent，还要从头试错、再踩一遍同样的坑。

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

更具体一点——能不能让人把任务认真做一遍，把这一遍操作里的「门道」打包下来，然后交给一个更便宜、更小的模型，让它照着做，就能完成同一类任务？

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

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

说得通俗一点，BrowserBC有点像agentic时代的「按键精灵」。

传统的按键精灵，会把人的鼠标点击和键盘敲击录下来再回放——但它录的是写死的坐标和按键，页面一变、布局一动，整段脚本立刻就废了。

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

人类一次录制，Agent就能模拟

研究团队录制了一个case：

视频地址：
https://mp.weixin.qq.com/s/OFXkRh_keR4HzgTImCGjVg

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

这类任务看起来不难，但是小模型经常栽在它上面——不是不理解任务，而是要么不知道怎么用筛选功能，要么产生幻觉输出虚构信息假装完成。

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

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

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

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

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

就这样，BrowserBC把「操作浏览器」这件每天都在发生的事，变成了可以被Agent复用的技能。人把路趟通一次、由系统转写成说明书Agent型负责照着说明书把同一类路走顺。

而且，这条路天然是可复用、可扩展的。

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

现实是，大量老网站永远不会专门为Agent开放一套干净的机器接口；而BrowserBC直接复用人类在「给人看的那套界面」上积累下来的操作经验——只要人能用浏览器把它用起来，Agent就能借由蒸馏出的技能把它用起来。

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

这恰恰是「通用」二字的底气所在。

方法：怎么把一次操作转写成能用的Skill，又怎么把越来越多的Skill管起来

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

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

第一个问题：怎么转写，以及要特别注意什么？

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

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

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

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

这里有一个最该注意的原则：只保留「可迁移的过程性知识」，剥离「会变、会泄露的细节」。

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

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

原因很直接：网页天天在变，布局、DOM、版本、登录态都会变，克隆坐标和选择器极其脆弱；而克隆「做什么 + 怎么判断完成」才真正迁移得动。

还有两点值得一提：

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

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

其二，转写时要做一遍泄露检查：技能卡只该记可复用的过程，不该把具体答案夹带进去。

第二个问题：Skill怎么管理？

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

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不是一个炫技的方法。

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

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

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

核心启发在于：

第一，提升Agent的Browser Using能力，其实关键在于给它补齐完备的网页逻辑知识。

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

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

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

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

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