Multi-Agent电商系统设计：角色划分、编排与实战踩坑

去年年中，我给一个社区电商项目做"AI全流程服务"的售前Demo。初期方案很朴素：一个Agent、一个超长Prompt，把客服、导购、订单查询、售后退款全塞进去。结果试运行第三天就翻车——用户问"我上周买的保温杯能退吗"，Agent先是把"保温杯"理解成了购买意图，给人家热情推荐了三款新杯子，然后又在退货政策上即兴发挥，编了一条"七日无理由"——而那款是定制款，根本不在无理由范围内。我事后复盘，问题不在模型，而在方案本身：电商业务天然是一堆角色的活，你硬让一个Agent全干，它一定会串戏、越权、编造。这就是我这篇文章想聊的事：Multi-Agent电商系统设计，不是追热点，而是被现实逼出来的解法。

这篇文章会把我在实际项目里的完整设计思路摊开来讲：为什么电商场景必须走多智能体，角色怎么划分、编排怎么做、记忆和工具怎么管、代码骨架怎么搭，以及上线后踩过的那些藏在文档之外的坑。适合正在做电商客服、智能导购、订单售后自动化，或者单纯想用多Agent做业务系统的朋友参考。

1. 为什么电商系统需要"多个智能体"而不是一个大模型

1.1 单体智能体一肩挑的真实困境

先说说我那个翻车的Demo。当时我把所有业务规则写在了一个Agent的system prompt里：商品推荐规则、优惠计算规则、退货政策、物流查询说明，加起来快三千字。第一个问题是指令遵循率明显下降，长Prompt里排在后面的规则经常被模型忽略；第二个问题是上下文污染，用户聊着退货，Agent还惦记着前两轮的商品推荐，把两件事搅在一起；第三个问题更致命——权限没法收口。这个Agent手里同时握着商品检索、订单查询、退款申请的权限，模型一旦判断错误，就可能做出真实的越权操作。它把"查询订单"误用成"发起退款"，在测试环境里真的给一笔订单生成了退款工单，幸好是测试数据。

这三个问题其实是单体方案的必然结果：一个上下文窗口要同时装下多个岗位的专业知识、沟通风格和数据权限，互相干扰只是时间问题。电商业务的复杂度不是一个模型能撑住的，而多智能体的本质，就是把一个超长Prompt拆成多个"小而专"的Prompt，每个Agent配专属工具和专属记忆，各自守住一条业务线。

1.2 电商业务天生是一张"多人协作"的网

想清楚这一点，再看电商系统就会很自然：用户从进线咨询到收货售后，整个链路涉及的角色不下七八个——导购要热情、要懂推荐；客服要耐心、要会查单；售后要严格按政策判断；风控要铁面无私；库存要实时准确。这些角色的沟通风格、判断标准、数据权限完全不同。

我常用一个类比：单体Agent像一个"全能店员"，什么都会一点，但顾客问退款时他得翻手册，问库存时他得去仓库现看，还经常记错政策；多智能体则像一家正规门店——前台导购、客服专员、售后专员、库管各司其职，顾客要退货，前台只需要把他领到售后专员那儿，售后专员按手册判断，再让库管确认货品状态，每一步都有人负责、有据可查。

所以多Agent不是技术上的炫技，而是对电商业务结构的直接映射。每个Agent只维护自己的专业领域、只调用自己的工具集、只记住自己该记的东西，业务复杂度被拆散了，单点的出错率和维护成本反而降下来了。

1.3 成本账也要算清楚：不是每个Agent都要上大模型

聊多Agent，很多人第一反应是"成本爆炸"——一个Agent调一次大模型，十个Agent不得翻十倍？实际账不是这么算的。电商链路里的Agent分两类：一类是对话型，比如导购、客服，要理解复杂表达、要生成自然语言，确实需要高性能模型；另一类是任务执行型，比如订单查询、库存扣减、价格计算，本质上是结构化输入输出，完全可以用小模型甚至规则脚本完成。

