企业官网建设流程全解析

做电商系统这几年，我一直在琢磨一件事：传统商城“搜索框 + 分类导航 + 推荐位”这套体系，到底还有多少提升空间。直到我把大模型真正接进商城的核心链路，才意识到什么叫体验层面的降维打击。这篇文章写的就是从零搭建一个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 Prompt

Prompt是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_specs，Prompt里明确写“涉及商品的任何参数、价格、规格，必须先调用该工具，禁止直接回答”。第二层，输出侧加一道轻量校验：让服务端检查模型回答里出现的所有数字，是否都能在工具返回结果里找到对应值，找不到就强制改写回答为“具体参数以商品详情页为准”。

这套“工具强制 + 数字校验”的组合拳打下来，参数幻觉率从最初的百分之十几降到了百分之一左右。数字校验不用什么复杂算法，正则匹配数字再对比就够用，成本极低但效果立竿见影。

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可以出彩，但商城的底子永远是真数据、真库存、真交易链路。模型负责让人觉得聪明，业务系统负责让人觉得可靠，两者缺一不可。