Browser Use 放开观察方式，浏览器 Agent 不再只看一张元素清单
在 Browser Use 的架构复盘中，团队描述了一个变化：先让模型用代码执行操作，再让模型自己编写观察页面的代码，最终通过 CDP 获取所需信息，而不是始终接收系统预先整理好的元素清单。
作者：林岚｜OC 开发者生态编辑
在 Browser Use 的架构复盘中，团队描述了一个变化：先让模型用代码执行操作，再让模型自己编写观察页面的代码，最终通过 CDP 获取所需信息，而不是始终接收系统预先整理好的元素清单。
一句话结论：让 Agent 决定看哪里，可以减少观察盲区，但更强的浏览器控制能力仍需要独立的权限与结果验证。
按钮就在页面上，Agent 却可能完全看不见
浏览器自动化通常会把页面变成一份更短的表示：有哪些文字、哪些元素可以点击、输入框在哪里。这能节省上下文，但也意味着某些信息在模型看到之前就被过滤了。
Browser Use 举出的困境是，一个用户明明能看见的按钮，可能没有出现在交给模型的状态中。原因可以是页面结构特殊，也可以是提取规则遗漏。
此时继续强调“模型不够聪明”未必有用。它不能根据从未收到的信息选择正确操作，观察系统本身已经构成了能力上限。
从固定动作，走向按需编写程序
早期动作菜单容易理解：点击、输入、滚动。遇到签名绘制、批量操作等特殊需求，维护者却可能不断增加新动作。
让模型编写程序，意味着同一条执行通道可以表达更多组合。变量与中间结果得以保留后，模型也能检查前一步输出，而不是每次从头描述任务。
但程序化并不天然等于高效。模型也可能写出冗长脚本、重复查询或错误循环。减少工具数量，只是把部分复杂性转移到了运行时决策。
开放观察，比开放点击更进一步
通过 Chrome DevTools Protocol，模型可以根据问题选择截图、DOM 查询或特定框架检查。重点不是所有时候都收集更多信息，而是在缺少证据时改变观察方式。
这类似调试程序：堆栈、日志和变量值回答不同的问题，没有一种固定摘要适合每一种故障。浏览器 Agent 同样需要选择证据的能力。
不过，CDP 面向 Chrome 体系。文章描述的架构路径不能直接推出所有浏览器都拥有相同兼容性，也不能把更底层的访问能力当成所有站点都能稳定自动化。
节省 Token 的样本需要按原尺寸阅读
文中引用的一组对照只有六项任务、每项三次运行；两个模型在两种方案下都完成了相应运行，改动后平均 Token 使用减少。
这个结果支持“某些工作流能通过代码执行减少交互开销”，却不足以证明普遍成功率提高，更不能直接推算所有公司的浏览器成本下降多少。
长任务还包含重试、错误恢复和人工接管。一段短演示没有失败，不代表运行数小时后仍然能正确理解页面状态。这也是团队选择复用成熟 Agent 循环的背景。
能看见和被允许，是两件事
浏览器会话可能已经登录邮箱、业务后台或支付系统。观察能力扩大以后，执行边界更不能只靠“模型应该理解用户意思”。
工程上应分别处理读取页面、填写表单与提交外部变更。尤其是发消息、购买和删除，完成动作前后的状态需要可核查，而不是只留下模型的一句成功宣告。
Browser Use 的经验值得借鉴：不要让固定提取规则永久卡住模型。但好的抽象应该同时让失败可见、让权限明确。把工具变少不是终点，让系统更容易解释自己的行为才是。
关键事实
材料为团队架构复盘；变化包括代码化动作与按需观察；所引 Token 对照是小规模任务集；CDP 能力不等于跨浏览器通用保证。
OC 判断
浏览器 Agent 的重要进展可能发生在“给模型看什么”，而不只是换一个更强模型。
为什么重要
对开发者，观察盲区会直接造成无效重试；对用户，更灵活的自动化只有配合清楚的提交边界，才不会把方便变成失控。
评论
围绕这篇文章补充信息、提出问题或分享观察。