ServiceNow：先在自己的客户支持系统里测试 AI Agents

ServiceNow 讲的 Now on Now，直译是「把 Now 用在 Now 上」——它先把自己的产品部署在自己的运营里。落到客户支持这条线，公开材料给出的做法很具体：AI 智能体被放进真实的自助服务、案例分类、路由、对话摘要与知识文章生成，跑在 ServiceNow 自己的工单、知识库与 SLA 流程里，而不是一个隔离、干净、被挑选过的演示环境。其原生的 Now Assist 能力——案例摘要、知识生成、座席辅助，以及一定程度的自助分流——按其产品说明直接运行在平台的实时数据上，不依赖额外的外部连接器把数据搬来搬去。

这一步的分量，落在它改变了失败的承担顺序，而非「公司用了自己的产品」这句听起来平常的话。把智能体接进自己的生产支持，意味着它要面对真实的脏数据、语焉不详的工单、临时插队的升级和正在逼近的 SLA 时限——这些都是精心准备的演示样例给不了的压力。对一家打算把同一套智能体卖给成千上万家企业的公司，先在自己身上跑，等于先替未来的买方承担一轮真实的错分与延误。

有一条边界必须先划死，否则整篇分析都会站不稳：公开材料能支撑的是「做法」和「能力」——内部生产流程里的分类、路由、摘要、知识生成，加上一套原生的评估机制——它只指向方向，并不附带可核验的成效数字。第三方汇总里流传的那些百分比（减少了多少工单、提速了多少倍），在没有官方口径背书前不该被当成事实引用。这篇分析里凡涉及量化收益的地方，都按未经证实处理。

但即便把所有成效数字都拿掉，内部先行仍然改变了一件根本的东西：买方开口的方式。当供应商把自己当成第一个客户，采购评估的第一个问题就落在「你自己天天用它的时候，它在哪里出过错、那次出错被记在了哪里、由谁去收拾」，而非「你能给我演示什么」。这两个问题指向的证据完全不同——前者要的是最佳表现，后者要的是失败留痕。

这就是为什么 Now on Now 值得被当成一个采购范式来读，而不是一则客户故事。它把一个通常由供应商自愿提供、可给可不给的东西——「我们自己也在用」——推到了买方可以据此设条件的位置。接下来的问题是：客户支持这个场景，究竟压出了什么别的场景压不出的东西；以及买方到底该向供应商索取哪几样具体的证据，才算真正用上了这道杠杆。

质量复核后，需要把本文的证据边界说得更硬。ServiceNow 公开页面披露了若干 Now on Now 指标，包括 AI agents 支持客户自助服务请求、自动化客户支持工作流、AI 生成知识文章等；这些数字可以作为「供应商确实把系统放进自身运营」的线索，但它们仍是 ServiceNow 自披露，不等同于独立审计，也不能直接外推到客户部署中的 SLA、ROI 或错分率。

因此，本文不把 Now on Now 当作成功证明，而把它当作采购提问的起点：既然供应商声称自己在生产里使用，就应当能展示失败样本、低分执行日志、人工接管记录和修复闭环。能展示这些，内部先行才有采购价值；只能展示汇总比例和顺滑演示，它仍然只是更高级的市场材料。

说客户支持要准、要快、要担责，几乎是所有生产环境的共性，不足以解释它的特殊。它真正的高压，在于失败的落点和反馈的速度：一次错误会实时砸在一个正在屏幕另一端等待的人身上，并且立刻被对方看见。后台的对账、报表、批处理即便出错，也常有一层缓冲和事后修正的空间；而支持智能体的每一次误判，反馈环都短得几乎没有掩护——用户当场就知道自己被误解了。

拆开一个支持智能体的动作链，能看清失败可能发生在哪些接缝。它要先读懂一张工单的意图，判断这是密码重置、账单争议还是系统故障；再按类别、优先级和处理组把它分类；然后路由到正确的团队。这些分类判断依赖用每个客户的历史工单训练出的模型，随标注样本累积而变准——也就是说，它在冷启动阶段天然更容易错，而错分会沿着路由一路放大。分完、路由完，它还要把一段冗长的往复对话压成摘要、生成或更新知识文章、在人工座席身边做实时辅助。每一环都可能出偏差，每一次偏差都直接转化成一个真实用户的额外等待。

