从"问 AI"到"让 AI 改工单"：OpenAI 和 ServiceNow 这次交换了什么

【摘要】10 月 28 日，OpenAI 和 ServiceNow 扩展了 1 月开始的合作。表面上这是一条产品公告，但真正值得注意的是它的形状：现在唯一上线的东西是 ServiceNow 的 MCP 插件——让 ChatGPT 直接去改 ServiceNow 的工单记录、评估变更风险、分派值班团队。而 ServiceNow 那边没有给 ChatGPT 开新的权限，它用的是 Action Fabric——平台自己已经在执行的那套业务规则和权限。模型不获得更宽的权限，它继承平台已有的权限。 这条设计在 agent 权限设计里并不常见，也顺手把"分发渠道"这件事推到了一个新的位置。

目录

一、当下唯一上线的东西是什么
二、Action Fabric：整份公告里最被低估的一句话
三、但反过来也成立：先收紧角色，再接 ChatGPT
四、这是一条新的写路径，审计要跟上
五、为什么用 MCP 做交付
六、三条产品线里，只有方向没有产品
七、"分发渠道"这个位置在变
八、这份公告没说的四件事

一、当下唯一上线的东西是什么

先把"已上线"和"计划中"分开。这份公告里最容易犯的错，是把两者混成一句"OpenAI 和 ServiceNow 深度合作"。

现在就能用的，只有一个东西：ServiceNow 的 MCP 插件，在 OpenAI 的 marketplace 里。

它做的事，用 OpenAI 自己的话说，是"bring business context and workflow actions directly into ChatGPT"。具体到场景：一位 IT 工程师在 ChatGPT 里提问，然后——

• 找到相似的历史 incident
• 评估某次变更的风险
• 更新 ServiceNow 上的记录

全程不离开 ChatGPT。

同时 ServiceNow 还在 preview 一类"交互式体验"：值班工程师在 ChatGPT 里看到关联的监控告警、近期变更、受影响的服务，然后分派给正确的团队、推进修复、关掉工单。

这两者的区别在于写操作的比重：前者是"查了再更新记录"，后者是"在一个界面里走完整个值班流程"。

二、Action Fabric：整份公告里最被低估的一句话

OpenAI 公告里的原话：

Customers connect ChatGPT to their own ServiceNow instance and choose which capabilities to make available. ServiceNow’s Action Fabric applies existing business rules and permissions, so the actions people can take reflect your organization’s configuration and access.

我把关键部分拆开看：

“choose which capabilities to make available” —— 客户自己选暴露哪些能力。这不是全量接入，是白名单。

“applies existing business rules and permissions” —— 执行的时候套用的是既有的业务规则和权限。

“the actions people can take reflect your organization’s configuration and access” —— 人在 ChatGPT 里能做的事，反映的是他在 ServiceNow 里的角色本来就允许的事。

这就是整份公告的技术核心，而它只有一句话的长度。

模型没有获得一套新的、更宽的权限。它继承平台已有的权限。

我要强调这一点，因为 agent 集成里最常见的错误设计恰恰相反：给 agent 开一条平行的、通常更宽的权限通道——因为现成的权限系统"不好对接"，于是图省事绕过去。绕过去的后果是，你的权限模型有两套真相，而人只熟悉其中一套。

ServiceNow 的做法是把 agent 当成又一个客户端。ChatGPT 就是一个新的 ServiceNow 前端，权限判定逻辑完全没变。这在架构上是省事的，在安全上却是正确的。

对比一下：GitHub 那批发布里，Copilot Automations 也做了类似的事——共享自动化以 Copilot 身份行动，并因此需要额外一次人工批准。两边独立地选了同一条路：不因为接入方是 AI 就放松权限判定，而是让它继承原有身份，再补一道专门的闸。

三、但反过来也成立：先收紧角色，再接 ChatGPT

上一节那个设计的另一面，是一句必须一起听的话。

如果 ChatGPT 里的能力 = 你在 ServiceNow 里的角色，那么：

任何过于宽泛的 ServiceNow 角色，都会变成过于宽泛的 ChatGPT 能力。

我见过太多团队做这件事的顺序是反的：

❌ 常见顺序：接入 ChatGPT → 觉得挺好用 → 后面发现权限太宽 → 再回来收紧
✅ 正确顺序：先审计 ServiceNow 角色 → 收紧 → 再接入

原因很简单。接入之后，ChatGPT 成了这个角色权限的放大器——以前一个运维要手动查工单、慢慢点，现在一句话就能把该角色能做的所有事做完一遍。

权限没变，但权限的使用速度和覆盖面变了。 一个原本"理论上有点宽"的角色，接入之后会立刻变成"实际上很危险"。

所以这条公告真正的落地顺序应该是：先做一遍角色审计，把宽的收掉，再接。

四、这是一条新的写路径，审计要跟上

第三点，也是运维视角最容易忽略的一点。

"在 ChatGPT 里更新 ServiceNow 记录"很方便。但这条操作路径是新的：

• 之前：变更发生在 ServiceNow 的工单界面里，工单的活动日志记下了谁改的
• 现在：变更的发起发生在 ChatGPT 里

