做电商系统这几年我一直在琢磨一件事传统商城“搜索框 分类导航 推荐位”这套体系到底还有多少提升空间。直到我把大模型真正接进商城的核心链路才意识到什么叫体验层面的降维打击。这篇文章写的就是从零搭建一个AI智能商城的完整技术架构和实战过程。它不是玩具Demo而是能直接在真实业务里跑起来的方案用户进店后可以直接用自然语言提需求比如“帮我挑一台适合办公室用的千元级咖啡机”系统自己完成意图解析、商品检索、参数比对、库存确认甚至一步步把人引导到下单路径。适合正在做电商、零售导购系统的团队参考也适合想搞明白AI Agent到底怎么落进业务系统的技术同学。我会把整个架构怎么拆、AI层怎么和已有交易链路整合、Function Calling怎么用、商品知识库怎么做、模型怎么选、上线后踩了哪些坑全部摊开讲。全是实际项目里的取舍和教训不吹概念。1. 从业务痛点倒推架构AI智能商城到底应该长什么样1.1 不是给商城加聊天机器人而是重构“人找货”的交互链路很多团队一听“AI商城”第一反应是“在页面上挂一个对话框用户问什么模型答什么”。这个思路基本做不成。原因很简单纯聊天没有交易闭环用户聊完还得自己去搜索、筛选、下单AI只是个玩具。我反过来想传统商城最大的痛点是什么是搜索只能匹配关键词理解不了“复合意图”。用户搜“便宜又好用的跑步机”分词系统只能拆出“便宜”“好用”“跑步机”返回的结果往往是一堆跑步鞋、健身衣。而用户真正的约束条件是多维度的预算3000以内、噪音小、家用、可折叠、售后好。这些约束用自然语言描述很轻松但落到关键词搜索上就全丢了。所以AI智能商城的第一价值不是“会聊天”而是把用户的模糊需求拆解成结构化筛选条件再走真实商品库返回结果。这意味着AI层必须和商品、订单、库存系统连通它不是一个独立聊天玩具而是插在“人找货”链路中间的一个智能解析器。这个定位想清楚之后后续的技术选型都围绕它展开。还有一条经验别试图把商城所有功能都改成AI驱动。下单、支付、退款这些交易闭环对稳定性和审计要求极高AI模型的输出永远存在不确定性让AI直接操作交易链路风险太大。我的方案是让AI只做“理解意图、检索商品、生成推荐理由、引导用户操作”这些辅助动作最终下单动作还是用户在前端自己完成。这样既享受了AI带来的体验提升又不会因为模型抽风弄乱订单数据。1.2 四层架构拆解AI是粘合剂交易闭环不动整个系统我分成四层每一层的职责边界非常清晰前端交互层AI对话面板、智能搜索框、商品详情页问答区。负责收集用户输入、流式渲染AI回答、展示商品卡片。AI应用层意图识别、Agent编排、工具调用、Prompt拼装、会话记忆管理。这一层不直接碰数据库所有数据获取都通过调用下层“工具”完成。业务服务层沿用商城已有的商品服务、订单服务、库存服务、用户服务通过标准HTTP接口暴露给AI层使用。数据与模型层大模型推理服务、Embedding模型、商品向量库、用户行为数据仓库。这套分层最核心的原则是“AI层只是粘合剂不侵入已有业务逻辑”。商品、订单这些基础服务照旧跑AI层只做编排和翻译把用户自然语言变成调用参数把工具返回数据变成自然语言回答。好处是即使AI层挂了商城还能退回传统搜索和导航即使要接新模型只需要改AI应用层下面的业务服务完全不用动。有人会问AI应用层为什么不用LangChain或者其它现成Agent框架我的选择是框架可以借鉴但生产环境尽量自己控制核心循环。Agent框架帮你省了样板代码但也带来了黑盒问题工具调用重试逻辑、上下文截断时间点、模型返回异常的处理全包在框架里出问题排查起来费劲。我实际采用的方式是轻量自研Agent循环一个会话状态机加几个工具函数逻辑透明可控性高得多。1.3 选型原则动手之前先问三个问题搭建之前建议团队先对齐三件事它能帮你避免后面很多返工。一是数据敏感性。商品资料、订单信息属于业务核心数据如果公司对数据出境或第三方服务有严格限制那模型部署方式会完全不同。合规要求宽松的可以优先用商用API快速上线要求严格的就得提前规划私有化推理方案。二是AI能力边界。AI商城不是什么都让大模型干。我的原则是能查库的不要让它凭记忆能算的不要让它心算能规则的不要让它理解。比如价格筛选、库存判断这些交给工具函数处理模型只负责把自然语言翻译成调用参数。模型负责“理解”和“表达”系统负责“事实”和“计算”。三是部署成本预算。商用API按量计费看着单价不高但日均几千轮对话跑下来成本不小私有化部署一次性买GPU也不便宜还要养运维。我的建议是先商用API跑通业务验证效果等对话量和转化数据都稳定了再把高频且效果可对齐的场景切到私有化模型上。选型原则定下来之后后面每一步都有据可依不会今天换个向量库、明天换个模型。下面从前端开始按数据流把整个系统串一遍。2. 前端交互层的设计与实现2.1 三个入口覆盖用户逛店的不同场景AI能力不能只藏在一个聊天框里用户在不同的逛店阶段有不同的交互习惯所以我在前端设置了三个AI入口。第一个是首页搜索框升级。用户在搜索框输入“千元内适合办公室的咖啡机”输入框下方不会直接跳搜索结果页而是先出现一行提示“我可以帮你按价格、容量、使用场景筛选当前为你找到32件商品”。点击提示后进入AI对话模式把原始query带到对话上下文里。这个做法的好处是拦截住了想表达复杂需求的用户而不是让他面对一个返回一堆无关结果的传统搜索页。第二个是悬浮对话助手。页面右下角的悬浮球点击后展开全屏对话面板。这个入口承担售前导购角色用户聊得再深都没关系。这里的设计细节对话面板需要支持消息流式渲染、工具调用状态展示、商品卡片消息三种消息类型。商品卡片的操作按钮要能直接加购、跳详情页不能只在聊天里展示一张图片否则用户看完还得自己去搜。前端必须把交易闭环串起来。第三个是商品详情页智能问答区。这个入口解决的是“这件商品到底适不适合我”的问题。用户问“这个空调噪音多少分贝”“支持以旧换新吗”AI通过RAG检索商品参数和售后政策回答。这比翻几百字参数表体验好太多而且能降低售前客服压力。PC端和移动端的组件我直接复用同一套Web组件对话面板做成独立模块通过插件方式嵌入不同端。前端框架用Vue或React都行关键是要把聊天组件和业务组件彻底解耦方便多个端共用。2.2 流式输出用SSE把“打字机效果”落地AI回答生成需要几秒甚至几十秒如果等模型生成完整个回复再一次性返回用户等得想砸手机。所以必须做流式输出。实现方式不复杂后端用FastAPI这类框架发起模型API的流式请求拿到token流后通过SSE协议逐块推给前端。前端用fetch读取ReadableStream不断解析SSE事件把新到的文本追加到当前消息气泡里效果就是“打字机式”逐字出现。这里有个关键细节SSE事件不能只推文本。聊天消息里同时包含普通文本、商品卡片、工具调用状态所以要为SSE定义事件类型。我实际用的是三事件协议event: text 文本增量 event: tool_status AI正在调用某个工具 event: product 商品卡片数据前端根据事件类型渲染不同UI。tool_status很关键AI在后台查数据时前端要展示“正在为你筛选商品...”的状态卡片否则用户以为死机了。商品卡片事件可以携带完整商品信息渲染成横向滑动的卡片列表点击卡片直接跳详情页。此外还要处理中断场景用户看了一秒就知道答案不对直接点“停止生成”前端要能终止fetch并通知后端取消模型请求。市面上很多团队的流式只做了单向漏了“取消”这个操作结果就是用户已经离开对话页后台还在继续生成浪费token。2.3 工具调用过程可视化让用户看见AI是“查出来的”而不是“编出来的”这是我最想强调的一个交互细节。AI商城最大的信任危机是“AI是不是在胡说八道”。如果AI推荐了一个商品用户不知道这个推荐是凭空捏造的还是根据真实库存筛选出来的信任感建立不起来。解决办法是把工具调用过程展示在界面上。比如AI给出推荐列表之前消息流里先出现一张“工具卡片”“正在调用商品检索”“筛选条件价格≤1500 / 品类咖啡机 / 关键词办公室”用户看到AI是拿着真实条件去库里查的天然会增加对推荐结果的信任。工具卡片执行完成后AI的文本回复里甚至会引用几个关键参数来证明“为什么推荐这款”可以写“这款型号容量1.5升支持30分钟自动断电符合你刚才说的安全性要求”。这些参数只有调用了商品详情工具才能拿到。从技术实现角度这要求后端把每一次工具调用的名称、参数、返回摘要记录进消息流而不是只把最终答案推给前端。虽然开发量多了一点但对用户体感的提升非常明显。3. Agent编排与Function Calling落地实践3.1 为什么商城场景必须用Function Calling如果只是“AI 对话”模型可以直接凭训练知识回答“这款手机支持无线充电吗”但它记忆里的参数可能已经过时也可能是另一个型号的参数。纯靠Prompt约束“不要编造”只是降低但无法杜绝幻觉。Function Calling才是治本思路。它的核心是让模型输出“调用哪个工具、传什么参数”的结构化指令而不是直接输出业务答案。系统收到指令后去真实服务里查询查询结果回填给模型模型再把结果组织成自然语言回复。比如用户说“帮我查一下上周买的订单到哪了”模型不直接回答“你的订单还在路上”而是先输出一个JSON{ name: query_order_status, arguments: {\user_id\: \u12345\, \order_time_range\: \last_week\} }服务端解析这个JSON调用订单服务真实查询拿到物流轨迹数据再把数据连同“请用友好语气告知用户物流状态”的Prompt一起发回模型最终生成用户看到的回复。整个过程数据是真实的模型只负责理解和表达这是和单纯聊天本质上的区别。我在实现时也对比过LangChain的ReAct模式它让Agent自主决定调用哪些工具、调用几轮。自由度是有了但生产环境的失控概率也高模型可能为了一个简单问题循环调用工具好几轮导致延迟和费用飙升。Function Calling更像“半自主”模型决定调用哪个工具并给出参数系统的状态机控制调用轮数上限、异常处理和超时。我限制最大工具调用轮数为3轮超过就强制用已有结果收尾。3.2 工具集设计把后端能力变成AI可调用的函数Agent能干什么取决于你给它哪些工具。商城场景工具集我按业务域划分第一批上线只开放了这几个search_products按关键词、价格区间、品类、标签组合筛选商品返回按相关性排序的商品列表get_product_detail获取单个商品的完整参数、图片、SKU信息query_stock查询某SKU的实时库存和发货时效calculate_discount根据优惠券和满减规则计算最终价格query_order_status查询订单状态和物流轨迹recommend_products基于用户历史行为生成个性化推荐每个工具的“描述”要写得很详细因为模型就是靠描述来决定触发哪个工具、提取哪些参数。描述写得含糊模型提取参数就乱来。比如search_products的描述我写的是“根据用户需求筛选商品支持按价格区间、品类目录、属性标签、关键词进行组合筛选价格参数单位是元”直接告诉模型这个工具能处理什么、参数单位是什么提取准确率立刻上一个台阶。工具参数定义用JSON Schema下面是一段真实可用示例{ type: function, function: { name: search_products, description: 根据用户需求筛选商品可按价格区间、品类、标签、关键词进行组合筛选, parameters: { type: object, properties: { keyword: { type: string, description: 商品关键词例如咖啡机、跑步机 }, category: { type: string, description: 商品品类ID来自商城品类树 }, min_price: { type: number, description: 最低价格单位元 }, max_price: { type: number, description: 最高价格单位元 } }, required: [keyword] } } }服务端拿到这个Schema后只要照着校验参数合法性就能拦截掉模型偶尔传出的非法值比如负数价格、不存在的品类ID。工具层再做一层Redis缓存同样的查询参数在5分钟内直接返回缓存结果省一次模型调用也省一次数据库压力。3.3 多Agent分工别让一个Agent干所有活最早图省事我做了单一Agent售前售后全往里塞。结果上下文越滚越乱用户前面问“这台洗衣机怎么样”后面突然说“能退吗”Agent分不清是问商品退货政策还是订单退款两种回答节奏完全不一样。后来参照客服团队分工拆成三个Agent每个独立维护会话上下文导购Agent负责推荐、比价、参数解读、种草话术语气主动目标导向是引导加购售后Agent负责订单查询、物流跟踪、退换货政策、发票问题语气谨慎只答事实不推荐商品内容Agent负责商品属性问答比如“这款容量多大”“质保几年”依托RAG回答答完即走路由怎么分在AI应用层加一道意图分类用轻量Prompt让模型判断“用户当前这句话更接近哪个Agent的职责”返回Agent ID然后后续对话都路由到对应Agent。成本很低但每个Agent的System Prompt和工具集就干净多了。记忆管理也要单独说。把完整对话历史全塞进上下文肯定不行轮数一多token就爆。我用的方案是“槽位摘要 最近轮次”每轮结束后把用户表达的关键约束预算、品类、品牌偏好、订单号等抽成结构化摘要存到Redis新请求来的时候把摘要放最前面配合最近3轮对话作为上下文。这样模型每次都能记住核心约束又不会让历史消息无限膨胀。3.4 Prompt样板如何写商城Agent的System PromptPrompt是AI应用层最容易忽略但又最影响效果的地方。我在生产里打磨了很长时间沉淀出一个比较稳的写法。以导购Agent为例你是商城AI导购名字叫“小商”。你的任务是帮助用户快速找到满意的商品。 规则 1. 只能通过工具获取真实商品数据禁止凭空编造价格、库存、参数。 2. 推荐商品前必须先调用商品检索工具拿到结果后再回答。 3. 如果用户没有提供预算或使用场景先问清楚不要自行假设。 4. 每次推荐不超过3个商品并给出每个商品的推荐理由。 5. 如果工具返回空结果如实告知没有匹配商品并建议放宽筛选条件。 6. 回答尽量简洁不超过200字。这套Prompt里有几个设计重点。第一强制工具调用和禁止编造这是防幻觉的第一道闸。第二控制推荐数量避免模型一次性抛10个商品造成选择过载。第三工具为空时的处理方式写进了Prompt让模型在尴尬场景下也能给出得体回应。第四回答长度限制防止导购Agent输出长篇大论拖慢响应。Prompt不是写完就完事的。上线前我专门收集了100条真实用户问题逐条过了一遍模型回答把答错的、答得啰嗦的、答得没有人味的都标记出来回头针对性改Prompt或工具描述。这个“dailyprompt review”流程比任何调参都有效建议每个迭代周期都做一次。4. 商品知识库、向量检索与个性化推荐4.1 商品数据清洗向量化的前提是数据不烂很多团队一上来就让Embedding模型把商品标题全部向量化然后直接做相似度检索效果往往一塌糊涂。原因是商品数据从ERP导出来之后又脏又乱标题里混着促销词“爆款”“限时秒杀”规格单位不统一有的把“英寸”写成“寸”有的把“1.5匹”写成“1.5P”下架商品也没打标记。Embedding模型没有想象力你给它什么文本它就编码什么。标题是“【限时抢购】爆款静音空调 1.5匹家用冷暖一级能效 大促销全网最低价”向量就会被“促销、抢购、最低价”这些词带偏用户搜“安静卧室空调”反而匹配不上。所以数据清洗是第一步而且得人工盯。我提供一个能直接用的商品Schema模板基础字段商品ID、标题、副标题、品类ID、品牌、售价、原价、上下架状态规格字段统一单位后的参数比如功率(kW)、容量(L)、噪音(dB)标签字段适用场景家用/商用/送礼、人群儿童/老人/户外、核心卖点静音/节能/便携索引文本由“标题 品类名 核心属性 标签”拼接而成专门喂给Embedding模型拼接索引文本是有讲究的它不是把字段乱序拼起来而是按“用户最可能在意的属性”优先。比如空调顺序是“品牌 匹数 类型 适用场景 核心卖点 其他参数”。这样索引文本生成后的语义重心和用户搜索意图能对齐。4.2 Embedding模型与向量数据库选型Embedding模型我推荐用中文效果稳定的开源系列比如bge系列直接把商品索引文本转成1024维向量。需要注意Embedding模型和对话模型是两回事不能拿对话模型来“想当然”地生成向量专门的Embedding模型在语义相似度任务上效果好得多而且推理速度快。向量库选型是另一个容易纠结的点。我见过团队为了“技术先进”硬上Milvus结果业务只有几十万条数据多维护一套高可用集群运维成本吃不住。这里我的经验是分阶段来数据量百万以内直接用pgvector。它作为PostgreSQL插件和业务数据放一起备份、迁移、权限管理全都复用现有体系不用新引入中间件。数据量千万级或向量检索QPS很高时再考虑独立的向量数据库比如Milvus或者继续用Elasticsearch的kNN能力取决于团队原来是否已经维护了ES集群。pgvector建表查询非常简单实际落地代码大概长这样CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE product_embedding ( product_id BIGINT PRIMARY KEY, embedding VECTOR(1024), updated_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX ON product_embedding USING hnsw (embedding vector_l2_ops);查询时把用户意图转成向量再在表里做最近邻检索SELECT product_id FROM product_embedding ORDER BY embedding - $1::vector LIMIT 10;注意$1就是用户问题向量。召回后不要直接把向量相似度当成相关度还需要叠加一层“业务过滤”下架商品排除、价格范围过滤、库存可售过滤。向量负责语义匹配业务规则负责现实约束两者缺一不可。4.3 RAG问答落地把“猜答案”变成“查资料”商品属性问答是AI商城的高频场景用户问“这个手机支持无线充电吗”“冰箱保修几年”。直接让模型回答又是幻觉重灾区。RAG的思路是先检索相关信息再让模型基于检索结果回答。但商城RAG和通用文档RAG有个本质区别很多答案不是躺在文档里而是躺在结构化字段表里。“无线充电”是specs表里一个布尔字段“保修几年”是售后政策表里一个数字字段你在商品描述文档里反而找不到。所以我的落地方案是“结构化查询优先文档RAG兜底”用户提问先过一次Function Calling尝试映射成结构化查询比如提取实体“商品型号”、属性“无线充电”映射成功就直接查结构化参数表拿到精确结果组织回答映射失败再走文档RAG从商品详情、FAQ、售后政策文档里切块检索这个组合的效果很稳。统计下来大概80%的属性类问题走结构化查询就解决了剩下的文档问答查不到答案时Prompt里约定模型回答“具体信息以商品详情页为准”把不确定性直接挡在外面。RAG的文档切片也要讲究。商品详情页段落长直接整段塞进上下文既浪费token又降低命中率。我按“属性小块”切标题、卖点、参数、注意事项各成一块每块控制在200字左右检索时只召回最相关的3到5块。4.4 个性化推荐AI补全传统协同过滤的冷启动传统推荐系统UserCF和ItemCF最大的问题就在冷启动新用户没有行为数据系统怎么知道该推荐什么AI商城解决这个问题有一个天然优势——用户会直接开口说自己的需求。比如用户第一轮就说“我想找一款适合骑行时戴的蓝牙耳机要防水、续航长、别超过800块”。这句话本身就是极高的推荐信号。我把它送进Embedding模型转成向量在商品向量库做语义相似度检索再叠加用户说出的价格约束首屏推荐就能相当准确。这比传统推荐系统“瞎猜”强太多。多轮对话里用户表达的偏好也会实时更新。比如用户前面说“预算2000左右”看了几款后又补充“想要带烘干功能的洗衣机”Agent要把这些约束实时透出给推荐算法。我这里采用的做法是每轮会话结束Agent更新Redis里的“用户偏好槽位表”品类、价格带、品牌黑名单、功能需求推荐时先读槽位表做约束过滤再做语义排序。看到用户对某品牌明确表示“不要”就把该品牌所有商品降权这种个性化粒度传统推荐系统很难做到。推荐结果返回后不能直接甩给用户要加上“可解释推荐语”。比如“这款卡萨帝滚筒带热泵烘干符合你刚说的南方回南天需求目前有货券后价3599”。可解释性是AI推荐区别于传统推荐的一个巨大优势也是提高点击率的利器。5. 大模型选型与推理服务部署方式5.1 商用API和私有化部署做“双轨制”大模型选型是绕不开的话题。我的态度很明确不要非黑即白生产环境用“双轨制”。商用API的优势是模型能力强、稳定、零运维接入成本低适合快速验证业务。劣势是按token计费长期高调用量成本可观而且数据要出内网合规要求严格的项目过不了审。私有化部署的优势是数据不出内网、单次调用边际成本低、可针对业务数据微调。劣势是得养GPU资源模型能力通常弱于同代旗舰商用API而且推理延迟和并发能力都需要自己调优。我的选择是对话和复杂推荐等强能力场景用商用API追求效果意图识别、属性提取、商品问答等简单场景用私有化小模型追求速度和成本。两层之间通过统一的AI服务网关调用上层业务代码无感知想切就切。5.2 模型能力分级不要一类模型打天下很多人觉得“大模型”就是对话模型买一个最贵的完事。实际做AI商城会发现不同场景对模型能力的要求差异巨大用一套旗舰模型全扛非常浪费。我按“职责”把模型分成四档对话模型负责多轮导购对话、复杂推荐理由生成需要最强的指令跟随和上下文理解能力意图分类模型负责判断用户问题属于售前、售后还是属性问答用小参数模型就能干速度还快Embedding模型负责商品文本和用户query的向量化必须用专门的Embedding模型跟对话模型完全不同路线重排模型对检索召回的候选商品做精排用交叉编码器比向量余弦相似度更准确模型分级之后一个明显的好处是成本骤降。意图分类这类简单任务一天调用几万次用旗舰模型的话费用哗哗的换小模型后延迟从800ms降到200ms准确率只掉了2到3个百分点完全在可接受范围内。这里补充一个重要提醒不要拿对话模型临时当Embedding模型用也不要拿Embedding模型去生成对话回复。术业有专攻模型选错会直接影响效果而且排查起来特别隐蔽。5.3 成本与延迟的平衡两个数字和三条经验先算一笔账。假设商城日均5000轮AI对话平均每轮输入600 token、输出450 token商用API按常见定价估算一天光模型调用费就在大几百元级别一个月下来不是小数目。如果把高频的意图识别切到私有化小模型把FAQ类问题加缓存可以优化掉40%以上的调用量。控制成本的经验主要有三条。第一缓存高复用回答用户问“你们发货用什么快递”第一次用大模型生成后把回答缓存起来后面同一问题直接命中缓存不再调大模型。商品属性类FAQ尤其适合这个策略。第二压缩上下文模型输入token多贵啊历史消息别全带上用槽位摘要和最近3轮就够长文档用RAG只召回最相关段落。第三限制输出长度不是所有回复都需要小作文导购推荐控制在200字内既省token又提高阅读效率。延迟控制方面除了流式输出还有几条硬经验。AI调用必须设超时我用的上限是8秒超过就返回“AI助手繁忙请稍后再试”前端降级到传统搜索。不要在一个请求里串行调用多个工具比如要查库存又要算折扣尽量并行发起把总耗时压下去。6. 上线之后踩过的坑问题排查实录6.1 商品参数“一本正经胡说八道”上线第一周最典型的问题用户问“这款冰箱容量多大”AI回答“500升”实际商品参数页写着450升。原因很简单模型凭着训练记忆里对这款产品的模糊印象猜了个数字压根没去查结构化参数表。对策分两层。第一层把“商品属性问答”独立成一个专用工具get_product_specsPrompt里明确写“涉及商品的任何参数、价格、规格必须先调用该工具禁止直接回答”。第二层输出侧加一道轻量校验让服务端检查模型回答里出现的所有数字是否都能在工具返回结果里找到对应值找不到就强制改写回答为“具体参数以商品详情页为准”。这套“工具强制 数字校验”的组合拳打下来参数幻觉率从最初的百分之十几降到了百分之一左右。数字校验不用什么复杂算法正则匹配数字再对比就够用成本极低但效果立竿见影。6.2 上下文越用越长对话越来越慢运营反馈说用户聊到第15轮AI回复要等半天偶尔直接报错。排查下来是上下文窗口被完整历史消息撑爆了。每轮对话用户说一句、AI回一段再加上工具返回的商品数据15轮下来轻松超过上万tokens模型处理时间长且费用高。我的解法是“主动上下文压缩”加“固定滑动窗口”。每轮对话结束立刻抽出关键槽位预算、品类、品牌偏好、待确认参数存Redis新请求来了用“槽位摘要 最近3轮消息”作为上下文。摘要能保证核心约束不丢滑动窗口则控制token数量恒定。实际效果是用户聊多久响应延迟都保持稳定。有个细节摘要更新时机很重要。我踩过的坑是只在用户明确改变主意时更新摘要比如说了“预算提高一点”才更新价格槽位用户没提就不动避免把用户随口的话当成新约束反而推荐偏离方向。6.3 工具调用死循环一个请求烧掉几十次调用压测阶段发现有个请求在日志里循环调用search_products参数变化但逻辑没进展活活调了四轮才被外层兜底拦下来。这种“Agent陷入工具循环”的问题大模型越强的模型反而越容易出现因为模型总是觉得自己参数没调对想再试一次。对策是在AI应用层加“工具调用轮数限制器”单次会话最多允许3轮工具调用达到上限后状态机强制进入“收尾回答”阶段用已有结果直接组织回复。另外每轮工具调用都要把“为什么调它”的记录写进日志方便事后复盘模型是在正常排查还是在空转。现在日志里一旦出现单次请求连续3轮以上工具调用直接打告警人工介入。6.4 向量召回不准搜“静音空调”推来高噪音款式RAG和向量检索上线后badcase一直不断。印象最深的是用户说“静音空调”向量检索返回了某个标着“强劲制冷”的机型噪音数据根本不合格。复盘下来问题出在“静音”这个卖点没有显式结构化索引文本里只有标题和属性拼接模型向量化的重心跑到“制冷”“强劲”上去了。解决思路是把它变成显式标签运营在商品后台维护“核心卖点”字段静音、节能、大容量这类高频卖点独立成标签拼接索引文本时把标签放在固定位置。另外我加了一道“规则精排”如果用户显式提到了一票否决项比如不要超过1000元、不要变频候选商品里违反约束的不管向量相似度多高都直接降权移除。这套“向量召回 规则精排”的混合流程上线后badcase明显减少。向量负责用语义扩大搜索范围规则负责用用户约束做硬性收敛两者是互补的不能互相替代。6.5 降级与限流AI服务挂了商城不能跟着挂AI商城最大的风险不是AI答错而是AI服务不可用时整个商城不可用。我一个压测时踩过对话接口被刷爆线程池占满连带着商品服务也响应超时用户直接下不了单。后来我给所有AI调用加了统一治理。信号量控制并发上限超过直接拒绝并在前端降级调用超时设置严格上限工具调用总时长超过5秒直接截断AI服务连续失败自动熔断让前端隐藏AI入口只展示“智能助手暂时繁忙请使用搜索”。核心交易链路和AI层完全隔离AI挂了用户还能正常搜、正常买只是少了一个帮手而已。这里想强调一个设计原则AI永远是锦上添花基础交易体验才是底子。任何AI功能上线前都要先想清楚“它挂了会发生什么”。如果没有降级方案功能就不该上。7. 上线评估与后续可以扩展的方向7.1 用数据说话AI导购到底带来了什么功能上线只是开始真正难的是证明AI真的有用。我们搭建了一套比较基础的评估看板核心指标没有贪多AI入口渗透率进店用户里有多少点击了AI入口。这个指标反映用户对AI功能的接受意愿。AI会话转化率发起过AI对话的用户里30分钟内完成下单的比例。和传统搜索链路对比看有没有显著提升。问答解决率用户追问“这不是我要的”或者直接转人工客服的比例。这个指标反映AI回答质量。人工客服转接率AI主动转人工的比例越低说明AI自己解决的问题越多。灰度期我们的策略是只开10%流量并且严格对比“使用过AI的链路”和“传统搜索链路”的转化率差。数据出来后发现AI会话转化率比传统搜索高出约12个百分点而且用户平均浏览商品数更少、决策更快。这说明AI导购确实在帮用户缩小选择范围而不是让用户越看越乱。评估数据要持续看不能上线一周就下结论。Prompt迭代需要数据反馈的闭环没有评估看板后面的每次迭代都是拍脑袋。7.2 灰度发布从AI助手到AI店长的渐进路径我强烈建议不要一上来就做“全自动无人商城”那是终极形态不是起点。稳妥的路径是“渐进式放权”第一阶段AI只做问答和推荐不碰任何交易操作。这个阶段风险最低主要验证意图理解和推荐效果。第二阶段AI可以引导用户一步步完成下单流程。比如用户说“就买这个吧”AI生成一个带参数的加购链接用户点一下确认才真正加购物车。AI在这个阶段是“导购员”不是“代购”。第三阶段再逐步尝试AI主动跟进比如用户加购后长时间没付款AI主动提醒并推荐优惠券。这时用户已经开始习惯AI作为“店长”角色存在了。每个阶段放量之前都要先做一轮badcase评审把该阶段真实用户对话记录拉出来人工标记回答质量、工具调用正确性、推荐合理性。badcase率没降到阈值以下就不要放量。和其他所有AI系统一样质量评估永远是上线前的最后一道闸门。7.3 下一步可以扩展的三个方向第一个方向是AI营销物料生成。商城每周要上架几十个新品商品文案、活动页Banner文案、社群推广语都很费人力。用AI批量起草人工审核后发布能明显提效。注意审核不能省广告法合规和品牌调性还是需要人来把关。第二个方向是智能定价辅助。基于竞品价格、库存水位、销售速度让AI生成调价建议但先只做到“辅助提醒”级别不做全自动改价。价格是敏感操作全自动风险太大人工确认一步不能少。第三个方向是多店复用与行业复制。把Agent配置化之后一套AI能力可以快速复制到不同垂直类目比如母婴、数码、家居每个类目只需要调整商品Schema、工具集和Prompt风格技术底层完全复用。这个方向做成熟了AI商城就不是一个项目而是一套能对外输出的产品能力。最后分享我个人的实际体会。落地这套AI商城最大的感受是“AI不是万能药但放进具体业务流里确实能产生实打实的转化提升”。关键不是你的模型多强而是你能不能把模型能力拆成一个个可验证的小场景先把搜索和问答做透跑通数据和效果闭环再去想着扩大边界。还有一条要反复提醒自己的AI可以出彩但商城的底子永远是真数据、真库存、真交易链路。模型负责让人觉得聪明业务系统负责让人觉得可靠两者缺一不可。