同一个IT服务台为什么要接多个大模型？ServiceDesk Plus AI服务商选择、数据边界与切换治理指南
ServiceDesk Plus Cloud允许管理员为不同GenAI能力分别选择AI服务提供商，而不是必须让整个服务台使用同一个大模型。这意味着Ask Zia、回复辅助、会话摘要、代码生成、工作流助手等功能，可以根据实际需求配置不同AI引擎。真正需要管理的并不是“哪个模型最好”，而是某项功能是否需要多模态能力、是否涉及敏感工单数据、是否需要企业已有Azure体系、是否使用第三方API密钥、切换模型后输出是否发生变化，以及使用成本和效果能否持续观察。多模型真正的价值，是让企业按场景配置AI，而不是把所有AI任务交给一个统一模型。
直接回答：ServiceDesk Plus里为什么不一定只选一个大模型？
因为IT服务台里的AI任务并不相同。生成一段工单回复主要需要理解文本上下文；从流程截图生成工作流需要多模态能力；知识问答更关注检索与内容准确性；代码生成需要更强的指令理解和代码能力；涉及敏感工单内容时，企业还要考虑数据传输范围和第三方服务条款。ServiceDesk Plus允许按GenAI功能分别配置AI服务提供商，因此企业可以根据“功能需求、数据边界、模型能力、现有云平台和使用效果”选择，而不必把所有任务绑定在一个模型上。
什么是ServiceDesk Plus中的AI服务提供商？
AI服务提供商，可以理解为ServiceDesk Plus执行生成式AI任务时实际调用的模型服务。根据当前ServiceDesk Plus Cloud帮助文档，管理员可以在GenAI功能中为不同能力配置Zia（Zoho托管LLM）、Azure OpenAI、ChatGPT或Google AI Studio。第三方模型通常需要先完成对应集成，才能被选为某项功能的AI提供商。
多模型配置是不是让AI同时调用多个模型？
不一定。这里更重要的含义是“不同功能可以配置不同提供商”。例如企业可以让某项文本生成能力使用一个模型，让需要图像理解的Workflow Assist使用另一种支持多模态输入的模型。管理员也可以后续更换某项功能当前配置的AI服务商。因此，多模型管理的核心不是让每一次请求同时访问多个模型，而是让不同ITSM场景能够选择更合适的AI引擎。
本文适合谁阅读？
本文适合已经使用或准备使用ServiceDesk Plus Cloud GenAI能力，正在评估Zia LLM、ChatGPT、Azure OpenAI、Google AI Studio等不同AI服务提供商的ITSM负责人、服务台管理员和信息安全团队；也适合已经接入多个大模型，却还没有建立“什么功能用什么模型、为什么这样选、什么时候可以切换”的统一管理规则的企业。
企业第一次在IT服务台接入生成式AI时，最容易问的问题通常是：“到底接哪个大模型？”这个问题听起来很合理，却很容易把复杂的ITSM使用场景简化成一个模型选型题。
真实的服务台里，AI承担的工作差别很大。用户在Ask Zia里询问“我的VPN工单现在到哪一步”，需要的是上下文理解和服务台数据查询；技术员使用Reply Assist写回复，需要的是对会话的理解和语言生成；管理员让AI根据一张流程图生成工作流，需要的是图像理解和流程结构识别；让AI生成自定义函数，又涉及代码逻辑、字段和API；Solution Assist还需要结合企业知识库给出相关建议。
把这些任务全部交给同一种模型当然可以简化配置，但并不一定符合企业实际需要。一些企业更重视数据留在既有服务体系内，一些企业本身已经大量使用Azure服务，一些场景必须读取图片，一些场景只需要简单文本生成，还有一些功能使用量很大，需要特别关注调用和资源消耗。
ServiceDesk Plus Cloud目前已经把模型选择做到功能层级。管理员可以进入“设置 > Zia > 人工智能 > GenAI功能”，分别启用所需能力并选择AI服务提供商；之后也可以针对单项功能重新配置提供商。对于企业来说，这意味着大模型选择不再一定是一次性的“平台级决策”，而可以变成一套更细的IT服务管理配置。
但选择越灵活，越需要规则。如果今天管理员觉得ChatGPT效果不错就切过去，明天另一个人看到Azure OpenAI已经采购又切回来，过几周工作流生成效果变化，却没人记得当时到底使用了哪个模型，那么“多模型”只会从技术灵活性变成新的配置混乱。真正成熟的ITSM系统使用方式，是把模型能力、数据边界和实际服务场景一起考虑。
一、为什么“一套大模型全包”看起来简单，真正运行后却容易遇到问题？
对管理员来说，只配置一个AI提供商最省事：统一接入、统一密钥、统一培训，也不用向技术员解释不同模型。但随着AI进入更多ITSM流程，一套模型全包的局限会逐渐暴露出来。
第一，不同AI功能对模型能力的要求并不一样。最典型的例子是Workflow Assist。ServiceDesk Plus官方帮助文档说明，基于文字描述生成工作流需要较强的语言模型，而基于图片生成工作流则必须选择具备多模态处理能力的模型；当前文档同时说明，Zia托管LLM不支持图片输入。也就是说，同一个Workflow Assist功能里，“文字生成”和“图片生成”本身就可能对模型选择提出不同要求。
第二，不同场景涉及的数据敏感程度不同。让AI润色一句普通回复，和让AI总结包含用户名、IP地址、资产信息、审批记录甚至业务故障细节的长工单，数据风险并不相同。企业不能因为某个模型在普通文本任务上表现不错，就默认所有含敏感信息的场景都使用同样配置。
ServiceDesk Plus官方关于第三方数据访问的说明也提醒，某些第三方集成和开放API连接可能需要将ServiceDesk Plus Cloud数据提供给第三方，这类数据传输只有在明确授权后发生；配置集成时应仔细审查访问权限以及第三方服务的数据保护和隐私政策。对于AI模型选择来说，这意味着“模型能力”只是一个维度，数据流向同样需要纳入配置依据。
第三，企业已有技术体系不同。已经统一采购Azure服务并建立相应账号、密钥和权限管理机制的企业，在Azure OpenAI上可能更容易沿用既有管理方式；而希望直接使用ServiceDesk Plus内置能力的团队，则会更关注Zia托管LLM。模型选择如果脱离企业现有身份、采购、安全和运维体系，很容易产生额外管理成本。
第四，模型支持范围会随功能、版本和区域变化。当前ServiceDesk Plus Cloud GenAI功能帮助页列出的提供商包括Zia、Azure OpenAI、ChatGPT和Google AI Studio；Ask Zia相关产品页面在中国区又列出了DeepSeek。企业不应该因为“产品支持这个模型”就推断“所有AI功能都能使用这个模型”，而应该以当前具体功能的配置页面和官方文档为准。
第五，切换模型后，输出可能变化。同一个提示词交给不同模型，回答结构、长度、措辞、代码生成方式和工作流理解都可能不同。如果企业已经把某项AI输出嵌入标准流程，模型切换就应该被当作一次需要验证的配置变化，而不是随手改一下下拉框。
| 容易忽略的问题 | 可能表现 | 更合适的做法 |
|---|---|---|
| 所有功能都用同一模型 | 部分多模态或复杂任务能力不匹配 | 按功能需求选择 |
| 只比较生成效果 | 忽略数据传输和第三方条款 | 同时审查数据边界 |
| 认为所有模型都支持所有功能 | 实际配置时才发现不可选 | 按当前功能文档核对 |
| 随意切换模型 | 输出格式和质量突然变化 | 切换前做样例验证 |
| 没有记录配置原因 | 几个月后没人知道为什么这么选 | 建立功能—模型配置矩阵 |
二、不同GenAI场景应该怎么选AI服务商？先看任务，再看模型
企业不需要先讨论“哪家模型最好”，更实用的顺序是先把ServiceDesk Plus里的AI场景分组，再看每组任务需要什么能力。模型只有放进具体流程里，比较才有意义。
场景1：Conversation Summary、Reply Assist、Text Assist——重点看文本上下文和输出一致性
这类功能主要处理工单文本。管理员更应该观察：长会话能否准确抓住问题、回复是否遗漏关键事实、语言和格式是否符合团队沟通标准、技术员需要修改多少。这里未必需要最复杂的模型能力，关键是输出稳定、与实际服务流程匹配。
场景2：Workflow Assist——先判断有没有图片输入
如果管理员只是用文字描述“创建一个包含经理审批、通知和超时提醒的服务请求工作流”，重点是语言理解和流程逻辑；如果希望上传流程截图、架构草图或手绘流程，让AI识别图形后生成工作流，就必须先确认所选模型具备相应多模态能力。模型是否支持图片，在这里比单纯的文本表现更重要。
场景3：Code Generator、自定义函数生成——重点看代码审查和可重复验证
AI能够更快生成代码并不代表管理员应该只比较“谁第一次写出来能运行”。更适合观察的是复杂条件能否正确理解、是否容易出现不存在的字段或函数、代码是否便于人工阅读、同类提示输出是否稳定。无论选择哪种模型，最终代码仍应进入人工审查和测试流程。
场景4：Ask Zia——重点看知识、上下文、操作和区域支持
Ask Zia不仅是简单问答入口，它还可能结合服务台数据查询、知识搜索和工单操作。企业在选择其AI引擎时，应同时确认所在区域当前支持哪些提供商、对话是否需要多模态输入、是否会查询内部知识以及相关数据授权范围。中国区相关官方页面目前还列出了DeepSeek，因此Ask Zia的模型配置更应该以当前租户和官方页面为准。
场景5：高频GenAI功能——重点补上使用量和资源观察
某个功能每天只调用几十次，和每天大量技术员反复调用，管理重点并不相同。高频使用时除了质量，还应关注使用统计、用户分布和模型资源消耗。ServiceDesk Plus的Zia Dashboard可以查看GenAI各能力的使用情况，并从提供商和用户维度分析使用情况，因此模型配置不应该只在上线当天决定一次。
| AI场景 | 优先确认的问题 | 不建议只看什么 |
|---|---|---|
| 回复、摘要、文本辅助 | 上下文准确度、修改量、输出一致性 | 回答是否“看起来聪明” |
| Workflow Assist | 文字或图片输入、流程识别能力 | 单纯文本生成效果 |
| 代码生成 | 逻辑准确、可读、可测试 | 第一次是否能运行 |
| Ask Zia | 区域支持、上下文、内部知识、操作权限 | 模型品牌 |
| 高频GenAI能力 | 使用量、资源消耗、采纳效果 | 一次性测试结果 |
三、ServiceDesk Plus怎么做多模型配置？接入、分配、切换和统计要一起管
多模型真正好用的前提，是管理员能回答四件事：哪些模型已经接入、哪些功能正在使用哪个模型、最近有没有切换过、切换以后效果有没有变化。只完成第一步集成，还不能算完成管理。
第一步：第三方模型先完成独立集成。根据ServiceDesk Plus Cloud帮助文档，Azure OpenAI、ChatGPT和Google AI Studio需要先在第三方集成中启用，之后才能被配置为GenAI功能的AI服务提供商。以Azure OpenAI为例，管理员需要配置资源URL、基础模型、模型名称和API密钥，集成完成后才可以在Zia的GenAI功能中选择。
这一步不要只由“谁有API Key”决定。API密钥应存放在符合企业安全要求的位置，账号归属、续费、停用和人员离职后的密钥管理都应该提前明确。否则模型本身运行正常，却可能因为一个管理员离职或第三方账号变更突然失效。
第二步：在GenAI功能层级配置模型。进入“设置 > Zia > 人工智能 > GenAI功能”后，每项能力可以单独启用并选择AI服务提供商。这是整个多模型策略最重要的地方：企业可以把模型和业务场景一一对应，而不是把第三方集成开通后就默认所有功能全部使用。
建议管理员建立一张简单的“功能—模型配置表”，至少记录功能名称、当前提供商、选择原因、数据类型、负责人和最近一次调整时间。例如Workflow Assist选择某模型是因为需要图片输入，Conversation Summary选择另一个提供商是因为主要处理文本，原因写清楚以后，后续调整才不会变成拍脑袋。
第三步：模型切换前先做固定样例测试。ServiceDesk Plus支持后续重新配置某项GenAI功能的AI服务提供商，但“能切”不代表“应该直接切”。企业可以为主要功能保留固定测试样例：几张长工单用于会话摘要、几组不同语气的请求用于回复辅助、一张标准流程图用于Workflow Assist、几条复杂需求用于代码生成。
每次更换提供商后，用同一批样例重新测试，重点对比事实遗漏、格式变化、人工修改量和异常情况。这样模型调整就从“管理员感觉新模型更好”变成一项有依据的配置变更。
第四步：查看提供商使用统计。ServiceDesk Plus官方文档提供第三方AI集成使用统计，例如Azure OpenAI集成可以查看每位用户的使用情况；Zia Dashboard则可以查看不同GenAI能力的使用次数，并从提供商和用户角度分析使用情况。只有把使用数据和实际工单效果放在一起，企业才知道模型选择有没有真正进入日常工作。
模型切换最容易漏掉的一件事：别只测试“生成结果”，还要测试流程结果
如果AI只是生成一段草稿，模型变化主要影响内容质量；如果AI生成的是工作流、脚本、审批判断或其他会继续推动服务流程的内容，模型变化就可能进一步影响后续配置。因此切换提供商后，不仅要看AI输出本身，还应确认对应工作流、代码、人工审核和业务规则是否仍然能够按照预期工作。
示例场景A：文字工作流一直正常，上传流程图时却无法使用
场景：某企业一直通过文字提示让Workflow Assist生成流程，管理员觉得当前AI模型已经足够使用。后来团队希望直接上传旧流程截图，让AI生成新的可视化工作流，却发现现有配置无法处理图片输入。
原因：文字生成和图片生成对模型能力的要求不同。原来的模型满足文本场景，并不代表能够完成多模态任务。
调整：管理员没有把整个服务台的模型全部替换，而是针对Workflow Assist重新评估可选提供商，并使用固定流程截图验证生成效果。其他已经稳定运行的GenAI能力继续保持原配置，避免因为一个新需求引发全面切换。
示例场景B：模型切换后回复更流畅，但技术员修改得反而更多
场景：服务台为了测试新的AI提供商，把Reply Assist切换到另一种模型。新模型生成的语言更加自然，初看效果很好。
问题：运行一段时间后，技术员反馈新回复虽然更像人工表达，但经常增加未经确认的解释和承诺，需要删改的内容更多。如果只做一次样例测试，很容易把“语言更顺”误认为“业务更适用”。
调整：团队把技术员修改量、事实遗漏和发送前人工调整原因加入评估，不再只比较语言效果。模型选择最终回到服务结果，而不是单纯比较生成风格。
四、模型会变、功能会变：企业更需要一套长期可维护的AI服务商治理规则
多模型最大的管理难点不是第一次选谁，而是半年以后模型、功能、供应商和企业需求都发生变化时，现有配置还能不能解释得清楚。今天适合某个功能的模型，未来可能因为功能升级、数据要求变化或内部技术体系调整需要重新评估。
因此，企业可以把大模型配置当作一类持续维护的服务台配置项，而不是一次性的AI项目决策。
第一，建立“功能—模型—数据”台账。至少记录每项GenAI能力当前使用的提供商、涉及的数据类型、第三方集成账号、负责人、选择原因和最近验证时间。以后再出现“为什么Reply Assist用这个模型，而Workflow Assist用另一个”时，不需要重新猜。
第二，把敏感程度加入模型选择条件。普通知识润色、公开内容生成和包含内部资产、用户、审批、故障信息的工单摘要，不应该自动视为相同风险等级。企业可以按照自身数据分类制度，把不同GenAI场景划分等级，再决定允许哪些第三方服务参与处理。
第三，把模型切换纳入轻量变更流程。并不是每次切换都需要复杂CAB，但至少要记录为什么换、谁批准、测试了哪些样例、什么时候生效、出现异常如何恢复。特别是工作流生成、代码生成等可能进一步影响配置的能力，更应该保留验证记录。
第四，提前准备提供商不可用时的处理方式。第三方密钥失效、账号限制、服务异常或内部策略变化，都可能导致某个AI提供商无法继续使用。企业至少要知道哪些功能可以临时切回其他提供商，哪些功能可以短期关闭，哪些关键流程不能依赖AI才能继续运转。AI应该提高服务效率，而不能变成新的单点依赖。
第五，用实际采用数据定期复盘。某个AI模型在测试时表现很好，但如果技术员长期不用、生成内容经常被重写、某项能力使用量极低，那么继续维持这套配置的意义就需要重新评估。Zia Dashboard提供的GenAI使用洞察可以作为入口，再结合工单处理时长、人工修改、用户满意度和错误反馈判断真实价值。
| 治理项目 | 建议记录 | 什么时候复核 |
|---|---|---|
| 模型配置 | 功能、提供商、原因、负责人 | 功能升级或模型调整时 |
| 数据边界 | 输入数据类型、敏感等级、第三方条款 | 新增数据类型时 |
| 模型验证 | 固定样例、输出差异、人工修改 | 更换提供商前后 |
| 运行效果 | 使用量、用户、采纳情况、服务结果 | 定期服务复盘 |
| 异常预案 | 替代提供商、停用方式、负责人 | 集成或账号变化时 |
外部参考：多模型本质上也是AI治理问题
NIST发布的Generative AI Profile强调，组织需要在生成式AI生命周期中持续识别、测量和管理相关风险；ISO/IEC 42001则要求组织建立、实施、维护并持续改进人工智能管理体系。放到IT服务台场景里，多模型治理并不意味着给每个模型打一个简单分数，而是要持续知道模型被用在哪里、处理了什么数据、发生变化后如何验证，以及出现风险时由谁处理。 NIST Generative AI Profile； ISO/IEC 42001:2023
核心要点速览
ServiceDesk Plus的多模型能力，重点不是“模型越多越好”，而是“不同任务可以按需要选择”。 当前Cloud版GenAI功能可以按单项能力配置Zia、Azure OpenAI、ChatGPT、Google AI Studio等AI服务提供商；不同功能、版本和区域实际可选范围应以当前配置页面和官方文档为准。模型选择时至少要同时考虑功能能力、输入形式、数据敏感程度、企业现有技术体系和使用效果；模型切换后应使用固定样例重新验证；Zia Dashboard和第三方集成使用统计则可以帮助管理员持续观察模型到底有没有真正被团队使用。
写在最后：企业真正需要的不是“选对一个大模型”，而是让每个AI场景都有合适的选择依据
大模型更新越来越快，今天讨论的模型能力，过一段时间可能又会发生变化。如果企业把整个IT服务台AI体系建立在“某一个模型永远最好”的假设上，每次行业变化都需要重新做一次大规模选型。
ServiceDesk Plus把AI服务提供商选择放到具体GenAI功能层级，反而提供了一种更容易长期维护的思路：哪个场景需要什么能力，就为这个场景配置合适的AI；某项能力发生变化，就只重新验证相关场景；涉及不同数据，就按数据边界决定是否允许使用第三方模型。
借助ManageEngine ServiceDesk Plus，企业可以把Zia LLM以及支持的第三方AI服务接入同一套ITSM环境，并按照Ask Zia、回复辅助、会话摘要、代码生成、工作流辅助等不同功能分别配置和调整。这样，多模型带来的价值就不只是多几个下拉选项，而是让企业在AI能力变化越来越快的情况下，依然能够保持数据边界清楚、配置原因可解释、模型切换可验证、使用效果可复盘。
常见问题解答（FAQ）
延伸阅读：