ServiceNow 那边大概仍然会记下这次变更（因为执行还在它那边），但发起者是谁、当时的对话上下文是什么、agent 依据什么做了判断——这些在 ChatGPT 那一侧。

这不是说它不安全，但审计的拼图变成两块。如果你的合规要求是"能解释某次工单变更为什么发生"，你可能需要：

1. ChatGPT 侧的会话记录（谁在什么上下文里提了这个请求）
2. ServiceNow 侧的活动日志（变更实际落了什么）

而且别忘了上一节那个透明性：ChatGPT 侧的会话内容，按 OpenAI 的条款，是留在 OpenAI 那边的。

五、为什么用 MCP 做交付

公告没强调这点，但它是理解整件事的关键之一。

ServiceNow 在 ChatGPT 里的集成，交付形式是 MCP 插件——一个标准连接器，在 OpenAI 的 marketplace 里可以装。

这意味着：它不是一家一家的定制对接。 任何有 MCP 客户端的 agent 宿主，理论上都能装这个插件。ServiceNow 的业务上下文（工单、资产、身份、权限）通过标准协议暴露出去。

这跟过去两年的 MCP 生态是同一个方向：协议层标准化，让厂商能把差异化的业务能力打包成标准插件。

（顺便，这跟我上一期写的 Agent Skills 捐给 Linux 基金会下的 AAIF 是同一件事的两面。Skills 标准化了"知识怎么打包"，MCP 标准化了"能力怎么暴露"。一个 agent 的运行时由这两层组成：知识层（skill）+ 能力层（MCP 工具）。当两层都标准化了，厂商的竞争就回到了"我的业务上下文对不对、我的知识准不准"上。）

六、三条产品线里，只有方向没有产品

除了 MCP 插件，OpenAI 规划了三条线，全部是计划：

① 应用开发
Codex 集成进 ServiceNow 的 AI Workflow Factory，让开发者带着 ServiceNow 的业务上下文和平台能力去建应用。OpenAI 模型还会驱动 Build Agent 和 Autonomous Engineer。

② 安全
联合安全方案，把 OpenAI 的安全模型能力和 ServiceNow 的资产、身份、业务上下文结合起来——识别漏洞、排定优先级、协调修复。

这个方向有个值得注意的量级：ServiceNow 的说法是，一次代码库扫描可能发现 1 万到 10 万个现有或合成的安全漏洞。"哪些最紧急"才是真问题。

③ 语音
ServiceNow 的 Super Intelligence Control Tower 里用 OpenAI 的语音模型。人用嘴说一个 AI 用例，agent 把它填进评估表、追问缺失信息、自动打风险评级。

时间表（OpenAI 官方口径）：

只有第一行是现在能用的。其余全是 2027 年的意图。

七、"分发渠道"这个位置在变

这份公告真正的战略意义，可能不在功能，在结构。

过去的分发链是：模型公司 → 云厂商 → 开发者。模型是上游，云是通道。

这次多了一条：模型公司 ←→ 企业工作流厂商。

ServiceNow 不是模型供应商，也不是云厂商。它手里握的是 IT 工单、资产目录、身份、权限、业务规则——这些恰恰是 agent 真正需要、而且模型自己造不出来的东西。

而 OpenAI 那边的动作也印证了这一点：OpenAI 说自己在自己的运营里用 ServiceNow 的工作流。 反向也打通了。

再叠上别的信号：Uber 把 3 万名员工迁到 ChatGPT Work，Oracle 把 OpenAI 产品嵌进自己的应用。现在 ServiceNow 也把 ChatGPT Work 和 Codex 给到全体员工（之前只有工程部门）。

当一个 agent 需要碰真实业务系统时，谁掌握那个系统的入口，谁就掌握 agent 的落地渠道。 模型公司有模型能力，但碰不到工单；工作流厂商没有最强模型，但站在了必经之路上。

这可能才是"企业工作流厂商正在成为前沿实验室的新分发渠道"这句话的意思。

八、这份公告没说的四件事

按重要性排：

① 没有任何效果数据。 没有 benchmark，没有实测节省时间，所有用例都是例子。explainx 那篇整理得很清楚——“The use cases are examples, not results”。

② 没有定价、合同金额、席位数。

③ 没有说明记录过 ChatGPT 时的数据处理细节，除了权限模型这一层。具体哪些字段被送过去、留存多久、能不能用于训练，公告里没写。

④ 没有列出插件暴露了哪些 ServiceNow 能力。 你没法从公告判断接进来之后 agent 能碰到多大范围。

一句话：这份公告里唯一真正有技术含量的，是 Action Fabric 那一句——让 agent 继承平台已有的权限，而不是另开一套。这条设计让"接一个 AI 到工单系统"这件高风险的事，变成了一个权限模型完全不变的前端改造。至于其余六条产品线，目前都还是意向。

留言区：如果你们公司用 ServiceNow 或类似的工作流平台（ServiceNow、Jira、ServiceNow 的竞品都行），你们会怎么安排接入顺序——先收紧角色再接，还是接了再收紧？如果有已经接过的，说说实际踩到了什么。