值得列入候选名单的开源 RPA 工具，以及它们的运行环境

常见开源 RPA 候选名单上的一些工具无法在没有桌面环境的 Linux 服务器上运行。它们自动操作桌面界面，依赖图形会话，而这样的服务器没有可供控制的桌面会话。仅这一项特性就把这个类别分成了两类，也决定了你的机器人可以部署在哪里。

商业 RPA 的许可证制度是人们搜索最佳开源 RPA 工具的主要原因。我在 2026 年 10 月 5 日再次检查了下文的许可证、项目活动和软件包记录，每一项状态说明都链接到了它所依据的记录。

核心要点

• 先看会话需求，再看功能列表。Oculix、OpenRPA 和 taskt 以 GUI 为核心，执行本地桌面任务需要图形会话。RPA Framework 在执行浏览器、文件和数据任务时不需要。TagUI 和 UI.Vision 则取决于所用模式。
• RPA Framework 在 2026 年的 2 月、3 月、5 月、6 月、8 月和 10 月均发布了版本，是这里核实过的项目中发布记录最稳定的一个。
• TagUI 使用 Apache-2.0 许可证，仍接受贡献，但 AI Singapore 已停止对其维护和支持。它的 Python 封装自 2023 年 7 月以来没有发布新版本。
• Automagica 和 OpenBots 不应出现在当前的候选名单上。Netcall 于 2020 年 10 月收购 Automagica 后，它便不再采用 AGPL3 许可证；OpenBots 则没有持续维护的 RPA 产品公共仓库。
• 如果你要连接的系统已经提供 API 或 webhook，你需要的是工作流自动化，而不是 RPA。这是不同的类别，使用不同的工具，搭建过程也短得多。

本文不涉及的内容

以下三个相关问题不在本文范围内，各有其原因。

• 提供免费层级的商业平台。UiPath Community Edition 和 Power Automate 的免费方案，与本文讨论的是不同的选择问题。
• 安装与配置。下文不是安装指南，也不会为任何工具提供命令行操作说明。
• AI 计算机操作代理。名单上的一款工具提供了与此类代理的集成，本文只用一句话提及，不做比较。

仍在维护中的开源 RPA 工具

下列六个项目符合本文采用的标准：真正开源的 RPA 软件，并且自 2025 年年中以来有公开活动。停止维护的免费 RPA 工具仍然免费，因此下面最值得关注的是带日期的那一列，而非许可证一列。其他列说明各款工具能自动完成哪些任务，以及它们对底层机器有什么要求。

rpaframework 是一组库，而不是应用程序。你需要编写 Python 或 Robot Framework 代码，并导入所需组件：与录制宏相比，入门更难，但维护轻松得多。其仓库将它描述为针对 Control Room 优化；Control Room 是 Robocorp 围绕它构建的商业编排产品。r/rpa 讨论串中的一位 Sema4.ai 团队成员称 Robocorp 现已成为 Sema4.ai 的一部分，并明确说明了两者的界限。库采用 Apache-2.0 许可证，平台则不是。所有权变了，界限没变。其底层的 Robot Framework 同样采用 Apache-2.0，不应作为另一个独立候选项。

UI.Vision 的浏览器扩展是开源核心。桌面自动化需要另行下载名为 XModules 的本地应用，为扩展提供图像和文本识别能力，使其能够点击浏览器之外的内容。它采用双许可证（AGPLv3 或商业协议）。如果你修改开源核心，却不愿遵守 AGPLv3 的源代码共享条款，商业许可证就是另一种选择。

taskt 是名单中较尴尬的一项。其开发分支在 2025 年 7 月收到一次提交，而上一个带标签版本 v3.5.0.0 发布于 2020 年 5 月。提交和发布传递的是不同信号，这么久没有带版本号的构建，并不意味着现有构建已无法工作。

SikuliX 需要单独说明，因为这个名称实际上已成为旧版本系列的代称。原始上游于 2026 年 3 月归档，oculix-org 镜像仓库则引导当前用户转向 Oculix，这个采用 MIT 许可证、持续活跃的后续项目。因此，现在应列入候选名单的是 Oculix；SikuliX1 更适合作为项目沿革和兼容性背景，而非仍在维护的候选项。

