[Amazon Bedrock] Worldwide Express 如何通过 Amazon Bedrock 自动处理货运异常

Worldwide Express 如何通过 Amazon Bedrock 自动处理货运异常

Worldwide Express（ShipStation Global 旗下公司）做成了很大的一件事：全系统约 50 亿美元营收、75 家以上的零担（LTL）承运商、超过 13 万家客户。但同样的规模也有一笔隐藏的成本。每个月，1,500 万美元的自由现金流被冻住，锁在那些还没被处理掉的账单异常里。每一笔都得靠人一家承运商一家一家地追，各家都有自己的规则要核对。Worldwide Express 把它外包给一个团队，一次只处理一个案子，每一起争议都要给客户和承运商打电话。异常越堆越多，现金一直卡着，而每一张订单变成钱都要花更长时间。

Worldwide Express 与 AWS 和 LTM 合作，基于 Amazon Bedrock 构建了一套 multi-agentic AI 方案，直接插进他们的运输管理系统（TMS）SpeedShip。上线六个月后，公司报告在办异常减少 75%、回款周期缩短 4 周、每年节省 100 万美元，以及一次性 1,000 万美元的自由现金流注入。

在这篇文章里，我们会说明这项挑战、解释 Worldwide Express 如何设计这套多 agent 方案，并分享结果。

挑战

在 LTL 货运里，大约 14% 的发票过不了采购订单、收货单与承运商发票之间的标准三单匹配。一旦匹配失败，发票就进入异常处理环节。对 Worldwide Express 来说，异常分成三类：

行项目不匹配： 数量或服务代码与运单记录对不上。 价格差异： 承运商开具的费率与合同价格不一致。 意外的附加费： 尾板费、住宅地址附加费或重新称重调整，而这些在原始报价里并没有。

每一笔异常都会触发一个五步的手工流程：

把发票与采购订单、收货单和价格交叉比对，识别异常类型。 在供应商记录里追查根因。 带着争议细节给承运商或仓库发邮件。 等待回复。 在 TMS 里执行处理结果。

每家承运商都按自己的费率结构和争议工作流运作，这套流程吃掉了 FinOps 团队的大部分带宽。

基于规则的流程自动化（RPA）能应付结构化、可预测的工作流。但异常解决需要情境判断：解读承运商的附加费政策、把收费与运单数据相互比对，并结合承运商、异常类型和金额来判定这笔费用是否成立。正是这种多变性，让这个问题适合用 agentic AI 框架来解。

从评估到生产

2025 年 6 月，Worldwide Express 引入了 AWS 的 Business Transformation & Value Advisory 团队，在 Order-to-Cash（订单到回款）生命周期上识别出 19 个自动化机会。清楚异常自动化的业务价值之后，Worldwide Express 用了不到 6 个月就从评估走到了生产。

工作原理

这套方案运行在 AWS 上。Amazon Bedrock 提供 AI 推理，Amazon Elastic Compute Cloud（Amazon EC2） 是引擎。设计上要求对以下事情有细粒度控制：每个 agent 如何推理、决策边界设在哪里，以及异常如何在 agent 之间路由。把框架直接构建在 Amazon EC2 上、由 Amazon Bedrock 提供推理，让这套编排逻辑始终握在团队自己手里，同时也支持开源 agent 库。业务逻辑层面的生产管控让每个 agent 的角色、输入和决策边界都明确且可审计。在账单争议的工作流里，每一个自动化决策都必须可解释。

Agents

检测到一个发票异常时，系统会把它路由到三个专门 AI agent 中的一个，每个 agent 处理一类具体的账单争议：

Invoice Matching Agent 找到匹配的运单记录，并把对不上的地方标出来。 Pricing Variance Agent 把承运商的收费与合同费率比对，判定差额是否成立。 Accessorial Validation Agent 核查那些意料之外的费用（比如住宅配送或尾板收费）是否确有实际派送事件支撑。

每个 agent 在给出建议之前，会先拉取具体承运商的计费规则和政策。异常处理完之后，系统会生成一段平实语言的说明，讲清查到了什么、采取了什么动作。

