BrowserBC：人类轨迹蒸馏为可复用技能，让小模型获得大模型的网页操作能力¶

📊 Level ⭐⭐⭐ | 9.7KB

核心概述¶

BrowserBC 将人类在浏览器中的一次操作轨迹蒸馏为自然语言技能卡，让更小、更便宜的模型照着技能卡就能完成同类任务。核心洞察：录的不是坐标，而是"做什么 + 怎么判断完成"的可迁移过程性知识。装备 Sonnet-4.6 蒸馏技能的小 Agent 达到 77%，逼近大 Agent 的 80%。

→ 原文存档

问题：Web Agent 的"从零摸索"¶

当前 Web Agent 不缺操作能力（能点击、输入、跳转），缺的是每到陌生网站都要从零摸索。摸索容易陷入循环导航、路径漂移、提前收手。更关键的是：这次摸索的经验随着对话一起蒸发，下次同类任务还要重踩同样的坑。

方法：轨迹 → 技能卡 → 技能图¶

转写：从坐标到过程性知识¶

原始浏览器轨迹嘈杂（误点击、等待、重复尝试、隐私信息）。BrowserBC 按语义边界切成子过程，每段抽成"证据"（任务指令 + 页面状态 + 关键步骤 + 反馈 + 成败信号），再转写为结构化自然语言 Skill 卡。

关键设计：只保留可迁移的过程性知识，剥离会变/会泄露的细节。"按语义标签找到字段、填入值、提交后确认成功状态"，而不是"点 (x,y)、再点那个 id 是某串字符的按钮"。

技能图管理¶

库组织为技能图，每个候选技能判断：新增 / 合并 / 特化。节点是技能，边是关系（时间依赖、特化、替代、互斥）。效果：重复演示合并为可复用节点；检索和更新只动相关局部；增量精炼只更新受影响的技能及邻居。

检索：轻量语义匹配¶

按语义相似度匹配最相关的技能卡，作为 Agent 的决策先验注入上下文。

关键实验结论¶

核心启发¶

1. 提升 Agent Browser Using 能力的关键在于补齐完备的网页逻辑知识
2. 人类与虚拟世界的交互过程本身是尚未被充分利用的数据资源
3. 人类访问分布服从幂律——常见站点的技能库会自然收敛；长尾站点只需一次成功轨迹即可蒸出可用技能
4. 真正决定 Web Agent 上限的：是否构建了可持续积累、可复用、可迁移的经验结构

深度分析¶

转写的是过程性知识，不是坐标回放¶

这条路线真正的分界线在于"录什么"。像素坐标（点 (x,y)、点某个 id 为某串字符的按钮）是与视口尺寸、分辨率、页面布局、登录态绑定的执行快照——换个执行器、换次页面改版立刻失效；而"按语义标签找到字段 → 填入值 → 提交后确认成功状态"是任务层面的不变量，换成别的执行器也照样能照着它自行决定怎么点。技能卡同时对两个执行器产生 +24pp / +20pp 的增益，正是这一点的间接证据：若蒸馏产物只是坐标回放的压缩，更换执行器（observation / action 空间不同）就不可能同时受益。

因此交付的不是"动作序列"，而是决策先验：说清"这一步为什么这么做、做到什么程度算完"，具体动作由执行器现场生成——这正是"技能是提示策略而非硬编码"的含义。

技能图是增量精炼的载体，而不是技能列表¶

若把每次演示都追加成一张新卡，技能库会线性膨胀并迅速出现同义重复，检索信噪比持续下降。BrowserBC 把入库决策收敛为三选一——新增 / 合并 / 特化——再用四类边（时间依赖、特化、替代、互斥）把节点连成图，带来两个收益：一是局部性，检索与更新只触及相关子图及邻居，一次新演示不会污染全库；二是可演化性，重复演示被合并为更抽象的节点，相似但语境不同的技能被显式标注为特化或替代关系，库随时间变得更密而非更乱。

这与 SkillX 的层次化组织、程序图 PG 的工具/技能/记忆网络思路同向：经验只有被组织成带关系的结构，才能局部更新而不必整体重写；差别在于 BrowserBC 的图由人类演示这一单一输入源递推而来。

实测瓶颈在执行精度，不在知识缺失¶

最反直觉的一条结论是：失败案例与技能质量关系不大。长表单漏字段、目标元素歧义、探索预算耗尽、推理链跑飞——技能卡本身是对的，做砸的是执行环节。 这意味着知识蒸馏与 harness 工程是两条正交的改进轴：前者解决"知不知道该怎么做"，后者解决"能不能稳定做到"；技能库覆盖一个站点后，边际收益应从"多蒸一张卡"转向字段核对、终止判据与预算管理。

盲目照搬 77.5% 与选择性使用 81.4%¶

同样的技能卡，盲目照搬 77.5%，以当前页面为准按需选择性使用则升到 81.4%；约 3.9% 的任务因盲目照搬反而被做坏。 这个 3.9% 比 3.9pp 的差值更值得注意：技能卡携带可能过时的隐含前提，页面一旦与技能描述不符，越忠实地执行越错。对 harness 设计的含义是：注入技能不能只给"该怎么做"，还要给出元指令与失效条款——以实际页面观测为准、冲突时以页面为准、前提不成立时放弃该技能而不是硬套。

迁移边界：过程性先验不是浏览器专属¶

OSWorld 的 30 个 Ubuntu 桌面任务中有 17 个在配备技能后改善， 说明可迁移的是"如何探索陌生界面、如何确认完成"这类交互层先验，而非浏览器专属动作。边界由对站点内部知识的依赖度决定：越接近通用交互模式（搜索 → 筛选 → 填表 → 提交 → 验证）越可跨环境复用，越深绑特定后台或表单流越难迁移。

再叠加人类访问分布的幂律特征：常见站点的技能库会自然收敛、边际收益递减，真正需要投入的只剩长尾站点，而长尾站点只需一次成功轨迹就能蒸出可用技能。 这同时决定了技能库的建设顺序——先做 head，长尾按需单次补齐。

实践启示¶

1. 把高手的操作当资产归档，而不是一次性 demo。 一次成功的人类轨迹就能蒸出可复用技能卡，采集成本远低于重新设计奖励或标注数据集；缺的不是数据源，而是把交互过程沉淀下来的管线。

2. 技能卡写成任务级不变量。 "语义定位 + 完成判据"必须保留，坐标、DOM id、临时值、隐私内容必须剥离；用"换一个执行器还能照做吗"作自检标准。

3. 技能库按图组织，按"新增/合并/特化"入库。 先判定是新建还是并进旧节点，再用时间依赖/特化/替代/互斥四类边表达关系；更新只动局部，库不会越用越乱。

4. 注入方式是"先验 + 以页面为准"，并写清失效条款。 同时给出技能与放弃条件，才能拿到 81.4% 而不是 77.5%，并规避那 3.9% 被技能带坏的逆向案例。

5. 蒸馏不替代 harness 工程。 知识到位后瓶颈转向执行精度，预算应投向字段核对、长表单分段校验、终止判据与探索预算管理。

6. 建设顺序服从幂律分布，跨域复用要主动尝试。 优先覆盖 head 站点让库自然收敛，长尾用单次成功轨迹兜底；过程性先验不限于浏览器，同一套库值得在 GUI/桌面环境试跑。

关联¶

• Autobrowse：浏览器 Agent 的失忆问题 — 持久化探索 vs 人类轨迹蒸馏，互补方案
• Browser Use：为 Agent 构建 Runtime Harness — 浏览器 Agent 的运行时验证