把这条链和一次被精心准备的演示并排放，差别就出来了。演示里，输入是被选过的、意图清晰的工单，模型在它训练分布的正中央作答；生产里，输入是长尾的、含糊的、夹带情绪和错别字的，模型不断被推到分布的边缘。一个支持智能体在演示里的表现，几乎不携带关于它在生产里如何失败的信息——这正是「先在自己身上跑」比「给你看一段录屏」信息量高出一个量级的原因。

正因为失败点多、反馈快、代价直接落在人身上，客户支持成了一个天然的压力测试台:它逼着运营方去回答一个演示永远不必回答的问题——当它错了，系统里有没有一个地方，如实记下了它错在哪一步。这个问题的答案，不取决于智能体本身有多强，而取决于它周围有没有一套盯着它、给它打分、并试图定位失败的机制。

这就把讨论从「智能体能力」推进到了「评估能力」。一个能在挑好的样例上流畅分流的智能体，和一个在真实工单洪流里出了错、并且那次错被完整记录下来的智能体，是两种不同的资产。前者是营销素材，后者才是运营基础设施。ServiceNow 在这条线上真正值得盯的信号，因此不是 Now Assist 能做多少事，而是它把「评估」本身做成了平台的原生能力——下一节的重点。

按 ServiceNow 的产品说明，它的 Agentic Evaluations 内建在 AI Agent Studio 里，机制是用一个充当评审的大模型，读取每个测试用例的执行日志，再对若干质量维度打分。这句话看着朴素，但它把评估从「人工抽检 + 事后投诉」的作坊模式，搬进了平台可以规模化、可重复运行的流程里。评估成了随每次改动都能重跑的一道内建关卡，而非上线后才补做的一次性验收。（以下对该机制的描述以其官方产品口径为准，具体维度定义与打分标准的细节未在公开材料中展开，按未经证实处理。）

给这套机制一个具体的形状。设想一张工单被智能体误判成了错误的类别，继而被路由到了处理不了它的团队，几经辗转，最终拖过了 SLA 时限。在没有原生评估的世界里，这类失败通常要等用户投诉、或月度复盘时才浮出水面。在有原生评估的世界里，理想情况是:这条完整的执行轨迹作为一个测试用例被回放，评审模型读到它「分类错误、路由错误、SLA 违约」，在对应维度上打出低分，连同那条日志一起被标记出来——失败在被真实用户撞见之前，先在评估里被看见。

这套机制的价值，来自它把「智能体做了什么」变成了可被第三方（哪怕是另一个模型）读取和评判的记录。执行日志是关键:它记录的不只是最终答案对不对，理想情况下还包括中间的每一步——调用了哪个工具、传入了什么、返回了什么、据此做了什么决定。评估的深度，直接受制于日志的粒度。日志记得越细，评审模型能定位的失败就越靠近真正的病灶；日志只记结论，评审就只能判断对错、说不清错在哪。

这里要立刻区分两件难度差一个量级的事:「能打分」和「能定位失败」。给一次执行结果打一个维度分，是相对容易的——评审模型看最终输出、对照期望，就能给出高低。而在一条多步动作链里做归因、指出失败具体发生在第三步的某次工具调用上，要难得多:它要求评审模型能读懂中间状态，要求日志本身记到了那个粒度，还要求它能把「最终结果错」正确地回溯到「哪一步先错」。前者是判分，后者是调试；现有实现里最薄弱、也最值钱的，恰恰是后者。

所以评估一个支持智能体，重点落在:它在真实工单上失败时，那次失败长什么样、被记在哪、由谁升级——而非它演示里跑得多顺。一套能读执行日志、能对多个维度打分、并且真的朝「定位失败发生在哪一步」使劲的评估，比任何一次顺滑的自助分流都更接近可以被信任的运营资产。但这套评估自己也有盲区，而且盲区不小——下一节专门拆它，因为买方若不先知道评估会在哪里失灵，就会把一份低分表当成安全证明。

原生评估最危险的地方，是它容易被当成一张出厂合格证:分数一片高，就默认智能体可控。但评审模型能看见的失败，受限于三个它自己无法突破的边界，买方必须和评估结果一起买下这份清单。

第一个边界是日志粒度。评审模型只能对它读到的东西打分。如果执行日志只记最终路由结果、不记中间的调用链，那么「分类在第几步、因为读错了哪个字段而偏掉」这类信息，评审模型根本无从判断——它会给出一个「结果错误」的低分，却说不出错因。这不是模型不够聪明，而是它面前的记录本身就是残缺的。因此，追问日志记到多细，和追问评估分多高，是同一件事的两面；只看分数、不看日志粒度，等于验收一份自己看不到过程的考卷。