有两个项目不断出现在候选名单上，但不应该。Automagica 自己的 README 宣布，Netcall 于 2020 年 10 月 13 日收购了公司，其机器人已不再以 AGPL3 许可证提供；而 OpenBots 的公共 GitHub 组织只有一个静态网站仓库和一个终端仿真库，没有 RPA 核心。

依赖 GUI 还是无头运行：决定服务器选择的分界线

当工作流依赖桌面 UI 自动化时，开源 RPA 工具就需要桌面会话。API、文件和数据自动化可以无头运行；浏览器在无头模式下运行时，浏览器自动化也可以。图像识别工具还需要可供分析的像素，不过，即使桌面自动化通过选择器而非图像识别控件，也仍然可能依赖图形会话。

桌面会话是用户登录后获得的图形环境：屏幕、窗口管理器以及带坐标的鼠标指针。无头运行正好相反，指机器在没有连接显示器的情况下运行。你租用的大多数 Linux 服务器默认都以无头方式运行。

这一分界源于自动化依赖什么。Oculix 与此前的 SikuliX 一样，使用计算机视觉，将存储的图像与当前屏幕像素进行匹配来定位按钮，因此需要可供分析的图形显示区域。通过自动化 API 驱动的浏览器可以在没有桌面显示的情况下无头运行。基于选择器的桌面自动化又有所不同：它可能识别的是控件而非像素，但仍可能依赖图形桌面环境。对于服务器上的开源 RPA，实际要问的是工作流是否需要图形会话。

TagUI 和 UI.Vision 横跨这两类，具体属于哪一类取决于所用模式。TagUI 自己的参考文档说明，-headless 选项会使用不可见的 Chrome 浏览器运行流程，且不适用于视觉自动化。UI.Vision 的浏览器任务在扩展内部运行，桌面任务则通过 XModules 执行；它识别屏幕上的图像，因此需要屏幕来识别这些图像。

虚拟显示器可以填补一部分差距。Xvfb 是一种标准方式，可为无头 Linux 机器提供内存中的显示器，图形程序能够在其中绘制内容，而不需要有人观看。这样，没有物理显示器的服务器也能进行屏幕驱动的自动化。但它无法让仅支持 Windows 的工具在 Linux 上运行，而且还增加了一层必须在凌晨三点保持正常工作的组件。

许可证和提交日期说明工具明年是否还会存在。会话需求则说明你究竟能不能运行它。

各款工具的运行环境

屏幕驱动的机器人需要能够控制的图形会话，无论是真实桌面、远程会话还是虚拟显示器。无头机器人则不需要。这听起来很简单，直到机器人必须在凌晨 3 点、无人操作键盘时启动。

自托管 RPA 有一项不受工具选择影响的运行要求：计划任务触发时，机器必须处于正确状态。在 Windows 上，这个状态有明确要求，Microsoft 针对自家产品提供了详细文档。Microsoft 关于 Power Automate 无人值守桌面流程的指导说明，产品会在目标机器上创建远程桌面会话来运行流程；无人值守运行无法连接机器的控制台会话；Windows 10 或 Windows 11 设备在存在用户会话时无法运行这种流程，即使会话已锁定。在 Windows Server 上，如果已有一个打开且锁定的会话，其用户与连接所用的用户相同，则会返回错误。

这是某一家供应商的实现方式，并非 Windows 的普遍规则，但它有助于理解故障模式，因为所有屏幕驱动的机器人都必须解决同一个问题：必须有某个主体占用一个交互式会话，而你自己登录的桌面往往正是障碍。在 Linux 上，相应问题较小，但并非不存在：在 SSH 会话关闭后仍能继续运行的任务需要调度器和服务管理器，而不是一个被你留着不关的终端。

Windows Server 处理会话的方式与桌面版本不同。它的 RD Session Host 角色在一台机器上运行基于会话的桌面，以提高多会话效率，因此机器人会话与自己的会话可以并存。如果你使用 RD Session Host 进行多会话操作，每个连接的用户或设备都需要 RDS CAL。这项费用应尽早纳入预算，而不是到最后才发现。

