企业官网建设流程全解析

最近在带团队做一套面向电商场景的多智能体系统，从拆解需求到第一版可跑通的 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 如果都做一次意图猜测，既浪费 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 都需要知道自己领域内的上下文，同时也要了解全局对话的概要。全量会话记忆如果每次都传给所有 Agent，token 成本会爆炸。

我的解法是分层记忆：

• 短期记忆：当前消息及其关联的最近 5 轮消息，存放在会话内存里。
• 中期记忆：当前流程节点的关键信息（订单号、商品 ID、用户 ID 等），存成键值对写入共享记忆体。
• 长期记忆：用户的历史偏好、消费习惯、历史售后记录，存向量数据库，按需检索获取。

每个 Agent 从共享记忆体里读取自己需要的内容名称，不是被动接收全部内容。这有点像一个公司里各业务线只关注自己领域的数据指标一样，既省资源，也避免无关信息干扰。

5. 实操过程中的经验与避坑指南

这一章全部是趟过水之后的干货，有些是我调研了很久才反推出来为什么该这么做的。分享几个我觉得最能帮大家少走弯路的经验。

5.1 给写好 Agent 的两个核心提示词技巧

很多人的 Prompt 写了很长，结果模型还是不听使唤，往往是因为没有把“角色的能力边界”和“工作流程”边界说清楚。

（1）给每个 Agent 定义一个固定的输出协议，让模型的输出结构稳定且可解析。例如经过反复验证，让模型先输出判断推理，再以固定 JSON 结构输出工具调用参数。这比直接“请你总结商品特点”这样的飘渺要求好调太多。

（2）为每个 Agent 配备一套极小样本，根本不需要很长的推理示例。选 2～3 个极端情况做示例，每个示例包含用户说了什么、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 效果评测与持续优化

评测体系是这套系统能不能长期迭代的关键。我们搭建了一套从数据回流、离线评测到线上监控的完整闭环，日常主要盯这几项指标：

线上监督的关键是用好“隐式反馈”：用户没有明确说“解决了”也没给差评，不代表体验好，还要观察用户是否在同一会话里反复问同类问题。比如用户问“怎么退货”之后又问“退款要多久”，说明前一个 Agent 的回答没有覆盖到用户关心的点。按这个思路持续挖掘隐式反馈，是不花钱就能获得的高质量标注数据。

6. 常见问题与排查思路速查表

下面这个表格是根据实际运维中拦截到的高频问题整理出来的，每一条都是真实发生过的坑和对应的排查路径。

还有一个容易被忽视的系统性坑：消息并发时序问题。用户可能同时发来两条消息，如果编排系统简单按时间顺序处理，后一条消息可能覆盖前一条的工作状态。我们的处理方案是在接入层就给每条消息打上全局自增序号，状态机只有收到序号大于当前状态的消息才允许转移，否则排队等待。这个看似是传统后端的问题，在 Multi-Agent 系统里预想不到地高频出现，尤其在用户手速快的场景下，一定要提前在设计里考虑好。

7. 一些系统的设计心得

文章写到这，这套 Multi-Agent 电商系统的主要设计和实操方法论已经完整铺开了。最后想再说几句个人的整体感受。

这套系统做下来，我最大的认知转变是：Multi-Agent 的核心难点不在于“让每个 Agent 变聪明”，而在于“把一堆聪明的 Agent 组织成不混乱的系统”。单个 Agent 的效果只要模型足够强、Prompt 设计合理，基本差不到哪里去；但真正拉开差距的地方，是编排流程、共享状态设计、错误处理、权限控制这些工程细节。

电商是一个容错率很低的场景，用户不会因为你用了先进的技术就原谅你推荐了不应该推荐的东西、回答了一个错误的退货政策。所以在工程化过程中，我反复和团队强调一个原则：做一个让用户觉得“这个助手很靠谱”的系统，比做一个“看起来很智能”的系统重要得多。这条原则后来帮我们挡掉了很多不必要的炫技需求。

还有一点关于迭代的体会：Multi-Agent 系统不能指望一次设计到位。我们第一版只设计了三个 Agent，后来根据实际会话数据和业务需求慢慢增加了购物车助手、售后质检、促销分析等角色。每个新 Agent 上线前都跑了一周左右的影子模式——只记录它的决策结果，不直接影响用户，确认效果稳定后才正式放量。这种渐进式扩展的思路，非常适合 Multi-Agent 这类复杂度高、影响面大的系统。

如果这篇文章对你有帮助，建议先从自己的业务链路里挑一个高频且边界清晰的场景（比如售后处理）试点做单 Agent，跑通之后再扩展到多 Agent 协作。等第一套流程真正稳定下来之后，再回头看我上面说的这些工程化细节，你会发现自己已经有能力应对更复杂的编排了。