最强模型每次重新学上网？BrowserBC项目实现一次操作永久复用

徽声在线发布

Agent 并非无法使用浏览器，而是往往在探索过程中耗费了大量时间——BrowserBC 项目通过将人类操作轨迹提炼为可复用的技能（Skill），实现了行为克隆（Behaviour Cloning）。用户只需操作一次，Agent 便能按照提炼的技能顺利完成任务。
项目发布仅6小时，便在海外开源社区引发了超过2500条讨论，并登上了 Twitter 的今日新闻。AI 领域极具影响力的前沿论文和开源项目分享者 AK 也对该项目给予了关注并进行了分享。

导读

在当今的 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 即可模拟

视频链接：https://mp.weixin.qq.com/s/dMAPeqDszlY0eDopwPAu0w

研究团队录制了一个案例:

任务看似简单：旅行前在目的地寻找一处安心、方便、实惠的民宿，需在预订网站输入时间、地点、人数，根据评分和数量筛选，并排序找出最优选项。这类任务虽不复杂，但小模型常在此类任务上栽跟头——不是不懂如何使用筛选功能，就是产生幻觉，输出虚构信息假装完成。

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

第二步，转写成 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 从能用走向好用的关键一步。