AI客服集成WMS：双模型架构在仓库管理中的落地实践

1. 项目概述：当AI客服遇上仓库管理

最近我们团队完成了一个挺有意思的项目，把AI客服能力直接集成到了我们的仓库管理系统里。这事儿听起来可能有点跨界，但背后的逻辑其实很直接：仓库每天要处理大量的内部和外部咨询，从“我的货到哪儿了”到“这个SKU的库存还有多少”，再到“这批入库单的质检标准是什么”。过去，这些咨询要么靠人工在系统里查，要么就是写一堆固定的FAQ，效率低不说，还容易出错。

我们用的不是单一模型，而是结合了Claude和Gemini。选择双模型架构，主要是考虑到它们在不同类型任务上的互补性。Claude在理解复杂、多轮次的对话意图和生成符合业务逻辑的、结构化的回复方面表现更稳定；而Gemini在处理实时数据查询、代码生成以及与现有API快速对接上，速度更快，灵活性更高。我们的目标不是做一个炫技的Demo，而是打造一个真正能7x24小时工作、减轻一线员工负担、提升响应速度的“AI仓库协管员”。

这个项目适合所有正在使用或计划升级WMS的团队负责人、技术主管以及对AI落地业务场景感兴趣的开发者。它不要求你从头训练一个大模型，而是聚焦于如何利用现有的、成熟的AI API，以相对可控的成本和复杂度，解决实际的业务痛点。接下来，我会详细拆解我们是怎么想的，怎么做的，以及过程中踩过的那些坑。

2. 核心架构设计与选型思考

2.1 为什么是“AI客服”+“WMS”？

传统的WMS核心是流程和数据的精准控制，比如收货、上架、拣货、打包、发货。它的交互对象主要是仓库操作员和系统本身。但随着业务发展，来自销售、客服、供应商甚至最终客户的查询请求越来越多，这些请求直接涌入仓库管理员的IM工具、邮箱甚至电话，形成了巨大的“查询噪音”。

我们算过一笔账，一个中等规模的仓库，管理员每天要花至少3个小时处理各种重复性查询。这些查询中，超过60%是可以通过查询系统现有数据直接回答的，比如库存查询、订单状态、物流轨迹。剩下的30%涉及简单的业务流程解释，只有不到10%才真正需要人工介入判断。AI客服的集成，目标就是吃掉那90%的标准化、重复性查询，让人工去处理更复杂的异常和决策。

这不仅仅是“降本增效”，更是体验升级。对于内部同事（如客服专员），他们能瞬间获得准确的仓库数据，无需切换多个系统或等待回复；对于外部合作伙伴，一个自动化的查询接口也能提升协作效率。

2.2 双模型架构：Claude与Gemini的角色分工

直接用一个模型行不行？理论上可以，但我们经过POC测试后发现，单一模型在应对我们复杂的场景时，要么成本过高，要么效果有短板。因此，我们设计了如下分工：

Claude 扮演“对话指挥官”与“复杂任务处理器”

• 核心职责：意图识别、多轮对话管理、生成最终面向用户的自然语言回复。
• 选型理由：Claude在长上下文理解和遵循复杂指令方面表现出色。当用户问“帮我查一下上周从A供应商来的那批货，现在还有多少没上架？顺便看看这批货的质检报告有没有问题”时，Claude能很好地拆解这个复合问题，理解“上周”、“A供应商”、“未上架库存”、“质检报告”等多个实体和关系，并组织起结构化的查询逻辑。它的回复也更像“人话”，更自然、体贴。
• 工作流位置：位于交互最前端，直接处理用户输入的原始问题。

Gemini 扮演“数据查询引擎”与“快速执行器”

