AI Agent购物工作流：从需求解析到人工审批的架构设计

前一阵子，我试着用AI Agent处理每周的日用品采购。我跟它约定的规则很简单：只能在固定的几个电商平台里搜索，单价超过50元的商品必须等我确认，默认选择有“自营”标识和7天无理由退货的链接。第一次测试结果还算像样，它把“抽纸、洗洁精、垃圾袋”都找齐了，价格也控制在预算内。但第二次它开始出问题：把“无糖乌龙茶”理解成“无蔗糖乌龙茶”，列了一堆其实含糖的饮品进来。那一刻我突然意识到，让AI Agent买东西，难点从来不是“会不会搜索”，而是“它是否真的理解了你要什么，并且在不越界的情况下完成闭环”。

这个观察也直接决定了文章的走向：AI Agent购物真正值得讨论的，不是“能不能自动下单”，而是“怎么把一个充满模糊语义、价格波动、售后风险和资金安全问题的日常动作，变成一个可定义、可校验、可复用的工作流”。

1. AI Agent购物真正要解决的不是“自动下单”

很多人一听到“AI Agent购物”，第一反应就是“让AI替我把单下了”。这个想象很自然，但它恰恰把问题定义窄了。如果只是替人下单，那比价插件、历史订单自动重购、优惠券助手早就做到了，不需要Agent。AI Agent进入购物场景，真正改变的是“决策前那段信息处理过程”。

1.1 购物流程里，真正值得自动化的是信息处理

一次完整的购物可以拆成六个环节：需求理解、信息搜索、比价与筛选、决策、下单、售后。

后两个环节，下单和售后，反而最不适合完全交给Agent。下单涉及支付密码、账号安全、资金权限；售后涉及退货、纠纷、客服沟通，这些环节一旦出错，补救成本远高于省下的那点时间。

真正适合自动化的是前四个环节里大量重复、耗时的信息处理：

• 需求理解：把“买个办公用的显示器”转换成“27英寸、4K、Type-C接口、预算2000元以内”。
• 信息搜索：在多个平台之间检索商品、价格、评价、库存。
• 比价与筛选：按预算、品牌偏好、历史价格区间、优惠条件做初步过滤。
• 决策：在符合约束的候选项里给出推荐，附上理由。

这些环节恰恰是过去最难自动化的，因为每个平台的页面结构不同，商品描述格式不统一，而且“什么值得买”是一个非常个人化的标准。Agent能切入的，就是把“人肉搜索、人肉比价、人肉判断”变成“模型理解自然语言、调用工具获取信息、用规则和偏好做过滤”。

1.2 为什么过去很难做出一个可靠的“购物Agent”

如果说“搜索-比价-决策”的需求一直存在，为什么直到最近才开始有人认真做？因为过去缺少三个条件。

第一，模型能“理解上下文”了。传统爬虫和规则引擎可以把商品标题、价格抓下来，但很难理解“无糖”和“无蔗糖”的区别，也很难处理“办公用的显示器”这种口语化表达。大模型让需求解析从“字段匹配”变成了“语义理解”。

第二，模型能“调用工具”了。一个Agent不再是只能聊天，它可以在收到指令后去调用搜索接口、读网页、查库存、调起支付确认页。这种工具调用能力把自然语言与真实世界动作连接了起来。

第三，API和开放平台更成熟了。不少电商平台提供商品搜索、店铺信息、物流查询等开放接口，虽然不是所有数据都开放，但已经足够构建一个最小可用的Agent原型。

但这三个条件也带来一个隐患：模型能力越强，错误看起来越可信。过去一个脚本写错规则，你会马上发现；现在一个Agent用流利的自然语言给出一个错误推荐，你会下意识信任它。

2. 一个最小可用购物Agent，至少要有这四层

我见过不少同学第一次尝试做购物Agent，直接写一个循环：调用大模型，让模型输出“商品名称”，然后去执行。这样的原型能跑，但大概率会在第三次调用时莫名其妙下单一个错误商品。

更稳妥的做法，是把Agent拆成四个角色层。每一层只做一件事，并且有明确的输出格式。

2.1 需求解析层：把口语变成结构化查询条件

这一层的输入是用户的自然语言，输出是一份结构化查询参数。比如“帮我买一台适合写代码的显示器，预算尽量控制在2000以内，不要曲面屏”，解析层应该输出：

{ "category": "显示器", "keywords": ["写代码", "护眼"], "min_size": 24, "max_price": 2000, "exclude": ["曲面屏"], "preferred_brand": [] }

关键点不是模型有多聪明，而是要求它必须输出JSON，并且对不确定的字段标注“unknown”。如果模型不确定“写代码”具体需要什么参数，就不要硬编造一个刷新率要求，而是把这个字段留给用户确认。