资源需求并不高。对于点击表单并输出文件的机器人，我不会配置超过 1 vCPU 和 2 GB 内存的资源。对于驱动完整浏览器的任务，我会提供 2 vCPU 和至少 4 GB 内存，尤其是涉及多个标签页时，因为这类工作负载中消耗资源的是 Chrome，而不是其上运行的自动化工具。

壁橱里的一台旧机器就能满足这一标准。但它必须保持通电、保持登录，而且不能是你晚上会合上的笔记本电脑。租用服务器可以消除这类问题，因为它能够独立于你的笔记本电脑持续运行，也不会争用你工作时使用的桌面会话。

如果租用机器比自行维护更合适，这一分界也可以相当清楚地对应两类产品。运行 Desktop 或 Server 镜像的 Windows VPS 为屏幕驱动的机器人提供独立的 Windows 环境，Linux VPS 则适合无头运行，两者都能持续运行，无论你的笔记本电脑是否打开。

该选哪一款

如果任务只涉及浏览器或文件，而且你会写 Python，那么就选 RPA Framework；本节其余内容讨论的是特殊情况。一旦任务涉及没有 API 的桌面应用，答案就会改变，因为你需要能够与图形桌面交互的工具，而候选名单也会变得更短、更老。

在 Linux 服务器上处理浏览器、文件和数据任务，请选择 RPA Framework。它可以无头运行，无须额外组件就能部署到没有显示器的机器上，并且最近在 2026 年 10 月仍发布了新版本。代价是你要编写 Python 或 Robot Framework 代码，而非录制宏；这会增加第一天的投入，但目标应用每次变化时，都会回报这份投入。

对于没有 API 的旧式 Windows 应用，如果你想使用视觉自动化，而不是编写完整的自动化代码库，就选择 UI.Vision，但要注意附带条件。它今年仍有提交，而这里并非所有支持桌面的选项都如此；此外，在修改并分发开源软件时，其双许可证中的 AGPLv3 会带来源代码共享义务。taskt 是这里的第二选择。其开发分支仍活跃，最近一个带标签版本发布于 2020 年 5 月；你需要权衡的，正是接受提交的项目与持续发布版本的项目之间的差距。

对于跨平台的、面向屏幕上任何内容的视觉自动化，请选择 Oculix，它是 SikuliX 的活跃后续项目。它仍以图像而非选择器为优先，但如今项目拥有 IDE 并持续发布版本，而不再只是一组图像匹配基础功能。当目标是像素，而非 DOM 或可访问性树时，可以使用它；已归档的 SikuliX1 仓库应视为旧版本系列，而不是仍在维护的产品。

TagUI 一直受到推荐是有原因的。它的脚本语言接近普通英语，在这六款工具中学习门槛最低。需要权衡的因素写在它自己的 README 中：其中声明AI Singapore 已停止维护和支持 TagUI，而项目由开源贡献者和社区继续推进。这并非被遗弃。贡献者仍在默认分支上提交修复，仓库也没有归档。但这也算不上强劲的发展势头，而且 PyPI 上的 rpa Python 封装比提交记录落后了好几年。可以为一个你能够接受冻结的任务选择 TagUI，而不要把它作为计划持续扩展三年的平台。

OpenRPA 更难判断。它在 MPL-2.0 许可证下提供真正的编排功能，但其最后一次代码提交和最新带标签版本都停留在 2025 年 6 月，此后仓库中唯一的活动只是自动创建的依赖更新分支。这并不算被遗弃，因为没有任何内容被归档，但也没有发布任何新版本。应结合机器人需要持续运行多久，权衡这一差距。

什么时候专用 RPA 工具不是正确答案

对上述所有工具最有力的反对意见，来自一位实际从事这类工作的人。在一个 r/selfhosted 讨论串中，一名运营人员想摆脱商业 RPA 合同，有回复主张改用 Python 搭配 Selenium 等自动化框架。搭建时投入更多，但完成后更少出故障，持续持有成本也低于该评论者使用过的 RPA 软件。同一讨论串中的另一位评论者独立表达了相同看法。

