自托管工单系统选型指南：FreeScout、Zammad 与 GLPI 对比

选择自托管服务台系统的四个关键问题

自托管服务台系统安装简单，但选型困难，因为该类别的需求通常非常具体。通过回答以下四个问题，可以将约二十个候选项目筛选至一到两个。在查看任何功能页面之前，请先确定这些答案。

• 邮件是否必须自动转换为工单，还是用户会使用网页表单并登录系统？
• 这是面向客户的外部支持，还是针对笔记本电脑或服务器等资产的内部 IT 服务台？
• 预计会有多少坐席登录系统？两人规模与二十人规模的产品需求完全不同。
• 是否需要服务等级协议 (SLA) 计时器、资产记录、公共知识库或审批流程？

以下各节将按此顺序展开。产品列表放在最后，因为产品本身是您在此决策中最不重要的环节。

邮件必须转换为工单吗？

如果答案是肯定的，那么无论安装哪种系统，电子邮件都是主要集成方式，而且它分为两个部分，故障表现各不相同。

入站：实际创建工单的部分

本文介绍的几乎所有选项，都会通过 IMAP（互联网消息访问协议）或 POP3（邮局协议）从您已经拥有的邮箱中读取邮件。帮助台会像普通邮件客户端一样登录邮箱，并按定时任务轮询。邮件不会主动推送到帮助台，因此定时任务停止后，工单也会停止创建，而客户完全看不到错误。Request Tracker 是例外：其安装指南只记录了在您自己的邮件服务器上配置别名，并将每封邮件通过管道传入 rt-mailgate。因此，如果要读取邮件服务商提供的邮箱，就需要在前面运行 fetchmail 等抓取程序，而这个抓取程序就是需要监控的定时任务。

osTicket 会明确显示这一机制。您可以在管理面板中为每个邮件账户设置抓取频率，但仅启用抓取功能还不够。轮询程序位于 api/cron.php 中，文档建议配置一条运行该程序的 crontab，通常每五分钟运行一次。内置的替代方案 auto-cron 只有在已登录的客服人员使用 Web 界面时才会触发，因此在安静的周末，如果没有人登录，就不会抓取任何邮件。

GLPI 将同一项工作拆分为两个部分。接收器是 GLPI 对邮件收集器的称呼，用于保存邮箱凭据；mailgate 自动操作则决定收集运行的频率。当工单停止出现时，应先检查该自动操作，再检查邮箱。Zammad 会根据其渠道配置，通过 IMAP 或 POP3 抓取邮件。在自托管服务器上，也可以使用 fetchmail，将每封邮件通过管道传入 Zammad 自己的邮件驱动程序。其 Sendmail 选项仅用于发送邮件，因此没有文档记录的入站邮件服务器管道。

