电商 Agent 架构设计：分层编排、工具调用与稳定性实战

1. 电商 Agent 架构设计的核心思路拆解1.1 为什么电商场景对 Agent 架构有特殊要求电商购物助手这个场景和通用的对话机器人有本质区别。通用聊天机器人回答错了用户笑一笑就过去了但购物助手如果推荐错了商品、算错了优惠、报错了库存用户直接下单失败或者买贵了这是实打实的体验事故。所以电商 Agent 的第一性要求不是“能聊”而是“又快又稳”。“快”体现在响应延迟上。用户问“帮我找一款三百块以内的蓝牙耳机”从意图识别、商品检索、库存校验到最终生成推荐话术整条链路必须在秒级完成。一旦超过三秒用户大概率就切走了。“稳”体现在准确性上价格、库存、优惠规则这些数据不能靠模型“记忆”或“猜测”必须走实时接口校验。我在实际搭建类似系统时踩过最大的坑就是早期让模型直接根据上下文里的商品信息生成回答结果模型会“脑补”出不存在的优惠券和库存状态。后来改成所有关键数据必须经过工具调用实时获取模型只负责编排和话术生成准确率才稳定下来。这个教训直接决定了整个架构的设计方向模型负责理解和表达数据负责事实和约束。1.2 分层架构把“聪明”和“可靠”拆开一个成熟的电商 Agent 架构我倾向于拆成四层接入层处理用户输入做初步的意图分类和路由。这一层要尽量轻不要在这里做重逻辑。编排层这是 Agent 的“大脑”负责决定调用哪些工具、按什么顺序调用、如何处理中间结果。通常由一个规划器加一个执行器组成。工具层封装所有外部能力比如商品搜索、价格查询、库存校验、优惠计算、订单创建。每个工具都是独立的、可测试的、有明确输入输出的函数。数据层商品库、用户画像、会话状态、日志。这一层是事实的唯一来源。这样拆的好处是编排层可以灵活调整策略而不影响工具实现工具层可以独立优化性能而不影响上层逻辑。我见过不少团队把工具调用逻辑直接写死在提示词里结果改一个接口就要重新调提示词维护成本极高。1.3 编排层的两种主流模式ReAct 与 Plan-and-Execute编排层目前有两种主流实现方式。一种是 ReAct 模式即“思考-行动-观察”循环模型每一步都根据当前状态决定下一步做什么。这种模式灵活适合探索性任务但延迟高因为每一步都要等模型输出。另一种是 Plan-and-Execute 模式先让模型生成一个完整的执行计划然后按计划依次调用工具中间只在必要时才让模型介入调整。这种模式延迟低、可控性强适合电商这种流程相对固定的场景。我的建议是混合使用对于“找商品”这类开放式任务用 ReAct对于“下单”这类流程化任务用 Plan-and-Execute。实际落地时可以在编排层做一个任务分类器根据用户意图自动选择模式。这样既保证了灵活性又保证了关键路径的稳定性。2. 核心细节解析与实操要点2.1 工具调用的参数设计别让模型自由发挥工具调用的参数设计是整个架构里最容易被忽视、但影响最大的环节。很多团队让模型自己生成工具调用的参数比如搜索关键词、价格区间、排序方式结果模型经常生成一些奇怪的参数组合导致检索结果为空或者偏离用户意图。我的做法是对每个工具的参数做严格约束。比如商品搜索工具参数只允许是结构化的 JSON包含category、price_min、price_max、keywords、sort_by这几个字段每个字段都有明确的类型和取值范围。模型的任务是从用户话语中抽取这些字段而不是自由生成查询语句。具体实现上可以用函数调用Function Calling或者结构化输出Structured Output来约束模型输出。以函数调用为例定义一个search_products函数参数 schema 里明确写清楚每个字段的类型、描述和枚举值。模型输出后先做一层参数校验不合法的参数直接拒绝并让模型重新生成而不是带着错误参数去查数据库。注意参数校验一定要在工具层做不要依赖模型自觉。我见过模型把price_max填成负数的情况如果不校验数据库查询直接报错。2.2 会话状态管理别把历史全塞进上下文电商购物助手通常需要多轮对话比如用户先问“有没有降噪耳机”再问“刚才那个第二个多少钱”。这就要求 Agent 能记住之前的交互。但把全部历史对话塞进上下文有两个问题一是 token 消耗大、延迟高二是模型容易被无关历史干扰。我的方案是维护一个结构化的会话状态对象包含current_intent、last_search_results、selected_product、user_preferences等字段。每轮对话结束后用一个轻量的抽取模型更新这个状态对象而不是把原始对话全部保留。下一轮对话时只把状态对象和最近一两轮对话传给模型。这样做的另一个好处是状态对象可以持久化到数据库支持跨会话恢复。用户今天没买完明天回来还能接着上次的进度。这个体验在电商场景里很重要但很多团队一开始没考虑到。2.3 缓存策略哪些能缓存哪些绝对不能电商 Agent 的性能优化缓存是绕不开的。但缓存用错了地方会导致用户看到过期的价格或库存这是致命的。我的原则是静态数据可以缓存动态数据必须实时。商品标题、描述、图片这些不常变的数据可以缓存几分钟到几小时。但价格、库存、优惠券状态这些必须实时查询或者至少设置很短的缓存时间比如 10 秒并且在下单前做最终校验。具体实现上可以在工具层加一个缓存装饰器对不同的工具设置不同的 TTL。比如get_product_detail缓存 300 秒check_inventory缓存 5 秒calculate_discount不缓存。同时在下单工具里强制重新校验价格和库存确保用户看到的价格和实际支付价格一致。提示缓存 key 的设计要包含所有影响结果的参数。我见过有人用商品 ID 做 key结果不同用户看到不同价格因为会员等级不同时缓存串了导致普通用户看到了会员价。3. 实操过程与核心环节实现3.1 从零搭建一个最小可用的电商 Agent假设我们要从零搭建一个电商购物助手支持“搜索商品-查看详情-下单”这条主流程。下面是我实际落地时的步骤和关键代码结构。第一步定义工具集。每个工具都是一个独立的函数有明确的输入输出。以商品搜索为例def search_products( category: str, price_min: float 0, price_max: float 999999, keywords: list[str] None, sort_by: str relevance, limit: int 10 ) - list[dict]: 搜索商品返回商品列表。 每个商品包含 id, title, price, image_url, rating 等字段。 # 实际实现会查询商品数据库或搜索服务 ...第二步定义编排逻辑。用一个状态机来管理对话流程每个状态对应一个处理函数。比如IDLE状态下等待用户输入SEARCHING状态下调用搜索工具CONFIRMING状态下等待用户确认下单。class ShoppingAgent: def __init__(self): self.state IDLE self.context {} def handle(self, user_input: str) - str: if self.state IDLE: return self._handle_idle(user_input) elif self.state SEARCHING: return self._handle_searching(user_input) ...第三步接入模型做意图识别和话术生成。模型只负责两件事把用户输入转成结构化的意图和参数以及把工具返回的结构化数据转成自然语言回复。中间的所有逻辑流转由状态机控制不经过模型。这样做的结果是整个系统的行为是可预测的、可测试的。你可以写单元测试来验证每个状态转换是否正确而不需要每次都跑一遍模型。3.2 关键参数的计算与选择在电商 Agent 里有几个参数需要仔细计算和选择。超时时间每个工具调用都要设置超时。商品搜索建议 2 秒库存查询建议 1 秒下单建议 5 秒。超时后要有降级策略比如返回缓存数据或者提示用户稍后重试。我一般会在工具层统一设置超时并在编排层处理超时异常。重试次数对于幂等的查询类工具可以重试 1-2 次。对于下单这类非幂等操作绝对不能自动重试必须让用户确认。我见过因为自动重试导致用户被重复下单的案例这是严重的事故。上下文窗口传给模型的上下文要控制大小。我的经验是系统提示词加状态对象加最近两轮对话控制在 2000 token 以内。超过这个数延迟会明显上升而且模型注意力会被稀释。并发度如果一次要查多个商品的价格和库存可以并发调用。但并发度不要超过 5否则容易触发下游服务的限流。可以用异步 IO 来实现并发比如 Python 的asyncio.gather。3.3 一个完整的下单流程拆解以“用户下单”为例拆解一下完整的工具调用链确认商品调用get_product_detail获取最新商品信息确认商品仍在售。校验库存调用check_inventory确认库存充足。计算价格调用calculate_discount计算最终价格包括优惠券、会员折扣、满减等。生成订单预览把商品信息、价格、收货地址等汇总展示给用户确认。用户确认等待用户明确确认。创建订单调用create_order创建订单这一步要带幂等键防止重复下单。返回结果把订单号、支付链接等返回给用户。每一步都要有明确的成功和失败处理。比如库存不足时要返回“该商品暂时缺货”并推荐相似商品价格计算失败时要提示用户稍后重试而不是直接下单。注意第 5 步的用户确认不能省。我见过为了追求“自动化”而跳过确认直接下单的设计结果用户只是问“这个多少钱”就被下单了这是灾难性的体验。4. 常见问题与排查技巧实录4.1 模型“幻觉”导致推荐不存在的商品这是最常见的问题。模型在生成推荐话术时可能会编造出商品库里没有的商品或者把商品属性说错。排查方法是在工具层返回结果后加一层校验确保模型输出的商品 ID 都在工具返回的列表里。如果不在直接拦截并重新生成。更彻底的做法是不让模型自由生成商品信息而是用模板填充。模型只负责选择推荐哪个商品和生成推荐理由商品标题、价格、图片这些从工具返回的数据里直接取。4.2 多轮对话中意图丢失用户说“第一个太贵了有没有便宜点的”模型需要知道“第一个”指的是上一轮搜索结果里的第一个商品。如果上下文管理没做好模型就不知道“第一个”是什么。解决方法是在会话状态里显式记录last_search_results并在提示词里明确告诉模型“上一轮搜索结果是这些”。同时在意图识别时把指代词解析成具体的商品 ID而不是让模型自己去猜。4.3 工具调用超时导致整体响应慢如果某个工具调用超时整个链路都会被拖慢。排查时先看日志确认是哪个工具慢。常见原因有数据库查询没加索引、下游服务限流、网络抖动。优化手段包括给工具加缓存、设置合理的超时和重试、对非关键路径的工具做异步化。比如商品推荐可以异步加载不阻塞主流程。4.4 常见问题速查表问题现象可能原因排查方法解决方案推荐了不存在的商品模型幻觉检查模型输出是否在工具返回列表中加校验层用模板填充商品信息多轮对话意图丢失上下文管理不当检查会话状态是否记录了关键信息显式记录搜索结果和指代关系响应时间超过 5 秒工具调用慢或串行调用看日志定位慢工具加缓存、设超时、并发调用价格显示错误缓存了动态数据检查价格是否走了缓存价格实时查询下单前二次校验重复下单重试逻辑不当检查下单工具是否自动重试下单必须用户确认带幂等键4.5 几个我踩过的坑第一个坑是过度依赖模型做决策。早期我把“是否推荐某个商品”的判断也交给模型结果模型经常推荐一些明显不合适的商品比如用户要买耳机推荐了耳机套。后来改成用规则引擎做初筛模型只负责在候选集里排序和生成话术效果好很多。第二个坑是忽略了下游服务的稳定性。有一次商品搜索服务挂了整个 Agent 直接不可用。后来加了降级策略搜索服务不可用时返回热门商品列表至少保证用户还能逛。第三个坑是日志打得太少。出问题时根本不知道是哪一步错了。后来在每个工具调用前后都打日志记录输入参数、输出结果、耗时排查效率提升了很多。5. 性能优化与稳定性保障5.1 延迟优化的几个关键手段电商 Agent 的延迟主要来自三部分模型推理、工具调用、网络传输。模型推理的优化空间有限主要是选更小的模型或者用流式输出。工具调用的优化空间最大可以通过缓存、并发、预计算来降低延迟。我常用的一个技巧是预取。比如用户搜索了“蓝牙耳机”在展示搜索结果的同时后台异步预取前几个商品的详情和库存。等用户点击某个商品时数据已经准备好了响应几乎是瞬时的。另一个技巧是流式输出。模型生成回复时不要等全部生成完再返回而是边生成边返回。用户看到第一个字的时间从 2 秒降到 500 毫秒体感快很多。5.2 稳定性保障降级、熔断、限流稳定性保障的核心是“假设一切都会失败”。每个工具调用都要有降级方案每个下游服务都要有熔断机制每个入口都要有限流。降级方案举例商品搜索失败时返回热门商品价格计算失败时提示用户稍后重试推荐服务失败时返回默认推荐列表。关键是不要让一个环节的失败导致整个系统不可用。熔断机制可以用现成的库来实现比如设置一个失败率阈值超过阈值就暂时切断对该服务的调用过一段时间再试探性恢复。限流主要是防止恶意请求或者突发流量打垮系统。可以在接入层做按用户 ID 或 IP 限流。5.3 监控与告警哪些指标必须盯必须监控的指标包括端到端响应时间P50、P95、P99、各工具调用成功率、模型调用成功率、缓存命中率、下单转化率。告警阈值根据业务情况设定比如 P99 响应时间超过 5 秒就告警工具调用成功率低于 99% 就告警。日志要记录每个请求的完整链路包括用户输入、意图识别结果、工具调用参数和结果、模型输出、最终回复。这样出问题时可以快速定位。提示监控指标要按维度拆分比如按商品类目、按用户等级、按时间段。这样能发现一些隐藏的问题比如某个类目的搜索特别慢或者某个时间段下单失败率特别高。6. 扩展方向与个人经验这套架构不只适用于电商购物助手稍作调整就可以用在其他需要“又快又稳”的场景比如客服机器人、订票助手、酒店预订等。核心思想是一样的模型负责理解和表达工具负责事实和约束编排层负责流程控制。我个人在实际操作中的体会是不要追求一步到位。先搭一个最小可用的版本跑通主流程然后再逐步优化。我见过不少团队一开始就想做得很完美结果几个月都上不了线。反而是那些先上线再迭代的团队最终效果更好。另外测试非常重要。每个工具都要有单元测试每个状态转换都要有集成测试整个链路要有端到端测试。电商场景的错误成本很高测试是保证稳定性的最后一道防线。最后分享一个小技巧在提示词里明确告诉模型“如果不确定就说不知道不要编造”。这句话看起来简单但能减少很多幻觉问题。配合工具返回的结构化数据模型的输出质量会稳定很多。