Automa Chrome插件v1.28.27：声明式Web UI自动化与CI集成实践

简介：Automa 是一款面向前端开发者、测试工程师及自动化需求用户的免费开源 Chrome 浏览器插件，通过无代码拖拽式工作流编排，轻松实现网页自动填写、数据抓取、截图、重复任务执行等 WebUI 自动化操作，显著降低浏览器自动化门槛。资源包为 v1.28.27 官方发布版完整源码压缩包（zip 格式），共含 69 个文件：44 个 JavaScript 文件构成核心逻辑与各模块功能（如 popup、contentScript、background、newtab 等）；6 个 CSS 文件负责多主题界面样式（含 light/dark/system 三套主题）；5 个 HTML 页面提供插件各入口视图；另有 SVG/PNG 图标、WOFF2 字体及本地化 JSON 资源（覆盖中、英、法、德、日、越、乌克兰等 10+ 语言），体现完整的国际化支持能力。包体仅 2.1MB，轻量易部署。目前已有 2622 人学习下载，读者可直接解压安装调试，获取可运行的生产级插件源码、模块化架构设计参考、多语言适配实践及 No-Code 工作流底层实现逻辑。

1. Automa Chrome 插件 v1.28.27：不是“录屏式宏”，而是可调试、可版本化、可嵌入 CI 的 WebUI 自动化黑匣子

你有没有试过用 Selenium 写完一个登录+填表+导出 PDF 的流程，结果上线三天后因为前端加了个 loading 动画就全链路卡死？或者用 RPA 工具点选元素，换了个浏览器缩放比例就找不到按钮？Automa 不是又一个“点哪录哪”的录制回放工具——它本质是一个运行在 Chrome 渲染进程内的声明式 UI 自动化引擎，用 JSON 节点图定义行为流，所有操作基于 DOM 状态而非像素坐标，天然抗 UI 微调。v1.28.27 是当前稳定分支中首个完整支持 Shadow DOM 深层穿透 + XPath 3.1 函数（如matches()、replace()）的版本，意味着你能直接对 Web Components 内部 input 做正则校验，而不用等document.querySelector('iframe').contentDocument加载完成再手动切上下文。适合三类人：需要把 UI 测试用例沉淀为 Git 可追踪配置的 QA 工程师；要批量处理 SaaS 后台重复任务（如客户信息同步、工单分类打标）的运营/客服同学；以及正在搭建低代码自动化中台、需要轻量级浏览器端执行器的后端开发者。它不替代 Puppeteer，但能让你少写 70% 的等待逻辑和重试胶水代码。

2. 安装与初始化：从 ZIP 解压到第一个可运行的「点击按钮」流程

Automa 不走 Chrome 应用商店，官方分发方式就是 ZIP 包直下——这既是优势（免审核、可离线部署），也是新手第一道门槛：解压后不能双击运行，必须通过 Chrome 的“加载已解压的扩展程序”入口注入。v1.28.27 的包结构已收敛为标准四件套：manifest.json（权限声明）、popup.html（右上角弹窗）、content.js（核心注入脚本）、workflow/目录（用户流程存档）。下面带你从零建一个最简工作流：自动点击某后台页面的「刷新数据」按钮。

2.1 解压与加载扩展：绕过“已损坏”警告的实操路径

Chrome 默认会拦截非商店来源的扩展，报错“无法加载此扩展程序”。这不是安全拦截，而是 Manifest V3 的签名验证机制触发的提示。解决方法不是关掉安全设置，而是走正确加载路径：

# 步骤1：解压到无中文、无空格路径（关键！） unzip automa-chrome-v1.28.27.zip -d /Users/yourname/automa-v1.28.27 # 步骤2：打开 Chrome 扩展管理页（地址栏粘贴） chrome://extensions/ # 步骤3：开启右上角「开发者模式」开关 # 步骤4：点击「加载已解压的扩展程序」→ 选择 /Users/yourname/automa-v1.28.27 目录

提示：若仍提示“清单文件缺失”或“权限不足”，请检查解压后根目录是否直接包含manifest.json。常见错误是 ZIP 包里套了一层文件夹（如automa-chrome-v1.28.27/manifest.json），此时需将内层文件夹内容整体拖到目标路径，而非整个文件夹。

