文章目录
- ServiceNow 插件已经进入 OpenAI marketplace。ServiceNow Action Fabric 会把 ChatGPT 中的请求交给既有业务规则、权限和批准流程处理,而且 ServiceNow 仍然负责执行和治理相关动作。
- ServiceNow 与 Google Cloud 已经把零售、客户关系管理和信息技术工作流标记为正式可用,但是电信工作流仍计划在 2027 年初正式可用。相同聊天入口不能消除不同业务流程的交付状态差异。
- Salesforce 已经提供基础 Agent Kill Switch,并且 Salesforce 计划把 Agent Evals、API Evals 和评估触发的干预能力在 2026 年 11 月至 2027 年 1 月期间分阶段推出。网关阻断仍不一定终止外部平台中的全部进程。
ServiceNow 把聊天入口连接到既有业务规则
OpenAI 与 ServiceNow 在 10 月 28 日公布了合作扩展。新的 ServiceNow 插件允许使用者在 ChatGPT 中查找相似事件、评估变更风险并更新 ServiceNow 记录。ServiceNow Action Fabric 会应用组织现有的业务规则、权限和批准,ServiceNow 仍然是执行和治理这些动作的系统。OpenAI 的公告同时说明,客户可以选择向 ChatGPT 开放哪些 ServiceNow 能力。
两家公司把当前能力与未来能力分开列出。ServiceNow 插件已经进入 OpenAI marketplace,增强能力预计在 2026 年末提供。ServiceNow Super Intelligence Control Tower 的语音能力预计在 2027 年第一季度提供,OpenAI 支持的安全能力预计在 2027 年 1 月进入早期访问并在 2027 年第二季度正式可用,Codex 与 ServiceNow AI Workflow Factory 的集成则预计在 2027 年提供。
对企业落地而言,聊天入口只有在调用既有业务对象、权限和批准流程时才能形成受控动作。企业需要把模型生成的请求转换成明确的主体、目标记录、规范化参数和批准状态,并且企业需要保留 ServiceNow 返回的执行结果。当前可用的插件可以提供连接入口,但是未来安全、语音和开发能力不能提前写入当前验收范围。
Google Cloud 与 ServiceNow 把行业动作划分为不同交付状态
ServiceNow 在 10 月 27 日公布了与 Google Cloud 的行业工作流集成。零售门店运营集成可以报告和诊断设备问题并派遣现场技术人员,客户关系管理集成可以更新机会记录、创建跟进并生成配置与报价,信息技术服务与运营管理集成可以处理事件、变更风险和配置依赖。ServiceNow 把这三类集成标记为已经向共同客户正式可用。
电信网络库存和服务订单管理集成仍预计在 2027 年初正式可用。ServiceNow Action Fabric 通过 Model Context Protocol(模型上下文协议)服务器和 Agent2Agent(智能体到智能体)连接把工作流接入 Gemini Enterprise,而且 ServiceNow 计划通过 Google Cloud Marketplace 发布连接器、演示和参考架构。公告没有提供跨行业错误率、完整服务等级、独立性能结果或所有地区清单。
对企业落地而言,连接协议只能统一调用入口,业务语义仍然来自具体记录、流程、权限和数据关系。企业需要分别验证零售设备、客户机会、信息技术配置项和电信订单等对象的标识、状态变化和回滚规则。企业知识图谱或本体可以帮助系统统一对象关系与业务口径,但是企业仍需用目标系统的权限和执行结果证明每个动作成立。
Salesforce 把评估结果连接到干预动作
Salesforce 在 10 月 27 日公布了 Agent Fabric 的新时间表。Agent Evals 计划在部署前生成测试,并且计划在生产运行中根据质量阈值评估 Agent、模型和 Model Context Protocol 服务器。API Evals 计划根据应用程序接口规范生成函数和性能测试。两项能力都计划在 2026 年 11 月进入测试,并且计划在 2027 年 1 月正式可用。
Salesforce 把基础 Agent Kill Switch 列为已经正式可用,并且 Salesforce 把评估触发的 Agent Kill Switch 列为 2027 年 1 月正式可用。VentureBeat 进一步指出,Salesforce 公告中的零售案例属于假设场景,而且通过网关阻断受治理流量不一定终止外部平台仍在运行的全部进程。Salesforce 的 Custom Agent Scanner 已经进入测试,Open Policies for Federated API Gateways 则已经正式可用。
对企业落地而言,系统发现错误答案、接口变化或费用异常以后,系统还需要把检测结果映射到告警、批准、限流、隔离或恢复动作。企业需要明确干预动作影响的是单次请求、会话、Agent、租户还是外部运行进程,并且企业需要验证恢复授权和审计记录。产品路线可以说明控制层正在缩短发现问题与执行干预之间的距离,但是产品路线不能证明自动干预已经在目标业务中安全运行。
跨平台控制仍依赖身份、资产目录与执行边界
ServiceNow 在 10 月 28 日同时公布了 Control Tower Alliance。该计划的创始成员包括 Anthropic、Amazon Web Services、Cisco、HiddenLayer、Kong、NVIDIA、Okta、OpenAI、Stripe、WitnessAI 和 Zenity。ServiceNow 表示,进入计划的集成方案将接受资格、认证和集成测试。现有公告没有列出每一项已经通过的具体方案、测试方法、失败结果或共同服务等级。
ServiceNow 的公告还把跨平台停止能力写成后续方向。Okta 的引述说明,双方当前工作的目标包括阻止异常 Agent 获得新令牌,而且双方希望进一步推动跨平台停止标准。Salesforce 的公告则把内部环境、第三方平台和不同应用程序接口网关纳入资产发现与策略范围。两家公司描述的是各自产品与合作路线,现有材料没有证明两套控制层已经互操作。
对企业落地而言,一个控制层只有在系统能够识别 Agent 身份、模型、工具、业务对象、应用程序接口和执行位置时才能准确实施策略。企业需要建立统一资产目录与关联语义,并且企业需要让身份撤销、网关阻断、外部进程停止和业务回滚分别留下证据。合作联盟和跨平台愿景可以减少未来集成碎片,但是企业不能把成员名单或计划中的标准当作已经完成的互操作验证。
后续观察
- OpenAI 与 ServiceNow 能否为当前插件公布可由客户复核的权限映射、批准记录、失败模式、服务等级和地区范围。
- ServiceNow 与 Google Cloud 能否使用真实客户负载公布不同行业工作流的成功率、回滚结果、人工批准比例和完整任务成本。
- ServiceNow、Salesforce、Okta 和其他合作伙伴能否证明身份撤销、网关阻断、外部进程停止与业务回滚可以在跨平台环境中保持一致。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准;“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析,不构成对第三方产品的背书。
← 返回每日观察