📌 TL;DR: 库存与履约Agent运行一个季度以后,Dashboard显示准确率提高、工具调用更稳定、行动速度加快、Human接管减少。但企业经营报表中的核心订单满足率、库存周转、履约成本和客户商品可获得性没有同步改善。 两张报表并不矛盾。Agent Dashboard回答系统是否把被交付的工作做得更好;企业经营报表回答这项工作做得更好以后,公司是否因此变得更好。系统表现是企业价值的必要条件,却不是最终证明。 企业需要验证系统表现是否改变了实际判断和行动,行动是否改变了相关业务状态,业务状态是否改善了客户和运营结果,以及这些改善是否进一步进入企业经营。这不是ROI公式,而是帮助管理层找到价值证据已经连接到哪里、又在哪里断开。 断点不同,项目调整方向也不同。系统能力没有进入行动,应检查实际使用和执行方式;行动没有改变业务,应检查时机、覆盖与业务约束;业务状态没有形成客户结果,应重新审查价值假设;结果改善却需要不成比例的投入,则要进入更完整的业务验证。 核心判断是:**系统指标证明Agent是否把工作做得更好,经营结果才证明这项工作是否值得持续存在。** AI做得更好,不等于公司因此变得更好。

Agent的运行指标都在变好,为什么企业经营结果没有同步改善?丨ANC重新理解AI原生过程指标

季度项目复盘会上,库存与履约 Agent 的项目团队给出了一个明确判断:经过一个季度的优化,系统已经比上线时更稳定、更可靠,也更能自主处理业务情况。这个结论有测试结果和运行记录支持,并不是技术团队的主观评价。业务负责人却提出了另一个问题:如果Agent已经明显进步,客户和企业经营究竟发生了什么变化?

现场没有人能够拿出同样清楚的证据回答。双方看到的都是真实事实。项目团队证明了系统取得进步,业务负责人追问的则是这些进步是否已经成为公司价值。这并不否定Agent的价值,它说明企业需要区分两个判断:

Agent是不是变得更好。
公司经营有没有因此变得更好。

NotebookLM的音视频概览,解读的比较通俗易懂,对于时间比较紧张的读者朋友,可以听听,会有启发。


一|企业为什么容易把AI指标当成价值证明

AI项目上线以后,最先看到的通常是系统指标。模型准确率、任务完成率、工具调用成功率、响应速度和Human接管率,都可以快速反映模型、产品和工程优化是否产生效果。

02页_f.png

这些指标非常适合项目管理。开发团队可以用它们定位问题,产品团队可以比较版本,管理层也可以通过Dashboard持续观察建设进展。团队调整模型、优化提示、增加工具或者修复接口以后,通常能够比较快地看到相应变化。

客户和经营结果则不同。订单满足率、客户留存、库存效率、履约成本和毛利出现得更慢,也同时受到需求、供应、价格、市场活动和组织执行等多种因素影响。技术团队很难在一次系统升级以后,立刻证明经营报表中的变化来自哪一项改进。

于是,企业很容易停在最先获得、最容易测量,也最接近系统的一层证据上。只要准确率提高、任务成功率上升、Human接管减少,项目就开始使用“价值提升”来描述系统进步。

这些指标没有错。没有足够可靠的判断和行动,后续业务改善通常无从发生。但系统表现是价值发生的必要条件,不是企业价值已经成立的证明。


二|Agent变好和公司变好,不是同一个判断

Agent的系统表现,回答的是AI是否把被交付的工作做得更好。模型准确率、判断一致性、工具调用成功率、任务完成率和响应速度,都可以帮助企业评价系统是否可靠、有效。

企业经营结果回答的是另一件事:这项工作做得更好以后,公司是否真的变得更好。企业最终关心的是客户需求有没有得到满足,销售机会和客户承诺有没有得到保护,以及运营质量、成本、风险和资产效率是否发生了有意义的变化。

03页_f.png

这两个判断有关,却不能互相替代。一个缺货预测模型变得更准确,意味着系统更有可能正确识别风险;但如果更准确的判断没有改变实际库存效率,业务运行就不会自动变化。一个Agent更快完成调拨,也说明系统效率提高;但如果调拨没有改善客户需要的商品可获得性,速度本身无法证明客户结果已经改善。

Google面向机器学习项目的公开文档同样区分模型指标和业务指标,并明确指出,优秀的模型指标不保证业务指标随之改善。Google for Developers:Measuring success