2.2 创建第一个工作流：三步定义「找按钮 → 点击 → 等待变化」

Automa 的工作流编辑器是纯前端 SPA，所有逻辑在浏览器内存中运行，不上传任何数据。我们以某内部系统为例（URL:https://admin.example.com/dashboard），目标是点击 ID 为refresh-btn的按钮并等待表格重绘：

1. 访问目标页面：在 Chrome 中打开https://admin.example.com/dashboard

2. 唤出 Automa 面板：点击地址栏右侧 Automa 图标 → 弹出面板 → 点击「+ 新建工作流」

3. 添加节点：

   • 拖入Wait for element节点 → 设置 Selector 为#refresh-btn，Timeout 为5000ms
   • 拖入Click element节点 → Selector 填#refresh-btn，勾选「Wait for element before click」
   • 拖入Wait for element not present节点 → Selector 填.loading-spinner（假设加载中显示此 class）

4. 保存并运行：点击右上角「保存」→ 输入名称refresh-dashboard→ 点击「运行工作流」

此时 Automa 会按顺序执行：先等按钮出现（超时则报错）、再点击、最后等 loading 元素消失。整个过程不依赖time.sleep()，所有等待都是基于 DOM 状态变更的主动监听。

2.3 节点参数详解：为什么 Selector 不能只写button？

Automa 的 Selector 引擎底层调用document.querySelector()，但做了两层增强：

• 自动补全前缀：若输入#refresh-btn，实际执行document.querySelector('#refresh-btn')；若输入button[aria-label="Refresh"]，则原样透传
• Shadow DOM 穿透支持：v1.28.27 新增>>>语法，例如#host-element >>> .inner-button会递归查找 Shadow Root 内的匹配元素

但要注意：绝对不要用模糊选择器如button或div:nth-child(2)。原因有三：

1. 页面结构微调（如新增一个 button）会导致定位漂移；
2. Automa 的「等待」逻辑基于MutationObserver，若初始不存在该 selector，它不会轮询 DOM 树，而是直接失败；
3. 多实例页面（如 Tab 切换）中，button可能匹配到非目标区域的按钮。

✅ 推荐写法：优先用id>>// 在 Run JavaScript 节点中填写 document.querySelector('#submit-btn').dispatchEvent( new MouseEvent('click', {bubbles: true, cancelable: true}) );

注意：dispatchEvent必须在目标元素存在且可交互时调用，建议前置Wait for element节点。

4.2 现象：Get element text抓取到空字符串，但手动检查 DOM 显示正常

原因：目标元素是 Web Component（如<custom-input>），其文本内容在 Shadow DOM 内部，Get element text默认不穿透 Shadow Root。
解决：启用 Shadow DOM 穿透模式，在 Selector 中使用>>>语法：

• 错误写法：custom-input（只能获取 host 元素自身文本）
• 正确写法：custom-input >>> .display-text（进入 Shadow Root 查找）

4.3 现象：工作流在本地运行正常，部署到另一台机器后Wait for element频繁超时

原因：Chrome 的字体渲染差异导致getBoundingClientRect()返回坐标精度不同，Automa 的某些等待逻辑（如Wait for element to be visible）底层依赖此 API。v1.28.27 中该问题在 macOS 与 Windows 混合环境中尤为明显。
解决：禁用坐标依赖型等待，改用纯 DOM 状态判断：

• 替换Wait for element to be visible→Wait for element（仅检测存在）
• 替换Wait for element to be enabled→Wait for element attribute（监听disabled属性移除）

4.4 现象：HTTP request节点返回 401，但 Postman 测试同一接口正常

原因：Automa 的 HTTP 请求默认不携带 Cookie，即使你在 Chrome 中已登录目标站点。Manifest V3 限制了扩展对 Cookie 的默认访问权。
解决：在manifest.json中声明"cookies"权限，并在工作流中显式读取：

1. 编辑解压后的manifest.json，在"permissions"数组中添加"cookies"
2. 添加Get cookies节点 → Domain:example.com→ Output:cookie_jar
3. 在HTTP request节点的 Headers 中添加：Cookie: {{cookie_jar}}