这一步容易忽略的是“排除条件”。很多购物Agent只做正向匹配，忽略了“不要什么”。比如“不要曲面屏”“不要光污染”“不要杂牌”，这些负向条件如果不单独提取，就很容易在筛选阶段被吞掉。

2.2 信息检索层：让Agent只从可信数据源里拿事实

信息检索层负责调用搜索API、商品接口或页面解析工具。它的核心职责是“获取候选商品列表”，而不是“生成商品列表”。

这两者的区别非常重要。如果模型直接生成商品信息，那么它极有可能产生幻觉，给你编造一个看起来完全合理但根本不存在的商品。在购物场景里，这个错误是不可接受的。

因此，检索层至少要满足三个要求：

1. 每一个返回的商品，必须有商品ID、标题、价格、图片、链接等结构化字段。
2. 数据来源必须是接口或可验证的页面，不能是模型“回忆”出来的内容。
3. 如果某个平台搜索接口失败，不能跳过，也不能编造结果，而是要记录错误，进入重试或转人工流程。

def search_products(query: dict, platform: str) -> list[dict]: # 这里对接平台的开放搜索接口或合规数据源 # 返回内容必须包含唯一商品ID、标题、价格、库存状态 result = platform_api.search( category=query["category"], keywords=query["keywords"], max_price=query["max_price"], exclude=query["exclude"], ) return result.get("items", [])

这段代码只是示例结构，具体接口名和参数取决于你对接的平台。重点在于：检索层的输出，是后续所有判断的事实基础。

2.3 决策判断层：用规则约束模型的选择空间

检索层拿到了商品列表，接下来要让Agent从中做推荐。这一层最容易犯的错，是把所有决策都丢给模型，让它在几十个商品里“凭感觉”挑一个。

更稳妥的做法是两步走：

第一步，用硬规则过滤。比如超过预算、排除条件命中、不包邮、库存不足，这些都应该用代码过滤，而不是让模型判断。硬规则不会幻觉，误判率是0。

第二步，把剩余候选商品的结构化信息交给模型，让它在“已经符合硬约束”的范围内做排序或解释。模型不需要记住所有商品，只需要根据你提供的上下文做判断。这样可以大幅降低幻觉风险。

def recommend(candidates: list[dict], rules: dict) -> list[dict]: filtered = [] for item in candidates: if item["price"] > rules["max_price"]: continue if any(w in item["title"] for w in rules["exclude"]): continue filtered.append(item) # 这里再把 filtered 交给大模型，做排序和理由说明 return filtered

2.4 人工审批层：把下单这个动作留在安全边界内

Agent可以搜索、比价、推荐，但在支付之前，必须保留一个人工确认点。这不是技术保守，而是风险控制的基本常识。

具体做法是：Agent把最终推荐结果整理成一张卡片，包含商品名称、价格、店铺、链接、推荐理由，然后通过IM工具或邮件发给用户。用户点击确认后，Agent才继续执行下单动作。

def request_approval(cart: dict) -> bool: # 发送审批消息给用户 send_approval_message(cart) # 等待用户确认，超时则取消 result = wait_for_user_response(timeout=10 * 60) return result == "approved"

如果没有这一层，任何一个小小的问题，比如价格单位理解错误、商品规格识别错误，都会直接变成真实损失。人工审批不是效率的敌人，它是在Agent还不够可靠时，保护用户信任的缓冲垫。

3. 从零搭一个购物Agent的实操路径

前面讲的是架构原则，这一节给出一个可以照着跑的路径。目标不是给你一套完整生产代码，而是让你理解一个最小闭环需要哪些东西，以及每一步怎么验证。

3.1 环境准备：模型API、工具函数和数据库

你需要准备四样基础环境：

• Python 3.10 以上。
• 一个大模型API的访问权限，用来做需求解析、推荐解释和校验。
• 一个日志存储，SQLite就够，记录每一次调用、搜索、推荐和审批结果。
• 一个可以真实访问的商品数据源，建议选择自己日常购物的平台，如果它有开放API优先用API；没有API，就准备一份静态商品清单用于测试，生产环境再对接合规的数据服务。

安装依赖的常见写法：

pip install openai pydantic fastapi sqlalchemy

这里不限定具体的模型服务商。只要你使用的大模型API兼容OpenAI格式，后面代码基本可以直接复用。记得把API Key放到环境变量里，不要写死在代码中。

3.2 让模型输出结构化的购物决策

不要直接问模型“你想买什么”，而是让它填空。用Pydantic定义输出结构，迫使模型返回字段完整的JSON。

from pydantic import BaseModel from typing import Optional class PurchaseDecision(BaseModel): product_id: str product_name: str price: float reason: str confidence: float needs_approval: bool

