AI 购物 Agent 最近讨论度很高。说白了它不是一个帮你“讲价”的机器人而是让大模型自己完成购物链条里的信息检索、比价、筛选和下单准备这些动作。有人拿它盯降价有人拿它做跨平台比价也有人把固定商品的补货流程做成每日定时任务。题目里问“How are people using AI agents to buy things”拆开看就是三类事找信息、做判断、执行操作。这篇文章适合三类读者。第一类是普通用户想用现成 Agent 工具提高购物效率第二类是开发者打算自己写脚本或 Agent第三类是电商、供应链、采购相关从业者想判断这个方向能落地到什么程度。最值得先记住的判断是AI 购物 Agent 真正值钱的不是“自动下单”这个最终动作而是前面那串决策链路能不能稳定跑完。下单只是最后一个动作检索、理解商品参数、判断是否匹配预算、识别库存和物流条件这些环节任何一个出错结果都不可用。下面按实际落地顺序拆开讲。1. 先给“AI 购物 Agent”拆分类它在买卖链条里到底做什么1.1 信息收集型盯价、查库存、找优惠这类 Agent 只“看”不“动”。目标是定期访问商品页面或调用开放接口把价格、库存、优惠券状态、发货时间抓回来再用 LLM 汇总成一句话或者一张表。实际例子很多。比如想买某款笔记本但觉得 6999 太贵可以设置一个 6500 的目标价Agent 每 30 分钟检查一次一旦价格低于阈值就把商品链接、当前价格、历史价格趋势一起发到企业微信或者钉钉机器人。这里 LLM 主要负责两件事理解“目标价和当前价的差异”要不要触发提醒以及把页面里混杂的“到手价”“满减后价格”“会员价”换算成同一个口径。这类方案最稳定因为它不涉及交易操作风险低哪怕偶尔抓取失败最多就是漏一次提醒。我一般建议想入门的朋友从这个类型开始。1.2 决策辅助型根据预算、参数和偏好筛选这一类的输出不是“下单”而是“推荐”。把用户需求写成一句话比如“2000 以内、适合程序员长时间打字、最好支持无线和三模连接、不要 RGB 光污染”Agent 先去多个平台搜索再抽取型号、价格、参数、评价关键词最后用 LLM 生成对比表。难点在于商品信息的噪声很大。同一个型号在不同平台可能叫法不同有的标题故意堆关键词有的套餐价格和单机价格混在一起。LLM 如果只看标题很容易把“无键盘版”当成“带键盘版”。我实测时常用的办法是要求 Agent 同时抓取主图 alt 文本、规格参数区域、标题三处信息交叉验证后再进入筛选逻辑。这类 Agent 适合做“购买前的辅助”适合预算有限、要求明确、但不想一个个平台翻页的人。它不替你付款所以边界比较安全。1.3 执行操作型自动下单、预约、定期补货这是最刺激的部分也是最容易踩坑的部分。执行型 Agent 会真正打开购物车、点击结算、选择地址、甚至尝试完成支付前一步。常见场景包括新品预约、限量商品开售、固定商品的每月补货。我对这类场景的建议是先分两段看从“搜索”到“加入购物车”属于相对可控的操作从“结算”到“支付”属于必须人工确认的操作。不是说技术上不能全自动而是支付环节涉及账号安全、资金安全和售后责任一旦流程出错后果远大于“少买一件商品”。如果一定要做执行型建议加一个最终确认环节Agent 生成“将购买以下商品、价格合计为多少、使用哪个地址”的摘要人工确认后才真正提交订单。2. 落地形态对比浏览器自动化、平台 API、本地定时任务2.1 浏览器自动化 Agent适用面最广稳定性最难控这类方案让模型通过工具操作浏览器比如 Playwright、Puppeteer或者具备屏幕理解能力的 Agent 框架。优点是几乎不需要平台授权网页能看就能跑缺点是对页面结构和登录态非常敏感平台改一次页面布局之前写好的选择器可能就全部失效。我在实测里发现浏览器自动化 Agent 更适合“低频、高价值”的任务比如每天晚上检查一次目标商品的价格而不是每秒钟刷一次库存。控制频率能明显降低被平台风控拦截的概率也能减少页面变化带来的连锁问题。另外浏览器自动化一定要保留运行截图。Agent 在页面上做了什么、看到了什么如果没有截图出问题时很难还原。截图目录按任务 ID 和时间戳命名排查效率会高很多。2.2 平台 API 或 OpenAPI稳定但受权限限制如果目标平台提供开放接口比如商品查询、库存查询、价格订阅这类入口优先用。接口返回结构化数据不需要 LLM 去解析混乱的 HTML准确率和稳定性都好很多。代价是接口能做什么完全取决于平台开放了哪些能力。很多平台只开放营销工具或自营商品的查询接口关键的交易操作仍然需要人工在 App 或网页完成。所以 API 方案常见于供应商管理和电商运营而不是个人日常购物。2.3 本地定时任务 LLM 决策最快跑通的组合个人开发者最容易落地的是“定时脚本 LLM 决策”组合。定时脚本负责抓数据LLM 负责理解需求和输出结论两者之间用 JSON 通信。它不需要完整 Agent 框架也不需要多复杂的状态管理。我这里给出一个参考目录结构不依赖任何特定框架shopping_agent/ ├── tasks/ # 每条采购或监控任务的配置 ├── collectors/ # 抓取商品信息的模块 ├── analyzer/ # 调用 LLM 做筛选和比价 ├── notify/ # 推送结果到微信/邮件/Webhook └── logs/ # 每次运行的状态和错误记录这种结构的好处是每个环节都能单独调试不抓数据就去测 LLM 判断不跑 LLM 就去测通知推送出问题时排查范围小。3. 最小可复现方案一个价格监控与采购决策 Agent3.1 需求配置先写好无论用什么框架我建议先写一张任务配置表把输入输出说清楚再写代码。参考结构如下{ task_id: keyboard-2025-06, task_type: price_monitor, target_name: 某品牌机械键盘, keyword: 三模无线机械键盘 68键, budget: 600, target_price: 499, platforms: [platform_a, platform_b], check_interval_minutes: 30, max_runtime_minutes: 10, notify_webhook: https://example.com/hook, human_confirm_before_order: true }这里最关键的字段不是 target_price而是 human_confirm_before_order。它决定了这个 Agent 是“只提醒”还是“主动买”。我建议开发阶段全部置为 true。3.2 核心流程分五步一个最基本的购物 Agent 闭环可以拆成五步需求标准化把用户自然语言整理成任务配置包含目标商品、预算、平台、触发条件。商品检索按关键词到目标平台搜索拿到商品列表。信息抽取从标题、价格、规格、库存、运费等字段里提取结构化数据。条件判断用 LLM 或规则判断哪些商品满足预算、库存和配送条件。结果输出低于目标价则推送提醒或进入人工确认下单流程。代码层面可以先用伪代码跑通主流程def run_once(task): products search_products(task[keyword], task[platforms]) parsed [extract_product(p) for p in products] matched [p for p in parsed if task[target_price] p.price] if matched: notify(build_report(matched)) if task[human_confirm_before_order]: send_confirm_message(build_order_summary(matched[0]))这个版本没有引入多轮 Agent 循环但已经能完成 80% 的监控诉求。后续再考虑 LLM 参与决策也是在这个主流程上替换“条件判断”这一环。3.3 为什么先跑单次再跑定时我见过不少人在第一步就直接上定时任务结果跑了一天后才发现通知链接写错提醒全部发到了测试环境。正确顺序是先手动运行一次确认日志、输出、通知都正常再把它放进定时器最后才考虑加并发和批量任务。单次运行要看三件事有没有拿到真实商品数据、价格字段是不是正确解析、通知有没有按预期推送。这三件事全部确认后再设置 check_interval。3.4 运行资源怎么预估常见环境是云服务器或家里一台常开的电脑Python 3.10 以上或 Node 18 以上都可以。浏览器自动化方案建议至少 2 核 CPU、2GB 内存磁盘 10GB 以上用来放浏览器缓存和日志。如果还需要跑本地大模型显存和内存要求会明显升高个人场景不建议为购物 Agent 单独部署大模型直接调 API 更划算。每次任务耗时取决于平台数量和商品数量。纯接口方案单平台一般在几秒到十几秒浏览器自动化方案一次可能要 30 秒到几分钟。如果任务要求 5 分钟内完成明显超出这个量级就要考虑拆任务或换更稳定的数据源。4. 三个值得先验证的场景4.1 历史比价和降价提醒这是最适合新手验证的场景。要求是对同一个商品 SKU 连续记录价格能输出价格趋势并判断是否达到目标价。验证指标很简单连续 7 天不出现误报价格字段准确率 100%通知延迟不超过 1 分钟。难点是同一商品在不同平台可能有多个等价链接比如套装版、单机版、第三方店铺版。Agent 如果只按名称匹配很容易把不同配置混为一谈。更稳的做法是锁定商品 ID 或标准条码再记录价格。4.2 跨平台比价汇总用户给出一个需求Agent 在多个平台同时搜索并汇总成对比表。这个场景对 LLM 的“归纳能力”要求最高因为各平台的商品命名、参数单位、价格口径都不一样。有些平台显示“到手价”是算完所有优惠后的价格有些平台显示的是“券前价格”直接比大小会误导。我在这个场景里会加一条硬规则所有价格必须先统一口径再交给 LLM 判断。比如把“券后价”“满减价”“会员价”全部换算成“最终需支付金额”并且注明是否含运费。口径没统一之前不要让模型做比较。4.3 固定商品周期补货比如办公耗材、猫粮、日常清洁用品每个月固定购买一次。Agent 做的是提前三天检查库存和价格价格正常就提醒下单价格异常就等两天再看。这个场景看起来简单但最容易忽略的是“上次买的是什么规格”。很多人直接按名称搜索结果买回不同包装导致成本没省反而浪费。建议在任务配置里保存标准商品 ID、历史购买链接和上次单价作为补货判断的基准。5. 结果怎么判断别只看“能不能下单”5.1 成功标准不止一个评价一个购物 Agent 是否合格我建议至少盯五个指标任务完成率多少任务在无人干预下走到了结束状态。误报率提醒用户“降价了”但实际价格没降或商品不对。无效动作率Agent 做了多少次没有意义的点击或查询。单次成本每完成一次监控或比价消耗的接口 token 数。可重复性同一个任务连续运行多次结果是否一致。不要只看“自动下单成功”这一个点。一个经常点错页面但最后侥幸买到的 Agent和一个从不点错但只会提醒的 Agent后者在实际使用中更可靠。5.2 常见失败模式和判断顺序我总结过购物 Agent 最常见的失败类型页面结构变化选择器失效抓不到价格字段。登录态过期之前保存的会话 Cookie 失效。风控拦截频繁刷新或操作特征太像脚本。数据口径错误把“月销量”当成“当前销量”把“原价”当成“实付价”。支付前拦截需要短信验证或人脸验证。排查顺序建议是先看日志和最终输出确认是“没执行”还是“执行错”再看输入配置确认关键词、预算、目标价没有写错然后检查网络和登录态最后才怀疑平台规则和功能边界。5.3 成本与 token 消耗怎么控制购物 Agent 的 token 消耗大头不是最终报告而是中间的商品列表。一个平台返回 30 条商品如果每条都塞进 LLM 上下文一次任务可能就要几千 token。更省的做法是先按标题和价格做规则过滤只把 3 到 5 条候选商品交给 LLM。实测中我发现把商品数量控制在 5 条以内比价质量几乎没有下降但 token 成本可以省掉一半以上。如果场景对成本敏感可以设置单次任务 token 上限达到上限就输出部分结果。6. 常见问题排查清单6.1 抓不到价格或价格一直不变先看是不是反爬拦截返回页面里有没有验证码或访问异常标识。再看选择器是否因为页面改版失效。最后确认目标商品是否缺货或下架很多平台对缺货商品会隐藏价格。排查顺序不要反过来。如果是浏览器自动化截图是排查看板。让 Agent 在每次抓取失败时保留页面截图和当前 URL能省很多时间。6.2 登录态频繁失效购物 Agent 一旦涉及个人账户登录态管理就是核心问题。常见原因包括会话被平台主动踢出、IP 地址变化、登录设备特征变化。更稳的做法是尽量用“游客模式 商品公开信息”完成监控只有到下单阶段才需要登录。如果必须登录不要把账号密码直接写在提示词里更不要明文存在配置文件中。建议通过环境变量或密钥管理工具读取并在运行时脱敏输出。6.3 通知收不到或重复推送通知问题通常不在 Agent而在 Webhook 地址、消息格式和去重逻辑。建议每条任务维护一个 result_hash相同结果只在变化时推送一次。连续收到相同提醒时先检查去重条件是不是被时间戳破坏了。6.4 并发任务互相干扰多个任务同时运行时如果不加锁常常出现 A 任务的查询结果写到 B 任务的输出目录里。建议每个任务使用独立工作目录和独立日志文件任务 ID 作为文件名前缀。先跑 3 个任务并发验证再慢慢加数量。7. 哪些场景不要全部交给 Agent7.1 高金额和售后复杂场景要保留人工确认第一次购买单价较高的商品比如手机、电脑、家电建议 Agent 只负责收集信息和生成下单摘要最终由人确认。不是技术不能实现全自动而是售后环节一旦出现退换货、保修、赠品缺失Agent 很难代替人去沟通和维权。7.2 抢购类任务要谨慎“定时抢购”“整点开抢”这类任务对延迟要求极高而且容易触犯平台规则也容易因为支付环节卡住而失败。这类场景不建议个人开发者用自动化去钻规则空子。如果确实有正常购物需求比如新品预约也应该保持人工最后确认。7.3 遵守平台规则不碰账户安全和违规边界购物 Agent 本质上是在用自动化方式访问网站使用前应该确认目标平台是否允许这类操作。不要用 Agent 去做刷单、批量注册、倒卖优惠券、绕过限购这类行为。合法合规的使用方式是把 Agent 用在公开数据查询、个人购物辅助、企业采购流程数字化这些正常场景。账户安全上建议做到三点账号密码不明文存储、会话 token 定期轮换、支付密码绝不交给脚本。我个人更建议把购物 Agent 当成一个“购物决策辅助系统”来用而不是当成一个“无人值守购物机器人”。先把盯价、比价、查库存这些只读场景跑稳再逐步往执行方向推进。真正成熟的方案往往不是模型多聪明而是任务定义够清楚、日志够完整、失败时有人能把链路接上。踩过几次坑之后我最大的体会是很多购物 Agent 翻车不是模型不会判断而是输入字段没统一、页面结构变了没人发现、登录态过期了没人处理。把这些基础问题解决好比换更强的模型更有效。 AI购物Agent实战：从价格监控到自动下单的完整指南
AI 购物 Agent 最近讨论度很高。说白了它不是一个帮你“讲价”的机器人而是让大模型自己完成购物链条里的信息检索、比价、筛选和下单准备这些动作。有人拿它盯降价有人拿它做跨平台比价也有人把固定商品的补货流程做成每日定时任务。题目里问“How are people using AI agents to buy things”拆开看就是三类事找信息、做判断、执行操作。这篇文章适合三类读者。第一类是普通用户想用现成 Agent 工具提高购物效率第二类是开发者打算自己写脚本或 Agent第三类是电商、供应链、采购相关从业者想判断这个方向能落地到什么程度。最值得先记住的判断是AI 购物 Agent 真正值钱的不是“自动下单”这个最终动作而是前面那串决策链路能不能稳定跑完。下单只是最后一个动作检索、理解商品参数、判断是否匹配预算、识别库存和物流条件这些环节任何一个出错结果都不可用。下面按实际落地顺序拆开讲。1. 先给“AI 购物 Agent”拆分类它在买卖链条里到底做什么1.1 信息收集型盯价、查库存、找优惠这类 Agent 只“看”不“动”。目标是定期访问商品页面或调用开放接口把价格、库存、优惠券状态、发货时间抓回来再用 LLM 汇总成一句话或者一张表。实际例子很多。比如想买某款笔记本但觉得 6999 太贵可以设置一个 6500 的目标价Agent 每 30 分钟检查一次一旦价格低于阈值就把商品链接、当前价格、历史价格趋势一起发到企业微信或者钉钉机器人。这里 LLM 主要负责两件事理解“目标价和当前价的差异”要不要触发提醒以及把页面里混杂的“到手价”“满减后价格”“会员价”换算成同一个口径。这类方案最稳定因为它不涉及交易操作风险低哪怕偶尔抓取失败最多就是漏一次提醒。我一般建议想入门的朋友从这个类型开始。1.2 决策辅助型根据预算、参数和偏好筛选这一类的输出不是“下单”而是“推荐”。把用户需求写成一句话比如“2000 以内、适合程序员长时间打字、最好支持无线和三模连接、不要 RGB 光污染”Agent 先去多个平台搜索再抽取型号、价格、参数、评价关键词最后用 LLM 生成对比表。难点在于商品信息的噪声很大。同一个型号在不同平台可能叫法不同有的标题故意堆关键词有的套餐价格和单机价格混在一起。LLM 如果只看标题很容易把“无键盘版”当成“带键盘版”。我实测时常用的办法是要求 Agent 同时抓取主图 alt 文本、规格参数区域、标题三处信息交叉验证后再进入筛选逻辑。这类 Agent 适合做“购买前的辅助”适合预算有限、要求明确、但不想一个个平台翻页的人。它不替你付款所以边界比较安全。1.3 执行操作型自动下单、预约、定期补货这是最刺激的部分也是最容易踩坑的部分。执行型 Agent 会真正打开购物车、点击结算、选择地址、甚至尝试完成支付前一步。常见场景包括新品预约、限量商品开售、固定商品的每月补货。我对这类场景的建议是先分两段看从“搜索”到“加入购物车”属于相对可控的操作从“结算”到“支付”属于必须人工确认的操作。不是说技术上不能全自动而是支付环节涉及账号安全、资金安全和售后责任一旦流程出错后果远大于“少买一件商品”。如果一定要做执行型建议加一个最终确认环节Agent 生成“将购买以下商品、价格合计为多少、使用哪个地址”的摘要人工确认后才真正提交订单。2. 落地形态对比浏览器自动化、平台 API、本地定时任务2.1 浏览器自动化 Agent适用面最广稳定性最难控这类方案让模型通过工具操作浏览器比如 Playwright、Puppeteer或者具备屏幕理解能力的 Agent 框架。优点是几乎不需要平台授权网页能看就能跑缺点是对页面结构和登录态非常敏感平台改一次页面布局之前写好的选择器可能就全部失效。我在实测里发现浏览器自动化 Agent 更适合“低频、高价值”的任务比如每天晚上检查一次目标商品的价格而不是每秒钟刷一次库存。控制频率能明显降低被平台风控拦截的概率也能减少页面变化带来的连锁问题。另外浏览器自动化一定要保留运行截图。Agent 在页面上做了什么、看到了什么如果没有截图出问题时很难还原。截图目录按任务 ID 和时间戳命名排查效率会高很多。2.2 平台 API 或 OpenAPI稳定但受权限限制如果目标平台提供开放接口比如商品查询、库存查询、价格订阅这类入口优先用。接口返回结构化数据不需要 LLM 去解析混乱的 HTML准确率和稳定性都好很多。代价是接口能做什么完全取决于平台开放了哪些能力。很多平台只开放营销工具或自营商品的查询接口关键的交易操作仍然需要人工在 App 或网页完成。所以 API 方案常见于供应商管理和电商运营而不是个人日常购物。2.3 本地定时任务 LLM 决策最快跑通的组合个人开发者最容易落地的是“定时脚本 LLM 决策”组合。定时脚本负责抓数据LLM 负责理解需求和输出结论两者之间用 JSON 通信。它不需要完整 Agent 框架也不需要多复杂的状态管理。我这里给出一个参考目录结构不依赖任何特定框架shopping_agent/ ├── tasks/ # 每条采购或监控任务的配置 ├── collectors/ # 抓取商品信息的模块 ├── analyzer/ # 调用 LLM 做筛选和比价 ├── notify/ # 推送结果到微信/邮件/Webhook └── logs/ # 每次运行的状态和错误记录这种结构的好处是每个环节都能单独调试不抓数据就去测 LLM 判断不跑 LLM 就去测通知推送出问题时排查范围小。3. 最小可复现方案一个价格监控与采购决策 Agent3.1 需求配置先写好无论用什么框架我建议先写一张任务配置表把输入输出说清楚再写代码。参考结构如下{ task_id: keyboard-2025-06, task_type: price_monitor, target_name: 某品牌机械键盘, keyword: 三模无线机械键盘 68键, budget: 600, target_price: 499, platforms: [platform_a, platform_b], check_interval_minutes: 30, max_runtime_minutes: 10, notify_webhook: https://example.com/hook, human_confirm_before_order: true }这里最关键的字段不是 target_price而是 human_confirm_before_order。它决定了这个 Agent 是“只提醒”还是“主动买”。我建议开发阶段全部置为 true。3.2 核心流程分五步一个最基本的购物 Agent 闭环可以拆成五步需求标准化把用户自然语言整理成任务配置包含目标商品、预算、平台、触发条件。商品检索按关键词到目标平台搜索拿到商品列表。信息抽取从标题、价格、规格、库存、运费等字段里提取结构化数据。条件判断用 LLM 或规则判断哪些商品满足预算、库存和配送条件。结果输出低于目标价则推送提醒或进入人工确认下单流程。代码层面可以先用伪代码跑通主流程def run_once(task): products search_products(task[keyword], task[platforms]) parsed [extract_product(p) for p in products] matched [p for p in parsed if task[target_price] p.price] if matched: notify(build_report(matched)) if task[human_confirm_before_order]: send_confirm_message(build_order_summary(matched[0]))这个版本没有引入多轮 Agent 循环但已经能完成 80% 的监控诉求。后续再考虑 LLM 参与决策也是在这个主流程上替换“条件判断”这一环。3.3 为什么先跑单次再跑定时我见过不少人在第一步就直接上定时任务结果跑了一天后才发现通知链接写错提醒全部发到了测试环境。正确顺序是先手动运行一次确认日志、输出、通知都正常再把它放进定时器最后才考虑加并发和批量任务。单次运行要看三件事有没有拿到真实商品数据、价格字段是不是正确解析、通知有没有按预期推送。这三件事全部确认后再设置 check_interval。3.4 运行资源怎么预估常见环境是云服务器或家里一台常开的电脑Python 3.10 以上或 Node 18 以上都可以。浏览器自动化方案建议至少 2 核 CPU、2GB 内存磁盘 10GB 以上用来放浏览器缓存和日志。如果还需要跑本地大模型显存和内存要求会明显升高个人场景不建议为购物 Agent 单独部署大模型直接调 API 更划算。每次任务耗时取决于平台数量和商品数量。纯接口方案单平台一般在几秒到十几秒浏览器自动化方案一次可能要 30 秒到几分钟。如果任务要求 5 分钟内完成明显超出这个量级就要考虑拆任务或换更稳定的数据源。4. 三个值得先验证的场景4.1 历史比价和降价提醒这是最适合新手验证的场景。要求是对同一个商品 SKU 连续记录价格能输出价格趋势并判断是否达到目标价。验证指标很简单连续 7 天不出现误报价格字段准确率 100%通知延迟不超过 1 分钟。难点是同一商品在不同平台可能有多个等价链接比如套装版、单机版、第三方店铺版。Agent 如果只按名称匹配很容易把不同配置混为一谈。更稳的做法是锁定商品 ID 或标准条码再记录价格。4.2 跨平台比价汇总用户给出一个需求Agent 在多个平台同时搜索并汇总成对比表。这个场景对 LLM 的“归纳能力”要求最高因为各平台的商品命名、参数单位、价格口径都不一样。有些平台显示“到手价”是算完所有优惠后的价格有些平台显示的是“券前价格”直接比大小会误导。我在这个场景里会加一条硬规则所有价格必须先统一口径再交给 LLM 判断。比如把“券后价”“满减价”“会员价”全部换算成“最终需支付金额”并且注明是否含运费。口径没统一之前不要让模型做比较。4.3 固定商品周期补货比如办公耗材、猫粮、日常清洁用品每个月固定购买一次。Agent 做的是提前三天检查库存和价格价格正常就提醒下单价格异常就等两天再看。这个场景看起来简单但最容易忽略的是“上次买的是什么规格”。很多人直接按名称搜索结果买回不同包装导致成本没省反而浪费。建议在任务配置里保存标准商品 ID、历史购买链接和上次单价作为补货判断的基准。5. 结果怎么判断别只看“能不能下单”5.1 成功标准不止一个评价一个购物 Agent 是否合格我建议至少盯五个指标任务完成率多少任务在无人干预下走到了结束状态。误报率提醒用户“降价了”但实际价格没降或商品不对。无效动作率Agent 做了多少次没有意义的点击或查询。单次成本每完成一次监控或比价消耗的接口 token 数。可重复性同一个任务连续运行多次结果是否一致。不要只看“自动下单成功”这一个点。一个经常点错页面但最后侥幸买到的 Agent和一个从不点错但只会提醒的 Agent后者在实际使用中更可靠。5.2 常见失败模式和判断顺序我总结过购物 Agent 最常见的失败类型页面结构变化选择器失效抓不到价格字段。登录态过期之前保存的会话 Cookie 失效。风控拦截频繁刷新或操作特征太像脚本。数据口径错误把“月销量”当成“当前销量”把“原价”当成“实付价”。支付前拦截需要短信验证或人脸验证。排查顺序建议是先看日志和最终输出确认是“没执行”还是“执行错”再看输入配置确认关键词、预算、目标价没有写错然后检查网络和登录态最后才怀疑平台规则和功能边界。5.3 成本与 token 消耗怎么控制购物 Agent 的 token 消耗大头不是最终报告而是中间的商品列表。一个平台返回 30 条商品如果每条都塞进 LLM 上下文一次任务可能就要几千 token。更省的做法是先按标题和价格做规则过滤只把 3 到 5 条候选商品交给 LLM。实测中我发现把商品数量控制在 5 条以内比价质量几乎没有下降但 token 成本可以省掉一半以上。如果场景对成本敏感可以设置单次任务 token 上限达到上限就输出部分结果。6. 常见问题排查清单6.1 抓不到价格或价格一直不变先看是不是反爬拦截返回页面里有没有验证码或访问异常标识。再看选择器是否因为页面改版失效。最后确认目标商品是否缺货或下架很多平台对缺货商品会隐藏价格。排查顺序不要反过来。如果是浏览器自动化截图是排查看板。让 Agent 在每次抓取失败时保留页面截图和当前 URL能省很多时间。6.2 登录态频繁失效购物 Agent 一旦涉及个人账户登录态管理就是核心问题。常见原因包括会话被平台主动踢出、IP 地址变化、登录设备特征变化。更稳的做法是尽量用“游客模式 商品公开信息”完成监控只有到下单阶段才需要登录。如果必须登录不要把账号密码直接写在提示词里更不要明文存在配置文件中。建议通过环境变量或密钥管理工具读取并在运行时脱敏输出。6.3 通知收不到或重复推送通知问题通常不在 Agent而在 Webhook 地址、消息格式和去重逻辑。建议每条任务维护一个 result_hash相同结果只在变化时推送一次。连续收到相同提醒时先检查去重条件是不是被时间戳破坏了。6.4 并发任务互相干扰多个任务同时运行时如果不加锁常常出现 A 任务的查询结果写到 B 任务的输出目录里。建议每个任务使用独立工作目录和独立日志文件任务 ID 作为文件名前缀。先跑 3 个任务并发验证再慢慢加数量。7. 哪些场景不要全部交给 Agent7.1 高金额和售后复杂场景要保留人工确认第一次购买单价较高的商品比如手机、电脑、家电建议 Agent 只负责收集信息和生成下单摘要最终由人确认。不是技术不能实现全自动而是售后环节一旦出现退换货、保修、赠品缺失Agent 很难代替人去沟通和维权。7.2 抢购类任务要谨慎“定时抢购”“整点开抢”这类任务对延迟要求极高而且容易触犯平台规则也容易因为支付环节卡住而失败。这类场景不建议个人开发者用自动化去钻规则空子。如果确实有正常购物需求比如新品预约也应该保持人工最后确认。7.3 遵守平台规则不碰账户安全和违规边界购物 Agent 本质上是在用自动化方式访问网站使用前应该确认目标平台是否允许这类操作。不要用 Agent 去做刷单、批量注册、倒卖优惠券、绕过限购这类行为。合法合规的使用方式是把 Agent 用在公开数据查询、个人购物辅助、企业采购流程数字化这些正常场景。账户安全上建议做到三点账号密码不明文存储、会话 token 定期轮换、支付密码绝不交给脚本。我个人更建议把购物 Agent 当成一个“购物决策辅助系统”来用而不是当成一个“无人值守购物机器人”。先把盯价、比价、查库存这些只读场景跑稳再逐步往执行方向推进。真正成熟的方案往往不是模型多聪明而是任务定义够清楚、日志够完整、失败时有人能把链路接上。踩过几次坑之后我最大的体会是很多购物 Agent 翻车不是模型不会判断而是输入字段没统一、页面结构变了没人发现、登录态过期了没人处理。把这些基础问题解决好比换更强的模型更有效。