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

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

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

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

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

邮件必须转化为工单吗？

如果答案是肯定的，那么电子邮件就是你所安装系统中的核心集成部分。它包含两个部分，且各自会以不同的方式失效。

入口：工单的实际创建过程

本文提到的所有方案都通过 IMAP (Internet Message Access Protocol) 或 POP3 (Post Office Protocol) 从你现有的邮箱中读取邮件。工单系统像普通邮件客户端一样登录并定时轮询。没有任何机制会将邮件主动推送到系统中，因此一旦定时器停止，工单创建就会中断，而客户不会收到任何错误提示。

osTicket 将这一机制显性化。你在管理面板中为每个邮件账户设置抓取频率，但仅开启抓取是不够的。轮询程序位于 api/cron.php 中，文档建议通过 crontab 条目运行，通常设置为每五分钟一次。内置的 auto-cron 选项仅在有客服人员登录 Web 界面时才会触发，因此在安静的周末，除非有人登录，否则不会抓取任何邮件。

GLPI 将此任务一分为二。接收器（即 GLPI 对邮件收集器的称呼）保存邮箱凭据，而 mailgate 自动操作决定了收集的频率。当工单不再生成时，请先检查该自动操作，再检查邮箱本身。Zammad 通过其通道配置进行 IMAP 或 POP3 抓取，在自托管环境中，它也可以通过 fetchmail 或 sendmail 管道接收邮件。

