OpenAI 与 ServiceNow 的合作扩大 ChatGPT 在工作场景中的作用

OpenAI 和 ServiceNow 于 10 月 28 日扩大合作，将业务操作引入 ChatGPT，同时仍由 ServiceNow 的控制机制负责执行。OpenAI ServiceNow partnership 将熟悉的对话界面与管理运营工作的系统连接起来。其重要性在于这种职责划分：员工可以从对话开始，而底层业务平台仍负责约束其操作。

这项公告结合了现已可用的插件与更长期的开发路线图。采购方应区分当前可评估的功能与计划在后续版本发布的能力。将助手连接至公司记录所带来的责任，也不同于让它总结一份文档。

核心矛盾在于界面的便利性与企业内部的可问责性之间。ServiceNow 单独推出的 Gemini Enterprise 集成为这一问题提供了有益对照。综合来看，这些进展表明一种新兴格局：助手竞相成为员工开始工作的入口，而工作流平台则继续承担将工作推进到底的责任。

OpenAI ServiceNow Partnership 当前新增了什么

根据 OpenAI 的企业工作流扩展公告，ServiceNow MCP 插件于 10 月 28 日在 OpenAI marketplace 上线。MCP 即 Model Context Protocol，为 AI 应用与外部工具之间的连接提供了标准化方式。增强版插件功能预计将在 2026 年底前推出。

客户可将 ChatGPT 连接到自己的 ServiceNow 环境，并选择开放哪些功能。OpenAI 表示，ServiceNow 用于公开受治理工作流操作的 Action Fabric 层，会应用现有的业务规则和权限。

这一即时变化为员工提供了进入运营系统的另一入口，但并未将这些系统的权限转移给对话界面。

这一差异很重要，因为回答和操作会带来不同后果。错误的解释可能让读者感到困惑；错误的记录更新则可能影响另一团队的队列、报告或后续决策。

因此，对采购方而言，这项公告提出了一个关于连接范围的实际问题：哪些请求仍仅限于信息查询，哪些请求能够修改业务记录？在员工依赖该集成之前，有效的评估需要清楚展示这条边界。

同样的区别也适用于用户在提出请求后看到的内容。助手可能识别出合适的操作、提交操作，或收到操作成功的确认。这些状态应保持可区分，尤其是在需要他人审批请求时。

这并不意味着对话界面天生不适合业务工作。它改变的是，一场有说服力的演示需要证明什么。当员工无法判断所请求的变更是否真正发生时，流畅的回答就没那么重要了。

这项合作还延续了双方于 2026 年 1 月 20 日宣布的关系。此前的企业 AI 协议强调了在 ServiceNow 内访问 OpenAI 模型，以及语音技术和工作流自动化。

10 月的扩展则增加了反向流动。ServiceNow 的功能可以从 OpenAI 界面访问，使这项合作不再只是向现有应用供应模型的安排。

对员工而言，这可以让工作的起点更灵活。对管理员而言，这也增加了一个需要与组织运营规则保持一致的界面。

因此，ServiceNow ChatGPT integration 最适合被理解为工作起点发生的变化。它是否能改善整个流程，取决于对话提出请求后发生的事情。

评估应跟随该请求直至其最终记录。若止步于看似吸引人的聊天回复，就会错过集成中承担运营责任的部分。

对话成为前门，而 ServiceNow 仍负责执行

ServiceNow 将新的受治理工作流插件描述为一种通过 ChatGPT 调查问题和更新记录的方式。其公告明确表示，ServiceNow 仍是操作执行和接受治理的场所。

一个预览场景涉及值班工程师在协调响应前，审查关联告警、近期变更和受影响服务。这是一种拟议的产品体验，而非独立衡量的客户成果。

这一机制的价值在于将调查与执行连接起来，同时保留可供他人查阅的业务记录。

考虑这一预览所暗示的工作流。工程师需要了解发生了什么变化、哪些服务受到影响，以及谁应当响应。对话可以帮助梳理调查，但事件仍需要明确负责人和可信的状态。

该集成的价值将来自于在这些阶段之间传递相关上下文。如果工程师必须在另一个应用中重新构建调查过程，对话带来的便利就不那么重要了。