线程关联是下一个容易出问题的环节。客户回复必须进入现有工单，而不能创建第二个工单。邮件线程依赖 Message-ID、In-Reply-To 和 References 标头；帮助台还会将工单引用添加到主题行作为备用机制。因此，支持邮件的主题中通常会出现类似 [#123456] 的内容。如果为了让邮件更整洁而从外发模板中删除该标记，每封回复都会作为新工单返回。

自动回复是最后一个问题。您的帮助台会向每封新邮件发送确认消息。如果它回复的地址本身也是自动回复程序，两个系统可能会持续循环，直到有人停止其中一个。RFC 3834 定义了 Auto-Submitted: auto-replied 标头，使自动回复程序能够相互识别并保持静默；规范实现通常会设置该标头。在将帮助台指向会转发到邮件列表的别名之前，应先使用真实邮箱进行测试。

出站：决定回复能否送达的部分

入站问题很明显，因为不会出现工单。出站问题则不可见：回复已经发送，客服人员关闭了工单，但客户始终收不到。您的工单系统会使用您的域名发送邮件，因此该域名必须授权它发送邮件。

域名需要配置 SPF（发件人策略框架）记录，列出所有发送邮件的来源。还需要配置 DKIM（域名密钥识别邮件）签名，以及一个 DMARC（基于域名的消息认证、报告和一致性）记录，其策略必须与两者保持一致。在安装任何系统之前，先检查当前已发布的记录：

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

第一条命令应输出以 v=spf1 开头的行。第二条命令应输出以 v=DMARC1 开头的行。第三条命令只会查询签名程序使用的选择器名称，因此如果结果为空，通常表示查询了错误的选择器，而不是 DKIM 缺失。

直接从 VPS 发送邮件时，问题通常会在这里出现。新 IP 地址没有发送信誉，许多主机商还会默认关闭出站 25 端口，直到您请求开放该端口。应改为通过邮件服务商中继。这与服务器上其他服务面临的决定相同：让自托管应用发出邮件且不被判定为垃圾邮件介绍了如何为所有服务统一完成配置。如果您还希望自行管理邮箱，在 VPS 上部署 Mailcow 邮件服务器可以提供帮助台轮询的收件箱，但这项工作比部署帮助台本身更复杂。

客户支持还是内部 IT 服务台？

这两种数据模型虽然界面相似，但本质不同，且这种差异决定了您的选型范围。

在客户支持场景中，请求者是一个电子邮件地址。身份验证较弱，请求量波动大，成功的标志是回复送达至从不登录您系统的用户。Web 表单、预设回复和按部门划分的队列是此类工具的核心，而资产管理则无关紧要。

在内部服务台场景中，请求者是员工，通常通过 LDAP（轻量级目录访问协议）从目录服务中同步。工单会关联到具体对象：如笔记本电脑、软件许可或虚拟机。这些对象存在于 CMDB（配置管理数据库）或库存系统中，该类工具的一半价值在于能够追踪哪些工单涉及了哪些设备。

GLPI 和 iTop 是为第二种模型构建的。FreeScout 和 osTicket 是为第一种模型构建的。Zammad 能够很好地支持客户支持，也可以在没有资产记录的情况下运行内部服务台。在选型时跨越这一界限是此类项目中代价高昂的错误，因为数据模型是无法轻易迁移的部分，而界面主题则可以。

预计会有多少坐席登录？

本文不按坐席数量收费，因此坐席数不会影响账单。它决定了你在处理首个工单前需要构建多少基础架构。

当坐席数量为 2 人时，架构往往是问题而非解决方案。你需要的是共享邮箱视图、任务归属标记以及可搜索的历史记录。FreeScout 完全符合这些需求。如果客户通过网站表单提交工单，osTicket 也是合适的选择。

当坐席数量达到 10 或 20 人时，你需要队列或部门划分、分配规则、权限级别以及能显示工作积压情况的报表。osTicket、Zammad 和 GLPI 都具备这些功能。配置这些功能需要一天的工作量；如果跳过配置，就会出现常见故障：所有工单堆积在同一个队列中，且无人负责。

是否需要 SLA、资产管理、知识库或审批流程？

请逐一评估这些需求，因为每增加一项功能，可选方案的范围都会缩小。

SLA 时钟用于根据目标衡量响应和解决时间，因此需要配置工作时间、优先级方案和升级路径。osTicket 自带 SLA 计划，Zammad 也提供 SLA 功能，而 GLPI 和 iTop 则将服务级别管理作为其模型的核心组成部分。

资产追踪功能首选 GLPI 或 iTop。GLPI 在服务台旁边内置了机器清单。iTop 是一个以工单系统为基础的 CMDB，如果你的核心需求是管理服务与硬件之间的关联，iTop 是最佳选择。Znuny 和 OTOBO 可以通过其 ITSM 软件包扩展 CMDB 功能。

知识库功能很常见，但并非所有系统都具备。Zammad 内置了知识库，需由管理员手动启用。osTicket 提供 FAQ 功能。GLPI 的知识库与服务台深度集成。FreeScout 则将知识库作为付费模块提供。

审批步骤和变更管理属于较小众的功能，主要由 iTop 和 OTRS 的衍生版本提供。如果某项工作必须在获得授权后才能开始，请优先考虑这些系统，并接受其随之带来的额外复杂度。

在线聊天与工单是不同的工作模式

如果您需要的是一个带有网站在线聊天功能的共享收件箱，请停止阅读工单系统的对比，直接参考 将 Chatwoot 作为您的支持中心。

两者的区别在于状态机。Chatwoot 会话是一串关联了特定人员的消息流，旨在跨多个渠道快速响应。工单则是一个包含状态、负责人、队列、截止时间和历史记录的记录项，可用于生成报表，旨在处理周期长于单次会话的工作。例如，耗时四天的硬件更换流程属于工单工作；而在 90 秒内回答“我的订单在哪里”则属于聊天工作。

许多团队希望两者兼得。同时运行两者意味着需要管理两个收件箱和两套通知，因此请选择符合您大部分业务量的模式，并将另一个渠道通过电子邮件接入。

值得考虑的选项

FreeScout：类似帮助台的共享收件箱

采用 AGPL-3.0 许可，使用 Laravel 框架以 PHP 编写，并持续发布新版本：1.8.247 于 10 October 2026 发布。其文档说明没有最低 CPU 或 RAM 要求，并且可以运行在共享主机上。核心功能免费，代理和工单数量不限；知识库、工作流、实时聊天、标签等一系列扩展功能则作为付费模块提供，按单个实例一次性购买永久许可。邮件是主要渠道且团队规模较小时，可以选择它。

osTicket：经典的表单和队列工单系统

采用 GPL-2.0 许可，支持 PHP 8.2 至 8.4 和 MySQL。1.18.4 版本于 June 2026 发布，因此维护节奏稳定但较慢。它提供部门、帮助主题、自定义表单、预设回复和 SLA 计划。界面风格较为陈旧。客户通过表单提交工单、需要传统队列，并且服务器成本较低时，可以选择它。

Zammad：功能完整的帮助台，但需要更多 RAM

采用 AGPL-3.0 许可，基于 Ruby on Rails 开发，7.2 系列自 23 September 2026 起为当前版本。自托管软件可免费运行。Zammad 定价页面上的订阅属于支持合同，截至 October 2026，Business 层级起价为每年 2,999 euros。Zammad 自己的硬件要求页面建议使用 2 个 CPU 核心和 6 GB RAM；如果 Elasticsearch 与其运行在同一台服务器上，还需额外 4 GB。Elasticsearch 是可选组件，但它可以加快跨多年历史工单的搜索。工单量较大、渠道较多，并且服务器能够承担其资源需求时，可以选择 Zammad。

GLPI：集成资产清单的 IT 服务台

采用 GPL-3.0 许可。12.0.0 版本于 7 October 2026 发布，要求 PHP 8.3 或更高版本。11.0 系列仍在获取补丁，11.0.11 于 1 October 2026 发布；该系列支持 PHP 8.2 或更高版本，以及 MySQL 8.0 或 MariaDB 10.6 及更高版本。邮件通过接收器和 mailgate 自动操作转换为工单，路由规则可以将消息发送到不同实体。GLPI 通过实体为同一安装实例中的不同站点或客户组织建模。内部 IT 场景中，资产清单与工单队列同样重要时，可以选择它。

iTop：在 CMDB 之上提供工单管理

采用 AGPL-3.0 许可，当前版本为 3.3.0，于 15 September 2026 发布。其 sizing guidance 对少于 200 个每月工单且少于 20 个控制台用户的环境，最低建议使用 4 GB RAM；当每月工单数达到 5,000 个时，建议使用 8 GB RAM。需要对服务、合同和影响进行建模，而工单只是整体管理内容中较小的一部分时，可以选择它。

Znuny 和 OTOBO：仍在维护的 OTRS 分支

两者都源自 OTRS Community Edition。该版本已于 December 2020 末停止生命周期。Znuny 采用 GPL-3.0 许可，继续维护 6.0.30 代码库，目前处于 7.3 系列。OTOBO 采用 GPL-3.0 许可，于 2019 年分叉，目前处于 11.0 系列。两者都使用 Perl，都遵循 ITIL 实践，并且资源占用较高：OTOBO 文档要求生产机器提供 8 GB RAM 和 40 GB 存储，并建议使用 16 GB。需要流程自动化和面向服务组织设计的工单模型，并且团队中有人熟悉 Perl 时，可以选择其中一个。

另外两个值得了解的选项

Request Tracker 采用 GPL-2.0 许可并使用 Perl，于 May 2026 发布 6.0.3。邮件是其原生界面，而不是后加的功能，因此它仍然适合邮件驱动的队列。Frappe Helpdesk 采用 AGPL-3.0 许可，于 October 2026 发布 1.30.2，提供这里最现代的界面，并支持 SLA 和知识库；但你需要同时部署完整的 Frappe 技术栈，包括 Redis 和与数据库并行运行的后台工作进程。

小型 VPS 需要满足什么条件

这些公开的最低要求是可靠的起点。这些数字来自项目自身，不是我的测量结果。

[
  {
    "tool": "OTOBO 11",
    "min_ram_gb": 8,
    "notes": "production minimum, 16 GB recommended, 4 GB for a test box"
  },
  {
    "tool": "Zammad 7",
    "min_ram_gb": 6,
    "notes": "add 4 GB more to run Elasticsearch on the same server"
  },
  {
    "tool": "iTop 3.3",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

将这 3 个数字视为最低限度，而不是目标值，因为每个数字都假设工单量不高。RAM 也只是其中一半。这里的每个选项都需要数据库，而数据库还需要单独的内存预算。因此，运行 Zammad 的 4 GB 服务器，实际上还要同时运行 Zammad、PostgreSQL 以及你部署的其他组件。

FreeScout 和 osTicket 完全没有公布 RAM 最低要求。这不是营销说法。它们只是通过 MySQL 运行的普通 PHP 应用，因此其最低要求由 PHP 和数据库决定，而不是由帮助台应用本身决定；这个最低要求远低于上面的数字。应改为检查磁盘空间：附件增长速度往往超出预期，因为客户会发送屏幕截图。

如何判断项目是否仍在维护？

在查看功能列表前请先确认这一点。如果一个存放客户数据的帮助台项目已停止维护，由此产生的安全隐患是无法通过配置解决的。

• 查看仓库中的许可证文件，不要只看营销页面。UVdesk 的社区版采用 OSL-3.0 许可证，大多数团队并未评估过该协议的合规性，且其上一个版本 v1.1.8 发布于 2025 年 9 月。
• 查看最新版本的发布日期，而非最新提交记录。提交记录可能仅是 README 中的拼写修正。
• 检查仓库是否已归档。Peppermint 是一个常出现在各类推荐列表中的开源帮助台项目，但其所有者已于 2026 年 7 月 17 日将其归档，其最后一个版本 0.5.5 发布于 2024 年 11 月。归档后的仓库为只读状态，这意味着不会再有任何安全补丁发布。
• 如果项目是从已停止维护的项目分支而来，请检查该分支是否活跃。Znuny 和 OTOBO 均处于活跃状态，且在 2026 年内均有版本发布。

何时不应自托管

请客观评估团队规模。如果只有两人每天处理少量消息，则无需使用工单系统。你们只需要一个共享邮箱、标签功能，以及关于分工的约定。引入工单系统会增加需要备份的数据库、可能静默失效的邮件集成，以及需要持续打补丁的应用程序，且它本身不会帮你处理任何工单。

仅在有明确理由时进行自托管：例如数据必须保留在你控制的基础设施内，或者按坐席计费的成本已成为工具预算中最大的支出。需要定制化功能也是合理的理由。这些都是充分的理由，上述工具本身也确实优秀。

不要仅因小规模下的成本考虑而选择自托管。工单系统存储着客户姓名、地址、订单详情和投诉历史，因此补丁更新是必须的，且备份必须经过至少一次恢复测试才算有效。你所反感的托管服务费用中，包含了邮件送达率保障、系统升级以及他人的值班响应。对于两个坐席的团队，这通常是更划算的交易，且当工单队列增长时，随时可以重新评估这一决策。

您所承担的工作

在安装前规划好备份。您需要备份数据库和附件目录，并需在备用服务器上完整恢复一次，以确保备份有效。

使用 Compose 运行服务，这样升级只需修改版本号并重启即可。如果您不熟悉 Compose，VPS 的 Docker Compose 基础知识涵盖了文件布局及卷的命名方式。请将数据库存放在命名卷中，而非容器内部，否则升级操作会连同工单数据一并删除。

监控邮件获取程序，因为该组件往往会在静默状态下失效。未送达的工单不会触发警报，最初的迹象通常是客户因无人回复而感到不满。请每周通过支持邮箱发送一封邮件，并确认其已成功接收。更好的做法是设置警报：当获取任务停止时，向您的手机推送通知比无人查看的仪表板更有效。

最后，分析工单的内容。当大多数工单是不同用户提出的相同问题时，您自行托管的论坛可以一次性公开解答。当大多数工单涉及付款和日期时，完善的记录系统可能比客服系统更能解决问题，此时自托管发票工具会是更合适的选择。

FAQ

我可以在 2 GB VPS 上运行自托管帮助台吗？

可以，前提是选择 PHP 应用。FreeScout 文档说明没有最低 CPU 或 RAM 要求，osTicket 也未公布相关要求，因此最低配置取决于 PHP 和 MySQL 在你的服务器上所需的资源。Zammad 和 OTOBO 则相反：它们各自的文档要求在添加 Elasticsearch 之前，至少需要 6 GB 和 8 GB RAM。为这两个应用分别准备独立服务器。

要将电子邮件转换为工单，我需要自己的邮件服务器吗？

不需要。这里几乎所有选项都可以通过 IMAP 或 POP3 登录你已有的邮箱，并通过 SMTP 发送回复。Request Tracker 要求将邮件通过管道传入，因此需要在它与邮箱之间配置 fetchmail 等获取工具。使用当前邮件服务商提供的邮箱即可。你需要为发件地址配置授权：为所有邮件中继配置 SPF 记录、启用 DKIM 签名，并配置与两者一致的 DMARC 记录。缺少这些配置时，回复可能会被归入垃圾邮件，而在你的界面中工单看起来像是已经回复，客户却未必能收到。

我应该使用 Chatwoot 还是工单系统？

当工作内容是对话时，使用 Chatwoot：例如网站实时聊天、社交渠道，以及需要在几分钟内处理的共享收件箱。当工作需要状态、负责人和截止时间，并且生命周期超出最初发起工作的对话时，使用工单系统。升级、审批和 SLA 计时都适合放在工单中。如果两者都需要，先选择与大部分进入流量匹配的系统，再通过电子邮件将另一个渠道路由到该系统。

如何确认某个帮助台项目仍在维护？

打开代码仓库，查看最新版本的发布日期，然后确认仓库未被归档。Peppermint 的所有者在 July 2026 将其归档，最后一个版本发布于 November 2024；归档后的仓库为只读状态，因此不会再有安全修复。随后直接阅读仓库中的许可证文件，不要只看网站声明的许可证，因为这里的一些项目使用的条款可能是你以前未审核过的，例如 UVdesk 的 OSL-3.0。

小型团队默认应选择哪个？

如果使用电子邮件作为渠道且代理人数少于 5 人，先选择 FreeScout，因为它资源占用低、发布频繁，也符合小团队现有的工作方式。如果客户应通过表单创建工单，并且你希望在较少 RAM 下使用部门和 SLA 计划，先选择 osTicket。如果工单涉及公司硬件，选择 GLPI，让资产清单和工单队列集中在同一处。