连接器市场：企业 AI 落地绕不开的基础设施

云与数字化 | AI Native ITSM 系列

企业 AI 最难的地方，往往不是模型会不会回答，而是它能不能在企业系统里安全地做事。

连接器市场，就是把“会回答的 AI”变成“可治理、可审计、可集成的企业能力”的基础设施。

过去一年，很多企业都在尝试把大模型引入内部管理、IT 运维、客户服务、研发协同和知识管理。试点阶段通常并不难：接一个模型，导入一些文档，做一个问答入口，员工可以问制度、问故障处理步骤、问报销流程、问代码规范。

但进入真正落地阶段，问题很快就暴露出来：AI 能说，却不能做；能总结，却不能推进流程；能给建议，却不能调用系统完成动作。一个员工问“我需要申请一台测试服务器”，AI 可以告诉他应该走什么流程，却不能自动识别申请人、发起审批、调用云平台、登记资产、通知使用人。最后员工还是要在 OA、云控制台、ITSM、企业微信之间来回切换。

这不是大模型本身的问题，而是企业 AI 缺少执行通道。企业内部系统长期分散在不同部门、不同厂商、不同年代的技术栈里，接口标准不一致，认证方式不一致，权限模型不一致，数据语义也不一致。AI 如果无法进入这些系统，就只能停留在“文字输出”层面。

所以我越来越认为，企业 AI 落地的关键问题，不只是模型选型，也不是提示词写得多精巧，而是企业有没有一套可靠的连接器体系。连接器市场不是一个锦上添花的插件列表，而是企业 AI 从演示走向生产环境绕不开的基础设施。

01

没有连接器，企业 AI 只能停在“建议层”

很多企业第一次做 AI 应用，会从知识问答开始。这是一个合理入口，因为成本低、风险小、效果容易感知。但如果 AI 长期只停留在问答层，业务价值会遇到明显天花板。

比如 IT 服务台每天会收到大量重复请求：重置密码、申请权限、开通账号、申请 VPN、创建测试环境、查询变更状态、咨询故障进展。这些事情看起来是问答，实际上大部分是流程和系统操作。真正消耗人力的，不是告诉用户“应该怎么做”，而是确认身份、判断权限、发起审批、调用接口、同步状态、记录审计、完成闭环。

如果没有连接器，AI 只能把这些动作描述出来。它可以生成一段很好的操作说明，却无法替用户完成任何一步。用户看完说明以后，还是要打开多个系统，手动提交表单，等待审批，催促处理人，再回到工单里更新状态。

关键判断

企业 AI 如果不能连接系统、调用能力、推进流程，就很难从“信息助手”升级为“业务执行助手”。连接器决定了 AI 能不能进入真实业务链路。

这也是为什么很多 AI 项目试点时很亮眼，进入生产后却很难持续。演示环境里，AI 只需要回答得像样；生产环境里，AI 要面对权限、异常、审批、数据一致性、幂等、审计、回滚和责任边界。没有连接器和治理体系，AI 一旦开始“做事”，风险会迅速放大。

02

连接器不是简单 API 对接，而是企业能力的标准化封装

很多人听到连接器，第一反应是“这不就是写几个 API 调用吗”。如果只是把系统接口包一层，这确实不复杂。但企业级连接器真正困难的地方，不在于能不能调通接口，而在于能不能把一个系统能力封装成可复用、可授权、可审计、可治理、可被 AI 理解的能力单元。

一个合格的连接器，至少要回答五个问题。

第一，连接什么。

它连接的是飞书、企业微信、钉钉、OA、ERP、CMDB、监控系统、云平台，还是企业自研系统。不同系统的认证方式、对象模型和接口语义完全不同。

第二，暴露什么能力。

同一个系统可以暴露很多能力，比如发送消息、创建审批、查询人员、创建工单、触发流水线、开通资源。连接器不能把所有接口无差别暴露给 AI，而要选择适合企业流程调用的能力。

第三，谁可以调用。

连接器必须接入企业权限体系。普通员工、服务台工程师、系统管理员、审批人、租户管理员可以调用的动作不同，AI 也必须继承这个权限边界。

第四，怎么记录。

每一次调用都要留下操作人、触发来源、参数摘要、审批状态、执行结果和错误信息。没有审计的自动化，在企业里很难被接受。

第五，失败怎么办。

企业系统调用经常会失败：接口限流、网络抖动、权限过期、参数不完整、目标系统维护。连接器必须处理重试、补偿、告警和人工接管。

