为什么企业上了几十套 SaaS，AI 还是调不动任何系统？

云与数字化 | 企业 AI、连接器、流程执行与开源 ITSM

企业 AI 落地最尴尬的地方，不是模型不会回答，而是它回答完以后，调不动任何系统。

几十套 SaaS 把业务搬到了线上，但没有把企业能力变成 AI 可以安全调用的工具。

很多企业这几年上了大量 SaaS：飞书、企业微信、钉钉、CRM、ERP、OA、项目管理、财务系统、报销系统、监控系统、客服系统、营销自动化、数据看板、云平台控制台。每个系统单独看都比过去好用，表单更漂亮，流程更线上化，通知也更及时。

但到了 AI 时代，一个很现实的问题出现了：当企业希望 AI 不只是回答问题，而是真的帮人完成工作时，它经常什么也做不了。它可以告诉你“应该创建一个工单”，但不能真正创建；可以建议“需要通知负责人”，但不知道负责人是谁；可以判断“这个变更有风险”，但无法读取 CMDB、审批流和历史事件；可以生成一段流程说明，但没有权限触发任何流程。

这不是模型能力不足，而是企业系统能力没有被组织成 AI 能调用、能审计、能授权、能回滚的工具层。

01

SaaS 解决的是“人怎么用系统”，不是“AI 怎么调用系统”

过去十年，SaaS 帮企业解决了很多问题。以前靠 Excel、邮件、微信群和线下签字完成的工作，逐渐迁移到了在线系统。销售在 CRM 里跟进客户，员工在 OA 里提交审批，研发在项目管理工具里推进任务，运维在监控平台里处理告警，财务在报销系统里做审核。

这些系统的核心设计对象是人。它们让人登录、点击、填写、审批、查看、导出。即使有 API，也往往是给系统集成或二次开发用的，而不是给 AI 直接执行业务动作设计的。

AI 需要的不是一个能点的页面，而是一组明确的工具：这个工具能做什么，需要什么输入，返回什么结果，调用前需要什么权限，调用后留下什么审计记录，失败时如何重试，产生副作用时谁负责。

SaaS 的页面是给人操作的，AI 需要的是可控工具。

企业没有工具层，AI 就只能停留在建议层，无法进入执行层。

02

企业系统越多，AI 反而越难执行

很多人会以为，企业系统越多，AI 可调用的能力就越多。实际情况常常相反：系统越多，身份越分散，权限越复杂，数据口径越不一致，流程边界越模糊，AI 越不知道该调用哪个系统。

比如一个员工说：“帮我申请一台新的开发机器。”这句话听起来很简单，但在企业内部可能涉及很多系统。要先判断员工所在部门和岗位；再判断是否有预算；再查资产库存；再走审批；再通知 IT；再更新 CMDB；再同步财务资产；最后可能还要在飞书、企业微信或钉钉里通知申请人。

如果这些动作分散在十几个系统里，AI 不是不知道该怎么回答，而是不知道该怎么安全执行。它缺少统一的对象模型、权限模型、流程模型和审计模型。

这也是为什么很多企业做 AI Agent 的时候，原型看起来很漂亮，进入真实业务就卡住。演示环境里，Agent 可以调用一个模拟 API；生产环境里，它面对的是多个账号体系、不同审批规则、跨部门权限、历史数据质量和审计责任。

03

API 不等于工具，接口代理也不等于连接器

很多企业已经有 API，但 AI 仍然调不动系统，原因是 API 只是技术入口，不等于业务工具。

一个 API 可能叫 /create，但它到底创建什么？谁可以调用？参数缺失怎么办？重复调用会不会创建两次？调用失败后是否需要补偿？这个动作是否会触发审批？生成的数据归属哪个租户？是否需要写入审计日志？这些问题不解决，AI 就不能直接调用。

企业需要的连接器，不是把 HTTP 请求转发出去的接口代理，而是把外部系统能力封装成可描述、可授权、可观测、可审计的业务工具。

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

它能执行什么能力？

需要什么权限和凭据？

输入输出结构是什么？

失败、重试、幂等怎么处理？

调用记录如何审计？

能否被流程引擎和 AI 安全编排？

04

真正缺的是企业能力地图

企业上了几十套 SaaS，但很少有人能回答一个简单问题：我们公司到底有哪些能力可以被系统调用？

