我的职业生涯中有一大部分时间是在银行业和物流业度过的。在物流领域，我花了超过八年时间，参与物流系统的不同阶段，从开发、实施到生产支持。

这段经历深刻影响了我看待技术的方式。了解某个工具或框架固然重要，但我最关心的，是理解它背后的业务问题，以及技术究竟能在哪里真正创造价值。

几周前，我以演讲者身份回到了我曾工作多年的公司。回到那里让我想起许多日常物流运营中的挑战，也让我思考，如果今天来面对这些问题，我会如何处理。

这就是 Agentic Warehouse Management System（智能体驱动的仓储管理系统） 的由来。

对于这个项目，我并不打算构建一套完整的 WMS。相反，我想借用一个自己非常熟悉的物流场景，来探索 AI 智能体如何成为真实业务流程的一部分，以及它能在哪些环节创造价值。

在第一部分中，我们将介绍 WMS 场景，并找出 AI 智能体可以在哪里提供帮助。在 第二部分 中，我们会使用 Java 和 Spring AI 来定义并接入该智能体。最后，在 第三部分 中，我们将执行计划、收集上下文、做出补货决策，并在必要时采取行动。

试用应用

智能体驱动 WMS 的在线版本可在此访问。

你可以从概览页面（Overview）开始，它会带你了解主要的 WMS 流程，并演示如何与应用程序交互。该应用基于以下技术构建：

• Java 与 Spring Boot
• Spring AI，用于智能体与工具集成
• OpenAI，用于语言模型
• Voyage AI，用于向量嵌入
• MongoDB，用于运营数据、智能体运行记录和向量搜索

完整源代码可在此查看。

仓储管理系统

WMS（Warehouse Management System，仓储管理系统）是一种用于管理和控制仓库内商品流动的软件系统。它通常处理收货、库存跟踪、商品发运、补货等流程。仓库可以存放运营公司自己的商品，也可以存放其他公司的商品。在本文中，我们将这些公司称为 货主（depositors）：

[LOADING...]

货主拥有存放在仓库中的商品，仓库则负责接收、存储、管理和发运这些商品。一个仓库可以同时为多个货主服务。例如，Amazon、Nike 或 Walmart 的商品都可以存放在同一个仓库中并进行管理，而每个货主的库存仍然彼此隔离。真实的 WMS 可能支持更多流程，但在本应用中，我们只关注这一流程中较小的一部分：

[LOADING...]

**入库（Inbound）**操作代表商品进入仓库，并会增加某货主的可用库存。**出库（Outbound）**操作代表商品离开仓库，并会减少该库存。

此外，我们还会加入一个简单的补货请求（Replenishment Request）流程。当需要补充更多商品时，仓库可以创建一个请求，指明需要补货的商品及数量。之后，货主就可以安排一批新商品入库。补货请求创建后，系统还会准备一份货主邮件草稿（Depositor Email Draft），用于通知货主。

对 WMS 流程建模

在上述流程中，传统实现通常会涉及几个基础实体，例如入库单、出库单、库存和补货请求，以及商品和货主。**入库（Inbound）**操作代表货主拥有的商品进入仓库。例如：

// INBOUND COLLECTION
{ 
     number: 'NF-IN-01',
     depositor: { _id: ObjectId('6a88aaa60aab66cebc2c4e62'), name: 'Amazon' },
     items: [ { productCode: 'BR01', quantity: 1500 } ],
     status: 'COMPLETED' 
}

一旦操作完成，这些数量会被加入库存（Inventory）：

// INVENTORY COLLECTION
{ 
productCode: 'BR01', 
depositor: { _id: ObjectId('6a88aaa60aab66cebc2c4e62'), name: 'Amazon' }, quantity: 1500 
}

**出库（Outbound）**操作则方向相反。商品离开仓库，库存数量相应减少：

