最强模型告别重新学上网 开源项目实现人类点一遍Agent永久复用
试想一下，你的 Web Agent 是否曾陷入这样的困境：它能够识别按钮和输入框，能执行点击、输入、跳转、提交等基础操作——像 Claude、Codex 这类模型早已掌握了这些能力。然而，当面对一个全新的网站或任务时，它仍然不得不调用最昂贵的模型，从零开始重新摸索整个流程。 而探索过程往往充满坎坷。
试想一下，你的 Web Agent 是否曾陷入这样的困境：它能够识别按钮和输入框，能执行点击、输入、跳转、提交等基础操作——像 Claude、Codex 这类模型早已掌握了这些能力。然而，当面对一个全新的网站或任务时，它仍然不得不调用最昂贵的模型，从零开始重新摸索整个流程。
而探索过程往往充满坎坷。Agent 可能陷入无限循环，在两个页面之间来回徘徊；也会逐渐偏离原始任务目标；在搜索结果中反复切换，却无法提取关键信息；甚至即使已经接近正确答案，也可能提前放弃，草率收场。
即使偶尔成功了，这些经验却常常随对话结束而丢失。下一次任务，换成另一个 Agent，又得从头开始试错，重复相同的错误。
于是，一个简单而核心的问题随之浮现：能否实现一次执行、多次复用？
更具体地讲——能否让人类先完整地执行一次任务，将操作中的关键步骤打包封装，然后交付给一个更廉价、更轻量的模型，使其按照这些步骤完成同类任务？
Einsia AI 旗下的 Na vers Lab 推出的开源项目 BrowserBC，提供了一条简洁明了的三步范式：录制 → 转写为技能 → 交付执行。
录制：当用户通过浏览器执行任务时，系统会全程记录完整的操作轨迹——包括任务指令、每步的页面快照（含渲染截图及结构化的DOM/无障碍树快照）、用户的每一次交互（点击、输入、跳转、提交均携带对应的元素定位信息）、以及页面反馈（跳转、验证、报错、完成信号），最终任务结束时的状态也被一并保存。
转写：核心不在于将操作存储为一段可回放的脚本，而是借助模型将其转写为一份自然语言形式的技能——即一份类似说明书的“技能卡”，清晰描述这类任务应如何执行、以及如何判断操作是否正确完成。
执行：随后将该技能卡交付给任意语言模型进行解读。模型依据技能描述在真实网页上自主执行操作，而非机械地复现某次特定的点击坐标。
通俗而言，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
一次录制，Agent 就能照着做
BrowserBC 将杂乱的浏览轨迹进行清洗、蒸馏，转化为可复用的自然语言技能，并进一步构建成可扩展的技能图谱，最终通过检索相关技能，引导 Agent 完成新任务。
BrowserBC 的方法部分主要解答两个核心问题：如何对一段操作进行总结，以及在总结过程中需关注哪些要点；同时，针对总结出的海量技能，如何进行有效管理。
第一个问题：如何转写，以及需要特别注意哪些事项？
原始的浏览器轨迹通常十分嘈杂，包含误点击、无意义的等待、重复尝试、临时的页面状态，甚至可能夹杂隐私信息。因此，在转写之前，BrowserBC 会先进行数据清洗，并依据语义将轨迹切分为若干连贯的子过程，而非简单按固定长度硬性分割。
每个子过程首先被提取为一份“证据（evidence）”：保留任务指令、该段操作前后的页面状态、用户执行的关键步骤、页面提供的反馈，以及成功或失败信号。
随后，将证据转写为结构化的自然语言技能卡，通过固定字段清晰描述“应执行什么操作、如何判断进展、怎样才算完成、失败后如何处理”，并注明其来源与适用场景。这样的技能卡既可直接作为上下文输入语言模型，也便于人工审查和编辑。
这里有一条最需牢记的原则：只保留“可迁移的过程性知识”，剥离“可变、会泄露的细节”。
需剥离的内容：精确坐标、DOM 选择器、临时 ID、登录状态、隐私文本，以及任何指向具体答案或专门针对评测检查器的内容；
需保留的内容：语义层面上的“应该做什么、如何判断进展、怎样算完成”。
例如，一张“填写表单”技能卡应描述为“根据语义标签定位对应字段、将任务指定的值填入、提交后确认页面显示成功状态”，而非“点击坐标(x,y)，再点击ID为某字符串的按钮”。
原因显而易见：网页不断变化，布局、DOM结构、版本、登录状态都会改变，复制坐标和选择器极其不可靠；而复制“做什么+如何判断完成”才是真正可迁移的。
此外，有两点值得注意：
第一，单条成功轨迹便足以蒸馏出一个可用技能（其本身便刻画了一种可行解的结构）；而将同一任务的多次尝试（包括失败）综合起来，技能会更加稳健——成功执行强化了操作步骤，失败执行则暴露了缺失的前提条件，从而催生出明确的恢复策略。
第二，在转写过程中需进行泄露检查：技能卡仅应记录可复用的过程，不应附带具体答案。
第二个问题：如何管理技能？
若每条轨迹都生成相互独立的技能，技能库将迅速失控：出现重复、冗余，甚至互相冲突的情况。
BrowserBC 的解决方案是将技能库组织成一张技能图（skill graph）。每当生成一个候选技能时，系统便判断应将其新增（add）为一个新节点、合并（merge）到已有技能中，还是注册为某个更通用技能的特化（specialize）：
当两个技能在意图、前置条件、步骤、效果、终止证据上相互兼容时，则进行合并；
当适用条件不同、所需信息不同或约束互相冲突时，则保持分离。
图中的节点代表技能，边则表示技能之间的关系——包括时间依赖、特化、同一子目标下的替代方案、以及同一状态下的互斥。因此，一个通用过程（如“填写表单”）可以连接到其多种特化版本（如支付、修改资料）以及相应的失败恢复技能，无需将它们压缩为一条扁平的条目。
这张技能图实现了三件事，正是 BrowserBC 所强调的可扩展性的真正含义：将重复的演示合并为可复用的节点，而非无限制地堆砌样本；使检索与更新仅涉及相关的局部区域；支持增量式精炼——每新增一条轨迹，仅更新受影响的技能及其邻居。需要强调的是，这张图的价值在于“组织”：学习与复用的基本单元始终是那张自然语言技能卡，而图将这些卡片有序存放、检索和更新，正是技能库持续扩展而不会失控的关键。
在执行阶段，检索设计得十分轻量化：基于语义相似度（若有额外信息，则结合当前页面上下文的兼容性）选取一小部分相关技能，注入到 Agent 的上下文中，其余的实际操作则交由 Agent 自行读取当前页面来完成。技能既非可执行脚本，也不是需要照搬的演示，而是引导 Agent 向蒸馏出的行为模式趋近，而每一个具体动作仍然针对当前页面实时选取。
实验与讨论：技能带来跨基准、跨站点的一致提升
BrowserBC 首先在 WebArena-Hard 上进行了评估：258 个经人工验证的任务，涵盖 GitLab、电商及其后台、论坛、跨站点组合等六类自托管站点。实验严格控制了变量——Agent、动作接口、步数与时间预算均固定不变，唯一变量是否注入 BrowserBC 检索到的技能。结果显示：基础 Agent 的成功率为 60.5%（156/258），注入技能后提升至 81.4%（210/258），提升了 20.9 个百分点，成功挽回了基线原本失败的 54 个任务。
更具挑战性的测试来自 ClawBench：152 个任务运行在真实的在线网站上，页面布局与操作流程会随每次运行而变动，且以写操作为主。这种设定消除了“依赖记忆”的可能性——任何编码了精确坐标、DOM 选择器或缓存页面状态的技能，在此只会适得其反。结果表明：无技能的基线仅解决了 50/152（32.9%），注入技能后解决了 104/152（68.4%），提升了 35.5 个百分点，成功数几乎翻倍，且在所有八个类别中均表现一致。
BrowserBC 在 WebArena-Hard 与 ClawBench 上的性能表现。
事实上，技能不仅提升了成功率，还减少了完成任务所需的交互次数。在 WebArena-Hard 任务中，Agent 的平均工具调用次数从 31.2 降至 22.7（降低 27.3%）。这与“技能作为流程性先验”的定位一致：它减少了试探性导航和反复查看页面的行为，将底层的实时定位交还给执行时的当前页面状态。
讨论一：技能是一份“带置信度的先验”，而非一条命令。
一个细节很能说明问题：在 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 可用的技能。
核心启发在于：
第一，提升 Agent 的浏览器操作能力，关键在于为其补全完整的网页逻辑知识。
第二，人类与虚拟世界的交互过程本身，便是一种尚未被充分利用的数据资源。
第三，若这些轨迹能够被持续蒸馏、管理与复用，Agent 便可以从“能够操作网页”逐步迈向“高效操作网页”。
因此，BrowserBC 的核心并非教会 Agent 点击网页——而是在信息不完备的环境中，借助人类轨迹为 Agent 补充决策所需的先验知识。
从这个意义上说，真正决定 Web Agent 能力上限的，从来不是“能否复现某个浏览器操作流程”，也不是“能否快速搭建一个看似可运行的系统”或“演示一个热门概念”，而是是否真正构建了能够持续积累、可复用、可迁移的经验结构。
这或许正是推动 Web Agent 从“可用”迈向“好用”的临门一脚。