• 核心职责：根据Claude分解出的结构化指令，生成精确的数据查询语句（如SQL、GraphQL）或调用特定的WMS API，并快速处理返回的数据。
• 选型理由：Gemini在代码生成和函数调用方面的响应速度极快，且对于从自然语言到结构化查询的转换非常精准。它擅长“快、准、狠”地完成数据抓取任务。我们将WMS的核心数据模型和API文档作为上下文提供给Gemini，它就能像一位熟练的开发人员一样，写出可执行的查询。
• 工作流位置：位于Claude之后，接收结构化指令，执行并返回原始数据。

简单来说，流程是这样的：用户提问 -> Claude理解并规划行动 -> Claude向Gemini发出“执行指令” -> Gemini查询数据或执行操作 -> 原始数据返回给Claude -> Claude将数据整合成友好回复给用户。这个链条清晰，责任分明。

2.3 技术栈与基础设施考量

除了AI模型，整个系统的稳定运行离不开稳健的基础设施。

• 后端框架：我们选择了Python的FastAPI。原因很简单：异步支持好（应对AI API调用等待），自动生成API文档（方便内部集成），性能足够。相比Django，它更轻量，更适合这种以API服务为核心的项目。
• 对话状态管理：这是关键。每个会话都需要一个唯一的session_id，用来存储多轮对话的历史。我们用了Redis来存储这些会话状态，因为读写速度快，而且可以设置自动过期，方便清理无效会话。存储的内容不仅仅是对话历史，还包括Claude分析出的用户意图、已查询过的实体（如订单号、SKU）等中间状态。
• WMS接口层：我们为AI客服系统单独封装了一层“WMS适配器”。千万不要让AI模型直接、无限制地访问生产数据库，这是安全红线。这个适配器提供了一组安全的、权限受控的只读（大部分情况下）API，专门用于AI查询。例如，GET /api/ai/inventory?sku=xxx，GET /api/ai/order-status?order_id=xxx。
• 日志与监控：所有AI交互必须全链路日志记录。我们记录了用户的原始输入、Claude的意图分析结果、Gemini生成的查询语句、查询结果以及最终回复。这不仅是排查问题的依据，更是后续优化模型效果的宝贵数据。监控方面，我们关注API调用延迟、错误率以及Token消耗成本。

注意：安全与权限是生命线。AI客服的权限必须遵循“最小权限原则”。它只能访问明确授权的数据接口，并且所有通过AI系统执行的“写操作”（如标记异常、触发特定流程）都必须经过二次确认或仅限内部高风险场景使用。我们在适配器层就做了严格的校验和审计。

3. 核心模块实现细节拆解

3.1 意图识别与对话管理模块

这是AI客服的“大脑”，由Claude主导。我们并没有采用传统的、需要大量标注数据训练的意图分类模型，而是利用了Claude强大的零样本/少样本学习能力。

1. 设计系统提示词（System Prompt）提示词的质量直接决定AI的表现。我们的提示词包含了以下几个核心部分：

你是一位专业的仓库管理AI助手。你的主要职责是帮助用户查询仓库信息或解答流程问题。 你拥有以下能力： 1. 查询实时库存（按SKU、库位、批次）。 2. 查询订单状态（入库单、出库单、调拨单）及物流轨迹。 3. 解答常见的仓库操作流程问题（如收货步骤、质检标准）。 4. 对于无法处理的问题，礼貌地引导用户联系人工客服。 请遵循以下规则： - 首先，确认用户的问题属于以上哪一类。 - 如果需要查询，请务必向用户澄清或确认关键参数（如SKU编号、订单号）。如果用户未提供，请主动询问。 - 查询时，你的输出必须严格遵循JSON格式：{"action": "query_inventory", "parameters": {"sku": "ABC123", "location": "A-01-02"}}。可用的action包括：query_inventory, query_order, query_shipment, explain_process。 - 如果只是流程咨询，请直接基于你的知识库回答。 - 保持回复专业、简洁、友好。

这个提示词明确了角色、能力、规则和输出格式，将Claude“框定”在业务范围内。