第二个边界是同源评审的共同盲区。当给智能体打分的大模型，和被打分的智能体出自同一家供应商、共享相近的训练数据与价值取向，二者很可能在同样的地方犯错、又在同样的地方视而不见。一类被系统性误解的工单，如果被评模型看不出问题，评审模型很可能也看不出——低分不会出现在本该出现的地方。这类结构性偏差（比如某种语言、某类口音转写、某个边缘产品线的工单被成批错分）恰恰是最需要外部视角才能抓到的，而同源评估在设计上就削弱了这种视角。

第三个边界是罕见与跨类别失败。评估跑的是测试用例集，它对高频、典型的失败覆盖得好，对长尾的、跨越多个类别边界的、几百万张里才出一次的失败，天然覆盖不足。而生产事故往往就藏在长尾里:平时不出现，一出现就是连锁的。一张全高分的评估表，准确的读法是「在我们测过的这些情形里，它表现达标」，而不是「它安全」。把前者读成后者，是这套机制最常见的误用。

这三个边界合起来给出一条使用规则:评估结果的价值，和买方追问它边界的能力成正比。一个只会问「评估分多少」的买方，买到的是一张可能被高分麻痹的表；一个会接着问「日志记到哪一层、评审模型和被评模型是不是同源、测试集覆盖了哪些长尾」的买方，才真正在使用这套评估。评估不保证安全，它只是把一部分失败提前搬到了上线之前——搬来多少，取决于以上三个边界卡在哪里。

认清盲区不是要否定原生评估的价值，恰恰相反:正因为它能把相当一部分失败前置，它才值得被认真索取和审读。但审读的前提，是买方手里得有可审的东西——真实的日志、真实的低分、真实的升级记录。这些东西不会因为「我们内部用过」这句话就自动存在，它牵出的是一整套治理问题，也是下一节的主题。

把智能体放进自己的支持系统，治理问题会立刻从抽象变具体，因为它触碰的是真实的敏感数据和真实的决策权。第一个必须划清的边界是数据可见性:智能体能读到真实工单、聊天记录和知识库里的个人信息、账户细节、内部处置口径——哪些字段可以进入模型上下文、哪些必须脱敏或屏蔽、生成的知识文章会不会把不该外露的内部信息带到面向用户的答复里，这些都得在部署前就定义好，而不是出事后再追。

第二个边界是自动决策与人工确认的分界线。分类和路由是判断，判断就有权重不同的后果:把一张普通咨询错分，代价是多绕一圈；把一张涉及资损或安全的工单错分并自动闭环，代价可能不可逆。所以哪些类别的动作允许智能体自动完成、哪些必须停下来等人确认，应当按后果分级明确写下来，而不是一刀切地全自动或全人工。一套读执行日志的评估在这里的作用，是让「某个本该人工确认的动作被自动执行了」这类越界，变成可被回放、可被复盘的记录。

第三个边界是升级与接管:什么情况下智能体必须主动停手、把对话交还给人工座席。低置信度、检测到用户情绪升级、涉及特定敏感类别、连续多轮没能解决——这些触发条件如果没有事先定义，智能体就会在自己能力的边缘继续硬撑，而这正是最容易造成真实伤害的地带。接管逻辑的质量，很大程度上决定了这套系统在最坏情况下的下限。

把这三条边界和评估机制接起来看，原生评估的意义就更清楚了:它能把「数据越权读取」「越界自动决策」「该升级未升级」这些治理失效，从抽象的风险变成执行日志里一条条具体的、被打了低分的记录。治理由此成为可以对着真实轨迹逐条检验的东西，而不再只是一份写在合规文档里的原则声明——前提依然是日志记到了那个粒度、评估覆盖到了那些维度。

但这里有一个容易被话术绕过去的关键:内部先行本身，只攒下了「产生这些治理记录」的条件，并不等于记录已经生成、更不等于记录没被挑选过。供应商完全可以自己用了一年、却只在采购环节递出一叠精挑细选的成功案例。所以治理这一节的落点，是「他们能不能把治理失效的原始记录交出来给你看」，而非「他们内部有治理」。这就把讨论从供应商的自我陈述，逼到了买方可以索取的具体证据清单上——采购该怎么设这道条件，是下一节。

