Agentic Commerce 这个词最近热度不低。它被描述成 AI 电商的下一个形态用户给一个指令Agent 自己完成比价、选品、下单甚至处理售后退款。听起来很完整但现实是这个概念从 2023 年开始酝酿到现在仍然没有出现真正规模化的消费级应用。业内讨论已经从“Agent 能不能做电商”转向了“为什么 Agent 做了很久还是没跑起来”。这篇文章尝试拆解原因从技术可靠性、推理成本、平台生态、安全合规和用户体验五个维度给出一个可复用的评估框架。如果你正准备做 Agentic Commerce 方向的产品或技术方案这篇文章重点回答几个问题当前 Agent 在电商场景的真实可靠度有多少一次完整购物任务大概要消耗多少推理资源平台和生态为什么是硬约束以及从哪个切入点更容易落地。1. Agentic Commerce 核心概念与能力速览先对齐概念。Agentic Commerce 可以理解为由 AI 智能体Agent驱动或高度参与的电商交易流程。与传统推荐系统的区别在于传统推荐只负责“展示”最终下单、支付、售后仍然由人在 App 或网页里完成Agentic Commerce 则希望 Agent 直接完成“决策-操作-履约”闭环。维度现状说明概念定义用户以自然语言提出购物目标Agent 自主完成搜索、比价、挑选、下单、支付、售后等环节底层技术大语言模型LLM、工具调用 / Function Calling、浏览器自动化、电商平台 API、支付与风控系统典型入口智能购物助手、浏览器插件、聊天机器人、手机系统级助理当前成熟度已具备 Demo 和封闭场景落地能力距离大规模 C 端普及仍有明显差距核心瓶颈多步任务成功率、推理成本、平台开放性、责任归属、用户信任均未完全解决适合先行尝试者垂直电商、B 端采购、跨境比价、企业内部采购流程自动化这里需要强调一点Agentic Commerce 并不是单一产品而是一整套技术栈的组合。很多团队把精力放在“模型能不能理解指令”上但真正卡住规模化的是模型之外的工程问题包括任务链路设计、平台适配、成本控制和用户干预机制。2. 为什么 Agentic Commerce 被看好价值点在哪先讲价值再讲问题否则容易把 Agentic Commerce 一棍子打死。首先是降低用户的比价和操作成本。传统购物需要用户自己开多个页面、反复切换比价Agent 可以把这个过程压缩成一句指令。其次是处理重复性购买需求比如每周购买固定品类的生活用品或者某个消费品出现降价时自动提醒或自动下单。再次是多平台聚合能力理论上 Agent 可以同时对接多个电商平台、多个物流渠道、多个支付方式这种能力用传统 API 集成的方式做成本要高得多。最后是企业采购场景企业内采购申请、比价、审批、下单这一长链路Agent 可以在内部系统里串起来减少大量人工流转。从需求侧看这些场景确实存在。但“存在需求”和“能落地”之间还隔着技术可靠性、成本经济性和生态准入三道坎。下面逐项拆解这也是本文的核心内容。3. Agentic Commerce 的参考技术架构在讨论失败原因之前先明确 Agentic Commerce 在工程上到底需要哪些环节。这决定了我们评估成本和风险时应该看什么。一个典型的 Agentic Commerce 流程可以分成四层。3.1 感知层感知层负责获取购物目标相关信息。输入可以是用户文本指令、历史订单、收藏夹、价格快照。输出是结构化的任务描述例如“找出预算 500 元以内、销量最高的 3 款蓝牙耳机并对比它们的运费和售后政策”。这一层相对简单但要注意隐私问题访问历史订单和收藏夹属于敏感数据必须要让用户明确知道数据用途。3.2 决策层决策层是 Agent 的核心。它通常由一个或多个 LLM 调用组成负责把任务拆解成子任务并选择调用哪些工具。常见的子任务包括关键词生成与改写搜索结果排序与过滤商品详情页信息抽取价格、评价、物流等多源信息比对是否触发下单行为的判断支付前的最终确认。决策层的质量很大程度上取决于模型对工具调用格式的遵循能力。目前不同模型在 Function Calling 的标准上并不完全一致有的模型返回 JSON 格式稳定有的模型偶尔会把参数名改掉这会导致下游工具调用直接失败。工程上通常会在这一层加一层 schema 校验和重试机制。3.3 执行层执行层负责把决策变成真实操作。具体技术方案有三类官方 API调用电商平台开放接口优点是稳定、合规缺点是覆盖平台少、权限受限浏览器自动化通过 Playwright、Puppeteer 等工具模拟用户操作优点是覆盖所有网页缺点是脆弱、易被风控、需要持续维护原生集成在封闭的 App / 小程序环境里嵌入 Agent比如超级 App 自己做购物助手。3.4 系统层系统层包括记忆存储、订单状态追踪、支付通道、风控策略、售后工单接口。Agent 在这层面临的最大问题不是模型能力而是不同系统之间的协议不一致。支付接口要签名物流接口要轮询售后工单要人工审核每个环节都有自己独立的对账逻辑。下面给出一段简化版的 Agentic 购物流程伪代码用来表达这个链路到底在做什么# Agentic Commerce 购物流程简化示例伪代码 async def agentic_shopping_flow(user_goal: str, budget: float): # 1. 意图解析 intent await llm.parse_intent(user_goal) # 例如 {action: compare, category: bluetooth_earphone, keywords: 500元以内} # 2. 跨平台检索 candidates [] for platform in data_sources: items await platform_search(intent.keywords) candidates.extend(items) # 3. 信息抽取与结构化 normalized await llm.extract_attributes(candidates) # 4. 排序与决策 final_choice await llm.compare_and_select(normalized, budget) # 5. 下单前置确认必须由用户触发 if final_choice.confidence 0.9: return need_user_confirmation, final_choice return ready_to_checkout, final_choice # 注意支付、地址、优惠券等敏感操作必须显式二次授权从这段流程可以看出Agent 在单次任务中至少需要经历 4 到 6 轮 LLM 调用如果中途出错还要重试。这就直接引出成本与可靠性问题。4. 瓶颈一多步任务成功率与延迟Agentic Commerce 没有大规模跑起来最主要的直接原因是多步任务的成功率做不到令人放心。在演示视频里Agent 搜索、比价、下单一气呵成。但在复杂真实场景中每一步都可能出错关键词改写后召回的商品变了价格抓取时页面渲染不完整优惠券计算逻辑被理解错商品库存状态在点击时已经变化。任何一步出错最终结果就可能与用户目标不一致。这里有一个经常被低估的指标端到端成功率。如果单步成功率是 95%一个 5 步任务的端到端成功率大约是 77%如果单步成功率是 90%端到端成功率就掉到 59%。而真实电商任务往往不止 5 步。# 端到端成功率估算逻辑数字仅为演示计算逻辑 def e2e_success_rate(single_step_rate: float, steps: int) - float: return round(single_step_rate ** steps * 100, 1) # 假设单步成功率 0.95任务 6 步 print(e2e_success_rate(0.95, 6)) # 约 73.5% # 如果单步成功率只有 0.9 print(e2e_success_rate(0.9, 6)) # 约 53.1%这个计算是抽象的但道理很清楚Agent 购物链路越长系统级可靠性要求越高。单纯调大模型不能完全解决这个问题因为很多错误发生在执行层页面 DOM 结构变了、登录态过期了、平台风控要求验证码了。这些都不是 LLM 自己能兜住的。另一个问题是延迟。一次完整购物决策涉及多轮模型调用在大模型响应需要 2 到 5 秒的情况下完整流程可能超过 30 秒。用户如果等一次比价要 30 秒体验上几乎不可能和人工打开两个页面比价竞争。这对用户体验是致命的。从工程角度看提高成功率的手段通常包括三类一是把大任务拆成可独立验证的小任务每完成一步就做一次结构化校验二是对失败步骤做针对性重试但必须限制重试次数避免陷入死循环三是在关键决策点引入人工确认牺牲一部分自动化程度换取可靠性。5. 瓶颈二推理成本与 token 膨胀第二个硬约束是成本。Agent 任务的 token 消耗远高于普通问答。一次购物任务产生的 token 主要包括系统提示词、用户目标、工具返回的搜索结果、商品详情页抽取内容、Agent 的中间推理过程、最终回复。而商品详情页内容又特别长多平台聚合会把输入 token 撑得很大。从公开讨论看一次复杂 Agent 任务的 token 消耗可能是普通对话的 10 到 50 倍。我们需要把单价、上下文长度和任务频次代入才能估算实际成本。# 成本估算模板单价仅用于演示计算逻辑请替换为真实报价 token_price_per_million 20 # 假设输入 1M token 20 元 avg_tokens_per_task 500_000 # 假设单任务 50 万 token monthly_tasks 10000 total_tokens avg_tokens_per_task * monthly_tasks total_cost total_tokens / 1_000_000 * token_price_per_million print(f月度 token 成本约: {total_cost:.2f} 元)如果做一个千人级日活的小产品看起来还能接受但如果目标是百万级日活推理成本和客服兜底成本叠加后毛利模型会很紧张。因此目前看到的 Agentic Commerce 产品大多采用三种降本策略用较小模型处理子任务只让大模型做关键决策大量缓存搜索结果和商品结构化信息避免重复抓取限制工具调用次数和最大步数任务复杂度超过阈值时转人工。还需要说明模型价格在快速下降但任务的 token 量也在快速膨胀两头赛跑。成本问题短期内不会消失只会从“完全不能做”变成“特定高毛利品类可以做”。如果目标品类是客单价低、毛利薄的日用品Agent 的推理成本占比会显得特别高只有客单价高、决策链路长的品类才能撑起这部分成本。6. 瓶颈三平台生态与开放性问题Agentic Commerce 迟迟没有起量还有一个容易被低估的原因是平台生态不配合。大电商平台的核心壁垒是用户和交易数据、物流网络、商家生态。Agent 如果绕过平台自己聚合多源信息平台不仅没有收益还会担心流量被截胡、价格体系被打乱、售后责任变得模糊。因此平台普遍的态度是有限开放甚至在网页端增加风控措施。这导致第三方 Agent 只能用浏览器自动化去适配而这种方式非常脆弱。浏览器自动化的脆弱点在于页面结构和前端框架一变选择器就作废登录态和风控验证码经常出现高频操作容易被限流或封禁售后、退款、发票等环节很难用自动化稳定完成。更现实的路径是电商平台自建 Agent。平台自己掌握数据和交易闭环可以给 Agent 开放更高的权限。比如超级 App 内置的智能助手能直接帮用户完成下单和售后。这种模式落地阻力比较小但它不是第三方 Agent 的机会而是平台自身 AI 能力的延伸。所以 Agentic Commerce 的生态格局很清晰第三方想做聚合卡在准入和风控平台自己做又缺乏动力把能力开放给外部。这导致大量团队只能在信息层做一些比价和推荐真正有价值的交易闭环反而很难被外部触及。7. 瓶颈四安全合规与责任归属电商交易不是单纯的信息检索它涉及资金、个人隐私、地址、支付授权等敏感数据。Agent 一旦参与交易闭环必须解决几个以前没有的问题。第一是支付授权问题。Agent 代表用户下单或支付时用户是否对每次支付都有明确的知情和授权长期授权后用户算不算被诱导消费目前业界的通用做法是金额超过阈值或首次下单必须人工二次确认但这又削弱了“全自动”的体验削弱了 Agentic Commerce 的核心卖点。第二是隐私与数据合规问题。Agent 要访问历史订单、地址本、支付方式可能还需要读取邮箱或短信来追踪物流。这些都属于高度敏感的个人信息。产品方案需要明确数据存储位置、访问边界、撤回授权机制这在大规模用户场景下会显著增加合规成本。第三是责任归属问题。Agent 选品失误、价格抓取错误、自动下单买错商品责任算谁是用户授权失误、Agent 开发者、还是调用的大模型厂商这些责任链路在现阶段并没有统一的行业标准。法律上缺乏明确判例也导致很多稳健型企业在采购和商用上持观望态度。合规建议也很明确对于涉及支付、地址、个人信息的操作系统必须保留完整的审计日志并给用户提供随时人工介入和撤回授权的入口。涉及人脸、声音、肖像等敏感信息时更要注意授权范围。Agent 的决策过程建议做可视化展示让用户知道 Agent 基于哪些信息做出推荐不能只给一个结论。8. 瓶颈五用户体验与信任门槛除了技术、成本和生态还有一个相对软性但很关键的因素用户信任。用户使用传统电商时虽然流程繁琐但每一步都是自己操作的心里有掌控感。Agent 购物则相当于把所有决策交给黑盒。商品被换掉了、价格比自己看到的高、推荐理由说不清楚用户就会立刻失去信任。Agentic Commerce 产品需要解释自己的决策依据这需要额外的可解释性设计。当前一个比较稳妥的产品形态是“半自动推荐 人工确认”。Agent 先给出推荐结果与比价报告用户确认后才进入支付流程。这样 Agent 负责处理信息密度最高的环节人负责最终决策。这个形态牺牲了一部分“自动驾驶”的想象力但换来了真实可用性。另一个被忽视的问题是长尾场景。真实购物需求远不止“买一台手机”还包括赠品计算、优惠券叠加、会员积分、运费险、保修政策、以旧换新等大量规则。对 Agent 来说这些规则每一个都需要单独建模和持续更新。这也是为什么 Agentic Commerce 的落地速度慢于其他 AI Agent 应用方向。9. 当前可行的切入路径尽管距离大规模 C 端普及还有差距Agentic Commerce 并不是完全没有机会。更合理的判断是它正在从“通用购物助手”转向“垂直场景工具”。建议从这几个方向切入。9.1 垂直品类的信息聚合与比价不碰交易闭环只做信息层。比如针对 3C 数码、装机配件、跨境商品Agent 可以稳定完成参数抽取、比价、库存提醒。这类任务本身没有支付风险单步成功率可以做到更高即使出错用户的损失也不大。9.2 B 端采购流程自动化企业内部采购流程长、商品相对标准、对稳定性的要求高于灵活性。Agent 在企业内部系统先做采购申请、审批、订单分发等流程自动化比直接面向 C 端消费更有价值。企业更愿意配置预算也更容易绑定场景。9.3 平台自身的高频回购助手高频、标品、低客单价场景更适合 Agent。比如生活用品定期补货、宠物粮食复购、办公耗材采购。用户只需要设置一次规则Agent 按规则执行和提醒配合短信或 App 推送做确认就能形成相对可靠的服务。9.4 半自动导购 Agent先做导购不做闭环交易。输出比价报告、推荐理由、优惠券状态用户点击链接后跳转到原平台完成支付。这种模式可以避免支付合规问题也更容易获得平台侧的合作空间。10. 给开发者的落地实践建议如果你已经在做 Agentic Commerce 相关项目以下实践建议可以直接用。先建立任务成功率评估体系。每次任务记录步骤数、重试次数、失败原因、用户反馈用真实数据驱动模型和工具优化。控制 token 成本。对高频场景做缓存对商品详情页做结构化抽取减少大模型重复扫描全文。设置最大步数和超时时间。任务超过阈值就转人工确认避免 Agent 在错误链路里反复横跳。付款、地址、发票等敏感操作必须二次确认。这是合规底线也是产品底线。做好浏览器自动化的失败预案。页面结构变化时要有备用选择器、降级提示和人工介入通道。保存完整审计日志。包括输入指令、Agent 决策过程、工具调用结果、人工修正记录。这是后期排查和追责的依据。先做垂直场景再做横向平台。不要一开始就承诺“全平台比价 自动下单”。下面是一个简单的任务配置示例可供搭建评估框架时参考{ task_type: price_comparison, max_steps: 8, max_tokens_per_step: 60000, timeout_seconds: 60, require_manual_confirm: true, sensitive_operations: [checkout, payment, address_change], retry: { max_retries: 2, backoff_seconds: 5 }, logging: { trace_enabled: true, log_path: /var/log/agentic_commerce/ } }11. 常见误判与排查思路在落地 Agentic Commerce 的过程中常见的误判有以下几类。把这些整理成排查思路有利于团队少走弯路。现象误判原因正确排查思路对应解决方案Demo 跑通但生产环境频繁失败只测了理想路径增加异常路径测试和页面结构变化监测扩展工具链加入失败回退和人工兜底任务成功率始终上不去认为是模型能力不够拆解失败步骤区分是决策错误还是执行错误优先修复执行层比如稳定选择器、登录态管理整体成本过高认为是模型涨价统计 token 分布找主要消耗点对搜索和详情页做缓存小模型承担子任务用户不愿意长期授权认为是推广不足检查授权流程是否复杂、是否缺少解释改成半自动模式降低信任门槛平台封禁或限制认为是反爬对抗问题评估合规接入路径改用官方 API 或与平台合作避免在风险边缘试探售后问题无人处理认为是 Agent 流程不完整检查是否缺少售后智能体接口预留工单系统、人工客服、退款处理入口特别提醒不要试图用绕过风控、规避平台限制的方式实现自动化。这类做法既不稳定也有法律风险。Agentic Commerce 的长期价值应当建立在合规集成和用户授权的前提下。开发阶段建议先用测试账号、测试商品和模拟支付环境验证流程不要直接拿真实账号做自动化下单实验。12. 总结与下一步观察点Agentic Commerce 没跑起来不是概念错了而是技术可靠性和商业闭环还没有同时到位。现阶段最值得尝试的方向是信息层的聚合比价、B 端内部流程自动化和半自动导购而不是一步到位做全链路自动下单。如果你正在评估或开发这个方向建议最先做三件事给任务画一张步骤数和成功率的统计表把 token 消耗分布摸清楚把付款前的人工确认流程产品化。这三件事会决定一个 Agentic Commerce 项目能否从 Demo 走向可运营。值得继续观察的变量是电商平台开放 Agent 接口的进度、大模型推理成本下降速度和端到端 Agent 评估基准的成熟度。只要这三个指标有实质性变化Agentic Commerce 的落地速度会明显加快。当前阶段动手早的团队可以用最小的闭环把场景数据先积累起来等到基础设施成熟时手上已经有真实的任务数据和用户反馈会比从零开始的团队更容易跑出来。