在我设计的系统里，订单Agent和库存Agent的"大脑"就是一个轻量模型加一套工具调用，绝大多数情况下，它们根本不需要生成自然语言，只需要从数据库拿到结构化结果返回给上层。只有真正面对用户的导购、客服、售后才调用大模型。整体算下来，平均每轮用户交互的token消耗，比单体大模型方案反而低不少，因为单体方案每一轮都要把三千字的业务规则全部吃进去。

2. 智能体的"岗位说明书"：先把角色边界定清楚

2.1 前台三件套：导购、客服、售后

做多Agent系统，最容易犯的错是不分青红皂白先写代码，结果Agent之间职责重叠，用户问个退款，导购和客服抢着答，答案还不一样。我的做法是，开工前先给每个Agent写一份岗位说明书，明确职责边界、输入输出、可用工具和绝对禁区。前台三个Agent是这样分的：

这套划分的核心逻辑是：每个Agent只对自己那一亩三分地负责。导购Agent的Prompt里完全没有退货政策的内容，所以它绝不可能生成"可以退"这样的话；客服Agent只负责查询和解释，不拥有发起退款按钮的权限，所以哪怕它被诱导说出了"我给您退"，实际操作也执行不了。这就是权限隔离的价值——模型可以胡说，但工具调用权限和业务逻辑不允许它越权。

2.2 中台角色：订单、库存、商品是"执行者"

前台Agent是给用户看的，中台Agent则是给系统自己用的。订单Agent管理订单生命周期的查询和状态流转，库存Agent负责库存锁定和扣减，商品Agent管上下架和基础信息维护。这三个Agent基本不直接面对用户，更像是被前台Agent调用的"内部服务"。

这类执行型Agent的设计要点是：不要给它自由发挥的空间。我一般要求它们输出严格的结构化结果，比如订单Agent的返回必须是{order_id, status, amount, items, returnable}这样的JSON，不允许输出多余的自然语言。这样上层Agent拿到的数据是干净的，不会因为订单Agent"话多"而产生理解偏差。实际开发中，这类Agent甚至可以考虑不调大模型，直接用工具函数加规则判断，性能和稳定性都更好。

2.3 后台角色：定价、风控、供应商

后台角色决定了系统"会不会乱来"。定价Agent负责计算促销价、校验毛利底线；风控Agent负责识别恶意行为、审核退款和改价请求；供应商Agent负责根据库存和销售预测给出补货建议。

这三个角色在用户不可见的地方工作，但它们的存在非常关键。没有风控Agent，售后Agent发起的每一笔退款都会直接执行，恶意用户可能利用模型的漏洞反复薅羊毛；没有定价Agent，导购Agent随口承诺的折扣可能把毛利压到负数。我把它们设计成只接受请求、返回审批结果的模式——任何涉及钱和价格的变更，都必须经过它们的闸口。

2.4 角色设计的三条铁律

折腾过几轮之后，我总结了三条角色设计原则，现在每次画Agent列表之前都会过一遍：

1. 一件事只有一个主责Agent。用户问"能不能退"，主责是售后Agent，客服和导购最多做引导，不能直接给结论。
2. 权限最小化。每个Agent的工具集只包含完成本职工作的最小集合，不要给导购开退款权限，也不要给客服开改价权限。
3. 依赖关系画成有向无环图。Agent之间的调用关系必须单向清晰，不能出现A依赖B、B又依赖A的环，否则编排层容易死循环。我会在文档里画一张依赖图，每个Agent只允许依赖它的下游Agent，不跨级调用。

3. 编排与通信：让一群"各怀绝技"的Agent不打架

3.1 三种编排模式怎么选

Agent有了，角色分好了，接下来就是怎么组织它们干活。我见过三种编排方式：中心化编排是一个Orchestrator接收用户请求，决定派发给哪个Agent，收集结果后统一返回；层级编排是有一个主管Agent负责拆解复杂任务，下发给多个子Agent并行执行；点对点编排是Agent之间直接互发消息，没有中心节点。

