做AI购物代理这个方向也有一年多了踩过的坑数都数不过来。有一个感受越来越强烈很多团队把精力全花在怎么把查询Query写漂亮、怎么调Prompt上结果实际效果就是上不去。真正拉开差距的其实是上下文Context的构建和利用。这篇文章就围绕“AI购物代理”这个产品形态聊明白为什么上下文优先于查询以及我在实际项目里是怎么设计上下文层的。无论你是做AI Agent的工程师、电商平台的产品经理还是想入门大模型应用开发的人这篇都值得看完。1. 先别急着调Prompt把上下文当成第一公民1.1 什么是AI购物代理它到底解决什么问题AI购物代理说白了就是一个能替用户完成购物决策和购买动作的智能体。它跟传统搜索框、推荐流最大的区别在于交互形态用户可以用自然语言连续表达需求比如“帮我找一款适合油性敏感肌的防晒霜预算两百以内要能发货的”代理自己去检索、对比、筛选、解释甚至按用户确认后直接下单。我见过不少团队把购物代理做成了“套了壳的搜索”用户问一句代理调一次商品搜索API把Top 10结果丢给大模型润色一下就完事了。这种方案不是不能用但用户体验极其割裂。用户说“上次那个牌子不错但这次想要小瓶的”代理完全不知道“上次那个牌子”指的是什么用户说“预算提高了”代理也不知道之前预算是多少、为什么提高。每一次对话都要从头解释用户很快就失去耐心。传统搜索是“用户输入关键词系统返回结果”推荐是“系统根据标签猜用户喜欢什么”。而购物代理是一个能连续对话、能多轮交互、能执行动作的Agent它的核心价值不在单次问答而在多轮交互中的连续性和记忆能力。这就是为什么我说查询是“一锤子买卖”上下文是“连续剧”。1.2 为什么说上下文比查询更重要先说一个容易被忽视的事实大模型本身对“单次查询”的理解能力已经很强了。你给一个清晰的指令比如“找出价格低于300元的无线降噪耳机”模型几乎不会理解错。真正的难题是用户不会总把需求一次性说清楚也不会每次都把前提条件重复一遍。举个例子。用户在周一问“推荐一款适合通勤的背包能放14寸笔记本。”代理推荐了几款。周二用户回来说“第一款太重了有没有轻一点的”如果代理没有记住周一聊过的“第一款”是哪款、重量是多少这个问题根本无从答起。查询本身很简单——“轻一点”但它依赖一个关键前提昨天会话里的商品列表和用户反馈。这个前提就是上下文。我做过一次对比测试同样一个多轮购物对话A版本每次只把用户当前这句话发给模型B版本把历史对话摘要当前商品候选列表用户偏好画像一起发给模型。结果A版本在第二轮之后的有效回答率断崖式下跌B版本则保持稳定。这不是模型能力的问题是信息输入的问题。查询决定的是“怎么问”上下文决定的是“有没有资格问好”。没有上下文再漂亮的查询也是空中楼阁。2. 上下文到底包含什么三层结构拆解2.1 用户画像层长期偏好如何沉淀第一层上下文是用户画像属于长期记忆跨会话有效。包括性别、年龄区间、所在城市、消费预算区间、品类偏好、品牌偏好、价格敏感度、历史购买记录、退货率高等行为信号。购物场景里用户画像的沉淀不能只靠用户自己填。更可靠的方式是从行为里挖用户反复搜索某类商品、在某个价位段停留很久、对某种材质反复提问这些都是信号。把信号清洗后写入画像下一次对话时直接作为静态上下文注入。这里要特别提醒一个坑画像不是越细越好。我见过有人把画像字段设计了几十个结果一是存储成本高二是注入Prompt后占大量token三是部分画像字段置信度不高反而干扰模型判断。我的经验是购物场景优先维护四类画像字段预算区间、偏好品类/品牌、物流敏感度是否在意发货速度、购买决策风格纠结型/果断型。其他字段按需扩展但别贪多。画像的更新时机也重要。不要每次对话都全量更新而是在关键节点更新用户明确表达偏好变化时、完成一次购买后、对某类商品连续表达负面反馈时。比如用户说“以前觉得贵点无所谓现在要省着点”这就是预算画像的强更新信号代理应该立刻把预算档位降下来并在后续推荐中体现。2.2 会话状态层当次对话的临时记忆第二层是会话状态属于短期记忆只在一次会话周期内有效。它记录的是当前对话的进度用户已经看过哪些商品、对哪些商品点了不喜欢、当前筛选条件是什么、正在对比哪几款、已经排除了哪些候选、用户对每款商品的评价。会话状态是整个上下文结构里最关键、也最容易做烂的一层。很多团队以为把历史消息全部塞给模型就算有上下文了结果token爆炸模型反而被历史噪音干扰。正确做法是维护一个结构化的“会话工作台”实时记录当前需求清单用户明确提出的所有约束条件候选商品列表带价格、特性、来源渠道用户对每个候选的反馈喜欢/不喜欢/犹豫/原因当前正在进行的决策节点选品中 / 对比中 / 待确认下单实际项目中我会在每次对话轮次结束后让模型输出一次结构化的会话状态更新用JSON格式存起来。下一次轮次开始时把最新的结构化状态最近几轮原始对话一起注入。这样做的好处是模型无需从头理解每一轮的历史直接基于结构状态做增量推理既省token又稳定。2.3 实时环境层商品、库存、价格的动态信息第三层是实时环境属于动态上下文包括当前可用的商品池、实时库存状态、价格变动、优惠信息、发货时效、用户所在区域的配送范围等。这一层的特点是变化快、时效性强不能靠缓存必须实时获取。购物代理最致命的问题就是“推荐了买不到的商品”。我之前踩过这个坑用户问“有没有低于2000元的折叠屏手机”代理从商品库里筛了一款价格也合适但用户点进去发现该地区无货。后来我强制要求代理在给出推荐结论之前必须调用库存/可售状态接口校验把不可售商品直接从候选列表剔除。宁可候选少一点也不要给用户看买不了的东西。实时环境层还有一个作用为上下文“校准”。比如用户画像里写了“预算500元以下”但当前聊到某款商品用户主动说“这款如果降到599我就考虑”。这时实时价格触发了预算上限的突破条件代理要能识别这种“画像约束被临时放宽”的状态优先响应当前会话的显式表达而不是机械执行画像规则。3. 实操一个可落地的上下文优先购物代理设计3.1 整体架构与数据流基于我的实践一个上下文优先的购物代理核心模块是四个对话入口、上下文管理器、决策引擎、动作执行器。其中上下文管理器是大脑决策引擎是手脚动作执行器是出口。数据流大概是这样的用户输入自然语言先进入上下文管理器管理器把用户输入与三层上下文组合成“增强输入包”然后传给决策引擎。决策引擎分析用户意图决定这一轮是继续追问、给出推荐还是执行下单。如果需要推荐调用检索/搜索服务获取商品把商品数据回流到上下文管理器更新候选列表再生成推荐文案返回给用户。关键一点检索服务不应该直接暴露给大模型而是要经过上下文管理器“过滤”。过滤规则包括剔除不可售商品、剔除与当前约束冲突的商品、按画像偏好做初排序。这样进入Prompt的商品候选已经是“干净”的模型只需要在有限候选取舍减少幻觉概率。3.2 上下文数据的存储与更新策略存储方面三层上下文我用了不同的存储方案。用户画像和会话状态用Redis带TTL实时环境层不落库靠接口实时拉取。Redis里我用的数据结构很简单用户画像用Hashkey是user_idfield是画像维度会话状态用String存JSON每次更新整体覆盖。更新策略上我遵循三个原则。第一画像层低频更新只在强信号触发时写。第二会话层每轮更新但更新动作放在模型输出结构化状态之后。第三实时环境层不落库每次决策前动态拉取。这套策略在成本和实时性之间取得了比较好的平衡。这里多说一句结构化会话状态的具体格式供参考{ session_id: s_20241201_001, requirements: { category: 降噪耳机, budget_max: 800, brand_preference: [sony, bose], exclusions: [入耳式] }, candidates: [ {id: p1001, name: Sony WH-CH720N, price: 649, feedback: positive}, {id: p1002, name: Bose QC45, price: 1599, feedback: negative_price} ], pending_question: null, stage: comparing }这个JSON就是“会话工作台”每轮结束后更新。下一轮注入Prompt时模型先看这个工作台再结合用户最新输入推理成本很低准确率很高。3.3 Prompt与Agent编排中的上下文注入Prompt设计上我用的不是“一股脑全塞”的方式而是把上下文分段组织明确告诉模型哪些是长期约束、哪些是当前会话状态、哪些是实时数据。我常用的Prompt骨架是这样你是购物助手帮助用户完成商品选购。 【用户画像长期偏好】 - 预算区间500-800元 - 偏好品类数码3C - 价格敏感度高 【当前会话状态】 - 需求降噪耳机预算800内 - 候选Sony WH-CH720N649元用户倾向、Bose QC451599元超预算 - 用户最近反馈觉得Bose太贵 【实时环境】 - 当前可售候选Sony WH-CH720N有货、Bose QC45无货 【用户最新输入】 {user_message} 请基于以上上下文回答。如果用户输入与上下文冲突以用户最新输入为准。注意最后一句“以用户最新输入为准”这是防止上下文“绑架”对话的关键。用户可能临时改变主意代理必须能灵活覆盖既有上下文里的旧约束而不是被画像或会话状态困住。Agent编排上我的经验是把“更新上下文”作为一个独立的Agent动作来看待。每轮对话不是简单把结果返回给用户而是要走“解析意图 → 更新上下文 → 决策 → 执行动作 → 再更新上下文”的闭环。有些框架把这一步做成隐式的但我建议显式做方便排查问题时复盘。4. 常见问题与排查技巧实录4.1 上下文过期与脏数据问题做得越久越发现上下文管理最大的敌人不是模型而是脏数据。用户画像里存了一个月前的收货地址会话状态里残留了上一个需求的筛选条件这些都会让代理“答非所问”。我遇到过最典型的一个case用户之前问过“机械键盘”会话状态里一直挂着“分类键盘”的约束。隔了两天用户重新发起会话问“显示器推荐”由于新会话没清干净旧会话状态代理一直在推键盘。排查后发现是会话状态存储的key没有带session维度新会话误读了旧会话的残值。后来我把所有会话状态key都加上session_id前缀并在会话结束时主动清空或标记过期问题才解决。排查上下文类问题我的建议是先看日志里的“增强输入包”也就是每一轮真正喂给模型的内容。如果模型答得不对先别怀疑模型去看看上下文里有没有过期数据、有没有互相矛盾的约束。很多时候问题就出在上下文垃圾上。4.2 上下文过长导致的模型能力下降有些同学走另一个极端既然要上下文那就把历史消息全部带上越多越好。结果上下文一长模型开始“走神”要么遗忘早期约束要么被无关历史带偏。这里要纠正一个认知大模型的上下文窗口是越来越大了但“窗口够大”不等于“用满就好”。我在实际项目里测过把历史聊天记录全量塞进去的情况下模型对早期约束的遵循率明显下降尤其是历史里有大量重复性内容时。Claude这类模型对超长上下文的处理能力确实强但有明确的研究和实测表明过长的上下文会导致中间信息被稀释这几乎是所有Transformer架构模型的通病。所以上下文的注入要做“减脂”。我说几个实用做法一是历史消息只保留最近3-5轮原始对话更早的压缩成摘要二是关键的约束条件从历史里抽取出来写入结构化会话状态避免模型自己去历史里翻三是上下文注入总量控制在一个合理范围比如不超过模型默认窗口的三分之一给推理留足空间。4.3 查询质量差其实是上下文没喂对还有一种情况很迷惑单独测试某个查询时模型回答完全正常但放到整个对话流程里就出错。这种问题十有八九不是查询本身的问题而是上下文没喂对。举个我实际遇到的例子。用户问“有没有适合跑步戴的耳机”代理调了商品搜索API关键词是“运动耳机”。结果返回的商品里有头戴式的用户明明跑步需要的是入耳式或骨传导。问题出在哪儿不是查询词不对而是上下文里的历史信息没被利用起来——用户早在前一轮说过“我用AirPods Pro跑步总会掉”这是一个强烈的品类偏好信号应该转成检索的过滤条件。解决这个问题的关键是“上下文驱动检索”不是让模型凭空想查询词而是从上下文中提取出结构化的检索条件比如品类、价位、特定功能、排除项然后拿这些条件去检索。这比单纯让模型“理解用户查询然后搜”靠谱得多。我在系统里单独加了一个“检索意图抽取”模块专门从当前会话状态最新用户输入里抽取检索参数效果立竿见影。5. 一些实操经验和后续可扩展的方向做这个项目过程中我有一套自己的排查方法论用户反馈不好的时候先看上下文工程的状态再看检索质量最后才轮到Prompt和模型本身。顺序反了效率极低。上下文是地基地基歪了上面做什么都白搭。另外想分享一个细节上下文的记录不要只记“用户说了什么”还要记“用户没说什么”。沉默本身就是信息。比如用户对推荐的几款商品都不表态只说“再看看”这往往意味着候选没有打动他可能是价格超出预期也可能是风格不匹配。把这些隐性信号也写进会话状态下一轮推荐时果断换策略用户体验会明显提升。如果后续想在这个方向深入我觉得有三个扩展点很值得做。第一是跨会话的长期记忆增强把用户历史购买记录和“售后反馈”纳入画像做到真正懂用户。第二是多模态上下文用户拍照说“帮我找同款”图片信息也要进入上下文体系这对视觉理解模型和上下文工程都提出了更高要求。第三是隐私保护下的上下文压缩如何在记忆用户的同时不记住敏感信息这是一个越早想清楚越好的方向。做AI购物代理这一年多我最大的体会是技术选型、模型调参这些东西都可以通过学习和测试快速补齐难的是建立“上下文优先”的产品思维方式。查询只是水面上的冰山一角上下文才是水面下的庞然大物。谁把水下这部分做扎实了谁才能真正把购物代理做出可用性来。