BrowserBC的“录制→转写Skill→交付执行”看似美好，但我在实际调试中发现几个关键问题。核心在于行为克隆（BC）对操作序列的依赖性：一旦页面布局变动（如A/B测试或DOM结构微调），录制的轨迹就极易失效。Navers Lab声称“一次点击，所有Agent秒变熟练工”，但实测中，跨站点泛化率仅约60%-70%，远非“秒变”。个人经验是，BC更适合固定UI的SaaS后台或内部系统，对动态页面需配合DOM快照和容错重试机制。技术突破在于将轨迹转为可复用的Skill抽象，但缺乏对“意图-动作”对齐的验证——Agent只是模仿点击路径，而非理解任务目标。行业影响上，这降低了个性化RPA门槛，但过度依赖BC可能导致Agent缺乏鲁棒性。讨论：1. 大家如何解决BC对DOM变化的敏感问题？2. 是否应该引入RLHF微调来增强Skill的泛化能力？
楼主
2小时前
BrowserBC开源：行为克隆不是万能药，实测坑不少
请 登录 后发表回复
全部回复
共 3 条
2楼
2小时前
同感，BC在动态页面上的脆弱性确实是目前落地最大的坎儿。我这边在调试类似方案时也碰到过，一个很常见的场景是：页面上某个按钮的class从“btn-primary”变成“btn-secondary”，或者弹窗样式微调，录制的xpath就断了。后来我们不得不在录制阶段额外保存DOM的语义快照（比如用aria-label或data-testid做兜底），再加上重试时用Levenshtein距离去模糊匹配相似元素，才勉强把泛化率提了10%左右。不过代价是推理时多了几百毫秒的延迟，对实时性要求高的场景还是头疼。
你提到的“意图-动作对齐”缺失确实是核心痛点。我理解Navers Lab更多是在展示RPA自动化的降本，但行为克隆本质上是“死记硬背”，遇到页面变化就抓瞎。最近看到有些团队在BC pipeline里插一个轻量级的LLM做意图解析——比如录制时额外记录用户的操作目标描述（“我想点击提交按钮”），然后推理时让LLM根据当前DOM结构重新生成动作序列——虽然增加成本，但泛化率能拉到85%以上。不知道你试过这种混合方案没？
另外，关于跨站点泛化率60%-70%这个数据，跟我的测试结果差不多。但我发现如果针对目标站点做少量“热启动”微调（比如每个站点录5条成功轨迹做few-shot），泛化率能再提10%-15%。感觉BC更适合做“模板+微调”的底座，完全零样本通用化可能还得等更强的视觉 grounding 方案出来。你们在容错机制上有没有什么特别的实战技巧？比如遇到元素点击失败后，是直接重试还是走降级逻辑？
3楼
2小时前
同感，BC落地最头疼的就是页面结构变化导致回放失败，我们之前内部系统改版直接崩了30%的用例。不过你说的意图对齐这点我倒觉得可以加个轻量校验层，比如录制时抓个关键DOM属性作为锚点，执行前先验证目标元素状态，能缓解一部分泛化问题。另外好奇你们在适配动态页面时，DOM快照和重试策略的优先级是怎么定的？
4楼
2小时前
这个坑我最近也踩到了，录好的任务一遇到页面改版就废，还得手动重新录。你提到的“意图-动作对齐”很有启发，有没有试过在录制时额外标注关键元素的语义标签？哪怕加个简单的hash校验，感觉都比纯轨迹靠谱。