三种模式各有适用场景。中心化优点是可控、好追踪、容易加超时和重试，缺点是Orchestrator可能成为瓶颈；层级适合"帮用户对比十款手机"这种需要并行收集信息的复杂任务；点对点最灵活，但问题链路一旦拉长，排查问题会非常痛苦。我的实践结论是：电商场景以中心化编排为主，少量必须的场景允许点对点。95%的请求走中心化，只有像"大促期间批量比价"这种明确需要并行收集的场景，才让导购Agent临时拉起几个子Agent并行工作。

3.2 Agent之间的"普通话"：消息协议

多Agent系统要稳定运行，Agent之间得说同一种语言。我定义了一套统一的JSON消息协议，所有Agent之间的通信都走这个结构：

{ "msg_id": "m_8f3a21c9", "request_id": "req_20250111_0001", "from": "orchestrator", "to": "after_sale_agent", "task_type": "evaluate_return", "payload": { "order_id": "SO202501100021", "user_id": "U12345", "reason": "leaking", "evidence_text": "保温杯倒放后漏水" }, "ttl_ms": 3000, "priority": 1 }

每个字段都有讲究：msg_id是这条消息的唯一标识，用于去重和日志追踪；request_id贯穿一次用户请求的全链路，所有Agent的日志都要带上它；from和to决定了路由方向；task_type是任务类型，Agent根据它分发到不同的处理逻辑；payload是结构化业务数据；ttl_ms是超时控制，防止某个Agent卡死导致整条链路挂起。

这套协议最大的好处是让Agent之间的通信从"自然语言"降级成"结构化数据"。Agent之间的消息和最终面向用户的回复是两回事，面向用户的部分可以让前台Agent用自然语言润色，但Agent之间必须用机器可解析的结构，这样每一跳都是可验证、可重试的。

3.3 一次退换货请求的完整调用链

拿"昨天买的保温杯漏水想退"这个场景，走一遍完整的调用链：

1. 入口Agent收到用户消息，意图识别为"售后/退换货"，把请求连同request_id转给Orchestrator。
2. Orchestrator根据意图路由，把任务派发给售后Agent，附上用户ID和原文。
3. 售后Agent发现自己需要订单信息，于是按协议向订单Agent发起查询请求。
4. 订单Agent调用订单查询工具，返回{order_id, status: "delivered", item: "定制保温杯", days_since_delivery: 1}。
5. 售后Agent再调用政策库工具，查询该商品的售后政策，工具返回"定制类商品不支持无理由退货，但因质量问题可退，运费由商家承担"。
6. 售后Agent判断漏水属于质量问题，生成退款工单，并调用风控Agent审核该用户的历史行为。
7. 风控Agent返回"无异常"，退款工单状态置为"待执行"，同时通知支付系统进入退款流程。
8. 售后Agent生成给用户的回复："检测到您的杯子存在质量问题，符合退货条件，运费由我们承担，退款将在1-3个工作日原路退回。"

每一步都有据可查：谁在处理、调了什么工具、结果是什么。用户感知到的是一条流畅的回复，背后其实是四五个Agent和十几次工具调用的协作。

3.4 冲突与仲裁：当两个Agent意见不一致

Agent一多，意见冲突是必然的。我踩过的典型案例是：导购Agent为了促成转化，对用户承诺"这款再给您便宜20"，但定价Agent算下来这笔订单毛利已经是负数。两个Agent各说各话，用户信了导购，最后系统拒绝执行，体验极差。

解决方案是建立仲裁规则：凡是涉及价格、折扣、退款的承诺，导购Agent和客服Agent都没有最终决定权，必须调用定价Agent或售后Agent的"校验接口"确认后才能对外承诺。校验接口返回allowed/denied以及原因，前台Agent只能转述结果，不能自行修改。仲裁规则里还要留一道口子：如果某个Agent发现自己在三秒内无法确认结果，必须说"稍等，我帮您确认一下"，把不确定性转成查询动作，而不是给一个拍脑袋的回答。

