ServiceNow×Genesys对谈：A2A+MCP协议下，客服AI从单点智能走向跨平台编排

山止川行AI 前沿2026-09-18626 阅读💛 132 收藏

一句话结论

ServiceNow 全球 CRM 战略合作总监 Rob Otto 在这支对谈里给出两个关键判断：第一，AI 落地的真正障碍不是模型能力而是数据位置——大型企业平均有 300-350 个应用，人人都有自己的 AI，但这些 AI 互不通信，数据孤岛被 AI 反而放大了；第二，下一波浪潮是智能体编排（agentic orchestration），A2A（agent-to-agent）和 MCP（模型上下文协议）会让跨平台的智能体协同成为常态——他用一个”Tesla 电费账单”的完整故事，把这套协议组合能实现的全链路自动化讲得具体可感。

先看一组反直觉数据：AI 生产率不升反降

Otto 引用了一项研究的结论：生成式 AI 出现三年后，企业从 AI 获得的生产率反而下降了 20%。钱越投越多，产出却往下走——他的归因是”没人真正知道能用 AI 做什么”，很多组织只是对董事会喊”你得拿出点 AI”，然后随便扔个东西进去，没有方向感。

他刚在欧洲遇到一个客户，说”我要先把 CRM 和案件管理装好，再去想 AI”。Otto 的反驳是：这是个过时的顺序观——退一步看，有些事今天就能做，能立刻改善组织运转和平均解决时间（MTTR），不必等”完美实施”完成后再启动 AI 之旅。

应用蔓延：300-350 个应用是怎么来的

Otto 拆解了企业工具栈的现状：过去上本地部署要 IT 排期，SaaS 打开了闸门——每个部门都能有自己的应用，HR 有 HR 的，IT 有 IT 的，各有专用工具。这在当时是进步，但今天的蔓延（sprawl）制造了一堆问题：数据访问困难、权责不清、组织内状况不可见。

然后 AI 被当成救命稻草，结果”它只放大了问题”：数据被锁在各个孤岛里，每家应用都想在自己上面盖一层 AI，这些 AI 互不通信。Otto 的结论直接指向数据位置：组织要成功，本质是数据——你需要所有数据在一个地方。数据分散在多个互不共享的应用里，AI 就没有最好的数据源来做智能决策；就算做了决策，也无法落地执行。

落到操作层，他给了一个反直觉的建议：别等”先把应用实施完美”再启动 AI。他在欧洲遇到的客户想”先把 CRM 和案件管理装好再去想 AI”，Otto 的回应是退一步看——有些 AI 能力今天就能叠加进现有实施里，立刻改善组织运转和平均解决时间（MTTR）。正确的姿势不是串行（先完美实施→再上 AI），而是并行：在基础设施成熟的过程中，把意图识别、知识推荐这类轻量 AI 能力先跑起来，用早期收益养大项目的信心和预算。

应用蔓延放大了数据孤岛

从试点到规模：为什么试点会失败

对”生成式 AI 三年了，为什么很多组织还停在试点”，Otto 的答案是地基：很多 AI 在一个小场景里不错，但”迅速耗尽跑道”，无法扩展到下一个层级或跨应用。组织不想管理 50 个 AI 应用。

他对比了两类供应商：一类靠 VC 融资、有一个不错的小众功能；另一类（他以 ServiceNow 和 Genesys 为例）收购公司后会重新平台化（re-platform），停售 6 个月到两年直到完全整合——一个 UI、一个数据模型。Genesys 上云时同样是重新平台化而不是把本地的东西平移进云。这种”从地基长出来”的架构，才能支撑未来 5-10 年随业务变化而生长，也才扛得住财富 500 强对安全性和可扩展性的要求。

那句很实用的选型提醒：投资要有 wherewithal（底气），要选那些 5 年、10 年、15 年后还在的厂商——你不能把公司押在一个靠 VC 输血的利基功能上。

采购团队可以用三个可验证的问题来落实这条建议：第一，这家供应商过去三次收购的整合记录如何——被收购产品是一年后仍在独立维护（贴牌式整合），还是并进了统一数据模型（真整合）；第二，其 AI 能力是原生构建在平台数据层之上，还是外挂的第三层——前者能读到全部业务对象，后者只有接口喂给它的片段；第三，合同里的数据出口条款是否允许你完整导出全部结构化数据——平台押注最坏的情况是换供应商，数据可迁移性决定了那时你还有没有谈判筹码。

Tesla 账单故事：A2A+MCP 编排的完整图景

对谈的核心段落是 Otto 讲的一个客户服务全链路故事，值得完整展开。

起点是一通来电：“我有账单问题。“Genesys 侧的智能体先理解通话意图——不管客户怎么表述、不管对接的是真人坐席还是智能体，都能识别出”这是账单问题”。

