MongoDB 如何用受控工具构建智能体仓储管理系统：决策与执行

这是 MongoDB 博客“构建智能体仓储管理系统”系列的最后一部分，承接前两篇已完成的智能体定义、触发与规划阶段，聚焦执行计划中剩余的执行、决策与完成环节。作者使用 Java 与 Spring AI 实现，AgentRunner 逐个读取任务描述与能力标签，执行后保存结果，并把已完成任务的结果作为后续任务的上下文。 工具调用被严格限制在任务能力范围内：执行器只拿到当前目标、前序任务结果、当前任务以及该能力对应的工具。例如 ANALYSIS 任务可以查询 WMS 中的库存、发票流水、库存移动和待处理补货单，但没有创建补货请求的工具，边界由应用侧定义。 补货政策通过独立的 POLICY 能力工具获取。每个货主可在 Depositor Policies 页面登记自然语言业务规则，例如 7 天提前期或单次补货至少 500 单位。政策文本入库时用配置的 Voyage AI 嵌入模型转为向量写入向量存储，检索时按货主与知识类型过滤，形成一条 RAG 流程，把最相关政策注入执行上下文。 DECISION 任务结合分析结果与政策上下文判断是否需要补货，输出以两种 token 之一结尾，AgentRunner 据此决定是否继续。若无需补货，REPLENISHMENT 与 NOTIFICATION 任务被标记为 SKIPPED 并结束执行；若需要补货，则由受控工具创建补货请求，校验与持久化仍留在应用服务中，随后通知任务用补货 ID 生成货主邮件草稿。全部任务完成后生成摘要，补货请求可在 Replenishments 页面复核。 作者在展望中提到，当前智能体只在单次执行内复用前序任务结果，下一步可引入跨执行记忆，例如参考历史 AgentRun 中相似情形的审批结果来调整补货数量。系列的核心主张是：应用定义智能体被允许做什么，智能体在这些边界内决定怎么做。