在数商云这类电商中台上搭智能体最怕的不是技术难而是把智能体当成一个“聊天盒子”。我最早接这个需求的时候团队里讨论的第一个问题不是“用哪个大模型”而是“智能体到底解决电商的哪个环节”。如果不先把这个问题想清楚后面所有架构选型、接口设计、评测方案都会变成无源之水。电商智能体不是简单做一个对话窗口它是把商品咨询、订单查询、售后处理、营销推荐这些本来需要人反复点鼠标、查系统、记流程的工作交给一套“能理解意图、能调用工具、能查数据、能按规则行动”的自动化系统去完成。数商云这类平台本身沉淀了商品、订单、库存、会员这些核心数据又有统一的中台API天然适合在上面接智能体。这篇文章我会从技术架构拆到全链路落地把我在实际项目里验证过的方案、踩过的坑、调整过的参数都写出来给准备在数商云上做类似项目的朋友一个可参考的路线图。1. 电商智能体到底是个什么“体”1.1 先别急着写代码把智能体的职责边界划清楚我见过太多项目一上来就喊“我们要做个全能的AI客服”结果做了三个月发现用户问“这件衣服有没有L码”答得挺好但“帮我查一下上周的退款到账没”就开始胡说八道。原因很简单——智能体的价值不在“聊天”而在“行动”。它要能对接数商云中台里的订单服务、售后工单、库存查询这些真实业务接口才能回答那些“非数据不可”的问题。所以第一件事是划边界。我一般把电商智能体的职责分成四层信息问答层商品参数、优惠规则、尺码推荐、物流时限这类靠知识库和检索就能答。数据查询层我的订单到哪了、积分有多少、优惠券能不能用必须实时调用中台接口。操作执行层改地址、申请退款、催发货、开发票涉及写操作要配权限和二次确认。主动营销层根据用户行为和标签做推荐、发券、提醒复购一般在用户授权后由事件触发。这四层对架构的要求完全不一样。信息问答层做好RAG就行数据查询层必须接入真实的查询接口并做字段级权限控制操作执行层要有“动作前确认”机制避免智能体把订单状态改错了。我在真实项目里看到很多翻车事故都出在把操作执行层的权限放得太松比如智能体可以直接调用“修改订单地址”接口但用户并没有在对话里明确说清楚新地址结果地址改到了旧小区。后来我们加上“关键动作复述确认”这步问题立刻少了一大半。1.2 用在哪几个环节产出最大从ROI来看电商智能体最值得先落地的场景有三个售前导购、售中查询、售后处理。售前导购是转化率提升最明显的地方。用户问“三千以内的拍照手机推荐一款”智能体如果能结合数商云里的商品库、实时库存、优惠活动给出2到3款有货且符合预算的选择再附上参数对比和当前促销价这个对话本身就完成了传统导购员80%的工作。我实测下来这类场景的用户点击率比普通列表页高30%以上。售中查询是“防差评”的关键。以前用户查物流要自己输入单号跳转第三方页面现在智能体直接调中台物流接口把“已揽收—运输中—派送中”的状态翻译成人话再主动追加一句配送网点的联系电话体验完全不一样。售后处理则是“降人力”的核心退换货流程里大量重复问答和表单填写智能体可以先用对话收集退货原因、上传凭证照片、选择退款方式再把这些结构化数据传给售后工单系统人工只需要审核异常单。这三个场景建议优先做前两个。售后处理涉及逆向物流和财务对账复杂度更高等前两个跑顺了、团队对智能体的行为有感觉了再上成功率会高很多。2. 技术底座数商云上搭智能体的架构选型2.1 整体分层设计与数据流走向我在数商云上的智能体架构基本是四层这四层拆开之后每个模块的职责都非常清晰接入层统一接管小程序、App、Web、企微客服这些渠道把消息转成标准会话事件。智能体引擎层负责意图识别、会话管理、工作流编排、工具调用、RAG检索是整个系统的大脑。业务服务层封装数商云中台的商品、订单、库存、会员、营销接口以标准OpenAPI形式暴露给智能体。数据与保障层包含内容知识库、用户画像标签、行为日志、监控告警、权限审计。用户消息从接入层进来后先走一个轻量级意图分类器。这个分类器只做粗粒度路由比如“查物流”“问商品”“办退款”“闲聊”不需要太智能化规则加一个小的文本分类模型就够用了。真正难的是意图识别后的动作编排比如用户说“我昨天买的鞋能不能换大一码”这里面其实包含三个动作查订单、查售后政策、生成换货申请。如果一开始就丢给大模型自由发挥它大概率会漏掉售后政策这个维度。数据流上我强调一个原则智能体永远不要直连数据库。所有查询和操作都必须经过业务服务层。这既是为了安全也是为了数据口径统一。智能体只需要知道“调什么API、传什么参数、拿到什么返回”不需要关心数据库里表的Join关系。这个隔离层也让后续对接更多渠道时业务逻辑可以复用。2.2 Agent 框架选择编排优先还是自由发挥现在市面上的Agent框架很多我的选型经验就一句话电商场景编排优先自由发挥只用在兜底。我最早尝试过完全交给大模型自己规划步骤让它决定“先查订单、再调售后政策、然后生成工单”。看起来很美实际跑起来问题很多。大模型经常漏步骤尤其是涉及多轮追问时它会忘记自己已经确认了退货原因又重复问一遍。更麻烦的是它可能在一个需要精确数值的场景里“脑补”出一个订单号。后来切到工作流编排模式把高频场景固化成DAG图节点就是业务API调用边就是条件判断和数据流转。比如“订单查询”场景固定是“解析订单号—调订单接口—格式化结果”中间不允许模型自由发挥。模型只负责两件事从用户话里抽参数、把结果翻译成自然语言。这样行为可预期技术上也好排查问题。自由发挥场景我留给了“非标准化问答”比如用户问“这件衣服配什么裤子好看”这种问题没有固定流程就让模型结合商品属性和知识库自由生成。但即便在这个场景我也会限制它的输出格式强制它给出“款式建议推荐商品链接”防止它长篇大论讲一堆空话。我的建议是整个系统里编排驱动的场景至少占80%自由生成的场景控制在20%以内。2.3 模型与记忆怎么配模型选型上我不会只盯一个最强模型。电商对话量大全走最强模型成本根本压不住。我现在的做法是三级模型路由小模型跑意图分类和实体抽取比如“查订单”“问尺码”“退货原因”速度快、成本低。中模型跑知识问答和商品对比这类场景对推理要求不高但需要一定的事实组织能力。大模型只处理复杂多轮对话、售后纠纷协商、内容创作这类需要强推理的任务。记忆设计是电商智能体最容易做砸的地方。电商对话往往跨越好几天用户昨天问了洗衣机今天又问“那款还能送货吗”如果智能体没有长期记忆就会让人感觉“这人记性真差”。我的经验是分三层记忆会话内记忆、用户级记忆、商品上下文记忆。会话内记忆用缓存保存最近几十轮消息用户级记忆存关键画像比如地址、常用收件人、近期订单状态商品上下文记忆存用户浏览或咨询过的商品快照。这三层数据都有生命周期用户级记忆可以放几天到几周避免模型被超长上下文中不重要的细节干扰同时也控制Token消耗。2.4 工具链接中台还是自定义API数商云这类平台通常已经提供了强大的中台能力商品中心、订单中心、库存中心都有现成的API。问题在于这些API面向内部系统设计字段非常多有很多内部枚举值直接暴露给智能体容易学坏。我建议做一层工具适配器把中台API重新封装成Agent Tools。这个适配器只做三件事裁剪字段只保留智能体需要的、翻译枚举状态码翻译成业务描述、添加限制写操作强制二次确认。比如中台订单接口返回status5适配器翻译成“包裹已从仓库发出当前正在运输途中”再交给模型组织语言。封装好的工具用一个Schema描述包括工具名、参数列表、返回值说明、使用例子。Schema的写法直接影响模型调用工具的准确率我后来发现给工具加上“典型问题示例”非常管用。比如查物流工具的描述里写上“当用户问‘我的快递到哪了’时应调用此工具并传入订单号”模型对工具的命中率明显提高。3. 全链路落地实践从需求到上线的关键步骤3.1 第一步把业务流程转成智能体可执行的动作图谱这一步是整个落地过程中最重要、也最容易被跳过的环节。业务流程文档写得再好如果不转成机器可执行的图谱智能体永远不知道怎么“动手”。我的做法是把每个业务场景画成“用户意图—触发条件—动作序列—异常分支”四段式。举一个真实的售后换货场景用户意图用户想换货。触发条件对话中识别出“换”“尺码不合适”“颜色不对”等信号。动作序列调用订单查询确认商品在可退换期内调用售后政策服务确认换货规则收集用户期望的尺码颜色生成换货申请单并通知人工审核。异常分支订单已超过换货期则自动转人工不强行拒绝用户输入的期望商品无库存则推荐相近款式并询问是否接受。这个图谱画完之后测试团队就可以照着图谱写用例开发团队照着图谱接接口数据团队照着图谱埋点。我建议在动手写代码之前先拿这个图谱找业务方评审一遍因为很多业务规则文档里其实没写清楚比如“换货申请后多久内可取消”这类问题在评审阶段暴露出来比上线后再返工要省太多成本。3.2 第二步提示词与工作流编排动作图谱有了接下来是提示词和工作流编排。我不把提示词看成一段静态文字而是看成一套“控制策略”。好的提示词要让模型知道三个边界该做什么、不该做什么、拿不准时怎么办。以售前导购为例我的系统提示词大概会包含这些内容角色定位你是XX旗舰店的智能导购、服务范围仅对XX店铺商品负责、行为红线不讨论与商品无关的话题、不编造库存和价格、输出格式先给结论再给理由附商品链接。这些约束看起来简单但每条都在实际运行中筛掉了大量bad case。工作流编排上我强烈建议把每个工具调用做成独立的节点而不是让模型一次性调用多个工具。原因有二一是多工具并发调用时如果某个接口失败模型很容易“将错就错”继续向下执行生成一个基于错误信息的答案二是分步调用方便日志审计每步都留下痕迹出了问题可以精确定位。比如查询订单和查库存必须分两步先确认订单存在再查库存两个接口之间加一个条件分支订单号无效就直接结束对话不继续白跑库存接口。这里还要说一个细节就是工具调用的超时和重试。数商云中台接口偶尔慢我遇到过查询订单接口5秒没返回模型等得不耐烦直接跟用户说“系统开小差了”。后来我在工作流节点里给每个工具设置了超时阈值和最多两次重试重试还失败就输出标准的兜底话术“正在帮你查询请稍等一下”而不是让模型自由发挥。3.3 第三步灰度切流与权限隔离电商系统牵一发动全身智能体绝对不能对外一口气全量开放。我用的是三层灰度策略第一层是内部白名单只开放给运营和客服团队测试。这个阶段主要验证功能正确性可以在数商云的沙箱环境里跑即使操作出错影响也可控。第二层是低风险渠道选一个流量小的入口比如某个特定商品详情页开放真实用户流量。第三层才是全域开放同时按百分百比逐步放量比如先10%、再30%、再到100%。权限隔离上我吸取过教训。有一次测试人员用测试账号跟智能体对话查出来的却是真实用户的订单因为查询工具只校验了“是否登录”没有校验“查的是不是自己”。从那之后所有涉及用户数据的工具我都强制在适配器里注入当前会话的用户ID后端接口只能按这个注入的用户ID查数据不接受前端传参指定用户ID。这样就从根上杜绝了越权访问。写操作类工具还需要更严格的控制。我的做法是写操作必须配置“人工审批开关”只有打开开关才允许智能体直接执行开关关闭时智能体只能生成操作草稿提交给人工确认。比如“修改收货地址”这个动作我至少在初期保持人工审批模式等智能体在大量对话中表现稳定了再逐步改为自动执行但保留审计日志。3.4 第四步评估指标与回归口径智能体上线不是终点是迭代的起点。但迭代需要一个稳定的评估体系否则你根本不知道改动是变好了还是变坏了。我用的评估指标分三层任务成功率用户提出的问题是否在当轮对话里得到解决比如查物流后用户是否表达了满意或没有继续追问。工具调用准确率该调工具时有没有调、调的工具有没有用对、参数传得对不对。安全合规指标有没有越权访问、有没有编造信息、有没有触发敏感词。评估数据的收集很关键。我在智能体后端的每个环节都埋了日志意图分类结果、工具的入参出参、模型的生成内容、用户的最终反馈全部汇总到日志平台。每天抽100条对话做人工抽样打分同时用一套自动化回归用例集跑一遍。这套回归用例里有高频场景比如“查订单到哪了”也有刁钻场景比如“我昨天买的能退吗但我没订单号”每次改提示词或模型版本都要全量重跑一遍确保这个修好了、那个没弄坏。我踩过的一个坑是为了让模型回答更准确把提示词写得太长太细结果常规问题回答得很标准但稍微问偏一点就“死板”了。后来我把超长提示词拆成了主提示词加场景子提示词主提示词管底线子提示词管具体场景改一个场景不影响其他场景回归测试也更好定位。4. 踩坑记录与排查思路真实项目里最容易翻车的点4.1 幻觉和商品库幻觉怎么把大模型拉回事实轨道电商场景里最不能忍的就是幻觉。用户问“这个保温杯容量多大”智能体回答“500ml”实际只有350ml这一条就可能让用户直接退货投诉。商品参数类幻觉根因是模型在“凭印象回答”没有先检索再生成。我的解决方案是强制“检索后回答”。在工具适配层里加了一个商品知识库查询工具所有涉及商品参数的问题模型必须先调用这个工具拿到结构化参数再根据参数生成回答。为了确保模型走这个流程我在提示词里明确写用户询问商品属性时禁止直接作答必须先调用商品检索工具。同时我在后置校验里加了一层规则回答中包含“容量”“材质”“尺寸”这些关键词时自动检测回答内容是否与检索结果一致不一致就强制覆盖。还有一种幻觉不太好发现模型把不同商品的特征混在一起。比如智能体把A手机的电池容量安到了B手机上因为这两个型号在训练语料里经常一起出现。这种问题靠规则检测很难抓我的办法是缩小RAG检索范围只检索当前会话涉及的商品ID不检索全库降低跨商品串信息的概率。4.2 多智能体协作的“踢皮球”问题后期场景变多以后我尝试过把智能体拆成售前、售中、售后三个子Agent各管一摊。这个设计在测试环境跑得很好但在真实流量下暴露了一个尴尬现象用户的问题跨业务线时Agent之间开始“踢皮球”。举个真实例子用户说“我刚买的裙子要退货但我现在想先问下有没有别的尺码可以换”。售前Agent说“换货请找售后”售后Agent说“商品咨询属于售前”——用户在中间绕来绕去体验非常差。排查下来发现问题不在Agent本身而在于缺少一个统一的“总编排器”。后来我加了一个Router层它不负责具体业务只负责两件事判断问题归属哪个Agent、检测当前Agent处理不了时是否要转交给另一个Agent。我还定义了一个跨Agent交接协议转交时必须带上关键上下文用户ID、订单号、对话摘要接收方不需要用户重新描述问题。加了这层之后跨线转交的体验顺畅很多。4.3 性能与成本平衡Token 快烧完了怎么办电商大促期间流量是平时的十倍如果你的智能体按峰值流量设计模型调用规格平时就是在烧钱。我的策略是“逻辑前置、模型后置”能走规则的场景绝不让模型跑。比如物流状态查询这种结果极其规律的信息我直接在工作流里调接口、拼模板模型只负责一个“表面润色”的工作。能用小模型解决的意图分类、情感判断绝不让大模型参与。大模型只在需要语义理解和内容生成时上比如售后纠纷安抚、个性化营销文案。上下文窗口管理也很关键。有些用户喜欢一次问十几个问题如果全都塞进上下文几轮下来Token消耗会非常夸张。我做了上下文裁剪策略前30轮对话全部保留30轮之前的只保留意图标签、关键实体订单号、商品名、用户地址、最后结论其他细节全部丢弃。如果用户后续问起之前的细节再通过用户级记忆去检索不依赖上下文。我建议你在上线前就做一个成本预算模型预估日活、平均对话轮数、每轮Token消耗、三级模型调用比例算出每天的成本区间。这个数字最好在立项时就过一遍别等项目跑起来才发现成本是预期的三倍到时候产品、技术、财务三方都难受。4.4 权限与审计智能体不是法外之地权限问题是我在所有交付项目里反复强调的不是因为我有多小心而是因为真实翻过车。有一次智能体帮用户查“最近订单物流”结果把用户三年内的订单列表都返回了。后来定位到原因中台接口默认返回全部订单适配器没有限制条数模型又把接口返回的所有内容都转发给了用户。从那之后我定了两条铁律第一所有查询接口必须做“最小必要返回”。适配器只透传当前场景需要的字段订单查询默认只返回最近五条商品查询只返回在架商品且价格字段必须脱敏处理。第二所有写操作接口必须走审计。审计日志里记录时间、用户ID、智能体实例、工具名、入参出参、触发来源、人工审批人一条不能少。审计日志平时没人看但一旦出现客诉纠纷它就是定位问题、划分责任的关键证据。权限不是一次性配置完就结束的。数商云上的角色和权限体系经常调整比如运营新增了一个活动营销工具对应的调用权限就要跟着变。我建议每个月做一次权限复核把智能体已接入的工具清单拉出来对照当前的业务需求关掉不再使用的、收紧权限过大的、补上遗漏的。5. 智能体上线后的迭代节奏与扩展方向智能体跟普通软件不一样它不是上线即完成而是“上线才开始”。我目前固定每周做一次迭代复盘周一拉出上周所有bad case按问题类型归类意图误判、工具误调、话术生硬、知识库缺失周二修提示词和RAG知识库周三用回归用例集全量验证周四放一个低流量灰度跑两天看数据下周继续循环。这个节奏比较笨但稳我前后维护了快十个月智能体的任务成功率从最初的68%慢慢爬到了92%以上是靠一版一版叠出来的。扩展方向上我现在比较看好的几个方向包括多语言客服直接改智能体的语言层不用重复建设业务逻辑、个性化营销文案结合数商云会员标签体系在用户生日、会员等级升级等节点主动触达、供应链协同给运营团队用的智能体自动生成补货建议和库存预警。这些都是在现有智能体底座上生长出来的东西基础扎实的话扩展并不会伤筋动骨。根据我个人的经验最后再说一句做电商智能体有时候慢就是快。与其一口气铺很多场景、最后每个场景都做得稀烂不如先把两三个高频场景打磨到极致。用户在“查物流”“问商品”这种高频小事上觉得好用比你在十个场景里酷炫地展示AI能力更能带来真实的商业回报。