夜雨聆风MANAGEMENT REVIEW · OPEN ITSM
云与数字化 | 开源 ITSM 的插件市场与能力包生态
企业级软件最难的不是做功能，而是功能越来越多以后，核心系统还能不能保持稳定。
开源 ITSM 要长期走下去，插件市场不是可选项，而是避免每个客户都改核心代码的基础设施。
前面几篇文章，我们从 ServiceNow 的 Spoke 机制，讲到了国内企业自己的 Spoke 生态，也讲到了为什么要从飞书、企业微信、钉钉这些协同入口开始做连接器。连接器解决的是“系统怎么接进来”，但它还没有回答另一个更难的问题：企业差异化能力怎么扩展？
企业软件有一个长期矛盾：标准产品必须稳定，但每个客户又都有自己的流程、组织、字段、审批规则、页面入口、内部系统和管理制度。做得太标准，客户觉得不贴合；做得太定制，产品内核很快变成一团难以维护的项目代码。
开源项目更容易遇到这个问题。因为开源意味着大家都能改，早期为了满足场景，很容易把差异化需求直接写进核心代码里。今天加一个字段，明天加一个页面，后天接一个内部系统，再过一段时间，主干代码就会越来越重，升级越来越难，社区贡献也越来越难合并。
所以我越来越确定：如果要做一个面向国内企业的开源 AI Native ITSM，不能只做工单、CMDB、工作流和连接器，还必须从一开始设计插件机制。插件市场的本质，不是做一个“应用商店页面”，而是为企业级扩展建立清晰边界。
01
为什么企业软件越用越难升级？
很多企业都有这样的经历：刚上线一个系统时，版本很干净，厂商升级也很顺利；运行两三年以后，系统里开始有大量定制字段、定制流程、定制报表、定制接口、定制页面。到了下一次大版本升级，谁也不敢轻易动。
原因很简单：定制能力没有边界。核心代码里既有产品标准逻辑，也有某个部门的特殊逻辑，还有某个历史项目留下来的临时接口。时间一长，谁也分不清哪些是产品能力，哪些是客户定制，哪些是可以删掉的旧逻辑。
ITSM 系统尤其容易这样。因为 ITSM 处在流程中心，天然会被各种部门、各种系统、各种制度拉着走。安全团队希望加安全事件字段，运维团队希望接监控告警，人事希望走入职流程，行政希望做设备申请，财务希望加成本中心，研发希望对接代码平台和 CI/CD。每个需求单独看都合理，但如果全部写进核心，系统会越来越难维护。
企业软件真正的长期成本，不是第一版开发成本，而是持续变化成本。
如果变化都靠改核心代码承接，系统越成功，技术债越重；客户越多，主干越难稳定。
这就是插件机制要解决的问题：让标准内核保持稳定，让差异化能力在边界清晰的插件里生长。
02
二开不是原罪，没有边界的二开才是问题
开源项目经常会被二次开发。企业拿到源码以后，根据自己的制度、系统和场景做修改，这是开源的优势，不是问题。问题在于，二开如果没有插件边界，就会从“扩展”变成“分叉”。
一旦企业在核心代码里改得太深，后续社区版本升级就会很痛苦。新版本修了安全问题，企业不敢合；新版本增加了功能，企业合不上；企业内部又继续改，最后变成一个独立分支。它还能用，但已经很难享受开源社区的持续演进。
一个健康的开源 ITSM，应该允许二开，但要把二开引导到可治理的扩展层：插件、连接器、流程模板、字段扩展、页面扩展、AI Skill、能力包。这样企业可以做自己的差异化，同时不破坏核心系统。
好的二开应该像这样：
核心系统负责通用能力：用户、租户、权限、工单、流程、CMDB、审计、连接器生命周期。
插件负责差异能力：行业字段、内部系统接入、专属页面、特殊流程、部门规则、AI Skill。
能力包负责场景交付：员工入职、SLA 告警、云资源申请、密码重置、重大事件响应。
这也是为什么插件市场不只是给开发者看的功能。它直接关系到企业能不能长期升级，开源社区能不能持续合并贡献，项目能不能从单体产品走向生态。
03
插件市场的本质，是扩展契约
很多人理解插件市场，会先想到一个页面：上面有很多卡片，点一下安装。这个页面当然需要，但它不是插件市场的核心。真正的核心是扩展契约。
所谓扩展契约，就是平台明确告诉插件：你可以扩展什么，不能碰什么；你要声明哪些权限；你依赖哪些连接器；你新增哪些菜单和页面；你调用哪些 API；你写入哪些数据；你如何被审计；你如何升级和卸载。
如果没有契约，插件只是换了一种形式的核心代码定制。安装时看起来方便，运行几年以后同样会失控。
一个 ITSM 插件至少应该声明这些信息：
它的名称、版本、兼容平台版本和维护者。
它需要哪些权限，比如读取工单、调用连接器、创建流程任务。
它扩展哪些菜单、页面、API、流程节点和后台任务。
它依赖哪些连接器、工作流模板、AI Skill 或数据模型。
它的关键操作是否写审计，失败后如何处理。
这套契约越清晰，生态越容易发展。因为开发者知道怎么扩展，企业知道怎么评估风险，平台知道怎么安装、升级和禁用。
04
一个 ITSM 插件应该能扩展什么？
如果插件机制只支持后端接口，那还不够。企业级 ITSM 的扩展通常是端到端的：有页面、有权限、有流程、有连接器、有审计，有时还要有 AI Skill。
我认为一个开源 ITSM 的插件体系，至少要支持七类扩展。
第一，菜单和页面扩展。
插件可以新增入口、配置页、报表页、场景页面，但这些入口要受 RBAC 和租户权限控制。
第二，API 和后台任务扩展。
插件可以提供自己的 API、定时任务、异步任务和事件处理逻辑，但必须有权限和审计边界。
第三，流程模板扩展。
插件可以安装服务请求流程、审批流程、SLA 升级流程、变更审批流程，让企业直接复用。
第四，连接器依赖。
插件可以依赖飞书、企业微信、钉钉、Webhook、云厂商、监控平台等连接器，并声明需要哪些动作。
第五，数据模型和字段扩展。
不同行业和企业需要不同字段，但字段扩展不能随意污染核心表结构，需要有模型声明和迁移策略。
第六，权限和审计扩展。
插件引入的新动作、新页面、新 API，都要能纳入权限体系和审计日志。
第七，AI Skill 扩展。
插件可以带上特定场景的 AI Skill，比如安全事件分诊、变更影响分析、SLA 风险预测、知识生成。
这套扩展能力不是一开始就全部做完，但设计方向要清楚。否则后续很容易为了单个需求不断破坏核心边界。
05
插件生命周期，比插件数量更重要
很多平台喜欢展示自己有多少插件。但对企业来说，插件数量不是第一位，插件生命周期才是第一位。因为企业真正担心的是：装了以后能不能管，出问题能不能停，升级以后会不会坏，卸载以后有没有残留。
一个企业级插件至少应该有清晰生命周期：安装、启用、配置、健康检查、升级、禁用、卸载。每一步都要有状态、日志和权限控制。
这和连接器 lifecycle 是一致的。当前开源 ITSM 项目已经把连接器安装、启用、健康检查、测试发送放进 GA 验收设计里，后续插件市场也应该沿用类似模式。这样连接器、插件、Skill、能力包都能使用统一的生命周期治理。
插件生命周期要解决的不是“能不能装”，而是“能不能被企业放心地装”。
安装前知道权限，启用前完成配置，运行中能健康检查，出问题能禁用，升级时有兼容策略，卸载后能清理资源。
这听起来很基础，但越是企业级软件，越要把这些基础能力做扎实。生态不是靠口号长出来的，是靠生命周期、文档、测试和治理机制慢慢长出来的。
06
开源 ITSM 当前应该先做最小插件模型
插件市场听起来很大，但不应该一开始就做得过重。对当前开源 AI Native ITSM 项目来说，更现实的路径是先做最小插件模型，把扩展契约立起来，再逐步扩展能力。
当前项目已经具备一些基础：ITIL 核心流程、CMDB、BPMN 工作流、RBAC、多租户、知识库、AI 分诊、摘要、RAG 检索、AI 审计、连接器市场雏形，以及飞书、企微、钉钉、Webhook 等扩展方向。这些能力还不是成熟插件生态，但足够支撑第一版插件机制的设计。
第一版插件模型不需要追求全能。我会优先考虑几个基础点。
第一，插件 manifest。
先定义插件如何声明名称、版本、权限、菜单、连接器依赖、Skill 依赖、流程模板和审计要求。
第二，生命周期 API。
支持 install、enable、configure、health、disable、uninstall，先把治理闭环跑通。
第三，权限接入。
插件新增的菜单、API、动作都必须进入 RBAC，不能绕过平台权限。
第四，审计接入。
插件安装、配置变更、关键动作调用、启用禁用都要写审计。
第五，第一个能力包示例。
可以先做 SLA 告警通知包或密码重置服务包，用一个具体场景验证插件、连接器、流程和 AI Skill 如何组合。
这条路比较慢，但更稳。因为它不是为了做一个漂亮的市场页面，而是为了让未来的每个扩展都有规则、有边界、有生命周期。
07
插件市场最终会走向能力包
单个插件解决的是扩展问题，但企业真正购买或安装的，往往不是一个孤立插件，而是一个完整场景。比如员工入职、SLA 告警、云资源申请、密码重置、重大事件响应，这些都不是一个插件能完全表达的，它们需要连接器、流程模板、表单、权限、通知、AI Skill 和审计策略组合起来。
这就是能力包的价值。能力包不是单点功能，而是一组可以安装的流程能力。它可以包含一个或多个插件，也可以依赖多个连接器和 Skill。
比如 SLA 告警能力包，可以包含 SLA 规则模板、工单筛选逻辑、飞书/企业微信/钉钉通知连接器、升级流程、责任人匹配、AI 摘要和审计记录。企业安装它以后，不只是得到一个通知插件，而是得到一套可以运行的服务质量治理流程。
从这个角度看，插件市场只是起点，能力包生态才是目标。插件把扩展边界立起来，能力包把业务场景交付出来。
结语
开源 ITSM 要避免每个客户都改核心代码，关键不是禁止定制，而是把定制引导到插件、连接器、流程模板、字段扩展、AI Skill 和能力包里。
插件市场不是一个应用商店页面，而是一套扩展契约和工程治理体系。它决定了标准内核能不能保持稳定，企业差异化能不能被承接，社区生态能不能长期发展。
我正在做的开源 AI Native ITSM 项目还在早期，GitHub 上已有 30+ Star，插件市场和能力包生态仍在建设规划中。但如果目标是面向国内企业做一个可私有化、可扩展、可二次开发的 ITSM 底座，那么插件机制必须尽早设计。否则项目越成功，核心代码越容易被各种场景拉散。
项目地址：
https://github.com/heidsoft/itsm
官网：
https://cloudmesh.top
下一篇我会继续写：可安装能力包，把连接器、流程模板和 Skill 打包在一起。
如果你也在做企业级开源软件，欢迎一起讨论插件 manifest、生命周期、权限和审计应该怎么设计。