引言
10 月 28 日，OpenAI 宣布与 ServiceNow 扩大合作：ServiceNow 的企业上下文和工作流动作将直接进入 ChatGPT，同时 OpenAI 的模型与 Agent 会更深地嵌入 ServiceNow 产品线。官方给出的场景非常具体——一位 IT 值班工程师，不离开 ChatGPT 就能找到相似工单、评估变更风险、更新 ServiceNow 记录。
这不是又一个「AI 写代码」的发布，而是企业软件的入口之争：当对话窗口能直接改工单状态，ServiceNow 的 Web 界面还剩多少存在感？
一、这个集成本质上在做什么
拆开来看是三件事：
1. 上下文注入：把企业自己的 ServiceNow 实例里的工单、CMDB、监控告警读进 ChatGPT，让模型知道「你们公司上周刚因为同一个变更挂过一次」。
2. 动作执行：不只是读，还能写——更新记录、指派团队、发起变更评审。
3. 权限映射（Action Fabric）：这是最不起眼但最关键的一层。官方明确说，Action Fabric 会套用企业既有的业务规则与权限，因此用户能做的动作严格受其组织配置约束。
换句话说，OpenAI 负责「会想」，ServiceNow 负责「谁有资格动手」。
二、为什么权限层比模型层更重要
过去两年企业 AI 落地最大的坑不是模型不够聪明，而是权限边界塌陷：给 Agent 一个 API Key，它就能碰到比这个人权限更大的东西。前面几周我们连续报道的 Agent 越权、审计日志被抹、银行封堵 Agent 类事件，病根都在这里。
ServiceNow 的做法是「不新建信任，只继承既有信任」——你本来就有的权限，AI 代你使用时不会放大。这个设计的价值在于：企业不需要为 AI 重新设计一套权限体系，只需要确认既有体系是健全的。
反过来说，如果一家企业的 ServiceNow 权限本来就配得稀烂（大量人拿着 admin 角色），接入 ChatGPT 只会把历史债务放大到对话窗口里。
三、Codex 的加入意味着什么
官方还提到计划把 Codex 集成进 ServiceNow 的应用开发能力。这一步的意义在于闭环：从「发现问题」到「改配置/写脚本」到「走变更流程」，全部在同一上下文里完成。
对运维团队是效率提升，对变更管理是压力测试——如果 AI 起草的变更单质量高于人类，评审环节会快速退化成橡皮图章。这是需要提前设计防线的地方。
四、评分与建议
综合评分：4.5 / 5
- 场景贴合度：5 / 5（IT 运维是最适合 Agent 的高频场景之一）
- 权限设计：4.5 / 5（继承模型正确，但依赖企业自身配置质量）
- 落地门槛：3.5 / 5（需要 ServiceNow 企业授权 + 流程改造）
- 风险控制：4 / 5（有动作审计，但变更评审可能被弱化）
给三类团队的建议：
已经在用 ServiceNow 的中大型企业：优先选一个低风险流程（比如密码重置、软件安装申请）做试点，验证权限继承是否符合预期，再考虑扩到变更管理。
用 Jira / 飞书 / 钉钉的团队：这个集成对你们暂时没直接价值，但「Action Fabric 式权限继承」这个思路值得抄——不要在 Agent 层重建权限，做透传。
个人开发者：跳过。这是企业级产品，个人场景下 ChatGPT 已够用。
五、我的判断
企业 AI 的竞争焦点，2026 年下半年已经从「模型能力」转向「能不能安全地动手」。OpenAI 找 ServiceNow 而不是自己造工单系统，说明它认了这个现实：动作的合法性来自企业既有制度，不来自模型。
未来一年值得观察的是：当 ChatGPT 能改工单之后，谁对错误动作负责。这个问题目前没有答案，官方文档也没提。
---
*资料来源：OpenAI 官方公告《OpenAI and ServiceNow expand partnership across enterprise workflows》（2026-10-28）。内容经 AI大广场 编辑整理，非赞助内容。*