4. 记忆、状态与工具：Agent能不能"干成事"就靠这三样

4.1 短期记忆与长期记忆的分工

Agent要真正干活，光有角色和编排还不够，它得"记得住事"。我把它分成两层：短期记忆是当前会话的上下文，比如用户这次进来聊了什么、已经确认了哪些信息；长期记忆是跨会话的持久信息，比如用户的历史订单、偏好类目、退换货记录。

多Agent场景下，记忆共享是个容易翻车的地方。我一开始让每个Agent都去查用户全量历史，结果每个Agent拿到的上下文又乱又长，反而干扰判断。后来改成：Orchestrator统一维护一个"用户上下文摘要包"，在派发任务时，只把当前任务相关的摘要注入对应Agent。比如售后Agent只需要知道"该用户历史退换货3次、其中1次疑似恶意"，不需要知道他最近浏览过什么商品。这样既保留了必要的记忆，又避免了无关信息干扰。

4.2 工具调用：让Agent不再"纸上谈兵"

电商Agent的核心能力全在工具调用上。系统里挂了这样一批核心工具：search_products（商品检索）、get_order_detail（订单详情）、create_refund_ticket（创建退款单）、check_inventory（库存查询）、calc_promotion_price（促销价计算）。每个Agent的Prompt里注明它可以用哪些工具，工具清单就是Agent的"权限边界"。

工具调用的关键规范是让工具返回结构化数据。我统一要求所有工具返回JSON，例如get_order_detail返回{order_id, status, amount, items: [{sku_id, name, qty, price}]}，禁止返回一大段格式化文本让模型去"理解"。结构化的返回意味着模型不需要做信息抽取，直接把这些字段填进下一轮工具调用的参数里，幻觉的空间小很多。

4.3 状态一致性与幂等：最容易被忽视的坑

多Agent协作衍生出一个单体系统不太会遇到的问题：同一个请求可能被多个Agent重复触发。比如用户退款，售后Agent第一次调用create_refund_ticket超时了，按照重试机制又发了一次，如果这个接口不是幂等的，系统就会生成两笔退款工单，用户收到两笔钱。

解决方法是给所有写操作加上幂等键。create_refund_ticket接口要求必须传request_id，每次重试用同一个request_id，数据库对这个字段建唯一索引，重复的请求直接返回第一次的结果。类似的还有库存扣减、价格修改，凡是写操作一律幂等。这个设计让我少挨了很多骂，强烈建议在做架构的时候就把幂等性当成基础设施来建，而不是等出事了再补。

4.4 会话归属与交接摘要

用户在多轮对话里会在Agent之间被转手，比如从导购聊到下单，再从客服聊到售后。问题来了：每个Agent都读全量聊天记录，token白烧不说，还容易读到无关信息。我的做法是维护会话状态服务，每轮对话结束后，当前主责Agent生成一段"交接摘要"，结构化地记录：用户ID、意图、已确认信息、待办事项、当前危险标记。Orchestrator把Agent切换时，只把交接摘要注入新Agent的上下文。

举个例子，用户从"想买保温杯"（导购Agent）聊到"之前买的那款漏水要退"（售后Agent），售后Agent拿到的交接摘要是{user: U12345, intent: 购买咨询→售后, mentioned_previous_order: true, order_hint: "上周保温杯"}，它顺着这个提示去查订单，不用把整段购物咨询记录都读一遍。

5. 落地架构与代码骨架：照着能跑的最小实现

5.1 整体架构分层

纸上谈兵讲完了，说说怎么落地。一套可用的多Agent电商系统，我习惯分成六层：

