过去两年里大模型和 Agent 技术的发展让“购物”这件事正在发生一个不太显眼但足够深远的改变用户不再一直是购物链路里的唯一决策者。人们开始把“找商品、比参数、盯价格、查优惠、跟物流”这些耗时动作交给 AI Agent 去做自己只保留最终确认和支付环节。这个变化在技术圈和普通消费者中间同时发生但大家对它的理解往往停留在“AI 帮我把东西买了”的层面这个理解太窄了。这篇文章会从技术角度拆解 AI Agent 购物的真实形态现在有哪些场景已经落地、一个最小可用的购物 Agent 系统由哪些模块组成、如何用 Python 写一个原型以及为什么“全自动下单”还没有成为主流。读完你会得到一张清晰的技术地图也会知道如果要在项目里接入 Agent 购物最应该避开的坑在哪里。1. 一个本质变化购物从“搜索驱动”变成“意图驱动”传统电商购物的主流交互是“人找货”用户打开购物 App输入关键词翻看列表比价看评论最后完成支付。在这个流程里所有决策几乎都靠自己完成。商品页面的展示方式、搜索排序规则、优惠券叠加条件决定了用户能不能在有限时间内找到理想商品。当 Agent 介入购物之后交互关系变了用户负责表达“我想要什么”Agent 负责执行“怎么找到它、怎么比较它、什么时候买它”。比如用户说“我需要一台 4000 元以内、适合写代码的轻薄笔记本”剩下的商品筛选、参数对比、价格跟踪甚至下单动作都由一个程序代理完成。这个转变的本质不是多了一个聊天机器人而是购物链路中的“决策权”开始从人转移到程序。这里说的决策权不是指最终买单的权力而是指“在大量商品和信息中做筛选”的权力。过去这个权力由搜索引擎和推荐算法部分接管现在由 Agent 以更主动、更连续的方式接管。理解这一点很重要。如果你只是让大模型输出几个商品推荐那它和搜索引擎没有本质区别。真正的 Agent 购物是在一个连续的任务里完成多轮检索、判断和执行并且能根据新信息调整动作。这也是为什么 Agent 购物值得单独讨论而不只是“大模型在电商里的应用”。从工程角度看这个转变还带来了一个新问题Agent 需要具备调用外部工具的能力否则它只能“说”不能“做”。这也是为什么现在讨论 Agent 购物总绕不开工具调用、API 对接、权限控制和异常处理这些话题。2. AI Agent 购物到底是什么先抛开“自动下单”这个刻板印象很多人一听“AI Agent 购物”第一反应就是“让 AI 自动下单”。这个理解太窄了而且可能误导产品设计方向。AI Agent 购物的完整定义是让一个具备“理解能力、决策能力和执行能力”的智能体参与购物旅程中的一个或多个环节。购物旅程比大多数人想象的更长至少包括六个环节商品发现根据模糊需求生成准确的结构化查询条件信息收集聚合商品参数、用户评论、价格历史、优惠信息比价与推荐跨平台、跨店铺比较输出有依据的建议决策建议结合预算、评分、返利、售后政策给出最终候选交易执行在符合阈值的情况下自动下单或生成购买链接履约跟踪物流查询、到货提醒、退款申请、售后对话。这六个环节可以全部交给 Agent也可以只交给其中一部分。现实中绝大多数落地方案都不是全自动而是“人机协同”人负责最终确认Agent 负责前期调研人设置规则Agent 按规则执行Agent 做多步操作人在关键节点审核。这里有一个容易被误导的点很多人把“Agent 购物”等同于“全自动机器人代购”。实际上当前技术条件下全自动购物在安全性、合规性和体验稳定性上都还没完全成熟。更主流的做法是“半自动 人工兜底”。为什么会这样因为购物和聊天不同购物涉及真实资金、真实商品、真实售后服务。一个错误理解可能导致用户买到完全不需要的东西而且责任归属很难说清。所以目前的 Agent 购物产品大多把自动化重点放在“决策辅助”和“流程效率”上而不是把最后一步支付权限完全交给程序。对于开发者来说这个定位差异决定了你的系统设计是做“一个会聊天的商品搜索引擎”还是做“一个能跑完整流程的自动化工作流”。前者重点是信息质量后者重点是执行安全和异常兜底。3. 四类正在发生的典型场景为了说清楚“人们正在用 AI Agent 怎么买东西”我按风险和自动化程度把当前场景分成四类。这四类不是虚构的而是真实存在于开源项目、电商工具和企业服务里的典型形态。3.1 价格监控与“等它降价”自动化这是最成熟、也最早出现的一类场景。以前用户需要自己反复刷新商品页面或者使用简单的爬虫脚本判断价格是否降到心理价位。现在可以让 Agent 完成整个闭环输入商品链接设定目标价格Agent 定时抓取价格、库存、优惠券状态价格满足条件时通知用户甚至直接进入结算流程。这类 Agent 的技术核心不是“聊天”而是“定时任务 数据抽取 阈值判断 通知”。在很多开源项目里它通常由一个轻量级任务调度器加一个大模型函数调用组成。大模型的角色是理解用户输入的目标价格和商品条件后续的抓取和判断完全用普通代码实现不需要每次循环都调用大模型。这也是为什么价格监控类工具最容易先落地。它的决策风险很低即使 Agent 判断失误用户看到的只是一个价格提醒不会直接产生资金损失。3.2 复杂需求的信息聚合与筛选这类场景最适合大模型发挥。典型用户需求是“我想买一台洗衣机预算 3000 元要求能洗羊毛衫噪音别太大最好支持 App 遥控。”这种需求涉及商品参数、用户评论、功率、尺寸、售后条款等多个维度。人在翻电商页面时往往要开十几个标签页信息密度低很容易遗漏关键参数。Agent 可以把“商品筛选”变成一个结构化任务从描述中抽取需求参数将参数转成目录查询条件拿到候选商品列表再逐个获取详情、评论摘要、价格走势最终输出一张横向对比表。这里的关键技术不是简单调用搜索 API而是“需求分解”和“信息验证”。LLM 很容易在归纳需求时丢条件或者在评论摘要里加入噪音信息。比如用户说“支持 App 遥控”模型可能把它理解成“支持 Wi-Fi”这两个条件在商品筛选里差别很大。因此工程上要设计一个校验环节把大模型抽取出的结构化条件和原始输入做一次交叉确认。3.3 跨平台比价和返利链路传统的比价网站大多是静态数据聚合。Agent 的优势在于它能“带着上下文”跨平台比价并且在比价完成后继续执行后续动作。例如用户看中一款耳机Agent 可以同时在多个主流电商渠道检索同款识别卖家身份、历史评价、售后政策汇总不同平台的优惠券、满减、返利比例计算实际到手价给出推荐购买渠道并把跳转链接发给用户。这类 Agent 的核心难点是“异构页面解析”和“数据归一化”。不同平台对同一个商品的标题、参数、价格口径不一致。一个平台标“13.3 英寸”另一个平台标“13.3寸”一个平台价格显示“2999 起”另一个显示“券后 2799”。Agent 需要把这些信息标准化才能做横向对比。这比表面看起来复杂得多往往需要维护一套字段映射规则而不是单纯靠自然语言理解。3.4 供应链采购与企业采购自动化B 端场景是目前 AI Agent 购物价值更明确的方向。企业采购往往有固定审批流程、供应商目录、预算上限和合规要求。传统做法是采购员人工询价、填单、走审批。Agent 可以把流程改成接收需求描述、自动从供应商目录中匹配商品、生成采购申请表、发起审批流、审批通过后自动下单、同步财务入账信息。这里涉及的不只是购物而是与企业内部审批系统、ERP、财务系统的深度集成。和 C 端个人购物相比B 端采购的流程更确定、预算更明确、风险管控需求更强所以反而更容易先落地。因为企业采购本身就有审批节点Agent 只是把“填写采购申请”这个环节自动化最后的资金支付仍然由财务系统和审批流程兜底。小结AI Agent 购物并非单一产品形态而是一组“AI 接替重复劳动”的场景集合。当前最容易商业化的是价格监控、信息聚合和 B 端采购辅助这类“低风险、可控”的环节全自动下单在 C 端仍处于谨慎探索阶段。4. 技术架构一个最小 AI 购物 Agent 由哪些模块组成从工程角度看一个最小可用的 AI 购物 Agent 不需要很复杂但必须包含五个核心模块意图理解、商品检索、分析与决策、执行与通知、记忆与偏好。下面逐个拆解。4.1 意图理解模块这个模块负责把用户的自然语言需求转换成结构化查询条件。输入是“3500 以内能烘干的洗衣机”输出是 JSON 格式的查询参数。实际实现时可以让大模型输出一个固定结构的 JSON再通过代码校验字段完整性和取值范围。{ category: 洗衣机, max_price: 3500, properties: { 烘干功能: true }, sort_by: 综合评分 }意图理解模块最容易出问题的点是“条件丢失”和“条件误解”。大模型可能漏掉用户说的“噪音别太大”或者把“支持 App 遥控”误解为“支持 Wi-Fi”。因此这个模块后面必须接一个校验函数把关键条件反馈给用户确认或者把缺失条件标注出来。4.2 商品检索与数据采集模块这个模块对接电商平台的开放 API或者使用合规的第三方数据服务。它的目标是获取候选商品列表而不是自己爬网页。和很多人的直觉不同商品检索模块不应该依赖大模型逐条判断而应该优先使用结构化查询。大模型负责生成查询条件检索模块负责执行查询。开发者需要重点处理的细节包括API 签名、分页、限流、字段映射、错误重试。如果平台接口不提供自动下单能力模块输出应该是一个带参数的购买链接而不是一个支付指令。4.3 分析与决策模块这是 Agent 与普通搜索脚本的核心区别。它负责对候选商品做参数归一化综合评论、评分、价格、品牌、售后等因素进行打分并按用户预算、偏好、购买时间窗口做约束校验最后给出推荐结果并说明理由。这个模块的设计要点是“打分逻辑要透明”。不要让大模型直接输出“我觉得这个好”而应该让模型给出结构化的打分依据价格权重多少、评分权重多少、为什么排除某几个商品。这样用户才能信任推荐结果代码也更容易调试。4.4 执行与通知模块执行模块负责下单、支付或跳转通知模块负责通过 IM、邮件或推送提醒用户。在个人购物场景中执行模块通常不应该直接自动支付而是生成一个带参数的购买链接等待用户确认。在企业采购场景执行模块需要和审批系统联动审批通过后才触发下单。通知模块虽然看起来不起眼却是用户体验的关键。很多 Agent 购物产品做不好问题不在模型能力而在“用户不知道 Agent 正在做什么”。好的通知设计应该把 Agent 的每一步动作都同步给用户正在搜索、找到 3 个候选、价格已经低于目标价、准备生成购买链接。4.5 记忆与偏好模块每次购物的历史记录、用户偏好、退货记录可以存储下来作为下一次推荐的重要上下文。这个模块在 Agent 架构里对应“长期记忆”在具体实现上可以是一个向量数据库加一个会话存储。比如用户之前多次搜索过“静音”类商品下次推荐时就可以自动提高静音参数的权重。需要注意隐私边界。用户没有明确授权的情况下不要把历史订单、支付信息、地址用于训练或第三方分析。记忆模块应该支持随时查看、导出和删除。4.6 一个最小的模块交互流程用户输入 → 意图理解 → 商品检索 → 数据分析 → 决策推荐 → 用户确认 → 执行购买 → 售后跟踪这个流程里每一步都可以接入 LLM但并非每一步都必须用 LLM。工程上更合理的做法是能用规则和普通代码解决的就不用大模型只有意图理解、摘要生成、复杂判断这类任务才调用 LLM。这样既能控制成本又能降低幻觉风险。5. 代码实现构建一个可运行的 AI 购物 Agent 原型为了让概念落得更实下面给出一个 Python 实现的伪原型。它不依赖特定电商平台只演示从用户输入到推荐通知的完整链路。你可以在真实项目中保留同样的模块边界只替换内部实现。5.1 项目结构ai-shopping-agent/ ├── main.py ├── requirements.txt └── agent/ ├── intent.py ├── retrieve.py ├── decision.py └── notify.py5.2 依赖pip install openai pydantic python-dotenv这里使用了openai库调用大模型接口pydantic用于结构化输出校验python-dotenv用于管理 API Key 等环境变量。5.3 意图理解模块# agent/intent.py import json from openai import OpenAI client OpenAI() INTENT_PROMPT 你是购物助手。请把用户的购物需求转换为 JSON 查询条件。 JSON 字段包括category、max_price、min_rating、keywords、extra_requirements。 只输出 JSON不要输出任何其他内容。 def parse_intent(user_text: str) - dict: resp client.chat.completions.create( modelgpt-4o-mini, # 请以实际可用的模型为准 messages[ {role: system, content: INTENT_PROMPT}, {role: user, content: user_text}, ], temperature0.2, ) text resp.choices[0].message.content.strip() return json.loads(text)这段代码的核心是“输出约束”在 Prompt 中要求模型只输出 JSON便于后续直接传给检索模块。但仅仅在 Prompt 里约束还不够模型偶尔仍会输出多余文字或格式错误。实际生产环境建议使用 function calling 或 Pydantic 做更严格的结构化输出校验确保解析失败时可以重试或请求用户澄清。5.4 商品检索模块# agent/retrieve.py from typing import List, Dict def search_products(query: dict) - List[Dict]: 这里通常应该调用电商平台开放 API。 演示时返回模拟数据。 category query.get(category, ) max_price query.get(max_price, 100000) mock_products [ { id: P1001, title: f{category} A 型号, price: 2999, rating: 4.8, score: 92, }, { id: P1002, title: f{category} B 型号, price: 4200, rating: 4.9, score: 88, }, { id: P1003, title: f{category} C 型号, price: 3499, rating: 4.5, score: 80, }, ] result [] for p in mock_products: if p[price] max_price: result.append(p) return result这里故意保留了一个可替换的接口search_products。真实开发时你需要在函数内部实现一个EcommerceClient处理 API 签名、分页、限流和字段映射。很多开发者会在这里直接写爬虫代码但如果是生产环境我更建议优先考虑平台开放 API 或者授权数据服务否则很容易遇到合规和封禁问题。5.5 决策推荐模块# agent/decision.py from typing import List, Dict def make_recommendation(products: List[Dict], user_query: dict) - Dict: if not products: return {reason: 没有符合预算的商品, candidates: []} rated [] for p in products: # 综合得分 平台评分 用户评分加权 - 价格惩罚 # 这里价格越低得分越高 price_penalty p[price] / 100.0 score p[score] p[rating] * 10 - price_penalty rated.append((score, p)) rated.sort(keylambda x: x[0], reverseTrue) best rated[0][1] return { reason: f推荐 {best[title]}价格 {best[price]}评分 {best[rating]}, candidates: [p for _, p in rated[:3]], confirm_required: True, }推荐模块的评分公式可以很简单关键是让每个候选商品都有可解释的得分。这里故意把“价格惩罚”设计成线性关系方便演示实际项目中你可能需要根据商品品类调整价格弹性比如高价值商品的价格权重应该更高避免 Agent 总是推荐最便宜的商品。5.6 通知模块# agent/notify.py def send_notification(message: str) - None: # 生产环境可接入钉钉、企业微信、飞书或短信 print(f[NOTIFY] {message})通知模块在生产环境通常对接 IM 机器人。注意通知消息应该包含足够的上下文比如商品标题、价格、购买链接和推荐理由而不是只发一句“已找到商品”。5.7 主流程# main.py from agent.intent import parse_intent from agent.retrieve import search_products from agent.decision import make_recommendation from agent.notify import send_notification def main(): user_text 我想买一台 3500 以内的洗衣机要支持烘干功能评分别太低 # 1. 意图解析 query parse_intent(user_text) print(解析后的查询条件:, query) # 2. 商品检索 products search_products(query) print(f找到 {len(products)} 个候选商品) # 3. 决策推荐 result make_recommendation(products, query) print(推荐理由:, result[reason]) # 4. 通知用户确认 if result[confirm_required]: send_notification(已生成购物推荐等待用户确认) print(候选:, result[candidates]) if __name__ __main__: main()这段主流程把四个模块串成了一个完整链路。注意最后一步只是通知用户确认并没有自动下单。这是有意为之的设计目的是让原型在默认情况下不产生资金操作风险。5.8 运行与验证python main.py预期输出类似解析后的查询条件: {category: 洗衣机, max_price: 3500, min_rating: 0, keywords: [], extra_requirements: } 找到 2 个候选商品 推荐理由: 推荐 洗衣机 A 型号价格 2999评分 4.8 [NOTIFY] 已生成购物推荐等待用户确认 候选: [{id: P1001, ...}, {id: P1003, ...}]运行结果里最重要的不是推荐了哪款商品而是整个流程是否按预期执行意图解析输出合法 JSON、检索模块按价格过滤、决策模块给出有理由的推荐、通知模块触达用户。你把retrieve.py替换成真实平台 API把notify.py替换成企业微信机器人这个最小原型就可以变成半自动购物助手。6. 为什么“全自动下单”当前还没有成为主流很多人会问既然技术链路能跑通为什么没有看到大规模的全自动购物 Agent这个问题背后藏着 Agent 购物落地的真正难点。6.1 支付安全与风控边界自动支付意味着程序拥有资金操作权限。一旦 Agent 被恶意指令、异常链接或错误解析诱导就可能产生非预期支付。在个人消费场景这是几乎不可接受的。用户能接受 Agent 推荐错了商品但不能接受 Agent 自动扣了款。任何与支付相关的自动动作都必须有最少一层人工确认这是支付安全的基本常识。6.2 平台合规与接口限制主流电商平台对自动化下单通常有严格限制。开放 API 一般只提供商品查询、订单查询能力很少开放自动创建订单的接口。自动下单往往只能通过浏览器自动化的方式实现而这种方式可能违反平台服务条款存在账号封禁风险。这个限制不是技术问题而是平台利益和用户协议的约束Agent 开发者绕不过去。6.3 商品信息的非结构化噪音商品页面的价格、优惠、库存、运费经常在几秒内变化。Agent 基于某个时间点的快照做决策很容易在下单时发现原条件已经失效。比如 Agent 判断“当前价格 2799低于目标价”但用户点开链接时价格已经回到 3299。要解决这个问题Agent 必须具备“下单前实时验真”能力而实时验真又会增加延迟和调用成本。6.4 责任归属难题如果 Agent 买错了责任归谁是用户的指令表达不清楚还是 Agent 理解错了还是平台数据有误还是商品页描述有误导当前法律和平台规则都没有清晰回应这个问题。这也是很多公司不敢贸然推出全自动购物产品的原因。相比之下B 端采购因为有审批流和合同约束责任归属更清晰所以更容易落地。6.5 幻觉和错误工具调用Agent 在做信息摘要时可能“脑补”参数在调用工具时可能选错 API。即使整体准确率做到 99%在购物这种高风险动作上1% 的错误也可能变成严重的售后问题。而且大模型的错误往往是“自信地错”用户很难从输出表面看出问题。这就需要对 Agent 的工具调用结果进行校验而不是完全信任模型输出。结论全自动购物不是“能不能做”的问题而是“安全责任、合规边界、异常处理”三个问题还没有完全解决。当前更务实的路线是让 Agent 完成调研、比价、推荐让用户完成最终确认。随着支付风控系统和 Agent 工具生态的成熟全自动的下单动作会越来越多但短期内不会全面取代人。7. 常见问题与排查思路问题现象可能原因排查方式解决方案意图解析输出不是 JSONPrompt 没有严格约束输出格式打印模型原始输出检查是否有多余文字在 Prompt 中强调“只输出 JSON”或改用 function calling检索结果与需求明显不符检索模块的字段映射错误打印解析后的查询条件检查关键词是否丢失增加字段校验和二次抽取逻辑推荐结果价格超过预算决策模块没有再次过滤超预算商品检查search_products和make_recommendation的过滤逻辑在决策模块重复执行预算校验不依赖上游过滤爬虫获取数据时被平台拦截请求频率过高或请求头特征明显查看日志中的 HTTP 状态码和响应头改用官方 API或降低频率或购买合规数据服务Agent 偶尔推荐已下架商品直接使用了缓存数据检查缓存时间戳和商品 ID 状态对商品 ID 做实时验真自动下单失败页面结构变化或登录态失效查看自动化工具的异常快照增加重试机制和人工接管入口通知消息太晚到达定时任务调度延迟或轮询间隔过长查看任务队列和执行日志缩短轮询间隔或改用事件触发的推送机制这些问题是 Agent 购物开发里最常见的一批。排查时有个通用原则先分清是“模型问题”还是“代码问题”。模型问题通常出在输出格式和语义理解上代码问题通常出在字段映射和状态管理上。先打印中间结果看数据在哪一步开始不合理基本就能定位问题。8. 工程实践建议如果你要在项目里落地 AI 购物 Agent上面的原型只是起点。要在真实项目里落地需要额外考虑安全、成本、稳定性、合规这些工程问题。以下是我认为最值得重视的七条建议。8.1 永远保留“人审”环节无论面向 C 端还是 B 端都不应该设计一条没有用户确认的全自动支付链路。即使你目标是做自动采购也应该把“人审”设计成一个可配置的开关默认开启只有经过充分测试和风控评估后才允许关闭。这里的人审不一定是人工逐单确认也可以是“系统根据规则自动审批 事后抽检”但绝不能完全没有兜底。8.2 把 LLM 调用次数压到最小LLM 调用是有成本、有延迟、有幻觉风险的操作不应该成为 Agent 的主循环。能用规则和代码完成的部分就不要交给大模型。例如价格比较、阈值判断、库存检查、优惠券叠加计算都应该用普通代码实现。大模型只需要参与意图理解、摘要生成、异常情况下的兜底判断。这样既省成本又降低幻觉风险。8.3 设计好“记忆边界”Agent 记录用户偏好时要注意隐私和合规。用户没有明确授权的情况下不要把历史订单、支付信息、地址用于训练或第三方分析。记忆模块应该支持用户查看、导出和删除自己的数据。这一点不只是合规要求也直接影响用户对 Agent 的信任度。8.4 增加输入校验层Agent 接收外部数据时要把它当作不可信输入处理。商品描述、评论、链接这些外部输入如果需要进入 Prompt就有提示注入的风险。攻击者可以通过构造恶意商品描述诱导 Agent 执行非预期动作。工程上要尽量避免把外部原文直接拼进 Prompt最好先做结构化提取只把摘要字段传入模型。这和安全领域的输入过滤是同一个逻辑在购物场景里同样重要。8.5 设置预算阈值和熔断机制在 B 端采购场景建议设置单笔上限、日累计上限、异常交易熔断。Agent 行为一旦超过阈值自动暂停并通知管理员。比如单笔采购超过 1 万元Agent 不能直接提交日累计超过 5 万元系统锁定整个采购流程。这些规则可以用配置文件维护不需要写死在代码里。8.6 做好追踪与审计每次 Agent 执行的关键动作都应该记录输入、推理过程、工具调用、输出结果。问题出现时这些日志是回溯责任和优化模型的唯一依据。实际项目中我建议至少记录四个字段用户 ID、会话 ID、工具名称、输入输出快照。日志不要只记录成功路径失败和重试路径同样重要。8.7 从小切口开始不要一上来就做全自动购物。建议先从“价格提醒”“跨平台比价”“商品参数问答”这类低风险功能切入验证数据来源、模型效果和用户接受度再逐步扩展执行能力。这样即使某个环节出问题也不会直接造成资金损失。Agent 项目最怕的就是在第一版就追求“大而全”结果把高风险动作和低风险功能混在一起出了问题无法排查。9. AI Agent 购物真正考验的是系统设计与信任回到开头的问题人们到底是怎么用 AI Agent 买东⻄的现在可以看到答案不是“让 AI 自动下单”这么简单。有人用 Agent 做价格监控把“等降价”这件事从手动刷新变成自动通知有人用 Agent 做复杂需求筛选把“开十几个标签页比参数”变成一张结构化的对比表有人用 Agent 做企业采购辅助把重复的询价和填单流程自动化。这些应用有一个共同点Agent 接管的不是用户的支付决策而是购物流程里最耗时、最重复的信息处理环节。当前阶段决定一个购物 Agent 项目能不能落地的关键往往不是模型有多聪明而是工程系统有多稳健。数据源是否合规、提示注入是否被防御、异常情况下是否有兜底、日志是否能回溯、用户是否知道 Agent 在做什么这些工程问题比“再换一个更强的大模型”重要得多。如果你正准备做一个 AI 购物 Agent 项目我的建议是先选择一个风险最低的场景比如价格监控或多平台比价把数据链路、校验机制和通知系统跑通再逐步增加自动执行能力。先把“信任”建立起来再谈“自动化”。购物天然是高风险场景任何一个环节出问题损失的都是用户真金白银的信任。下一步值得关注的方向是电商开放平台对 Agent 的 API 适配、购物域的工具调用协议、支付风控系统对 Agent 流量的支持以及端侧小模型在购物轻量化场景的部署。这些基础设施完善之后AI Agent 购物才有机会从“辅助决策”走向更大范围的“流程自动化”。