如何借助 ManageEngine 让服务台的 AI 和 Token 成本可预期

SaaS 通胀（SaaSflation）。

这个说法确实存在。您或许是第一次听说，但只要使用过云软件，就不会对它描述的现象感到陌生：没有新增许可证，也没有升级版本，同一套软件的费用却逐年上涨。续费报价不断走高，产品版本和收费档位悄然调整，部署内容毫无变化，变化的只有账单上的最终金额。

这一问题本就日益突出，而近年 AI 的快速发展，又为 SaaS 厂商提供了更容易被接受的涨价理由。与此同时，企业也面临尽快采用 AI 的压力。按席位收费的固定订阅模式，正逐步让位于按用量计价的方式；AI 附加功能、按量计费条款和版本升级费用，也越来越多地出现在续费报价单中。

IT 服务管理（ITSM）平台正是费用容易攀升的领域之一。它处于 IT 运营核心，关联组织内的每个团队，承担的工作又恰好是 AI 所擅长的——AI 理应在这类平台上被充分使用，但这也让它在按用量计费时往往支出最高。

ManageEngine ServiceDesk Plus 的设计理念与此不同。选用 ServiceDesk Plus 管理服务台后，以下五个方面将不再是您的困扰。

一、无论使用哪个版本 都能利用 AI 提升服务管理

某些不愿透露名字的厂商：当 AI 被单独售卖时，所谓“AI 驱动的 ITSM”便是这副模样。

不少 ITSM 厂商将 AI 作为付费附加功能，甚至要求先将整体部署升级到高级版本，才能购买这项功能。结果，您本只想获得其中某一项能力，却不得不为一整套用不上的功能买单——这些功能既非团队提出的需求，也大概率永远不会用到。

在 ServiceDesk Plus 中，从标准版起，无论席位多少，都可使用预测式、生成式和对话式 AI；企业版还提供 Zia Agents 智能体，AI 本身无需额外付费。AI 能力覆盖产品全流程，企业中的各类角色都能在日常工作中用到它：终端用户可通过对话式 AI 助手 Ask Zia 实现自助服务；技术人员可按需生成问题解决方案；流程负责人可使用智能事件聚类功能；管理员则可通过仪表板获得全面的可观测性，查看 AI 用量情况。

您可以在这里查看各版本提供的功能。

二、AI 账单不会随用量波动 后台也不会悄悄累积费用

AI 的普及让许多 SaaS 产品从固定订阅转向按用量计费。在 ITSM 领域，这种费用波动往往以某种消耗单位呈现，而这些单位往往并非您能直接掌控的因素。如今，不少 ITSM 厂商按会话次数、额度或辅助操作次数来计量 AI 用量，这些额度的消耗并不完全在服务台经理的掌控之中。

更重要的是，您付费购买的并非结果，而是一次次尝试——无论成功与否，每次尝试都会消耗 Token（词元）。面对数据混乱的配置管理数据库（CMDB），智能体并不会在失败后就停下，而是会重试、循环，或将任务转交给更高层级处理，每一步都和成功解决问题时一样，消耗着同一个额度池。于是额度在后台悄悄减少，账单也随之逐步增加。

若您使用 ManageEngine 托管的大语言模型（LLM）来驱动 ServiceDesk Plus 的 AI 功能和预置智能体，就不会遇到这类问题。我们的大语言模型基于 Qwen、GLM 等开源基础模型构建，由我们自行托管和运行，使用过程中不会持续产生按量费用，后台也不会累积额外开销。

三、每项功能和每个智能体都能分别选择模型 无需被单一 AI 供应商锁定

能提供模型选择的平台并不少，但区别在于这种选择能细化到什么程度、又有多灵活。有些 ITSM 平台虽自行托管模型，却不允许您决定由哪个模型为服务台提供支持；有些平台支持自带密钥（BYOK），但同一时间只能接入一家供应商的模型。即便允许使用客户自带密钥，这一设置通常也只能应用于整个平台，无法按功能分别配置。

这一区别的影响比表面看起来更大。全局设置意味着一次选择就决定了服务台中所有 AI 交互所用的模型，无法按实际需要逐项调整；而这些平台几乎都仍按用量计费，因此更换供应商只是换了收款方——您依然要按消耗单位付费，只是钱付给了谁不同而已。

ServiceDesk Plus 则以不按用量计费为基础：默认使用我们托管的 ManageEngine 大语言模型，使用过程中不会产生按量费用；若您的组织已订阅信赖的 AI 供应商，也可通过自带密钥（BYOK）接入平台。更重要的是，ServiceDesk Plus 支持为每项 AI 功能、每个智能体分别指定模型，无需采用统一的平台级设置。这样一来，整个服务台无需争抢同一个 Token 额度池，您可以逐项判断哪些功能值得投入费用。

具体来说，您可以把大量日常工作交给使用我们托管模型的预置智能体处理，再把前沿模型留给真正值得为之付费的场景。