这里有一个关键设计：needs_approval字段。当模型发现商品价格接近预算上限、店铺评分较低或规格模糊时，可以主动标记需要人工确认。把“要不要问人”这个判断交给Agent，比让Agent硬着头皮做决定更符合实际场景。

3.3 加入人工确认和回滚机制

实际开发中，审批不只是一个按钮，还要考虑回滚。比如用户点击确认后，Agent去下单，但下单接口返回库存不足，这时候Agent应该能重新搜索替代商品，而不是把错误抛给用户。

我的建议是写一个execute_order函数，它只负责调用下单接口，并且把每一步记录到日志。如果下单失败，立刻进入“无单”状态，并通知用户重新确认。

def execute_order(decision: PurchaseDecision) -> str: # 记录下单开始 logger.info(f"start order: {decision.product_id}") try: order_id = platform_api.create_order(decision.product_id) logger.info(f"order success: {order_id}") return order_id except Exception as e: logger.error(f"order failed: {e}") raise

日志里至少要包含：决策快照、审批人、执行时间、接口返回结果。这样一旦出了问题，你可以知道Agent当时看到了什么数据、为什么推荐这个商品、用户是在什么状态下确认的。

3.4 先跑一个小样本验证闭环

刚搭建完不要立刻去跑真实订单。先用10条测试需求跑闭环，每条需求分别对应正常、边界、冲突三种情况。

举几个例子：

• 正常：预算2000元以内，27英寸4K显示器。
• 边界：预算刚好等于某商品价格，是否允许超出。
• 冲突：既要求“大牌”又要求“最低价”，模型如何解释取舍。

跑完小样本后，重点看两件事：

1. 有多少次请求最终转入了人工审批。
2. 人工审批的转化率是不是太高。

如果10次里有8次都需要你确认，说明规则写得太保守，Agent没有起到提效作用。如果10次里只有1次需要确认，可能是规则太激进，未来存在买错风险。理想状态是，常规需求自动通过，复杂或模糊需求才进入人工环节。

4. 不要低估AI幻觉，购物场景里它就是“买错东西”

在普通聊天里，AI幻觉最多是让回答看起来有点假。但在购物场景里，幻觉等于直接经济损失。“编造一个不存在的商品推荐给你”和“抢茅台脚本”完全是两回事，前者是技术缺陷，后者是违规行为，我们只讨论前者。幻觉不解决，Agent就永远只能停在“玩具”阶段。

4.1 最危险的幻觉不是编造事实，而是编造“看起来合理”的商品

一个常见幻觉案例是，Agent搜索到了某个品牌的产品，但模型在总结时把“500ml”写成了“1L”，原因可能是训练数据里有很多同品牌的1L装，模型自动补全了不存在的规格。还有更隐蔽的：模型把用户评论里的“一般般”理解成“好评”，然后推荐给用户。

这些问题的共同点是，模型不是没有数据，而是在表达时过度自信。它宁可让它的话听起来流畅，也不愿意停下来承认“我不知道”。购物场景需要的是“宁可问一句，不要说错一句”。

缓解幻觉不能靠提示词，要靠强制约束：

• 要求模型所有商品事实都从检索结果中提取，禁止在最终回答里新增商品属性。
• 给模型一个“不确认字段”的选项，让它能输出unknown。
• 在推荐结果中要求附上数据来源ID，用户或系统可以反查。

4.2 用结构化验证对抗幻觉

一个更稳妥的做法，是把Agent的输出拆成“可验证的部分”和“需解释的部分”。

可验证的部分包括商品ID、标题、价格、库存、店铺名，这些必须和检索结果完全一致。可以用代码做字段对齐，不一致就直接拒绝推荐。

需解释的部分包括推荐理由、优缺点、适用场景，这些可以使用模型生成，但要标明是“模型解释”，不是商品事实。

def validate_decision(decision: PurchaseDecision, search_item: dict) -> bool: if decision.product_id != search_item["product_id"]: return False if abs(decision.price - search_item["price"]) > 0.01: return False return True

这一步只用代码，不做任何AI判断。它能挡住大部分“编造商品”和“价格写错”类幻觉。

4.3 一份可以落地的排查链路

如果你发现Agent买错了东西，不要急着改提示词。按顺序排查看：

1. 先看输入：原始需求是否被正确解析。比如“无糖乌龙茶”是否被解析成了“无蔗糖”。
2. 再看检索结果：搜索接口返回的是否包含错误的商品，还是模型在接口之外自己“脑补”了商品。
3. 再看过滤规则：排除条件是否生效，价格上限是否被绕过。
4. 再看推荐输出：模型是否重新表述了商品信息，导致和原始字段不一致。
5. 最后看审批环节：人工确认时，展示给用户的信息是否完整，用户是否被错误信息误导了。

大部分问题不会同时发生在所有环节，它们往往集中在某一个具体环节。排查链路的意义，就是让你不要在Agent隔空输出的“真相”上花时间。