把上面的机制翻译成采购动作，核心是把评估的重心从「演示顺不顺」挪到「失败留没留痕」。一场发布会演示，信息量集中在模型的最佳表现；而买方真正要防的是最坏表现。这两者之间的信息落差，决定了只看演示的采购，本质上是在用一个和风险几乎无关的指标做决策。务实的替代，是向供应商索取三样可核验的东西，并让这三样——而非演示——决定它能不能进下一轮。

第一样，是自己使用的证据——能证明智能体确实跑在其真实生产支持流程上的记录，而非「我们也在用」这句声明:处理了哪些类别的真实工单、覆盖了多大比例的实际话务、在哪些流程里是自动闭环、在哪些流程里仍需人工兜底。声明可以由市场部门写，记录不能凭空捏造——这正是它比声明更有分量的原因。

第二样，是失败与升级的记录。被错分的工单样本、被错误路由的轨迹、触发人工接管的真实案例，以及这些失败最终如何被发现、被归因、被修复。一个愿意把自己的错分样本摊开给你看的供应商，和一个只肯给你看成功案例的供应商，传递的是完全不同的信号:前者在邀请你审查它的下限，后者在请你欣赏它的上限。

第三样，是读执行日志的评估结果。不只是一张维度分表，还要能顺着分数下钻到对应的执行日志——至少记到每次工具调用的输入与输出，而不是只留一个最终结论。日志的粒度在这里是硬指标:它决定了这份评估到底是「能判分」还是「能定位失败」，而这正是上文说的、难度差一个量级的分界。买方要问的，是「把某一条低分背后的完整执行日志给我看」，而非「你们有没有评估」。

这套标准有一个明确的适用条件，也有一个明确的失效条件，必须同时说清楚才算负责任。适用条件:当买方真的开口索取这三样、并且有能力读懂它们时，它是一道相当有效的筛子——一个连自己生产日志都不敢交的供应商，基本可以判定它没底气让智能体进你的关键流程。失效条件:如果采购仍以演示效果和报价为主轴，只把「请提供内部使用证据」写成招标书里一句没人会去核的套话，那这道条件就形同虚设，换回来的只是一叠更厚的、同样好看的文档。工具是否有牙齿，取决于买方是否真的咬下去。

上一节的三样证据，只有在买方读得懂的前提下才有意义，否则再严格的索取条款都会退化成走过场。这一点常被跳过，却是整套采购逻辑成败的枢纽:证据的效力，系于审读者的分辨力，而非证据本身。

分辨力的第一层，是分得清一份真实的执行日志和一份精选的合规文档。真实日志是杂乱的:它有失败、有重试、有被降级处理的边缘工单、有中途接管的断点；而为采购精心准备的材料是平滑的、叙事完整、结论正面。一个有经验的技术买方，看到一份「全程顺利、零失败、每一步都符合预期」的所谓生产记录，第一反应应该是警觉而非放心——真实生产不长这样。分不清这两者的买方，会把最像营销素材的那份材料评为最高分，恰好选中风险最高的供应商。

分辨力的第二层，是知道该往日志的哪一层追问。同样拿到一份评估结果，弱买方停在「分数不错」，强买方会追问:这些测试用例覆盖了哪些类别、有没有跨类别的长尾、评审模型和被评模型是不是同源、日志记到了工具调用级还是只记了最终结论、被打低分的那几条现在修好了没、怎么验证修好了。这些追问不需要买方自己会训模型，但需要它理解这套机制会在哪里失灵——也就是上文那三个盲区。理解盲区的买方，才问得出让供应商无法用文档搪塞的问题。

这就解释了为什么同一道采购标准，在不同买方手里效果天差地别。标准是死的，它只规定了「要索取什么」；真正决定它有没有用的，是买方「读得懂什么」。把这道标准写进制度、却没有配上有能力审读的技术评估团队，等于装了一把只有钥匙孔、没有锁芯的锁——看着森严，推一下就开。

因此，对正在搭建 AI 采购流程的组织，真正的投资顺序或许和直觉相反:与其先把评估条款写得面面俱到，不如先确保采购链条里有人能读懂智能体的执行日志、能识别一份被美化过的生产记录、能顺着一条低分追到它的成因。条款可以外包给咨询公司起草，分辨力不能外包——它必须长在买方自己的团队里。少了它，前面所有关于证据和评估的讨论，都会在最后一公里失效。

值得把一个反面情形单独拎出来讲透，因为它是这整套逻辑最容易被钻的空子:「Now on Now」式的内部先行，是产生可信证据的必要条件，却远不是充分条件。把这两者混为一谈，买方就会用一句自我陈述替代了本该索取的原始记录。

