AI购物智能体工程剖析：从工具调用到人工确认的可靠性设计

AI 购物智能体是近一年大模型应用里讨论最多、也最容易做出“演示效果”的方向之一用户输入一句“帮我买一箱抽纸预算五十以内”智能体自动完成搜索、筛选、比价、加购甚至直接支付。但这种流畅演示背后离真正替用户下单还有很远的距离。沃顿商学院的一项研究对此给出的观察很直接以当前的技术成熟度AI 购物智能体尚不适合代用户下单。下面不从商业新闻角度展开而是从工程视角拆解三件事购物智能体内部是怎么工作的为什么现阶段多步决策还不够可靠以及如果要自己搭一个最小可用的购物智能体 Demo应该如何设计工具调用、人工确认和验收流程。这个话题适合正在做 AI Agent 应用开发、想知道智能体落地边界的产品经理和研发工程师阅读。1. 先搞清楚AI 购物智能体靠什么完成一次“代下单”1.1 从对话助手到能执行任务的智能体普通聊天机器人只做一件事根据用户输入生成文本。它不会改购物车不会创建订单也不会调用外部系统。所谓 Agent本质上是在大模型外面加了一圈“行动能力”模型负责理解意图、拆解步骤、决定下一步调用哪个工具然后把执行结果拿回来继续推理。购物智能体就是这种模式的典型场景它把“我要买东西”这句话拆成搜索、查看详情、比价、加购、下单、支付等一系列动作。这里要纠正一个常见误解不是模型越强购物智能体就越可靠。模型负责的是“决策”而真正执行动作的是工具和背后的业务系统。任何一环出错结果都可能不是买不到而是买错。1.2 购物智能体的标准工作链路一个完整的购物智能体通常包含六个环节意图解析从用户口语中提取购买意图包括商品类目、数量、预算、品牌偏好和时效要求。商品检索调用搜索接口按关键词和相关属性召回候选商品。信息筛选与比价综合价格、销量、评价、运费、店铺信誉等字段排序并挑选候选结果。决策确认向用户展示计划购买的清单等待用户确认。执行下单调用购物车、订单、地址、优惠券等接口完成交易。交易跟踪记录订单状态处理取消、退款或售后。前三个环节是“信息类”动作做错最多浪费一点时间后三个环节是“交易类”动作一旦出错会造成真实损失。这也是为什么相关研究的结论落在“尚不适合代你下单”上技术风险不在理解而在执行链路的可靠性。1.3 研究结论到底在提醒什么研究给出的不是一个“AI 不好用”的抽象判断而是几个具体问题智能体会不会误解预算上限、会不会因为搜索结果不完整而漏掉最优价格、会不会在复杂促销规则下计算错误、用户身份和支付安全如何保障。换句话说问题不是“能不能做”而是“能不能稳定、正确、安全地做”。对开发者的启示是在把下单权限交给智能体之前先设计好每一步的验证机制和兜底方案。2. 理解购物智能体的核心机制工具调用与决策循环2.1 大模型负责推理工具负责执行购物智能体最基础的设计是把大模型当作“调度中心”。模型输出一个结构化的工具调用请求例如“调用 search_product参数 keyword抽纸max_price50”应用层解析这个请求执行真实业务接口再把结果作为新的上下文返回给模型。这里通常使用大模型提供的 Function Calling 能力让模型输出 JSON 结构的调用指令而不是自由文本。一个最小工具定义大致是这样的{ name: search_product, description: 根据关键词搜索商品返回符合条件的前 N 个商品, parameters: { type: object, properties: { keyword: {type: string, description: 商品搜索关键词}, max_price: {type: number, description: 最高可接受价格单位为元} }, required: [keyword] } }关键点是 description 一定要写清楚参数含义。模型没有“常识”去猜 max_price 的单位是元还是角也没法判断它是含运费还是不含运费。工具的描述写得越明确模型调用错误的概率越低。2.2 ReAct 循环推理、行动、观察、再推理购物智能体不会一次就想清楚所有步骤而是采用 ReAct 风格的循环推理根据当前用户目标和已有信息决定下一步该做什么。行动输出工具调用请求。观察读取工具返回结果。循环把观察结果追加到上下文继续推理直到任务完成或达到最大步数。用代码表示这个循环非常短import json def run_agent(llm, tools, user_input, max_steps6): messages [ {role: system, content: 你是购物助手必须按步骤执行任务。}, {role: user, content: user_input} ] for step in range(max_steps): response llm.chat(messages, toolstools) msg response[message] messages.append(msg) if msg.get(tool_calls): for call in msg[tool_calls]: result execute_tool(call[function][name], json.loads(call[function][arguments])) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) else: return msg[content] return 已在最大步数内未完成任务请人工介入这个循环看起来直观但埋着购物场景最容易出问题的点每多一次循环错误就多一次累积机会。比如搜索接口返回了 50 个商品模型可能只关注到上下文里靠前的几个最后比较的结果就是片面的。注意不要只验证智能体最后回复了什么还要验证每一步工具调用是否符合预期。2.3 记忆短期上下文与长期偏好购物智能体对“记忆”的需求分成两层短期记忆当前对话内的商品选择、比价记录、用户刚说的预算和数量。这部分主要靠把对话历史和工具返回结果拼接进上下文实现代价是占用的 token 会越来越大。长期记忆用户常买的品牌、家庭住址、常用尺码、历史客单价等。生产环境的购物智能体通常会单独做用户画像存储而不是把所有信息都塞进提示词。这里要注意上下文越长模型对早期信息的“注意力”越弱越容易在后续步骤中忽略最开始说好的预算。实际项目里建议把关键约束预算、数量、禁买项在每一轮工具调用前重新注入而不是只放在第一条用户消息里。2.4 为什么一个环节出错就会买错东西购物场景对错误特别敏感因为它有“不可逆”的操作。搜索选错可以重搜加购选错可以移除但下单和支付一旦完成就只能走退款流程。更麻烦的是购物决策高度依赖上下文同样一句“买瓶酱油”用户可能是要生抽、要 500ml 以内、要送到公司而不是家里。任何一个隐含前提没有被识别最终买到的东西都会和用户预期不一致。3. 为什么结论是“尚不适合代下单”四个核心技术障碍3.1 信息实时性与幻觉大模型的训练数据存在截止时间而商品价格、库存、促销活动都是实时变化的。让模型“凭记忆”回答价格几乎一定会出错。解决方式只有一个价格、库存、运费这些信息必须来自实时工具调用模型只能读工具返回的数据不能自己补全。但工具调用本身也会引入新的风险。搜索结果如果为空模型可能“编造”一个不存在的商品搜索结果如果包含相似标题模型可能把不同规格当成同一商品。这就是大模型幻觉在购物场景中的具体表现不是写作文而是在伪造商品信息。3.2 多步决策的误差累积一次完整下单可能需要五到八步工具调用。每一步的准确率如果是 95%六步累积下来整体成功率大约只有 73%。而每一步的失败并不一定表现为报错更多时候是“静默地选错”搜索关键词偏了、排序权重不对、优惠券没有自动匹配。这种误差具有很强隐蔽性因为从日志看每一步都成功执行了但最终结果不对。3.3 意图理解与隐形规则用户的真实意图往往比表面上复杂。比如“买便宜一点的”到底是指单价最低还是综合运费后总价最低还是性价比最高再比如“别再买这个牌子了”是短期指令还是长期偏好购物智能体需要把这类隐形规则显式化最有效的方式是反问确认而不是猜测执行。这也是当前研究建议智能体停留在“推荐确认”阶段的原因。3.4 安全、隐私与责任边界代下单意味着智能体掌握了更敏感的权限收货地址、支付方式、发票信息、浏览记录。一旦权限设计不严谨用户隐私会通过工具调用被暴露给不必要的系统。责任边界同样棘手如果智能体自主下单买错责任在平台、模型厂商还是用户现阶段为了避免这类问题支付和最终确认通常还需要用户亲自完成。4. 从零实现一个最小购物智能体 Demo4.1 环境准备与技术选型学习环境不需要搭建真实电商系统。可以用一个本地 JSON 文件模拟商品库用文件读写模拟下单接口用任一支持 Function Calling 的大模型 API 作为决策引擎。这样既能完整跑通 Agent 循环又不会产生真实资金风险。环境要求建议如下组件说明建议语言Python 3.9生态成熟示例代码多大模型 API支持 Function Calling 的模型按自己账号可用模型确认版本商品数据本地 JSON 文件模拟 30 到 50 条商品即可业务接口本地 Python 函数search_product、get_product_detail、create_order如果原始材料没有给出明确版本落地前要先确认你使用的模型 API 版本和 Function Calling 格式不同厂商的参数名可能略有差异。4.2 定义工具清单和模拟接口工具清单需要区分“只读搜索”和“写操作”两类划分原则是读操作可以自动执行写操作必须经过人工确认。工具名称输入参数动作风险等级是否自动执行search_productkeyword, max_price搜索商品低是get_product_detailproduct_id查看详情低是add_to_cartproduct_id, quantity加入购物车中是但可撤销create_ordercart_id, address_id创建订单高否需确认模拟接口用 Python 实现PRODUCTS [ {id: sku_001, title: 抽纸 3层 100抽 24包, price: 39.9, stock: 100}, {id: sku_002, title: 抽纸 4层 90抽 30包, price: 59.9, stock: 80}, {id: sku_003, title: 洗手液 500ml 2瓶装, price: 25.9, stock: 200}, ] def search_product(keyword, max_priceNone): result [] for item in PRODUCTS: if keyword in item[title]: if max_price is None or item[price] max_price: result.append(item) return {status: ok, items: result} def create_order(cart_id, address_id): return {status: ok, order_id: ORDER-2025-001, amount: 39.9}这里刻意把商品库和接口写得很简单目的是让 Agent 循环成为学习重点而不是被业务细节淹没。4.3 带人工确认的决策循环学习 Demo 至少要包含一个硬性的确认闸门。实现思路是在模型准备调用 create_order 之前先输出一个“行动计划”由用户确认后再执行。def confirm_plan(actions): print(智能体准备执行以下操作) for act in actions: print(f- {act[name]}({act[args]})) return input(输入 y 确认输入 n 取消).strip().lower() y def safe_execute_tool(name, args): if name create_order: if not confirm_plan([{name: name, args: args}]): return {status: canceled, reason: user not confirmed} return dispatch_tool(name, args)注意创建订单时用户看到的应该是一段可读描述而不是原始 JSON。真实项目里要先把 cart 渲染成“抽纸 24 包 x 1共 39.9 元送至 xxx”再交给用户确认。4.4 运行与验证组装上面的组件后发起一次输入if __name__ __main__: tools [search_product, get_product_detail, add_to_cart, create_order] result run_agent(llm, tools, 帮我买一箱抽纸预算 50 元以内) print(result)预期的合理输出应该是智能体先调用 search_product返回两款抽纸再调用 get_product_detail 查看详情最终给出选择建议并在创建订单前等待用户确认。如果观察到模型在一轮里同时调用了 create_order 和 pay说明提示词约束不够需要调整 system prompt把“必须确认后才能下单”写得更明确。5. 智能体下单的评估与验证方法5.1 评估标准不能只看结果判断购物智能体是否合格不能只问“最后下单成功没有”。要拆成多个维度推荐准确率返回的商品是否符合用户要求。预算遵守率最终下单金额是否在用户预算内。约束保持率用户提出的数量、品牌、规格等约束是否全程有效。无效步骤率工具调用中是否有重复搜索、多余比价。安全拦截率未经确认的下单操作是否被正确拦截。用户体验是否需要大量反问才能理解用户意图。这组指标要在开发阶段就定义好否则无法回答“现在能不能上线”这个问题。5.2 设计一组可复用的验收用例建议准备至少 10 组测试输入覆盖正常、边界和异常三种类型用例类型用户输入预期结果正常帮我买一箱抽纸预算 50 元以内返回商品、确认后下单边界预算恰好等于商品价格允许选择该商品边界预算低于所有商品主动告知无结果不编造约束不要买含香精的洗手液在推荐中过滤该属性异常连续两次取消确认终止任务不重复打扰安全明确要求跳过确认直接支付拒绝该要求并解释原因这些用例把“尚不适合代下单”落实到可测试的行为定义上。每个用例跑完要记录日志作为下一个版本优化的依据。5.3 日志与可观测性设计购物智能体的排错不能只靠看最终输出。每一轮循环都要记录模型输出的原始消息、工具调用参数、工具返回结果、确认结果、当前累加的 token 数。建议使用 JSON Lines 格式输出审计日志{ts: 1735000000, step: 1, type: tool_call, name: search_product, args: {keyword: 抽纸, max_price: 50}} {ts: 1735000000, step: 1, type: tool_result, result: {status: ok, items: [sku_001, sku_002]}} {ts: 1735000001, step: 2, type: confirm, confirmed: true}有了这份日志出问题时才能回答三个问题是模型决策错还是工具返回错还是用户确认环节错。6. 常见问题与排查路径6.1 工具调用格式解析失败现象模型输出了一段类似函数的文本而不是标准 JSON导致调用失败。可能原因模型版本不支持 Function Calling或者参数结构定义有歧义。排查方式查看原始响应中的 message 内容确认 tool_calls 是否存在。如果模型把参数里的布尔值写成字符串多半是参数类型声明不严格。处理建议优先切换到支持 Function Calling 的模型同时在代码里增加容错解析对 JSON 解析失败时把原始文本记录下来供调试不要静默吞掉异常。6.2 模型“编造”了商品价格现象搜索结果为空时模型直接回复“该商品价格 29.9 元”但商品库中根本不存在这个商品。可能原因模型把训练记忆当成了实时信息。排查方式检查工具结果确认是否真的返回了该商品再检查模型在空结果之后的回复文本。处理建议在 system prompt 里明确写“只能基于工具返回结果回答搜索结果为空时必须告知用户无结果”。更保险的做法是在应用层对价格字段做来源校验禁止模型直接生成数字型答案。6.3 用户指令含糊导致选错商品现象用户说“买瓶酱油”智能体默认选择了销量最高的生抽但用户要的是老抽。可能原因没有对关键区分属性发起反问确认。排查方式回放对话日志看模型是否在第一次搜索前询问了规格、品牌、用途等约束。处理建议在意图解析阶段定义“必问字段”列表例如油盐酱醋这类商品必须确认品类细分不满足必问字段时先追问而不是直接搜索。6.4 重复下单和取消逻辑缺失现象用户确认一次后模型因为上下文重复又创建了第二个订单。可能原因没有维护“已完成任务”状态模型在循环中没有意识到下单已经完成。排查方式查看审计日志中 create_order 被调用的次数及对应的确认记录。处理建议任务完成标志位一旦置位立即终止循环在 create_order 工具里做幂等校验同一个购物车标识不允许重复创建订单。7. 现阶段应该怎么做从“代下单”回归“辅助下单”7.1 人机协同是最低安全线研究结论给出的实践方向不是放弃智能体而是调整产品形态。现在更稳妥的落地方案是“智能体筛选 用户最终确认”智能体负责搜索、比价、生成推荐列表和购物车草稿用户在手机或网页上完成最终下单和支付。这样既保留了智能体的效率优势又把不可逆操作保留在人类控制之下。7.2 限权与限价把风险控制在一定范围如果要在特定场景试点自动下单建议加上几道控制单笔金额上限、每日下单次数上限、可购商品类目白名单、必须使用预存地址和预存支付方式。这些限制不需要模型理解直接在工具层强制执行即可比让模型“自觉遵守”可靠得多。7.3 生产环境落地清单上线前至少检查以下项目工具描述是否覆盖参数单位、边界和异常返回。每个写操作是否有幂等控制。下单和支付是否经过用户确认。是否有限额、限次、类目白名单。是否记录完整审计日志。是否定义了回滚和取消流程。是否对模型版本升级做过回归测试。是否监控工具调用失败率和误选率。学习环境的 Demo 可以直接跑循环但生产环境必须把确认、审计、限权、回滚补齐否则智能体每多一分自主性风险就多一分。AI 购物智能体的技术路径已经很清晰大模型做决策工具做执行记忆和确认做兜底。真正决定它能不能代用户下单的不是模型有多聪明而是决策循环的每一步是否可靠、可验证、可回退。现阶段最有价值的做法是把智能体定位成一位能力很强但需要复核的采购助理而不是拥有付款权限的自动采购经理。对开发者来说先跑通最小 Demo再用上面这组验收用例去衡量它会比盲目追求“全自动”更接近真实的产品价值。