Playwright 到 AI 智能体迁移(一):哪些模块该先动——评估矩阵

不是所有模块都值得迁移到 AI。三个评估维度:操作稳定性、结构变化频率、异常处理成本。用数据而不是直觉做决策。

亿牛云技术团队2026年5月6日3 分钟阅读

为什么需要评估矩阵

很多人听到"AI 浏览器智能体"后,第一反应是"把所有的 Playwright 脚本都换成 AI"。这个冲动可以理解,但实践下来是错误的。

在我们的经验中,全面替换通常导致两个极端:

  • 脚本依然在维护——AI 版本完成后,脚本因为各种原因没有下线,两套系统并行维护
  • AI 版本中途放弃——因为某些简单操作在 AI 方案中变得不可靠,又切回脚本,白花了迁移的功夫

更好的方式不是全面替换,而是渐进迁移。第一步是:哪些模块应该先动、哪些根本不该动。

三维度评估矩阵

每个自动化任务从三个维度打分:

维度一:操作稳定性(1-5 分)

这个维度的含义是:同样的脚本逻辑,每次执行的结果是否一致。

分数含义示例
5100% 稳定,零变化导航到固定 URL、读取固定选择器
4偶尔失败(<5%)登录页面有时有 CAPTCHA
3有时失败(5-20%)搜索结果排序偶尔变化
2经常失败(20-50%)表单字段内容随用户类型变化
1极不稳定页面结构每周改版

维度二:结构变化频率(1-5 分)

目标页面的 DOM 结构变化的频率。

分数含义示例
5几年不变内部管理系统的标准表单
4偶尔变主流 SaaS 产品的标准页面
3每几个月变电商网站改版
2每月变A/B 测试频繁的页面
1持续变化动态生成的内容页面

维度三:异常处理成本(1-5 分)

脚本失败时,人工介入的成本有多高。

分数含义示例
5零成本,自动重试即恢复读取页面标题失败
4低成本,重试几次即可超时后重试
3中成本,需要手动确认数据不一致
2高成本,需要人工介入表单提交失败
1极高成本,业务影响支付错误、数据丢失

综合评分

class MigrationScore:
    def __init__(self, name, stability, change_freq, exception_cost):
        self.name = name
        self.stability = stability       # 操作稳定性(1-5)
        self.change_freq = change_freq  # 结构变化频率(1-5)
        self.exception_cost = exception_cost  # 异常成本(1-5)
 
    def ai_suitability(self):
        """AI 适配度评分"""
        # 结构变化频繁 + 异常成本高 → 更适合 AI
        return (5 - self.stability) + (5 - self.change_freq) + self.exception_cost
 
    def recommendation(self):
        score = self.ai_suitability()
        if score >= 10:
            return "strong_ai"
        elif score >= 7:
            return "prefer_ai"
        elif score >= 4:
            return "hybrid"
        else:
            return "keep_script"

实际评估示例

任务 A:登录公司内部系统
  操作稳定性:5(几 乎零变化)
  结构变化频率:5(几年不变)
  异常处理成本:4(登录失败有自动重试)
  AI 适配度:(5-5)+(5-5)+4 = 4 → "keep_script"
 
任务 B:从电商产品页提取价格
  操作稳定性:3(偶尔失败)
  结构变化频率:3(每几个月改版)
  异常处理成本:3(数据不一致需要手动检查)
  AI 适配度:(5-3)+(5-3)+3 = 7 → "hybrid"
 
任务 C:处理供应商发来的各种格式的订单表
  操作稳定性:2(经常变化)
  结构变化频率:1(每个供应商格式不同)
  异常处理成本:2(填错单成本高)
  AI 适配度:(5-2)+(5-1)+2 = 9 → "prefer_ai"
 
任务 D:从没有标准 API 的政府网站抓取公告
  操作稳定性:1(经常改版)
  结构变化频率:1(改版频繁)
  异常处理成本:2(无法及时抓取影响业务)
  AI 适配度:(5-1)+(5-1)+2 = 10 → "strong_ai"

迁移路径概览

根据评估结果,三种迁移策略:

keep_script → 不做任何迁移。脚本用得好好的,不需要改。

hybrid → 脚本为主,AI 辅助处理异常。通过桥接层(D系列)实现自动切换。

prefer_ai / strong_ai → AI 为主,脚本作为性能优化。逐步将核心逻辑交给 AI。

总结

评估矩阵的核心思想:不是 AI 智能体适合所有场景,而是每个场景有它适合的自动化程度。

稳定性高、结构变化少、异常成本低的任务?继续用脚本。 稳定性低、结构变化多、异常成本高的任务?优先迁移到 AI。 中间状态的任务?混合模式,让脚本和 AI 在同一个任务流中协作。

需要企业代理方案?

我们可根据目标站点、并发规模与稳定性目标提供定制方案。