做了快一年的电商智能体项目最大的感悟是客服导购绝对不是把两套话术拼在一起那么简单。我们团队接到的第一个需求特别朴素——能不能让客服机器人别那么蠢至少会查个订单、懂点商品。结果真正做起来才发现用户根本不会按你预设的分类来提问。有人问我买的鞋什么时候到也有人问这款扫地机和隔壁那个比哪个更省心还有人直接甩一句你们这衣服适合160的微胖女生吗——一句话里同时牵扯到订单、售后、商品参数、尺码推荐、竞品对比。刚开始我们做的是纯客服机器人上线两周就被用户吐槽答非所问后来才痛下决心重构把客服和导购两条能力线彻底打通。这篇文章就把整个设计和开发过程完整拆一遍需求怎么拆、架构怎么搭、知识库怎么建、工具怎么调、评测怎么做以及我们在线上踩过的那些坑。适合正在做或准备做电商智能体、大模型客服系统的同学参考也适合产品经理和技术负责人用来评估方案边界——因为很多代价真的是做进去之后才看得见。1. 需求拆解客服、导购、售后三合一到底难在哪1.1 传统客服机器人的三个致命伤在动手之前我们必须先搞清楚为什么传统机器人不行。市面上大多数客服机器人还在用基于意图分类加固定话术的套路用户问退货怎么办机器人命中退换货意图回复一篇写好的政策说明。这套逻辑的问题非常明显不理解上下文。用户说我刚买的那个坏了、就是这个、你刚才说的那个机器人根本不知道这个指什么。不具备操作能力。查物流、改地址、申请售后全都跳转到人工或H5页面路径极长。商品知识为零。商品参数在客服知识库里压根不存在遇到电池多大这类问题直接哑火。前两个问题大家早有共识第三个问题被严重低估。我们拉过一段时间的线上会话日志做分析发现约23%的客服咨询本质上属于导购型问题——用户不是来投诉的是想在购买前弄清楚某件事。这部分流量传统上被白白转给了人工而人工客服又恰恰最不擅长做推荐。1.2 导购场景的真正痛点导购这事儿电商平台其实有成熟的做法用户点进商品详情页看到参数、评价、推荐搭配。但用户真正会问的导购问题详情页一个都答不了比较型问题A和B哪个好——需要跨商品对比而且答案因人而异。适配型问题这个沙发我家客厅3米5能放吗这个奶粉1岁宝宝能吃吗——涉及参数换算和场景推理。偏好型问题送男朋友生日礼物预算一千以内他喜欢打游戏和健身。——需要从闲聊里提取约束条件。这些问题的共同特点是没有标准答案必须结合用户画像和实时数据来推理。而大模型恰好擅长这个这也是我们坚持引入生成式智能体的核心原因。1.3 我们的目标边界需求拆到最后我们给自己划了三条边界统一入口售前咨询、售中查单、售后处理全部走同一个机器人不再分售前机器人售后机器人。能力分层常见问题用知识库直答需要数据支撑的走工具调用订单、物流、卡券、售后需要推理的走大模型生成。人工兜底模型不确定、用户情绪激烈、或者涉及资金安全类操作必须能无缝转人工转接时还要把上下文摘要带过去。这三条边界决定了后面的所有技术选型。特别是第三条直接导致我们在架构上增加了会话摘要模块和置信度评估模块——这不是额外加分项而是上线前的及格线。2. 整体架构编排层、知识层、工具层怎么分工2.1 分层设计思路整个智能体的架构我们反复调了三轮最终稳定在一个四层结构上层级职责主要组件接入层多渠道适配、会话管理、限流风控消息网关、会话存储编排层意图识别、任务路由、上下文管理、工具调度LLM Agent框架、Prompt模板库、状态机能力层知识检索、工具调用、策略执行RAG检索服务、订单/物流/售后工具API、推荐引擎数据层知识库、商品库、用户画像、会话日志向量数据库、关系型数据库、日志系统编排层是整个系统的中枢。很多团队一开始把编排逻辑塞在Prompt里让大模型自己看着办结果线上跑起来完全失控——让它查订单它去编造订单号让它推荐商品它一本正经地推荐了已经下架的商品。我们的做法是编排层用代码控制什么时候该做什么大模型只负责怎么做不负责该不该做。具体来说编排层内置了一个轻量级路由模块。用户消息进来后先做意图分类规则小模型双保险分类结果决定走哪条链路咨询问答类走RAG检索答案生成。订单/物流类走工具调用链先确认订单身份信息再调API获取数据最后生成答复。导购推荐类走画像提取商品召回对比生成链路。售后办理类走校验规则工具调用结果确认的强流程。闲聊/情绪类直接走安抚话术必要时转人工。2.2 状态管理多轮对话的地基电商场景的对话有一个特点目标明确但拐弯多。用户可能先说我想看看有没有适合跑步的耳机聊了三轮之后又说算了其实我是想送人。如果系统只记住最后一句话中间的跑步送人这些约束就全丢了。我们最终采用了一个多级记忆方案短期记忆最近10轮原始对话直接放进Prompt上下文。工作记忆一个结构化的JSON对象实时记录当前会话已确认的约束条件预算、偏好、收货地址、已推荐过的商品ID等。长期记忆同一用户跨会话的画像摘要购买力等级、历史品类偏好、售后记录从用户ID关联的车里读取。工作记忆的维护是这套方案的关键也是最容易出错的地方。我们的做法是在Prompt里强制要求模型每次回复前输出当前约束集的增量更新再通过代码层做合并校验防止模型自己乱删约束。比如用户先说预算500以内后面说贵一点也行模型要能识别这是约束放宽而非替换。提示千万别让大模型自行决定记什么不记什么。我们在测试阶段发现模型经常把用户随口吐槽的质量不好当成商品偏好写进画像导致推荐逻辑完全跑偏。必须用代码定义好哪些信息有资格进入记忆哪些只是闲聊。2.3 模型选型的考量模型层面我们做了双模型策略主模型负责复杂对话生成和推理轻量模型负责意图分类和关键信息抽取。主模型我们测试过不同尺寸的开源和闭源方案最终选择了综合效果和成本都平衡的一个中型模型单次推理成本控制在几分钱以内。轻量模型则用一个蒸馏过的小模型单独部署延时控制在100毫秒以内。为什么不用最强的大模型因为电商客服场景的反馈闭环太快了——用户不满意立刻就会说你听不懂人话每天数百万级请求如果全走最强模型成本直接吃掉利润。实际跑下来我们的经验是意图分类这种模式化任务的准确率小模型和大模型的差距可以控制在1%以内但成本和延时差距是三到五倍。该省的地方一定要省。3. 商品知识库的建设向量检索之外的细节3.1 商品数据不能直接扔给向量库这是我们在知识库建设上踩过的最大一个坑。最初我们图省事把每个商品的详情页文本切块后直接embedding扔进向量数据库。结果用户问3000元以内的轻薄本召回来的全是一堆性能强劲轻薄便携的宣传话术参数层面的对比反而做不出来。问题出在商品数据是结构化程度极高的信息向量检索擅长语义匹配但做不了精确过滤。我们后来改成结构化为主、向量为辅的混合方案商品主数据SKU、价格、库存、参数、类目全部存关系型数据库支持精确过滤和范围查询。商品卖点、使用场景、材质描述等非结构化文本才走向量检索。检索时先通过SQL做粗筛比如价格上限、类目、上架状态再对粗筛结果做向量语义排序。这个改动立竿见影。之前用户问适合油皮的面霜系统经常召回控油洁面乳因为它们的embedding距离很近。现在先用面霜类目加肤质适配字段过滤再去排序准确率直接提升了一截。3.2 参数换算与场景约束的工程化导购型问题里有一类特别考验知识库设计用户说的约束和商品参数不是同一个描述体系。比如适合160cm女生穿 → 商品参数里只有S/M/L尺码和裙长92cm。客厅3.5米能放吗 → 商品参数里只有沙发总长2.8米。这个充电宝能带上飞机吗 → 商品参数里只有电芯容量26800mAh。这些问题如果单纯靠向量检索答案永远是建议您查看详情页。我们做了一套轻量级的参数换算服务把常见换算规则写成一堆可配置的函数式规则比如身高155-165且偏好宽松 → 推荐M码额定能量超过160Wh → 建议托运。用户在对话中暴露身高/偏好等画像信息后编排层会调用换算服务把推荐结果过滤一遍。这套规则不需要覆盖所有商品只覆盖高频类目服装尺码、家具尺寸、电子产品功率限制等性价比非常高。我们80%的适配型问题都是靠这套规则解决的大模型反而只在规则覆盖不到的时候才介入。3.3 知识更新的时效性问题电商知识库有个隐蔽但致命的问题商品和活动信息的时效性以小时计算。大促期间价格每小时都可能变库存随时清零活动规则说改就改。如果智能体引用的是昨天的数据会直接导致用户下单失败体验比答不上来还差。我们的对策是把知识库分成三层静态层品牌介绍、材质说明、售后政策每周更新一次即可。动态层价格、库存、活动规则工具调用时实时取数不做缓存。半动态层物流时效、仓库发货范围每半小时同步一次。关键原则凡是能通过API实时获取的数据绝对不进向量库。向量库只存不太会变的东西。这一点我们吃了不少亏才总结出来——最开始把价格写进知识库文本大促开始后全平台涨价智能体还在一本正经地推荐特惠价399被用户截图挂了两次。4. 客服能力实现工具调用的设计与兜底4.1 工具的本质是让模型不碰数据电商客服涉及的数据操作很多查订单、查物流、改地址、申请退款、查优惠券、核算赔付金额。如果让大模型直接拿这些数据出错的概率几乎是100%——它会一本正经地编造订单号、编造物流状态。所以我们定了条铁律模型永远不直接接触数据只接触工具的封装结果。举个例子查物流的路由是这样的用户说我的快递啥时候到。意图分类命中物流查询。编排层进入确认订单身份子流程——如果当前会话没有订单号模型会生成一句追问麻烦提供一下订单号或者我帮您查最近一笔订单用户给出订单号代码层校验订单号的格式合法性我们遇到过模型把用户说的数字串加了个空格或者漏了一位直接报错。调物流API拿到结构化结果包裹状态、当前节点、预计到达时间等。把结果填进Prompt模板让模型组织成一句自然语言答复。第5步和第6步之间的数据传递用的是JSON Schema定义好的格式。模型看到的是字段说明和值不是数据库查询语句更不是原始API返回。这样即使模型组织话术时发挥不稳定数据本身也不会被污染。4.2 一个工具调用的JSON Schema示例物流查询工具的入参Schema我们当时是这样定义的{ name: query_logistics, description: 根据订单号查询物流轨迹和预计送达时间, parameters: { type: object, properties: { order_id: { type: string, description: 订单号仅包含数字和字母长度11位 } }, required: [order_id] } }代码层拿到模型输出的参数后先做格式校验正则匹配仅数字字母长度校验再查用户身份有没有权限查看这单。权限校验这一步绝对不能省——我们遇到过用户报别人的订单号试图查询的情况如果不过权限直接调API就是严重的数据泄露事故。4.3 售后流程的强状态机售后类操作和查询类工具有本质区别查询是只读的售后是写操作。退款、改地址、申请换货每一步都可能卡在某个前置条件上。比如退款前提是订单在可退状态、改地址前提是商品还没发货。我们用状态机来管理售后流程每个工具只负责完成一步状态机的流转由编排层控制状态可执行动作流转条件待确认订单查订单、核对商品用户确认订单号校验资格查订单状态、退款政策订单满足退款条件用户确认发起退款申请、录入原因用户明确同意并选择原因完成返回受理单号退款请求提交成功转人工生成会话摘要校验失败/用户要求人工/情绪激烈状态机的好处是模型永远不需要做决策它只在当前状态允许的选项里帮用户完成操作和解释。这从根本上杜绝了模型自作主张直接给用户退款这类事故也让我们过内部安全审计时轻松了很多。4.4 工具失败的兜底策略工具一定会失败API超时、库存变动、订单状态异常、参数不合法。我们的兜底策略分三级重试超时类错误自动重试一次间隔500毫秒。换路主API挂了走备用API比如物流信息平台A挂了走B。降级全部失败后模型生成抱歉暂时查询不到为您转接人工客服同时把已获取到的部分信息附在转接摘要里让人工不用从头问一遍。这里有个细节降级话术里绝不能编造系统升级维护中这类解释。我们早期总喜欢给故障编个冠冕堂皇的理由结果同一句系统维护中被用户在不同时段碰到了四五次直接投诉你们系统天天维护。后来统一改成暂时无法获取已为您转接人工诚实反而投诉率更低。5. 导购能力实现从回答问题到促成转化5.1 用户偏好提取从对话里挖约束导购链路的核心是从对话里提取结构化偏好。这和我们做的短期记忆一脉相承但提取的信息更细。我们把偏好分成几个维度硬约束预算上限、指定品牌、指定类目、尺码、颜色。软偏好使用场景通勤/运动/送礼、风格取向简约/潮流、对特定参数的关注续航/重量。排除项用户明确说不要的不要白色的不要超过500g的。提取逻辑上我们既没让模型自由发挥也没完全用规则硬编码。最终方案是先让轻量模型做命名实体识别级别的抽取抽不出来的信息再由主模型在生成推荐话术时从对话历史里隐式利用。硬约束必须进结构化字段因为它们决定SQL查询的过滤条件软偏好可以不进结构化字段直接靠模型在生成时理解上下文。这套拆分的价值在效率上非常明显。硬约束结构化后商品召回阶段可以在毫秒级完成筛选如果全指望模型生成一次推荐要等模型读完整个对话历史再加推理慢不说还容易把不要白色理解反。5.2 商品召回先拿对候选集再谈生成话术导购推荐的链路是候选集召回 → 对比分析 → 话术生成。召回这一步我们完全用工程手段解决不会让模型直接凭记忆推荐——因为模型对商品库存和最新价格的记忆一定是过时的。一条典型的推荐链路长这样# 伪代码导购推荐的主链路 def recommend(user_profile, query): # 1. 从用户画像和当前对话提取硬约束 filters extract_hard_constraints(user_profile, query) # 2. SQL精确查询候选商品价格、类目、库存、上架状态 candidates product_db.query(filters, limit20) # 3. 向量检索补充语义相关的候选 semantic_hits vector_retrieval.search(query, top_k10) # 4. 合并去重按综合排序 ranked merge_and_rank(candidates, semantic_hits) # 5. 只把排序后的TOP5商品信息交给模型生成话术 return build_prompt(ranked[:5])注意第5步很关键模型只能看到TOP5商品的结构化信息看不到完整候选列表。这样可以有效防止模型选了一个库存为0的商品硬推。而且我们强制要求模型在推荐话术里附上推荐理由和可选替代品理由必须引用具体参数比如这款重量只有168克是同类里最轻的不允许说这款很好这种空话。5.3 商品对比模型最擅长也最危险的场景这两个哪个更好是导购场景里模型表现最两极分化的问题——答好了用户直接下单答不好用户直接走人。我们的处理方法是给模型一个特定的对比输出模板先列出对比维度从两件商品共同的属性里选3-5个关键维度价格、核心参数、适用场景、售后政策。再给出结论明确说如果更看重X选A更合适如果更看重Y选B更合适。最后给一个中性建议不强行二选一可以问用户更在意哪个维度。这个模板的价值在于逼着模型先摆事实再下结论。如果让模型自由发挥它经常跳过事实直接下结论而且结论有时候还反直觉。我们有一次内测模型对两款电池容量一样的手机一口咬定续航差很多理由是A的处理器更省电——这是模型脑补出来的参数表里根本没写。注意对比类回答务必要求模型只引用参数表中存在的数据。我们在Prompt里加了一句如果某个参数未在商品信息中提供请说明详情页暂未标注不要推测。这句话把对比类回答的可信度拉高了一个档次。5.4 优惠信息的透传与合规导购离不开促销。满300减50、前两小时九折、会员专享价——用户会问模型必须准确回答。但促销规则非常容易把模型绕晕因为它本质上是多个条件叠加的判定逻辑。我们把促销规则做成了可执行的规则引擎模型不直接解读规则文本而是根据用户的问题调用促销查询工具工具返回该商品当前适用的优惠组合的结构化结果模型只负责把结果讲清楚。举个例子用户问这款耳机现在买划算吗工具会返回{ original_price: 399, promotions: [ {type: 满减, condition: 满300减50, result_price: 349}, {type: 券, condition: 店铺券50元可用, result_price: 299} ], final_price: 299, expire_time: 2025-06-18 23:59:59 }模型只需要把原价399叠加满减和店铺券后到手299优惠截止今天组织成更自然的口语。所有可能引起争议的数字到手价、截止时间全部来自工具返回值模型一个数字都不能自己算。这里尤其要强调的是时效应答大促期间优惠每分钟都可能变模型的语言组织再流畅只要引用了过期的价格转化率立刻跌穿。我们的经验是能用工具取实时数据的永远不让模型背数据。6. 安全护栏与幻觉治理上线前的生死线6.1 Prompt的分层约束我们的系统Prompt设计了三层结构角色层定义身份品牌官方智能助手、语气专业、热情但不夸大、立场不评价竞品、不承诺效果。能力层列出可以使用的工具、知识库的范围边界、需要转人工的场景清单。红线层明确禁止的表述绝对价格承诺、医疗保健功效断言、金融收益承诺、绝对化用语最好第一等。红线层的效果尤为显著。电商场景最怕的就是合规风险比如保健品说根治、护肤品的三天见效、电子产品的永不坏。我们把这些红线直接在Prompt里声明并配合输出侧的关键词过滤做双保险。有一次模型差点回复这款按摩仪对缓解颈椎病有显著效果被关键词过滤器拦截了——这个case后来成了我们培训材料里的经典反面案例。6.2 幻觉治理让模型开口前先确认依据幻觉是客服智能体的头号公敌。模型编造物流信息、编造退款进度、编造商品参数任何一个在线上发生都是事故。我们的治理策略是三查三不三查查来源模型输出的关键事实价格、日期、订单号、政策条款必须能在工具返回值或知识库原文中找到对应。查一致多轮对话中前后说法不能矛盾比如前面说发货了后面又说待发货。查边界推荐理由不能超出商品信息中实际存在的参数范围。三不不编数据凡是数据类信息必须来自工具不能说根据系统显示然后自己编一个数字。不跨域回答知识库没有的内容明确说这个我暂时无法确认不硬答。不承诺结果退款到账时间、物流时效这类受外部影响大的东西只转述官方政策原文不做肯定XX小时内到的保证。实现上我们用了一个轻量级的事实校验器模型生成回复后代码层先解析出回复中所有数字和日期实体然后跟工具返回值或知识库原文做匹配匹配率低于阈值的直接要求模型重写。这个校验器写起来不复杂但线上幻觉率下降了一大截。6.3 情绪识别与升级策略电商客服有一个躲不开的场景用户很生气。我们在设计时专门做了情绪识别和升级机制。识别用的是轻量模型外加几个高信号关键词投诉气死差评315等。一旦触发情绪升级执行以下策略话术切换到共情模式先表达歉意和理解不做辩解。简化操作路径直接给出解决方案选项不反问一堆问题。如果用户连续两轮情绪未缓解立即触发转人工并把会话摘要用户诉求、已做操作、情绪等级用结构化文本传给人工客服工作台。情绪升级机制最难的其实是度的把握。转人工太频繁人工压力爆炸智能体形同虚设转人工太少用户体验受损。我们上线初期调了两周最终用情绪触发连续两轮未缓解作为默认策略配合每周复盘的误判案例持续调优。7. 评测方案离线集、线上指标与效果数据7.1 离线评测集的构建智能体的评测比传统软件复杂得多因为它没有一个唯一的正确输出。我们花了大力气构建了一套分层评测集单轮问答集2000条单轮对话覆盖售前知识、售后政策、物流订单、商品参数四类每条标注标准答案和关键事实点。多轮会话集500条完整会话重点标注是否成功维护了上下文约束——比如用户三轮前说过预算500后面推荐是否还在500以内。工具调用集300条需要调工具的场景标注工具调用是否正确参数是否合法数据上屏是否准确。安全合规集200条对抗样本包括诱导骂人、诱导承诺、诱导评价竞品、询问敏感信息等。评测方式采用LLM-as-Judge 人工抽检双轨制。大模型做初筛评分每天抽5%由人工复核。关键指标是事实准确率Factual Accuracy——不是回答流不流畅而是回答中的每个数字、日期、订单状态是否与真实数据一致。这是客服智能体最值得追的指标比任何对话自然度都重要。7.2 线上指标从解决率到净推荐值线上效果我们只盯五个指标指标定义目标值问题解决率会话结束且用户未转人工/未重复咨询同问题≥75%转人工率主动转人工的会话占比≤20%导购转化率会话中有推荐行为且产生下单的比例≥8%用户满意度会话结束后的评分4-5星占比≥85%事实准确率抽检会话中关键事实无错误的比例≥98%其中导购转化率是最有意思的指标——它直接证明了这个智能体不只是个省钱工具替代人工客服还是个赚钱工具带来增量成交。我们上线三个月时这个指标稳定在9%左右对比纯人工客服时的推荐转化率约12%虽然还差一些但考虑到智能体覆盖的咨询量远大于人工绝对增量其实更可观。7.3 线上跑测的一个典型case放一个我们内部复盘时公认的优质会话帮大家直观感受一下最终效果用户想买个降噪耳机平时通勤地铁上用预算500以内。 智能体好的通勤降噪这个场景很明确。我先按500以内、入耳式降噪筛选了几款热门的给您对比一下 ① A款价格299主动降噪-42dB续航30小时支持蓝牙5.3 ② B款价格459主动降噪-48dB续航24小时支持无线充电佩戴检测 ③ C款价格349主动降噪-38dB续航36小时防护等级IPX5。 通勤场景如果更看重降噪深度B款最合适如果续航优先C款性价比更高。您更看重哪个方面 用户B吧有点贵能不能看看有没有券。 智能体查了一下B款目前有店铺满400减50的优惠券可领叠加会员9折到手大约413元。需要我帮您把优惠券入口发出来吗 用户好的来一张。 智能体调用领券工具返回成功 智能体优惠券已领取下单时自动抵扣。还有什么需要帮您的吗比如要不要看一下搭配的耳机收纳盒这个case里包含了约束提取通勤、预算500、商品召回TOP3带原因、优惠查询实时取数、工具执行领券、二次导购推荐配件——全链路跑通且所有数字都来自实时数据。这就是我们想要的理想形态。8. 踩坑实录那些吞掉我们大量工时的隐蔽问题8.1 工具参数幻觉模型会自己补齐你没让它填的参数开发中期我们遇到一个诡异的问题用户没提供订单号模型却调用了物流查询工具而且填了一个看起来很像订单号的字符串。排查后发现模型在对话历史里看到过用户之前提到的一个类似数字串就直接当成订单号填进去了。这暴露出一个Prompt层面的漏洞工具描述里没有明确哪些参数必须由用户提供、哪些可以从历史中推断。修复方案是在JSON Schema的description里加约束比如order_id必须由用户明确提供如果会话中不存在用户给出的订单号返回错误码不要猜测。同时编排层加了一道校验用户当前会话没有确认过订单身份时查物流工具一律拒绝执行先走确认子流程。8.2 多轮对话的约束漂移差点让推荐系统人格分裂约束漂移指的是用户在对话中不断调整需求系统却只记住了最新一条丢了前面的约束。最典型的例子是用户先问有没有适合油皮的面霜聊了几句之后附带问顺便看看洗面奶系统直接连洗面奶推荐都按油皮来但推荐面霜时又把油皮给忘了推了一款适台干皮的。这个问题的根子在状态管理。我们早期把当前所有约束放在Prompt里让模型自己组织结果是模型经常只从最近的用户消息里提取约束对更早的约束选择性失忆。改成结构化工作记忆后约束的合并、更新、优先级全部走代码逻辑模型只负责读取当前约束集并应用——约束丢失率从17%降到了2%以下。8.3 知识库更新不及时大促期间翻了车前面提到知识库时效性问题我们是在大促实战中吃的亏。某次大促预热期运营临时改了一批商品的优惠力度但负责同步商品信息的ETL任务没跑成功静默失败——没有告警。结果智能体给用户报了旧价格用户下单时发现对不上一天之内冒出一堆投诉。这个事故之后我们做了两件事给关键数据变更加告警商品价格、库存、活动状态这些字段发生非预期批量变更时立即推送告警到值班群。给智能体加价格核验前置步骤推荐话术里如果涉及价格必须先调实时价格工具确认再组织语言。第二件事其实是把模型报价格这个高风险动作整个拿掉了——现在模型在推荐话术中写的所有价格数字都必须来自实时工具返回知识库里的旧价格根本不会进入Prompt。8.4 不够聪明的问题比太聪明好解决项目进行到后期我们把大量精力放在治理模型太聪明上——它太会顺着用户的话往下接太会编造不存在的信息太会在不确定的时候选择自信作答。反而不够聪明的场景答不上来、理解偏了通过持续补充知识库和规则就能稳步提升。给新手团队的建议是先做好控制再做智能。把工具调用、状态管理、事实校验这些工程护栏搭扎实模型哪怕傻一点至少不会闯祸。之后再逐步放开模型能力——比如从只允许查询到允许推荐从固定模板到自由生成。反过来做先让模型自由发挥再补漏洞线上只会翻车翻到没法收拾。最后分享一个我自己的体会。做这种生产级客服导购智能体最爽的时刻不是模型答对了一道难题而是看到那些脏数据被拦截在用户视野之外——订单号报错了、库存过期了、优惠价过时了系统在最后一步挡住了错误用户什么都没察觉。这个项目做了近一年我最想跟后来者说的是大模型决定了智能体的天花板但工程化决定的是地板。用户最终体验到的不是模型有多聪明而是系统有多靠谱。把地板抬高一个不是那么聪明但永远可靠的助手远比一个偶尔惊艳但经常犯错的聊天机器人更能赢得用户信任。