如果你还在手动写爬虫脚本抓取网页数据或者为每个自动化测试用例编写重复的浏览器操作代码那么是时候停下来看看这个新工具了。最近在开发者社区里一个名为Figranium的项目引起了我的注意。它打出的旗号是“可视化构建浏览器任务并通过 API 执行”听起来像是把无头浏览器如 Puppeteer、Playwright的脚本编写变成了像搭积木一样的拖拽操作。但别急着把它归类为又一个“低代码爬虫工具”。经过深入了解我发现 Figranium 的核心价值远不止于此。它真正解决的是将复杂的浏览器交互逻辑“服务化”和“流程化”。对于需要处理大量网页自动化、数据抓取、RPA机器人流程自动化或端到端测试的开发者来说这意味着你可以将浏览器操作封装成一个独立的、可复用的、并且可以通过 HTTP API 调用的“微服务”。想象一下这个场景你的业务系统需要定期从十几个不同的供应商网站抓取价格信息。传统做法是写一堆 Python 脚本处理登录、反爬、页面解析、数据清洗然后部署到服务器上再配上复杂的定时任务和错误监控。而 Figranium 的思路是你通过可视化界面编排好“登录-搜索-提取价格”这个任务流将其发布为一个 Docker 容器。之后任何需要执行这个抓取任务的服务只需要向这个容器的 API 发送一个简单的 POST 请求即可。它把浏览器自动化从“脚本”升级为了“服务”。本文将带你深入拆解 Figranium。我们不仅会探讨它如何通过可视化降低浏览器自动化的门槛更重要的是我会分享如何将其 Docker 化部署并通过 API 集成到你的现有系统中。你将看到完整的搭建步骤、核心 API 的调用示例以及在实际项目中如何避开那些常见的“坑”。1. Figranium 要解决的核心痛点为什么我们需要“浏览器任务即服务”在深入技术细节之前我们必须先搞清楚 Figranium 瞄准的靶心是什么。浏览器自动化不是一个新领域Selenium 已经存在了十多年后来的 Puppeteer 和 Playwright 在性能和功能上更是大幅提升。那么为什么我们还需要 Figranium关键在于“任务”与“服务”的分离以及“开发”与“执行”的分离。传统模式的困境技能门槛与维护成本编写稳定的浏览器自动化脚本需要熟悉特定框架如 Playwright、处理异步操作、应对网站动态加载和反爬机制。这对于非专业前端或测试工程师来说学习曲线陡峭。环境依赖与部署复杂脚本往往依赖本地的浏览器驱动、特定版本的 Node.js/Python 环境。将其部署到服务器尤其是 Docker 或 Kubernetes 集群中需要处理复杂的依赖和启动配置。难以集成与复用一个写好的爬虫或测试流程通常以脚本文件形式存在。其他服务如后端 API、数据管道想要调用它只能通过命令行或子进程调用耦合度高错误处理和状态管理都很麻烦。协作与版本管理困难可视化的工作流比一长串代码更易于团队评审、理解和修改。脚本的逻辑变更需要开发人员介入而一个设计良好的可视化流程业务人员也可能参与调整。Figranium 提供的思路可视化编排将点击、输入、等待、提取数据等浏览器操作抽象成“积木块”通过连线的方式定义执行顺序和逻辑分支。这降低了创建复杂任务的入门门槛。任务即 API编排好的任务被编译成可执行单元并暴露出一组标准的 RESTful API。执行一个任务就像调用POST /api/v1/tasks/run一样简单。Docker 化运行时整个执行引擎被封装在 Docker 镜像中。这意味着执行环境是标准化、隔离的可以在任何支持 Docker 的地方一键启动天生适合云原生部署。集中化管理理论上你可以部署一个 Figranium 服务器管理数十个不同的浏览器自动化任务并通过统一的 API 网关进行调度和监控。所以Figranium 最适合谁我认为是以下几类开发者需要构建内部数据抓取工具的中小团队缺乏专职爬虫工程师但业务又依赖多方数据。测试工程师希望快速构建可复用的端到端测试流程并能被 CI/CD 系统直接调用。RPA 开发者需要将一些基于网页的办公自动化流程以 API 形式提供给其他系统集成。全栈开发者在项目中偶尔需要处理自动化任务不希望深入学习和维护一套完整的浏览器自动化框架生态。接下来我们从概念到实战一步步拆解它。2. 核心概念解析任务、步骤、执行器与 API要玩转 Figranium首先要理解它的几个核心概念。这些概念构成了整个系统的基础模型。概念通俗解释类比在 Figranium 中的体现任务 (Task)一个完整的浏览器自动化目标。要做的一道菜例如鱼香肉丝。一个可视化的工作流包含从开始到结束的所有步骤。步骤 (Step)任务中的一个具体操作单元。做菜的每一个动作切肉、炒菜、调味。可视化编辑器中的一个个功能块如“打开网页”、“输入文本”、“点击元素”、“提取数据”。执行器 (Executor)真正驱动浏览器执行任务的“引擎”。厨房和厨师。Figranium 的后端服务负责解析任务定义调用 Puppeteer/Playwright 等底层库来操作浏览器。API 端点与控制执行器交互的接口。点餐的电话或二维码。一组 HTTP 接口用于上传任务、启动执行、查询状态、获取结果。Docker 容器打包了执行器、浏览器及其所有依赖的标准化运行环境。一个配备了全套厨具和食材的“移动餐车”。确保任务在任何地方都能以相同的方式运行避免了“在我电脑上好好的”这类问题。它们如何协同工作设计阶段你在Figranium 的可视化编辑器中拖拽不同的“步骤”块连接成一条流程线定义了一个任务。这个任务本质上是一个结构化的 JSON 或 YAML 配置文件。部署阶段你将这个任务配置文件连同Figranium 的执行器一起打包或部署到一个Docker 容器中。这个容器内已经包含了 Chromium 浏览器和所有必要的运行时。运行阶段你的业务系统通过 HTTP 请求调用容器暴露出的API 端点例如/run。执行器接收到请求后启动一个浏览器实例严格按照任务定义执行每一步操作。结果返回任务执行完毕后成功或失败执行器将结果如提取的数据、截图、日志通过 API 响应返回给调用方。理解了这套模型我们就知道使用 Figranium 的关键在于两点学会用编辑器构建任务以及学会通过 API 与执行器交互。3. 环境准备从零开始搭建 Figranium 实验环境由于 Figranium 是一个相对较新的开源项目我们假设你从它的官方代码仓库例如 GitHub开始。为了完成本文的演示你需要准备以下环境。基础环境要求操作系统Linux (Ubuntu 20.04 / CentOS 7)、macOS 或 Windows 10/11 (WSL2 推荐)。本文主要基于 Linux 环境演示。Docker 与 Docker Compose这是核心依赖。Figranium 的“Dockerized”特性意味着我们需要它们来构建和运行。Node.js如果要从源码构建或开发需要 Node.js (版本 16)。如果仅使用预构建的 Docker 镜像则非必须。Git用于克隆代码仓库。第一步安装 Docker 和 Docker Compose如果你还没有安装可以参考以下精简步骤以 Ubuntu 为例# 更新软件包索引并安装必要依赖 sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 设置稳定版仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 安装 Docker Compose (v2) sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose # 验证安装 docker --version docker-compose --version第二步获取 Figranium 项目代码假设项目托管在 GitHub我们克隆它请替换为实际仓库地址# 克隆项目仓库 git clone https://github.com/your-org/figranium.git cd figranium # 查看项目结构 ls -la典型的项目结构可能包含docker-compose.yml用于一键启动所有服务编辑器前端、API后端、数据库等。Dockerfile用于构建执行器或后端服务的镜像。client/可视化编辑器的前端代码可能是 React/Vue。server/API 后端服务代码可能是 Node.js Express/Koa。executor/浏览器任务执行器代码。docs/和examples/文档和示例。第三步通过 Docker Compose 快速启动如果项目提供这是最快捷的体验方式。如果项目根目录有docker-compose.yml文件# 启动所有服务在后台运行 docker-compose up -d # 查看服务运行状态 docker-compose ps # 查看日志确认服务启动无误 docker-compose logs -f server # 查看后端日志 docker-compose logs -f client # 查看前端日志启动成功后通常可以通过http://localhost:3000访问可视化编辑器通过http://localhost:8080访问 API 文档或后端服务。如果项目没有提供docker-compose.yml那么我们需要关注如何构建和运行核心的“执行器”部分。4. 核心流程拆解构建、编排与执行一个浏览器任务让我们通过一个具体的例子走通从创建到执行一个任务的完整闭环。我们的目标是访问 CSDN 首页搜索关键词“Docker”并提取第一篇文章的标题和链接。4.1 使用可视化编辑器编排任务首先我们访问 Figranium 的可视化编辑器假设运行在localhost:3000。编辑器界面通常包含左侧面板各种可用的“步骤”块Actions。中间画布拖拽和连接步骤块构建工作流。右侧面板配置当前选中步骤的参数。我们按顺序拖拽并配置以下步骤Navigate(导航)配置url为https://www.csdn.net。这是任务的起点。Wait(等待)配置等待selector为#toolbar-search-inputCSDN 首页搜索框的选择器等待时间timeout为 10000 毫秒。确保页面加载完成。Type(输入)配置selector为#toolbar-search-inputtext为Docker。向搜索框输入关键词。Click(点击)配置selector为.btn-search搜索按钮。触发搜索。Wait(等待)配置等待selector为.main-container .article-list a等待新的搜索结果列表加载。Extract(提取数据)这是关键步骤。我们需要配置提取规则。selector:.main-container .article-list a:first-child(选择第一个文章链接)。output: 这里我们定义要提取的数据结构。在编辑器中这可能以表单或 JSON 格式配置。{ title: :text, // 提取元素的文本作为标题 link: :attr(href) // 提取元素的 href 属性作为链接 }Return(返回)将上一步Extract输出的数据作为整个任务的最终结果返回。将这些步骤用箭头连接起来形成一个线性工作流。最后点击保存或导出按钮。编辑器会将这个工作流导出为一个任务定义文件例如csdn_search_docker.json。4.2 理解生成的任务定义文件导出的 JSON 文件是 Figranium 执行器的“食谱”。它的结构大致如下{ name: CSDN Search Docker, version: 1.0, steps: [ { id: step1, type: navigate, params: { url: https://www.csdn.net } }, { id: step2, type: wait, params: { selector: #toolbar-search-input, timeout: 10000 } }, { id: step3, type: type, params: { selector: #toolbar-search-input, text: Docker } }, { id: step4, type: click, params: { selector: .btn-search } }, { id: step5, type: wait, params: { selector: .main-container .article-list a, timeout: 10000 } }, { id: step6, type: extract, params: { selector: .main-container .article-list a:first-child, output: { title: :text, link: :attr(href) } } }, { id: step7, type: return, params: { data: {{step6.output}} // 引用上一步的输出 } } ] }这个文件清晰地描述了“做什么”和“怎么做”但完全不关心“在哪里运行”和“如何被触发”。这正是其作为 API 调用基础的优势。5. 将任务 Docker 化构建可独立执行的任务镜像现在我们有了任务定义文件。下一步是创建一个包含 Figranium 执行器和这个任务的 Docker 镜像使其成为一个独立的、可执行的服务。5.1 创建 Dockerfile在项目目录下或新建一个目录我们创建一个Dockerfile。这个文件描述了如何构建我们的任务镜像。# 使用 Figranium 官方提供的基础执行器镜像或者从项目构建 # 假设官方镜像名为figranium/executor:latest FROM figranium/executor:latest # 将我们的任务定义文件复制到容器内的特定目录 WORKDIR /app/tasks COPY csdn_search_docker.json ./csdn_search_docker.json # 暴露执行器服务的端口假设默认是 8080 EXPOSE 8080 # 设置容器启动时运行的命令加载我们的任务 # 假设执行器可以通过环境变量或参数指定任务文件 CMD [node, executor.js, --task-file, /app/tasks/csdn_search_docker.json]关键点解释FROM figranium/executor:latest我们基于一个预装了 Figranium 执行器、Node.js 和 Chromium 的镜像开始。你需要确认这个镜像的实际名称。COPY csdn_search_docker.json ...将本地任务文件复制到镜像中使其成为镜像的一部分。CMD ...指定容器启动时执行器加载我们给定的任务文件。5.2 构建并运行 Docker 镜像# 在包含 Dockerfile 和 csdn_search_docker.json 的目录下执行 docker build -t my-csdn-search-task . # 构建成功后运行容器 # -p 8080:8080 将容器的8080端口映射到宿主机的8080端口 # -d 后台运行 docker run -p 8080:8080 -d --name csdn-task-runner my-csdn-search-task # 查看容器日志确认执行器已启动并加载了任务 docker logs -f csdn-task-runner如果一切顺利日志会显示执行器已启动并在端口 8080 监听 API 请求。现在这个容器就成为了一个专为“CSDN 搜索 Docker”这个任务服务的微服务。6. 通过 API 调用与集成让任务真正运转起来Docker 容器运行后核心的交互方式就是 HTTP API。Figranium 执行器通常会提供一组 RESTful 接口。6.1 核心 API 调用示例我们使用curl或任何你喜欢的 HTTP 客户端如 Postman来测试。1. 健康检查端点curl http://localhost:8080/health预期返回{status:ok}之类的 JSON表明服务正常运行。2. 获取已加载的任务信息curl http://localhost:8080/api/v1/tasks预期返回一个任务列表包含我们刚加载的csdn_search_docker任务的信息。3. 执行任务同步方式这是最常用的端点。我们发送一个 POST 请求来触发任务执行。curl -X POST http://localhost:8080/api/v1/tasks/csdn_search_docker/run \ -H Content-Type: application/json \ -d { parameters: {}, options: { headless: true, timeout: 60000 } }请求体参数说明parameters: 可以向任务传递动态参数。例如如果我们将任务中的搜索关键词Docker设置为变量{{keyword}}那么就可以通过parameters: {keyword: Kubernetes}来动态改变搜索词。本例中未使用。options: 执行选项。headless: 是否使用无头模式无界面。生产环境通常为true。timeout: 整个任务执行的超时时间毫秒。4. 执行任务异步方式对于耗时较长的任务可能支持异步执行。# 启动异步执行 curl -X POST http://localhost:8080/api/v1/tasks/csdn_search_docker/run/async \ -H Content-Type: application/json \ -d {parameters:{}} # 假设返回了任务ID: {taskId: abc123} # 然后可以通过ID查询结果 curl http://localhost:8080/api/v1/tasks/results/abc1236.2 在代码中集成Python 示例在实际项目中我们更可能用编程语言来调用这个 API。以下是一个 Python 示例import requests import json class FigraniumClient: def __init__(self, base_urlhttp://localhost:8080): self.base_url base_url def run_task(self, task_name, parametersNone, optionsNone): 同步执行一个任务 url f{self.base_url}/api/v1/tasks/{task_name}/run payload { parameters: parameters or {}, options: options or {headless: True, timeout: 60000} } headers {Content-Type: application/json} try: response requests.post(url, datajson.dumps(payload), headersheaders, timeout70) response.raise_for_status() # 如果状态码不是200抛出异常 return response.json() except requests.exceptions.RequestException as e: print(f请求失败: {e}) if hasattr(e, response) and e.response is not None: print(f响应内容: {e.response.text}) return None # 使用客户端 if __name__ __main__: client FigraniumClient() result client.run_task(csdn_search_docker) if result and result.get(success): data result.get(data) print(f任务执行成功) print(f文章标题: {data.get(title)}) print(f文章链接: {data.get(link)}) # 可以将 data 存入数据库或进行下一步处理 else: print(f任务执行失败: {result})这个简单的客户端封装了 API 调用你可以在你的数据管道、定时任务或 Web 后端中直接使用它。7. 运行结果与效果验证当我们调用runAPI 后会收到一个 JSON 格式的响应。一个成功的响应可能如下所示{ success: true, taskId: run_20231027_112233, data: { title: Docker 从入门到实践最全教程, link: https://blog.csdn.net/xxx/article/details/12345678 }, metrics: { duration: 4520, stepCount: 7 }, logs: [ {level: info, message: Task started}, {level: info, message: Step 1 (navigate) completed}, // ... 其他日志 {level: info, message: Task completed successfully} ] }如何验证结果正确检查success字段为true是首要条件。审查data字段确认提取的数据结构符合预期内容非空且格式正确例如链接是完整的 URL。查看logs字段如果success为false日志会提供详细的错误信息例如元素未找到、超时、网络错误等。可选截图验证在任务编排时可以加入Screenshot步骤将关键节点的页面截图保存或返回用于人工复核和调试。如果调用失败或返回意外结果第一时间的排查思路API 连接确认 Docker 容器正在运行 (docker ps)并且端口映射正确。容器日志运行docker logs container_name查看执行器内部是否有启动错误。任务逻辑检查任务定义 JSON 文件。网站的选择器CSS Selector可能已更新导致wait或extract步骤失败。你需要使用浏览器的开发者工具重新确认选择器。执行参数检查options例如timeout是否设置得太短或者headless: false在无图形界面的服务器上可能导致失败。网络环境确保 Docker 容器可以访问外网例如https://www.csdn.net。8. 常见问题与排查思路在实际使用 Figranium 或类似工具时你会遇到一些典型问题。下表汇总了常见问题及其解决方法。问题现象可能原因排查方式解决方案容器启动失败1. 基础镜像不存在或无法拉取。2. Dockerfile 语法错误。3. 端口被占用。docker build或docker run的错误信息。docker ps -a查看容器状态。1. 检查镜像名是否正确网络能否访问 Docker Hub。2. 逐行检查 Dockerfile。3. 更改映射端口如-p 8081:8080。API 调用返回 4041. 任务名称错误。2. API 路径不正确。3. 执行器未成功加载任务。检查调用 URL 和任务名。查看容器日志确认任务加载日志。1. 调用/api/v1/tasks端点确认可用任务名。2. 查阅项目 API 文档确认正确路径。3. 重启容器确保任务文件路径正确。任务执行超时1. 页面加载慢或元素迟迟不出现。2. 网络延迟高。3. 任务步骤过多或复杂。查看返回的logs卡在哪一步。增加options中的timeout值测试。1. 在wait步骤中增加timeout值。2. 优化选择器使其更精准。3. 考虑将大任务拆分成多个小任务。元素找不到 (NoSuchElement)1. 页面结构已变化选择器失效。2. 等待时间不足元素未加载出来。3. 页面在 iframe 内。使用浏览器开发者工具手动验证选择器。在任务中增加Screenshot步骤查看失败时的页面状态。1. 更新任务定义中的选择器。2. 在操作元素前增加显式wait步骤。3. 使用SwitchToFrame步骤如果 Figranium 支持处理 iframe。提取的数据为空或格式错误1.extract步骤的选择器未匹配到任何元素。2. 提取规则如:text,:attr语法错误。3. 页面内容是 JavaScript 动态渲染的。检查extract步骤的output配置。确认页面在无头模式下内容是否正常渲染可设置headless: false调试。1. 修正选择器和提取规则。2. 考虑使用Evaluate步骤如果支持执行 JavaScript 来获取复杂数据。3. 确保执行器使用的浏览器版本支持页面所需特性。内存消耗过高1. 同时执行多个任务浏览器实例未关闭。2. 页面内容非常复杂。3. Docker 容器内存限制过低。使用docker stats监控容器资源使用。查看执行器日志是否有内存警告。1. 确保任务配置中正确关闭浏览器通常执行器会自动管理。2. 为 Docker 容器设置合理的内存限制 (-m 1g)。3. 优化任务避免打开过多标签页或加载过重资源。9. 最佳实践与工程化建议将 Figranium 用于生产环境需要考虑更多工程化因素。1. 任务设计最佳实践模块化与复用将常见的登录、导航到某个模块等操作设计成可复用的“子任务”或“模板”通过参数化调用避免重复编排。健壮的选择器优先使用id、> 
长河君 · 2026/8/25 2:09:40 · 阅读 1.2k Figranium：可视化编排浏览器任务，实现自动化即服务
如果你还在手动写爬虫脚本抓取网页数据或者为每个自动化测试用例编写重复的浏览器操作代码那么是时候停下来看看这个新工具了。最近在开发者社区里一个名为Figranium的项目引起了我的注意。它打出的旗号是“可视化构建浏览器任务并通过 API 执行”听起来像是把无头浏览器如 Puppeteer、Playwright的脚本编写变成了像搭积木一样的拖拽操作。但别急着把它归类为又一个“低代码爬虫工具”。经过深入了解我发现 Figranium 的核心价值远不止于此。它真正解决的是将复杂的浏览器交互逻辑“服务化”和“流程化”。对于需要处理大量网页自动化、数据抓取、RPA机器人流程自动化或端到端测试的开发者来说这意味着你可以将浏览器操作封装成一个独立的、可复用的、并且可以通过 HTTP API 调用的“微服务”。想象一下这个场景你的业务系统需要定期从十几个不同的供应商网站抓取价格信息。传统做法是写一堆 Python 脚本处理登录、反爬、页面解析、数据清洗然后部署到服务器上再配上复杂的定时任务和错误监控。而 Figranium 的思路是你通过可视化界面编排好“登录-搜索-提取价格”这个任务流将其发布为一个 Docker 容器。之后任何需要执行这个抓取任务的服务只需要向这个容器的 API 发送一个简单的 POST 请求即可。它把浏览器自动化从“脚本”升级为了“服务”。本文将带你深入拆解 Figranium。我们不仅会探讨它如何通过可视化降低浏览器自动化的门槛更重要的是我会分享如何将其 Docker 化部署并通过 API 集成到你的现有系统中。你将看到完整的搭建步骤、核心 API 的调用示例以及在实际项目中如何避开那些常见的“坑”。1. Figranium 要解决的核心痛点为什么我们需要“浏览器任务即服务”在深入技术细节之前我们必须先搞清楚 Figranium 瞄准的靶心是什么。浏览器自动化不是一个新领域Selenium 已经存在了十多年后来的 Puppeteer 和 Playwright 在性能和功能上更是大幅提升。那么为什么我们还需要 Figranium关键在于“任务”与“服务”的分离以及“开发”与“执行”的分离。传统模式的困境技能门槛与维护成本编写稳定的浏览器自动化脚本需要熟悉特定框架如 Playwright、处理异步操作、应对网站动态加载和反爬机制。这对于非专业前端或测试工程师来说学习曲线陡峭。环境依赖与部署复杂脚本往往依赖本地的浏览器驱动、特定版本的 Node.js/Python 环境。将其部署到服务器尤其是 Docker 或 Kubernetes 集群中需要处理复杂的依赖和启动配置。难以集成与复用一个写好的爬虫或测试流程通常以脚本文件形式存在。其他服务如后端 API、数据管道想要调用它只能通过命令行或子进程调用耦合度高错误处理和状态管理都很麻烦。协作与版本管理困难可视化的工作流比一长串代码更易于团队评审、理解和修改。脚本的逻辑变更需要开发人员介入而一个设计良好的可视化流程业务人员也可能参与调整。Figranium 提供的思路可视化编排将点击、输入、等待、提取数据等浏览器操作抽象成“积木块”通过连线的方式定义执行顺序和逻辑分支。这降低了创建复杂任务的入门门槛。任务即 API编排好的任务被编译成可执行单元并暴露出一组标准的 RESTful API。执行一个任务就像调用POST /api/v1/tasks/run一样简单。Docker 化运行时整个执行引擎被封装在 Docker 镜像中。这意味着执行环境是标准化、隔离的可以在任何支持 Docker 的地方一键启动天生适合云原生部署。集中化管理理论上你可以部署一个 Figranium 服务器管理数十个不同的浏览器自动化任务并通过统一的 API 网关进行调度和监控。所以Figranium 最适合谁我认为是以下几类开发者需要构建内部数据抓取工具的中小团队缺乏专职爬虫工程师但业务又依赖多方数据。测试工程师希望快速构建可复用的端到端测试流程并能被 CI/CD 系统直接调用。RPA 开发者需要将一些基于网页的办公自动化流程以 API 形式提供给其他系统集成。全栈开发者在项目中偶尔需要处理自动化任务不希望深入学习和维护一套完整的浏览器自动化框架生态。接下来我们从概念到实战一步步拆解它。2. 核心概念解析任务、步骤、执行器与 API要玩转 Figranium首先要理解它的几个核心概念。这些概念构成了整个系统的基础模型。概念通俗解释类比在 Figranium 中的体现任务 (Task)一个完整的浏览器自动化目标。要做的一道菜例如鱼香肉丝。一个可视化的工作流包含从开始到结束的所有步骤。步骤 (Step)任务中的一个具体操作单元。做菜的每一个动作切肉、炒菜、调味。可视化编辑器中的一个个功能块如“打开网页”、“输入文本”、“点击元素”、“提取数据”。执行器 (Executor)真正驱动浏览器执行任务的“引擎”。厨房和厨师。Figranium 的后端服务负责解析任务定义调用 Puppeteer/Playwright 等底层库来操作浏览器。API 端点与控制执行器交互的接口。点餐的电话或二维码。一组 HTTP 接口用于上传任务、启动执行、查询状态、获取结果。Docker 容器打包了执行器、浏览器及其所有依赖的标准化运行环境。一个配备了全套厨具和食材的“移动餐车”。确保任务在任何地方都能以相同的方式运行避免了“在我电脑上好好的”这类问题。它们如何协同工作设计阶段你在Figranium 的可视化编辑器中拖拽不同的“步骤”块连接成一条流程线定义了一个任务。这个任务本质上是一个结构化的 JSON 或 YAML 配置文件。部署阶段你将这个任务配置文件连同Figranium 的执行器一起打包或部署到一个Docker 容器中。这个容器内已经包含了 Chromium 浏览器和所有必要的运行时。运行阶段你的业务系统通过 HTTP 请求调用容器暴露出的API 端点例如/run。执行器接收到请求后启动一个浏览器实例严格按照任务定义执行每一步操作。结果返回任务执行完毕后成功或失败执行器将结果如提取的数据、截图、日志通过 API 响应返回给调用方。理解了这套模型我们就知道使用 Figranium 的关键在于两点学会用编辑器构建任务以及学会通过 API 与执行器交互。3. 环境准备从零开始搭建 Figranium 实验环境由于 Figranium 是一个相对较新的开源项目我们假设你从它的官方代码仓库例如 GitHub开始。为了完成本文的演示你需要准备以下环境。基础环境要求操作系统Linux (Ubuntu 20.04 / CentOS 7)、macOS 或 Windows 10/11 (WSL2 推荐)。本文主要基于 Linux 环境演示。Docker 与 Docker Compose这是核心依赖。Figranium 的“Dockerized”特性意味着我们需要它们来构建和运行。Node.js如果要从源码构建或开发需要 Node.js (版本 16)。如果仅使用预构建的 Docker 镜像则非必须。Git用于克隆代码仓库。第一步安装 Docker 和 Docker Compose如果你还没有安装可以参考以下精简步骤以 Ubuntu 为例# 更新软件包索引并安装必要依赖 sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 设置稳定版仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 安装 Docker Compose (v2) sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose # 验证安装 docker --version docker-compose --version第二步获取 Figranium 项目代码假设项目托管在 GitHub我们克隆它请替换为实际仓库地址# 克隆项目仓库 git clone https://github.com/your-org/figranium.git cd figranium # 查看项目结构 ls -la典型的项目结构可能包含docker-compose.yml用于一键启动所有服务编辑器前端、API后端、数据库等。Dockerfile用于构建执行器或后端服务的镜像。client/可视化编辑器的前端代码可能是 React/Vue。server/API 后端服务代码可能是 Node.js Express/Koa。executor/浏览器任务执行器代码。docs/和examples/文档和示例。第三步通过 Docker Compose 快速启动如果项目提供这是最快捷的体验方式。如果项目根目录有docker-compose.yml文件# 启动所有服务在后台运行 docker-compose up -d # 查看服务运行状态 docker-compose ps # 查看日志确认服务启动无误 docker-compose logs -f server # 查看后端日志 docker-compose logs -f client # 查看前端日志启动成功后通常可以通过http://localhost:3000访问可视化编辑器通过http://localhost:8080访问 API 文档或后端服务。如果项目没有提供docker-compose.yml那么我们需要关注如何构建和运行核心的“执行器”部分。4. 核心流程拆解构建、编排与执行一个浏览器任务让我们通过一个具体的例子走通从创建到执行一个任务的完整闭环。我们的目标是访问 CSDN 首页搜索关键词“Docker”并提取第一篇文章的标题和链接。4.1 使用可视化编辑器编排任务首先我们访问 Figranium 的可视化编辑器假设运行在localhost:3000。编辑器界面通常包含左侧面板各种可用的“步骤”块Actions。中间画布拖拽和连接步骤块构建工作流。右侧面板配置当前选中步骤的参数。我们按顺序拖拽并配置以下步骤Navigate(导航)配置url为https://www.csdn.net。这是任务的起点。Wait(等待)配置等待selector为#toolbar-search-inputCSDN 首页搜索框的选择器等待时间timeout为 10000 毫秒。确保页面加载完成。Type(输入)配置selector为#toolbar-search-inputtext为Docker。向搜索框输入关键词。Click(点击)配置selector为.btn-search搜索按钮。触发搜索。Wait(等待)配置等待selector为.main-container .article-list a等待新的搜索结果列表加载。Extract(提取数据)这是关键步骤。我们需要配置提取规则。selector:.main-container .article-list a:first-child(选择第一个文章链接)。output: 这里我们定义要提取的数据结构。在编辑器中这可能以表单或 JSON 格式配置。{ title: :text, // 提取元素的文本作为标题 link: :attr(href) // 提取元素的 href 属性作为链接 }Return(返回)将上一步Extract输出的数据作为整个任务的最终结果返回。将这些步骤用箭头连接起来形成一个线性工作流。最后点击保存或导出按钮。编辑器会将这个工作流导出为一个任务定义文件例如csdn_search_docker.json。4.2 理解生成的任务定义文件导出的 JSON 文件是 Figranium 执行器的“食谱”。它的结构大致如下{ name: CSDN Search Docker, version: 1.0, steps: [ { id: step1, type: navigate, params: { url: https://www.csdn.net } }, { id: step2, type: wait, params: { selector: #toolbar-search-input, timeout: 10000 } }, { id: step3, type: type, params: { selector: #toolbar-search-input, text: Docker } }, { id: step4, type: click, params: { selector: .btn-search } }, { id: step5, type: wait, params: { selector: .main-container .article-list a, timeout: 10000 } }, { id: step6, type: extract, params: { selector: .main-container .article-list a:first-child, output: { title: :text, link: :attr(href) } } }, { id: step7, type: return, params: { data: {{step6.output}} // 引用上一步的输出 } } ] }这个文件清晰地描述了“做什么”和“怎么做”但完全不关心“在哪里运行”和“如何被触发”。这正是其作为 API 调用基础的优势。5. 将任务 Docker 化构建可独立执行的任务镜像现在我们有了任务定义文件。下一步是创建一个包含 Figranium 执行器和这个任务的 Docker 镜像使其成为一个独立的、可执行的服务。5.1 创建 Dockerfile在项目目录下或新建一个目录我们创建一个Dockerfile。这个文件描述了如何构建我们的任务镜像。# 使用 Figranium 官方提供的基础执行器镜像或者从项目构建 # 假设官方镜像名为figranium/executor:latest FROM figranium/executor:latest # 将我们的任务定义文件复制到容器内的特定目录 WORKDIR /app/tasks COPY csdn_search_docker.json ./csdn_search_docker.json # 暴露执行器服务的端口假设默认是 8080 EXPOSE 8080 # 设置容器启动时运行的命令加载我们的任务 # 假设执行器可以通过环境变量或参数指定任务文件 CMD [node, executor.js, --task-file, /app/tasks/csdn_search_docker.json]关键点解释FROM figranium/executor:latest我们基于一个预装了 Figranium 执行器、Node.js 和 Chromium 的镜像开始。你需要确认这个镜像的实际名称。COPY csdn_search_docker.json ...将本地任务文件复制到镜像中使其成为镜像的一部分。CMD ...指定容器启动时执行器加载我们给定的任务文件。5.2 构建并运行 Docker 镜像# 在包含 Dockerfile 和 csdn_search_docker.json 的目录下执行 docker build -t my-csdn-search-task . # 构建成功后运行容器 # -p 8080:8080 将容器的8080端口映射到宿主机的8080端口 # -d 后台运行 docker run -p 8080:8080 -d --name csdn-task-runner my-csdn-search-task # 查看容器日志确认执行器已启动并加载了任务 docker logs -f csdn-task-runner如果一切顺利日志会显示执行器已启动并在端口 8080 监听 API 请求。现在这个容器就成为了一个专为“CSDN 搜索 Docker”这个任务服务的微服务。6. 通过 API 调用与集成让任务真正运转起来Docker 容器运行后核心的交互方式就是 HTTP API。Figranium 执行器通常会提供一组 RESTful 接口。6.1 核心 API 调用示例我们使用curl或任何你喜欢的 HTTP 客户端如 Postman来测试。1. 健康检查端点curl http://localhost:8080/health预期返回{status:ok}之类的 JSON表明服务正常运行。2. 获取已加载的任务信息curl http://localhost:8080/api/v1/tasks预期返回一个任务列表包含我们刚加载的csdn_search_docker任务的信息。3. 执行任务同步方式这是最常用的端点。我们发送一个 POST 请求来触发任务执行。curl -X POST http://localhost:8080/api/v1/tasks/csdn_search_docker/run \ -H Content-Type: application/json \ -d { parameters: {}, options: { headless: true, timeout: 60000 } }请求体参数说明parameters: 可以向任务传递动态参数。例如如果我们将任务中的搜索关键词Docker设置为变量{{keyword}}那么就可以通过parameters: {keyword: Kubernetes}来动态改变搜索词。本例中未使用。options: 执行选项。headless: 是否使用无头模式无界面。生产环境通常为true。timeout: 整个任务执行的超时时间毫秒。4. 执行任务异步方式对于耗时较长的任务可能支持异步执行。# 启动异步执行 curl -X POST http://localhost:8080/api/v1/tasks/csdn_search_docker/run/async \ -H Content-Type: application/json \ -d {parameters:{}} # 假设返回了任务ID: {taskId: abc123} # 然后可以通过ID查询结果 curl http://localhost:8080/api/v1/tasks/results/abc1236.2 在代码中集成Python 示例在实际项目中我们更可能用编程语言来调用这个 API。以下是一个 Python 示例import requests import json class FigraniumClient: def __init__(self, base_urlhttp://localhost:8080): self.base_url base_url def run_task(self, task_name, parametersNone, optionsNone): 同步执行一个任务 url f{self.base_url}/api/v1/tasks/{task_name}/run payload { parameters: parameters or {}, options: options or {headless: True, timeout: 60000} } headers {Content-Type: application/json} try: response requests.post(url, datajson.dumps(payload), headersheaders, timeout70) response.raise_for_status() # 如果状态码不是200抛出异常 return response.json() except requests.exceptions.RequestException as e: print(f请求失败: {e}) if hasattr(e, response) and e.response is not None: print(f响应内容: {e.response.text}) return None # 使用客户端 if __name__ __main__: client FigraniumClient() result client.run_task(csdn_search_docker) if result and result.get(success): data result.get(data) print(f任务执行成功) print(f文章标题: {data.get(title)}) print(f文章链接: {data.get(link)}) # 可以将 data 存入数据库或进行下一步处理 else: print(f任务执行失败: {result})这个简单的客户端封装了 API 调用你可以在你的数据管道、定时任务或 Web 后端中直接使用它。7. 运行结果与效果验证当我们调用runAPI 后会收到一个 JSON 格式的响应。一个成功的响应可能如下所示{ success: true, taskId: run_20231027_112233, data: { title: Docker 从入门到实践最全教程, link: https://blog.csdn.net/xxx/article/details/12345678 }, metrics: { duration: 4520, stepCount: 7 }, logs: [ {level: info, message: Task started}, {level: info, message: Step 1 (navigate) completed}, // ... 其他日志 {level: info, message: Task completed successfully} ] }如何验证结果正确检查success字段为true是首要条件。审查data字段确认提取的数据结构符合预期内容非空且格式正确例如链接是完整的 URL。查看logs字段如果success为false日志会提供详细的错误信息例如元素未找到、超时、网络错误等。可选截图验证在任务编排时可以加入Screenshot步骤将关键节点的页面截图保存或返回用于人工复核和调试。如果调用失败或返回意外结果第一时间的排查思路API 连接确认 Docker 容器正在运行 (docker ps)并且端口映射正确。容器日志运行docker logs container_name查看执行器内部是否有启动错误。任务逻辑检查任务定义 JSON 文件。网站的选择器CSS Selector可能已更新导致wait或extract步骤失败。你需要使用浏览器的开发者工具重新确认选择器。执行参数检查options例如timeout是否设置得太短或者headless: false在无图形界面的服务器上可能导致失败。网络环境确保 Docker 容器可以访问外网例如https://www.csdn.net。8. 常见问题与排查思路在实际使用 Figranium 或类似工具时你会遇到一些典型问题。下表汇总了常见问题及其解决方法。问题现象可能原因排查方式解决方案容器启动失败1. 基础镜像不存在或无法拉取。2. Dockerfile 语法错误。3. 端口被占用。docker build或docker run的错误信息。docker ps -a查看容器状态。1. 检查镜像名是否正确网络能否访问 Docker Hub。2. 逐行检查 Dockerfile。3. 更改映射端口如-p 8081:8080。API 调用返回 4041. 任务名称错误。2. API 路径不正确。3. 执行器未成功加载任务。检查调用 URL 和任务名。查看容器日志确认任务加载日志。1. 调用/api/v1/tasks端点确认可用任务名。2. 查阅项目 API 文档确认正确路径。3. 重启容器确保任务文件路径正确。任务执行超时1. 页面加载慢或元素迟迟不出现。2. 网络延迟高。3. 任务步骤过多或复杂。查看返回的logs卡在哪一步。增加options中的timeout值测试。1. 在wait步骤中增加timeout值。2. 优化选择器使其更精准。3. 考虑将大任务拆分成多个小任务。元素找不到 (NoSuchElement)1. 页面结构已变化选择器失效。2. 等待时间不足元素未加载出来。3. 页面在 iframe 内。使用浏览器开发者工具手动验证选择器。在任务中增加Screenshot步骤查看失败时的页面状态。1. 更新任务定义中的选择器。2. 在操作元素前增加显式wait步骤。3. 使用SwitchToFrame步骤如果 Figranium 支持处理 iframe。提取的数据为空或格式错误1.extract步骤的选择器未匹配到任何元素。2. 提取规则如:text,:attr语法错误。3. 页面内容是 JavaScript 动态渲染的。检查extract步骤的output配置。确认页面在无头模式下内容是否正常渲染可设置headless: false调试。1. 修正选择器和提取规则。2. 考虑使用Evaluate步骤如果支持执行 JavaScript 来获取复杂数据。3. 确保执行器使用的浏览器版本支持页面所需特性。内存消耗过高1. 同时执行多个任务浏览器实例未关闭。2. 页面内容非常复杂。3. Docker 容器内存限制过低。使用docker stats监控容器资源使用。查看执行器日志是否有内存警告。1. 确保任务配置中正确关闭浏览器通常执行器会自动管理。2. 为 Docker 容器设置合理的内存限制 (-m 1g)。3. 优化任务避免打开过多标签页或加载过重资源。9. 最佳实践与工程化建议将 Figranium 用于生产环境需要考虑更多工程化因素。1. 任务设计最佳实践模块化与复用将常见的登录、导航到某个模块等操作设计成可复用的“子任务”或“模板”通过参数化调用避免重复编排。健壮的选择器优先使用id、>