// OUTBOUND COLLECTION
{
number: 'NF-OUT-01',
depositor: { _id: ObjectId('6a88aaa60aab66cebc2c4e62'), name: 'Amazon' },        items: [ { productCode: 'BR01', quantity: 1480 } ],
status: 'COMPLETED'
 }

该操作完成后，属于货主 Amazon 的 BR01 库存将只剩下 20 件。此时，可能就会需要创建补货请求（Replenishment Request）。从业务角度来说，仓库实际上是在说：

“Amazon，您的 BR01 只剩 20 件了。您能否在我们断货之前，再安排一次新的入库？”

在我们的 WMS 中，这个请求可以用类似下面的文档表示：

// REPLENISHMENT COLLECTION

{
depositor: { _id: ObjectId('6a88aaa60aab66cebc2c4e62'), name: 'Amazon' }, items: [ { productCode: 'BR01', quantity: 1500 } ],
message: 'Replenishment is required for product BR01 due to low stock.', status: 'PENDING'
}

决定何时补货

创建补货请求本身并不复杂。更有趣的问题是：什么时候应该创建它？我们来看 BR01 的以下库存变动：

8 月 18 日，Amazon 将 1,500 件商品送到仓库。之后几天，仓库每天处理 300 件出库。

[LOADING...]

每次出库后，可用库存会变为：

1,500 → 1,200 → 900 → 600 → 300 → 0

如果消耗模式持续下去，仓库将在第五次出库操作时完全耗尽 BR01。

自动化该流程的常见方式是定义最低库存阈值。例如，只要可用库存少于 500 件，就可以创建补货请求：

if (inventory.getQuantity() < 500) {

replenishmentService.create(productCode, quantity, depositor);

}

这是一个完全合理的规则。一旦库存降到 300 件，WMS 就会检测到库存低于阈值（500），并请求更多商品。

但请考虑：货主平均需要 7 天才能把新商品送到仓库。如果我们等到库存低于 500 件才发起请求，可能就太晚了——在新一批货到达之前，BR01 就可能已经耗尽。

我们可以把剩余库存天数也加入判断：

int daysOfStock = inventory.getQuantity() / dailyConsumption;

if (inventory.getQuantity() < 500

        || daysOfStock < depositor.getLeadTimeDays()) {

    replenishmentService.create(productCode, quantity, depositor);

}

现在，WMS 既能对低库存做出反应，也能在剩余库存不足以覆盖货主到货周期时，提前安排补货。

这些都是确定性规则。当决策可以通过已知条件和计算清晰表达时，它们会运行得很好。但随着业务发展，新的规则和例外会不断出现。

到了某个阶段，挑战就不再只是多增加一个条件。

当决策需要上下文

当决定“该做什么”需要的不仅仅是对预设条件进行判断时，问题就变得更有趣了。我们回到同样的例子。

Amazon 发来 1,500 件 BR01，仓库每天发货 300 件。三天后，只剩 600 件。

使用我们之前创建的规则，计算非常简单：

• 当前库存：600 件
• 近期消耗：每天 300 件
• 库存可用天数：2 天
• Amazon 到货周期：7 天

由于两天的库存不足以覆盖七天的到货周期，我们的代码就会创建补货请求。

但请考虑两种不同的情况：

1. 场景 A： 近期每天 300 件的消耗属于 BR01 的正常需求范围，没有迹象表明它会放缓。在这种情况下，创建补货请求是合理的。
2. 场景 B： 相同的每天 300 件出库，其实来自一场已经结束的短期促销。更早的库存变动显示，BR01 通常每天只消耗约 50 件。在这种情况下，立即按同样数量补货可能并不必要。

我们的确定性规则在两种情况下看到的数值完全相同：库存 600 件、近期日消耗 300 件、到货周期 7 天，所以它会返回同样的结果。

但两种情形并不相同。

要做出更好的决策，系统需要更多上下文。它可能需要查看之前的库存变动记录，判断近期消耗是否代表该商品的正常行为，检索相关的货主策略，然后再决定是否真的需要采取行动。