反过来，若将每一项对话结论自动复制到事件记录中，则会带来另一种问题。工作假设与已确认的发现用途不同。可靠的实现应帮助用户保留这种区别。

这正是为何界面问题不能与记录管理问题割裂开来。员工需要空间来探索不确定的可能性。运营记录则需要足够清晰，以便未参与原始对话的同事能够理解。

这种职责划分也有助于解释两家公司的动机。OpenAI 获得了让用户继续在其界面内工作的理由。ServiceNow 则获得了另一条进入其平台治理下工作流的路径。

这些动机可以彼此一致，而不使任何一家公司处于次要地位。助手处理人员表达意图时所进行的交互；工作流系统则应用该意图转化为操作所需满足的组织条件。

对企业采购方而言，这种安排挑战了一个关于软件采用的常见假设。员工可能经常使用某应用的功能，却不打开其传统界面。使用方式可能发生变化，而底层运营依赖仍然存在。

这会给那些仅出售便利性的供应商带来压力。如果助手能够提供用户偏好的界面，底层应用就必须通过业务逻辑、可靠记录和执行能力来证明其价值。

这是基于该架构作出的解读，而非已披露的商业结果。公告并未说明采购决策或应用使用情况将如何变化。

不过，它确实为采购方提供了一种评估该方案的具体方法：跟踪一个事件，从最初的问题到调查、获授权的更新及确认完成。

当这条链路变得更容易追踪时，ServiceNow ChatGPT integration 就值得关注。更短的对话只有在负责事件的人员仍能理解发生了什么时才有用。

Gemini Enterprise 表明这是一项分发战略

OpenAI 的扩展紧随 ServiceNow 于 10 月 27 日宣布相关 Google Cloud 合作之后。该Gemini Enterprise 集成同样将对话交互与 ServiceNow 工作流连接起来。

ServiceNow 描述了已正式发布的 IT、零售运营和客户关系管理集成。电信集成预计将于 2027 年初推出。该公告将 Action Fabric 置于 Gemini Enterprise 与底层工作流能力之间。

ServiceNow 正在将其覆盖范围扩展至多个助手，使界面成为一种分发选择，而非其平台唯一的归属。

这一对照改变了读者解读 OpenAI 协议的方式。访问业务工作流很有价值，但更广泛的战略并不依赖于 ChatGPT 成为每位员工的首选助手。

对 ServiceNow 而言，支持不同界面可以使其在员工从任何地方开始工作时保持相关性。对助手提供商而言，连接成熟的工作流平台，则提供了进入业务流程的路径，否则它们需要分别完成整合。

两种安排都不意味着所有助手会提供等同的功能。采购方不应将共享合作伙伴的名称视为功能覆盖、管理控制或发布成熟度一致的证据。

有意义的比较在于所完成的任务。获授权的员工能否获取必要信息、理解拟执行的操作，并验证其结果？不同界面需要凭借各自的能力回答这些问题。

这也将模型竞争与工作流竞争区分开来。模型可以给出有用的解释，却没有修改业务记录的权限。工作流系统可以执行权限控制，却未必提供员工偏好的交互方式。

这项合作将这些功能结合起来，但并未抹去它们之间的差异。这为两个层面的竞争留下空间：助手理解意图的能力，以及平台执行意图的可靠性。

企业架构团队面临由此产生的协调问题。支持多个助手可以带来灵活性，同时也提高了跨入口维持一致规则的重要性。

审批要求不应因员工切换界面而变得模糊。同事也不应收到关于同一运营记录相互矛盾的描述。

这些是评估标准，而非任何一项集成已报告的缺陷。它们源于通过多个对话产品公开共享业务能力这一做法。

竞争背景也缓和了关于替代的说法。助手获得用户注意力，并不自动意味着取代维护组织状态的应用。

与此同时，保留底层工作流并不保证拥有与员工之间的关系。界面提供商可以影响人们在哪里搜索、调查，以及决定下一步做什么。

