1. 当UI自动化脚本开始自己写自己UI自动化测试这件事做过的人都懂——写脚本的时间往往比跑脚本的时间还长。页面改一个按钮的定位几十条用例集体飘红新来一个需求测试同学对着浏览器开发者工具翻半天就为了找一个稳定的选择器。更别提那些动态渲染、懒加载、iframe嵌套的页面写起来简直是在跟前端斗智斗勇。我最近在折腾一个挺有意思的方向让AI智能体自己来写Playwright的UI自动化脚本。核心思路是把Agent Skills智能体的技能编排能力和Playwright现代浏览器自动化框架结合起来让智能体能够理解页面结构、自主决策操作步骤、生成可执行的测试脚本甚至根据执行结果自我修正。这套东西解决的核心问题是把人找元素、人写断言、人调等待的重复劳动交给一个能看懂页面、会推理、能试错的智能体来完成。它适合有一定自动化测试基础、想探索AI辅助测试落地的同学也适合对Agent架构感兴趣、想找个真实场景练手的开发者。哪怕你之前没怎么接触过Playwright只要理解基本的Web操作逻辑跟着思路走也能搞明白。需要先说明的是这不是那种一键生成完美脚本的银弹。智能体写出来的脚本第一版大概率是能跑但有瑕疵的真正的价值在于它把最耗时的探索和初稿环节自动化了人只需要做审核和微调。这个定位想清楚了后面的期待就不会跑偏。2. 为什么是Playwright而不是别的自动化框架2.1 智能体需要什么样的自动化底座要让智能体自己写脚本底层的自动化框架必须满足几个硬条件。第一API要足够语义化智能体生成的代码得让人看得懂、改得动。第二等待机制要智能不能到处写死sleep否则智能体生成的脚本会又慢又脆。第三要有强大的选择器引擎和调试能力方便智能体在失败时定位问题。我对比过几个主流方案。Selenium生态成熟但API偏底层等待逻辑基本靠人肉封装智能体生成这种代码很容易踩坑。Cypress体验好但运行在浏览器内跨域和多标签页场景受限智能体处理复杂页面时容易卡住。Puppeteer偏底层适合做爬虫但测试断言体系弱。Playwright在这几个维度上比较均衡。它的auto-waiting机制是内置的——点击元素前自动等元素可交互填表单前自动等元素可见这直接省掉了智能体最容易写错的那部分逻辑。它的选择器引擎支持文本、角色、测试ID等多种定位方式智能体可以根据页面语义灵活选择。而且Playwright自带codegen和trace viewer前者能录制操作生成代码给智能体当参考后者能在失败时给出完整的执行快照这对智能体的自我修正环节特别有用。2.2 Agent Skills在这里扮演什么角色Agent Skills不是某个具体框架的名字而是一种能力编排的思路把智能体需要的能力拆成一个个可组合的技能单元每个技能负责一件明确的事智能体根据任务目标动态调用和串联这些技能。放到UI自动化这个场景里我把它拆成了这么几类技能页面感知技能抓取DOM结构、提取可交互元素、识别页面状态加载中/就绪/报错元素定位技能根据自然语言描述找到对应元素比如登录按钮搜索输入框操作执行技能点击、输入、滚动、等待、截图等原子操作断言生成技能根据操作意图推断应该验证什么生成合理的断言脚本组装技能把上述操作按正确顺序拼成可执行的Playwright脚本执行反馈技能运行脚本、捕获错误、分析失败原因、触发修正这套技能拆分的意义在于智能体不需要一次性生成完美脚本它可以先感知页面、再定位元素、再逐步操作每一步都有明确的输入输出出错时能精确定位是哪个环节的问题。这比让大模型直接看着页面截图写代码要可控得多。2.3 一个关键的设计取舍生成代码还是生成操作序列这里有个容易走偏的地方。很多人第一反应是让智能体直接输出Playwright的Python或JavaScript代码。我试过效果不稳定——大模型生成的代码经常有语法小错、API用错、等待逻辑缺失调试成本很高。后来我换了个思路让智能体生成结构化的操作序列JSON格式再由一个固定的代码生成器把它翻译成Playwright脚本。操作序列长这样{ steps: [ {action: goto, url: https://example.com/login}, {action: fill, target: 用户名输入框, value: testuser}, {action: fill, target: 密码输入框, value: password123}, {action: click, target: 登录按钮}, {action: assert_visible, target: 欢迎信息} ] }这样做的好处是智能体只需要关注做什么不用操心怎么写代码代码生成器是确定性的保证语法和API调用永远正确操作序列本身可读性极强人工审核和修改都很方便。这个取舍是我踩了几次坑之后才定下来的强烈建议一开始就这么设计。3. 页面感知技能的实现细节3.1 怎么把页面喂给智能体智能体要操作页面首先得看见页面。最直接的方式是截图但纯视觉方案对智能体来说信息密度太低而且坐标定位在不同分辨率下不稳定。我的做法是DOM结构提取 关键元素摘要双通道输入。DOM提取不是把整个HTML丢给智能体——那太长了token消耗爆炸且噪音极大。我写了一个提取脚本只保留可交互元素和关键文本节点输出一个精简的结构def extract_interactive_elements(page): elements page.evaluate(() { const selectors a, button, input, select, textarea, [rolebutton], [onclick]; const nodes document.querySelectorAll(selectors); return Array.from(nodes).map((el, idx) ({ idx: idx, tag: el.tagName.toLowerCase(), type: el.type || , text: (el.innerText || el.value || ).trim().slice(0, 50), placeholder: el.placeholder || , ariaLabel: el.getAttribute(aria-label) || , visible: el.offsetParent ! null, rect: el.getBoundingClientRect().toJSON() })).filter(e e.visible); }) return elements这个提取结果会连同页面标题、URL、可见文本摘要一起作为智能体的输入上下文。实测下来一个中等复杂度的页面提取后的信息量大概在2000-4000 token完全在可控范围内。3.2 元素定位的语义匹配策略智能体拿到元素列表后需要根据自然语言描述找到目标元素。比如用户说点击登录按钮智能体要在列表里找到最匹配的那个。我设计了一个多级匹配策略优先级从高到低优先级匹配方式适用场景示例1test-id精确匹配开发规范的项目>async def wait_and_locate(page, description, max_retries5, interval1000): for attempt in range(max_retries): elements await extract_interactive_elements(page) match semantic_match(elements, description) if match and match[confidence] 0.7: return match await page.wait_for_timeout(interval) return None对于明确的加载状态比如loading遮罩、骨架屏我还会让智能体识别这些状态并主动等待其消失。这个判断逻辑可以写成一个独立的技能智能体在感知阶段调用即可。4. 从操作序列到可执行脚本的翻译层4.1 代码生成器的结构设计前面提到智能体输出的是结构化操作序列翻译层负责把它变成Playwright脚本。这个翻译层的设计直接决定了最终脚本的质量。我的翻译层分成三个模块步骤解析器、定位器生成器、断言构造器。步骤解析器负责把每个action映射到对应的Playwright API。比如click映射到page.click()fill映射到page.fill()goto映射到page.goto()。这部分是纯映射逻辑简单但要求覆盖全面。定位器生成器是核心。它接收智能体给出的元素描述和感知阶段提取的元素信息生成Playwright的定位表达式。我优先使用Playwright推荐的定位方式def build_locator(element_info): if element_info.get(testId): return f[data-testid{element_info[testId]}] if element_info.get(ariaLabel): return f[aria-label{element_info[ariaLabel]}] if element_info.get(text): return ftext{element_info[text]} if element_info.get(placeholder): return f[placeholder{element_info[placeholder]}] return None断言构造器根据操作意图推断验证点。比如点击登录按钮后合理的断言是页面出现欢迎信息或URL跳转到首页。这部分我会让智能体在生成操作序列时就附带断言建议翻译层只负责把建议转成代码。4.2 生成的脚本长什么样经过翻译层处理最终产出的Playwright脚本大概是这样import asyncio from playwright.async_api import async_playwright async def test_login_flow(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) page await browser.new_page() await page.goto(https://example.com/login) await page.fill([placeholder请输入用户名], testuser) await page.fill([placeholder请输入密码], password123) await page.click(text登录) await page.wait_for_selector(text欢迎回来, timeout10000) assert await page.is_visible(text欢迎回来) await browser.close() asyncio.run(test_login_flow())这个脚本有几个特点等待逻辑是Playwright内置的自动等待不需要手写sleep定位器优先用语义化的文本和placeholder断言明确且可读。人工审核时一眼就能看出在做什么改起来也方便。4.3 脚本的可维护性优化智能体生成的脚本如果直接用维护性其实一般——定位器散落在各处页面一改就要满脚本找。我在翻译层加了一个优化把定位器抽成常量。LOCATORS { username_input: [placeholder请输入用户名], password_input: [placeholder请输入密码], login_button: text登录, welcome_text: text欢迎回来 } async def test_login_flow(): # ... await page.fill(LOCATORS[username_input], testuser) await page.fill(LOCATORS[password_input], password123) await page.click(LOCATORS[login_button]) # ...这样页面改版时只需要更新LOCATORS字典不用动测试逻辑。这个优化看起来小但在实际项目里能省大量维护时间。我建议在翻译层默认开启这个模式。5. 执行反馈与自我修正的闭环5.1 失败信息的结构化捕获脚本跑失败是常态关键是失败后智能体能不能自己修。要做到这一点失败信息必须是结构化的、智能体可理解的。Playwright的报错信息其实挺详细但直接丢给智能体还是太原始。我做了一层封装把失败信息整理成固定格式def capture_failure(error, page, step): return { failed_step: step, error_type: classify_error(error), error_message: str(error)[:500], page_url: page.url, page_title: page.title(), screenshot: capture_screenshot(page), available_elements: extract_interactive_elements(page) }classify_error会把错误归类比如元素未找到超时断言失败页面崩溃等。不同类别触发不同的修正策略。5.2 常见失败的修正策略我总结了智能体最常遇到的几类失败以及对应的修正思路元素未找到最常见。修正策略是重新感知页面用更宽松的匹配条件重新定位。如果还是找不到智能体会尝试滚动页面、切换iframe、等待更长时间。实在不行就标记为需要人工介入。超时通常是页面加载慢或元素渲染延迟。修正策略是增加超时时间、检查是否有loading状态未消失、确认网络请求是否正常。断言失败说明操作执行了但结果不符合预期。修正策略是重新检查断言条件是否合理有时候是断言写得太严格有时候是操作本身有问题。定位到多个元素Playwright的严格模式会报错。修正策略是让智能体根据上下文选择最合适的那个比如表单内的登录按钮而不是页面上所有叫登录的按钮。5.3 修正循环的终止条件自我修正不能无限循环否则一个修不好的问题会一直烧token。我设了几个终止条件同一类错误连续修正3次仍未解决停止并上报总修正次数超过5次停止并上报修正后脚本能跑通但断言结果与预期不符标记为疑似问题交人工判断这个终止机制很重要。我早期版本没设限制结果有个定位问题让智能体循环了二十多次token消耗直接起飞。加上限制后整体成本可控多了。6. 实际跑下来踩过的坑和应对6.1 智能体过度自信的问题智能体有个毛病定位元素时即使匹配度不高它也会给出一个结果而不是老实说我不确定。这导致脚本跑起来看着正常实际点错了元素。我的应对是在技能层强制要求返回置信度并且在翻译层加了一道校验置信度低于0.7的定位生成的脚本里会加注释标记运行时也会打印警告。人工审核时重点看这些标记能提前发现大部分隐患。6.2 动态ID和随机class的干扰有些前端框架会生成随机ID或带哈希的class比如idinput-a3f8b2。智能体如果按ID定位这次跑通了下次就失效。解决办法是在感知阶段就过滤掉这类不稳定属性。我写了个简单的启发式规则ID或class里包含连续数字、哈希样式字符串的降权处理优先用文本、placeholder、aria-label这些稳定属性定位。6.3 iframe和Shadow DOM的处理iframe和Shadow DOM是自动化测试的老大难。Playwright对iframe有frame_locator支持对Shadow DOM也有穿透能力但智能体不一定知道什么时候该用。我的做法是在感知阶段就检测页面结构如果发现iframe或Shadow DOM在上下文里明确标注出来并提示智能体使用对应的定位方式。这个提示很关键没有它智能体生成的脚本大概率会在这些地方卡住。6.4 断言写得太死或太松智能体生成断言时容易走两个极端要么写assert page.title() 精确标题这种一改就挂的要么写assert page.is_visible(body)这种等于没断言的。我调整了断言生成技能的提示词要求断言必须满足验证的是操作的核心结果、使用相对宽松的匹配如包含而非等于、避免依赖易变的内容如时间戳、随机数。调整后断言质量明显提升。7. 这套方案适合什么场景不适合什么场景7.1 适合的场景回归测试脚本的快速生成页面稳定、流程固定的回归用例智能体生成初稿的效率比人高很多人只需要审核和补充边界情况。探索性测试的辅助面对不熟悉的页面智能体可以先跑一遍主要流程把页面结构和可交互元素摸清楚给人提供参考。测试脚本的批量维护页面改版后让智能体重新感知页面、更新定位器比人工一个个改快得多。新手学习Playwright智能体生成的脚本结构清晰、注释完整拿来当学习材料挺合适。7.2 不适合的场景复杂的业务逻辑验证涉及多系统交互、数据一致性校验的场景智能体目前还搞不定需要人工设计测试策略。性能测试Playwright本身不是性能测试工具智能体生成的脚本也不适合做性能验证。安全测试涉及权限绕过、注入攻击等场景需要专业的安全测试工具和人工经验智能体帮不上忙。完全无人值守目前阶段智能体生成的脚本还是需要人工审核。完全放手让它自己跑自己修风险太大。7.3 成本与收益的平衡这套方案不是免费的。每次智能体感知页面、生成脚本、执行修正都要消耗token。一个中等复杂度的测试用例从生成到跑通大概需要3-5轮交互token成本在可接受范围内但量大之后还是要算账。我的建议是把智能体用在写初稿和批量维护这两个高价值环节人工聚焦在审核和复杂场景设计上。这样人机分工明确整体效率提升最明显。如果指望智能体全自动搞定一切投入产出比反而不好。8. 几个提升成功率的实操技巧8.1 给智能体提供页面上下文要克制一开始我恨不得把整个页面信息都塞给智能体结果它反而抓不住重点。后来我做了减法只给可交互元素、关键文本、页面标题和URL其他的一律不给。信息精简后智能体的定位准确率反而提升了。这个道理跟人一样——你给新人看整个代码库他懵你只给他看相关的那几个文件他很快就能上手。8.2 操作序列的粒度要适中操作序列拆得太细智能体要生成几十步容易在中途跑偏拆得太粗一步里包含太多操作出错时不好定位。我的经验是一个操作序列控制在5-15步每步对应一个明确的用户动作。超过15步的流程拆成多个子序列分别生成。8.3 善用Playwright的trace功能Playwright的trace viewer能记录脚本执行的完整过程包括每步的截图、DOM快照、网络请求。智能体修正失败时我把trace信息也作为输入给它它定位问题的准确率明显提高。这个功能强烈建议开启虽然会稍微拖慢执行速度但调试价值极高。8.4 建立定位器的稳定度评分我在项目里维护了一个定位器稳定度评分表记录每种定位方式在历史执行中的成功率。智能体生成定位器时会参考这个评分优先选择稳定的方式。比如同样是找登录按钮>