三个 11 月样本与共同起点
本轮复盘的材料集中在 2026 年 11 月 2 日至 5 日：emergent.sh 于 11 月 3 日报道 Worldwide Express 的应收账款智能体上线；Forbes Liberia 刊出 CJ Logistics 与 Infios 六个月智能体化的过程回顾；商派 ShopeX 于 11 月 5 日发布《当 Agent 的回报写进利润表》，归纳三档国内经营级样本。三者行业相近（物流、供应链、流通），但读数单位差别很大。
| 样本 | 切入流程 | 公开读数单位 | 来源属性 | 是否具名 |
|---|---|---|---|---|
| Worldwide Express × AWS | 应收账款：发票、对账、争议、催收 | 营运资金、账期天数、处理时长、工时 | 科技媒体报道，单一来源 | 具名企业 |
| CJ Logistics × Infios | 承运商状态更新跟单 | 班次时间占比、每票成本、token 计费 | 行业媒体访谈，单一来源 | 具名企业 |
| 国内三档样本 | 调货、报关、结算 | 月节省金额、净利增幅、时长、缺货率、周期 | 厂商内容文章，文末含代理商推广 | 未具名 |
共同起点不是模型选型，而是切口选择：三份材料都把智能体放进高频、重复、规则明确的单据环节——发票匹配、状态跟单、调货分配、报关与结算。这些环节的输入是结构化或半结构化单据，输出是可核对的动作，出错时也有明确的人工接管点。这与本站 R-CASE-56 归纳的「公开读数多为中间指标」并不冲突：本轮样本的不同之处，是有几项读数直接落在现金流与账期上，而不是停留在处理时长。
Worldwide Express：应收账款四环节
据 emergent.sh 11 月 3 日报道，美国物流服务商 Worldwide Express 把 AWS AI agents 用于应收账款流程，官方口径为释放 1000 万美元此前被人工处理延迟占用的营运资金。报道把改善归因于现金转换周期平均缩短 18 天：此前发票匹配、争议处理与跟进沟通依赖人工，导致回款延迟；智能体接手后自动识别付款差异、把发票与收款匹配，并在无需人工介入的情况下发起客户沟通。
| 环节 | 智能体动作 | 公开读数 | 口径备注 |
|---|---|---|---|
| 发票生成与投递 | 按运输完成事件触发 | 未单列 | 与 ERP 事件流对接 |
| 付款对账 | 跨多个支付渠道实时匹配 | 未单列 | 需处理部分付款与差异 |
| 争议检测与路由 | 识别异常并分派解决工作流 | 未单列 | 未解决项应升级人工 |
| 客户沟通 | 自动回应发票状态、付款条件与账单问题 | 跟单工时降 43% | 报道未给基线工时 |
| 高风险账户 | 预测分析，逾期前识别 | 未单列 | 未给准确率或召回率 |
| 汇总读数 | 数值 | 换算 | 必要的限定 |
|---|---|---|---|
| 释放营运资金 | 1000 万美元 | 除以 18 天约 55.6 万美元每天 | 属假设性反推，非公司披露的日均应收规模 |
| 现金转换周期压缩 | 平均 18 天 | 与上一行同属资金占用口径 | 「平均」未给分布与样本期 |
| 应收账款处理时间 | 降 67% | 约快 3.03 倍 | 未给原始时长与任务构成 |
| 跟单工时 | 降 43% | 剩余约 57% | 与上一行分母不同，不可相加 |
技术栈方面，报道提到 AWS Bedrock 的基础模型结合针对物流计费模式定制训练的算法，并通过 AWS Lambda 与 API Gateway 与既有 ERP 集成，让数据在遗留系统与新增智能体层之间流动。这里值得记的是集成方式：没有替换 ERP，而是在其上加一层事件驱动的处理与对账。报道未披露上线周期、投入金额、错误率与人工接管比例。
CJ Logistics：承运商状态跟单
Forbes Liberia 的访谈回顾了 CJ Logistics 与 Infios 约六个月的智能体化过程。选择合作方的理由很实际：Infios 工程团队熟悉自己的工作流触发条件与平台架构，可以把智能体能力直接嵌进核心操作系统，避免维护割裂的数据源与定制集成。切入点不是运价谈判这类高风险任务，而是承运商未传送强制状态更新造成的跟单瓶颈——即便 EDI 与可视化工具已普及，司机与调度仍常忽略手工录入，人工陷入反复电话与邮件的循环。
| 实施要素 | 公开材料内容 | 对复现的意义 |
|---|---|---|
| 前置设计 | 为执行跟单设计记忆结构与规则设定协议 | 规则设计触发了内部策略讨论 |
| 决策树 | 邮件还是电话、按承运商画像定制动作、跟单频次 | 把人的经验转成可判定条件 |
| 上线节奏 | 约两个月从概念推进到可运行智能体 | 六个月为整体密集开发周期 |
| 执行方式 | 自动生成语音电话，用 LLM 抽取中断原因码（高速拥堵、仓库滞留延长） | 输出进入结构化字段而非自由文本 |
| 动态调整 | 初次电话礼貌收集数据，未响应者遇到逐渐加强的自动跟单 | 策略随响应状态变化 |
| 人工边界 | 未解决问题无缝升级人工操作员 | 异常处理的兜底 |
| 规模 | 每日监控数千票货物 | 异常管理仍是关键 |
ROI 的表述偏定性但方向明确：此前一线人员把 20% 至 30% 的班次时间用于收集例行位置更新；自动化执行促使承运商遵守追踪标准，长期降低每票成本。定价按 token 消耗计算，且入站呼叫比出站 ping 需要更深的上下文分析，消耗更多 token；团队通过平衡跟单频次与节省的工时建立 ROI 模型。
若把 20% 至 30% 取中值 25%，跟单工时降 43% 后约占班次 14.25%，对应释放约 10.75% 的班次时间。这是把两个不同来源的读数放在一起的假设性估算，CJ Logistics 材料并未给出「降 43%」这一数字（它来自 Worldwide Express），因此该结果仅用于说明量级，不能作为任何一方的实测结论。
路线图还包括自动预约调度（需适配 Walmart、Target 等企业的调度门户）、缺失 POD 文档告警、辅助路由与承运商谈判的决策智能体，以及仓库侧的库存截断、SLA、空间利用与每日任务优先级。受访人 Nuffer 的总结是：识别业务机会比重新设计底层流程简单，写智能体代码远快于让利益相关方就增补后的工作流达成一致。
国内三档对照：调货、报关、结算
商派 ShopeX 11 月 5 日的文章归纳了三档经营级样本，并给出两组辅助读数。需要前置说明：三档企业均未具名，文末包含企业版 WorkBuddy 代理合作与产品推广内容，属于厂商内容文章；下列读数宜当作方法学示例，不宜当作可外推的行业基准。
| 样本 | 公开读数 | 换算与口径提示 |
|---|---|---|
| 生活用纸企业「链算平台」 | 三个月建成连接供应链的平台，仅调货一项每月节省近 800 万元，2026 上半年净利润同比增长超过 50% | 按 12 个月粗算约 0.96 亿元每年，但仅调货一项，且净利增幅受多因素影响，两者不可相加 |
| 港口物流 | 报关 30 分钟压缩到 5 分钟，亏损排查从数天缩短到秒级 | 报关快 6 倍、每单省 25 分钟；「数天到秒级」缺具体基数 |
| 医药流通 | 缺货率 4.9% 降到 2.4%，结算周期 3 天压缩到 1 小时 | 缺货率相差 2.5 个百分点、相对降约 51.0%；结算倍数取决于按自然日还是工作日计，口径未披露 |
| 某网络设备企业 | 员工每天与智能体对话达 130 万次 | 交互量，不是完成任务数或人数 |
| 某零售集团 | 规划 2500 个席位、已覆盖 14 个部门 48 个场景，任务轨迹「体检」后 Token 消耗降低 10% | 2500 除以 14 约 178.6 席位每部门，属规划值；Token 降幅来自调用结构优化而非模型降价 |
文章把结果归因于「四道关」的递进链路：用 MCP 与连接器接进 ERP、CRM（接入真实业务）；用 VPC 与机密计算实现数据不出域（安全托付）；用可观测中心把 Token 与成本算清（衡量投入产出）；用 7×24 小时常驻的托管智能体把验证过的实践铺开（快速复制）。另有内部实践把数字助理托管上云、接管核心 ERP 的 300 多个业务接口，并以 SaaS、VPC、私有化三种形态适配不同数据边界。
文章同时给出三个自检坐标：接不接得进业务流、效果能否量化到经营指标、单点能否沉淀为组织资产。这三问可以直接转成验收题，比任何单一百分比都更耐核查。
可复现六步路径
把三份材料里的实施动作按时间顺序对齐，可以整理出一条不依赖具体厂商的六步路径。每一步都给出「做完应留下什么」，便于在项目里设检查点。
| 步骤 | 动作 | 做完应留下 | 对应样本 |
|---|---|---|---|
| 一 | 选高频、重复、规则明确的小切口 | 场景清单、频次与基线指标 | 调货、报关、结算、发票匹配、状态跟单 |
| 二 | 把流程规则写成机器可判定的决策树 | 渠道选择、承运商画像、跟单频次、争议路由规则 | CJ Logistics |
| 三 | 打通既有系统而非另建系统 | ERP / TMS 事件流、Lambda 与 API Gateway 或 MCP 连接器 | Worldwide Express、国内四道关 |
| 四 | 小规模验证，同时记质量、token 与单位成本 | 质量基线、单位调用成本、可测算材料 | 国内第三步与本站 R-INDUSTRY-59 五步测算法 |
| 五 | 设人工接管与升级边界 | 未解决争议、异常原因码、高风险账户的升级规则 | CJ Logistics、Worldwide Express |
| 六 | 沉淀为可复用 Skill，做轨迹体检后再扩散 | 行业经验封装、调用结构优化、下一场景复用成本 | 商派标准 Skill 与 Token 降 10% |
六步里有三步（二、四、五）与模型能力无关。这也解释了为什么 CJ Logistics 的受访人会把「让利益相关方就增补后的工作流达成一致」列为主要难点：智能体代码只是把已经谈妥的规则执行出来，规则本身谈不拢，代码写得再快也无法上线。
四列 ROI 记账模板
三份材料合起来出现四类收益读数，它们的分母互不相同。把它们并成「总体提升百分之多少」是最常见的记错方式，建议按四列分别记账。
| 列 | 计量单位 | 本轮样本读数 | 记账时应附的分母 |
|---|---|---|---|
| 现金流 | 金额 | 释放 1000 万美元营运资金、调货每月近 800 万元 | 统计期、业务范围、是否含一次性收益 |
| 周转 | 天数 / 时长 | 账期平均缩短 18 天、结算 3 天到 1 小时、报关 30 到 5 分钟 | 基线时长、按自然日还是工作日、单量 |
| 工时 | 班次占比 / 处理时长 | 跟单工时降 43%、应收账款处理时间降 67%、一线 20% 至 30% 班次时间 | 岗位人数、任务构成、复核工时是否计入 |
| Token 与运行成本 | 调用量 / 单价 | 任务轨迹体检后 Token 降 10%、按 token 消耗的计费方式 | 调用结构、入站与出站单价差异、返工量 |
现金流是存量释放，周转是时间压缩，工时是投入变化，token 是运行成本；前两列改善可能来自同一批流程，但不能相加成一个百分比。更实际的做法是每列都填「基线值、当前值、统计期、复核人」，并把复核成本与返工量单独记在备注栏——本站 R-CASE-55 与 R-CASE-56 都提醒过，公开读数里最常缺的正是这两项。
规则先于代码：决策树才是主要工作量
把三份材料里的「非模型工作」抽出来，会看到一条一致的实施顺序。CJ Logistics 在训练智能体执行跟单之前，先要设计记忆结构与规则设定协议，具体到「这一票用邮件还是电话联系」「按承运商画像如何调整动作」「跟单频次设多少」，这些决策树设计反而触发了内部策略讨论；Worldwide Express 的智能体要能判断「识别到付款差异后该走哪条解决工作流」；国内材料则把订单路由、库存调度、授信返利、全渠道对账这类隐性经验封装成标准 Skill。
| 规则类型 | 需要事先谈妥的问题 | 没谈妥时的表现 |
|---|---|---|
| 渠道与频次 | 邮件还是电话、多久跟一次、何时升级 | 重复打扰或漏跟，数据仍缺失 |
| 差异处置 | 部分付款、金额不符、发票缺失分别走哪条路径 | 对账卡住后全部回流人工 |
| 授权边界 | 哪些动作可自动执行、哪些必须人工确认 | 执行动作超出授权范围 |
| 语义口径 | 「完成」「异常」「高风险」在各部门的定义 | 同一指标在不同报表里不一致 |
| 经验封装 | 哪些做法值得沉淀为可复用 Skill | 单点跑通但换团队就要重做 |
这也给「先买平台还是先理流程」提供了一个可操作的判据：若上述五类规则里有两类以上尚无书面定义，先补规则比先比模型更划算。本站 R-INDUSTRY-59 记录的政企三道断层里，业务语义与责任运维两道同样属于这类前置工作，只是约束更强。
三条红线与一处反向优化
把这三份材料用于内部立项参考时，建议至少守住三条红线。
| 红线 | 本轮对应的风险 | 处理方式 |
|---|---|---|
| 匿名样本不可外推 | 国内三档企业未具名，文章含代理商推广内容 | 只取其方法学（小切口、四道关、三个坐标），读数不作行业基准 |
| 单一来源需交叉 | 两个海外案例各只有一篇报道，未见客户侧或厂商侧二次确认 | 立项前索取原始时长、单量、投入与复核数据 |
| 不同分母不合并 | 现金流、周转、工时、token 四类读数并存 | 按四列模板分别记账，附基线与统计期 |
CJ Logistics 材料里有个容易被略过的细节：定价按 token 消耗，而入站呼叫比出站 ping 需要更深的上下文分析、消耗更多 token。若把「降 token」设成单一优化目标，系统可能倾向于减少必要的深度跟单，短期账单变好、状态数据质量反而下降。合理的做法是把「状态数据完整率」「异常原因码准确率」与 token 一起纳入约束，让成本优化发生在调用结构（如批次、缓存、不必要的重复询问）上，而不是削减必要动作。国内样本里 Token 降 10% 来自任务轨迹「体检」，正是这一思路的正面例子。
未披露项与后续跟进
- 基线缺失：Worldwide Express 未给原始应收账款时长、单量、投入金额、错误率与人工接管比例；CJ Logistics 未给跟单成功率、承运商合规率变化与每票成本的具体数值。
- 归因未拆：国内样本的净利增幅、每月节省金额未说明是否扣除平台、算力与 FDE 投入，也未拆分智能体贡献与其他管理动作的贡献。
- 口径未披露：结算「3 天到 1 小时」按自然日还是工作日计、报关与亏损排查的分项耗时、130 万次对话对应的任务完成数，公开材料均未说明。
- 来源属性：两个海外案例为单一媒体报道，国内样本出自厂商内容文章且文末含推广信息；三份材料都未提供第三方审计或客户侧独立复核。
- 换算限制：本文的 55.6 万美元每天、3.03 倍、10.75% 班次、0.96 亿元每年、51.0% 相对降幅、178.6 席位每部门，均为带假设的现象级换算，不是企业披露的实测值。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是 Worldwide Express 的部署周期与投入、CJ Logistics 六个月开发的分阶段读数，以及国内三档企业的具名与复核数据。