目录
一、很多人已经开始慌了：测试脚本还没写稳，AI就能自己修了
二、本质变化：从“人写脚本”变成“人定目标，AI执行闭环”
三、核心机制拆解：Agent怎么感知、推理、操作、修复
四、典型案例对比：一个登录框，暴露了两个时代
五、工程落地启示：你的角色不再是写代码的人
六、留给你的一个问题
一、很多人已经开始慌了：测试脚本还没写稳，AI就能自己修了
过去三个月，我至少被问了二十次同一个问题。
“你搞自动化的，有没有感觉到AI在逼近？”
不是问会不会被取代，而是问——已经开始疼了没有。
疼在哪？
以前写Playwright脚本，最耗时的不是断言，是定位器。今天这个按钮的id还是loginBtn，明天上线就变成了el-button-66。你还没跑完一轮回归，UI已经改了两次。维护成本高到团队里没人愿意碰老旧用例。
而今年，AI Agent这个概念从ChatGPT插件一路烧到了测试领域。
不是那种“帮你生成几行样板代码”的玩具。
是真正的：你说一句“测试登录失败场景”，Agent自己去打开页面、输入账号、点按钮、捕获错误、断言提示文案——并且，如果定位器失效，它会自己重新分析DOM，自己修。
很多人开始意识到：
我们过去引以为傲的“脚本编写能力”，可能不是未来的护城河。
二、本质变化：从“人写脚本”变成“人定目标，AI执行闭环”
这件事的本质，不是多了一个代码生成器。
核心在于反馈闭环的所有权发生了转移。
传统自动化测试的闭环是这样的：
人看需求 → 人写脚本 → 人运行 → 人看报错 → 人改定位器 → 人维护
每一个反馈节点，都要人介入。
而AI Agent模式下的闭环变成了：
人给目标 → Agent执行 → Agent发现定位失效 → Agent重新分析DOM → Agent生成新定位器 → Agent重试 → Agent断言结果 → Agent继续下一步
中间不需要人停下来。
什么叫“自己写、自己修、自己断言”？
自己写：根据自然语言指令，自动生成Playwright操作序列。
自己修：执行时报NoSuchElementError，Agent拿到页面快照，重新推理正确选择器。
自己断言：不靠硬编码预期文本，而是根据上下文语义判断是否符合目标。
这是三层能力的叠加。
能做到这一点的前提，不是某个大模型足够强，而是Playwright提供了足够可靠的底层控制能力 + Agent架构把“感知-决策-执行”串成了闭环。
三、核心机制拆解：Agent怎么感知、推理、操作、修复
直接给代码前，先讲清楚架构。
下图是这个Agent的核心工作流：
拆开讲三个关键机制。
机制一：感知层不是只看页面，而是看结构
Agent拿到的不是截图，是Playwright返回的DOM元素可交互性快照。
哪个元素可点击、哪个输入框当前focused、哪个button被disabled——这些信息比视觉更重要。
本质上，Agent在做的事情是：把页面的结构状态，压缩成一个大模型可以推理的中间表示。
机制二：修复不是瞎猜，是基于失败信息的定向重推理
传统脚本失败，你看到的是TimeoutError: waiting for selector "button:has-text("登录")"。
Agent看到的是：
定位器失败
当前页面里还有哪些文本接近“登录”的按钮
重新构建选择器，比如button >> text=Sign in或[data-testid=login]
验证新定位器是否唯一且可交互
这不叫“智能”。这叫把工程师的排错流程显式编码进了循环。
机制三：断言从“文本匹配”升级为“目标达成判断”
传统断言：expect(page.locator('.error')).toHaveText('密码错误')
AI断言：执行完操作后，问自己——“当前页面状态，是否符合用户原本说的‘登录失败’这个目标？”
实现方式不是让大模型读整个页面，而是提取关键语义节点：错误提示、URL变化、弹窗出现、输入框高亮等。把这些作为证据链，交给模型判断。
四、典型案例对比：一个登录框，暴露了两个时代
拿最常见的登录测试说事。
传统Playwright脚本写法
await page.goto('https://example.com/login')
await page.fill('#username', 'test')
await page.fill('#password', 'wrong')
await page.click('button:has-text("登录")')
await expect(page.locator('.error-message')).toHaveText('用户名或密码错误')
问题在哪？
一周后，开发把#username改成了input[name="user"]，把.error-message改成了.el-message--error。
脚本全崩。你花十五分钟定位，十分钟改完，还要提PR。
Agent驱动的方式
你只给一句指令：
测试登录失败场景：用test账号，错误密码，确认看到错误提示。
Agent内部自动完成：
Agent自动生成的第一版
page.goto("/login")
page.fill("#username", "test")
page.fill("#password", "wrong")
page.click("button:has-text('登录')")
断言失败：未找到.error-message
修复阶段
dom = page.content()
新定位器 = llm.推理(dom, "找一个显示错误信息的元素，可能是el-message、alert、或红色文本")
page.wait_for(新定位器)
assert "错误" in page.text_content(新定位器)
整个过程，你不用改一行代码。
即使UI变了，只要错误提示的语义没变，Agent就能自适应。
这就是两个时代的区别：
一个依赖选择器稳定性。一个依赖语义稳定性。
五、工程落地启示：你的角色不再是写代码的人
看到这里，如果你是一个中级工程师，最应该问的不是“这个Agent怎么写”，而是我的工作内容会变成什么。
给出三个判断。
判断一：定位器知识正在贬值
过去会写复杂XPath、会调CSS选择器，是一项硬技能。
未来，这项技能会变成Agent的基础能力，就像现在的排序算法不需要你手写快排一样。
你真正要掌握的，是如何描述目标、如何设计验证闭环、如何处理边缘情况。
判断二：自动化的瓶颈从“写脚本”变成了“定规则”
Agent很强，但它不知道什么场景该断言、什么错误可以忽略、什么操作顺序业务上不允许。
这些规则，需要你以“测试策略”的方式注入。
举个例子：
不是告诉Agent“点那个按钮”。
而是告诉它“在提交订单前，如果库存不足，应该停在当前页并显示提示”。
你从编写者，变成了设计者。
判断三：在校生和初级工程师，现在是最好的上车时机
因为老一代工程师的经验（各种定位器技巧、等待策略的细微差别）不再是壁垒。
新的壁垒是：你会不会使用Agent框架、会不会设计LLM的上下文、会不会评估模型输出的可靠性。
这些东西，学校和培训班还没教。
谁先摸清楚，谁就是下一批“资深”。
六、留给你的一个问题
看完这篇文章，我不问你学会没有。
我问一个更实际、更扎心的问题：
你现在的自动化测试体系，如果去掉所有硬编码选择器，改为让Agent在运行时动态推理定位——它能存活超过三个迭代版本吗？
如果答案是“不能”，那问题不在Agent，不在Playwright。
在你当前的测试设计里，有没有真正的反馈闭环。
