做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里我用的数据结构很简单：用户画像用Hash，key是user_id，field是画像维度；会话状态用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-CH720N（649元，用户倾向）、Bose QC45（1599元，超预算） - 用户最近反馈：觉得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购物代理这一年多，我最大的体会是：技术选型、模型调参这些东西，都可以通过学习和测试快速补齐，难的是建立“上下文优先”的产品思维方式。查询只是水面上的冰山一角，上下文才是水面下的庞然大物。谁把水下这部分做扎实了，谁才能真正把购物代理做出可用性来。
