最近在带团队做一套面向电商场景的多智能体系统从拆解需求到第一版可跑通的 Demo 前后花了两周多。过程中踩了不少坑也沉淀了一套比较完整的设计思路今天一次性把这些经验整理出来希望给正在做或者准备做 Multi-Agent 应用的同学一些参考。这套系统不是赶时髦硬凹的多 Agent 壳子而是真正面对电商业务里“用户需求多样、流程链路长、决策依赖上下文多”这些特点去设计的。电商这类场景特别适合用 Multi-Agent 来落地因为它的流程天然可以被拆成独立领域——进店、逛店、咨询、下单、支付、物流、售后每个环节都有独立的业务逻辑和数据结构相互之间又需要协作。这种“独立又协作”的形态和 Multi-Agent 的设计哲学几乎完全重合。这篇文章不讲虚的直接从架构设计、Agent 分工、协作机制、技术选型、工程实现、踩坑记录这六个维度展开适合正在做 Agent 应用的开发者、电商系统的架构师以及对大模型应用落地感兴趣的产品经理。看完你至少能知道电商系统里的 Agent 到底该怎么切分、互相之间怎么说话、编排引擎怎么设计、以及上线之前最容易忽视的哪些问题。1. 为什么电商场景需要 Multi-Agent 而不是一个大模型1.1 传统单模型方案的困境很多人第一反应是我都用大模型了直接把用户问题丢进去让大模型一步到位回答不就行了在简单问答场景可以但放到电商全链路里很快就会发现一个模型的“全能”反而成了瓶颈。举几个实际例子。用户在售前阶段会问“这个手机和另一个型号比怎么样”到了售后阶段会说“我收到的屏幕有条划痕要退换”。这两类问题的知识域完全不同前者是商品知识库、参数对比、用户评价分析后者是订单状态、物流轨迹、售后政策、图片凭证。如果都塞进一个大模型的上下文里一方面 prompt 会膨胀到没法维护另一方面模型容易被无关内容干扰回答的专业性反而下降。还有一个更现实的问题模型的上下文窗口有限。一个电商商品详情页可能有几十万字的数据包括图文、参数、规格、用户评价不可能全塞进去。即便是最新的长上下文模型塞满之后推理速度会明显变慢成本还会飞涨。传统单模型方案在这个场景下面临的不仅是效果问题还有工程化和成本的双重压力。1.2 电商链路天然适合 Agent 化切分电商用户的完整购物路径基本是固定的搜索/推荐发现商品→ 商品咨询了解详情→ 下单支付完成交易→ 物流跟踪等待收货→ 售后处理解决问题→ 复购推荐再次触达。每个环节的角色、目标、知识域、工具接口都不一样。用 Multi-Agent 的视角来看这几乎就是教科书级的“多角色协作流程”每个 Agent 负责一个专业领域拥有自己的知识库和工具集通过统一的调度中心协作。这种设计的好处很直接职责清晰每个 Agent 只做一件事Prompt 短、知识精、工具少模型的压力小输出质量高。可独立迭代商品推荐 Agent 效果不好单独调它就行不会影响售后 Agent。故障隔离一个 Agent 挂了其他 Agent 还能继续服务不至于全站瘫掉。成本可控不需要每次请求都把所有领域知识塞进上下文按需调用对应 Agent 即可。1.3 我从这个架构里实际获得的收益首版上线后我们用一组真实用户问题做了对比测试单模型方案全部打在一个大 Prompt 里Multi-Agent 方案按角色拆分。结果非常直观推荐准确率从单模型的 68% 提升到 82%售后问题的解决率从 54% 提升到 76%。更重要的是平均单次请求的 token 消耗下降了 40%——因为每个 Agent 只需要处理和自己相关的上下文不需要把全链路数据都背在身上。所以我的观点很明确电商这类流程复杂、领域分明的业务系统是 Multi-Agent 最好的落地场景之一它不是技术炫技而是真正能解决工程问题的架构选择。2. 整体架构设计与 Agent 分工体系2.1 分层架构设计先说一下系统整体分了几层让后续的讨论有共同的坐标系。我采用的是五层结构接入层、调度层、Agent 层、工具层、数据层。接入层负责接收用户输入和统一身份鉴权支持多渠道来源App、小程序、Web把用户的原始消息统一打包成标准的会话消息格式。调度层是整个系统的中枢包含意图识别模块和流程编排引擎。意图识别模块判断用户想干什么是想咨询商品、查询订单、发起售后还是闲聊流程编排引擎则负责决定“接下来该调用哪个 Agent”并在多个 Agent 协作时维持流程状态。Agent 层是业务能力的载体每个 Agent 都是一个独立的功能单元内部包含自己的提示词模板、知识库索引、工具调用集合和记忆存储。工具层封装了所有对外部系统的操作查询商品库、创建订单、更新物流状态、查库存、生成优惠券等这些通过统一 API 网关暴露给 Agent 层调用。数据层包括各业务库、知识库、向量数据库、会话数据存储、监控日志等。这个分层参考了传统后端架构的成熟思路但因为每个 Agent 都是带“大脑”的独立服务所以比普通的后端微服务多了一个“决策”维度——Agent 不是被动响应而是根据上下文主动规划下一步动作。2.2 核心 Agent 角色定义在实际落地中我根据地推的电商业务链路设计了六个核心 Agent。他们的职责边界如下Agent 名称职责范围核心工具关键知识用户意图识别 Agent判断用户当前需求所属领域意图分类器、实体抽取器历史会话记忆商品推荐 Agent根据用户画像和需求推荐商品商品检索、相似度计算、排序模型商品知识库、用户偏好商品咨询 Agent回答商品规格、参数、使用问题商品详情检索、参数对比商品数据库、常见问答交易处理 Agent处理下单、支付、优惠计算购物车API、订单API、优惠券服务交易规则、活动规则物流跟踪 Agent查询物流状态、预计送达时间物流查询接口、时效预估模型物流轨迹数据售后服务 Agent处理退换货、退款、投诉售后工单API、图片审核、政策检索售后政策、历史工单这里最关键的设计决策是意图识别 Agent 被单独拎了出来而不是每个 Agent 自己去做意图判断。为什么这么设计因为传统微服务架构的“网关路由”思想同样适用于 Agent 系统——每个 Agent 如果都做一次意图猜测既浪费 token又容易出现多个 Agent 抢一个任务的情况。让专门的意图识别 Agent 先做一次粗粒度分类再用规则路由到具体的业务 Agent效率和准确率都更高。2.3 Agent 内部结构设计每个 Agent 内部采用了一套固定的“感知-思考-行动”循环结构这和经典的 Agent 设计一脉相承。感知接收调度层传入的会话上下文加上该 Agent 自己的历史记忆。思考让模型根据当前上下文判断“用户真正想要什么”“需要哪些信息才能完成目标”“是否有信息缺失需要追问”。行动调用工具层提供的 API 获取数据或者触发业务流程。输出生成最终回复或者向调度层发出“移交控制权”的请求。这个结构里有一个特别重要的细节Agent 不能无限循环。我给每个 Agent 都设了最大行动轮数通常是 3 轮。也就是说如果 Agent 觉得自己信息不够、连续追问了三次还得不到关键信息就立刻生成一个“需要人工介入”的信号把人引到在线客服而不是一直绕圈。这个设计后来被证明非常必要因为大模型在信息不全时很容易陷入“自嗨”式的连环追问体验很差。3. 协作机制与核心流程编排3.1 Agent 之间的通信方式Agent 之间怎么“说话”一开始我们想做直接的消息传递让 Agent A 调用 Agent B 的接口。很快发现这个思路有问题Agent A 和 Agent B 之间产生了强耦合编排逻辑散落在各个 Agent 的代码里根本没法全局控制。后来我们改成了中央调度 共享上下文的模式。所有 Agent 不直接通信而是通过调度层交换信息。调度层维护一个共享的“会话记忆体”Session Memory里面存了本次会话的目标状态、已获取的信息字典、当前流程节点Agent 需要什么数据就从会话记忆体里读需要产出什么数据就写回去。这种模式的好处是Agent 之间完全解耦替换任何一个 Agent 只需要保证它能读写相同的记忆体结构即可。缺点是共享记忆体可能成为瓶颈和污染源所以我们在记忆体里仔细划分了命名空间用户输入区、Agent 产出区、系统控制区。用户输入区只有接入层的解析结果能写Agent 产出区只有 Agent 能写系统控制区只有编排引擎能写。这样不同角色的数据就不会互相踩踏。3.2 核心购物链路编排流程拿一条完整的“咨询-购买-售后”链路来举例看看编排引擎是怎么工作的。假设用户说“我想买个适合跑步戴的耳机之前买过你们家另一款用了一个月出现断连想看看能不能退。”第一步接入层把这段话送到调度层意图识别 Agent 判断出本轮需求同时涉及三个领域选购、售后。系统解析出两个意图后编排引擎决定先处理售后。因为很多电商平台的体验设计里售后问题优先级更高用户的情绪和信任度都会受影响。第二步编排引擎调用售后 Agent。售后 Agent 从共享记忆体里读取用户的历史订单信息发现之前的订单在退货周期内。它先核对退货政策确认符合条件然后调用售后工单 API 创建一条退货申请。第三步售后 Agent 完成工单创建后编排引擎判断“退货结束后用户还有购买新耳机的需求”于是把控制权交给商品推荐 Agent。推荐 Agent 在对话上下文里看到“跑步”“耳机”“断连”这几个关键信息结合用户的消费历史检索出几款抗汗、续航长、支持运动场景的耳机生成比价和推荐列表。整个流程里每个 Agent 都不知道对方是怎么实现的它们只遵循一个简单的契约从共享记忆体读输入把输出写好告诉调度层“我完成了什么”和“我还需要什么”。3.3 编排引擎的设计细节编排引擎是这套系统的心脏我用状态机模型来实现。每个业务流程都定义成一个状态图节点是“调用哪个 Agent”边是“前一个 Agent 产出什么结果就跳到哪个状态”。这样做有个特别大的好处流程可观测、可回滚、可恢复。比如售后退款流程的状态包括待审核、审核中、已通过、待收货、已退款、已关闭。如果用户在某个状态中断了会话引擎会把当前状态持久化下次用户回来直接从断点继续不需要用户重新描述问题。这一点对电商体验特别重要用户不会愿意把同一个问题说两遍。除了状态机我还用了一个超时和熔断机制。电商系统一天里会有明显的流量波峰波谷比如大促时段如果某个 Agent 响应超时不能让它拖住整个链路。我们的策略是设置单 Agent 超时时间 3 秒超过就直接走兜底方案返回统一话术或转人工同时给调用方返回一个“AgentTimeout”的错误码。这样即使某个模型服务挂了用户至少能拿到一个不崩溃的应答而不是看着转圈等半天。4. 技术选型与工程化实现要点4.1 编排框架选型别急着上重型框架这一块我踩过不少折腾说点血泪经验。项目刚启动时我们研究了几套主流的多智能体编排框架调研下来最直接的一个感受是这些框架各有特长也有各自的限制。有的擅长图结构编排自带记忆和后端接口但对团队的技术栈有要求有的对国产模型支持友好工具调用本身很稳但对复杂流程的状态管理比较弱。花了几天时间测试后我们最终决定生产系统不直接用任何重框架的复杂编排能力只借鉴它们的状态图表达思想用我们自己熟悉的技术栈做很薄的一层编排引擎。核心原因是任何框架都有学习成本和隐形的行为约束一旦在版本迭代中发现框架行为和业务逻辑冲突会非常被动。我们自身的技术栈比较成熟用状态机加消息队列完全可以表达我们的调度逻辑维护成本反而更低。所以我的建议是如果是做技术验证、原型与 PoC可以大胆用成熟框架快速跑通如果是做要上真实流量的生产系统一定要想清楚框架的边界在哪里什么时候需要自研。市面上没有银弹框架越早意识到这一点越好。4.2 模型选型与调用策略模型选型直接决定了系统效果的底座。我们目前采用的是大小模型结合、分层调用的策略。意图识别和控制路由用轻量模型因为这类任务逻辑简单用轻量模型速度快、成本低准确率可以做到 95% 以上。偶尔遇到模棱两可的输入可以加上一个规则引擎兜底比如用户输入包含“退货”“退款”“投诉”等关键词时直接路由到售后流程。内容生成和复杂推理用主力大模型。商品推荐理由生成、多商品对比分析、生成退换货话术这类任务需要更强的语义理解和生成能力必须要上主力模型。建议选择一个工具调用能力成熟、幻觉率低、且支持流式输出的模型。另外我强烈推荐在调用层加一个路由规则售价高的商品、VIP 用户的会话、涉及复杂纠纷的对话都自动升级为最强模型处理普通流量默认走轻量模型。这类成本控制策略在理论上很美好真正开始用才发现优化空间惊人——把不必要的高成本请求切到轻量模型上之后token 费用大约直接省了近一半。4.3 工具调用的安全与可靠性Agent 要真正干活就必须调用外部 API。这里的安全问题比单模型时代严重得多。一个 LLM 即使再聪明也没有天然的“权限意识”不能让它拿到什么接口就随便调。我采用的方案是给每个工具做三级封装工具元信息层用 JSON Schema 定义输入输出参数让模型知道怎么调用。权限校验层对应 Agent 携带权限 Token每个 Token 只暴露该 Agent 必须用到的接口名单。操作审计层记录每次调用的时间、参数、结果并设置高危操作的二次确认机制。举例来说售后 Agent 可以调“查订单”“创建退货单”这两个接口但不能调“修改订单价格”“直接退款”这类高权限操作——这类操作必须走人的审批。在电商场景里任何涉及资金变动的操作都应当有明确的“人类确认”环节这不是怕 AI 出错而是为了责任链清晰。4.4 记忆体系与上下文管理Multi-Agent 系统的上下文管理比单 Agent 复杂很多。每个 Agent 都需要知道自己领域内的上下文同时也要了解全局对话的概要。全量会话记忆如果每次都传给所有 Agenttoken 成本会爆炸。我的解法是分层记忆短期记忆当前消息及其关联的最近 5 轮消息存放在会话内存里。中期记忆当前流程节点的关键信息订单号、商品 ID、用户 ID 等存成键值对写入共享记忆体。长期记忆用户的历史偏好、消费习惯、历史售后记录存向量数据库按需检索获取。每个 Agent 从共享记忆体里读取自己需要的内容名称不是被动接收全部内容。这有点像一个公司里各业务线只关注自己领域的数据指标一样既省资源也避免无关信息干扰。5. 实操过程中的经验与避坑指南这一章全部是趟过水之后的干货有些是我调研了很久才反推出来为什么该这么做的。分享几个我觉得最能帮大家少走弯路的经验。5.1 给写好 Agent 的两个核心提示词技巧很多人的 Prompt 写了很长结果模型还是不听使唤往往是因为没有把“角色的能力边界”和“工作流程”边界说清楚。1给每个 Agent 定义一个固定的输出协议让模型的输出结构稳定且可解析。例如经过反复验证让模型先输出判断推理再以固定 JSON 结构输出工具调用参数。这比直接“请你总结商品特点”这样的飘渺要求好调太多。2为每个 Agent 配备一套极小样本根本不需要很长的推理示例。选 23 个极端情况做示例每个示例包含用户说了什么、Agent 该调用什么工具、输出什么样的话术模型很快就能学会风格且不容易跑偏。这里分享一个调试技巧在开发环境打开所有 Agent 的“思考轨迹”日志看清模型每一步在判断什么、为什么这么判断。上线后可以把这些日志关掉但排查问题时一定需要。5.2 多 Agent 上下文污染问题这是多 Agent 系统里最容易出的问题也是最难排查的。现象就是 Agent A 处理过的冗余信息被 Agent B 读到导致 Agent B 的回答里出现不该出现的内容。比如售后 Agent 处理的“退款金额”内部字段如果被商品推荐 Agent 读取到它可能会在推荐话术里莫名其妙列出一堆退款明细用户一脸懵。解决手段就是在共享记忆体里做严格的字段可见性控制。给每个字段打上“可被谁读取”的 Tag编排引擎在传递上下文的时候做一次过滤。本质上这和后端系统里的数据权限设计是同构的——不是所有数据对所有模块可见。5.3 Agent 与人的协作边界设计电商系统跑真实业务后发现一个规律用户对 AI 的期望不是“无所不能”而是“反应快 别乱来”。所以我们在设计 Agent 时特别注重“何时让位给人”的机制设计。定义三类必须转人工的场景情绪激烈检测到用户连续出现愤怒词汇、投诉升级词汇。多次失败Agent 连续 2 次尝试都未能解决用户问题。高风险操作涉及高额退款、法律纠纷、安全投诉等。转人工时不能让用户感到“被抛弃”Agent 要把当前对话的摘要、已执行过的操作、判断依据一并传给人工客服工作台这样人工客服不用再问一遍用户“你之前说的是什么”体验会好很多。5.4 效果评测与持续优化评测体系是这套系统能不能长期迭代的关键。我们搭建了一套从数据回流、离线评测到线上监控的完整闭环日常主要盯这几项指标指标定义目标值意图识别准确率是否正确识别用户核心意图≥ 95%工具调用成功率Agent 调用 API 的成功占比≥ 95%问题解决率用户问题是否在本次会话内被闭环解决≥ 80%转人工率需要人工接管的会话占比≤ 15%用户满意度会话结束后的用户评分≥ 4.2/5线上监督的关键是用好“隐式反馈”用户没有明确说“解决了”也没给差评不代表体验好还要观察用户是否在同一会话里反复问同类问题。比如用户问“怎么退货”之后又问“退款要多久”说明前一个 Agent 的回答没有覆盖到用户关心的点。按这个思路持续挖掘隐式反馈是不花钱就能获得的高质量标注数据。6. 常见问题与排查思路速查表下面这个表格是根据实际运维中拦截到的高频问题整理出来的每一条都是真实发生过的坑和对应的排查路径。现象可能原因排查方法解决方案Agent 回答了和当前商品无关的内容共享记忆体中残留了上一个会话的数据查看会话记忆体的生命周期与清理时机会话结束清理短期缓存记忆体增加隔离字段多个 Agent 同时抢着回复意图识别不精确或编排路由出现并发分支分析意图识别日志与路由结果强化带权路由机制限制单请求只能激活一个主 Agent工具调用返回异常但 Agent 毫无察觉工具调用结果被模型忽略查看工具结果解析日志检查返回内容是否被截断在工具结果中增加强标记并让 Action 阶段强制校验用户连续追问时 Agent 忘记历史信息短期记忆窗口太短查看当前上下文的拼接长度动态调整记忆窗口或引入中期记忆摘要响应耗时经常超过 5 秒某个 Agent 串行处理任务过多分析链路耗时的每一步详情将并行任务拆成多条链路并发执行或引入缓存机制同一问题两次回答结果截然不同模型温度参数设置不当对比两次推理日志中的采样参数降低模型温度值或对关键回流问题固定采样种子还有一个容易被忽视的系统性坑消息并发时序问题。用户可能同时发来两条消息如果编排系统简单按时间顺序处理后一条消息可能覆盖前一条的工作状态。我们的处理方案是在接入层就给每条消息打上全局自增序号状态机只有收到序号大于当前状态的消息才允许转移否则排队等待。这个看似是传统后端的问题在 Multi-Agent 系统里预想不到地高频出现尤其在用户手速快的场景下一定要提前在设计里考虑好。7. 一些系统的设计心得文章写到这这套 Multi-Agent 电商系统的主要设计和实操方法论已经完整铺开了。最后想再说几句个人的整体感受。这套系统做下来我最大的认知转变是Multi-Agent 的核心难点不在于“让每个 Agent 变聪明”而在于“把一堆聪明的 Agent 组织成不混乱的系统”。单个 Agent 的效果只要模型足够强、Prompt 设计合理基本差不到哪里去但真正拉开差距的地方是编排流程、共享状态设计、错误处理、权限控制这些工程细节。电商是一个容错率很低的场景用户不会因为你用了先进的技术就原谅你推荐了不应该推荐的东西、回答了一个错误的退货政策。所以在工程化过程中我反复和团队强调一个原则做一个让用户觉得“这个助手很靠谱”的系统比做一个“看起来很智能”的系统重要得多。这条原则后来帮我们挡掉了很多不必要的炫技需求。还有一点关于迭代的体会Multi-Agent 系统不能指望一次设计到位。我们第一版只设计了三个 Agent后来根据实际会话数据和业务需求慢慢增加了购物车助手、售后质检、促销分析等角色。每个新 Agent 上线前都跑了一周左右的影子模式——只记录它的决策结果不直接影响用户确认效果稳定后才正式放量。这种渐进式扩展的思路非常适合 Multi-Agent 这类复杂度高、影响面大的系统。如果这篇文章对你有帮助建议先从自己的业务链路里挑一个高频且边界清晰的场景比如售后处理试点做单 Agent跑通之后再扩展到多 Agent 协作。等第一套流程真正稳定下来之后再回头看我上面说的这些工程化细节你会发现自己已经有能力应对更复杂的编排了。