能不能创建工单？能不能查询资产？能不能触发审批？能不能发消息给指定岗位？能不能查询某个客户的合同状态？能不能检查预算？能不能暂停一个云资源？能不能把告警转成事件？能不能根据变更单自动找到影响范围？

这些能力分散在不同系统里，但企业缺少一个统一的能力目录。没有能力目录，AI 就没有工具清单；没有工具清单，就没有可靠执行；没有可靠执行，AI 就只能停留在问答和写作。

所以连接器市场真正有价值的地方，不是把 SaaS 名字列成一个目录，而是把企业内部和外部系统的能力整理成一张“企业能力地图”。这张地图告诉 AI：哪些动作可以做，哪些动作不能做，哪些动作需要审批，哪些动作只允许查询，哪些动作必须由人确认。

05

AI 调系统之前，企业必须先解决权限和责任

企业 AI 最危险的不是回答错，而是执行错。回答错可以纠正，执行错可能会改数据、发通知、触发审批、影响业务，甚至造成合规风险。

所以 AI 调系统之前，必须先回答权限和责任问题。AI 是以谁的身份调用？是员工本人、部门管理员、系统机器人，还是某个服务账号？调用动作的权限来自哪里？谁批准？谁能撤销？谁对结果负责？

这就是为什么企业 AI 不能只靠提示词治理。提示词可以提醒模型“不要做危险动作”，但真正的控制必须落到系统层：RBAC、租户隔离、审批流、审计日志、凭据管理、动作白名单、人工确认、异常回滚。

AI Agent 进入企业系统，首先不是智能问题，而是治理问题。

没有权限、审计和责任边界，越强的 AI 越不能放心使用。

06

这件事和 RPA、自动化脚本有什么不同

有人可能会问：企业以前不是已经做过 RPA、自动化脚本、接口集成了吗？为什么现在还要讲连接器和工具层？

区别在于，RPA 和脚本更多解决的是“把一个固定动作自动跑起来”。它适合处理规则稳定、界面变化不大、风险边界清楚的重复任务。比如定时导出报表、批量录入数据、跨系统搬运字段。

企业 AI 面对的是另一类问题：用户表达不固定，任务上下文会变化，执行路径需要判断，调用哪个工具也可能取决于权限、风险、当前流程状态和历史信息。它不是简单重复一个脚本，而是在多个工具之间做受约束的决策。

所以 AI 需要的工具层，不能只是“我能调用某个接口”。它还需要描述工具语义、风险等级、权限范围、输入输出、幂等约束、回滚方式和审计字段。只有这些边界清楚，AI 才能在系统允许的范围内执行，而不是靠提示词猜测。

RPA 更像把人的固定操作录下来，企业 AI 工具层更像把企业能力整理成可治理的动作。

一个面向页面，一个面向流程和权限；一个偏自动化，一个偏可控执行。

07

为什么 ITSM 是企业 AI 调系统的好入口

企业 AI 要调系统，不能一上来就直接操作所有业务系统。更合理的入口，是从流程、工单、审批、资产和知识库这些可审计的场景开始。ITSM 正好处在这个位置。

ITSM 天然处理“请求、分派、审批、执行、反馈、关闭”这类闭环。它记录谁发起、谁处理、谁审批、什么时候执行、结果是什么。它连接事件、问题、变更、发布、服务请求、服务目录、SLA、CMDB 和知识库。对 AI 来说，这些都是非常重要的上下文。

如果一个 AI 要辅助处理故障，它需要知道告警来自哪里、受影响资产是什么、历史是否发生过类似事件、知识库里有没有处理方案、谁有权限执行变更、是否需要 CAB 审批、SLA 是否即将违约。所有这些信息，都和 ITSM 的对象模型有关。

所以我做开源 AI Native ITSM，不是因为工单系统本身多新，而是因为它是企业 AI 从“问答系统”进入“可控执行系统”的一个现实入口。

08

开源 ITSM 里的连接器，应该怎么设计

在当前项目里，连接器还在建设中。我不想把它写成已经成熟的生态。比较准确的状态是：项目已经有连接器运行时接口、Manifest、自描述能力、健康检查、消息结构、生命周期 DTO，也有飞书连接器配置文档；连接器市场 v1，包括飞书、钉钉、企业微信、Webhook 等，仍在后续版本持续推进。

