最近做 AI 编程的人，应该已经明显感觉到一个变化：
AI Coding 正在从“帮你写代码”，走向“帮你完成工程任务”。
以前打开 Claude Code、Codex，我们最常说的是：
帮我写一个登录接口。
现在越来越多人开始直接说：
把这个需求实现了。
自己跑测试。
发现问题就修。
确认没问题以后告诉我改了什么。
开发侧已经开始发生变化。
测试侧其实也一样。
过去两年，我们讨论 AI 测试，最常见的还是：
AI 生成测试用例。
AI 生成 Selenium / Playwright 脚本。
但最近我在 Anthropic 官方 Skills 仓库里看到一个很值得测试工程师研究的 Skill：
webapp-testing
它使用 Playwright 和本地 Web 应用交互，可以做前端功能验证、UI 行为调试、浏览器截图和 Console 日志分析。
表面上看，这不就是 UI 自动化测试吗？
我把它的 SKILL.md 拆了一遍以后，发现真正值得看的其实不是 Playwright。
而是 Anthropic 在尝试回答一个更有意思的问题：
如果把 Web 测试交给一个 Agent，它到底应该怎么判断、怎么观察、怎么执行，又怎么证明自己真的测过？
这可能比“AI 能不能帮我写 Playwright”更值得测试开发关注。
目录
一、它不是 Playwright 教程，而是在给 Agent 一套测试决策
二、“先侦察、再执行”，可能是测试 Agent 最关键的一步
三、官方 Skill 也不是标准答案，networkidle 就值得商榷
四、Agent + Skill 和传统 UI 自动化到底是什么关系
五、真正值得测试开发抄的，是这套工程分层
六、未来的 AI 测试，不再以“脚本”为中心
一、它不是 Playwright 教程，而是在给 Agent 一套测试决策
先把 webapp-testing Skill 是什么说清楚。
从工程角度看：
Anthropic Web Testing Skill 是一套面向 Web 测试任务的 Agent 工作指令，它让 Claude 根据页面类型、服务状态和真实渲染结果决定如何使用 Playwright 完成测试。
它并没有发明新的自动化测试框架。
核心技术依然非常熟悉：
Python
+
Playwright
+
Chromium
真正不同的是：
Anthropic 并没有一上来教模型：
page.click()
page.fill()
page.locator()
而是先给了 Claude 一棵测试决策树。
官方 Skill 当前的核心逻辑大概是这样：
图片
这套 Decision Tree 就写在 Anthropic 官方 webapp-testing Skill 中。
注意这里发生的变化。
传统 UI 自动化通常是：
测试工程师
↓
理解页面
↓
找元素
↓
设计步骤
↓
写 Playwright
↓
机器执行
而 Skill 想把它逐渐变成：
测试工程师定义目标
↓
Agent 理解页面
↓
Agent 找元素
↓
Agent 决定操作
↓
Playwright 执行
↓
Agent 判断结果
也就是说：
人的职责开始从“把每一步写出来”，转向“告诉 Agent 我要验证什么”。
这个变化，比生成几行 Playwright 代码重要得多。
二、“先侦察、再执行”，可能是测试 Agent 最关键的一步
Anthropic 这个 Skill 里，我最喜欢的一个设计叫：
Reconnaissance-Then-Action
翻译成人话就是：
别着急点，先看看页面到底长什么样。
官方给动态 Web 应用设计的流程大致是：
打开页面
↓
等待页面进入可分析状态
↓
截图 / 检查 DOM
↓
根据真实页面识别 Selector
↓
再执行用户操作
看起来只是多了一步“观察”。
但对测试 Agent 来说非常关键。
因为大量 AI 自动化脚本失败，并不是模型不会写 Playwright。
真正的问题是：
模型在猜页面。
AI 写 UI 自动化，最危险的是“想当然”
例如我们让 AI 测试登录页面。
模型通过代码猜到页面大概有：
username
password
login button
于是直接生成：
page.fill("#username", "test")
page.fill("#password", "123456")
page.click("#login")
代码很好看。
运行以后发现：
真实页面是动态渲染的。
登录按钮文字叫“立即登录”。
用户名输入框没有 #username。
Modal 还没有加载出来。
或者点击登录以后还需要短信验证。
于是：
代码语法完全正确，测试却完全错了。
这正是“先侦察、再执行”的价值。
先让 Agent 看真实页面：
page.screenshot(path="/tmp/inspect.png", full_page=True)
content = page.content()
page.locator("button").all()
官方 Skill 就提供了类似的探索方式。
Agent 获得真实 DOM、截图和页面元素之后，再决定下一步。
整个过程实际上已经开始形成：
图片
这很接近一个最小的 Agent 行为闭环。
注意，我这里说的是“接近”。
Anthropic 这个 Skill 本身还不是一个复杂的自主测试 Agent。
但它的行为模式已经明显区别于传统：
Step1 → Step2 → Step3 → Step4
固定执行的自动化脚本。
传统自动化是在执行提前写好的答案，Agent Testing 开始尝试根据现场状态决定下一步。
这可能是未来 AI 测试一个非常重要的变化。
三、官方 Skill 也不是标准答案，networkidle 就值得商榷
这里有一个细节，我觉得测试开发一定要注意。
Anthropic 官方 Skill 对动态应用给了一个非常明确的提醒：
先执行：
page.wait_for_load_state("networkidle")
然后再检查 DOM。
甚至把这一点标成了：
CRITICAL
它背后的逻辑很好理解。
现在大量 Web 应用都是：
HTML Shell
↓
JavaScript
↓
API 请求
↓
数据返回
↓
React / Vue 渲染
↓
DOM 更新
页面刚打开时看到的 DOM，不一定是用户最终看到的 DOM。
所以必须考虑：
页面什么时候才真正可以测试？
这个问题完全正确。
但是具体采用 networkidle，我认为不能直接照抄。
因为 Playwright 官方文档目前对 networkidle 的态度非常明确：
DISCOURAGED。
Playwright 官方建议测试不要把“网络连接已经空闲 500ms”作为页面已经准备好的通用判断，而应该更多依靠 Web Assertion 或明确的业务状态。
为什么？
假设你的系统有：
WebSocket。
轮询。
埋点。
广告请求。
后台持续刷新。
页面可能长期存在网络活动。
反过来也可能出现：
网络已经安静了，但核心组件还没有进入真正可操作状态。
所以真正工程化以后，我更建议测试 Agent 等待的是：
登录按钮可操作
或者：
订单列表加载完成
或者：
Loading 消失
或者：
某个业务状态出现
而不是统一：
Network == Idle
这其实引出了一个很重要的测试思想：
页面“加载完成”是浏览器状态，而页面“可以测试”往往是业务状态。
未来如果我们自己设计 Web Testing Skill，这一层最好做成：
图片
而不是所有页面都套同一个等待策略。
这也是为什么我一直认为：
官方 Skill 值得研究，但不应该当成不可修改的标准答案。
测试工程师的专业价值就在这里。
四、元素定位也不能完全交给 Agent“随便找”
官方 Skill 提到，可以使用：
text
role
CSS
ID
等描述性 Selector。
但如果真正进入企业级自动化测试，我还会再收紧一层。
Playwright 官方一直建议优先使用更接近用户行为的 Locator，比如：
getByRole()
getByLabel()
getByText()
getByTestId()
尤其推荐优先使用 user-facing attributes 和明确的测试契约，而不是依赖脆弱的 DOM 结构、长 CSS 或 XPath。
例如：
不推荐：
page.locator(
"#app > div:nth-child(2) > div > button:nth-child(3)"
)
更合理的是：
page.get_by_role(
"button",
name="登录"
)
为什么这个细节对 Agent 特别重要？
因为如果完全让模型临场寻找 Selector：
它很可能优先选择：
现在能点的。
但测试开发需要考虑的是：
半年以后还能不能点。
这两个目标不一样。
所以真正成熟的测试 Skill，应该把 Locator Strategy 本身写进测试规则：
优先：Role / Label / TestId
其次：稳定业务属性
谨慎：CSS
避免：DOM 层级强绑定的 XPath
这就是“让 AI 写代码”和“让 AI 写可维护测试代码”的差别。
五、Agent + Skill 会替代传统 UI 自动化吗？
不会这么简单。
这是很多测试工程师看到 Web Testing Skill 后最容易问的问题。
从目前的工程成熟度看，我反而建议把两者定位清楚。
能力
传统 Playwright 自动化
Agent + Web Testing Skill
操作步骤
提前确定
可以动态决定
Selector
工程师维护
Agent 可以先观察再寻找
页面变化适应
较弱
理论上更强
可重复性
高
受模型决策影响
Determinism
高
相对较低
执行成本
低且可预测
模型调用成本更高
CI 大规模回归
成熟
目前仍需工程约束
探索性测试
一般
很有潜力
Bug 复现
依赖脚本
很适合 Agent
新需求冒烟
需要提前编码
很适合 Agent
所以如果现在公司每天晚上跑：
5000 条核心回归用例
我不会建议：
全部改成 Agent，让 AI 自己看着测。
因为企业回归测试非常看重：
稳定性。
确定性。
可重复。
成本。
历史结果可对比。
但如果换成另外几类场景：
刚开发完一个页面，需要快速冒烟
临时验证一个需求
复现一个线上 UI Bug
探索一个陌生系统
根据 PR 自动做页面验证
Agent Testing 的价值就会明显很多。
所以我更倾向于这样的判断：
Agent Testing 短期内最可能补充的是探索、验证和调试，而不是直接替换企业现有的大规模稳定回归体系。
六、真正值得测试开发抄的，是这套工程分层
Anthropic 这个 Skill 里面还有一个我认为非常好的设计：
它没有什么事情都让大模型做。
例如本地服务启动。
官方提供了：
scripts/with_server.py
这个辅助脚本负责 Server 生命周期，而且支持同时管理前端、后端多个服务。
例如：
python scripts/with_server.py \
--server "cd backend && python server.py" --port 3000 \
--server "cd frontend && npm run dev" --port 5173 \
-- python your_automation.py
这里体现了一个非常重要的 Agent 工程原则。
启动服务、等待端口、关闭进程，这些事情：
规则明确。
结果明确。
流程稳定。
没有必要每一次都让 LLM 重新思考。
所以：
确定性任务
↓
交给 Script
而：
页面怎么理解？
应该点击什么？
异常是否值得关注？
下一步应该做什么？
↓
交给 Agent
整个架构就开始清楚了：
图片
让模型负责“不确定的判断”，让代码负责“确定的执行”，是当前 Agent 工程非常值得坚持的一条边界。
七、还有一个容易被忽略的问题：Context 也要控制
官方 Skill 里有一句很有意思的要求。
对于辅助脚本：
先执行：
--help
不要一上来就读取全部源码。
为什么？
Anthropic 在 SKILL.md 里直接解释了：
辅助脚本可能比较大，如果直接读进上下文，会污染 Context Window，所以应该尽量把它们作为黑盒工具调用。
这个设计看起来和测试没关系。
实际上非常重要。
很多团队现在做 Agent 的方式是：
PRD 全塞进去
代码全塞进去
接口文档全塞进去
测试规范全塞进去
日志全塞进去
几十个 Skill 也全塞进去
最后 Context 非常长。
模型却未必更聪明。
真正成熟的 Agent 系统应该考虑：
哪些信息现在必须知道？
哪些资料需要时再读取？
哪些工具只需要知道输入输出？
哪些源码根本没必要进入 Context？
这就是现在越来越多人讨论的：
Context Engineering。
而 Anthropic 的 Skill 机制本身也强调按任务加载对应指令、脚本和资源，而不是把所有内容永久塞进模型上下文。
对于测试开发来说，这一点以后会越来越重要。
因为真实企业测试上下文本身就非常大：
需求。
代码。
接口。
数据库。
日志。
监控。
测试用例。
历史缺陷。
全部一次塞给 Agent，显然不是长久之计。
八、测试 Agent 最后必须解决的，是“证据”
Anthropic Web Testing Skill 还特别提到了两个能力：
Screenshot。
Browser Logs。
我认为这个方向比“AI 自动点按钮”重要得多。
因为以后测试 Agent 最大的信任问题一定是：
Agent：测试通过了。
然后测试工程师问：
你到底测了什么？
如果 Agent 只能回答：
我已经执行完成。
这个系统在企业里几乎没法真正托付。
所以一个真正可用的 Testing Agent，结果至少应该逐渐包含：
测试目标
+
执行路径
+
关键状态
+
断言
+
页面截图
+
Console
+
Network
+
错误上下文
也就是说：
测试 Agent 必须从“给结论”，走向“给结论 + 给证据”。
传统测试其实一直如此。
你提 Bug 不能只写：
页面错了。
你还需要：
复现步骤。
实际结果。
预期结果。
日志。
截图。
环境。
Agent 也一样。
AI 做测试最大的门槛，可能不是它会不会测，而是我们能不能验证它真的测过。
九、如果让测试团队自己做 Web Testing Skill，我会再加一层
Anthropic 当前这个 Skill 很适合作为示例。
但距离企业级 Web 测试，还有不少东西没有覆盖。
例如：
测试数据。
账号权限。
环境隔离。
接口 Mock。
失败重试。
Flaky Case。
Trace。
跨浏览器。
视觉回归。
历史结果对比。
CI/CD。
质量门禁。
所以如果让我给测试团队设计一套真正面向企业的 Testing Agent，我会更倾向于：
图片
这里面 Playwright 只是：
执行层。
真正困难的是上面的：
测试目标理解。
测试策略。
状态判断。
异常归因。
证据采集。
结果评测。
这才开始接近一套完整的：
AI Testing Agent。
十、Skill 写完以后，还应该“测试 Skill”
这一点可能是测试工程师最应该关注的。
Anthropic 最新公开的 skill-creator 已经不只是教你怎么写 SKILL.md。
它还明确增加了：
测试 Skill、建立 Eval、比较有 Skill 和没有 Skill 的结果、迭代 Skill 表现。
例如一个测试用例生成 Skill。
不能因为：
我跑了一个需求，生成得挺好的
就说它已经可以用了。
真正应该问的是：
换 50 个需求怎么样？
关键风险召回率怎么样？
会不会漏权限？
会不会漏并发？
不同模型结果差多少？
修改 SKILL.md 以后到底变好了还是变差了？
这件事和软件测试非常像。
没有自动化测试的代码，我们不会轻易说：
生产稳定。
同样：
没有 Eval 的 Skill，也只能叫“这次看起来不错”。
这反而可能是测试工程师进入 Agent 时代非常好的切入点。
因为模型越自主：
越需要验证。
Skill 越多：
越需要评测。
Agent 能做的事情越复杂：
越需要测试它到底有没有按照预期工作。
AI 测试下一步，可能不再以“脚本”为中心
过去几年 UI 自动化的核心资产是什么？
脚本。
Page Object
Test Case
Selector
Assertion
未来很可能还会存在。
但是 Agent + Skill 出现以后，测试系统可能逐渐增加另外一层资产：
测试目标
测试策略
Skill
工具
上下文
Eval
证据链
传统自动化是：
人理解系统
↓
人设计步骤
↓
机器执行
Agent Testing 想做的是：
人定义目标
↓
Agent 理解系统
↓
Agent 观察
↓
Agent 决策
↓
工具执行
↓
Agent 验证
真正变化的不是 Selenium 换成 Playwright。
甚至也不是 Playwright 前面多了一个 Claude。
变化的是：
测试系统里的“决策权”开始往 Agent 移动。
这对测试开发提出的要求反而更高。
以后我们需要理解的不只是：
UI 自动化。
接口自动化。
Python / Java。
还会越来越多地碰到：
Agent。
Skill。
Context Engineering。
Tool Use。
MCP。
Eval。
Observability。
Feedback Loop。
所以我觉得 Anthropic 这个 webapp-testing Skill 值得测试工程师研究。
不是因为它已经做出了一个多么完善的 AI 自动化测试平台。
恰恰相反。
它还很简单。
但它已经暴露出了一个很明显的方向：
AI 测试正在从“让模型帮我生成测试脚本”，开始走向“让 Agent 自己理解测试任务，并调用工具完成测试”。
如果这个方向继续发展下去，我们以后真正需要设计的，可能不再只是一套 UI 自动化框架。
而是一套：
能让 Agent 正确理解测试目标、可靠执行、留下证据并且可以被持续评测的测试系统。
那么问题来了：
如果现在把你们公司的 UI 自动化测试交给 Agent，你最不敢放给 AI 自己决定的那一步，会是什么？