必要性这一半是成立的:一个从没在自己生产环境里跑过智能体的供应商，根本不可能拿出真实的失败留痕、也不可能有一套在真实工单洪流里被反复校准过的评估——它连产生这些记录的场景都没有。所以「你自己用了吗」仍然是一个有价值的第一道门槛，它能筛掉那些只在实验室和演示间里打磨过产品的供应商。

但充分性这一半不成立，而且缺口很大。「我们内部用了」和「我们能把内部踩坑的原始记录交给你审」之间，隔着好几道供应商可以自由裁量的关卡:它可以自己用了、却从不认真记录失败；可以记录了、却在采购环节只挑成功案例递出；可以递出了一部分、却把最能暴露问题的那些日志留在手里。每一道关卡，都足以让「内部先行」这四个字听起来很硬、实际上什么可核验的东西都没兑现。

所以防这个话术缺口的办法很直接:把索取的对象从「状态」换成「物证」。不要收下「我们在生产里用了智能体」这种描述状态的声明——状态无法证伪；要收下描述具体物证的东西——被错分的那张工单长什么样、评估里被打低分的是哪个维度、对应的那段执行日志能不能调出来。声明可以写得无懈可击而无从核对，物证要么拿得出、要么拿不出，没有中间地带。一个真在自己身上认真跑过、且不怕你看的供应商，交出这些几乎是顺手的事；一个交不出的，「内部先行」多半只停在了 PPT 上。

把这一节和采购标准接起来，就得到一条可以直接写进评估表的判据:内部先行只是入场的资格，能否交出未经挑选的失败物证才是评分项。前者供应商说了算，后者买方说了算——而把评分权从供应商的叙事手里，挪回到买方能核验的物证上，正是这整套方法要争取的东西。

把这套做法从 ServiceNow 的具体产品里剥出来，真正能带走的是一种读供应商的方式：看它有没有把智能体接进自己最要紧的流程、替未来的买方先吃下一轮真实的错分、错路由与 SLA 违约。这一步之所以关键，靠的是背后一道关于「承担顺序」的不对称——谁先在自己身上承担失败，谁就交出了演示台上给不了的那种证据。

这道不对称是这样运作的。把智能体接进自己的生产支持，等于供应商先替未来的买方吃下了一轮真实的错分、错路由和 SLA 违约——出错的第一份代价被前置到了卖方这一侧。一个连这步都不肯做的供应商，本质上是在要求买方替它去踩第一次坑、用自己的关键流程给它当试验场；它没有资格要求你把智能体接进你最要紧的环节。这道不对称对有技术评估能力的买方是一道真实的筛子，但它的收紧有一个明确的触发条件：只有当买方真的开口去问「你自己用它时，它在哪里出过错」并且有能力核验答案时，它才会真正收紧。反过来，一个可以让这道判断失效的清晰信号是：如果一个头部供应商能长期只靠演示和报价拿下大单、从不被要求出示自己的失败日志，那说明市场还没把这道不对称定价进去，这道机制在当下就是松的。

顺着这道不对称，给两边各留一条可执行的判断，而不是一句「迟早会变」的断言。对买方：真正的分水岭，是一个供应商敢不敢让智能体先在它自己的关键流程里出错——一个只肯在你的流程里做第一次试验、却拿不出自己踩坑记录的供应商，还没到能进你核心环节的资格线。对建设者：先在自己身上承担失败这件事本身，就是你最难被对手模仿的资产，因为它要证明的东西很朴素——你敢不敢把它接到自己身上、认下第一轮的错。这恰是买方最想要、也最没法替你伪造的那部分。

这道不对称之所以是这个案例特有的、而非一句放之四海的口号，在于它只在「智能体会实时地、可归因地失败」的场景里才成立。客户支持满足这个前提：失败当场发生、当场被看见、并且能被执行日志逐步记录。换到那些失败缓慢显现、难以归因、或后果可以被静默吸收的场景，「先在自己身上承担失败」这一步的证据价值会大打折扣——那里更需要的是别的检验方式。把这套方法用对地方的前提，是先确认你要买的智能体，身处一个失败真的会留下痕迹的环境。

所以真正稀缺的，从来不是「我们也在用 AI」这类可以被任何供应商复述的话，而是「我们先让它在我们自己身上出了错，并且把那次错原原本本记了下来」这份没人能替你伪造的记录。承担失败的顺序，本身就是这个案例留给采购方最该带走的那把尺子。