我认为开源 ITSM 的连接器设计，不能只做“接入某个 SaaS”。它应该把每个外部系统封装成可安装、可配置、可健康检查、可审计、可被流程和 AI 调用的能力包。

比如飞书连接器，不应该只是“发一条消息”。它应该能描述自己支持哪些能力：发送消息、发送卡片、接收事件、同步用户、触发审批、同步任务、处理回调。它还需要声明配置项、权限范围、凭据字段、健康状态、最后一次错误和生命周期状态。

这些看起来是工程细节，但决定了 AI 能不能安全使用它。没有 Manifest，AI 不知道工具能力；没有权限声明，系统不知道谁能调用；没有健康检查，流程不知道连接器是否可用；没有审计，企业不知道动作是谁触发的。

09

当前项目能做什么，不能做什么

我也想把开源 ITSM 项目的边界讲清楚。当前项目已经具备 ITIL 核心流程、工单、事件、问题、变更、发布、服务请求、服务目录、SLA、知识库、BPMN 工作流、RBAC、多租户、Docker Compose 部署等基础能力，也已经在连接器方向做了运行时接口、Manifest、自描述能力、健康检查和生命周期结构。

但这不意味着它现在已经拥有一个成熟的连接器生态。飞书、钉钉、企业微信、Webhook 这些连接器市场能力仍然在持续推进中；AI 自动执行也不应该在早期就被夸大。更准确的说法是：项目正在把 ITSM 从一个流程系统，逐步扩展为企业 AI 可以调用的流程和工具底座。

这件事必须慢一点。因为一旦 AI 进入企业执行链路，就不能只追求“能跑”。它还要看权限是否正确、审计是否完整、失败是否可处理、数据是否隔离、连接器是否健康、流程是否可回溯。企业级系统最怕的是 demo 很顺，生产很乱。

所以我宁愿把路线图说得保守一点：先把对象模型、流程引擎、连接器契约、权限边界和审计结构打牢，再逐步让 AI 参与更多动作。这样走得慢，但更接近企业真正愿意使用的系统。

10

为什么企业自己也需要内部工具市场

很多企业未来不一定只依赖外部软件厂商提供连接器。越大的企业，内部系统越多，定制流程越多，安全边界越复杂，最终一定会需要自己的内部工具市场。

这个市场里不只是 SaaS 连接器，也包括内部 API、流程模板、自动化脚本、查询工具、审批动作、数据同步任务、知识检索 Skill。它们统一被登记、审核、授权、发布、调用和下线。

这件事对企业 AI 很关键。一个 Agent 能不能真正进入生产，不取决于它会不会写漂亮的自然语言，而取决于企业有没有一组可靠工具可以给它用。工具越可靠，权限越清晰，审计越完整，AI 的边界就越清楚。

从这个角度看，连接器市场不是 SaaS 目录，而是企业 AI 的基础设施；内部工具市场也不是开发者玩具，而是企业把系统能力变成 AI 可调用能力的组织方式。

11

企业现在应该先看什么

企业现在不一定马上要做一个完整的连接器市场，但可以先检查几件很具体的事。

第一，企业内部有哪些高频、低风险、重复性的动作，可以先封装成工具。比如创建工单、查询知识库、发送通知、查询资产、创建任务、读取审批状态。这些动作适合成为 AI 的第一批工具。

第二，哪些动作绝不能让 AI 自动执行，只能给建议。比如删除资产、修改财务数据、关闭生产告警、自动批准高风险变更、调整权限。这些动作必须保留人工确认和审计。

第三，企业是否有统一的身份和权限体系。如果每个 SaaS 都有自己的账号和权限，AI 调用系统时就很难确定身份边界。未来无论做 Agent 还是自动化，身份治理都是基础。

第四，调用结果是否能回写到流程里。AI 执行了什么，不应该只停留在聊天记录里，而应该进入工单、审批、事件、变更、知识库或审计日志。只有这样，企业才知道工作真的发生了。

结语

企业上了几十套 SaaS，并不等于 AI 就能调动几十套系统。

SaaS 把人的工作搬到了线上，连接器和工具层要做的是把企业能力变成 AI 可以安全调用的动作。中间缺的不是一个聊天框，而是对象模型、权限边界、流程编排、健康检查、审计记录和失败处理。

未来企业 AI 真正落地，不会只发生在模型层，而会发生在连接器、流程、权限和工具市场这些看起来不那么热闹、但决定系统能不能执行的基础设施里。