1. 电商 Agent 到底难在哪从“能聊”到“能买”的鸿沟电商 Agent 这个词这两年快被说烂了。随便打开一个技术社区到处都是“我用大模型做了一个购物助手”的帖子。但真正做过的人心里都清楚Demo 和能上线的系统之间隔着的不是一层窗户纸而是一整条鸿沟。我最早接触这类项目是在两年前当时帮一个做垂直品类的小团队搭过一套导购对话系统。那时候大模型的工具调用能力刚出来不久大家都很兴奋觉得只要把商品接口挂上去让模型自己决定什么时候查库存、什么时候推荐、什么时候下单一个智能购物助手就成了。结果第一版上线不到三天就被叫停了——用户问“有没有适合送长辈的茶叶”Agent 连续调了七次搜索接口每次返回几十个商品最后给用户推了一款咖啡豆。问题出在哪不是模型不够聪明而是整个架构没有为“电商”这个场景做任何约束。Anthropic 这次开源的电商 Agent 架构指南之所以值得拿出来认真拆解是因为它没有停留在“怎么让模型调用工具”这个层面而是把电商场景里最要命的那几个问题——延迟、准确性、状态管理、异常兜底——全部摆到了台面上并且给出了一套可以直接参考的分层方案。这套方案的核心思路可以用一句话概括把 Agent 拆成“快思考”和“慢思考”两条路径让简单请求走短路复杂请求走长路同时用确定性的状态机兜住所有不确定性。这篇文章我会从架构设计的角度把这套方案拆开来讲。不管你是正在做电商导购、客服机器人还是任何需要“对话交易”的场景这套思路都能直接抄作业。我会补充大量实操层面的细节包括参数怎么设、状态怎么管、异常怎么兜以及我自己踩过的那些坑。1.1 为什么电商 Agent 比通用助手难做通用对话助手的目标是“生成合理的回复”而电商 Agent 的目标是“完成一笔正确的交易”。这两个目标的难度完全不在一个量级。生成合理回复模型只要不胡说八道就行用户问天气你答天气用户问知识你答知识答错了顶多被骂两句。但电商 Agent 不一样它要查库存、算价格、比对优惠、确认地址、发起支付每一步都涉及真实的数据和真实的钱。一旦出错轻则用户买错东西重则产生资损和客诉。我总结下来电商 Agent 面临的核心挑战有四个第一是延迟敏感。用户问“这个有货吗”期望的是秒级回复。如果 Agent 在后台串行调了五六个接口每个接口 500 毫秒再加上模型推理的时间用户等三五秒才看到回复体验直接崩掉。电商场景的对话轮次往往很短用户耐心极低延迟每增加一秒转化率就往下掉一截。第二是准确性要求极高。商品信息、价格、库存、优惠规则这些数据必须准确。模型可以不知道某个冷门知识但不能把 199 的价格说成 99也不能把没货的说成有货。这就要求 Agent 在涉及关键数据时必须走确定性的查询路径而不是让模型“凭记忆”回答。第三是状态复杂。一次购物对话可能涉及多个商品、多个轮次、多个意图的切换。用户可能先问 A 商品再问 B 商品然后回头又问 A 的优惠最后决定买 B。Agent 需要在整个对话过程中维护一个清晰的状态知道用户当前在看什么、购物车里有什么、走到哪一步了。第四是异常场景多。接口超时、库存突变、优惠券失效、地址无法配送这些异常在真实电商环境里每天都在发生。Agent 必须有兜底机制不能一遇到异常就卡死或者胡说。1.2 这套架构指南的核心主张Anthropic 这套指南最值钱的地方是它明确提出了分层路由的思想。不是所有请求都值得走完整的 Agent 推理链路大量请求其实是确定性的、可以走短路的。具体来说它把用户请求分成三类确定性请求比如“查一下订单状态”“这个商品多少钱”“帮我加入购物车”。这类请求有明确的意图和参数可以直接映射到后端接口不需要模型做复杂推理。半确定性请求比如“有没有适合送长辈的茶叶”“帮我推荐一款 500 以内的耳机”。这类请求需要模型理解意图、提取约束条件但最终的查询和筛选可以走结构化路径。开放性请求比如“我想布置一下新家预算一万帮我看看买什么”。这类请求需要多轮规划、多商品组合、复杂推理才需要走完整的 Agent 链路。这个分类看起来简单但落地的时候非常关键。我见过太多项目把所有请求都塞给模型做完整推理结果就是又慢又贵又不准。正确的做法是能走短路的绝不走长路能确定性解决的绝不交给模型。2. 架构拆解快慢双通道与状态机兜底理解了核心主张接下来看具体怎么落地。这套架构可以拆成四个层次接入层、路由层、执行层、状态层。每一层都有明确的分工层与层之间通过标准化的数据结构通信。2.1 接入层请求归一化与意图预判接入层做的事情是把用户的自然语言输入转换成后续层可以处理的结构化请求。这一步不需要模型做太重的推理但需要做几件关键的事。首先是请求归一化。用户可能说“这个多少钱”“价格是多少”“卖多少钱”这些表达在语义上是一样的归一化之后统一映射到“查询价格”这个意图。归一化的方式可以是规则匹配也可以用一个轻量级的分类模型。我的经验是规则匹配覆盖高频表达模型兜底长尾表达两者结合效果最好。其次是上下文注入。接入层需要把当前会话的历史、用户画像、当前浏览的商品等信息一起打包进请求。这里有个坑上下文不是越多越好。我试过把完整的历史对话都塞进去结果模型被无关信息干扰反而容易出错。正确的做法是只注入与当前意图相关的上下文比如用户当前在看的商品、最近三轮的对话、用户的偏好标签。最后是意图预判。接入层需要快速判断这个请求属于哪一类然后决定走哪条通道。这个判断不需要非常精确因为路由层还会做二次确认但需要足够快。我的做法是用一个小的分类模型或者关键词规则在 50 毫秒内给出一个初步判断。2.2 路由层快慢通道的分流逻辑路由层是整个架构的核心。它的任务是根据请求的特征决定走快通道还是慢通道。快通道处理确定性请求。这类请求的特征是意图明确、参数完整、可以直接映射到后端接口。比如“查订单”“查物流”“加购物车”“查价格”。快通道的处理流程是意图识别 → 参数提取 → 接口调用 → 结果格式化。整个过程不涉及复杂的模型推理延迟可以控制在 500 毫秒以内。慢通道处理半确定性和开放性请求。这类请求需要模型做意图理解、约束提取、多轮规划。慢通道的处理流程是意图理解 → 约束提取 → 规划 → 工具调用 → 结果生成。延迟通常在 2 到 5 秒但换来的是更强的理解能力和更灵活的响应。路由判断的依据是什么我总结下来主要是三个维度判断维度快通道特征慢通道特征意图明确度意图单一且明确意图模糊或复合参数完整度参数可直接提取参数需要推理补全结果确定性结果可直接查询结果需要组合生成举个例子用户说“帮我查一下昨天买的那个耳机的物流”这个请求意图明确查物流、参数完整昨天买的耳机走快通道。用户说“我想买个耳机主要用来跑步预算五百左右有什么推荐”这个请求意图是推荐、参数需要推理跑步场景、五百预算走慢通道。注意路由判断不要追求 100% 准确。我一开始总想把路由做得完美结果加了一堆规则和模型路由本身就成了瓶颈。后来想通了路由允许一定的误判关键是慢通道要能兜住快通道漏掉的请求快通道要能快速处理慢通道判断为简单的请求。2.3 执行层工具调用与结果组装执行层是真正干活的地方。快通道和慢通道在这里共享同一套工具集但调用方式不同。快通道的工具调用是确定性的。意图识别出来之后直接映射到对应的工具参数从请求里提取调用完直接返回结果。比如“查价格”映射到get_price工具参数是商品 ID调用完把价格格式化返回。慢通道的工具调用是规划性的。模型需要先规划需要调用哪些工具、按什么顺序调用、每个工具的参数是什么。这里的关键是工具描述要足够清晰。我见过很多项目工具描述写得含糊不清模型不知道该什么时候调用、参数怎么填结果就是乱调一气。工具描述我建议包含这几个要素工具名称、功能说明、参数列表含类型和示例、返回值说明、适用场景。比如{ name: search_products, description: 根据关键词和筛选条件搜索商品适用于用户有明确购买意向但需要查找具体商品的场景, parameters: { keyword: {type: string, description: 搜索关键词如跑步耳机}, price_min: {type: number, description: 最低价格可选}, price_max: {type: number, description: 最高价格可选}, category: {type: string, description: 商品类目可选} }, returns: 商品列表每个商品包含 ID、名称、价格、库存状态 }结果组装这一步快通道和慢通道也不一样。快通道直接格式化返回慢通道需要模型把多个工具的结果整合成一段自然的回复。这里有个技巧不要让模型自由发挥。给模型一个固定的回复模板让它填充关键信息而不是让它从头生成。这样既能保证信息准确又能控制回复风格。2.4 状态层对话状态与交易状态的分离管理状态管理是电商 Agent 最容易出问题的地方。我的经验是对话状态和交易状态必须分开管理。对话状态记录的是“用户当前在聊什么”包括当前意图、当前商品、最近几轮对话。这个状态是易变的随着对话推进不断更新。交易状态记录的是“这笔交易走到哪一步了”包括购物车内容、收货地址、支付状态、订单号。这个状态是相对稳定的一旦确定就不应该被对话内容轻易改变。为什么要分开因为它们的生命周期和更新频率完全不同。对话状态每轮都在变交易状态只在关键节点变。如果混在一起管理很容易出现“用户随便说了句话结果把购物车清空了”这种事故。我的做法是用两个独立的状态存储对话状态放在内存里交易状态放在持久化存储里。每次对话开始时从持久化存储里加载交易状态对话过程中只更新对话状态只有用户明确确认下单时才更新交易状态。提示交易状态的更新一定要有确认机制。用户说“帮我下单”Agent 不能直接下单必须先展示订单摘要让用户确认后再执行。这个确认步骤看起来多余但能避免大量误操作。3. 实操落地从零搭一套可用的电商 Agent理论讲完了接下来讲怎么落地。我会按照实际搭建的顺序把每个环节的关键点和参数选择讲清楚。3.1 环境准备与技术选型先说技术选型。这套架构对模型的要求是“够用就好”不需要最强的模型。快通道的意图识别和参数提取用一个小模型甚至规则引擎就能搞定。慢通道的规划和生成需要一个中等能力的模型。我的选型建议是快通道意图识别规则引擎 小模型兜底。规则覆盖高频意图小模型处理长尾。小模型可以用 7B 级别的推理速度快成本低。慢通道规划生成中等能力的模型14B 到 70B 之间。这个级别的模型在理解复杂意图和规划多步操作上已经够用延迟和成本也可控。工具调用框架用标准的 function calling 接口不要自己造轮子。主流框架都支持工具描述和调用结果解析直接用就行。环境方面我建议至少准备两套环境开发环境和预发环境。开发环境用来调试工具和提示词预发环境用来做端到端测试。电商场景的测试数据要尽量真实商品、库存、价格、优惠都要和线上一致否则测出来的结果没有参考价值。3.2 快通道实现意图识别与参数提取快通道的实现相对直接。核心是两个模块意图识别和参数提取。意图识别我用的是“规则优先 模型兜底”的策略。规则部分维护一个意图关键词表比如“价格”“多少钱”“贵不贵”映射到query_price“库存”“有货吗”“还有吗”映射到query_stock。规则匹配用简单的字符串包含和正则速度极快。规则匹配不中的请求交给小模型做分类。小模型的提示词要写得简洁明确给出意图列表和几个示例让模型输出意图标签。这里有个细节意图列表不要太多。我一开始定义了三十多个意图结果模型经常混淆。后来精简到十二个核心意图准确率明显提升。参数提取是快通道的另一个关键。比如“查一下昨天买的那个耳机的物流”需要提取出“订单时间昨天”“商品耳机”这两个参数。参数提取可以用规则也可以用模型。我的做法是结构化参数用规则非结构化参数用模型。订单号、商品 ID 这类有固定格式的用正则提取时间、商品名称这类自然语言表达的用模型提取。参数提取完之后要做一个完整性校验。如果参数不完整比如用户说“查物流”但没说哪个订单快通道不能直接调用接口要把请求转给慢通道让模型通过多轮对话补全参数。3.3 慢通道实现规划与工具编排慢通道是整套架构里最复杂的部分。核心是让模型学会“先规划、再执行”。我的做法是给模型一个明确的规划提示词让它先输出一个执行计划再按计划调用工具。提示词的结构大概是这样的你是一个电商购物助手。用户提出了一个请求你需要 1. 理解用户的真实意图 2. 提取所有约束条件 3. 规划需要调用哪些工具按什么顺序调用 4. 按计划执行并根据执行结果决定是否需要调整 可用工具[工具列表] 请先输出你的执行计划格式为 - 意图... - 约束... - 计划步骤1. ... 2. ... 3. ...这个“先输出计划”的步骤非常关键。我试过让模型直接调用工具结果它经常跳步或者顺序错乱。加上计划步骤之后模型的执行逻辑清晰了很多出错率明显下降。工具编排的另一个关键是并行调用。如果多个工具之间没有依赖关系应该并行调用而不是串行。比如用户问“这个商品的价格和库存”查价格和查库存是两个独立的工具可以并行调用。并行调用能把延迟从两个接口的串行时间压缩到一个接口的时间。注意并行调用要控制并发数。我试过一次性并行调用十个工具结果把后端接口打挂了。建议并发数控制在 3 到 5 个超出的排队执行。3.4 状态管理实现会话上下文与交易快照状态管理的实现我建议用“会话上下文 交易快照”的组合。会话上下文存在内存里结构大概是这样session_context { session_id: xxx, current_intent: query_price, current_product: {id: 123, name: 跑步耳机}, recent_turns: [ {role: user, content: 这个多少钱}, {role: assistant, content: 这款跑步耳机售价 399 元} ], user_profile: {preferred_categories: [数码, 运动]} }交易快照存在持久化存储里结构大概是这样transaction_snapshot { user_id: xxx, cart_items: [{product_id: 123, quantity: 1}], shipping_address: {...}, payment_status: pending, order_id: None }每次对话开始时从持久化存储加载交易快照注入到会话上下文中。对话过程中只更新会话上下文。用户明确确认下单时才更新交易快照并持久化。这里有个细节交易快照的更新要加锁。用户可能同时开多个会话如果两个会话同时更新交易快照会出现数据覆盖。我的做法是用乐观锁更新时检查版本号版本号不匹配就重试。3.5 异常兜底超时、降级与人工接管异常兜底是电商 Agent 上线前的最后一道防线。我总结了几种常见的异常场景和对应的处理策略异常场景处理策略工具调用超时设置 3 秒超时超时后返回“正在查询请稍候”并异步重试工具调用失败降级到缓存数据或返回“暂时无法查询请稍后再试”模型推理超时降级到快通道的规则回复库存突变下单前二次校验库存库存不足时提示用户并推荐替代商品优惠券失效下单前校验优惠券有效性失效时提示用户并重新计算价格连续多轮无法理解转人工接管并附带对话摘要人工接管这个机制我特别想强调。很多项目觉得 Agent 应该全自动不需要人工。但实际运营下来总有一些请求是 Agent 处理不了的比如复杂的售后、特殊的定制需求。这时候如果硬让 Agent 处理只会把用户惹毛。正确的做法是设置一个“转人工”的兜底当 Agent 连续两轮无法给出有效回复时自动转人工并把对话摘要和用户信息一起转过去。4. 性能优化与常见问题排查架构搭起来之后接下来就是调优。这部分我踩过的坑最多也最有分享价值。4.1 延迟优化的几个关键手段延迟是电商 Agent 的生命线。我实测下来几个最有效的优化手段是第一快通道尽量不走模型。意图识别和参数提取能用规则就用规则规则覆盖不了的再用小模型。我做过对比纯规则的快通道延迟在 50 毫秒以内加上小模型之后延迟增加到 200 毫秒左右。对于高频请求这 150 毫秒的差距在用户体验上是能感知到的。第二慢通道的规划步骤做缓存。很多请求的规划逻辑是相似的比如“推荐商品”这个意图规划步骤基本固定。可以把常见的规划结果缓存起来命中缓存时直接复用不用每次都让模型重新规划。第三工具调用并行化。前面提过无依赖的工具调用并行执行。我实测下来三个工具串行调用需要 1.5 秒并行调用只需要 0.6 秒延迟降低了一半多。第四流式输出。慢通道的回复生成用流式输出让用户先看到部分内容而不是等全部生成完再展示。这个手段对感知延迟的优化非常明显用户看到内容在逐字出现会觉得系统响应很快。4.2 准确率提升的实操技巧准确率是电商 Agent 的底线。我总结的几个提升准确率的技巧第一关键数据强制走确定性查询。价格、库存、优惠这些数据绝对不能让模型“凭记忆”回答必须走接口查询。我的做法是在提示词里明确写“涉及价格、库存、优惠的问题必须先调用对应工具查询不得直接回答。”第二工具返回结果做二次校验。工具返回的数据不一定准确比如库存接口可能返回缓存数据。我的做法是在关键节点做二次校验比如下单前重新查一次库存和价格。第三回复内容做规则过滤。模型生成的回复里如果包含价格数字要和工具返回的价格做比对不一致就拦截重生成。这个规则过滤能拦住大部分价格错误。第四建立评测集。我维护了一个包含 500 条真实用户请求的评测集每次修改提示词或工具描述后都跑一遍评测集看准确率有没有下降。这个习惯帮我避免了很多次“改了一个地方坏了另一个地方”的问题。4.3 常见问题速查表问题现象可能原因排查方向解决方案Agent 反复调用同一个工具工具描述不清晰或参数提取错误检查工具描述和参数提取逻辑优化工具描述增加参数示例回复内容包含错误价格模型未调用价格工具或调用了缓存数据检查提示词和工具调用日志强制关键数据走确定性查询多轮对话后状态丢失会话上下文未正确传递检查上下文注入逻辑修复上下文传递增加状态校验慢通道延迟过高工具串行调用或模型推理慢检查工具调用链路和模型耗时并行化工具调用优化提示词路由判断错误路由规则或分类模型不准确检查路由日志和误判案例调整路由规则补充训练数据下单时库存不足未做下单前二次校验检查下单流程增加库存二次校验和替代推荐4.4 我踩过的几个大坑第一个坑把模型当数据库用。早期我为了让 Agent 回答快把商品信息直接塞进提示词里让模型从提示词里找答案。结果商品一多提示词就超长模型开始丢信息价格经常答错。后来改成工具查询准确率立刻上来了。这个坑的教训是模型擅长理解和生成不擅长精确检索和计算该用工具的地方一定要用工具。第二个坑状态管理混在一起。前面提过我一开始把对话状态和交易状态混在一起管理结果用户随便说了句话把购物车清空了。后来分开管理之后这类事故再没出现过。第三个坑忽略异常场景。上线初期我只测了正常流程没测异常场景。结果上线第一天就遇到库存接口超时Agent 卡在那里一直转圈用户以为系统挂了。后来加了超时和降级机制才稳定下来。第四个坑提示词写得太长。我一开始觉得提示词越详细越好把各种规则、示例、约束都塞进去。结果模型被长提示词干扰反而容易出错。后来精简到核心规则加少量示例效果反而更好。提示词不是越长越好关键是清晰和聚焦。5. 这套架构的适用边界与扩展方向最后聊聊这套架构的适用边界。它不是万能的有些场景用这套架构反而会变复杂。适合的场景商品导购、客服问答、订单查询、售后处理。这些场景的共同特点是意图相对明确、工具有限、状态可管理。不太适合的场景复杂的谈判议价、多商品组合的深度规划、需要大量外部知识支撑的咨询。这些场景要么需要更强的模型能力要么需要更复杂的架构设计。扩展方向的话我觉得有几个值得尝试第一多模态输入。用户拍一张照片问“这个有类似的吗”需要 Agent 支持图像理解。这个扩展需要在接入层增加图像处理模块把图像转成文本描述后再走后续流程。第二个性化推荐。在慢通道里增加用户画像和推荐算法让 Agent 的推荐更精准。这个扩展需要打通用户画像系统和推荐系统。第三多 Agent 协作。把导购、客服、售后拆成独立的 Agent通过消息队列协作。这个扩展适合业务复杂度高、单 Agent 难以覆盖所有场景的情况。我个人在实际操作中的体会是这套架构最大的价值不是它有多复杂而是它把“什么该让模型做、什么不该让模型做”这条边界划得很清楚。很多项目失败不是因为模型不够强而是因为把太多不该模型做的事交给了模型。把边界划清楚把确定性的东西交给确定性系统把不确定性的东西交给模型这才是电商 Agent 又快又稳的关键。