第二跳：Genesys 把意图传给 ServiceNow 的智能体：“ServiceNow 账单智能体，去查为什么这笔账单偏高。“ServiceNow 进入各系统的账单记录做分析，回来的结论是：“查了你过去两年的账单，只有最近三个月升高，而且集中在下午时段——猜测这位客户买了电动车。“这一步展示的是分析型智能体的标准工作方式：并行检索多个系统的记录，把散落的账单数据整理成一条因果线索，再输出可执行的判断，而不是把原始数据倾倒给客户。

第三跳：这个信息传回 Genesys 侧智能体，它据此询问客户：“您最近是不是买了一辆电动车？“客户确认买了 Tesla。

第四跳是 Otto 认为的编排真正价值：客户顺口说”真希望能把费用降下来”。这个意图被传给 ServiceNow 侧的优惠评估智能体，它并行评估多个变量——客户没开自动扣款？开通可以月省 5%；买了电动车？有一笔 250 美元补贴可以申请；还有个叫 WeaveGrid 的应用与 Tesla 兼容，装上车后下午 5 点插电、等到夜里 10 点低电价时段才开始充电，更省。

第五跳：Genesys 侧智能体问客户要不要这些优惠，客户同意后，智能体直接把表格填好：“我只需要您的签名，PDF 发给您。”

Otto 强调这一切的底层是数据位置：“我怎么知道 WeaveGrid 兼容 Tesla？因为我们都在一个平台上，所有数据都在那儿。我知道他买了 Tesla，不用再问。“通话、查因、优惠评估、填表、签名，过去要几天甚至几周、要挫败客户多次的流程，在自主智能体协同下按秒完成。

拆开看这个故事的技术骨架，对架构师有三点直接启示。其一，意图在入口侧识别一次、全程复用——Genesys 判定”账单问题”后，后续所有智能体都不再重新询问客户背景，这在协议层对应 A2A 的任务移交语义。其二，分析型智能体与执行型智能体分工——ServiceNow 侧先做账单分析（只读各系统记录），结论回传后再由促销评估智能体并行计算多个可执行选项，读写分离让每一步都可审计。其三，闭环回到对话——所有后台计算的结果最终由 Genesys 侧智能体用自然语言向客户确认并收尾（填表、签名），客户感知到的始终是”一次对话”，而不是被转来转去的工单。

Tesla账单故事：五跳全自动

成本中心怎么变收入引擎

对”接触中心和 ITSM 这些传统成本中心怎么变成增长源”，Otto 的路径很清晰：先让简单问题自动化解决（知识文章或智能体直接处理）；解决不了的就无缝升级到组织其他部门——Genesys 负责理解意图，ServiceNow 的智能体接手跑完后续工作流。问题解决得快了，客户体验好了，才有资格谈追加销售（upsell）和留存——“留住一个客户比获取一个新客户容易得多”。接触中心就此从成本中心变成收入生成器。

对员工侧他补了一个观察：AI 接走重复问题后，坐席留下的都是智能体解决不了的难题，工作更有含金量、流失率下降；而生成式 AI 同时承担了培训功能——把老员工的隐性经验（“这事得问 Joe，他知道怎么解决”）从人脑里抽出来沉淀进系统，新人的上手成本大幅降低。这给客服团队的用人策略指出一个可计算的方向：统计”只有某几个人会处理”的工单类型，优先把这些场景的知识文档化并接入 AI 知识库——既降低了关键人依赖，又直接扩充了智能体可自动解决的工单范围，是同一份投入的两份回报。

给 CX 领导者的投资建议

对”现在该押注什么来赢得 2-5 年后”，Otto 的建议三条：把一切收敛到 best-of-breed 的平台方案上——能随需扩展、有安全性和可扩展性的那种；接受”人更少但更专业”的组织演化方向；把教育与知识沉淀当作投资重点。

对两家公司的合作，他的总结公式是 1+1=3：“这不是’买这个还是买那个’的选择题，是两者都要。我称之为投资（investment）而不是成本（cost）——它会持续压低组织成本、加速答案交付、改善客户服务。”

给CX领导者的投资建议

运营团队怎么用这套思路

如果你在规划跨系统的客服 AI 架构，这支对谈的操作启示：第一步，画出现有应用地图，标出客户数据所在的每个孤岛——A2A/MCP 编排的前提是知道”谁手里有什么数据”；第二步，选一个”意图识别→查因→行动”的完整链路做试点（类似账单查询场景），验证跨平台智能体协同的真实效果而不是单点问答；第三步，评估供应商时把”重新平台化的能力”（收购整合后一个数据模型）和长期存续能力放进权重——编排时代赌的是平台，不是功能。

还有一个容易被忽略的准备项是员工侧的配套。Otto 观察到 AI 接走重复问题后，坐席留下的是智能体解决不了的难题——这意味着技能要求上移，培训投入要同步加码；同时把老员工的隐性经验尽早抽进知识库（“这事得问 Joe”类Know-how），让 AI 和新人都能调用，避免关键人离职造成的知识断档。编排做得越好，“人处理难题”的含金量越高，这是一线团队职业路径的正向变化，值得在内部沟通时明说。

1+1=3的平台投资逻辑