简介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的按钮并等待表格重绘访问目标页面在 Chrome 中打开https://admin.example.com/dashboard唤出 Automa 面板点击地址栏右侧 Automa 图标 → 弹出面板 → 点击「 新建工作流」添加节点拖入Wait for element节点 → 设置 Selector 为#refresh-btnTimeout 为5000ms拖入Click element节点 → Selector 填#refresh-btn勾选「Wait for element before click」拖入Wait for element not present节点 → Selector 填.loading-spinner假设加载中显示此 class保存并运行点击右上角「保存」→ 输入名称refresh-dashboard→ 点击「运行工作流」此时 Automa 会按顺序执行先等按钮出现超时则报错、再点击、最后等 loading 元素消失。整个过程不依赖time.sleep()所有等待都是基于 DOM 状态变更的主动监听。2.3 节点参数详解为什么 Selector 不能只写buttonAutoma 的 Selector 引擎底层调用document.querySelector()但做了两层增强自动补全前缀若输入#refresh-btn实际执行document.querySelector(#refresh-btn)若输入button[aria-labelRefresh]则原样透传Shadow DOM 穿透支持v1.28.27 新增语法例如#host-element .inner-button会递归查找 Shadow Root 内的匹配元素但要注意绝对不要用模糊选择器如button或div:nth-child(2)。原因有三页面结构微调如新增一个 button会导致定位漂移Automa 的「等待」逻辑基于MutationObserver若初始不存在该 selector它不会轮询 DOM 树而是直接失败多实例页面如 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权限并在工作流中显式读取编辑解压后的manifest.json在permissions数组中添加cookies添加Get cookies节点 → Domain:example.com→ Output:cookie_jar在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/checkoutv4 - 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在工作流末尾添加HTTP request节点Method:POSTURL:https://in.logtail.com/your-source-keyLogtail 示例Body:{level: info, message: Dashboard refresh completed, timestamp: {{now}}}Headers:Content-Type: application/json这样每次执行结果都会落库配合 Logtail 的告警规则如「过去 1 小时无成功日志」就能实现无人值守的健康监控。从那以后我每次新建工作流都强制走一遍「导出 JSON → 提交 Git → 本地用 Puppeteer 模拟 CI 环境跑通」的三步验证。不是为了炫技而是因为 UI 自动化的脆弱性藏在每一处 DOM 变更里——只有让工作流像代码一样被版本、被测试、被监控它才真正脱离“玄学脚本”的范畴成为可交付的工程资产。希望帮到你。本文还有配套的精品资源点击获取
简介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的按钮并等待表格重绘访问目标页面在 Chrome 中打开https://admin.example.com/dashboard唤出 Automa 面板点击地址栏右侧 Automa 图标 → 弹出面板 → 点击「 新建工作流」添加节点拖入Wait for element节点 → 设置 Selector 为#refresh-btnTimeout 为5000ms拖入Click element节点 → Selector 填#refresh-btn勾选「Wait for element before click」拖入Wait for element not present节点 → Selector 填.loading-spinner假设加载中显示此 class保存并运行点击右上角「保存」→ 输入名称refresh-dashboard→ 点击「运行工作流」此时 Automa 会按顺序执行先等按钮出现超时则报错、再点击、最后等 loading 元素消失。整个过程不依赖time.sleep()所有等待都是基于 DOM 状态变更的主动监听。2.3 节点参数详解为什么 Selector 不能只写buttonAutoma 的 Selector 引擎底层调用document.querySelector()但做了两层增强自动补全前缀若输入#refresh-btn实际执行document.querySelector(#refresh-btn)若输入button[aria-labelRefresh]则原样透传Shadow DOM 穿透支持v1.28.27 新增语法例如#host-element .inner-button会递归查找 Shadow Root 内的匹配元素但要注意绝对不要用模糊选择器如button或div:nth-child(2)。原因有三页面结构微调如新增一个 button会导致定位漂移Automa 的「等待」逻辑基于MutationObserver若初始不存在该 selector它不会轮询 DOM 树而是直接失败多实例页面如 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权限并在工作流中显式读取编辑解压后的manifest.json在permissions数组中添加cookies添加Get cookies节点 → Domain:example.com→ Output:cookie_jar在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/checkoutv4 - 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在工作流末尾添加HTTP request节点Method:POSTURL:https://in.logtail.com/your-source-keyLogtail 示例Body:{level: info, message: Dashboard refresh completed, timestamp: {{now}}}Headers:Content-Type: application/json这样每次执行结果都会落库配合 Logtail 的告警规则如「过去 1 小时无成功日志」就能实现无人值守的健康监控。从那以后我每次新建工作流都强制走一遍「导出 JSON → 提交 Git → 本地用 Puppeteer 模拟 CI 环境跑通」的三步验证。不是为了炫技而是因为 UI 自动化的脆弱性藏在每一处 DOM 变更里——只有让工作流像代码一样被版本、被测试、被监控它才真正脱离“玄学脚本”的范畴成为可交付的工程资产。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