系统指标仍然重要。它们帮助企业判断Agent是否完成工作、哪里出现故障、哪一部分能力需要继续改进。只是项目团队不能停在这些指标变好的位置,还需要继续验证这些系统进步是否形成了业务价值。

模型指标证明AI是否完成了工作,经营结果才证明这项工作是否值得持续存在。

同一个数字也不需要被永久划入某一种指标类别。例如,订单满足率在一次库存调整以后,可以作为业务反馈帮助AI形成下一步;经过持续观察以后,它也可以成为企业判断客户和运营结果是否改善的证据。关键不在指标叫什么,而在企业现在用它回答什么问题。


三|同一个库存Agent,两张报表为什么会给出不同答案

要判断系统进步有没有体现在企业经营,需要把同一时期的Agent运行记录与经营结果放在一起观察。

库存与履约 Agent 已经运行了一个季度。Agent Dashboard显示,缺货风险识别准确率提高,调拨和补货建议更少被Human推翻,工具调用成功率上升,从发现风险到形成行动的时间也进一步缩短。收到业务反馈以后,系统能够比过去更快修正原来的路径。

企业经营报表给出的却是另一组事实:核心客户订单满足率没有明显提高,紧急调拨和加急履约仍然频繁发生,部分缺货风险只是从一家门店转移到另一家门店,库存周转和履约成本也没有同步改善。

04页_f.png

两张报表并不互相否定。Agent Dashboard证明系统把自己的工作做得更好了;经营报表则要求企业继续确认,这些系统进步是否进一步改变了真实业务和经营结果。

以“缺货判断更准确”为例,企业首先需要知道,更准确的判断是否改变了实际库存行动。如果新的判断仍然被Human忽略,或者只能生成一份更准确的风险名单,业务状态可能保持不变。即使行动真的改变了,企业还要确认库存是否在客户需要的商品、门店和时间上变得更加可用。

商品可获得性改善以后,核心客户订单和客户承诺才有可能得到更好满足。即便订单满足率已经提高,公司仍需观察这项改善有没有被更高的库存占用、频繁调拨和加急履约成本抵消。

这些追问不是要把所有经营变化都归因给Agent。现实结果受到多种因素影响,企业也不可能证明每一项变化都由AI单独造成。这里需要建立的是一条足以审查的连接:Agent的进步究竟经过了哪些实际变化,又怎样体现在客户与经营结果中。

如果项目只能证明第一张报表变绿,却无法说明第二张报表中的什么应该随之改变,企业拥有的仍然主要是系统进步证据。


四|AI的进步怎样连接到企业经营结果

从Agent系统表现到企业经营价值,中间存在一段需要被验证的关系:

系统表现
→ AI判断与行动
→ 业务状态变化
→ 客户与运营结果
→ 企业经营价值

它提供一种检查方式:每一层的改善,实际改变了下一层什么?

05页_f.png

模型准确率提高以后,需要看实际判断和行动是否因此变化。如果业务人员仍然采用原有做法,或者Agent没有进入真正的业务动作,系统能力就会停留在技术层。

行动发生变化以后,需要看目标所指向的业务状态是否改变。Agent可以执行更多任务、更快调用工具,但如果行动时机不对、覆盖范围有限或者无法在真实业务中落实,目标状态仍然可能保持不变。

业务状态改变以后,还要看客户和运营结果是否改善。库存增加、消息发出、工单关闭和销售线索得到联系,都是可见的中间变化,却不自动等于客户需求得到满足、问题得到解决或者销售机会得到推进。

客户与运营结果改善以后,企业仍然需要判断这些改善是否形成了公司真正关心的经营价值。一项客户结果可能同时带来新的成本、风险或资源占用,局部改善也可能被另一处经营损失抵消。

Google的《Rules of Machine Learning》区分系统直接优化的objective、其他可测量指标和更长期的用户与系统健康,并提醒不要把可优化目标与最终健康状态混为一谈。Google for Developers:Rules of Machine Learning

这段连接中的任何一环没有发生,Agent都可能在系统内部越来越好,而企业获得的价值仍然有限。


五|找到价值断点以后,企业应该调整什么

价值审查的作用,不只是证明项目成功或者失败,更重要的是找到系统进步没有继续成为经营结果的位置。断点不同,企业需要调整的对象也不同。

