三类部署，三种归因口径
把三组材料并排，增量不在于「谁的效果更好」，而在于每个数字对应的是哪一段系统。工业平台给的是运行侧效果，客服案例给的是链路同比节省，办公部署给的是采用侧折算量；三者的分母、观测窗与发布方性质都不同。
| 材料 | 发布方与性质 | 主要读数 | 归因对象 |
|---|---|---|---|
| CrossnoKaye ATLAS / AURA | AWS 机器学习博客 2026.11.09 起的客户案例，另有多家技术媒体全文转述与一篇独立归因分析 | 吞吐 +11%~17%、能耗 −21%、22 万亿数据点、日增 500 亿读数、1000+ 在线 APC 应用 | 效果读数属 ATLAS 上的先进过程控制应用；AURA 属分析与排查层 |
| DoorDash / Orion Health | AWS 客户案例，经行业媒体汇总 | 转人工 −49%、首解 +12%、同比节省 300 万美元；50 万条记录 1 分钟内检索、日省约 50 工时 | 客服链路与检索链路，均为厂商案例 |
| Wipro / Bristol Myers Squibb | 微软公告，经行业媒体汇总 | 月活超 95%、750 万 prompts 每月、25 万 FTE 天每季、2.9 万自建智能体 | 采用与折算口径，非单流程 ROI |
据此可以把证据分成三级：运行侧效果级（有过程读数，但归因对象是已运行的控制应用）、链路同比级（有金额与时间节省，但只覆盖一个业务环节）、采用折算级（有使用量与折算天数，不给单流程收益）。三级之间不能互相补齐——把工业平台的吞吐提升乘以客服案例的金额节省、再套用办公部署的折算天数，得到的复合数字没有任何来源支撑（原创口径辨析）。
读落地复盘时，头一个动作不是比百分比大小，而是问这个变化是哪一段系统带来的、原文有没有把它记在那个系统名下。三段材料里，只有工业平台那一篇在自己的正文里明确写了效果来自一千多个控制应用，也正因如此，它同时暴露出一个常见误读：把平台整体读数当作智能体增量的前后对比。
需要标注来源性质：AWS 与微软的材料都是发布方或客户案例，技术媒体为转述，独立归因分析为第三方评述；本文按「官网或官博 → 全文转述 → 汇总媒体 → 独立评述」的顺序标注证据强度，不把转述当原文（原创证据分层）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是三组案例的观测窗是否一致、是否有统一的效果核算口径，以及是否存在经第三方审计的结果。
CrossnoKaye：11–17% 记在过程控制应用账上
CrossnoKaye 的 ATLAS 是软件定义的自动化平台，接在既有 PLC 与 DCS 基础设施之上，不需要替换厂内硬件。公开材料给出的规模是：覆盖超过 100 家工业设施、1.3 万台受控资产，存储超过 22 万亿条机器数据点，每天新增超过 500 亿条读数，运行超过 1000 个在线先进过程控制（APC）应用；这些应用把生产吞吐提升 11% 至 17%，并让设施总能源成本平均下降 21%（来源：AWS 机器学习博客案例，经 DNA Insider、Tech Bytes、syncai.news 等全文转述）。
| 架构层 | 公开做法 | 对归因的意义 |
|---|---|---|
| 边缘控制层 | 厂内部署带冗余计算机、电源与交换机的 ATLAS 控制柜，跑本地 Kubernetes 与契约优先微服务；云端编写、校验并版本化基础控制叙述后下发，断网时本地继续运行；控制柜为仅出站网关，厂内零入站防火墙端口 | 控制动作在边缘执行，与云端智能体解耦 |
| 云端优化层 | S3 中版本化 Python 包跑两条流水线，计算热流分布、资产健康指数、能耗强度与物量平衡偏差等派生指标；设定值经 SQS FIFO 按设施严格排序后下发，平台报出每天 65 万次闭环控制动作 | 11%~17% 与 21% 对应这一层的一千多个 APC 应用 |
| AURA 智能体层 | 部署在 EKS 上、以 Temporal 持久工作流编排；经内部 Atlas Data 网关读取设备拓扑、联锁、基础控制逻辑与传感读数，查询经内部 Model Gateway 与 Bedrock Guardrails 约束；需要统计或物量计算时，调用 AgentCore Code Interpreter 在隔离 microVM 沙箱内运行 Python | 负责规划排查与出带引用的技术简报，不直接产生控制效果读数 |
归因的关键句在原文里：大语言模型擅长理解工程语境与规划排查，但无法被信任在提示词里对百万级传感读数做统计与物量平衡，所以 AURA 把这些计算交给隔离沙箱里的 Python，并拒绝发布未经验证的数字。这条设计约束恰好说明 AURA 的增量在哪一侧——它降低的是「模型编造数值结论」的风险，而不是「控制回路调得更优」（原创归因解读）。
还有一处权限设计值得单列：AURA 的自动化 Routines 可由排程、传感阈值、变化率区间、告警或设备模式切换触发，但以只读模式运行；涉及设定值变更时须取得明确的人工核准。公司另报出每年超过 9000 次控制软件部署、累计超过 100 万运行小时且无安全事故（来源：DNA Insider 中文转述、Tech Bytes 架构全文）。
按公开读数可做三条结构折算：22 万亿除以 500 亿约 440 天，即按当前日增速率重填一遍存量约需 1.2 年；500 亿除以 100 家设施约 5 亿读数每家每日；1000 个 APC 应用除以 100 家设施约 10 个每家（原创换算）。三条都是机械均摊，前者不代表数据保留策略，后两者不代表实际分布，列出它们是为了标出哪些数看起来像效益、实际只是分母游戏。
另有一处容易顺手算错：100 万运行小时除以 9000 次部署约 111 小时每次部署，看似是「平均部署运行时长」，但前者是跨设施累计时长、后者是年度部署次数，两者分母不共享，商数没有可解释的含义（原创反例）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是 APC 应用在 AURA 上线前后的对照读数、1000 个应用的行业分布，以及 65 万次闭环动作与 11%~17% 之间的核算链路。
DoorDash 与 Orion Health：300 万美元与 50 工时
同一批行业汇总里还有两条形态完全不同的读数。DoorDash 用 AWS 技术与 Anthropic Claude 改造客服运营，报出转人工比例下降 49%、首次解决率提升 12%，以及同比 300 万美元运营成本节省；Orion Health 用 AWS 服务在一分钟内检索超过 50 万条内部记录，为支持团队每天节省约 50 工时（来源：InfotechLead 汇总，引 AWS DoorDash 客户案例与 Orion Health 案例）。同一篇汇总也提醒，企业还需另行核算推理费用、集成成本与应用维护。
| 读数 | 性质 | 分母 / 观测窗 | 能否进财务列 |
|---|---|---|---|
| 转人工 −49% | 相对变化 | 转接量，未给基线具体数值 | 中间指标 |
| 首解 +12% | 相对变化 | 首次解决量，与转接量不同集合 | 中间指标 |
| 同比节省 300 万美元 | 经营指标 | 同比、客服链路、未给科目拆分 | 可列条件性金额，需标注未扣成本项 |
| 50 万条记录 1 分钟内检索 | 吞吐读数 | 单次检索，未给并发与准确率 | 技术中间指标 |
| 日省约 50 工时 | 折算量 | 日，未给基线人力与核算方法 | 需先澄清基线再决定是否采用 |
49% 与 12% 的分母不同，一个是转接量、一个是首次解决量，不能相乘成「综合提升 61%」之类的合成值；它们与 300 万美元之间也没有给出换算式，因此不能反推「每减少一次转接省多少钱」（原创口径辨析）。50 万条除以 60 秒约 8333 条每秒（原创换算），这是吞吐的量级示意，不是检索准确率；同样，日省 50 工时若按 250 个工作日年化约 1.25 万工时，但原文未给基线人力、观测天数与是否含峰值，年化值只能作为条件性估算，不可与金额相加。
把这两条与办公侧的采用读数放在一起，会看到第三种口径：Wipro 报出月活超过 95%、每月约 750 万次 prompts、每季度超过 25 万 FTE 天、约 2.9 万个自建智能体（来源同上）。FTE 天是按人折算的季度量、prompts 是月度使用量、智能体数是累计存量，三者时间窗不同；本文在本站 R-INDUSTRY-63 已作按人折算，此处只作为「采用侧读数不能进单流程 ROI」的对照，不重复计算（内部对照说明）。
汇总材料在给出 300 万美元的同时明确提示还有推理费、集成成本与应用维护。这意味着公开金额是某一环节的经营改善，不是扣完全部新增成本后的净收益。把它与 50 工时、25 万 FTE 天并列相加，等于把三种不同核算口径的产物塞进同一张损益表。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是 DoorDash 的基期具体数量、300 万美元的科目构成，以及 Orion Health 的日省 50 工时对应的团队规模与测量方法。
同一篇材料里的两组效果，归因范围不同
CrossnoKaye 案例里还有一组容易被一起引用的读数：批次干燥时间标准差下降 34%、成品率达标的产品多 6%、某采石场识别出每年超过 5 万吨可回收的产能缺口，以及一次排查在不到四分钟内完成。把两组读数分列，会看到归因范围并不相同。
| 读数 | 原文归因 | 与 11%~17% 的关系 |
|---|---|---|
| 吞吐 +11%~17%、能耗 −21% | 平台上运行的一千多个在线 APC 应用 | 归到云端优化层，与 AURA 无前后对比 |
| 干燥时间标准差 −34%、达标产品 +6% | 边缘控制、云端优化与 AURA 的组合效果 | 组合归因，不能单独记到智能体名下 |
| 采石场每年 5 万吨可回收产能 | AURA 结合传送带拓扑与已部署联锁定位出故障链路后识别的缺口 | 属「可识别的潜在产能」，非已实现产出 |
| 一次排查不到四分钟 | AURA Chats 的技术简报产出时长 | 过程耗时指标，不是效益金额 |
采石场案例的过程值得记：破碎回路在一个班次内两次跳闸，操作员看到二级破碎机故障告警、清除后重启，数小时后再跳；historian 时间戳显示二级破碎机在三级之后数秒报障，因此被怀疑是设备内部故障。AURA 把传送带拓扑与已部署的基础控制联锁放在一起分析，定位到跨设备的联锁关系，而非单台设备（来源：syncai.news 与 Tech Bytes 全文转述）。这条链路说明 AURA 的增量在跨系统的关联排查，与 APC 的设定值优化是两件事。
把 5 万吨乘上任何单价、再与 11%~17% 的增产相加，都缺少同一口径：前者是「识别出的可回收产能缺口」，属潜在量，且未给是否已被回收、回收成本与产品单价；后者是已报出的运行效果比例（原创口径辨析）。同理，34% 是标准差的下降、6% 是达标产品占比的变化，一个是离散度、一个是比例，不能相加成「质量提升 40%」。
还有一处设施数的口径差：ATLAS 覆盖超过 100 家工业设施，而 AURA Chats 一次可处理单一设备、单个工艺线，或最多涵盖 200 座设施的多据点组合（来源：DNA Insider 中文转述）。两个「设施数」一个是平台覆盖规模、一个是单次查询的范围上限，不构成「200 大于 100 所以能力超出」的比较（原创量纲辨析）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是 34%、6%、5 万吨各自的观测期与基线，以及组合效果中 AURA 单独贡献的拆分方法。
四列 ROI 记账：先把归因写进表
把本轮主要读数按「读数、性质、分母或观测窗、证据等级」四列填表，并额外在性质列里注明归因对象。这张表的作用是在合计之前先判掉不能相加的项。
| 读数 | 性质与归因对象 | 分母 / 观测窗 | 证据等级 |
|---|---|---|---|
| 吞吐 +11%~17%、能耗 −21% | 运行侧效果；归 1000+ APC 应用 | 设施级，未给观测期 | AWS 官博案例，经多家全文转述 |
| 22 万亿数据点、日增 500 亿读数 | 平台规模；非效益 | 累计存量 / 日 | 官博案例 |
| 65 万次闭环控制动作每日 | 运行量；非效益 | 全平台 / 日 | Tech Bytes 架构全文转述 |
| 干燥标准差 −34%、达标 +6% | 组合效果；含边缘、云端与 AURA | 批次 / 产品，未给基线 | 官博案例，经转述 |
| 5 万吨可回收产能 | 潜在产能缺口；非已实现节约 | 年、单采石场 | 官博案例，经转述 |
| 同比节省 300 万美元 | 经营指标；归客服链路 | 同比 | AWS 客户案例，经媒体汇总 |
| 日省约 50 工时 | 折算量；归检索链路 | 日，基线人力未给 | AWS 案例，经媒体汇总 |
| 25 万 FTE 天每季 | 采用侧折算量；非单流程收益 | 季，与月度 prompts 不同窗 | 微软公告，经媒体汇总 |
表内没有一行四列齐备到可以直接进合计列：运行侧效果缺观测期与智能体前后对照，组合效果缺拆分方法，潜在产能缺单价与是否已回收，同比金额缺科目构成，折算量缺基线。这个结论不是对材料质量的判断，而是把归因边界显式写进表格之后的必然结果（原创记账结论）。
四列之外再加一问会更稳：这项读数在原文里被记在哪个系统名下。CrossnoKaye 的一组效果读数之所以能与其他案例拉开差距，不是因为数值更大，而是因为它是本轮材料里少数自带归因说明的一组——原文明确写了效果来自 APC 应用。有归因说明，才有资格谈「智能体增量是多少」这个问题（原创框架说明）。
把 300 万美元与 50 工时按四列填完，再看它们与 25 万 FTE 天的关系：三者分别对应客服链路、检索链路与全公司采用折算，分母是同比金额、日工时与季度折算量，任何两列相加都需要先补一份同源核算表，而公开材料没有给（原创口径辨析）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是三案例的投入成本、经核实的财务净额，以及任何一份可与公开读数对照的审计材料。
可复现六步路径
把三段材料里能交叉印证的动作抽出，可整理成一条不依赖特定厂商的六步路径。它描述的是顺序与检查点，不是效果承诺；其中与模型能力关系不大的步骤占多数。
| 步骤 | 动作 | 三份材料里的依据 | 检查点 |
|---|---|---|---|
| 一 | 先建软件定义的底座，统一设备模型、historian 与基础控制 | ATLAS 在既有 PLC / DCS 上统一设备模型、控制叙述与历史数据 | 跨系统命名与联锁是否可查询 |
| 二 | 边缘冗余与仅出站网关，断网时本地继续运行 | 本地 Kubernetes 控制柜、零入站端口、断网可独立控制 | 云连接中断时控制是否降级 |
| 三 | 把数值计算放进隔离沙箱，模型只做规划与解释 | AgentCore Code Interpreter 在 microVM 内跑 Python，拒绝发布未经验证的数字 | 每个数值结论能否回溯到脚本与数据源 |
| 四 | 只读例程起步，配置变更走显式人工核准 | AURA Routines 只读，设定值变更需明确批准 | 高危动作是否默认关闭 |
| 五 | 先定归因边界再定指标，区分控制效果与智能体效果 | 11%~17% 归 APC 应用，组合效果单列，采石场缺口标为潜在量 | 每项读数是否写明归到哪个系统 |
| 六 | 用不可变版本快照与同源基线复盘，保留回滚路径 | 任务使用不可变版本快照，产出附引用证据表与图表的技术简报 | 观测窗与分母是否前后一致 |
六步里第五步最容易被跳过，而它恰恰是本轮材料给出的最有迁移价值的一条：如果不先把 11%~17% 归到 APC 应用，后续任何「智能体带来多少增产」的复盘都会从一开始就建立在错误基线上。第三步也值得单独记——把计算从提示词里挪进沙箱，是用架构约束换数值可信度，而不是靠提示词要求模型「不要编」（原创解读）。
需要说明边界：六步是从公开材料归纳的实施顺序，没有对照实验支持，也不构成效果保证；不同规模、安全等级与合规要求下的步骤取舍会不同。本站 R-CASE-60 归纳的六步侧重「披露强度分级」，本篇六步侧重「归因与控制边界」，两者可叠加使用但不互相替代（内部对照说明）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是六步各自的工期基线、失败率与回滚条件，以及在多厂区推广时的成本曲线。
三条红线与可证伪边界
结合三段材料暴露的口径缺口，给出引用与落地时的三条红线。
| 红线 | 具体所指 | 违反后会造出什么 |
|---|---|---|
| 不把平台整体效果记到智能体账上 | 11%~17% 与 21% 归 1000+ APC 应用，AURA 无前后对比 | 把长期运行的过程控制收益写成智能体上线后的增量 |
| 不把不同归因范围的读数相加 | 34% 标准差、6% 达标变化、5 万吨潜在产能属组合或识别结果 | 把离散度、比例与潜在吨数拼成「综合提升」 |
| 不在分母未澄清前汇总 | 300 万美元为同比、50 工时每日基线未给、25 万 FTE 天为季度折算 | 把同比金额、日工时与季度折算量塞进同一张损益表 |
可证伪边界要写清。AWS 官博案例给出了架构与规模读数，但没有给出 AURA 上线前后 APC 应用效果的对照，因此本文只能判断「归因对象在原文中被写明」，不能判断「AURA 对 11%~17% 的贡献为零」。若后续披露 AURA 参与设定值优化的前后对照并显示贡献显著，本轮的归因分层即需按新证据修订（原创可证伪设计）。
一条可复现的检验路径是：取同一批历史告警与同一份 historian 数据，在「只读 AURA 分析」与「人工排查」两种配置下分别记录定位时长、结论一致率与是否引用了可回溯的脚本；若两者在定位时长上无差别，则 AURA 的增量限于关联排查路径与数值可核验性，而非排查速度。另一条是要求披露 1000 多个 APC 应用在 AURA 上线前后的设定值与吞吐读数，用同源基线直接核对 11%~17% 是否变化。公开材料目前都未给出这两组数据，本文列为待验证项（原创检验设计）。
本轮三份材料里，工业平台那篇自带归因说明，反而最容易被误读成智能体成效；客服与检索案例归因清楚，却缺少净额口径。落地复盘的价值不在于把效果数字报得更大，而在于把每段系统各自贡献了什么、还有哪些没被计量写明白。缺这一列，四列记账就永远填不满。
与本站已覆盖的案例划清边界：R-CASE-57 讨论单据到现金流链路里的账期与按 token 计费，R-CASE-59 讨论客户入职与县域制造的验收口径，R-CASE-60 讨论三类披露强度下的 ROI 记账分层；本篇切口是同一批读数在不同系统之间的归因归属，所选三案例与那三篇不重叠（内部对照说明）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是三案例的项目费用、经核验的财务净额、失败与回滚记录，以及上线 3 个月之后指标是否保持。
未披露项与内部对照
把可引用的与不能外推的分开列，是这篇复盘的收尾。可引用的是：ATLAS / AURA 三层架构与权限设计、100 多家设施与 1.3 万台资产等规模读数、APC 应用对应的 11%~17% 与 21%、以及 DoorDash 与 Orion Health 的案例读数及其各自的链路归属。不能外推的是：把 APC 效果当作智能体前后对比、把组合效果拆成智能体单独贡献、把潜在产能折算成已实现收益、把同比金额与工时折算量相加。
- 缺对照：没有任何一份材料给出 AURA 上线前后 APC 应用效果的同源对照。
- 缺净额：300 万美元与 50 工时都未附新增成本科目，汇总媒体自身也提示需另算推理与集成费用。
- 缺基线：34%、6%、5 万吨与 25 万 FTE 天均未给基线具体数值或核算方法。
- 缺统一口径：三段案例的观测窗分别为设施运行期、同比与日或季度，没有共同核算表。
- 发布方立场：AWS 与微软为客户案例发布方，技术媒体为转述，独立归因分析为第三方评述；案例选择天然偏向成功样本。
还要说明一处引用纪律：本文对 CrossnoKaye 的架构细节以 AWS 官博客案例的多家全文转述交叉核对，对「11%~17% 属 APC 应用而非 AgentCore 前后对比」这一判断，除原文句式外另参考了一篇独立归因分析的评述；但该判断本质上是本文按原文句式与架构分层自行核对得出的，未把评述文章的表述当作原文事实引用（原创来源说明）。
对准备做类似复盘的团队，一条较稳的顺序是：先固定系统与流程边界，再逐项给读数标注归因对象，然后按四列填表，最后才讨论是否汇总；每换一版系统或流程，重跑同一批历史样本，比较的是归因结构而不只是效果数字。这条顺序是从公开材料的缺口倒推出来的实施建议，没有对照实验支持，也不构成效果保证（原创框架说明）。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是三案例的投入成本、经第三方核验的财务结果、失败与回滚记录，以及任何一份可与公开读数对照的审计材料。