2. 实现多轮对话上下文我们利用Claude的API，每次请求都将完整的对话历史（包括用户消息和AI之前的回复）作为上下文传入。这使Claude能记住当前会话中已经提及的信息。例如：

• 用户：“查一下SKU为XYZ456的库存。”
• Claude：（识别为库存查询，但参数不足）{"action": "query_inventory", "parameters": {"sku": "XYZ456"}}。同时回复用户：“请问您想查询哪个库位的库存？还是查询总库存？”
• 用户：“总库存就行。”
• Claude：（结合上下文，知道是延续上一个查询）{"action": "query_inventory", "parameters": {"sku": "XYZ456", "location": "all"}}

3. 状态维护在Redis每次交互后，我们将更新后的对话历史和解析出的意图参数（如上例中的sku）存入Redis，Key为session_id。这样即使服务重启，也能恢复对话状态（在一定时间窗口内）。

3.2 数据查询与API调用模块

这是AI客服的“手”和“脚”，由Gemini主导。Claude输出的标准化JSON指令，就是交给这个模块执行的“任务单”。

1. 构建Gemini的专用提示词给Gemini的提示词更偏向“技术执行”：

你是一个数据查询转换器。你将收到一个JSON格式的指令，你需要根据指令和下方的WMS数据库Schema，生成可执行的SQL查询语句。 WMS Schema摘要： - 库存表 (inventory): id, sku_code, location_code, quantity, batch_no, update_time - 订单表 (orders): order_id, order_type (IN/OUT), status, supplier/customer_info, create_time - 订单明细 (order_items): id, order_id, sku_code, qty - 物流表 (shipments): shipment_id, order_id, carrier, tracking_no, status, estimated_delivery 指令示例： 输入: {"action": "query_inventory", "parameters": {"sku": "ABC123", "location": "all"}} 输出: SELECT location_code, SUM(quantity) as total_qty FROM inventory WHERE sku_code = 'ABC123' GROUP BY location_code; 请只输出SQL语句，不要有其他任何解释。

我们将主要的几张表结构作为上下文给了Gemini。对于API调用，提示词类似，但要求输出的是HTTP方法和URL（如GET /api/inventory?sku=ABC123）。

2. 安全执行与结果处理Gemini生成的SQL或API请求，不会直接执行！这是一个至关重要的安全层。

• 对于SQL：我们会用一个非常严格的“SQL语法和表名/字段名白名单校验器”进行检查。确保查询只涉及允许的表和字段，没有DELETE、UPDATE、DROP等危险操作，没有子查询或复杂连接（根据安全策略放宽）。通过校验后，才在只读副本数据库上执行。
• 对于API调用：直接映射到我们预先定义好的、安全的WMS适配器API。 执行得到的数据结果（通常是JSON或列表），会原样返回给Claude进行下一步的“润色”。

3. 错误处理与重试网络超时、API限流、查询语法错误（尽管有校验，但Gemini偶尔仍会生成奇怪语句）都可能发生。我们为这个模块设计了指数退避的重试机制，并对常见的错误类型（如“SKU不存在”、“订单号无效”）设置了友好的错误信息模板，让Claude能够将这些信息转化为用户能理解的回复，例如“抱歉，没有找到SKU为‘XXX’的商品信息，请确认编号是否正确。”

3.3 知识库与流程问答模块

并非所有问题都需要查数据。关于“仓库工作时间”、“破损商品处理流程”、“新员工培训材料在哪”等问题，属于静态知识。我们为这部分构建了一个向量知识库。

1. 知识库构建我们将公司内部的SOP文档、FAQ、培训材料等文本，分割成小块（如段落），使用文本嵌入模型（我们选了text-embedding-3-small）将其转换为向量，然后存入Pinecone这类向量数据库。每个向量片段都带有元数据，如来源文档、标题。

2. 问答流程当Claude识别用户问题属于“流程咨询”时，它会触发另一个流程：