4.5 现象：Run JavaScript节点中fetch()调用被 CORS 阻止

原因：Automa 注入的 content script 运行在页面上下文中，fetch受制于页面本身的 CORS 策略。
解决：改用 Automa 内置的HTTP request节点（它走扩展后台进程，不受 CORS 限制），或在Run JavaScript中调用chrome.runtime.sendMessage转发请求到 background script（需额外开发）。

5. CI/CD 集成：把 Automa 工作流变成 GitOps 可管理的自动化资产

Automa 的工作流本质是 JSON 文件，这意味着它天然适配 Git 版本控制、Code Review 和 CI 触发。v1.28.27 的workflow/目录结构已标准化，我们可以构建一条从代码提交到自动执行的闭环链路。这不是概念演示，而是我在某高校实验室部署的真实流水线：每天凌晨 3 点自动抓取教务系统课表更新，校验格式后推送到内部知识库。

5.1 工作流导出与版本化：JSON 文件即源码

Automa 编辑器右上角有「导出」按钮，生成的.json文件包含完整节点拓扑、参数、注释。关键字段说明：

• nodes: 节点数组，每个对象含id、type（如"click_element"）、parameters（具体配置）
• connections: 连接线数组，定义节点执行顺序，格式为{"from": "node_1", "to": "node_2"}
• metadata: 包含创建时间、作者（可为空）、描述（建议写清业务场景）

提示：导出的 JSON不包含敏感凭证（如 API Key、密码），所有密钥必须通过环境变量或外部注入。Automa 本身不提供密钥管理，这是刻意设计——安全边界由你的 CI 系统把控。

5.2 GitHub Actions 自动化：用 Chrome Headless 执行工作流

Automa 是 Chrome 扩展，必须在真实浏览器中运行。我们用browserless/chrome容器启动无头 Chrome，再通过 Puppeteer 加载 Automa 扩展并触发工作流：

# .github/workflows/automa-ci.yml name: Automa Workflow CI on: push: paths: - 'workflows/*.json' jobs: run-automa: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Launch Chrome with Automa run: | docker run -d --rm \ --name chrome-headless \ -p 3000:3000 \ -v $(pwd)/automa-v1.28.27:/extension \ browserless/chrome:latest - name: Execute workflow via Puppeteer run: | npm install puppeteer node << 'EOF' const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://localhost:3000' }); const page = await browser.newPage(); // 加载 Automa 扩展（需提前打包为 crx 或加载解压目录） await page.goto('chrome-extension://<EXTENSION_ID>/popup.html'); // 通过 Automa API 触发指定 workflow（需自行实现注入逻辑） await page.evaluate(() => { // 此处调用 Automa 的内部 API，如 window.automa.runWorkflow('refresh-dashboard') }); await browser.close(); })(); EOF

⚠️ 注意：上述脚本中的<EXTENSION_ID>需通过chrome://extensions/页面查看加载后的实际 ID（一串哈希值），每次重新加载扩展都会变化。生产环境建议用crx打包固化 ID，或改用chrome-extension://<ID>/background.js的通信方式。

5.3 工作流健康度监控：用日志断言替代人工巡检

Automa 的Log message节点输出会写入 Chrome 控制台，但 CI 环境中不可见。我们用HTTP request节点将关键日志推送到轻量级日志服务（如 Logtail）：

1. 在工作流末尾添加HTTP request节点
2. Method:POST
3. URL:https://in.logtail.com/your-source-key（Logtail 示例）
4. Body:{"level": "info", "message": "Dashboard refresh completed", "timestamp": "{{now}}"}
5. Headers:Content-Type: application/json

这样每次执行结果都会落库，配合 Logtail 的告警规则（如「过去 1 小时无成功日志」），就能实现无人值守的健康监控。

从那以后我每次新建工作流，都强制走一遍「导出 JSON → 提交 Git → 本地用 Puppeteer 模拟 CI 环境跑通」的三步验证。不是为了炫技，而是因为 UI 自动化的脆弱性藏在每一处 DOM 变更里——只有让工作流像代码一样被版本、被测试、被监控，它才真正脱离“玄学脚本”的范畴，成为可交付的工程资产。希望帮到你。

本文还有配套的精品资源，点击获取