这是在真正放大价值，而不是一味堆高 Token 消耗。

除 Zia Agents 外，ServiceDesk Plus 还支持模型上下文协议（MCP）。通过 Zoho MCP，超过 90 项 ServiceDesk Plus 操作被开放为 MCP 工具，涵盖读取工单、创建请求、添加备注、审批变更等场景。因此，如果您的组织已统一采用某套智能体生态——无论是 Microsoft Copilot，还是 Claude 这样的 LLM 客户端——都可以直接在服务台中协同工作，无需等待我们另行开发对应方案。您既不会被我们的模型锁定，也不会被我们的智能体锁定。

借助 Zoho MCP，您可以将 ServiceDesk Plus 与自己选用的大语言模型及 AI 智能体平台连接起来，按自己的方式开展 ITSM 工作。

进一步了解 →

四、使用 ManageEngine 托管模型 无需将数据交给第三方 AI 服务商

服务台中保存着组织内一些最敏感的数据，例如访问权限申请、员工离职记录和安全事件。引入 AI 后，这些上下文信息需要被送往某处处理，而向您销售产品的厂商，往往并非实际处理数据的那一方。

这种安排本身未必有问题，但当您的数据驻留承诺、安全审查和事件响应，都依赖于一家并非由您选择、也无法由您直接审计的第三方时，问题便随之出现。真正值得追问的是：AI 运行在谁的基础设施上？您的数据是否跨越了未被事先告知的地理边界？模型是否会用平台中保存的数据进行训练？而不只是泛泛地问一句“AI 是否安全”。

在 ServiceDesk Plus 中，选用我们的原生大语言模型，可确保数据仅用于模型推理，不会被用于训练模型，整个处理链路也不会有第三方 AI 服务商介入。

此外，我们还提供 Platform AI——位于平台与 AI 模型之间的网关层。任何请求在到达大语言模型之前，Platform AI 都会对可识别个人身份的信息（PII）进行匿名化处理，并对敏感字段加以遮蔽，确保大语言模型只接收到完成任务所需的信息。当您接入自行选择的 AI 供应商时，这一机制尤为重要：此时数据交接虽由您主动决定，采用的是您协商好的条款，对方也经过安全团队审核，但网关层依然在发挥作用——即便使用第三方模型，对方也无法看到敏感的用户数据。

通过 AI 网关层处理数据时的数据流

五、AI 无需作为黑箱运行

到了编制预算的时候，您会被问到：AI 用量主要花在哪里，哪项功能消耗最多，六个月前启用的某项功能是否仍在创造应有的价值。引入智能体后，这些问题变得更加重要，因为智能体执行的是实际操作，而不只是提供建议。因此，您不仅需要掌握 Token 消耗情况，还需要了解智能体执行的每一项操作。

ServiceDesk Plus 的可观测性具体体现在以下方面。

Zia 仪表板按功能细分用量，让您清楚看到哪些功能正被实际使用，而不只是已经启用，同时还能查看成功率和 Token 消耗情况；它还会按供应商区分用量，对比我们原生托管的大语言模型与第三方模型的使用情况。这样一来，模型选择不再依赖猜测，而是能基于可衡量的数据作出决定，并据此采取行动。

对于智能体，每次 Zia 智能体会话都会留下逐步记录的时间线，涵盖工具调用、大语言模型调用、Token 用量，以及每项决策背后的推理依据。遇到需要解释的情况，可直接追溯操作过程，无需凭猜测推断原因；大语言模型每执行一项操作，系统都会同步生成相应的审计记录。

Zia Agents 用量分析

ServiceDesk Plus 基础 AI 功能用量分析

避免陷入 AI 投资回报的两难境地

在 ITSM 中，每一项关于采用 AI 的商业论证，都以实际使用为前提。无论是减少人工处理的工单量，还是缩短解决时间，用来证明采购合理性的指标都取决于 AI 是否被充分使用。但按用量计费恰恰让使用本身变得更昂贵：用得越多，费用越高，而支出又是其中最难被准确预测的一部分。

于是，团队往往会做出看似理性的选择：限制 AI 的推广范围，只把它用在复杂工单上。结果，最初支撑采购决策的理由，在不知不觉中悄然瓦解。

这是一个难解的两难境地：不充分使用，就无法获得投资回报；不清楚使用成本，又无法承诺充分使用。于是，大多数组织最终都未能充分利用已购买的功能，进而认为 AI 在 ITSM 中的价值被过度宣传。但在我们看来，更准确的判断是：问题出在定价方式上。

本文讨论的五个方面，归根结底都指向同一个问题：您能否让 AI 得到它应有的充分使用？如果答案取决于按量计费机制、产品版本、额度池，或是一家并非由您选择的供应商，那么 AI 在组织中会受到怎样的使用限制，其实已不难预见。选择 ServiceDesk Plus，就能摆脱这种受成本掣肘的使用轨迹，重新获得可预期的定价与更优的投资回报——这也会让您的首席财务官感到满意。