OpenAI与ServiceNow扩大合作：企业工作流迎来AI代理

OpenAI 与 ServiceNow 宣布扩大双方的合作关系，这次的重点不再停留于模型接入层面，而是双向打通：OpenAI 的模型与智能体将被嵌入 ServiceNow 平台及其工作流中，而 ServiceNow 的工作流能力则反向前置到 ChatGPT 和 Codex 之中。

合作的核心：双向嵌入而非单向调用

以往的厂商合作大多是单向的——把某个大模型 API 接入现有产品，做一个对话入口就结束了。这次 OpenAI 与 ServiceNow 的扩展合作呈现出明显的双向特征。

一侧是 OpenAI 的模型和 agent 能力进入 ServiceNow，直接服务于企业内部的流程运转；另一侧是 ServiceNow 的工作流被引入 ChatGPT 和 Codex，让开发者和知识工作者在 AI 界面中就能触发企业级流程。这种双向设计意味着 AI 不再只是工作流之外的"助手"，而是成为工作流内部的参与者。

对企业用户来说，这一变化的实际意义在于：AI 代理可以调用 ServiceNow 中沉淀的流程规则、工单数据和审批链路，而不是在信息真空中生成回答。

企业工作流为什么需要 Agent

ServiceNow 长期占据企业 IT 服务管理、运营流程编排的核心位置，其平台承载了大量跨部门的标准化流程。这些流程的特点是规则明确、节点众多、依赖上下文——恰恰是传统 RPA 难以灵活处理、而大模型 agent 有机会切入的场景。

把 OpenAI 的 agent 引入这类平台，指向的是流程中的判断与协调环节：理解工单意图、选择合适的处理路径、在多系统之间传递状态。OpenAI 方面将合作表述为把模型和 agent 带入 ServiceNow 及其工作流，ServiceNow 方面则将工作流带入 ChatGPT 与 Codex，两句话合在一起，勾勒的是一个"AI 界面 + 企业流程后端"的组合形态。

Codex 的加入值得关注

值得单独注意的是 Codex 出现在合作范围内。Codex 面向的是代码与开发任务，将其与 ServiceNow 工作流连接，暗示合作不只覆盖业务流程审批，也涉及开发运维侧的自动化衔接。不过素材中并未披露具体的技术集成方式、上线时间或覆盖的产品模块，这些细节仍有待双方后续公布。

RPA（机器人流程自动化） 指通过脚本或软件机器人模拟人工操作界面、在多个系统间搬运数据的自动化技术。它的优势在于处理规则固定、界面稳定的重复性任务，例如自动填表、批量导出报表。但 RPA 的局限也很明显：它依赖预设路径，缺乏对上下文的理解能力，一旦遇到界面改版、非结构化输入或需要判断的分支就会失效。大模型 agent 的差异在于具备语义理解和推理能力，可以读取工单的自然语言描述、推断用户意图、在多个可选路径中做出选择，并把结果传递给下游系统。两者并非简单替代关系——RPA 擅长确定性执行，agent 擅长不确定环境下的判断与协调，企业流程中真正卡壳的往往正是后者，这也是模型厂商把 agent 定位为流程「判断层」的原因。

Codex 最初是 OpenAI 推出的代码生成模型系列，后来演化为面向软件开发任务的智能体产品形态，覆盖代码编写、审查、调试与仓库级操作。把 Codex 与 ServiceNow 工作流打通，技术上的想象空间在于：开发或运维事件（如工单触发的变更请求、故障修复任务）可以由 Codex 直接读取上下文并生成代码改动或修复建议，再回写到 ServiceNow 的变更管理流程中完成审批与记录。这意味着 AI 不只是回答开发问题，而是参与从问题发现到变更落地的完整链路。不过这种跨系统集成通常涉及身份认证、代码仓库权限、审计留痕等工程细节，落地难度显著高于单纯的对话式接入。

对企业的实际影响

从企业采购和架构决策的角度看，这类合作有两个直接后果。

第一，AI 能力的分发渠道正在从"独立 AI 产品"转向"已有企业软件内置"。企业不必再单独搭建一套 AI 系统，而是在既有的 ServiceNow 使用场景中获得 agent 能力。第二，工作流的入口变得分散——员工既可以在 ServiceNow 里用 AI，也可以在 ChatGPT 或 Codex 里发起流程，这对权限管理和数据边界提出了新的要求。

素材没有提供具体的客户案例、可用范围或定价信息，因此目前更适合把这次合作理解为方向性的信号：企业软件与前沿模型厂商的绑定正在加深，agent 进入生产流程的步伐在加快。

企业软件内置 AI（AI embedded in enterprise software） 与 独立 AI 产品 是两种不同的能力分发模式。前者把模型能力直接嵌入企业已采购的系统（如 ServiceNow、Salesforce、SAP），员工在使用原有界面时即可调用；后者则需要企业单独采购、单独集成、单独治理。内置模式的优势在于降低了采用门槛和数据搬运成本，模型可以直接访问系统内已有的流程数据与权限体系；劣势是能力受限于厂商的集成深度，企业可选择的空间变小。当工作流入口分散到多个 AI 界面时，企业还需面对身份联邦、数据驻留、审计日志跨系统对齐等治理问题，这实际上是 AI 进入核心流程后新增的架构成本，而非可以忽略的细节。

一点观察

OpenAI 与 ServiceNow 的合作扩展，反映的是模型厂商向企业纵深渗透的路径选择——不与现有企业软件正面竞争，而是嵌入其中。对 ServiceNow 而言，这是在平台内补齐 AI 能力；对 OpenAI 而言，这是把模型送进企业核心流程的通道。双向嵌入的设计如果能落地，企业工作流的形态可能会从"人操作系统"逐步转向"人下指令、agent 走流程"。这条路径的成败，取决于集成深度与治理能力，而这两点在当前披露的信息中尚未展开。