连接器不是接口代理，而是企业 AI 的工具层

云与数字化 | 开源 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 项目还在早期，GitHub 上已有 30+ Star。连接器市场目前仍是持续建设方向，但我会坚持一个原则：先做企业级工具层，再谈 AI 自动化。否则连接器越多，风险越大；AI 越能执行，边界越模糊。

项目地址：https://github.com/heidsoft/itsm