浏览器自动化skill

你可能正卡在这一步：想让模型自己打开网页点几下、填个表、抓点数据，结果翻了一圈发现叫法五花八门，有的说是 skill，有的说是插件，有的干脆塞进 Agent 工具里，不知道从哪下手。这篇不解释原理，只给一套可执行的挑选顺序——先判断页面属于哪一档，再看登录态和验证码怎么处理，最后确认失败重试与日志留痕怎么做。看完你能自己列出一份候选项，而不是在词条里打转。

你可能正卡在这一步：想让模型自己打开网页点几下、填个表、抓点数据，结果翻了一圈发现叫法五花八门，有的说是 skill，有的说是插件，有的干脆塞进 Agent 工具里，不知道从哪下手。这篇不解释原理，只给一套能直接照着走的挑选顺序——先判断页面属于哪一档，再看登录态和验证码怎么处理，最后确认失败重试和日志留痕怎么做。看完你能自己列出一份候选项。

一个前提先说清楚：浏览器自动化不是越重越好。能用接口或现成的页面结构直接拿数据，就别开浏览器。开浏览器意味着你要额外承担会话管理、渲染等待、资源占用这几类问题，只有页面确实需要交互时才值得。判断标准放在下面第一档里。

先给页面分档，再谈挑组件

把目标页面按交互复杂度分三档，档位决定你选哪一类技能组件。别跳档，也别为了省事把简单页面往重方案上做，后面维护成本全落在你身上。拿不准某个技能属于哪一类，到 /skills 对照它的能力描述与依赖条件。

• 先问自己：不点任何按钮，能不能拿到目标数据？能就归一档
• 需要几步交互就能完成？三步以内视为二档，超过且页面结构易变，先考虑拆分任务
• 页面有没有验证码或风控跳转？有就先确认合规性，别把绕过当成默认能力
• 同一站点是否已有别人写好的接口封装？有就优先复用，别重复造

登录态、会话与凭据怎么管

登录态是浏览器自动化里最容易被低估的一块。多数失败不是点击点错了，而是跑到一半被踢回登录页，任务静默返回空数据，你还以为选择器写错了。常见做法是复用已登录的浏览器上下文，或把会话目录持久化下来，避免每次重新走登录流程。

1. 确认会话来源搞清楚登录态从哪来：手动登录后复用上下文，还是用凭据换 cookie。前者的稳定性通常更好，适合人工值守场景
2. 把凭据移出配置凭据不要明文写进技能配置，走环境变量或独立凭据存储，团队协作时尤其注意，配置文件一旦进仓库就收不回来了
3. 验证过期识别故意让会话过期跑一次，看组件能不能识别「被踢回登录页」并明确报错，静默返回空数据是最难查的坑
4. 确定多账号隔离粒度多账号轮换时先想清楚：共用一个浏览器实例，还是每个账号独立上下文。隔离太细资源吃紧，太粗会串号

验证码这里要单独说一句：遇到需要人工介入的页面，合理的做法是把任务挂起、截图、通知人处理，而不是默认组件能自己过掉。组件之间在这件事上的能力差异很大，选型时把它当成一个显式的检查项。

稳定性：等待策略、重试与降级

稳定性的第一原则是把「等」写对。固定延时等待是最不可靠的写法，页面快的时候白等，慢的时候照样失败。优先用元素可见、网络空闲这类条件等待，让组件自己判断时机。

第二原则是把重试分类。网络抖动、临时超时这类可以重试；元素不存在、页面结构变了，重试多少次都没用，只会浪费时间。给每个步骤设总超时，别让一次卡死拖垮整批任务，超时阈值可以参考 /api-timeout-tuning 的分档思路。

条件等待

等元素可见或网络空闲，而不是等固定秒数

可重试失败

网络抖动、临时超时、限流返回，适合退避重试

不可重试失败

元素找不到、页面结构变更、跳转到了预期外地址

降级路径

失败后截图加人工确认，或换用接口方式兜底，别让任务直接死掉

• 给整个任务设总超时，给单步设软超时，两级都要有
• 重试次数和退避间隔写进配置，别散落在代码里，方便后期统一调
• 失败时保留现场：截图、当前 URL、关键元素的 HTML 片段
• 批量任务里单条失败不要中断整批，标记出来最后统一看

留痕、评测与上线前检查

日志不是给自己看的仪式感，而是排查时唯一的依据。每一步至少记这几项：目标页面、选择器或动作、耗时、结果状态、失败时的页面快照。缺了快照，页面改版后你只能靠猜。

上线前准备一小批代表性页面做回归用例，页面改版后先跑这批用例，别直接在生产任务上试。日常盯三个指标：成功率、平均耗时、重试次数。指标掉下去往往早于用户反馈。

最后提醒资源这一项：浏览器方案的资源占用和并发要单独算，开太多实例会拖慢机器甚至互相干扰。上线前到 /tools/speed-test 量一下本机基线，再决定并发开多少。组件之间的可信度与历史表现，可以到 /sites 看当时的记录，别只看别人的一句评价。