智能体浏览器：和普通浏览器、脚本的区别

用脚本做浏览器自动化的路子大家都熟：定位元素、写好路径、加异常处理，跑起来很稳，直到页面改版。改动落在关键节点上，整套脚本就得重写一遍，因为代码认的是具体的结构，而结构是最容易变的东西。

智能体浏览器（Agent Browser）换了个思路，让模型看着页面的内容决定下一步做什么。这也是它对改版不那么敏感的原因。

差别一：谁来决定下一步

传统脚本里，路径是人写的。第一步点哪里、第二步填什么、第三步等多久，全部提前定死，运行时只是照着执行。

智能体浏览器把决策交给模型。你描述的是目标，比如把某个来源的内容按条件整理成表格；至于要打开哪个页面、先点筛选还是先翻页、遇到弹窗怎么处理，是执行时现算的。

这一步的差别最容易被低估。它意味着脚本的维护成本从写代码转移到了写清楚需求——难度降了，但对目标的描述要求变高了。

差别二：怎么知道页面上有什么

脚本靠选择器认元素，XPath 和 CSS 选择器指向的是节点在结构里的位置。位置一变，选择器就失效。

智能体浏览器的做法是把页面的结构信息或者截图交给模型，由模型判断这是登录按钮、那是搜索框、这块是商品价格。它读的偏向语义，而不是坐标。

代价也很实在：为了让模型看懂一个页面，需要把 DOM 结构或截图送过去，页面越复杂送得越多。长任务跑下来，这部分开销不小，每一步还要等模型推理返回，整体速度明显慢于硬编码脚本。

差别三：动作怎么落地

判断完了还得真的点下去。这类工具通常把浏览器能力封装成一组可调用的动作：打开页面、点击、填表、登录、上传文件、滚动翻页、提取数据。模型输出的是调用哪个动作、带什么参数，浏览器负责执行，结果再回传给模型，形成下一轮的输入。

拆解和纠错也发生在这一层。一个目标被切成若干步按序执行，中途发现走岔了，模型可以换个入口重来，而不是直接报错停住。这一点在处理结构不规整的页面时很关键，完成率基本由它决定。

现在能跑到什么程度

确定性强、步骤明确的任务，它已经能跑通：按条件收集公开信息并整理成结构化数据；在自有系统里做重复的录入和按格式提交；盯着指定页面的变化，价格、库存、公告更新时提醒。这些场景的共同点是路径可预期，出错能重试，结果有人能核对。

还稳不住的地方

涉及语义理解的地方最容易出问题。给一个按钮判断该不该点，模型得先理解业务含义，页面结构复杂或者文案反常识的时候，误判就出现了：点错了入口、抓错了字段。层级越深的链路，误差越容易累积，前面偏一点，后面就找不回来。

强对抗的场景更难。验证码、风控拦截、登录态失效这些环节，能力基本取决于底层环境而不是模型本身，模型再聪明也没法把被拒绝的请求变成成功。云端托管执行、代理由服务方统一处理，这条路能覆盖一部分，但也会带来按量计费的成本和对第三方基础设施的依赖。

选型时值得看的几项

执行过程能不能查看、能不能回放，这件事常被忽略，但出问题时是唯一的定位手段。再看纠错方式，是中断报错还是换路径继续；看模型和成本是否可控，长任务的开销往往比预期高；看能否接入自定义工具和流程；最后确认登录态怎么保持，会话丢了要重跑是很烦的事。

用之前先想清楚规则

技术上能做的事，和有权限做的事不是一回事。目标平台的服务条款是否允许自动化访问，请求频率会不会给对方服务带来压力，这两条要先判断。另外，用这类工具批量注册账号、自动执行平台任务去换收益，属于违反平台规则的用法，各家对操作节奏、行为路径、环境一致性的识别能力都在提高，被处理时通常是一批账号一起。

如果任务本身是合规的，只是需要多个账号各自的登录态互不干扰，那就轮到环境隔离这一层发挥作用，比如 PurpleMark 提供的独立环境，让每个账号的会话和存储互不可见。

比较务实的验证方式，是挑一个自己熟悉的、步骤清楚的小任务，让工具完整跑一遍，把结果和人工做出来的对一遍，记下出错时它是怎么反应的，再算一下实际耗时。一个小任务能跑顺，再考虑往外扩；一上手就想着全流程自动化，多半卡在中间某一步。