录一遍就完事了！手把手带一次，AI学会替你填表刷网页

新智元报道

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

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

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

真正卡住它们的，是另一个问题：每接一个新任务、每换一个新网站，几乎都要让最强、也最贵的那个模型，从零开始再把整个流程摸索一遍。

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

在摸索一遍之后呢？就算这次侥幸做成了，这点经验也往往随着这一轮对话一起蒸发。

下一次同类任务，再换一个 Agent，还要从头试错、再踩一遍同样的坑。

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

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

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

录制：在浏览器里做任务的时候，把全过程完整记录下来——任务指令、每一步的页面观察（既有渲染出来的截图，也有结构化的 DOM / 可访问性树快照）、用户的每一个动作（点击、输入、跳转、提交，并带着对应的元素定位）、页面给出的反馈（页面跳转、校验与报错信息、完成信号），以及任务最终落到哪个状态。

转写：关键在于，它不是把这段操作存成一段「回放脚本」，而是由模型把它转写成一份自然语言的 Skill——一份说明书式的「技能卡」，写清楚这类任务该怎么做、怎么判断做对了。

执行：再把这份 Skill 交给任意一个模型去读。它据此在真实页面上自己落地操作，而不是机械复刻某一次的点击坐标。

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

项目发布后6小时，BrowserBC已经引发了海外开源社区超过2500条相关讨论，登上了Twitter的Today News。

AI 社区最具影响力的前沿论文和开源项目分享者AK也关注并分享了该项目。

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

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:

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

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

第一步，录制。

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

第二步，转写成 Skill。

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

意图：在预订网站找到最佳的住宿选项；

关键步骤：先写基本信息，搜索之后逐项应用筛选器——这正是小模型最容易不理解或者做不到的地方；

完成判据：最后输出可以人工核查的版本；

要避免的坑：官方筛选器可能和用户实际需要的标准不一样，如有需要则需要自己编写脚本筛选。

第三步，交付给一个小模型执行。

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

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

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

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

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

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

把操作沉淀成Skill

并管好越来越多的Skill

BrowserBC 的方法部分，其实就回答两个问题：

一段操作该怎么总结、总结时要注意什么；以及总结出来的成千上万个 Skill，该怎么管理。

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

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

原始的浏览器轨迹往往非常嘈杂——里面有误点击、无意义的等待、重复尝试、临时的页面状态，还可能夹着隐私信息。因此在转写之前，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 从能用走向好用的临门一脚。