邮件线程是另一个陷阱。客户的回复必须归入现有工单，而不是开启第二个工单。邮件线程依赖 Message-ID、In-Reply-To 和 References 头部信息，而工单系统会将工单引用添加到主题行作为后备方案，这就是为什么支持邮件的主题中会出现类似 [#123456] 的内容。如果你从外发模板中删除了该令牌，邮件看起来会更整洁，但所有回复都会变成新工单。

自动回复是最后一个问题。你的工单系统会向每条新消息发送确认回执。如果它回复的地址本身也是一个自动回复器，两者可能会陷入循环，直到其中一方停止。RFC 3834 定义了 Auto-Submitted: auto-replied 头部，以便自动回复器能够识别彼此并保持静默，表现良好的系统都会设置该头部。在将工单系统指向一个转发到列表的别名之前，请先用真实的邮箱进行测试。

出口：决定回复是否送达的关键

入口问题是可见的，因为工单不会出现。出口问题则是隐蔽的：回复已发送，客服关闭了工单，但客户从未收到。你的工单系统以你的域名身份发送邮件，因此该域名必须授权此行为。

该域名需要一条 SPF (Sender Policy Framework) 记录，列出所有发送邮件的来源。它还需要 DKIM (DomainKeys Identified Mail) 签名，以及一条与前两者策略一致的 DMARC (Domain-based Message Authentication, Reporting and Conformance) 记录。在安装任何软件之前，请检查当前的发布记录：

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.236 版本于 2026 年 8 月 24 日发布。其文档说明没有最低 CPU 或 RAM 要求，且可在共享主机上运行。核心功能免费，支持无限数量的坐席和工单，而知识库、工作流、在线聊天、标签等大量扩展功能则作为付费模块，以单实例一次性买断授权的形式销售。当以邮件为主要渠道且团队规模较小时，请选择此方案。

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

采用 GPL-2.0 许可，支持 PHP 8.2 至 8.4，使用 MySQL。1.18.4 版本于 2026 年 6 月发布，维护节奏缓慢而稳定。该系统提供部门、帮助主题、自定义表单、预设回复和 SLA 计划等功能。界面风格较为陈旧。当客户通过表单提交工单、你需要传统的队列管理且服务器资源有限时，请选择此方案。

Zammad：功能完备的服务台，但对 RAM 有要求

采用 AGPL-3.0 许可，基于 Ruby on Rails，2026 年 8 月时 7.1 系列为当前版本。自托管版本可免费运行。Zammad 定价页面上的订阅属于支持合同，截至 2026 年 8 月，Business 级别起价为每年 2,999 欧元。Zammad 官方硬件建议要求双核 CPU 和 6 GB RAM，如果 Elasticsearch 运行在同一台服务器上，则需额外增加 4 GB。Elasticsearch 为可选组件，它也是实现多年历史工单快速搜索的关键。当你有实际业务量、多个渠道且服务器性能足以支撑时，请选择 Zammad。

GLPI：附带资产清单的 IT 服务台

采用 GPL-3.0 许可，支持 PHP 8.2 或更高版本、MySQL 8.0 或 MariaDB 10.6 及以上版本，11.0.8 版本于 2026 年 6 月发布。通过接收器和 mailgate 自动操作，邮件可转换为工单；路由规则可将消息分发到不同的实体，GLPI 正是通过这种方式在单个安装实例中对不同站点或客户组织进行建模。当内部 IT 部门对资产清单的重视程度不亚于工单队列时，请选择此方案。

iTop：以工单为基础的 CMDB

采用 AGPL-3.0 许可，当前版本为 2026 年 8 月发布的 3.2.3-2。其官方规模建议指出，对于每月少于 200 个工单且控制台用户少于 20 人的场景，最低需 4 GB RAM；对于每月多达 5,000 个工单的场景，则需 8 GB RAM。当你需要对服务、合同和影响范围进行建模，且工单仅是其中一小部分时，请选择此方案。

Znuny 和 OTOBO：仍在维护的 OTRS 系列

两者均源自 OTRS Community Edition，该版本已于 2020 年 12 月底停止支持。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 RAM。当你需要流程自动化、且工单模型专为服务型组织设计，同时团队中有熟悉 Perl 的成员时，请选择其中之一。

另外两个值得了解的方案

Request Tracker (GPL-2.0, Perl) 于 2026 年 5 月发布了 6.0.3 版本，其原生界面即为电子邮件，而非插件，这使其非常适合邮件驱动的队列管理。Frappe Helpdesk (AGPL-3.0) 于 2026 年 8 月发布了 1.29.0 版本，拥有此处介绍的方案中最现代化的界面，并支持 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.2",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

请将这些 3 数值视为底线而非目标，因为每个数值都基于适度的工单处理量。内存并非全部。此处每个选项都需要数据库，而数据库需要独立的内存预算，因此运行 Zammad 的 4 GB 服务器实际上是在同时运行 Zammad、PostgreSQL 以及你部署的其他任何程序。

FreeScout 和 osTicket 没有发布最低内存要求。这并非营销手段。它们是与 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 或内存要求，osTicket 也没有发布相关要求，因此底线取决于 PHP 和 MySQL 在你服务器上的实际需求。Zammad 和 OTOBO 则相反：它们的文档要求在添加 Elasticsearch 之前，分别需要 6 GB 和 8 GB 的内存。请为这两个应用单独准备一台服务器。

我需要自建邮件服务器来将邮件转换为工单吗？

不需要。此处提到的所有选项都会通过 IMAP 或 POP3 登录你现有的邮箱，并通过 SMTP 发送回复。使用当前服务商提供的邮箱即可。你需要做的是为发送地址配置授权：包含邮件中继服务器的 SPF 记录、DKIM 签名，以及与前两者一致的 DMARC 记录。否则，回复会被标记为垃圾邮件，导致你在界面上看到工单已回复，但对方并未收到。

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

当工作内容以对话为主时，请使用 Chatwoot：例如网站实时聊天、社交渠道或需要在几分钟内回复的共享收件箱。当工作内容涉及状态、负责人和截止时间，且其生命周期长于发起对话的沟通时，请使用工单系统。升级流程、审批和 SLA 计时器属于工单系统的范畴。如果两者都适用，请从处理主要业务量的系统开始，并通过邮件将另一个渠道的流量路由到该系统中。

如何检查服务台项目是否仍在维护？

打开代码仓库并查看最新发布的日期，确认仓库未被归档。Peppermint 已于 2026 年 7 月被所有者归档，其最后一次发布是在 2024 年 11 月；归档后的仓库为只读状态，因此不会再有安全更新。此外，请阅读仓库中的许可证文件，而不是仅参考网站上声明的许可证，因为此处的部分项目使用了你可能尚未评估的条款，例如 UVdesk 使用的 OSL-3.0。

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

如果主要渠道是电子邮件且客服人员少于 5 人，请从 FreeScout 开始，因为它轻量、更新频繁，且符合小型团队现有的工作方式。如果客户需要通过表单提交工单，且你希望在低内存占用下实现部门管理和 SLA 计划，请从 osTicket 开始。如果工单涉及公司硬件，请从 GLPI 开始，以便将资产清单和工单队列统一管理。