每个自定义 agent 都有一份 instruction prompt（定义它的角色、决策边界和输出格式）、一组 action（接入 SpeedShip 的集成），以及对承运商专属知识库的访问权限。借助 Amazon Bedrock，每个 agent 通过一个 API 访问合适的 foundation model，同时沿用已有的 AWS 治理。关于各 Region 的模型可用性，请见 Amazon Bedrock 中按 AWS Region 支持的模型。

Actions

这些 agent 通过分析师本来就在用的同一批 API 连接 SpeedShip。也就是说，AI 看到的正是一个人类审核者会看到的东西（合同费率、运单细节、派送凭证），而它写回的也是同一个工作流。SpeedShip 的 API 就在 AWS 上，所以这些 agent 接进去的 endpoint 与其他既有系统相同。

承运商知识库

每家承运商都有不同的计费规则、费用定义和争议流程。Worldwide Express 存下了每家承运商的文档：费率规则、附加费定义、争议步骤和差异阈值。当一个 agent 处理异常时，它会先检索那家承运商自己的政策与标准作业流程（SOP）文档再做决定，因此每个决策都立足在承运商自己的规则上。处理所有承运商的始终是这三个 agent，不需要任何按承运商单独写的代码。

人在环中

在初期上线阶段，审批这一步是 FinOps 采纳这套方案的必要条件。一开始，由人类审核者用现有的 SpeedShip UI 批准建议，之后建议才正式生效。等到准确率超过 99%，批量审批就成了默认做法。

可观测性

Worldwide Express 的团队搭建了看板，跟踪按承运商计的自动化率、按异常类型计的错误率、解决时长和人工覆写频率。当一位审核者驳回一条建议，系统会把这条反馈记录下来。团队依据驳回历史打磨 instruction prompt 和知识库，稳步提高自动化覆盖范围。

端到端流程

下图展示了从异常检测、经过三个专门 agent、一直到人工审批的端到端流程。在图里，来自各个数据源（SpeedShip TMS、一套运输系统、一个电子数据交换（EDI）服务器，以及承运商和供应商门户）的异常被检测出来并路由到三个 agent 之一。每个 agent 都运行在带 Auto Scaling 的 Amazon EC2 上，使用一套自带 prompt、工具和承运商知识库的 agent 框架，并调用 Amazon Bedrock 做模型推理。agent 产出一份处理报告。随后成本确认与一段由 AI 撰写的说明会交给人类审核者，在 SpeedShip 分析师 UI 里审批。

图 1：Worldwide Express 在 AWS 上的 AI 驱动异常处理架构

结果

六个月下来，Worldwide Express 已把这套方案部署到 40 多家 LTL 承运商。这些 agent 目前每周办结 10,000 笔（约 50%）异常，错误率低于 1%。这让 FinOps 团队的时间从例行处理转向复杂、高价值的争议。

影响最明显的地方是在办异常的积压量，它从 2025 年 6 月的 1,500 万美元降到六个月后的 400 万美元，减少 75%。Worldwide Express 盘活了 1,000 万美元被占用的现金，年度成本节省超过 100 万美元，首年 ROI 达 60 倍。公司报告回款周期改善了四周。

“借助 AWS，我们把每周 40% 以上的账单异常自动化了，显著降低成本，并把账单周期从天缩短到分钟。如今我们每周多释放约 1,000 万美元的客户账单，速度快到以前根本做不到。” — Nathanael Pearson，Worldwide Express 的 FinOps 副总裁

往前看

Worldwide Express 已经在把这套做法扩展到 Order-to-Cash 周期的其他环节。对管理着大量承运商的物流公司来说，向前的路径是先从小处做起：先把最重复的那类异常自动化，证明准确率，然后铺开到其余的业务组合。

结论

Worldwide Express 的异常自动化展示了当 agentic AI 遇到一个界定清晰的业务问题时可以做到什么。Amazon Bedrock、承运商专属知识库，加上人在环中的审批设计，这几者的组合让 Worldwide Express 在不到 6 个月里从评估走到生产，同时守住了财务管控。公司现在正把自动化推广到其他 Order-to-Cash 流程。

想探讨类似做法是否适用于你的组织，请向你的客户团队发起一次沟通，或进一步了解 Amazon Bedrock。像 LTM 这样的 Partner 可以用你自己的数据跑一轮价值验证（Proof of Value）冲刺。

关于作者