Browser Agent 和 Computer Use 最近一年真正进展到哪了
过去一年，Browser Agent 和 Computer Use 几乎成了所有 agent 叙事里最能吸引注意力的一类展示。它天然适合做演示，因为“看见一个系统在网页上自己点、自己填、自己翻页、自己查资料”这件事，本身就比很多更底层的能力更容易让人直观地产生震撼感。问题也恰恰出在这里：它太容易被演示成功的瞬间定义，太不容易被长期运行的现实校正。于是围绕这条线的判断经常被拉向两个极端。一边会觉得浏览器智能体已经接近成熟，只差再做一些产品化收口；另一边则会因为试过几次不稳定流程，就把它整个归为华而不实的 demo 技术。真正接近现实的判断，通常都不在这两个极端里。
如果要先给一个简明结论，我会说：Browser Agent / Computer Use 最近一年确实有真实进步，但这些进步主要不在“它已经像人一样会自由操作所有网页”，而在“它开始更像一个可以被团队管理和约束的执行系统”。换句话说，这条线的变化不是从“不会动”跳到了“万能自动化”，而是从“演示层面能动”逐渐往“有限边界下可以被试点、可以被审查、可以被回放”的方向走。这种变化没有那么戏剧化，但它对 builder 团队反而更重要，因为团队最终用得上的，永远不是一次漂亮的 end-to-end demo，而是一条在真实流程中可以反复复用、出了错也知道怎么定位和接手的能力。
要理解这一轮变化，首先得把一个误区拆掉：浏览器智能体真正难的，从来不是“会不会点击”。今天大多数团队已经接受，一个模型结合浏览器工具后，做到点按钮、切标签页、填一段文本、抓一页内容，并不再是最稀缺的能力。真正难的地方在别处，在于任务是不是边界清楚、页面状态是不是稳定、步骤是否可以验证、失败后能不能停、停下后能不能被人接住。这些因素在演示视频里经常被折叠成一条流畅的过程，但在生产环境里，它们决定了 Browser Agent 到底是一项看起来惊艳的功能，还是一项能进入团队流程的能力。
所以我认为最近一年最实在的进步，首先体现在任务边界终于开始被讲清楚。早期不少 Browser Agent 相关的展示喜欢营造一种“网页就是一个通用执行界面”的感觉，仿佛只要系统足够聪明，它就能自然完成表单填写、后台维护、网页研究、跨页面资料采集、运营动作，甚至复杂的多系统跳转任务。但更成熟的团队现在开始更明确地区分这些类型，因为它们背后的稳定性假设完全不同。网页调研和资料采集是一类问题，表单流又是一类问题，后台运维、跨系统链路和涉及权限审批的任务则是另外一类问题。能够主动承认“不同任务需要不同边界”，看起来像没有以前那么激进，实际上恰恰说明这条技术线开始从神话回到工程。
第二个重要变化，是人工兜底不再被当成失败，而开始被当成设计的一部分。很多早期 agent 叙事里有一种潜在执念：最好完全自动化，尽量不要让人介入，好像一旦需要人接管，整个系统就失去了价值。真实生产场景恰好相反。对很多团队来说，真正有价值的不是系统能否在无人值守条件下端到端完成一切，而是它能不能把高重复、低歧义、机械性的那一大段工作稳定吞掉，同时在高风险、易出错或需要判断的节点把控制权交还给人。你会发现，随着这类思路变成熟，Browser Agent 的价值评价标准也变了。过去大家爱问“能不能完整自动化”，现在更成熟的问题是“能不能稳定吃掉 70% 到 90% 的机械步骤，并且在关键节点把人放在正确的位置上”。这不是降低标准，而是终于把“可交付”放到了“看起来全自动”前面。
第三个变化体现在权限和环境意识上。网页自动化真正容易出事故的地方，往往不是单次点击错了，而是系统被放进了一个权限过宽、状态不稳、上下文不清楚的环境里。它也许能完成一个动作，但代价是会话混乱、环境污染、副作用难撤销，最后你得到的不是自动化，而是一条很难审计的风险链。最近一年，Browser Agent / Computer Use 方向里最值得肯定的进步之一，就是越来越多系统开始认真处理沙箱环境、会话隔离、只读与读写边界、浏览器上下文管理和批准后执行这些问题。它们不一定都已经做得很好，但至少说明产品和框架层正在承认一件很关键的事：Computer Use 本质上不是更高级的点击器，而是一个会产生副作用的执行系统。只要承认了这一点，团队才能开始认真谈“能不能安全地引入到真实流程里”。
第四个真实进步是回放、排障和复盘意识明显增强。一个只能在成功时被展示、失败时却说不清原因的系统，很难在组织里长期存活。Browser Agent 最大的现实困难之一，就在于它天然生活在一个非常脆弱的表面世界里：UI 会改、弹窗会变、异步加载会漂、权限流程会插队、多步骤链路会不断出现新的条件分支。任何一处细小变化，都可能让流程看起来像“突然变笨了”。在这种环境里，真正重要的不是单次成功，而是有没有办法知道它为什么失败、失败在哪一步、哪些失败是可重试的、哪些失败必须交还给人。过去一年更靠谱的系统，开始越来越重视 trace、replay、screenshot / step log、task history 和 error point visibility。它们不性感，但对生产来说，比“会自动点网页”本身更有长期价值。因为团队最终要维护的不是一个视频，而是一条要不断复用的流程。
当然，承认这些进步，并不意味着要忽略它依然非常明显的局限。到今天为止，那些还明显停留在 demo 逻辑里的部分仍然很多。最典型的第一类，是跨站点、长链路、状态复杂的流程依然很脆。只要任务涉及多次登录、多系统切换、权限跳转、表单嵌套和条件分支，稳定性通常就会明显下降。这不是一个边缘问题，而是 Browser Agent 是否能扩大适用面的核心限制。第二类高频问题是页面变化和前端细节带来的脆弱性。一个按钮位置变了、一个 class 名改了、一个弹窗多出来、一个 loading 慢一点，都可能让原本流畅的链路瞬间崩掉。这意味着你不能把“今天跑通了”直接理解成“这条流程已经可以托管给系统长期维护”。
第三类还很现实的边界，是验证码、登录和企业权限体系。很多最关键、最值钱的流程，恰恰也是风控和权限最重的流程。它们不是完全不能辅助，而是很难适合作为全自动链路交出去。第四类则是所谓“高约束环境幻觉”。很多看起来很强的成功案例，其实都默认了页面结构相对规律、任务步骤提前整理过、干预成本可控、旁边有人随时盯执行过程、出错后可以立刻人工接管。这些条件不是假的，但它们会让系统看起来比真实生产环境更成熟。团队如果不把这层滤镜拆掉，就很容易高估当前能力，低估后续维护成本。
因此，Browser Agent 到底值不值得用，关键不在于“它是不是已经成熟”，而在于“它适合哪类流程”。我会把当前更值得认真评估的场景归纳为四类：网页研究与资料采集、有明确步骤的表单流、后台运营里的重复动作，以及那些可被审查、可被中断、可被人工接管的半自动流程。它们的共同特征是：任务边界比较清楚，成功标准比较明确，出错代价可控，人类兜底也合理。相反，那些高风险金融或合规动作、跨系统长链路自动化、完全无人值守的复杂网页操作，以及权限复杂又难审计的企业核心流程，今天仍然更适合保持谨慎。这不是说以后永远不能做，而是说当前阶段还不适合作为默认落地方向。
如果一个团队真的准备认真评估 Browser Agent / Computer Use，我其实不建议它从“最酷的 demo 任务”开始，而建议它从一条更像生产团队会走的顺序开始。第一步，先挑边界最清楚的任务，例如固定网页的数据采集、流程稳定的后台录入、成功标准清楚的表单步骤。这样更容易定义成功，也更容易做 replay 和回归检查。第二步，先把人工接管点设计出来，而不是默认追求无人值守。团队至少要先写清：哪些步骤允许系统自己做，哪些步骤必须停下来给人确认，失败到哪一步就直接交还给人。第三步，再要求最少可观测能力，至少要能看到每一步点了什么、页面状态怎么变、失败点在哪、哪些重试有效。做不到这一步，流程即使偶尔成功，也很难安全扩大使用范围。
在这个过程中，比“demo 当场顺不顺”更值得记录的，其实是一些更无聊但更重要的指标：同一任务 10 次里能稳定成功几次，失败是不是集中在固定步骤，人工接手后的恢复成本高不高，页面轻微改动后是否会立即大面积失效，每次维护这条流程到底要花多少时间。这些指标之所以重要，是因为团队真正关心的不是单次惊艳，而是可重复、可定位、可维护。试点前再进一步，我甚至建议把目标流程写成一张最小检查表：开始条件是什么，完成标志是什么，哪些步骤最容易变，哪一步失败必须人工接管，如果今天网页改版了第一优先级先查哪三个点。它听起来很朴素，但恰恰能把“我们觉得这个 demo 很强”改写成“我们知道它为什么能试、为什么会坏、坏了先查哪里”。
所以如果一定要用一句话概括 Browser Agent / Computer Use 最近一年的真实进展，我不会说“网页智能体快要像人一样自由操作网页了”，我会说：它开始更接近一种有边界、可回放、可人工接管的半自动工作流能力。这个判断比乐观口号冷一点，但对 builder 团队更有用。因为它既能防止团队被 demo 拉得过度乐观，也能防止大家因为它还不完美就整条线一起否定。真正值得做的，是找到那些高重复、低歧义、可接管、可审计、可以逐步扩大范围的网页任务，把 Browser Agent 放进这些地方。它最近一年的确是在往前走，只不过走向的不是“万能网页代理”，而是“在明确边界下越来越像系统的执行能力”。