• 将用户问题转换为向量。
• 在向量数据库中搜索最相似的几个文本片段。
• 将搜索到的片段作为“参考上下文”，连同用户原始问题，再次提交给Claude，要求它“基于以下资料回答问题”。
• Claude会综合这些资料生成回复，并且我们要求它在回复末尾注明“以上信息来源于[文档名称]”。

这种方式保证了回答的准确性，并且避免了模型“胡编乱造”（幻觉）。同时，也让我们能很方便地更新知识库——只需更新文档并重新生成向量即可。

3.4 系统集成与部署架构

整个系统以微服务的形式部署，与主WMS解耦，通过API进行通信。

用户 (Web/IM/企业内部应用) | v [API Gateway & Auth] // 统一认证和路由 | v [AI Customer Service Core (FastAPI)] |-----------------------| | | v v [Claude Service] [Gemini Service] | | |---(结构化指令)------>| | | |<---(原始数据)---------| | v [Knowledge Base Service] (向量检索) | v [WMS Adapter API] (安全数据接口) | v [WMS Core Database & Systems]

部署要点：

• 容器化：所有服务都打包成Docker容器，用Kubernetes或Docker Compose管理，便于扩展和滚动更新。
• 配置管理：AI API密钥、数据库连接串等敏感信息通过环境变量或保密管理工具注入，绝不写死在代码里。
• 限流与熔断：对Claude和Gemini的API调用设置严格的速率限制，并实现熔断机制，防止因一个服务故障导致整个系统雪崩。
• 灰度发布：新功能先对内部小团队开放，收集反馈并监控稳定性，再逐步推给所有用户。

4. 实操中的挑战与解决方案实录

4.1 模型幻觉与事实性核查

这是最大的挑战。AI，特别是生成式模型，有时会“自信地”编造信息。比如，用户问“订单PO-2024-1001的物流单号是多少？”，即使数据库中不存在这个订单，Claude也可能编造一个单号出来。

我们的解决方案：

1. 强制结构化输出：如前所述，让Claude必须输出JSON指令，而不是直接回答。这迫使它从“生成模式”切换到“规划模式”，减少了第一步的幻觉。
2. 数据验证闭环：Gemini执行查询后返回的数据，Claude在生成最终回复前，必须基于这些真实数据进行表述。我们在给Claude的最终回复生成提示词中强调：“你的回答必须严格基于提供的数据，如果数据为空或显示‘未找到’，你必须如实告知用户‘未查询到相关信息’，不得自行编造。”
3. 置信度阈值与人工接管：对于关键查询（如涉及金额、敏感客户信息），系统会计算一个“置信度”分数（基于查询结果的明确性、历史类似问题的准确性等）。低于阈值时，AI会明确说“这个问题我需要为您转接人工客服确认”，并将会话历史和查询结果一并转给人工坐席。

4.2 成本控制与Token优化

同时调用两个顶级模型的API，成本不容忽视。我们做了以下优化：

• 对话历史摘要：随着对话轮次增加，传入的历史消息Token数会暴涨。我们实现了一个简单的摘要功能：在对话超过5轮后，将早期几轮的历史用Claude总结成一段简短的背景摘要，替换掉原始的长篇历史，大幅节省Token。
• 缓存常见查询结果：对于“今日总入库单数”、“爆款SKU实时库存”这类高频且数据更新不要求秒级的查询，我们在Redis中设置结果缓存（TTL为1-5分钟）。当识别到相同查询时，直接使用缓存数据，无需调用Gemini和数据库。
• 精细化监控：我们建立了每个会话、每个用户的Token消耗和API调用成本仪表盘。这帮助我们识别出哪些类型的问题最“烧钱”，进而优化提示词或引导用户更清晰地提问。

4.3 复杂多轮对话的上下文管理

用户的问题可能很绕。例如：“我上周三提交的那个紧急订单，就是给XX公司的那批货，现在发走了吗？如果没发，最快什么时候能发？顺便告诉我库存里还有多少他们的备品，SKU好像是A开头的。”

