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?skuxxxGET /api/ai/order-status?order_idxxx。日志与监控所有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存入RedisKey为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?skuABC123。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也可能编造一个单号出来。我们的解决方案强制结构化输出如前所述让Claude必须输出JSON指令而不是直接回答。这迫使它从“生成模式”切换到“规划模式”减少了第一步的幻觉。数据验证闭环Gemini执行查询后返回的数据Claude在生成最终回复前必须基于这些真实数据进行表述。我们在给Claude的最终回复生成提示词中强调“你的回答必须严格基于提供的数据如果数据为空或显示‘未找到’你必须如实告知用户‘未查询到相关信息’不得自行编造。”置信度阈值与人工接管对于关键查询如涉及金额、敏感客户信息系统会计算一个“置信度”分数基于查询结果的明确性、历史类似问题的准确性等。低于阈值时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开头的”需要模糊匹配或进一步澄清。我们的处理策略实体识别与记忆Claude在每轮对话中都会尝试识别并提取关键实体订单号、SKU、日期、公司名并将其存入会话状态。当用户使用指代词时系统会优先从已识别的实体列表中匹配。任务分解与顺序执行Claude会将复合问题分解成独立的子任务JSON指令按顺序发送给Gemini执行。例如先查订单得到订单ID和状态如果状态是“待发货”再触发一个“预计发货时间”的查询这可能涉及另一个计算逻辑最后用“XX公司”和“A%”去模糊查询库存。所有结果收集齐后再组织成一段连贯的回复。主动澄清对于“A开头的SKU”这种模糊输入Claude不会直接让Gemini做全表模糊查询性能差且结果可能过多。而是会回复用户“关于备品库存我这里找到多个A开头的SKU请问您指的是A1001, A1002还是其他您可以提供更完整的编号吗”引导用户提供更精确的信息。4.4 与传统系统及人工客服的对接AI客服不能是一座孤岛。与工单系统对接当AI判断需要人工介入或用户直接要求“转人工”时系统会自动在内部工单系统创建一张工单并将完整的对话历史、已查询到的信息作为附件分配给相应的客服小组。客服人员打开工单就能看到前因后果无需用户重复。人工辅助AI客服人员在处理复杂工单时可以AI助手命令它查询相关数据。例如客服在聊天框输入“仓库助手 查一下这个客户最近三个月的退货记录”AI会在后台执行并直接将结果反馈给客服人员。这成了客服人员的“超级外挂”。反馈学习循环所有转人工的对话都会被标记。我们会定期分析这些案例为什么AI处理不了是意图识别错了还是知识库缺失或是权限不足这些分析结果用于持续优化提示词、补充知识库和扩展API能力。5. 效果评估与持续迭代项目上线后我们设定了几个核心指标来评估效果问题解决率AI独立解决无需转人工的会话占比。目前稳定在75%左右达到了初期目标。平均响应时间从用户提问到收到首次回复的时间。从人工平均的几分钟降至AI的2秒内。用户满意度在对话结束后推送简单的评分。目前平均分在4.2/5分。人工客服负载内部客服团队处理的仓库相关查询量下降了约60%。迭代过程第一周主要处理“幻觉”问题和错误识别。通过强化提示词和增加数据验证快速压低了事实性错误率。第一个月根据高频问题扩展知识库内容并优化了对于模糊查询的澄清话术提升了用户体验。持续进行我们建立了“Bad Case”收集渠道鼓励员工反馈AI回答不佳的例子。每周团队会Review这些案例讨论是模型能力问题、提示词问题还是系统逻辑问题并制定优化方案。我个人最深的体会是这类项目的成功技术只占一半另一半是对业务的深度理解。你必须和仓库管理员、客服坐在一起看他们每天怎么工作听他们接到什么电话记录下那些最琐碎、最重复的问题。然后用技术手段把这些“痛点”一个个拧下来。一开始不要追求大而全从一个最具体、最高频的场景切入比如“库存查询”做深做透让用户立刻感受到价值。有了信任和正向反馈再逐步扩展功能边界。同时对成本和安全要保持绝对的警惕设置好监控和熔断毕竟它是直接连接着你核心业务系统的“智能体”稳字当头。