1. 渠道接入层：小程序、App、第三方IM等入口，负责消息收发和用户身份识别。
2. 入口路由层：做意图识别，判断请求是闲聊、购物咨询、订单查询还是售后服务，并打上intent标签。这层可以不用大模型，用轻量分类模型甚至规则就够。
3. 编排层（Orchestrator）：接收intent，决定派发给哪个Agent，管理消息路由、超时、重试、仲裁。
4. Agent层：各个业务的智能体，对话型和执行型都在这一层。
5. 工具层：商品服务、订单服务、库存服务、政策库、风控服务等，以内部API形式暴露给Agent调用。
6. 数据层：用户画像库、订单库、会话状态库、长期记忆向量库、日志追踪库。

各层之间单向依赖，上层只能调用下层，Agent不能直接访问数据库，必须通过工具层。这个约束保证了权限可控制、访问可审计。

5.2 一个Agent的最小实现骨架

以售后Agent为例，我用Python写过一个最小骨架，核心就是一个类加一套工具注册：

class Agent: def __init__(self, name, system_prompt, tools, llm_client): self.name = name self.system_prompt = system_prompt self.tools = tools # {tool_name: callable} self.llm_client = llm_client async def handle(self, message, context_bundle): messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": message}, {"role": "system", "content": f"上下文摘要包: {json.dumps(context_bundle, ensure_ascii=False)}"} ] while True: resp = await self.llm_client.chat(messages, tools=self.tool_schemas()) if resp.tool_calls: for tool_call in resp.tool_calls: result = self.tools[tool_call.name](**tool_call.args) messages.append({"role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False)}) continue return resp.content

这个循环的逻辑很朴素：模型说要调用工具，系统就执行工具并把结果塞回对话，再让模型基于工具结果继续，直到模型直接给出最终回复。每轮工具调用都带上tool_call_id，确保多工具调用的返回能对上号。

售后Agent的Prompt我写得很克制，核心就两条：一，所有退货政策判断必须来自政策库工具返回的原文；二，涉及金额超过500元必须转人工审核。Prompt里明确写了"禁止自己推断退货政策，如果你不知道，请先调用工具查询"。

5.3 编排器的调度主循环

Orchestrator是整个系统的心脏，它的主循环大概是这样的：

async def orchestrator_run(user_input, session_state, context_bundle): request_id = generate_request_id() intent = await intent_router.classify(user_input) agent_name = ROUTE_TABLE[intent] # 意图->主责Agent映射 agent = agent_registry.get(agent_name) try: reply = await asyncio.wait_for( agent.handle(user_input, context_bundle), timeout=AGENT_TIMEOUT_MS ) except TimeoutError: reply = await fallback_to_manual(agent_name, user_input) save_session_state(session_state, request_id, intent, agent_name) return reply

ROUTE_TABLE就是一张意图到Agent的静态映射表，比如purchase_consult -> guide_agent、order_query -> service_agent、after_sale -> after_sale_agent。这张表是系统稳定性的基石，不建议让模型来动态决定路由，规则判断比模型判断更可靠，出错也更好排查。超时兜底是必须的，我一般给客服场景3秒超时，超时后直接转人工，不让用户干等。

5.4 人工兜底：Human-in-the-loop设计

多Agent再怎么自动化，也不能把所有事情都交给模型。我在系统里定义了一张"高危操作转人工"的规则表：

人工兜底在系统设计上的体现是：所有高危操作都不是Agent直接调用工具完成，而是Agent先生成"工单"，工单进入审核队列，人工审核通过后才有权限触发真正的写操作。这样既保留了AI处理大部分常规请求的效率，也在关键链路留了人的判断。

6. 真实上线后踩过的坑：这些教训文档里没有

6.1 Agent踢皮球：转交失控

上线第一个星期，我就遇到了"踢皮球"问题。用户问了个稍微复杂的问题——"我想把A商品退了，再补差价换成B商品，能行吗"，结果导购Agent说"退货请联系售后"，售后Agent说"换货差价请咨询导购"，用户被来回转了两三次，最后直接在对话里发火。