OpenAI ServiceNow partnership 正处于这场协商之中。其即时影响是扩大访问；其战略含义则是将员工交互的地点与企业执行的地点分离开来。

这种分离让客户有更多可比较的维度，而不只是回复质量。他们可以评估权限延续性、结果清晰度，以及在偏好工作环境中的一致性。

Codex 将合作扩展到应用构建

计划中的 ServiceNow Codex 集成将把 OpenAI 的编码代理引入 ServiceNow 的应用开发环境 AI Workflow Factory。OpenAI 模型也计划用于 Build Agent 和 Autonomous Engineer。

两家公司预计，AI Workflow Factory 中的 Codex 将于 2027 年推出。它们还计划在 2027 年 1 月开放安全功能的早期访问，并于第二季度正式全面推出。

ServiceNow 的 Super Intelligence Control Tower 语音功能预计将于 2027 年第一季度推出。拟议的体验将帮助用户描述 AI 使用场景，并提供风险评估所需的信息。

这些计划将双方的合作从执行既有工作，扩展至创建和维护定义这些工作的系统。

对开发者而言，这与生成一项孤立的代码变更并非同一回事。业务应用的责任不止于代码能否运行。它还需要体现谁可以执行哪些操作，以及请求如何在人与人之间流转。

因此，ServiceNow Codex 集成在分析层面的吸引力，在于能够接触到应用所处的业务环境。当编码助手能够处理变更周围的约束条件时，其价值会更高。

这种价值仍需接受评估。生成的变更需要让维护它们的人员能够理解，尤其是在涉及权限或运营流程时。

一次成功的演示应当将所请求的业务行为与最终产生的应用行为联系起来。证明代理生成了代码，远不如证明应用正确处理了预期流程更有说服力。

安全计划也带来了类似的上下文问题。发现潜在漏洞与决定组织应如何应对，是相关但不同的任务。

优先级取决于受影响的系统及其运营重要性。修复还需要明确负责人、合适的变更流程，以及确认根本问题已经得到解决。

两家公司拟议的组合之所以值得关注，是因为它将安全分析与组织上下文关联起来。它是否能带来更好的决策，仍有待部署实践和可独立评估的结果来验证。

语音则为同一主题带来了另一种变化。说话可能让信息提供更为容易，特别是在表单要求用户跨多个回答提供背景时。

然而，更简便的输入方式并不能证明由此产生的评估一定正确。用户仍需审查系统所理解的内容，并解决缺失或含糊的细节。

该产品路线图围绕一个共同理念展开：在受治理的环境中，将人的意图转化为结构化工作。编码、安全调查和口述评估，分别以不同方式应用了这一理念。

买家在评估路线图时应保留这些差异。插件能够用于事故更新的证据，并不能证明未来编码或安全集成已具备就绪条件。

计划中的功能应纳入战略评估。采购和部署决策仍应与可供评估的具体产品保持关联。

权限解决授权问题，而准确性仍是另一个独立问题

该合作对业务规则和权限的强调，回应了一项关键的企业需求。但这本身并不能解答 AI 指导操作质量的所有问题。

一项操作可以获得授权，但仍可能有误、不完整，或不适合当时的情境。

一名员工可能有权限更新多条事故记录。系统仍需要识别目标记录，并理解所请求的变更。权限确立的是授权，而不是意图。

这种区别是该方法在分析层面的局限，而非宣布的插件存在失败的证据。它说明组织应在评估访问控制的同时评估决策质量。

含糊的请求提供了一个有用的测试。员工可能会提到“之前那起事故”，而有多条记录都符合这一描述。可靠的交互应当在进行具有后果的更新前消除这种歧义。

部分完成同样值得关注。一项请求可能涉及检索信息、提出变更建议和提交更新。如果后续阶段失败，员工需要准确了解哪些步骤已完成。

这很重要，因为对话式语言可能让未完成的流程听起来仿佛已经尘埃落定。买家应检查助手的表述与运营系统已确认状态之间的关联。

同一原则也适用于需要审批的操作。已提交的请求和已获批准的变更是不同的结果。界面应当清楚传达这种区别，而不应要求用户自行推断。