分界点在于维护。如果任务要运行多年、处理量很大，而且你或团队中的某个人能够维护一个小型代码库，就编写代码。Selenium 和 Playwright 在第一天的成本更高，但到第四百天成本更低，因为自己写的脚本发生故障时，你能看懂问题。如果任务只持续几个月，或团队无人编写代码，那么 RPA 工具更快实现可用机器人的优势，足以抵消其脆弱性。

录制生成的内容最容易随时间老化。通过观察点击而生成的脚本，与录制时的布局绑定，所以页面重新设计或按钮移动就会使它失效，而错误消息往往解释不清原因。有些地方对这一类别的怀疑更深：一个讨论开源选项的 r/rpa 讨论串中的评论者称，RPA 是把脚本重新包装后卖给非技术管理人员；对于范围足够窄的任务，这种描述并非不公允。

还有一种类别判断错误，应尽早识别。如果你要连接的系统提供 API 或 webhook，你根本不需要 RPA。RPA 操作用户界面，是因为没有其他入口；工作流自动化则直接调用入口，因此构建更快，也远没有那么脆弱。那是另一套工具，有自己的成本曲线，首先应弄清楚的是n8n 的许可证及其自托管成本。如果你希望今天就运行起来，我们的应用市场提供 n8n、Node-RED、Apache Airflow、Kestra 和 Dagu 的一键部署应用。

UI.Vision 当前的网站宣传了 Anthropic Computer Use 集成，因此这一类别已经开始吸收通过推理屏幕内容、而非匹配存储图像来操作屏幕的代理。

常见问题

UiPath 是开源的吗？

不是。UiPath 是商业平台，其 Community Edition 提供的是免费使用权，而不是公开源代码。UiPath 的 Community Agreement规定了使用条款，其中包括禁止反编译和逆向工程软件。开源的 UiPath 替代品，是那些以 Apache-2.0、MIT、MPL-2.0 或 AGPLv3 许可证发布代码的项目。

TagUI 仍有人维护吗？

原始维护者已不再维护。TagUI 的 README 声明，AI Singapore 已停止维护和支持，而项目由开源贡献者和社区继续推进。仓库没有归档，仍接受提交，默认分支上最新提交日期为 2026 年 9 月 20 日；不过，从 2025 年 3 月到这次修复之间，该分支一直没有变化。PyPI 上的 rpa Python 封装仍为 1.50.0，发布于 2023 年 7 月 7 日。

能在没有桌面的 Linux 服务器上运行 RPA 机器人吗？

可以，适用于 API、文件和数据自动化，以及配置为无头运行的浏览器自动化。桌面 UI 自动化通常需要图形会话。在 Linux 上，如果提供 Xvfb 等虚拟显示器，图像驱动的工作流有时也能在原本无头运行的服务器上运行。

Robocorp 被收购后，RPA Framework 仍然开源吗？

根据许可证和发布记录，答案是肯定的。rpaframework 在自己的仓库中采用 Apache-2.0 许可证，并于 2026 年 10 月 4 日在 PyPI 发布了 33.0.2 版本，此时距离 Robocorp 成为 Sema4.ai 的一部分已经过去很久。围绕这个库构建的编排产品 Control Room，在公司易主之前就属于商业部分，现在仍然如此。

哪些开源 RPA 工具可以在 macOS 或 Linux 上运行，而不是只支持 Windows？

除 taskt 和 OpenRPA 外，这些工具都可以；这两款仅支持 Windows 是结构性原因，而非打包方式的选择。taskt 的仓库称其使用 C# 构建于 .NET Framework 之上，OpenRPA 则自动操作 Windows 桌面应用，因此两者都没有 Linux 或 macOS 构建。其余四款均跨平台。UI.Vision 为这三个平台都提供 XModules，Oculix 支持 Windows、macOS 和 Linux，RPA Framework 可以在任何能够运行 Python 的环境中运行，而 TagUI 的 README 称其支持 Windows、macOS 和 Linux。