关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集Playwright 1.56 发布时，大多数人把它当成一次常规更新——加了几个AI辅助功能，仅此而已。
但把 1.56 到 1.60 的发布轨迹连起来看，事情完全不一样了。2026年5月发布的 1.60，不是“测试框架加了AI功能”，是“浏览器自动化框架把自己重构成了Agent的操作层” 。
一个信号很明显：Playwright 1.60 的发布说明里，Test Agents（planner、generator、healer）从预览转为生产可用，MCP服务器进一步成熟，ARIA快照增加了bounding boxes——这些能力没有一个是“给测试工程师用的新API”，全部是“给Agent用的基础设施” 。
换句话说：Playwright 正在变成AI Agent操作浏览器的那一层“操作系统”
一、操作系统的四个必备层，Playwright 1.60 补齐了哪几层？
一个操作系统，至少要给上层应用提供四样东西：感知外部世界的能力、执行操作的能力、诊断问题的能力、以及预置的角色和工作流。
Playwright 1.60 在这四层上，每一层都有实质性推进。
第一层：感知层——Agent怎么“看见”页面
Agent操作浏览器的第一步，不是点击，是理解页面上有什么。
Playwright MCP 一直走的是ARIA快照路线：不截屏、不跑视觉模型，直接把可访问性树转成结构化文本，Agent读的是“这是一个textbox，名字叫用户名，ref是e5” 。这比截图省一个数量级的Token，而且定位是确定性的——ref指向的是具体元素，不是坐标猜测。
1.60 在感知层加了一个关键能力：ARIA快照可以携带bounding boxes。每个元素除了语义角色和名称，还附带它在页面上的坐标和尺寸[box=x,y,width,height] 。
这个改动看起来很小，但它解决了一个Agent特有的问题：Agent不仅需要知道“页面上有个按钮”，还需要知道“这个按钮在页面的什么位置” 。布局推理、遮挡判断、响应式适配，这些以前要靠截图加视觉模型才能做的判断，现在从ARIA快照里直接拿到了，零视觉推理开销 。
操作系统的第一件事，是让上层应用“看得见”。Playwright 1.60 把“看见”做成了结构化的、可推理的、Token友好的输入。
第二层：执行层——Agent怎么“动手”
看得见之后，要能动手。这一层 Playwright 1.60 的关键变化不是某个新API，是执行通道的分化和统一同时发生了。
分化体现在：Agent操作浏览器，现在有两条正式通道。MCP适合沙箱环境里的Agent、以及原生支持MCP的IDE集成；CLI + Skills适合有文件系统访问权限的编码Agent，把浏览器状态落盘而不是塞进模型上下文，Token效率高出数倍 。Microsoft同时维护两条通道，推荐按场景选，而不是二选一。
统一体现在browser.bind()。在 1.59 之前，Agent探索应用、测试运行器执行spec、MCP服务器处理临时查询，各自拉起一个浏览器实例，状态是分裂的——healer在一个session里修好了测试，runner在另一个session里跑还是红的。browser.bind()让三者挂到同一个浏览器实例上 。
这意味着什么？healer检查的是真正产生失败的那个浏览器状态，不是一次“复现尝试” 。Agent可以看着人类通过Screencast点完一个流程，然后在同一个session里接着操作。登录和状态准备只发生一次，不是三次 。
操作系统的第二件事，是给上层应用提供统一的、状态一致的执行环境。browser.bind() 就是这个环境的粘合剂。
第三层：诊断层——Agent怎么“知道自己做错了什么”
这是 1.60 最被低估的一层。
Agent驱动浏览器，最大的风险不是“点错了按钮”，是点错了之后不知道自己错了，或者人类不知道Agent为什么错了。一个Agent跑完几百个操作，失败了，如果没有一份机器可读、人类可审计的记录，这个Agent就是不可问责的。
Playwright 1.60 把 HAR网络捕获折叠进了 tracing 。一条trace现在同时包含：每一步动作、动作前后的快照、console输出、以及完整的网络请求和响应。
对于Agent来说，这条trace的价值是它从“人类调试工具”变成了“Agent的飞行记录仪” 。
- 调试：把trace喂回给Agent，比一句“它失败了”有用一万倍。
- 审查：人类可以精确回放healer改了什么、为什么改。
- 合规：“展示AI做了什么”有了字面意义上的答案。
同一时期，structured errorContext 让断言失败的信息对非人类读者也可读——Agent拿到的不再是一句笼统的报错，是结构化的失败上下文 。
操作系统的第三件事，是让上层应用的行为可追溯、可审计、可复盘。 没有这一层，Agent-driven testing在CI里跑得再多，也是不可信的。
第四层：角色层——Agent“该干什么”已经有人替你想好了
前三层是基础设施。第四层是出厂预置的角色。
Playwright Test Agents——planner、generator、healer——在 1.56 引入，1.60 转为生产可用 。
三个角色各司其职：planner探索运行中的应用，产出一份人类可读的Markdown测试计划；generator读取计划，生成可执行的spec文件，并且在生成过程中实时验证选择器和断言；healer跑失败的测试，检查运行时的UI，提出修复方案——通常是更新定位器或调整等待条件。
这三个角色不是三个孤立的工具，是一个闭环：plan → generate → run → heal 。
但它们被暴露为MCP定义，加载进Claude Code、VS Code agent模式、OpenCode这些AI编码工具里。工具驱动Agent，Playwright提供浏览器、计划格式和heal循环 。
操作系统的第四件事，是给上层应用提供标准化的运行时角色。 planner/generator/healer就是这个操作系统预装的“系统服务”——你不用从零编排Agent该做什么，Playwright已经把最常见的测试工作流封装成了角色。
二、“操作系统”这个定位，改了什么游戏规则？
把四层叠起来看，Playwright 1.60 做的事情就很清楚了。
它不再是“一个你写代码调用的测试框架” 。你手写spec、npx playwright test跑、看报告——这条路依然完全可用，Test Agents是可选的，你的现有套件不依赖它们 。
它正在变成“一个Agent可以直接站上去操作浏览器的运行时” 。Agent通过MCP或CLI接入，拿到结构化的感知输入（ARIA+boxes）、状态一致的执行环境（browser.bind()）、完整的审计记录（trace+HAR）、以及预置的工作流角色（planner/generator/healer）。
这个转变的实质，不是Playwright“变得更AI了”，是浏览器自动化的“接口层”从“人类工程师的API”变成了“Agent的操作系统调用” 。
以前，Agent要操作浏览器，得通过一个“翻译层”——让LLM生成Playwright代码，再执行代码。现在，Agent直接调用Playwright暴露的结构化工具，不需要生成中间代码。代码生成从“必需环节”变成了“可选环节” 。
三、但有一条边界，操作系统自己划得很清楚
Playwright在把能力交给Agent的同时，也把不该交给Agent的东西划了出来。
healer能修定位器、修等待条件，但不碰断言 。原因很直接：healer无法可靠地区分“应用改版了”和“应用坏了” 。一个因为改版而失败的测试应该被修；一个因为真Bug而失败的测试应该保持红色。这个判断需要知道产品应该做什么——那是人的判断，不是Agent的 。
被反复验证过的实践是：heals必须以“提案”的形式出现——一个PR里的diff，由人review，绝不自动合入。允许heal直接流进main分支的团队，几乎无一例外地发现自己的测试套件“礼貌地绕过了一个真Bug” 。
Planner可以提出覆盖方案，但覆盖判断是产品判断。Agent可以写出expect(page.getByRole('alert')).toBeVisible()，但只有理解需求的人才知道这个断言是不是对的 。
操作系统负责“能做”，不负责“该做”。 这条边界，Playwright划得比很多Agent工具都清醒。
四、避坑指南
坑一：以为Test Agents是必选项。 你的现有Playwright套件完全不需要Agent。planner/generator/healer是作者工具，不是运行时依赖。生成的spec就是普通spec，用npx playwright test照常跑 。
坑二：MCP和CLI二选一，而不是按场景选。 有文件系统访问的编码Agent，CLI + Skills的Token效率通常是MCP的数倍；沙箱环境、纯MCP集成的IDE，用MCP。两条通道Microsoft都在维护，选型看场景，不看立场 。
坑三：跑了Agent但不存trace。 没有trace的Agent-driven testing是不可审计的系统。1.60的trace已经包含HAR网络捕获，CI里跑Agent就必须归档trace 。
坑四：让healer自动合入修复。 这是最危险的用法。healer修的是“应用变了，测试没跟上”的那一类失败，它分不清“变了对不对”。heals进PR，人review，不自动merge。
坑五：把“Agent能操作浏览器”当成“Agent能替你决定测什么”。 感知、执行、诊断、角色——四层都是基础设施。测什么、什么算对、能不能发，仍然是人说了算。
最后
Playwright 1.60 不是一个“功能更多”的测试版本。它是Playwright把自己从“测试工具”重新定位成“Agent操作浏览器的操作系统”的那个版本。
感知层给了Agent结构化的“看见”，执行层给了Agent状态一致的“动手”，诊断层给了Agent可审计的“复盘”，角色层给了Agent预置的“工作流”。四层叠加，Agent不再需要“生成代码→执行代码”这条绕路，可以直接站在Playwright提供的运行时上操作浏览器。
但操作系统从来不替应用做业务决策。 测试该覆盖什么、断言该不该放宽、一个heal该不该合入——这些判断，依然留在人的手里。
Playwright 1.60 改变的，是执行层的所有权。它没有改变判断层的归属。
