让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践

确定性计算场景下的 AI 角色边界

生鲜补货业务中，库存计算属于典型的确定性计算。团队在项目落地时明确，当业务逻辑是确定性计算时，AI 不该直接参与计算，而是把重点放在调度环节。

AI 负责判断补货时机、选择补货品类和触发对应流程，但具体库存数字、补货数量这些精确运算全部交给现有业务系统完成。这种划分避免了 AI 在确定性场景中可能出现的幻觉或不稳定输出。

项目实践显示，AI 在调度层面的表现稳定，能根据实时销售趋势、促销活动等信号灵活调整补货节奏。相反，如果让 AI 直接输出库存计算结果，容易出现与实际业务规则不符的情况。

这种角色边界不是随意设定，而是基于生鲜商品高时效性、高损耗的特点。生鲜补货决策需要同时考虑保质期、损耗率、门店实时销量等多维确定性数据，这些数据处理逻辑已经在业务系统中经过长期验证。

LangGraph 编排在补货流程中的定位

让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践：LangGraph 编排在补货流程中的定位

LangGraph 在整个项目中承担编排职责。它把多个 AI 代理和业务工具组织成一个可控的流程图，确保补货决策按照预设路径推进。

在生鲜补货场景下，LangGraph 负责协调不同代理之间的调用顺序。当销售数据出现异常波动时，LangGraph 先触发趋势分析代理，再根据分析结果决定是否唤起补货建议代理。

这种编排方式让整个流程具备可追溯性。每个决策节点的状态都被 LangGraph 记录下来，方便后续排查问题或优化路径。

项目中 LangGraph 没有直接处理任何库存数字，它只负责把正确的代理和工具在正确的时间点串联起来。生鲜补货流程涉及多个环节，从数据读取到决策生成再到执行确认，LangGraph 把这些环节组织成状态机，避免代理之间出现调用混乱。

通过 LangGraph 的图状结构，团队能够可视化整个补货决策路径，这对理解复杂业务流程帮助很大。

MCP 工具化代理的实现机制

让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践：MCP 工具化代理的实现机制

MCP 工具化代理是连接 AI 调度层和业务计算层的关键。代理被包装成工具形式，供 LangGraph 调用，但代理本身不执行库存计算。

每个 MCP 代理专注于特定任务，比如读取销售趋势、识别促销信号或生成补货请求。这些代理把输入参数传递给后端的业务系统，由业务系统完成实际计算后再把结果返回给代理。

实现上，MCP 代理采用工具化封装方式。LangGraph 通过标准接口调用这些代理，代理再把请求转发到业务计算模块。这种机制确保 AI 代理只做信息收集和调度决策，不触碰核心计算逻辑。

在生鲜补货实践中，MCP 代理会把当前门店的促销信息、历史销量数据打包发送给业务系统。业务系统根据内置规则计算出建议补货量，然后代理把这个结果包装成下一步调度的输入。

这种工具化设计让代理变得可插拔。团队可以根据业务变化快速调整代理功能，而不需要改动底层计算逻辑。

三层架构的整体分层设计

让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践：三层架构的整体分层设计

项目采用三层架构设计，最上层是 LangGraph 编排层，中间是 MCP 工具化代理层，最下层是业务计算层。三层各司其职，避免功能重叠。

LangGraph 层专注于流程控制和状态管理。它决定什么时间调用哪个代理，以及如何根据返回结果选择下一条路径。

MCP 工具化代理层负责翻译和传递。代理把 LangGraph 的调度指令转换成业务系统能理解的请求格式，同时把业务系统的计算结果转换成 LangGraph 能继续编排的信号。

业务计算层则完全保留原有确定性逻辑。所有库存计算、补货量计算、损耗预测等都由这层完成，这些逻辑经过多年业务打磨，已经高度可靠。

三层架构确保信息流向清晰：调度指令从上往下传递，计算结果从下往上反馈。任何一层出现问题都可以独立排查，不会影响其他层。这种设计在生鲜补货项目中有效降低了系统复杂度和维护成本。

AI 调度与业务计算的边界案例

让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践：AI 调度与业务计算的边界案例

在实际补货场景中，边界划分非常具体。当系统检测到某生鲜品类销量突然上升时，AI 代理负责判断这是短期促销还是趋势变化，并据此决定是否启动补货流程。

但具体补多少货、从哪个仓库调拨、预计损耗多少，这些全部由业务计算层完成。AI 只接收计算结果，然后决定是否把补货单推送给门店经理确认。

另一个案例是促销期间的补货决策。AI 代理会识别促销活动信号，并调度对应的代理去收集历史促销数据。但促销期间的库存安全阈值计算仍然由业务系统根据固定公式完成。

项目中还出现过边界模糊的情况，比如 AI 试图直接建议具体补货数量。团队及时调整了提示词和工具接口，强制代理只能输出调度指令，不能输出计算数值。

这些案例表明，清晰的边界定义不是一次就能完成，而是需要在落地过程中不断调试。生鲜业务的高频特性让团队能快速验证边界是否合理。

落地实践中的关键决策点

让 AI 补货，但不让它算库存——LangGraph 在生鲜补货的落地实践：落地实践中的关键决策点

生鲜补货项目的落地过程中，团队面临几个关键决策。首先是是否让 AI 直接接触库存数据库。最终决定是完全隔离，AI 通过 MCP 代理间接获取摘要信息，而不是直接读取原始库存。

第二个决策是 LangGraph 的状态持久化方式。团队选择把每个补货流程的状态记录下来，以便后续审计和优化。这对生鲜这种需要追溯责任的业务特别重要。

第三个决策点是如何处理 AI 调度中的不确定性。生鲜补货虽然核心计算是确定的，但外部因素如天气、节日会带来不确定性。LangGraph 被用来捕捉这些不确定信号，并交给业务规则去转换计算。

项目还特别注意了异常处理机制。当业务计算层返回异常结果时，LangGraph 会触发备用代理路径，而不是让 AI 自行猜测解决方案。

通过这些决策，生鲜智能补货系统在实际门店中逐步上线。团队观察到补货准确率提升，同时因为边界清晰，系统维护难度显著降低。

整个落地过程表明，当业务逻辑是确定性计算时，把 AI 限制在调度层面，反而能更好地发挥其优势，同时保持业务系统的稳定性和可解释性。

相关阅读