因此，连接器市场不是 API 文档市场，而是企业能力市场。它把分散系统里的动作抽象成标准能力，再交给流程引擎、AI Agent、工单系统和自动化规则安全调用。

03

企业连接器市场应该具备哪些核心能力？

如果连接器市场要支撑企业级 AI，而不只是做一个演示用的集成列表，我认为至少需要六类能力。

一是统一的能力描述

AI 调用连接器之前，必须知道这个连接器能做什么、需要哪些参数、返回什么结果、有哪些风险、适合什么场景。传统 API 文档是写给工程师看的，AI 需要的是更加结构化的能力描述，包括输入输出、权限级别、幂等性、风险等级和可回滚性。

例如“发送飞书消息”和“重启生产服务器”都可以是连接器能力，但风险完全不同。前者可能只需要普通授权，后者必须有审批、变更窗口、影响范围分析和回滚方案。能力描述不清楚，AI 就无法做出稳妥的调用决策。

二是统一的认证和密钥管理

企业系统的认证方式复杂多样，有 API Key、OAuth、JWT、AK/SK、Webhook Token，也有很多历史系统使用自定义签名。连接器市场不能把密钥散落在脚本和配置文件里，而要有统一的密钥托管、权限隔离、轮换和审计机制。

这件事看似基础，但决定了连接器能否进入生产环境。很多自动化脚本之所以无法规模化，就是因为认证信息不可治理，出了问题也查不到是谁调用了什么。

三是细粒度权限控制

连接器市场必须支持到动作级、对象级、租户级的权限控制。不是“安装了连接器就都能用”，而是不同角色只能调用自己被授权的能力。AI 作为执行者时，也不能拥有超过触发用户或流程规则的权限。

这对于国内企业尤其重要。很多企业的组织层级、审批链、数据边界和合规要求比较复杂，如果连接器不能和 RBAC、多租户、部门权限、数据权限结合，AI 自动化就会变成新的风险点。

四是审计和可追溯

企业愿不愿意让 AI 调用系统，关键不在于 AI 是否“聪明”，而在于出了问题能不能追溯。一次连接器调用，应该能回答：谁触发的、基于哪个工单或流程、AI 为什么决定调用、调用了哪个系统、传了哪些参数、结果是什么、有没有人工审批、失败后如何处理。

没有审计，连接器只是自动化工具；有了审计，连接器才能成为企业治理体系的一部分。

五是低代码扩展能力

任何连接器市场都不可能覆盖企业里的所有系统。尤其在国内，大量企业都有自研系统、历史系统、行业系统和本地化部署软件。连接器市场必须允许企业快速创建自己的连接器，而不是每接一个系统都依赖厂商项目制开发。

更现实的路径是：通用系统提供官方连接器，自研系统支持基于 OpenAPI、Webhook、数据库视图或消息队列快速封装；复杂场景再通过代码扩展。这样既能保证标准化，又能适应企业现场的复杂性。

六是健康检查和运行治理

连接器不是安装完就结束。企业系统会升级，接口会变更，证书会过期，权限会调整。连接器市场必须提供健康检查、调用统计、错误告警、版本管理和灰度发布能力。否则，连接器越多，维护成本越高，最后又会回到脚本失控的老路。

04

连接器、流程引擎和 AI Agent 必须一起设计

如果只看连接器本身，很容易把它做成一个接口调用工具。但在企业 AI 场景里，连接器不能孤立存在，它必须和流程引擎、权限系统、CMDB、知识库、审计系统、AI Agent 一起设计。

以“生产环境数据库慢查询告警”为例，AI 真正要处理这个事件，需要的不只是一个数据库连接器。它可能要从监控系统拿指标，从 CMDB 找到数据库关联的业务服务，从变更系统查询最近上线记录，从知识库检索历史处理方案，从企业微信通知责任人，从 ITSM 创建事件单，从审批系统发起临时变更，从数据库连接器执行只读诊断命令，最后把处理过程写回工单。

这里面任何一个动作都不能随意发生。查询可以自动，变更要审批；低风险通知可以自动，高风险执行要人工确认；普通故障可以走标准流程，重大故障要进入应急流程。连接器负责“能不能调用”，流程引擎负责“什么时候调用”，权限系统负责“谁能调用”，审计系统负责“调用后如何追踪”，AI Agent 负责“在上下文里做判断”。