这些是验收测试中的实际问题。它们不要求预先假定集成缺乏防护措施，而是要求客户请供应商展示这些防护措施在现实条件下如何运作。

公开公告强调功能与预期收益，但没有提供独立测量数据，以证明该集成对事故解决、错误率或管理工作量的影响。

这些缺失的测量数据限制了读者能够得出的结论。可用的集成意味着有机会评估某个工作流，但并不证明该工作流能够改善每一家组织的运营。

该推广也带来了知识边界问题。个人笔记与组织的正式记录都可以帮助人们理解问题，但二者具有不同的权威性。

思考这一区别的读者，可以在决定哪些信息应纳入运营流程之前，了解个人知识库。

私人观察可以为调查提供参考，而不必成为经组织批准的结论。保持这种区别清晰可见，有助于同事理解哪些内容值得依赖。

因此，更广泛的挑战是贯穿整个交互过程的问责性。组织需要知道哪些信息支撑了一项拟议操作、谁授权了它，以及业务系统接受了什么。

这些要求应从一开始就塑造评估方式。若等员工养成信任对话式确认的习惯后再加入这些要求，过渡将更难管理。

OpenAI 与 ServiceNow 的合作提供了一种将辅助能力与受治理执行结合起来的架构。它是否适合某项具体业务，取决于该架构能否清晰处理日常的不确定性。

关注交付、运营证据与各类助手之间的一致性

下一阶段应通过产品交付和可观察的使用情况来判断。广泛承诺指明方向，而发布细节和部署证据则决定客户能够依赖什么。

最有价值的信号涉及能力、问责性，以及员工工作场景中不同入口之间的一致性。

第一个信号是预计于 2026 年底前发布的增强版插件。买家应寻找有关可用操作、管理控制和确认行为的具体文档。

若某次发布清晰界定这些边界，将增强受控部署的理由。若发布重点仅在界面演示，则对运营就绪度提供的证据会较少。

即使演示令人信服，这一区别仍然重要。经过准备的示例可以展示预期体验，但管理员还需要了解，当请求不完整或权限不同时，产品将如何表现。

第二个信号是合作伙伴公司内部使用的证据。ServiceNow 计划向全体员工提供 ChatGPT Work 和 Codex，而 OpenAI 表示其内部使用 ServiceNow 工作流。

开放访问与实际采用是不同的衡量指标。向全体员工提供服务可证明覆盖范围，而在相关任务中的持续使用，则能更有力地说明实际价值。

更有用的证据应将采用情况与可识别的工作流结果联系起来。读者应关注定义清晰的任务，以及如何评估完成情况或质量的说明。

这些结果仍需谨慎归因。部署后的改善并不会自动揭示新流程中的哪一部分促成了改善。

第三个信号是不同助手集成之间的一致性。随着 ChatGPT 和 Gemini Enterprise 提供 ServiceNow 功能，客户可以比较各个界面如何处理共同的运营要求。

一致的权限和可理解的结果，将支持 ServiceNow 通过不同助手触达员工的战略。行为不一致则会让管理和员工指导变得更具挑战。

ServiceNow 有商业理由推动这一方法成功。在其季度经营业绩中，该公司报告称，年初至今，生产环境中的代理式 AI 消费量同比增长超过 13 倍。

代理式 AI 指的是朝着完成任务采取行动的系统，而非仅生成回应。所报告的增长属于公司整体背景，并非对这项新宣布集成的衡量。

对读者而言，其含义是要区分各个层面的证据。一个不断增长的类别并不能证明某一特定产品的质量，而一款前景可期的产品也不能证明组织范围内的成果。

OpenAI 与 ServiceNow 的合作值得从实用角度解读：将当前可用的工作流与团队现有工作流进行比较。请管理员演示一次获准更新、一次含糊请求、一次被拒绝的操作，以及一次中断的流程。将每个示例一路追踪至业务记录。在评估中保留未来的编码、语音和安全计划，同时让当前决策基于你能够检查的功能。然后考虑员工是否以更少的重复完成任务，并且更清楚地了解发生了什么。哪一种运营流程会受益于对话式入口？在依赖它之前，团队又需要哪些证据？