注意：一旦发现推荐结果与检索结果不一致，优先怀疑“模型改写信息”，而不是“接口数据错误”。

5. 工程化：从单个任务到长期可用的购物工作流

很多Agent原型能跑通，但用两周就放弃了。原因是只处理了“单次任务”，没有处理“长期运行”会遇到的成本和稳定性问题。

5.1 成本和token管理：别让Agent帮你“花两份钱”

购物Agent的隐性成本不只是商品价格，还有API调用成本。如果每轮购物都要把一个长达几十条的商品列表塞进上下文，让模型逐条解释，token会快速上涨。

我的建议是：

• 在检索层做一次粗过滤，只把符合硬性条件的候选商品传给模型。
• 对推荐结果做缓存，同一个需求在1小时内不要重复调用模型。
• 设置单次任务最大调用次数，防止Agent陷入循环。

比如一个需求可以这样控制：搜索环节最多3次，模型解释环节最多2次，任何一次超时都转人工。这样即使某个接口出现问题，Agent也会停下来，而不是无限重试。

5.2 日志、审计与可解释性：买错了也能知道为什么

长期使用购物Agent，最重要的不是它每次都很聪明，而是当它做错时，你能通过日志确认是哪个环节出了问题。所以日志中至少要记录：

• 原始需求。
• 解析后的结构化参数。
• 每次搜索的请求和返回。
• 过滤规则命中情况。
• 推荐结果快照。
• 审批状态（通过、拒绝、超时）。
• 下单接口返回。
• 用户投诉或修改记录。

这些日志不仅能帮助你修复问题，还能让你的Agent随着时间迭代。如果连续多次出现同一类错误，说明对应的规则或数据源需要更新。

5.3 适合与不适合的边界

AI Agent购物适合怎么用、不适合怎么用，需要在长期使用前想清楚。

适合的场景通常有这些特征：

• 决策标准明确，比如预算、品牌、规格。
• 商品信息结构化程度较高，比如日用品、3C配件、图书。
• 价格波动不是核心因素，或者你愿意接受略微溢价换时间。
• 售后风险可控，即使买错了，退货成本也不高。

不适合的场景包括：

• 需要实物体验的商品，比如衣服、鞋子、家具。
• 价格实时波动很大，且对价格极其敏感的交易。
• 涉及大额支付、金融产品或需要身份核验的场景。
• 商品描述模糊、规格复杂、售后争议频发的品类。

把边界想清楚，比把Agent调得更聪明更重要。因为Agent再聪明，也无法替你去试穿一件衣服。

6. 我的判断：AI Agent会重塑购物，但不是你想象的那种重塑

最后说一点更长远的判断。很多人把AI Agent购物看成“科幻小说里的自动化管家”，但我的感受是，它更接近“一个能陪你理性的采购助理”。它不会替你消费，也不会替你冲动，但它能帮你把决策前的路径压缩到很短。

6.1 改变的是决策支持方式，不是支付方式

支付方式短期内不会被颠覆，账户安全、资金授权、售后纠纷都是严肃的社会工程问题。Agent更可能的角色，是把购物链路里的“搜索、比价、信息整理、初筛”全部前置，让人只做两件事：提出需求、确认最终结果。

这种改变对一个普通用户的影响是：花在购物上的时间不再和“货比三家”强相关，而是和“会不会定义需求”强相关。

6.2 使用者的核心能力正在变成“定义约束”和“检查输出”

将来使用AI Agent购物的效率差距，可能不取决于你会不会写代码，而取决于你能否把模糊的需求说清楚。比如“给我买个味道淡一点的洗发水”，这不算一个好的约束条件。更可执行的需求是“无硅油、适合油性头皮、价格在70元以内、不要某品牌”。

与此同时，用户也要学会“检查输出”。Agent给你的推荐卡片，不再只是一份“建议”，而是一份“需要你审核的合同”。你需要快速判断：它是不是超出了预算？它是不是误解了规格？它给的理由是否有数据支撑？

6.3 接下来值得关注的问题

购物Agent接下来会不会普及，关键不在模型推理能力，而在三件事：

• 商品数据的开放程度。
• 支付审批与用户授权流程的标准化程度。
• 失败追责机制。

一个能够稳定运行、出错了也能清晰归因的Agent，才配得上进入真实购物流程。否则，它更适合停留在“帮我查一下哪个平台更便宜”这个阶段。

回到我开头那个“无糖乌龙茶”的例子。如果当时Agent在输出“无蔗糖乌龙茶”之前，先标一句“我不确定这个品牌是否满足‘无糖’定义”，然后停下来问我，我并不会觉得它笨，反而会觉得它可靠。这可能是购物Agent最值得追求的方向：不是每次猜对，而是每次知道自己什么时候不该猜。