三个样本，三种「时间」口径
先把三组数字的原值与边界摆在一起，比直接谈经验更不容易跑偏（来源：亿邦动力 / 网易 2026-11-05；AWS 官方博客与 Circle K 合写稿 2026-11-02、GenAI Gazette 2026-11-05；Constellation Research 与 TheNextGenTechInsider 关于 Team Air 的报道）。
| 企业 / 场景 | 原值 → 新值 | 指标口径 | 是否包含末端动作 |
|---|---|---|---|
| 李宁 / 集团多场景智能体 | 50 个左右 Agent → 一年累计折算 46 万等效工作小时，约合 220 名员工工作量 | 观察期年化后相加的折算工时 | 含场景内执行，但不含 IT 部门 Coding 时间 |
| Circle K / DevOps 事件分诊 | 平均 45 至 60 分钟 → 15 分钟以内，降幅 67% 至 75% | 从告警到给出书面诊断的耗时 | 不含修复：智能体不解决事件，只给起点 |
| Team Air Distributing / ERP 查询与发票 | 15 至 20 分钟 → 约 60 秒；年省 2000 小时以上 | 单次查询耗时 + 年度累计节省工时 | 含查询与发票处理，节省工时来自流程挖掘对比 |
三行放在一起就看出问题：李宁的 46 万是「折算」、Circle K 的 15 分钟是「环节」、Team Air 的 2000 小时是「节省」。它们的分母分别是年化工时、单次事件、年度累计，既不能相加，也不能互相当作对方的验证。下面逐案拆口径。
这三组数字的价值不在大小，而在它们各自暴露了计量口径的一个薄弱点：折算会放大外推、环节耗时不等于端到端结果、年度节省需要能反推出调用频次。把这三件事写进验收表，比引用任何一个百分比都更有用。
李宁：46 万等效工时是怎么折算出来的
亿邦动力的报道给出了折算规则的原文口径：一个 Agent 上线用了两个月、跑了 100 小时，就按 12 个月折算成 600 小时；所有已上线、运行时间各不相同的 Agent 统一折成一年再相加（来源：亿邦动力 / 网易，2026-11-05，李宁集团信息系统总经理李飞）。这条规则是理解 46 万的关键——它不是实跑工时，而是年化外推值。
| 项目 | 原文数据 | 本栏目换算 / 说明 |
|---|---|---|
| 折算示例 | 2 个月跑 100 小时 → 年化 600 小时 | 外推倍数 6 倍，等于假设后续 10 个月维持同一使用强度 |
| 累计折算值 | 46 万小时，约合 220 名员工 | 46 万 / 220 ≈ 2091 小时每人每年，与常见全职年工时同量级，说明是工时折算而非人力替代 |
| 来源集中度 | 三分之二来自数字店长 | 约 30.7 万小时来自单一场景，其余约 15.3 万小时由多场景分摊 |
| 其余场景 | 导购陪练、知识问答、客服、经营分析、物流供应链 | 头部场景高度集中，平均值不宜用于单场景预期 |
| 未计入部分 | IT 部门 Coding 时间未计算在内 | 原文明确说明，若计入会明显更高，但未给量 |
| 一年目标 | Agent 扩到 200 个、折算工时 460 万小时 | 工时 10 倍、数量 4 倍，见交叉换算 |
筛选过程比结果更可复现。李宁在去年底搭建 AI Studio，把 AI 规划纳入设计开发、供应链、商品、终端、职能五个方向；今年初通过几十场 Workshop 梳理出 200 多个候选场景，最终挑 20 多个重点打造，两条筛选标准是复用性（一两个人用还是多部门都能用）与效率提升倍数（提升一个人还是 100 个人、两倍还是十倍）（来源：同上）。报道还记录了一条很务实的排除规则：如果原有数字化系统增强就能解决痛点，就不必用 AI（来源：同上，李飞表述）。
落地路径上还有几步值得抄：企业版部署的 WorkBuddy 先清理掉大量与工作无关的专家和 Skills，再着手建立「宁专家」，覆盖门店经营、门店日报、财务分析、HR 招聘；安全侧在拿到数据存储与调用记录相关说明、更新信息安全制度、部署安全网关与防泄漏手段后才逐步开放；数据侧不全量交给 AI，而是用 AI 做分析工具，工具本身仍跑在内部业务系统或决策支持系统里；IT 定位为赋能者，把业务部门用 AI Coding 做的工具工程化、接上组织与经营上下文（来源：同上，含李飞与集团 AI 创新总监刘磊的「扫盲、扫描、扫除」概括）。这些步骤合起来，构成一条可复现的六步路径，见后文表格。
Circle K：三合一，压缩的是取证而非决策
Circle K 是覆盖 27 个国家、超过 17,200 家门店的便利零售运营商。它与 AWS 合写的稿件在 2026 年 11 月 2 日公开，说明已把生成式 AI 事件分诊投入日常生产使用（来源：AWS 官方机器学习博客，2026-11-02；GenAI Gazette 全量直读，2026-11-05）。原有流程里，告警只告诉值班工程师「有东西坏了」，查云资源、搜日志与链路、看最近代码变更都靠人工，平均分诊 45 至 60 分钟，跨多服务的复杂事件超过一小时。
| 阶段 / 指标 | 改造前 | 改造后 | 说明 |
|---|---|---|---|
| 平均分诊时长 | 45 至 60 分钟 | 15 分钟以内 | 原文给出降幅 67% 至 75%，以公司自身事件响应记录为基线 |
| 简单事件 | 未单列 | 5 至 8 分钟出书面摘要 | 摘要发到工程团队 Slack 频道 |
| 复杂多服务事件 | 超过 1 小时 | 15 分钟内 | 仍需工程师接续处理 |
| 架构 | 初版三个独立智能体 | 2026-04 合并为单个智能体，带对各数据源的代理访问 | 合并后的设计目前在生产运行 |
| 底座 | 人工排查 | Amazon Bedrock，检查资源、日志、链路与代码变更 | 输出为书面诊断起点，不执行修复 |
报道里最该被加粗的一句是：收益不来自更好的判断，而来自移除了「告警」与「人的决策」之间的证据收集；智能体不解决事件，只把工程师从面对空白页变成面对一份诊断（来源：GenAI Gazette，2026-11-05）。因此 67% 至 75% 只覆盖分诊环节，不能写成平均修复时间或业务中断时长的同幅改善。另一条可复现经验是架构并非一次定型：初版拆成三个智能体，2026 年 4 月合并成一个带代理访问的智能体，稿件由此提示要为重建留预算（来源：同上）。把输出放进团队已有的聊天频道而不是新看板，也被列为避开采用率问题的做法。
Team Air：嵌进 ERP 的 60 秒与年省 2000 小时
Team Air Distributing 把智能体嵌在 Infor Velocity Suite 内，员工在既有 ERP 流程里用聊天界面查询实时库存与客户信用数据，无需切换到独立应用。Constellation Research 的报道记录了从「先问哪里最费劲」出发的做法：目标不是加 AI，而是找出员工已经在抱怨的高摩擦任务（来源：Constellation Research 案例页；TheNextGenTechInsider 技术拆解）。
| 项目 | 原值 / 目标 | 结果 | 备注 |
|---|---|---|---|
| 库存与信用查询 | 15 至 20 分钟人工检索或打电话问分点 | 约 60 秒 | 聊天界面直接在 ERP 内返回结果 |
| 发票处理自动化 | 目标 60% 至 70% | 达到 75% | 超出目标上限 5 个百分点 |
| 年度节省工时 | 未给基线 | 2000 小时以上 | 口径来自流程挖掘的前后对比 |
| 度量方法 | 无 | Infor Velocity Suite 的流程挖掘能力 | 同时比对时间节省与错误率 |
| 架构补充 | 专用智能体覆盖范围有限 | 对超范围复杂查询设受控的 Claude Haiku 连接 | 混合式，专用与通用分离 |
| 后续方向 | 应付应收 | 采购与 procure-to-pay | 继续用流程挖掘找高摩擦点 |
这组样本的可复现点有两个。其一是「先定结果目标再上线」：发票自动化 60% 至 70% 的目标先立，再报告 75% 的实际值，避免事后挑好看的指标。其二是用流程挖掘而非问卷来比对时间节省与错误率，让 2000 小时这个数字有前后可对照的流程来源（来源：Constellation Research 案例页）。不过该数字未逐场景拆分，因此下文只做反推自检，不把它当作精确结论。
八组原创换算：这些数字为什么不能相加
| 编号 | 换算 | 结果 | 用途与限制 |
|---|---|---|---|
| 一 | 46 万 / 220 人 | 约 2091 小时每人每年 | 验证「220 名员工」是按标准年工时折算，不是裁撤或替代人数 |
| 二 | 460 万 / 46 万 与 200 / 50 | 工时 10 倍、数量 4 倍 | 隐含单个 Agent 等效工时或调用密度需再提升约 2.5 倍，原文未展开实现路径 |
| 三 | 46 万 × 2/3 | 约 30.7 万小时 | 数字店长贡献，其余约 15.3 万小时由多场景分摊，头部集中度高 |
| 四 | 100 小时 / 2 个月 × 12 个月 | 600 小时，外推 6 倍 | 年化假设后续使用强度不变，季节性或不饱和场景会放大估值 |
| 五 | 200 余候选 → 20 余重点 | 保留约 10% | 按原文「200 多个」「20 多个」作量级估算，非精确比例 |
| 六 | (45−15)/60 与 (60−15)/60 | 50% 与 75%，原报道口径 67% 至 75% | 降幅区间依赖基线取值；无论如何只覆盖分诊环节 |
| 七 | 2000 小时 ÷ 单次节省 14 至 19 分钟 | 约 6300 至 8600 次查询每年 | 由 15 至 20 分钟压到 60 秒反推的自检量级，用于核对自家调用频次是否撑得起该数字 |
| 八 | 75% − 70% 与 75% − 60% | 超出上限 5 个百分点、下限 15 个百分点 | 目标达成度应与整体水平分开记，75% 仍留下四分之一未自动化 |
第六行需要额外说明：原报道给出的降幅是 67% 至 75%，本文用 45 至 60 分钟基线与 15 分钟上限做区间核算，下限得到 50%，与报道口径不一致，原因在于「15 分钟以内」是上限而非实际均值，原文未披露改造后均值（来源：GenAI Gazette，2026-11-05）。因此本文保留报道原始区间，不采用自行推算的 50% 作为结论，并把它列为待核验项。这类不一致本身就是一个提醒：区间数字往往来自不同的基线取值与不同的统计量。
第七行的反推同样不是结论，而是一道自检题：若某企业年查询量只有几百次，却对外宣称年省 2000 小时，就要回头核对节省是否来自别的流程（Team Air 的 2000 小时同时含发票处理）。三个样本的账不能相加，正是因为各自的边界都埋在这种细节里。
六步可复现路径与四列记账模板
| 步骤 | 动作（取自三案共性） | 对应样本 | 交付物 |
|---|---|---|---|
| 一 | 先找高摩擦、已有基线的任务，不先选模型 | Team Air、李宁 Workshop | 带原值时长的任务清单 |
| 二 | 按复用性与效率倍数筛场景，原有系统能解决就排除 | 李宁 200 余 → 20 余 | 优先级表与排除理由 |
| 三 | 上线前定结果目标与验收口径，含人工复核规则 | Team Air 60% 至 70% 目标 | 指标定义文档 |
| 四 | 把输出送进员工已有的工作界面，不新增看板 | Circle K 的 Slack 摘要、Team Air 的 ERP 内聊天 | 集成点与采用率记录 |
| 五 | 安全与数据边界先行：制度、网关、工具留在内部系统 | 李宁三道关口 | 权限矩阵与外发管控记录 |
| 六 | 预留架构重建预算，按度量结果收敛智能体数量 | Circle K 三合一 | 迭代记录与回滚方案 |
| 记账列 | 要记什么 | 本轮三案暴露的坑 |
|---|---|---|
| 时长节省 | 原值、新值、取的是均值还是上限 | Circle K 的「15 分钟以内」是上限，不能当均值 |
| 质量变化 | 错误率、复核退回率、是否引入新失败模式 | Team Air 用流程挖掘同时看错误率，另两案未披露 |
| 频率改变 | 调用次数、使用密度、季节性波动 | 李宁年化外推默认强度恒定，需频率佐证 |
| 复核成本 | 人工复核时长、谁认定「有效完成」、是否含末端动作 | Circle K 明确不解决事件，末端动作仍在人工侧 |
四条避坑红线
其一，折算值不得写成实跑值：李宁的 46 万是观察期年化后相加，原文自己说明未计 IT 部门 Coding 时间，引用时须同时给出这两条限定。其二，环节改善不得写成端到端改善：Circle K 的 67% 至 75% 只覆盖分诊，修复与恢复时长未披露。其三，年度节省不得脱离调用频次：没有频次与逐场景拆分，2000 小时无法复核。其四，跨企业数字不得相加或横向排名：三者分母、边界、是否含末端动作都不同，能比较的只有计量方法本身。
关于李宁 460 万小时目标的具体实现路径与各场景折算明细、Circle K 的事件总量与平均修复时间变化、Team Air 2000 小时的逐场景拆分与改造后分诊均值，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。