智能体从未真正被浏览器难住，真正阻碍它的是无休止的试探性操作 —— BrowserBC 将人类的浏览器行为轨迹精炼为可复用的“技能”，实现行为克隆（Behavior Cloning）：用户只需完整操作一次，智能体即可按图索骥完成同类任务。
项目发布仅 6 小时，BrowserBC 便在海外开源社区引发了超过 2500 条热烈讨论，并荣登 Twitter 的 Today News。AI 社区中最具影响力的前沿论文与开源项目分享者 AK 也关注并转发了该项目。
先聊聊几个核心判断。
如今的 Web Agent，在“执行操作”这一点上，基本已无太大争议。无论是 Claude 还是 Codex，这些模型都能顺畅理解页面布局、精准识别按钮和输入框，完成点击、输入、跳转与提交等一系列动作。真正制约它们的，是另一个深层问题：每当接手一个新任务或访问一个新网站，它们都不得不调用最强大、最昂贵的模型，从零开始将整个路径重新探索一遍。
而“从零探索”的过程，往往伴随着各种问题。比如，循环陷入死胡同，在几个页面之间反复跳转；或是渐渐偏离初始目标，越走越远；又或者是在搜索结果中来回切换，关键信息始终未能完整获取。还有一种情况：明明答案近在咫尺，智能体却提前收手，匆忙交出一份不尽人意的结果。
更棘手的是，即便这次侥幸成功，那么积累下来的操作经验也常常随着本轮对话一同散佚。下次遇到同类任务，换个 Agent，所有错误还得从头再犯一次。
因此，一个非常朴素的问题自然而然地浮现出来：能不能“操作一次，复用多次”？
说得更具体些 —— 能否先让人把任务完整、认真地做一遍，将这一趟操作中的“关键门道”打包提炼，然后交给一个更轻量、更经济的模型，让它依据这份经验就能完成同一类任务？
Einsia AI 旗下 Na vers Lab 推出的开源项目 BrowserBC，给出的答案非常直接：仅需三步 —— 录制、转写成技能（Skill）、交付执行。
录制，就是完整捕捉你在浏览器中执行任务的全过程 —— 包括任务指令、每一步的页面观察（既有渲染后的截图，也有结构化的 DOM 或可访问性树快照）、你的每一次操作（点击、输入、跳转、提交，并附带对应的元素定位信息）、页面给出的反馈（跳转、校验信息、报错提示与完成信号），以及任务最终落定的状态。
转写是关键环节：它并非简单地将这一系列操作保存为一段“回放脚本”，而是由模型将其提炼成一份自然语言技能 —— 一份类似说明书或“技能卡”的文档，清晰阐明这类任务该如何执行、如何判断操作正确。
执行，则是将这张技能卡交由任一模型去解读。模型据此在真实页面上自主完成操作，而非机械地复制某次具体的点击坐标。
说得直白些，BrowserBC 有点像智能体时代的“按键精灵”。传统的按键精灵会录制鼠标点击和键盘按键再回放 —— 但它记录的是写死的坐标和按键，页面一旦变化、布局稍有调整，整段脚本便立刻失效。而 BrowserBC 记录的并非坐标，它将这一系列操作转写成一份说明“该做什么、如何判定完成”的技能卡。这份技能卡能被其他模型理解，能在有所变化的页面中举一反三，还能被不断合并与复用 —— 它属于那种具备理解能力、能够迁移、甚至可以直接交给别人使用的“按键精灵”。
这也揭示了 BrowserBC 的核心逻辑：技能的来源与技能的执行者，可以完全分离。人在浏览器中完成一次任务，操作的轨迹被提炼成技能；之后，由另一个模型（哪怕更小、更廉价）依据该技能完成同类任务。技能一旦被转写成自然语言，就能在不同模型之间自由传递、复用和组合。
这，正是通往“通用网页浏览”的关键一步：将人类日常的浏览器行为精炼后，交付给智能体去执行。
BrowserBC 将人类的浏览器操作轨迹蒸馏为可复用的自然语言技能，为智能体在访问陌生网站时提供了宝贵的“决策先验”。
人类录制一次，智能体便可模仿
研究团队录制了一个具体案例：任务非常常见 —— 旅行前，希望为目的地找到一处安心、便捷又实惠的民宿。需要在预订网站上输入时间、地点、入住人数，并依照评分与评分数量进行筛选排序，最终找出最优选项。这类任务看似简单，但小模型常常在此栽跟头 —— 它们并非不理解任务，而是要么不清楚如何使用筛选功能，要么直接产生幻觉，输出虚假信息来假装完成任务。
第一步，录制。研究团队先让一位人类完整执行该流程：进入网站 → 输入时间、地点、人数 → 应用适当的筛选条件 → 阅读所有搜索结果 → 找到最佳选项。整个过程被原原本本地记录了下来。
第二步，转写成技能。系统将这段操作提炼成了一张技能卡，而非一段坐标回放。卡片上记录的是该类任务的通用方法论：意图 —— 在预订网站找到最佳住宿选项；关键步骤 —— 先填写基本信息，搜索后逐一应用筛选条件，而这正是小模型最不易理解或执行的部分；完成标准 —— 最终输出可供人工核验的结果；需要规避的陷阱 —— 网站最新的筛选条件可能与用户实际需求不一致，必要时需自行编写脚本进行筛选。
第三步，交付给小模型执行。这张技能卡被交给一个明显更小的模型，让它去完成另一次目的地的信息检索，执行同类任务。没有技能卡时，它要么跌跌撞撞、卡死或者耗时良久才勉强完成，要么直接产生幻觉。但拿到技能卡后，它立即明确需要输入什么信息、需要核查哪些界面、哪些地方可以依赖网站当前功能、哪些需要自行判断 —— 从而稳定地完成了任务。
就这样，BrowserBC 将“操作浏览器”这件每天都在发生的事，变成了智能体可以复用的技能。人类先趟通一次路，系统将其转写成说明书，由智能体负责按照说明书将同类路走顺畅。
而且，这条路径天然具备可复用、可扩展的特性。人类访问网站的分布遵循幂律分布：常见站点构成了人类访问的绝大多数，对这些站点而言，使用的人越多，技能库就会收敛得越完备。更关键的是，面对稀疏且长尾的分布，BrowserBC 让人们再也不必等待那些老旧网站主动提供 MCP 或最新的智能体接口。现实是，大量老网站永远不会专门为智能体开放一套干净的机器接口。而 BrowserBC 直接复用人类在“面向人类设计的界面”上积累下来的操作经验 —— 只要人类能用浏览器把它用起来，智能体就能借助蒸馏出的技能将其用起来。换句话说，一个网站能否被智能体高效访问，不再取决于网站方是否愿意配合、是否愿意升级，而取决于是否有用户已经在这个网站上走通过路径。这，正是“通用”二字的底气所在。
方法：如何将一次操作转写成可用的技能，并有效管理不断增长的技能库
BrowserBC 的方法部分，实际上只回答两个问题：一段操作该如何总结、总结时需要注意什么；以及总结出的成千上万个技能，该如何高效管理。
第一个问题：如何转写，以及需要特别注意什么？
原始的浏览器轨迹往往非常嘈杂 —— 其中包含误点击、无意义的等待、重复的尝试、临时的页面状态，甚至还可能夹杂隐私信息。因此，在转写之前，BrowserBC 会先进行数据清洗，并依据语义将轨迹切分为一段段连贯的子过程，而非按固定长度硬性切割。
每一段轨迹会先被抽取成一份“证据”：保留任务指令、该段操作前后的页面状态、用户采取的关键步骤、页面给出的反馈，以及成功或失败的信号。然后，将证据转写成结构化的自然语言技能卡，通过固定字段清晰说明“该做什么、如何判断进展、如何才算完成、失败了该怎么办”，以及它的来源和适用场景。这样的技能卡，既能直接喂给语言模型作为上下文，也方便人类进行审阅和修改。
这里有一个最需警惕的原则：只保留“可迁移的过程性知识”，剥离“会变、会泄露的细节”。
需要剥离的内容包括：精确坐标、DOM 选择器、临时 ID、登录状态、隐私文本，以及任何指向具体答案、针对评测检查器的内容。需要保留的，是在语义层面“该做什么、如何判断进展、如何算完成”。举个例子，一张“填写表单”的技能卡应该写明“根据语义标签找到对应字段、将任务给定的值原样填入、提交后确认页面出现成功状态”，而不是“点击 (x, y)、再点击那个 ID 是某串字符的按钮”。原因很简单：网页天天在变，布局、DOM、版本、登录状态都会变化，克隆坐标和选择器极其脆弱；而克隆“做什么 + 如何判断完成”才具备真正的迁移能力。
还有两点值得注意：其一，一条成功的轨迹就足以蒸馏出一个可用的技能 —— 它本身刻画了一种可行解的结构；而将同一任务的多次尝试（包括失败轨迹）放在一起，技能会变得更加稳健 —— 成功的轨迹强化执行步骤，失败的则能暴露缺失的前置条件，催生出显式的恢复策略。其二，转写时需要进行一次泄露检查：技能卡只应记录可复用的过程，不应将具体答案夹带进去。
第二个问题：技能如何管理？
如果每条轨迹都生成一个相互独立的技能，技能库很快就会失控：重复、冗余，甚至相互冲突。
BrowserBC 的做法是将技能库组织成一张技能图。每当产生一个候选技能，系统就会判断该将它新增为一个新节点、合并进已有技能，还是登记为某个更通用技能的特化。当两个技能在意图、前置条件、步骤、效果、终止证据上彼此相容时，就进行合并；当它们的适用条件不同、所需信息不同、或约束相互冲突时，就保持独立。
图中的节点是技能，边代表技能之间的关系 —— 时间依赖、特化、同一子目标下的替代方案、以及同一状态下的互斥关系。如此一来，一个通用过程（例如“填写表单”）可以连接到它的各种特化（如支付、修改资料）以及对应的失败恢复技能，而不必将它们压缩成一条扁平的条目。
这张图带来了三件事，也正是 BrowserBC 所说的可扩展性的真正含义：将重复的演示合并成可复用的节点，而非无限堆积样本；让检索和更新只影响相关的局部区域；支持增量精炼 —— 来一条新轨迹，只更新受影响的技能及其相邻节点。需要特别强调的是，这张图的价值在于“组织”：学习与复用的基本单元始终是那张自然语言技能卡，而图则负责将这些卡片有序地存放、检索和更新，这正是技能库能够持续扩张却不会失控的关键。
到了执行端，检索也刻意设计得十分轻量：按语义相似度（有额外信息时再叠加与当前页面上下文的兼容性）挑选出一小部分相关技能，塞入智能体的上下文，剩下的落地工作则交给智能体自己读取当前页面来完成。技能既不是可执行脚本，也不是需要照搬的演示，它只是将智能体引导到蒸馏出的行为模式上，而每一个具体动作仍然是对着当前页面实时选择的。
实验与讨论：技能带来跨基准、跨站点的一致提升
BrowserBC 首先在 WebArena-Hard 上接受了检验：258 个经人工核验的任务，覆盖 GitLab、电商及其后台、论坛、跨站点组合等六类自托管站点。实验严格控制了变量 —— 智能体、动作接口、步数与时间预算全部固定，唯一变量是是否注入 BrowserBC 检索到的技能。结果显示：基础智能体成功率为 60.5%（156/258），注入技能后提升至 81.4%（210/258），提升了 20.9 个百分点，成功挽回了基线原本失败的 54 个任务。
更强的检验来自 ClawBench：152 个任务运行在真实线上网站上，页面的布局与操作流程会在不同运行之间发生变化，且以写操作为主。这一设定彻底消除了“靠记忆取巧”的可能性 —— 任何编码精确坐标、DOM 选择器或缓存页面状态的技能，在这里只会越用越糟。结果是：无技能基线仅完成 50/152（32.9%），注入技能后完成 104/152（68.4%），提升了 35.5 个百分点，几乎将完成任务的数量翻了一番，并且在全部八个类别上都普遍适用。
事实上，技能不仅提升了成功率，还显著缩短了完成任务所需的交互次数。在 WebArena-Hard 任务上，智能体的平均工具调用次数从 31.2 次降至 22.7 次，下降了 27.3%。这与“技能作为流程性先验”的定位一致：它减少了试探性导航与反复的页面查看，而将底层的执行细节留给了智能体对实时页面状态的把握。
讨论一：技能是一份“带置信度的先验”，而非一条命令。
有一个细节相当说明问题：在 WebArena-Hard 上，如果强制智能体逐字照搬检索到的技能 —— 哪怕当前页面证据与之矛盾 —— 成功率只有 77.5%；而让它有选择性地使用、在技能与页面冲突时以页面为准，才达到 81.4%。更进一步，约 3.9%（10/258）的任务中，盲目照搬技能反而把本来能做对的任务搞砸了。这恰恰印证了那条核心判断：自然语言技能的价值在于“提示策略”，落地执行永远要交给模型去读取当前页面。
讨论二：技能是“蒸馏一次、便宜复用”的模型无关对象。
BrowserBC 的一个设计理念是：技能可以由一个强模型蒸馏一次，再交给另一个更便宜的智能体在执行时复用。研究团队在 WebArena-Hard 任务上，将“蒸馏技能的模型”与“执行技能的模型”进行了交叉组合，得出两点结论。其一，技能的质量主要在蒸馏阶段决定：Sonnet-4.6 蒸馏出的技能能够同时大幅提升两个执行器（+24 与 +20 个百分点），而 Qwen-3.7 蒸馏出的技能仅带来微弱增益。其二，高质量技能能够跨执行器迁移：装备了 Sonnet-4.6 技能的小智能体达到了 77%，逼近大智能体的 80%，直接坐实了“蒸馏一次、便宜复用”的设想。
讨论三：剩下的难题，难在“执行”而非“缺知识”。
对仍然失败的案例进行人工审计后发现，瓶颈大多落在执行精度，而非知识缺失：长表单遗漏了某个字段、目标对象存在歧义、长程任务将预算耗费在中间页面、或者模型自身推理过长而“跑偏”。这些情况下，技能本身是正确的，也用上了，限制因素是“按流程执行的保真度” —— 即底层模型的能力。这也划定了“小模型执行”的可行边界：技能能够补充“该怎么做”，但无法弥补“手稳不稳”。
讨论四：迁移到浏览器之外 —— OSWorld 案例研究。
论文还在 30 个 OSWorld 风格的 Ubuntu 桌面任务上做了一次诊断性的迁移研究 —— 需要说明的是，这并非将其当作一项完整的 OSWorld 刷榜，而是考察“方法的哪一部分能够迁移”。30 个任务中，有 17 个在配上匹配技能后得到了改善，说明过程性先验确实能够跨越浏览器的边界发挥作用。真正可以迁移的并非浏览器专属的动作序列，而是那份过程性先验 —— 前置条件、语义状态如何转移、进度里程碑、终止证据、失败如何恢复。在浏览器中，它体现在页面、链接、表单上；在桌面上，则体现在窗口、文件、对话框、持久设置上。剩下的案例则划出了方法的边界：少数任务本身足够简单，不需要技能；一部分卡在 GUI 控制本身（窗口焦点、模态弹窗、文件选择器状态），而非知识缺失；还有个别案例因为检索到错误匹配的技能而被“自信地带偏”。也就是说，当缺失的是“流程结构”时，技能最为有用；当缺失的是底层 GUI grounding、或检索喂错了先验时，技能不仅帮不上忙，甚至可能添乱。
BrowserBC 的意义不止是一个方法
BrowserBC 并非一个炫技的方法。它真正重要的地方在于，它指明了人类浏览器轨迹的价值：这是人类群体在浏览器迷宫中摸索出的高效操作路径。BrowserBC 所做的，正是将这些蕴含经验的轨迹精炼成智能体可用的技能。
核心启发在于以下几点：
第一，提升智能体的浏览器使用能力，关键在于为其补充完备的网页逻辑知识。第二，人类与虚拟世界的交互过程，本身就是一种尚未被充分利用的数据资源。第三，如果这些轨迹能够被持续精炼、管理和复用，那么智能体就可以从“能够操作网页”，逐渐走向“高效操作网页”。
因此，BrowserBC 的核心并非教智能体点击网页 —— 它是在信息不完备的环境中，用人类轨迹为智能体补上决策所需的先验。
从这个意义上说，真正决定 Web Agent 上限的，从来不是“是否能够复现某个浏览器操作流程”，也不是“是否快速拼装出一个看似可运行的系统”或是“Demo 出一个热门概念”，而是是否真正构建了可以持续积累、可复用、可迁移的经验结构。
这，或许就是让 Web Agent 从可用走向好用的临门一脚。