Playwright 到 AI 智能体迁移(一):哪些模块该先动——评估矩阵
不是所有模块都值得迁移到 AI。三个评估维度:操作稳定性、结构变化频率、异常处理成本。用数据而不是直觉做决策。
亿牛云技术团队2026年5月6日3 分钟阅读
为什么需要评估矩阵
很多人听到"AI 浏览器智能体"后,第一反应是"把所有的 Playwright 脚本都换成 AI"。这个冲动可以理解,但实践下来是错误的。
在我们的经验中,全面替换通常导致两个极端:
- 脚本依然在维护——AI 版本完成后,脚本因为各种原因没有下线,两套系统并行维护
- AI 版本中途放弃——因为某些简单操作在 AI 方案中变得不可靠,又切回脚本,白花了迁移的功夫
更好的方式不是全面替换,而是渐进迁移。第一步是:哪些模块应该先动、哪些根本不该动。
三维度评估矩阵
每个自动化任务从三个维度打分:
维度一:操作稳定性(1-5 分)
这个维度的含义是:同样的脚本逻辑,每次执行的结果是否一致。
| 分数 | 含义 | 示例 |
|---|---|---|
| 5 | 100% 稳定,零变化 | 导航到固定 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 在同一个任务流中协作。
需要企业代理方案?
我们可根据目标站点、并发规模与稳定性目标提供定制方案。