更准确的架构理解

连接器市场不是 AI 的外挂，而是 AI Native 平台的工具层；流程引擎不是表单流转工具，而是 AI 调用工具的治理轨道。

这也是为什么我不太看好“单点 Agent 工具集”的企业落地模式。个人效率工具可以让 Agent 自己选择工具，但企业系统必须有边界。连接器能力需要被流程、权限和审计包住，AI 才能在可控范围内发挥作用。

05

为什么国内企业更需要开放的连接器生态？

国内企业的信息化环境有几个明显特点：系统类型多，本地化部署多，自研系统多，组织权限复杂，协同工具分散，历史包袱重。一个集团公司内部，可能同时存在 OA、ERP、财务、人力、供应链、项目管理、运维监控、代码平台、云平台、数据平台、客服系统和多个自研后台。

更现实的是，很多企业不是没有系统，而是系统太多；不是没有流程，而是流程割裂；不是没有数据，而是数据无法在流程中自然流动。在这种环境下，AI 要落地，首先要解决连接问题。

如果连接器生态完全依赖闭源厂商，企业会面临几个问题：接入成本高、定制周期长、扩展受限、排障困难、迁移困难。特别是当 AI 自动化越来越深入业务流程时，连接器就不再只是一个技术组件，而会成为企业数字化底座的一部分。底座越关键，企业越需要可控、可审计、可二次开发。

这正是开源连接器市场的价值。它不一定一开始就覆盖所有系统，但它应该提供清晰的规范、SDK、测试方式和贡献机制，让企业、开发者、集成商可以一起建设生态。国内企业常用的飞书、企业微信、钉钉、Webhook、邮件、短信、主流云厂商、监控系统、代码平台、CI/CD 工具，都应该逐步形成可复用连接器。

连接器越开放，企业 AI 才越不容易被某一个厂商或某一种工作流锁死。

06

在开源 AI Native ITSM 项目里的建设路径

我正在做的开源 AI Native ITSM 项目，目标不是一开始就宣称替代成熟商业平台，而是先把企业服务管理的关键底座打稳：工单、事件、问题、变更、SLA、知识库、BPMN 工作流、多租户、权限、AI 分诊、摘要、RAG 知识检索、审计和可部署性。

在连接器方向，目前更准确的定位是“连接器市场雏形和扩展框架正在建设”。项目会优先围绕 ITSM 场景，把连接器做成能被流程和 AI 安全调用的能力，而不是只做一组接口代理。飞书、企业微信、钉钉、Webhook、Console 等通道会作为优先方向，用来支撑通知、审批、告警、工单联动和流程回写等场景。

我希望这个连接器市场最终解决三件事：

第一，让 AI 有受控的工具调用能力。AI 不只是回答问题，而是在权限、流程和审计约束下调用企业系统。

第二，让企业系统集成可复用。一个连接器开发完成后，可以在工单、变更、SLA、告警、审批、知识库等多个流程里复用。

第三，让生态可以共建。企业内部系统千差万别，只有开放规范和插件机制，才可能把连接器做成长期生态。

这个方向不会一蹴而就。连接器市场需要长期打磨：接口规范、权限模型、密钥托管、调用审计、错误处理、版本管理、测试框架、文档和开发者体验，每一项都很具体，也都很重要。但这些基础设施一旦建立起来，AI 才能真正进入企业流程。

结语

企业 AI 的下一步，不是再做一个更漂亮的聊天框，而是让 AI 能在企业流程里安全、可控、可审计地调用系统能力。

连接器市场的价值，就在于把分散的企业系统能力变成标准化、可治理、可复用的能力单元。它连接的不只是 API，更是企业的流程、权限、数据和责任边界。

我们这个开源 ITSM 项目还在早期阶段，GitHub 上已有 30+ Star，很多能力仍在持续建设。但我相信，面向国内企业的 AI Native ITSM，一定不能只做工单和问答，必须把流程引擎、连接器市场、Skill 市场和插件市场放在同一个体系里设计。只有这样，AI 才能从“会说”走向“能做”，并且做得可控。

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

官网：https://cloudmesh.top

我正在做一个开源 AI Native ITSM 项目，目标是面向国内企业构建可私有化、可扩展、可二次开发的 IT 服务管理和流程治理平台。

方向包括：ITIL v3、CMDB、BPMN 工作流、连接器市场、插件市场、Skill 市场、企业 AI 自动化。