• 挑战1：指代模糊。“那个紧急订单”需要从对话历史或用户信息中关联。
• 挑战2：复合问题。包含了订单状态查询、发货时间预估、库存查询三个子任务。
• 挑战3：模糊查询。“SKU好像是A开头的”需要模糊匹配或进一步澄清。

我们的处理策略：

1. 实体识别与记忆：Claude在每轮对话中，都会尝试识别并提取关键实体（订单号、SKU、日期、公司名），并将其存入会话状态。当用户使用指代词时，系统会优先从已识别的实体列表中匹配。
2. 任务分解与顺序执行：Claude会将复合问题分解成独立的子任务JSON指令，按顺序发送给Gemini执行。例如，先查订单，得到订单ID和状态；如果状态是“待发货”，再触发一个“预计发货时间”的查询（这可能涉及另一个计算逻辑）；最后，用“XX公司”和“A%”去模糊查询库存。所有结果收集齐后，再组织成一段连贯的回复。
3. 主动澄清：对于“A开头的SKU”这种模糊输入，Claude不会直接让Gemini做全表模糊查询（性能差且结果可能过多）。而是会回复用户：“关于备品库存，我这里找到多个A开头的SKU，请问您指的是A1001, A1002还是其他？您可以提供更完整的编号吗？”引导用户提供更精确的信息。

4.4 与传统系统及人工客服的对接

AI客服不能是一座孤岛。

• 与工单系统对接：当AI判断需要人工介入，或用户直接要求“转人工”时，系统会自动在内部工单系统创建一张工单，并将完整的对话历史、已查询到的信息作为附件，分配给相应的客服小组。客服人员打开工单就能看到前因后果，无需用户重复。
• 人工辅助AI：客服人员在处理复杂工单时，可以@AI助手，命令它查询相关数据。例如，客服在聊天框输入“@仓库助手 查一下这个客户最近三个月的退货记录”，AI会在后台执行并直接将结果反馈给客服人员。这成了客服人员的“超级外挂”。
• 反馈学习循环：所有转人工的对话，都会被标记。我们会定期分析这些案例：为什么AI处理不了？是意图识别错了，还是知识库缺失，或是权限不足？这些分析结果用于持续优化提示词、补充知识库和扩展API能力。

5. 效果评估与持续迭代

项目上线后，我们设定了几个核心指标来评估效果：

1. 问题解决率：AI独立解决（无需转人工）的会话占比。目前稳定在75%左右，达到了初期目标。
2. 平均响应时间：从用户提问到收到首次回复的时间。从人工平均的几分钟降至AI的2秒内。
3. 用户满意度：在对话结束后推送简单的评分。目前平均分在4.2/5分。
4. 人工客服负载：内部客服团队处理的仓库相关查询量下降了约60%。

迭代过程：

• 第一周：主要处理“幻觉”问题和错误识别。通过强化提示词和增加数据验证，快速压低了事实性错误率。
• 第一个月：根据高频问题扩展知识库内容，并优化了对于模糊查询的澄清话术，提升了用户体验。
• 持续进行：我们建立了“Bad Case”收集渠道，鼓励员工反馈AI回答不佳的例子。每周团队会Review这些案例，讨论是模型能力问题、提示词问题还是系统逻辑问题，并制定优化方案。

我个人最深的体会是，这类项目的成功，技术只占一半，另一半是对业务的深度理解。你必须和仓库管理员、客服坐在一起，看他们每天怎么工作，听他们接到什么电话，记录下那些最琐碎、最重复的问题。然后，用技术手段把这些“痛点”一个个拧下来。一开始不要追求大而全，从一个最具体、最高频的场景切入（比如“库存查询”），做深做透，让用户立刻感受到价值。有了信任和正向反馈，再逐步扩展功能边界。同时，对成本和安全要保持绝对的警惕，设置好监控和熔断，毕竟它是直接连接着你核心业务系统的“智能体”，稳字当头。