坦诚的立场
大多数工具对比文章都是厂商写的。看得出来——一方在每项指标上都“赢”，结论永远是“用我们的产品”。
这篇文章想不一样。AWX 和 Semaphore UI 解决的是有重叠的问题，但它们对“你是谁、你有什么”的假设不同。正确答案确实取决于你的处境。
我们将讨论：各自做什么、架构如何、功能上哪里不同，以及——最重要的是——什么样的团队该选哪一个。
什么是 AWX？
AWX 是 Red Hat 用作商业 Ansible 自动化平台（AAP）基础的开放源代码上游项目。它提供 Web 界面、REST API 和任务引擎，用于在基础设施上运行 Ansible playbook。
AWX 免费，采用 MIT 许可证，由社区支持。Red Hat 选取部分 AWX 版本进行加固，并重新打包为“Automation Controller”——AAP 的核心组件。功能通常先出现在 AWX；企业级支持在 Automation Controller 一侧。
现状（2026 年）： 最后一次 AWX 发布是 2024 年 7 月 2 日的 24.6.1。在大规模架构重构期间，开发已暂停。团队承认“现有应用架构限制了变更能力”，并已触及“在现有系统上能创新多远”的上限。Ansible 集合 awx.awx 也被指出缺乏积极维护。这并不意味着 AWX“已死”，而是说它处于没有明确时间表的重大过渡期。
什么是 Semaphore UI？
Semaphore UI 是用于运行 Ansible、Terraform/OpenTofu、Bash、Python 和 PowerShell 自动化的开源 Web 界面。它用 Go 编写，以单一二进制文件发布，无外部运行时依赖。
与 AWX 一样，它提供 UI、REST API、调度、RBAC 和团队管理。与 AWX 不同的是，它不绑定 Kubernetes，也不是建立在商业企业产品之上。
Semaphore 有免费的 MIT 开源版本，以及增加项目 Runner、2FA、Terraform HTTP 后端和日志导出的 Pro 层。企业选项包括 HA、LDAP/SSO 和优先支持。
架构与安装
这是两者分歧最大的地方。
AWX 需要 Kubernetes。 自 v18.0.0 起，单机 Docker 部署不再被官方支持用于生产。你需要一个可用的 Kubernetes 集群——可以是单机上的 k3s、完整多节点集群或托管云服务。推荐方式是 AWX Operator，需要 kustomize 3.5.1+。最新版本要求 PostgreSQL 15。
Semaphore 几乎不需要什么。 它是一个编译好的 Go 二进制文件。可通过包管理器（apt、dnf）、Docker、Helm 安装，或直接下载运行。小型环境可用 SQLite；生产环境用 PostgreSQL 或 MySQL。典型的 Docker 场景一条命令即可。
实际差异：把 AWX 装好往往需要数小时，并假设你熟悉 Kubernetes。部署 Semaphore 只需数分钟，几乎零前提。
| AWX | Semaphore UI | |
|---|---|---|
| 部署方式 | Kubernetes + AWX Operator | 二进制、Docker、Helm、包管理器 |
| 必需依赖 | Kubernetes、kustomize、PostgreSQL 15 | 无（内置 SQLite） |
| 建议最小内存 | 8 GB | 512 MB |
| 建议最小 CPU | 4 核 | 1 核 |
| 单二进制安装 | ❌ | ✅ |
| Windows 支持 | ❌ | ✅ |
| 安装耗时 | 数小时 | 数分钟 |
功能对比
两者都覆盖核心流程：定义自动化、配置清单与凭据、运行任务、查看日志。下面是完整功能集的对比。
| 功能 | AWX | Semaphore UI |
|---|---|---|
| Ansible playbook | ✅ | ✅ |
| Terraform / OpenTofu | ❌（仅能通过 Ansible 模块） | ✅ 原生 |
| Bash / shell 脚本 | ❌（仅能通过 playbook） | ✅ 原生 |
| Python 脚本 | ❌（仅能通过 playbook） | ✅ 原生 |
| PowerShell | ❌ | ✅ |
| REST API | ✅ 完整 | ✅ 完整 |
| 调度 | ✅ | ✅ |
| Cron 表达式 | ✅ | ✅ |
| 清单管理 | ✅ | ✅ |
| 动态清单 | ✅（内置插件） | ✅（通过 Ansible） |
| RBAC | ✅ 细粒度 | ✅ 基于角色（4 级） |
| LDAP | ✅ | ✅ 企业版 |
| SAML | ✅ | ❌ |
| OpenID Connect / OAuth2 | ✅ | ✅（10+ 提供商） |
| 2FA（TOTP） | ❌ | ✅ Pro |
| 执行环境 | ✅（容器隔离） | ✅（Runner） |
| 分布式 Runner | ❌ | ✅（全局 + 按项目） |
| Webhook 集成 | ✅ | ✅ |
| 通知 | ✅（邮件、Slack 等） | ✅（Slack、Teams、Telegram、邮件、Rocket.Chat、Gotify） |
| 审计日志 | ✅ | ✅ |
| 高可用 | ✅ | ✅ 企业版 |
| 审批工作流 | ❌ | ✅（Terraform plan/apply） |
| Terraform HTTP 后端 | ❌ | ✅ Pro |
| HashiCorp Vault 集成 | ❌ | ✅ |
| AI 助手（MCP） | ❌ | ✅ |
| 多工具工作流 | ❌ | ✅ |
| 内置 Swagger UI | ✅ | ✅ |
| 开源许可证 | Apache 2.0 | MIT |
| 企业支持 | 通过 AAP（约每年 1.3 万美元起） | 可作为附加项购买 |
自动化范围
AWX 以 Ansible 为中心。一切都围绕运行 playbook 的作业模板。技术上可以在 playbook 里用 cloud.terraform 集合跑 Terraform，但那是集成层面的变通——Terraform 状态、工作区以及 plan/apply 审批并不是 AWX 的原生概念。
Semaphore 将 Ansible、Terraform、Bash、Python 和 PowerShell 视为一等执行类型。创建模板时选择类型，界面、变量和审批流程会相应调整。如果你用 Ansible 做配置、用 Terraform 做供给，可以在同一界面管理两者，无需绕路。
纯 Ansible 环境差别不大。对大多数会混用工具的团队来说，差别就很重要。
访问控制
两者都支持基于角色的访问控制，但实现不同。
AWX 具有对象级细粒度权限。可以单独授予用户对特定作业模板、清单或凭据的访问。审计角色可以查看一切但不能修改。RBAC 可从 LDAP 或 SAML 同步。
Semaphore 的 RBAC 以项目为范围，包含四个角色：Owner、Manager、Task Runner、Guest。Owner 和 Manager 控制配置；Task Runner 只能执行任务不能改配置；Guest 只读。这能覆盖大多数团队结构，而不会过于复杂。
若有法规对审计访问的细粒度要求，AWX 的模型更具表现力。若只需区分“配置自动化的人”和“运行自动化的人”，Semaphore 的模型足够且简单得多。
团队与组织规模
AWX 面向大型组织设计。组织、团队以及按对象的权限反映企业层级。若要在多个业务单元管理数百用户，AWX 的权限模型能提供控制力。
Semaphore 以项目作为主要隔离边界。每个项目有自己的清单、模板、密钥和团队。多团队场景下，Semaphore Pro 增加 Project Runner——按项目分配隔离的执行环境。纽约的 Runner 处理纽约基础设施，法兰克福的处理法兰克福。不同项目的任务不共享执行环境。
对人数约一百以内、项目边界清晰的团队，Semaphore 的模式好用且可维护。对企业级平台、大量团队与权限重叠的场景，AWX 的粒度或许值得承担额外开销。
维护与支持的现实
使用两者都不那么轻松。
AWX 的社区支持意味着没有 SLA、没有明确的安全承诺、没有保证的兼容性。 Red Hat 自己也表示，用 AWX 管理生产系统对企业“可能有风险”。该工具更适合理解为 Automation Controller 的开发预览，而不是有坚实社区后盾的生产级平台。出问题只能靠自己。
当前发布暂停又增加不确定性。自 2024 年 7 月以来没有新版本，意味着超过 18 个月没有 bug 修复、安全补丁和新功能。若今天在生产环境运行 AWX，你运行的是没有积极维护的软件。
Semaphore 的社区支持同样是社区支持，但项目仍在积极开发、频繁发布。Pro 和企业层提供带 SLA 的付费支持（标准 12 小时，另有紧急选项）。若需要保证响应时间，这条路存在。
两者都不会免费提供 Red Hat 级别的企业保障。区别在于 Semaphore 仍在推进，并有清晰的付费支持路径；AWX 处于停滞，且低于 AAP 价位几乎没有商业选项。
何时适合 AWX
在以下情况 AWX 更合适：
- 你已经在运行 Kubernetes，运维成本已摊入平台。
- 需要 SAML 认证——这是 Semaphore 目前不支持的协议。
- 自动化 100% 是 Ansible，且想要最终成为 AAP 的那套东西的上游版本。
- 正在评估 AAP，想在签商业合同前熟悉界面。
- 需要对象级 RBAC——能授予特定 playbook 的访问权，而不给整个项目级权限。
- 计划迁移到 AAP，并希望配置可移植（AWX 与 AAP 共享同一数据模型）。
何时适合 Semaphore UI
在以下情况 Semaphore 更合适：
- 你不运行 Kubernetes（或不想仅为 Ansible UI 去跑它）。
- 你不只用 Ansible——Terraform、Bash、Python、PowerShell 或 OpenTofu 也是栈的一部分。
- 硬件资源紧张——1 CPU、1GB 内存的虚拟机就够。
- 需要 Windows 支持——Semaphore 原生支持 Windows；AWX 不支持。
- 团队里有非技术用户，需要在不碰 CLI 的情况下运行自动化。
- 因成本替换 AAP 或 Tower——Semaphore Pro 约每月 15 美元，而 AAP 约每年 1.3 万美元。
- 需要 Terraform HTTP 后端——Semaphore Pro 原生提供。
- 希望维护可预期——活跃发布、清晰路线图，以及无需五位数承诺的付费支持。
成本现实
AWX 免费，但并非零成本。Kubernetes 增加基础设施复杂度和运维负担。若你原本没有集群，仅为 AWX 搭建集群会在工程时间和云资源上产生真实成本。
Semaphore 的开源层是真正免费的，除小型虚拟机或容器外几乎没有额外基础设施开销。Pro 计划约每月 15 美元起。企业版为定制定价，但仍与 AAP 的起价不在同一量级。
若 Semaphore Pro 的替代方案是 Ansible Automation Platform，账很好算。即便 Semaphore 企业版，也只是 AAP 许可成本的一小部分。
总结
AWX 和 Semaphore UI 都是认真的开源项目。都不是空头产品，两者都有真实生产部署。选择取决于你的约束。
选 AWX，若你已投入 Kubernetes、需要 SAML，或走向 AAP。
选 Semaphore UI，若你想要十分钟内装好、不止 Ansible、且仍在积极维护并有清晰支持路径的方案。
若你正在评估 AWX，并对 Kubernetes 要求或安装复杂度感到阻力——这种阻力是真实的，不是能力问题。在拍板前，值得与 Semaphore 做一次直接对比。
