你可能已经有一堆端到端用例，维护到想吐，听说浏览器智能体能「像人一样点点点」就想换掉脚本。真接进去才发现：跑十次挂三次，报错说不清，定位器今天对了明天又偏，账单还悄悄涨。这篇不吹方案，只给一套判断标准和排查顺序，让你在动手前先量清楚自己的场景到底吃不吃这套，以及不合适时该退回什么。
你手上大概有一堆端到端用例，维护起来想吐，于是听说浏览器智能体能「像人一样点点点」，第一反应就是换掉脚本。真接进去才发现另一回事：跑十次挂三次，报错说不清，定位器今天对了明天又偏，账单还悄悄涨。
这篇不吹方案，只给一套判断标准和排查顺序。核心目的是让你在动手改代码之前，先量清楚自己的场景到底吃不吃这套，以及不合适时该退回什么。判断标准比工具选型重要得多，因为工具换起来快，用例迁移和团队习惯改起来慢。
先判断该不该用：三类场景分开看
别把浏览器智能体当成传统脚本的升级版，它更像是补在脚本写起来最痛的那些环节上。所以第一步不是选工具，而是把现在的用例按「页面结构敏感度」和「断言类型」分堆。分完之后你会看到三类场景，处理方式完全不同。
| 场景类型 | 典型特征 | 建议 |
|---|---|---|
| 适合 | 页面结构频繁改、断言偏语义（按钮含义对不对、流程通不通） | 可以试，但先挑一条最麻烦的老用例改写试跑 |
| 不适合 | 高频回归、需要毫秒级判定、断言全是精确数值比对、跑在 CI 里要求零抖动 | 别迁，传统脚本继续跑 |
| 灰区 | 既有稳定主流程又有探索性验证 | 按用例拆开，只迁探索那批，别整套一起动 |
判断动作就一个：挑一条最麻烦的老用例改写试跑，跑够一个迭代周期再决定要不要铺开。一周之内如果它在这条用例上稳定性和排查成本都没赢过原来的脚本，那铺开就是给自己找活。要注意这条判断有个不适用的情况：如果你的用例本来就跑得很少、失败也不痛，那省下来的维护量根本不足以抵消接入成本，这种情况直接跳过。
评测一套浏览器智能体，看哪几个维度
判断完该不该用，接下来是同类方案之间怎么比。这里容易踩的坑是只盯着「能不能跑通demo」，demo 跑通和长期可用是两码事。真正拉开差距的是下面这几个维度，建议按顺序看，前两个决定了你会不会被拖死。
- 定位方式：靠文本语义还是靠 DOM 结构，页面改版后哪种先崩，直接决定你的维护量
- 可重放性：同一用例多次运行结果是否一致，不一致时能否给出执行轨迹供复盘
- 失败可读性：报错是干巴巴的「元素没找到」，还是有截图和步骤日志，这决定排查是几分钟还是半小时
- 权限与数据：能不能限定域名白名单、能不能用测试账号跑，别让它带着真账号乱点
- 成本结构：按次、按步还是按 token，长链路用例最容易在这里失控
这几个维度里，可重放性最容易被忽略但也最要命。一个方案如果同一用例重跑结果飘忽、又不给你执行轨迹，那它跑挂的时候你连从哪查都不知道，这种方案哪怕前面几项都好看也不建议长期用。相反，定位方式偏保守、只做文本语义匹配的方案，初期覆盖率可能不高，但可控性强，适合当过渡。
接入前的准备清单
决定要接了，别急着写用例。下面这几件事如果不提前做，后面排查会变成一团乱麻，而且很多「看起来像模型不行」的问题其实是环境问题。按清单走一遍，能省掉大量来回。
- 环境隔离用专用测试库和测试账号，别和生产共用，避免它一冲动点了真实下单；验证方式是检查测试账号没有任何生产写权限。
- 基线先行到 /tools/speed-test 量一遍目标站点的响应基线。页面本身就慢的，别把锅甩给智能体，先把站点性能搞清楚。
- 用例分层把「必须稳」的核心流程和「允许模糊」的探索流程分成两批，先跑第二批。第一批等第二批跑稳了再动。
- 凭证管理Key 走服务端转发，别塞进前端。具体做法可参照浏览器直连那类文章的网关思路，这里不展开。
- 预算上限接之前先设单次运行的最大步数和超时，再配一个异常即停开关。没有上限的长链路用例是账单失控的主要来源。
这份清单里，凭证管理和预算上限是两条硬线。测试环境里塞生产 Key、或者不设步数上限就跑长流程，出事的时候都不是小问题。如果你的团队连测试账号都还没分出来，那说明接入时机还早，先把基础环境理清楚。
跑挂了怎么查：按这个顺序排
跑挂是常态，关键是别一上来就怀疑方案。用这个顺序排，大部分问题在前两步就能定位掉，省得在模型能力上钻牛角尖。顺序很重要，不能跳。
| 排查顺序 | 要看的点 | 对应动作 |
|---|---|---|
| 第一步 | 页面本身是否正常 | 接口超时、白屏、限流，用 /ai-status 之类监控对一下时间点 |
| 第二步 | 账号状态是否有效 | 登录态过期、验证码拦截、权限变更，这类最容易被误判成模型不行 |
| 第三步 | 执行轨迹从哪偏 | 是理解错指令还是点错位置，定位到具体步骤再谈优化 |
| 第四步 | 是否真是方案问题 | 同一用例重跑三次全挂且轨迹各不相同，才值得考虑换定位策略或换方案 |
第三步有个实用习惯：把执行轨迹和用例期望步骤并排看，找出第一个分叉点。分叉点在理解阶段，说明指令描述有歧义；分叉点在操作阶段，说明定位策略不适配当前页面。这两种问题的解法完全不同，混在一起改只会越改越乱。还有一种情况要注意：如果是站点本身在前端做了频繁的 A/B 实验，那定位漂移的锅未必在智能体，得先让前端那边把实验开关固定下来。
选型建议：按团队情况对号入座
最后落到选型。没有普遍最优的方案，只有和你团队现状匹配的方案。下面按几种常见情况给建议，你对照自己最接近的那条看。
- 小团队人手紧、用例少：优先挑接入成本低的，能跑通核心几条就够，别追求全覆盖
- 流程稳定、用例上百条：传统脚本仍然是主力，智能体只补那些脚本写起来最痛的环节
- 有合规或数据出境要求：先确认能不能私有化或至少限定网络出口，过不了这关的方案直接排除
- 正在做技术预研：可以并行小规模试两套，但别同时深度接入，观察成本会压垮你
不管落到哪条，都别一次性全量切换。留一段双跑期，新老并行跑同一批用例，对比通过率和排查耗时，用实际数据而不是直觉来决定长期押哪边。对照目录可以到 /stacks 看，价格和变动去 /price-watch 核对当时的数字，别信旧截图。
浏览器智能体不是脚本的替代品，是补在脚本最痛那几个环节上的备件；先量场景，再谈选型。下一步先别改代码，打开你现在的用例列表，按「结构敏感度」和「断言类型」分个堆，再挑一条最麻烦的做试跑。分完之后你自然知道该不该上、上哪种。→
常见问题
浏览器智能体能完全替代手写 E2E 脚本吗？
多数情况下不能，也更不该。稳定高频的回归用例，传统脚本执行快、结果确定、好排查，仍然更划算。浏览器智能体的价值在页面常改、断言偏语义、长链路探索这类脚本维护成本高的地方。更现实的做法是两者并存，按用例分派，而不是一刀切换。
为什么同样的用例跑几次结果不一样？
常见原因有三类：页面本身有动态加载或随机排序，模型的指令理解有波动，操作时序没做等待。先固定数据、固定视口、加显式等待，再重跑一轮。如果仍然每次都偏在不同的地方，说明这套方案的定位方式不适合这个页面，该考虑换策略或换方案。
怎么估算这套东西跑一轮要花多少钱？
它比纯脚本贵，因为每一步都要过一遍模型。粗算方式是：单条用例的步数乘以每步的 token 消耗，再乘以你要跑的用例数和频率。具体单价去 /tools/model-cost-calculator 按当时的价格算，别用记忆里的数字。跑之前先把单次运行的步数上限和超时设好，这是最有效的成本闸门。