这正是 AI 智能体开始创造价值的地方。

智能体不会取代库存计算、校验、持久化或创建补货请求这类确定性操作。这些操作仍然是常规应用逻辑。

相反，智能体可以使用受控工具，去观察固定规则所用数值之外的更多信息。它可以查看之前的库存变动、检查待处理的补货请求、获取货主策略，并收集有助于解释当前情况的其他信息。

问题不再仅仅是：

“库存是否低于 500 件？或者剩余库存天数是否不足以覆盖货主的到货周期？”

它变成了：

“当前情况究竟意味着什么？我们现在需要行动吗？”

这就是智能体在我们 WMS 中的角色：收集相关信息，理解当前状况，判断补货是否必要，并决定接下来应该发生什么，同时把定义明确的业务操作留在确定性代码中。

智能体应该放在哪里？

在我们的应用中，智能体在一次出库操作成功完成后进入流程。此时，库存已经更新，智能体会收到一个目标：

判断这次出库操作是否产生了补货需求。

在查看流程之前，有必要先明确我们所说的 AI 智能体是什么意思。

简单来说，AI 智能体会接收目标，遵循一组指令，通过工具与应用程序交互，观察所检索到的信息，并决定下一步做什么。

在我们的 WMS 中，这些要素都有明确职责：

1. 目标： 定义智能体需要完成什么。在本例中，就是判断已完成的出库操作是否产生了补货需求。
2. 指令： 定义智能体应该如何表现、需要考虑什么，以及必须遵守的边界。
3. 工具： 提供对 WMS 的受控访问。智能体可以用它们检查库存和库存变动、获取货主策略、检查待处理的补货请求，或者执行创建补货请求等操作。

关键之处在于：智能体并不会取代现有的 WMS 服务，也不会接管整个应用。入库处理、出库处理、库存更新、校验和持久化仍然由普通 Java 代码负责。

相反，智能体更像是协调者，它会根据目标和所收集到的上下文，决定使用哪些可用工具。

下图展示了智能体如何成为 WMS 流程的一部分：

[LOADING...]

这张图看起来像一系列步骤，但它并不是传统的硬编码工作流——并不是由应用预先定义每一个决策。

应用定义的是智能体的配置、指令、边界和可用工具。在这些边界内，智能体自行判断需要哪些信息，把收集到的结果作为上下文，决定是否采取行动，并判断接下来应该发生什么。

对于某次出库操作，智能体可能得出结论：需要补货，于是创建请求。对于另一次出库，它分析完可用上下文后，可能判断无需任何行动。

这是一个重要区别：WMS 控制智能体被允许做什么，而智能体负责在这些边界内决定该做什么。

当出库单据完成时，OUTBOUND_INVOICE_COMPLETED 事件会触发智能体。此后，工作流可以概括为四个步骤：

1. 计划（Plan）： 根据目标、指令和可用能力，智能体判断可能需要哪些信息和操作。
2. 分析（Analyze）： 智能体使用只读工具检查库存、库存变动、待处理补货请求和货主策略等信息。
3. 决策（Decide）： 根据收集到的信息，智能体判断补货是否确实必要。
4. 行动（Act）： 如果需要行动，智能体可以使用受控工具创建补货请求，并准备货主通知。如果无需行动，工作流直接结束，不改变任何内容。

结语

在第一部分中，我们重点讨论了 AI 智能体可以在仓储管理系统的哪些环节创造价值，同时，同样重要的是，它也明确了哪些地方不应替代确定性应用逻辑。

在第二部分中，我们将把这个设计落地为 Java 与 Spring AI，包括定义智能体、将其接入 WMS 工作流，以及创建执行计划。

接着，在第三部分中，我们将看到智能体如何通过受控工具执行这些任务、收集必要上下文、做出补货决策，并在需要时采取行动。

完整源代码可在此查看。

本文（Building an Agentic Warehouse Management System — Part 1: Where AI Agents Add Value）最初发布在 foojay 上。