云与数字化 | 开源 ITSM 的生态底座

如果把连接器简单理解为“把 API 包一层”，那企业 AI 很快会撞上生产边界。真正的连接器，是 AI 在权限、流程和审计约束下，调用企业系统能力的工具层。

之前聊过 ServiceNow 的 Spoke 机制。Spoke 真正值得借鉴的地方，并非它连接了多少系统，而是它把外部系统能力做成了可安装、可复用、可组合、可治理的流程组件。

但落到工程层面，还有一个更具体的问题需要回答：连接器到底该怎么设计？它与普通 API 包装的区别在哪？为什么企业 AI 要落地，必须先让连接器成为“工具层”？

其实不少企业手里早就攒了一大堆 API 对接、Webhook、脚本、定时任务和自动化工具。这些工具能跑，也能解决局部问题，但大多是一次性的项目制产物，散落在不同团队手里。接口调通了，不代表能力可治理；脚本能执行，不等于 AI 可以安全调用。

企业 AI 的难点，不只是让模型“知道答案”，而是让它在正确的时间、以正确的权限、调用正确的系统、执行正确的动作，且每一步都可审计、可回滚、可治理。这，正是连接器从“接口包装”升级为“工具层”的根本原因。

01

API 包装只解决“调通”，工具层要解决“可用、可控、可复用”

一个 API 包装通常只关心：请求地址、认证方式、参数传递、返回值解析。它解决的，是“系统之间能不能通信”。

但企业级连接器要解决的问题多得多。它需要知道这个动作属于什么业务场景，风险等级如何，谁可以调用，调用前是否需要审批，凭据由谁管理，调用失败怎么处理，调用结果如何写回流程，审计日志记录到哪里。

拿“发送飞书消息”和“重启生产服务器”来说，技术上都是一次 API 调用，但企业治理视角完全不同。前者是低风险通知动作，后者则可能影响生产服务，需要变更审批、影响分析、执行窗口和回滚方案。如果连接器只盯着 API，看不到风险和流程，就不可能成为企业 AI 的工具层。

接口包装回答的是：这个接口怎么调？
企业工具层回答的是：这个动作在什么场景下、由谁、以什么权限、经过什么流程、留下什么审计之后，才能被调用？

所以说连接器市场不能只做“系统图标列表”。真正有价值的连接器市场，应该交付一组可治理的动作，而不是一堆松散接口。

02

一个企业级连接器，至少要有生命周期

许多集成工具把连接器当配置项：填上地址、密钥、参数就能用。但企业级连接器不能只靠配置存在，它必须有生命周期。

生命周期可不是形式主义。它决定了连接器能不能进入生产环境，能不能被管理员治理，出问题时能不能快速定位和关闭。

一个连接器至少要具备这些状态和动作：
- install：安装连接器，注册能力、动作、权限和配置模板。
- configure：配置凭据、回调地址、作用范围和默认参数。
- enable：启用连接器，让流程和 AI 可在授权范围内调用。
- health：检查连接器是 ready、degraded 还是 unhealthy。
- test：在受控环境里测试发送、查询或回调。
- disable：风险或故障出现时禁用，不影响其他核心能力。
- uninstall：卸载连接器，并处理配置、权限、审计和依赖关系。

在当前开源 ITSM 项目的设计里，连接器 lifecycle、health 三态、连接器变更审计已被列入验收要求。这一点很关键：连接器越多，越不能靠人工记忆和临时配置管理，必须有系统化的生命周期管理。

03

凭据治理：密钥不能散落在脚本和环境变量里

企业里很多自动化之所以无法规模化，一个重要原因就是凭据不可治理。API Key 写在脚本里，Webhook Token 放在配置文件里，某个工程师离职后没人知道哪些任务依赖他的账号，密钥过期后流程突然断裂。

如果连接器要成为企业 AI 的工具层，凭据管理必须平台化。AI 不能直接接触原始密钥，普通流程也不该把密钥暴露给业务用户。连接器应该通过统一的凭据管理机制完成认证，并记录凭据的创建、更新、使用和失效。

连接器凭据治理至少包括：
- 凭据加密存储，不在日志、提示词和前端页面泄露。
- 按租户、系统、连接器和动作隔离凭据。
- 支持轮换、失效、测试和健康检查。
- 关键凭据变更要写审计，并能追溯影响范围。

这也就是 AI Native ITSM 和普通脚本自动化的本质差异。普通脚本能跑就行，平台型系统必须能治理；AI 工具调用更是如此，因为 AI 调用连接器时，背后实际使用的是企业授权能力。

04

权限边界：AI 不能拥有超过人的权限

企业对 AI 自动化最担心的一点，就是 AI 会不会越权操作。这个担心完全合理。如果连接器没有权限边界，AI 工具调用就会变成新的安全风险。

连接器必须与 RBAC、多租户、组织权限、流程权限结合。一个普通员工触发的 AI 操作，不能因为调用了某个连接器就获得管理员权限。一个租户的连接器配置，也不能被另一个租户使用。一个低风险通知动作和一个高风险执行动作，必须有不同授权。

因此连接器动作要按粒度授权，而不是只授权“能不能使用连接器”。比如飞书连接器里，发送消息、查询用户、创建审批、更新待办应该是不同动作；云平台连接器里，查询资源、创建实例、删除实例、修改安全组更应有严格区分。

企业 AI 的一个基本原则：
AI 不能因为“会推理”就绕过权限。AI 只能在用户、角色、流程和审批授予的边界内调用工具。