如果系统表现改善,却没有改变实际判断和行动,继续提高模型准确率未必能解决问题。企业需要检查AI建议是否真正进入业务流程,Human为什么没有采用,以及Agent是否拥有足以影响目标状态的执行空间。此时需要修复的是系统能力进入业务的方式。

06页_f.png

如果AI行动已经发生,但相关业务状态没有变化,企业需要检查行动的时机、强度、覆盖范围和现实约束。Agent可能完成了被允许执行的动作,却没有作用到决定经营结果的关键位置。问题不再是AI能否行动,而是这些行动能否真正改变业务。

如果业务状态已经变化,客户和运营结果却没有改善,企业就需要重新审查原来的价值假设。项目也许优化了一个容易改变的中间状态,却没有触及客户真正关心的问题。继续扩大相同动作,只是让中间指标变得更好。

07页_f.png

如果客户或运营结果已经改善,却需要不成比例的库存、履约、人力或者其他资源支持,企业面对的也不再是模型问题。它需要进一步判断,这项改善能否在更完整的业务条件下持续存在,以及是否值得继续投入。

因此,经营结果没有出现时,结论不应自动变成“Agent能力还不够”。企业应先找到价值连接断开的地方,再决定下一项建设是继续优化系统,修复行动与业务之间的关系,重新审查价值假设,还是进入更完整的业务验证。


ANC视角:企业最终评价的是价值创造,不是Agent本身

传统IT项目往往在功能上线、系统可用或者流程效率改善以后进入验收。但AI Agency承担的是持续推进经营目标的职责,因此企业不能只确认系统是否工作得更好,还要持续验证这些改善是否改变了真实业务,并形成值得继续投入的经营结果。

08页_f.png

AI Native Company的建设对象不是一个独立技术系统,而是一项经营价值的持续推进。ANC不会把Agent自身越来越强当作最终价值判断,而会继续追问:Agent变好以后,公司价值创造中的什么实际发生了改变?

AI Native Company不是拥有表现最好的Agent,而是能够让AI的进步持续成为企业价值创造的一部分。


写在最后

Agent运行指标持续改善,是一项真实而必要的进步。但如果这些进步停留在系统内部,企业获得的仍然只是一个表现更好的Agent,而不是已经得到证明的经营价值。

当系统进步开始改变真实业务,并形成客户和经营结果,企业才初步建立起AI与经营价值之间的连接。

现实中,企业通常不会因此立即让Agency进入全部业务。更常见的做法,是先选择部分门店、商品、客户或业务范围进行试点,在较短周期内验证这段价值连接。项目团队也会投入更密集的监测、支持和异常处理,确保问题能够被及时发现。

试点可以帮助企业确认:Agent的进步确实能够改变业务,并产生值得继续观察的经营结果。但当Agent从部分试点业务走向完整正式业务,面对全量流量、长尾情境、长期成本和更复杂的组织协作时,原来成立的价值连接是否还能保持?

这是下一期需要继续回答的问题:AI试点已经证明了价值,为什么进入真实业务以后仍可能不成立?


来源与限制

  1. *Google for Developers《Measuring success》*区分模型指标与业务指标,并明确指出优秀的模型指标不保证业务指标得到改善。本篇只用它证明工程实践中存在“模型成功不等于业务成功”的现实分界,不采用其项目方法作为ANC价值定义。
  2. *Google for Developers《Rules of Machine Learning》*区分系统直接优化的objective、其他metrics以及更长期的用户和系统健康。本篇只用它说明容易优化的系统目标与企业最终关心的结果之间可能存在距离,不展开其中的规则编号和产品案例。
  3. Google销售数字广告、云计算及AI产品,相关工程文档与自身产品实践存在关系。所有外部来源只承担可观察性,本文关于Agent系统表现、客户结果和企业经营价值之间连接的判断均由ANC提出。
  4. 文中的全渠道零售企业、Agent Dashboard和经营报表均为设想场景,不对应具体企业,也不构成库存、履约或项目评估建议。本文不计算ROI,不要求把所有经营变化归因于Agent,也不判断试点能否在完整业务条件下持续成立。

感谢你看到最后,如果你觉得有启发,随手点个赞、在看、转发吧,如果想第一时间收到推送,也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi,AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室,目前有两个主要研究方向:
塔迪AI工程系列」FDE落地工程、ANC:AI Native Company未来公司系列、GEO、AI判断工程。
塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践,深层共鸣的探索。不是用AI解读经典,也不是用经典指导AI。 这是一场跨越2500年的对话,在算法与古老智慧之间,照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025