上个月我把 OpenClaw 接进了飞书让它每天早上九点自动跑一遍核心链路的 UI 自动化测试跑完把结果直接发到测试群里有问题就在飞书里 我确认。这个方案跑通之后我的手机终于不用再背着“测试没跑完不敢锁屏”的包袱了。这篇文章把完整思路、配置细节和踩坑过程拆开讲清楚给同样被 UI 自动化维护成本折磨的团队一个可以直接抄作业的参考。整个方案的核心就三件事OpenClaw 负责当 AI 代理的大脑把自然语言指令翻译成可执行动作飞书负责当人的入口不管是发指令、收报告还是人工确认都在聊天框里完成UI 自动化测试本身还是用 Playwright 这类成熟框架来做不搞玄学。这套东西适合谁适合那些已经有 UI 自动化基础但觉得“脚本写出来没人跑、跑出来没人看、坏了没人改”的团队。也适合想尝试 AI Agent 驱动测试但不想一上来就推翻现有框架的人。你不需要自己训练模型不需要从零写编译器只需要把一个开源 Agent 框架部署起来然后把测试技能挂进去就行。1. 为什么是这个组合OpenClaw、飞书和 UI 自动化分别解决什么问题1.1 UI 自动化测试最痛的不是自动化本身很多团队一提到 UI 自动化第一反应是“脚本难写、元素难定位、用例难维护”。但我在实际项目里跑了两年多之后发现这些都不是最痛的。最痛的是三件事第一自动化用例跑完结果没人看测试报告躺在 CI 系统里跟项目经理和业务方之间存在一条巨大的信息断层第二环境一不稳定就跑出一堆假失败真出问题时反而被淹没在噪音里第三测试用例和业务需求之间的对应关系全靠文档维护时间一长就没人说得清楚。这三件事的本质是 UI 自动化缺一个“调度和翻译层”。脚本只负责执行但它不负责理解业务语境也不会在需要人决策的时候主动找人。传统做法是接一个测试管理平台再配一堆告警规则结果又引入了新的维护成本。所以我在想与其把规则写死在系统里不如让一个 AI Agent 来当中间层它既能理解飞书里的自然语言指令又能调用现有的 UI 自动化工具还能在拿不准的时候把人拉进来。1.2 OpenClaw 在这个方案里到底扮演什么角色OpenClaw 在这里不是替代 Playwright也不负责写测试脚本它是一个 Agent 运行时。你可以把它理解为“AI 大脑的操作系统”它负责连接大模型、挂载技能、管理对话上下文并且通过连接器把外部渠道比如飞书接进来。真正执行 UI 操作的是我们写好的测试 SkillOpenClaw 只负责判断“用户这句话应该触发哪个技能参数是什么结果应该回给谁”。这个分工非常重要。如果你让 AI 直接从零生成一整套 UI 测试框架结果大概率是能用但不敢用因为生成代码的稳定性和可维护性都不可控。但如果把执行层交给人来维护的成熟框架AI 只做意图识别、参数提取、结果分析和报告分发那么每一步出错都能被约束在可控范围内。实际用下来OpenClaw 最舒服的地方是它的 Skill 机制每个技能就是一个包含描述文件、脚本、资源的目录模型会根据描述文件决定何时调用哪个技能这种模式非常适合挂测试任务。1.3 为什么偏偏是飞书而不是再搞一个测试平台飞书在这个方案里的价值被严重低估了。很多人以为飞书只是收消息的但实际用它做交互层之后我发现有四个不可替代的优势。第一IM 本身就是最好的指令入口测试群里直接 机器人说“跑一遍登录回归”比打开 Jenkins 点参数再点构建顺畅得多。第二飞书多维表格可以作为用例库和结果仓库既能给 AI 读也能给人看还支持筛选和统计。第三飞书的卡片消息支持按钮交互这意味着可以让 AI 在遇到不确定结果时发起人工确认人在聊天框里点一下就行不用切系统。第四飞书开放平台的事件订阅支持长连接模式本地开发不用配公网回调这极大降低了部署门槛。如果你团队用的是钉钉或者企业微信思路是类似的但飞书在多维表格和机器人交互上确实更顺手。尤其是多维表格它等于白送了一个轻量级的测试管理数据库省掉了单独搭后端的成本。1.4 整体数据流一句话指令到一份测试报告整个链路我拆成七步虽然文字描述看起来长但实际配置完之后运行非常顺第一步用户在飞书群里 机器人发指令比如“跑一遍登录页核心链路”第二步OpenClaw 收到事件后基于历史对话和配置信息做意图理解第三步Agent 决定调用 TestRunner 技能并解析出 URL、模块、测试类型等参数第四步TestRunner 从飞书多维表格拉取对应模块的用例第五步Playwright 执行用例并把每一步的截图、DOM 快照、控制台日志、断言结果收集起来第六步技能脚本把结果整理成结构化 JSON调用飞书 API 发卡片消息并回写多维表格第七步如果出现疑似缺陷但 AI 置信度不高就在卡片上挂“请人工确认”按钮等人点击后再决定是否登记缺陷。组件分工可以用下面这张表来表示组件职责备注飞书客户端指令入口、报告展示、人工确认用户无感知就像聊天OpenClaw Agent意图识别、调用技能、组织回复大脑/调度层TestRunner Skill拉取用例、执行测试、生成结果自定义技能Playwright真实浏览器操作与断言执行层保证稳定性飞书多维表格用例存储、结果回写、统计报表轻量数据库这个架构的好处是每一层都可以替换。你不喜欢 Playwright可以换成 Selenium 或 Cypress不想用多维表格也可以换成 MySQL 或者 JSON 文件甚至 OpenClaw 本身也可以换掉只要你的 Agent 框架支持飞书连接器和自定义工具调用即可。2. 环境准备与关键配置OpenClaw、飞书开放平台、浏览器自动化三件套2.1 先列一份准备清单我在 Windows 笔记本和 Linux 服务器上都部署过这套方案两者的差异主要体现在浏览器运行环境上其余部分几乎一致。开始之前你至少需要准备这些一台能联网的机器建议至少 4G 内存否则跑浏览器的时候会紧张一个飞书企业自建应用的权限普通成员可能没有创建应用的权限这个需要找管理员开通Python 3.10 以上版本用于运行 Playwright 脚本Node.js 16 以上版本很多 Agent 管理工具和脚本都依赖它以及一个可用的大模型 API Key作为 OpenClaw 的推理后端。至于部署方式是 Docker 还是裸机我建议前期用裸机因为调试起来少一层网络问题。2.2 OpenClaw 部署脚本安装与容器方式OpenClaw 的部署不算复杂但跨平台细节需要留意。Linux 或 macOS 下可以直接用官方仓库提供的安装脚本Windows 下推荐用 PowerShell 执行安装安装完成后会有命令行交互引导让你配置模型提供商和基础目录。这里有一个容易踩的坑安装脚本默认会拉取一些依赖和示例技能如果你的网络环境不太好可能会卡在依赖下载阶段这时候不要反复重装先检查镜像源和代理设置把下载源切到可用镜像再继续。容器方式部署也很常见适合团队统一环境。我用 Docker 部署时会把配置目录和技能目录都挂载到宿主机这样改技能不用重新构建镜像。基础镜像选择一个带 Chromium 依赖的镜像省得自己装一堆 so 库。不过容器方式在 Windows 下跑 Docker Desktop 时文件挂载和浏览器沙箱经常会出问题如果你只是本地实验我建议还是直接裸机跑别一上来就上 K8s。部署完成之后OpenClaw 一般会生成一个配置目录里面包含主配置文件、技能目录、会话状态等。主配置文件里最关键的是模型相关配置包括模型名称、API 地址、密钥。这里要特别提醒不要用“unknown model”这种占位词我之前在测试环境里把模型名写成了 deepseek 的缩写变体结果启动后 Agent 直接回复 “agent failed before reply: unknown model”。排查了半天最后发现是模型标识符写错了模型提供方识别不了这个名称。模型名一定要严格照抄 API 文档里的 model id不能自己发挥。2.3 飞书应用机器人创建与权限配置飞书这边的配置是整个链路里最像“企业级”的部分因为它有完整的管理后台和权限体系。第一步进入飞书开放平台后台创建企业自建应用名字随便起比如“AI 测试助手”。第二步在“添加应用能力”里启用机器人这样你的应用才能收发消息。第三步配置事件订阅这里要特别表扬飞书的是它支持长连接模式本地开发不用配公网地址在事件订阅页面选择“使用长连接接收事件”就可以了。第四步添加事件回调至少需要订阅“接收消息”事件如果是私聊机器人还需要开启“接收消息 im.message.receive_v1”。第五步配置权限范围常见的权限点包括读取用户发给机器人的消息、以机器人的身份发送消息、读写多维表格等。第六步创建版本并发布等待管理员审核通过。这里我遇到的第一个真实报错就是飞书错误代码 2700002当时机器人完全收不到消息排查了一圈发现是应用还没发布成功事件订阅自然不生效。也就是说在管理后台创建完应用不等于应用可用要完整走一遍“创建版本 - 提交发布 - 管理员审核通过”的流程机器人能力才会真正启用。如果你也遇到类似错误码第一反应应该是去检查应用是否已发布、机器人能力是否启用、权限范围是否包含 im:message 相关权限。权限这块的原则是“最小够用”不要图省事把所有权限都勾上尤其不要勾选与联系人隐私相关的敏感权限。多维表格权限建议单独创建一个多维表格专用凭据读写范围只指向你的测试用例表。这样即使密钥泄露影响面也被限制住了。2.4 浏览器自动化执行器Playwright 安装与无头模式UI 自动化执行层我选的是 Playwright而不是老牌的 Selenium。原因有三个一是自动等待机制做得更好写脚本时不用到处塞 sleep二是截屏、录屏、追踪文件这些能力原生支持对 AI 分析失败原因很有价值三是多浏览器支持Chromium、Firefox、WebKit 都可以用同一套 API 控制。安装过程不复杂先装 Python 包再下载浏览器内核pip install playwright然后执行playwright install chromium。如果你只需要 Chromium不用装全套浏览器能省不少时间和磁盘空间。无头模式是定时任务和 CI 环境下的标配但它有两个坑。第一个是 Linux 服务器上以 root 用户跑 Chromium 时会因为没有沙箱环境而报错常规做法是在 launch 参数里加--no-sandbox但请一定明确这只在受控的测试服务器上使用不要把这个参数带到生产环境或者面向不可信页面时使用。第二个是字体缺失无头环境下中文经常渲染成方块影响截图和视觉判断需要在系统里装中文字体包或者用 Playwright 的--font-render-hinting和加载本地字体目录的方式解决。另外我建议把 Playwright 改造成可被调用的服务模式而不是每次测试都重新起浏览器进程。使用 Playwright 的launch_persistent_context可以保持用户目录和浏览器上下文复用在多次任务之间这样执行速度能快不少。如果你未来想让 AI 驱动一个长期打开的浏览器页面这种持久化模式几乎是必须的。2.5 把 OpenClaw 和飞书接起来配置文件示例OpenClaw 的核心配置一般是 YAML 或 TOML 格式具体字段会随版本变化但核心概念是稳定的一个连接器负责飞书一个模型提供商负责推理一个技能注册表负责暴露可用能力。下面这个是一个简化版配置结构是我本地实验时用的app: name: ai-ui-test-assistant model: provider: your_provider model_id: your-model-id api_key_env: LLM_API_KEY channels: feishu: app_id: cli_xxxx app_secret_env: FEISHU_APP_SECRET event_mode: websocket receive_message: true skills: - test_runner - report_sender如果你在本地实验建议把密钥都放在环境变量里配置里只保留引用避免误提交到 Git 仓库。我踩过一次把 app_secret 写进配置文件并推到仓库的坑虽然仓库是私有的但还是紧急轮换了密钥自此以后所有密钥一律走环境变量或专门的密钥管理文件。3. 核心逻辑实现把测试能力封装成 AI 可调用的 Skill3.1 Skill 的目录结构设计OpenClaw 的 Skill 机制是整个 AI 驱动流程里最关键的一环。一个技能在本质上是一个包含描述文件和可执行代码的目录描述文件告诉大模型“这个技能是干什么的、什么时候该调用、参数是什么”。描述写得好不好直接决定 Agent 能不能在正确时机调用正确技能。我的 Skill 目录长这样skills/ test_runner/ skill.md run.py config.yaml requirements.txt report_sender/ skill.md send.pyskill.md里面写的是给模型看的说明包括技能的用途、参数 schema、使用示例和限制。比如 TestRunner 的描述会写明“当用户需要执行 UI 自动化测试或回归测试时调用此技能参数包括 target_url、browser、headless 等”。这段描述不是给人读的是给模型做工具选择的依据所以一定要写得足够明确避免和 ReportSender 产生歧义。3.2 测试用例库用多维表格来管传统 UI 自动化项目里用例通常写在代码仓库里要么用 pytest 函数要么用 Page Object 类。但在 AI 驱动的场景下我推荐把用例作为数据放在飞书多维表格里原因很简单产品经理能直接看到用例AI 能直接读取测试报告也能直接回写。多维表格的字段我建议这样设计用例 ID、模块、用例标题、优先级、前置条件、操作步骤、预期结果、执行状态、最近执行时间、最近失败截图、失败原因、维护人。从多维表格拉用例并不复杂OpenClaw 技能脚本里可以调用飞书开放 API读取多维表格记录然后按模块过滤。这样当产品说“这周改了登录页”时你只需要在表格里勾选登录模块的用例AI 就能自动执行对应范围。不需要改任何代码只需要改动表格数据这就是数据驱动用例管理带来的最大红利。3.3 AI 辅助元素定位与稳定兜底很多人期望 AI 能自动完成“看页面 - 写定位符 - 写断言”的全流程我建议不要这么激进。现阶段的可靠方案是“AI 辅助定位 规则兜底”。也就是说让 AI 在测试执行前根据业务描述生成候选元素定位策略但执行时仍然由 Playwright 按优先级去匹配匹配不到再自动降级。元素选择器的优先级顺序我实践下来是这样的自定义属性>