2026 年 9 月 22 日，SAP 在一篇服务交付文章中披露了两个值得注意的客户信号：一家制造企业用 AI Agent 持续监测 ERP 健康、分析根因并执行经过批准的处置，每年约节省 3,000 小时；另一家美国客户将 AI 用于主动监测、异常解决和已授权动作执行，供应商按时付款率提升了 25%。[1]
这些数字来自 SAP 的客户案例，客户身份、统计周期、投入成本和独立验证均未公开，不能直接当作普遍回报。但它们指向一个比“Agent 能否自动处理工单”更重要的变化：当 AI 可以在交付后持续监测、判断和执行，企业购买的就不再只是软件许可或实施人天，而是一项需要长期证明效果的运营服务。
技术已经从一次性交付走向持续服务，许多项目的合同和验收方式却还停留在旧模式：功能是否上线、接口是否打通、工单是否关闭、顾问投入了多少人天。结果是供应商完成了约定动作，客户却很难回答，业务中断是否减少、关键流程是否更稳定、员工是否真的少做了无效工作。
AI 让“交付完成”和“客户得到结果”之间的距离暴露出来
传统企业软件通常有清晰的交付节点：部署、配置、测试、上线、验收。AI 服务则会在真实环境中持续受到数据变化、规则更新、模型升级、用户行为和异常事件影响。上线只是开始，效果会随环境变化而变化。
因此，下面几类常见指标都不足以单独证明服务价值：
SAP 提到，AI 服务开始按业务关键性而非单纯技术严重程度安排响应优先级。[1] 这意味着一次数据库告警是否重要，不能只由技术等级决定，还要看它是否影响生产结算、客户承诺、供应商付款或合规时限。AI 的价值不只是更快发现故障，而是更早识别“哪一个业务结果正在受到威胁”。
- 自动处理了多少任务，只说明吞吐量，没有说明结果是否正确；
- 节省了多少人工时间，没有说明这些时间是否真正转化为更高价值工作；
- 工单关闭得多快，没有说明问题是否复发、业务影响是否解除；
- 模型准确率有多高，没有说明错误发生在什么业务后果上；
- 系统可用率达到多少，没有说明关键经营流程是否可用。
从人天合同转向“结果服务”，先别急着承诺结果付费
结果导向不等于把所有费用都绑定到一个最终 KPI。销售收入、交付及时率、停机损失或客户满意度通常由多种因素共同决定，如果供应商无法控制数据质量、业务授权和现场执行，却要为最终结果承担全部责任，合同只会制造争议；如果指标完全由供应商定义和测量，又可能产生选择性优化。
更可行的做法，是把服务承诺拆成四层：
这四层把“供应商可以控制什么”和“双方共同影响什么”分开。项目早期可以按能力与运营质量付费；当数据基线稳定、影响关系得到验证后，再逐步把部分费用与业务过程结果挂钩。结果付费应是证据成熟后的商业安排，而不是销售阶段的口号。
- 能力承诺：系统能连接哪些数据、识别哪些事件、调用哪些工具，哪些动作必须由人批准；
- 运营承诺：监测覆盖率、响应时间、失败恢复、人工接管和重大事件通知达到什么水平；
- 业务过程承诺：异常积压、重复故障、处理周期、一次解决率或按时付款等可直接影响的指标如何改善；
- 经营结果观察：停机损失、收入、客户留存等最终结果如何跟踪，但在归因尚不充分时不轻率承诺因果关系。
每项 AI 服务都应有一张“结果责任表”
企业在采购或重签 AI 服务合同时，可以要求业务方、技术方和服务商共同确认一张结果责任表，至少包含：
这张表的重点不是增加文档，而是避免“效果归供应商宣传，风险归客户承担”。如果关键数据无法取得、业务动作没有授权、人工响应长期缺位，就应明确记录为共同依赖，而不是在验收时把所有差距归咎于模型。
- 目标结果：希望改善的业务过程，以及为什么值得改善；
- 基线与口径：当前水平、统计窗口、排除条件和数据来源；
- 可控范围：AI、服务商、客户业务团队分别能控制哪些环节；
- 领先信号：在最终结果出现前，可以观察哪些异常、积压或响应变化；
- 护栏指标：错误动作、漏报、反复修正、客户投诉和人工接管不能超过什么边界；
- 证据归属：运行日志、评测数据、人工判断和改进记录由谁保留，客户能否导出；
- 调整机制：模型、流程、数据或政策变化后，基线和承诺如何重新确认；
- 退出条件：效果持续不达标、风险越界或总体成本失控时，如何降级、暂停和退出。
采购方要买的不是一个模型，而是一套持续改进能力
美国政府问责局 2026 年关于 AI 采购的报告提供了一个有价值的外部观察：受访机构通常更倾向把 AI 作为服务而不是一次性产品采购；管理复杂 AI 项目的官员还表示，服务质量对最终表现的影响可能大于模型算法本身。报告同时强调，AI 需要持续评估，采购方应围绕期望结果定义需求，保留上线后的测试、监测和供应商问责机制。[2]
这对商业企业同样适用。一个值得长期购买的 AI 服务，至少应持续完成三件事：
NIST 2026 年发布的部署后监测报告也指出，发布前评测主要发生在受控环境中；进入真实场景后，非确定性输出、动态输入和意外后果都要求持续监测，而相关最佳实践仍在形成之中。[3] 因此，合同不能只写上线前通过多少测试，还应写明上线后监测什么、由谁判断、多久复盘，以及发现退化后怎样处置。
- 发现真实运行中出现的新问题，而不是只维持演示时的效果；
- 把失败、人工接管和业务变化转化为可验证的改进；
- 证明新版本确实改善了结果，而不是因为“模型更新了”就默认升级有价值。
企业 AI 的下一轮竞争，可能发生在服务模式而不是模型参数上
当多个模型都能完成相似任务时，客户最终感受到的差异，往往来自谁更理解业务结果，谁能更快处理真实例外，谁愿意共同承担持续改进责任，以及谁能用可信证据说明投入到底换来了什么。
这也给企业服务商带来新的机会：不再只出售软件、实施和运维人力，而是把行业知识、监测机制、改进流程和结果证据组合成可持续交付的服务。它可能形成更稳定的客户关系和收入，但前提是服务商敢于把价值口径说清楚，也愿意接受透明的持续评估。
企业评估 AI 项目时，不妨少问一句“能替代多少人”，多问一句：上线一年以后，谁负责证明这项服务仍然在创造结果？
这个问题一旦写进合同，AI 才真正从一次技术采购，走向一项可经营的企业能力。