排查下来，发现问题是Agent的Prompt里都写了"如果不属于我的职责，请引导用户联系对应Agent"，这句话本身没错，但模型会把大量模糊请求都判定为"不归我管"，反正把用户推给别人最省事。修复方案是引入主责Agent制：意图路由一旦确定主责Agent，它就是这次会话的责任人，不允许主动转出，只能让Orchestrator协调其他Agent提供辅助，最后由主责Agent汇总作答。同时在协议层限制同一会话转交次数不超过3次，超过就强制进人工。

6.2 Token消耗与延迟失控

多Agent系统的成本问题，比单体翻车更隐蔽。我有一段时间看监控，发现每次简单咨询平均要调4次模型，响应时间超过4秒，账单也涨得飞快。定位后发现两个原因：一是意图路由层用了大模型做分类，每条消息都花一次调用；二是很多Agent在简单的场景里把工具调用链拉得太长——用户问"发货了没"，客服Agent先查订单、再查物流、再让大模型写一段感谢语，完全没必要。

对策是把模型分级：意图路由改用规则加轻量分类模型；简单查询类请求直接走工具函数返回模板化回复，不经过大模型；只有真正需要生成自然语言回应的复杂对话才调用大模型。优化后，接近60%的请求根本不需要大模型参与，平均响应时间降到1.2秒，成本降了七成。

6.3 幻觉在电商场景的放大效应

电商场景的幻觉比通用聊天严重得多，因为用户是带着真金白银来的。最典型的是客服Agent编造政策，比如明明不支持退的定制商品，它为了"让用户满意"说可以退；或者把运费赔付标准说错，导致用户投诉升级。

我的应对有三层：第一，政策性信息一律从工具查，Prompt里写死"只能引用政策库工具返回原文，禁止自行推断"；第二，输出前做实体校验，在Agent返回之前，用一个轻量校验器检查回复里出现的金额、日期、天数是否与工具返回的数据一致，不一致就打回重写；第三，给Agent配"不知道"的自由，允许它说"我需要确认后答复您"，它有了退路，就不必硬编了。

6.4 可观测性：给每个Agent装上日志

多Agent的运维，最崩溃的瞬间是用户投诉说"你们客服乱承诺"，你翻日志发现根本不知道当时哪个Agent说了什么、依据是什么。我后来学会了：可观测性必须是第一优先级的基础设施。每个请求从入口就带上trace_id，每一跳Agent调用、每一次工具调用、每一次大模型请求都要记录：输入消息、输出回复、工具参数、返回结果、token数、耗时。

有了这套日志，定位踢皮球问题只花了五分钟：按trace_id查链路，看到同一个用户请求在三个Agent之间转了两轮，每轮都调了模型，一目了然。日志字段我统一是：trace_id, request_id, agent_name, action_type, input_hash, output, tool_calls, latency_ms, token_count, timestamp。这套字段成了我后来每个项目的标配。

6.5 降级策略：大模型挂了怎么办

最后聊聊稳定性。多Agent系统引入了一个单体系统没有的单点：大模型API。它一抖动，整个客服体系就瘫了。我做了三级降级：第一步，模型API超时自动重试一次，仍失败就切备用模型；第二步，备用模型也失败时，关键路径降级到规则引擎——订单查询、物流查询这类结构化请求直接走工具函数返回结果，只是回复措辞固定一点；第三步，完全不可用时，入口直接转人工客服，并在对话里提示"当前咨询量较大，已为您转接人工"。降级策略需要提前想清楚，别等线上事故了再临时写，那时候手忙脚乱一定会出更大的乱子。

最后再分享一个小经验：多Agent系统里，最贵的成本从来不是token，而是排查问题的工时。我吃过没打全日志的亏，也吃过权限没收口的亏，这些坑其实都写在"岗位说明书"和"消息协议"里，关键是开工前愿不愿意多花两天把这些基础设计做扎实。如果你现在正准备做类似的系统，我的建议是从第一天就把trace、幂等、转交上限这三件事写进代码规范，后面能省下无数个加班的夜晚。