构建代理式仓库管理系统——第三部分：工具、决策与行动
内容提要
本文是AI代理系列第三部分，介绍如何用Java和Spring AI实现仓库补货代理流程：代理按计划逐项执行任务，通过受控工具获取库存、发票等运营数据，并用RAG语义检索获取寄存方补货政策；随后依据上下文判断是否需要补货，若需要则创建补货请求并生成通知邮件草稿，否则跳过后续任务。核心原则是应用界定代理权限，代理在边界内自主决策。
延伸解读
能力边界如何约束代理行为
文章强调，每个任务被赋予特定能力，而能力决定了代理可用的工具集。例如，ANALYSIS任务只能查询库存、发票等运营数据，无法调用创建补货请求的工具。这种设计将代理的自主决策限制在应用预设的边界内，既保留了灵活性，又避免了越权操作。读者可从中理解：代理的“自由”来自工具组合的精细划分，而非无限制的模型调用。
RAG在业务规则检索中的实际作用
寄存方政策以自然语言文档存储，代理通过语义检索而非关键词匹配来获取相关规则。检索时按寄存方和知识类型过滤，只返回补货、入库或通用类政策。这使代理能结合当前上下文提出具体问题，如某产品的最低补货量，并将检索结果融入后续决策。该流程展示了RAG如何将非结构化业务规则转化为可操作的上下文，减少对硬编码规则的依赖。
决策令牌与任务跳过机制
DECISION任务的结果以REPLENISHMENT_REQUIRED或REPLENISHMENT_NOT_REQUIRED结尾，AgentRunner据此判断是否继续执行后续任务。若无需补货，剩余任务被标记为SKIPPED并直接完成运行。这种简单令牌机制让流程控制清晰可测，同时保留了代理在边界内自主判断的空间。读者应注意：决策结果的可解析性依赖于模型输出格式的稳定性，实际应用中需考虑异常处理。
工具不替代业务逻辑的架构原则
创建补货请求和生成邮件草稿的工具均不包含核心业务逻辑：验证与持久化仍由应用服务完成，工具仅提供受控的调用入口。邮件工具只生成草稿而不发送，进一步限制代理的副作用。这体现了文章的核心原则——应用界定代理权限，代理在边界内行动。这种分离有助于审计、测试和权限管理，也提醒开发者在集成AI代理时避免将关键业务规则下沉到工具层。
Q&A
在仓库补货代理中，代理如何执行计划中的任务？
AgentRunner 按顺序逐个处理任务：读取每个任务的描述和能力，执行任务，存储结果，然后继续下一个任务。执行时只使用与该任务能力关联的工具，并将之前任务的结果作为上下文传入。
代理如何获取库存、发票等运营数据？
在 ANALYSIS 任务中，代理通过受控工具从 WMS 获取运营数据，例如库存、发票移动、库存移动和待处理补货。这些工具使用 Spring AI 的 @Tool 和 @ToolParam 注解暴露给模型，代理在需要时调用。
寄存方补货政策是如何被代理检索和使用的？
寄存方政策以自然语言文档存储，通过 Voyage AI 嵌入模型转换为向量并存入向量库。在 POLICY 任务中，代理基于已收集的上下文提出问题，使用语义搜索（RAG）检索最相关的政策，并按寄存方和知识类型过滤，然后将结果加入执行上下文。
代理如何决定是否需要补货？
在 DECISION 任务中，代理利用 ANALYSIS 和 POLICY 任务收集的上下文判断是否需要补货，结果以 REPLENISHMENT_REQUIRED 或 REPLENISHMENT_NOT_REQUIRED 标记结尾。AgentRunner 根据该标记决定是否继续执行后续任务。
如果需要补货，代理会执行哪些操作？
代理使用 REPLENISHMENT 任务的动作工具创建补货请求，然后使用 NOTIFICATION 任务工具生成寄存方邮件草稿（不发送邮件）。工具仅提供受控的操作方式，验证和持久化仍由应用服务处理。
如果不需要补货，代理会如何处理剩余任务？
如果 DECISION 任务返回 REPLENISHMENT_NOT_REQUIRED，AgentRunner 会将剩余的 REPLENISHMENT 和 NOTIFICATION 任务标记为 SKIPPED，并完成本次执行。
这个代理设计如何确保代理在允许的边界内行动？
应用通过为每个任务分配能力来界定代理权限，每个能力只关联特定的工具。例如，ANALYSIS 任务只能访问 WMS 信息工具，不能访问创建补货请求的工具。代理在应用定义的边界内自主决策。