这也是连接器必须进入 ITSM 平台的原因。ITSM 本身就有工单、流程、审批、角色、租户、审计这些基础能力。连接器如果挂在这些机制之外，就很难做到企业级治理。

05

安全基线：Webhook 不是小功能，SSRF 是真实风险

Webhook 看起来是最普通的连接器能力：给一个 URL，系统就能把事件发出去，或者接收外部系统的回调。但正因为它通用，风险也很直接。

如果不加限制，Webhook 可能被配置到内网地址、元数据服务地址、本地端口，从而造成 SSRF 风险。企业内网环境越复杂，这类风险越需要提前防护。

所以连接器市场里，Webhook 不是“最简单的连接器”，而是最需要安全基线的连接器之一。它要有 URL 校验、内网地址限制、超时控制、响应大小限制、签名校验、重试策略和审计记录。

一个安全的 Webhook 连接器至少要考虑：
- 拒绝内网地址和高危地址段。
- 限制请求超时、重试次数和响应体大小。
- 支持签名、密钥和时间戳校验。
- 记录调用来源、目标 URL、状态码和错误原因。
- 在健康检查中暴露 ready / degraded / unhealthy 状态。

在当前项目设计里，已经把“连接器 webhook URL 指向内网地址时拒绝”和 health 三态列入要求。原因很简单：连接器从第一天起就应该按生产系统的安全标准来设计。

06

AI 工具调用：连接器要给模型“可理解的动作描述”

如果连接器只是给人用，API 文档可能就够了。但如果连接器要被 AI 调用，它还需要提供更结构化的动作描述。

AI 需要知道这个动作做什么，需要哪些输入，输出是什么，什么时候适合调用，风险等级如何，是否需要人工确认，失败后应该怎么处理。否则模型只能看到一个函数名，很容易产生错误调用。

比如“send_message”这个动作，描述不清楚时，AI 不知道它能发给个人还是群，是否支持卡片，会不会暴露敏感信息，是否需要用户授权。再比如“create_cloud_instance”，如果没有风险说明，AI 可能不知道这涉及成本、配额、安全组和资产登记。

面向 AI 的连接器动作，应该像企业工具说明书：
它不仅描述参数，还要描述业务语义、风险等级、权限要求、是否可自动执行、是否需要人工确认、结果如何验证。

这也是 AI Native ITSM 与传统 ITSM 的差异。传统系统主要把连接器给流程节点和管理员使用；AI Native 系统还要让连接器成为模型可理解、可选择、可审计的工具层。

07

连接器应该先服务流程，再服务 AI

很多人做 AI Agent 工具，会从模型出发：模型需要什么工具，就给它接什么工具。但在企业场景里，更稳妥的做法是反过来：连接器应该先服务流程，再服务 AI。

原因很简单。企业流程本身已经定义了责任、审批、状态、SLA、审计和回滚边界。连接器进入流程以后，AI 才能在这个边界里工作。否则 AI 直接调用工具，看起来智能，但很难解释、很难治理、也很难追责。

比如一个云资源申请，流程里可以明确：谁发起，谁审批，谁创建，是否需要成本中心，创建后是否写入 CMDB，什么时候回收资源。AI 可以辅助补全信息、判断风险、生成摘要，但不能绕过流程直接创建资源。

这也是设计开源 AI Native ITSM 时的基本方向：先把工单、流程、权限、审计、连接器、知识库这些基础打好，再让 AI 逐步参与分诊、摘要、推荐、工具调用建议和低风险自动化。

更稳妥的路径是：
- 流程定义责任边界。
- 连接器提供受控动作。
- Skill 提供判断和生成能力。
- AI 在流程内选择和建议工具调用，而不是绕开流程直接操作系统。

08

开源 ITSM 的连接器工具层，可以从哪里开始？

对当前开源 ITSM 项目来说，连接器工具层不需要一开始就做成庞大的市场。更现实的路径，是先把最小企业级模型跑通。

第一批连接器可以从 Console、Webhook、飞书、企业微信、钉钉开始。Console 用于调试和演示；Webhook 用于通用系统接入；飞书、企业微信、钉钉用于通知、待办、审批触达和员工服务入口。它们足够基础，也足够高频。

但重点不是做几个连接器图标，而是为所有连接器建立统一框架。

第一版连接器工具层应该包含：
- 统一 manifest：声明动作、权限、凭据、风险和依赖。
- 统一 lifecycle：安装、配置、启用、健康检查、测试、禁用、卸载。
- 统一安全基线：SSRF 防护、凭据隔离、超时、签名、审计。
- 统一流程调用方式：连接器动作可以成为工作流节点。
- 统一 AI 描述：让 Skill 和 Agent 能理解动作语义和风险边界。

把这套基础打好以后，再扩展云厂商、监控系统、代码平台、CI/CD、OA、ERP，才不会变成一次次项目制对接。

结语

连接器不是接口包装。接口包装只是把系统连起来，企业级连接器要把系统能力变成可授权、可审计、可编排、可被 AI 理解的工具。

企业 AI 要真正落地，不能只依赖模型能力，也不能把工具调用散落在脚本里。它需要一个受控的工具层：有生命周期、有凭据治理、有权限边界、有安全基线、有审计追踪，并且能进入流程。

正在做的开源 AI Native ITSM 项目还在早期发展。连接器市场目前仍是持续建设的方向，但有一个原则会始终坚持：先做企业级工具层，再谈 AI 自动化。否则连接器越多，风险越大；AI 越能执行，边界越模糊。