京东商家智能助手：Multi-Agents 在电商垂域的探索与创新

电商助手是一款集合了多种电商经营决策功能的工具软件，旨在帮助电商从业者完成从商品发布到订单管理、客服沟通、数据分析等一系列电商运营任务。

京东零售基于 Multi-Agents 理念搭建了商家助手大模型在线推理服务架构，这一系统的核心是算法层基于 ReAct 范式定制多个 LLM AI Agents，每个 Agent 都有专门业务角色和服务功能，可以调用不同的工具或多 Agent 协同工作来解决相应的问题。

以下是京东零售全渠道生态部关于《京东商家智能助手：AI 多智能体系统在电商垂域的探索与创新》的探索实践，包括Multi-Agents 如何模拟真实的商家经营、ReAct 范式的 Multi-Agent 在线推理架构，以及Agent 落地垂域的样本、训练与评估监控的方法。欢迎大家一起交流

现实中，商家如何进行经营决策

Agent 需要模拟人类的决策过程，因此需要先了解现实中的经营是如何进行的。

通常，平台向商家传递各种各样的信息，包括新的玩法、新的规则条款，以及可能的惩罚通知等。面对平台的各种消息和随之而来的疑问，商家需要一个经营助手协助，他通常扮演着一个专门提供平台知识百科的咨询顾问角色。

当商家提出赔付、运费等与业务相关的复杂问题，需要先理解需求，然后从长篇的业务文本中抽取出问题解决的大方向或目标。定位问题后，形成逐步的解题思路，再灵活调用各种资源和工具来解决问题，其中包括调用知识库、进行搜索和检索，以及使用人脑进行总结和筛选重点内容。经过这一系列操作后将问题的最终答案返还给商家。

那么如何将现实空间的平台咨询顾问映射到 Agent？顾问这个角色是我抽象出来的，京东实际上并没有这样的角色。对于商家来说，每天提供专属服务的实际上是我的许多同事，包括在线客服、业务运营人员以及产品经理，他们解答各种问题。那是否需要为每个岗位角色构建一个 Agent？解决这个问题时，我们还要回到应用场景，从商家的需求出发：无论谁在回答问题，对商家来说都只有一个人帮助他们解答问题。因此，构建一个 Agent 即可，它映射到为商家提供专属咨询服务的多个业务岗位的人。 构建这样一个 AI 版的 Agent 对商家和平台都有好处。对商家而言，他们将体验到一个永远在线的百科全书，能够突破时间、体力和知识掌握的极限。对平台来说，可以降低成本。

除了上面单一的 agent 提供专属服务的情况，当我们讨论到多领域助手与商家的经营协作时，整个团队是如何协作经营的呢？比如，商家提出了一个问题：“最近我的店铺经营得怎么样？”这个问题看似简单，但实际上是商家每天在处理完各种信息后首先会思考的。

对于现代电商商家来说，了解经营状况通常从查看数据开始，然后才能评估经营状况。他不会直接去系统读取数据或编写数据库查询语言，而是直接“调度”数据分析师这一角色，因为商家清楚自己的目标是数据相关的服务。于是，他将任务分配给团队中的数据分析专家，这位专家经过一系列操作后，会返回给商家一份数据报告。接下来，商家需要阅读并理解这份数据报告，他可能会发现新用户的留存率不佳的问题。这时，商家会根据新发现的问题更新决策。

商家的上述过程是 agent ReAct 范式的一个典型例子，即基于观察（observation）来更新整个推理（reasoning）过程。 在解决问题的思路上，人类和 Agent 非常相似。

接下来，更新的决策就是商家重新选择一个角色，比如用户研究专家，来分析新用户的偏好，解决新用户的留存率不佳的问题。这样的“拿到结果更新决策 - 调度新的专业角色 - 输出结果”会不断循环往复。

一个经营诊断与优化的问题，电商商家团队的成员要懂得数据分析、平台知识、用户研究、商品选品、定价、营销投放，还需要有人掌握制作图片和音视频素材的技能，以及完成所有操作和客户售后运营。而商家自己，需要清楚地了解每个团队成员的专长（profile），以便在更新决策时知道如何调度这些资源。此外，商家还需要能够理解每个专家返回的结果，这对商家来说也不是件容易的事情。

当商家发展到一定阶段，他们通常会聘请一个“最强大脑”来代理所有这些调度工作。这个“最强大脑”可以被理解为一个“总管”。有了总管，所有的调度工作都由总管代理完成，而商家只需要与总管沟通即可。这样的协作模式可以极大地提高商家的经营效率。商家想要完成一个经营诊断，他只需向总管提出：“帮我看看最近经营得怎么样？”然后他就可以耐心等待。总管在接到任务后，会进行一系列的操作，最终给出结论：“你最近新客户的留存情况不太好，我这里有一些商品营销创意的建议，你看看是否采纳。”相关的专家们的输出材料会作为附件提供给商家。

从单一个体到各个专业领域的专家团队，再到基础的执行工具，共同帮助商家完成了一个决策过程。在当前的团队配置中，可以关注三类主要角色：

1. 领域专家：以咨询顾问为代表，这类角色不仅具备决策能力，还能够调度工具。在 AI 空间中，他映射我们的 Agent。
2. 工具：这类角色不具备决策能力，只能执行任务。在 AI 世界中，映射为软件系统中已有的多种原子服务能力接口 API。
3. 总管：作为整个决策发起的引擎，总管不需要在某一领域深耕，但必须具备通用的电商知识，了解如何经营业务。在面对问题时，总管能知道如何发起调度，负责整体的专业服务流程编排，在 AI 空间中，他映射我们最强的 Agent。

构建 AI 版的商家经营团队

商家经营团队的运作模式为我们提供了 AI Agent 的现实版样例。现在来到 AI 空间，请出我们的商家智能助手，我们暂且称呼它为 Mario X。将现实空间的团队映射到 AI 空间，我们用大量 Transformers 和研发代码构建了一个 AI 版的商家经营团队：一个由 Master Agent（主代理）领导的多领域 Agents 团队，团队同时掌控着一系列原子能力工具 API。

这样的 AI 团队带来了多方面的好处：

1. 体验提升：商家可以享受到 7*24 小时的在线服务。

2. 效率提高：商家不再需要学习使用各种工具和专业知识，只需用他们最熟悉的经营语言与 Master Agent 沟通，即可直接享受系统提供的各种服务。

3. 决策质量提升：由于有大量的备选方案可供选择，商家的决策效率和质量自然会提高。

4. 成本节约：商家可以减少人力和时间的投入，平台也可以减少不必要的运营开支，让我们的业务人员从繁琐的问答中解放出来。

 ReAct Agent 构建

构建 ReAct Agent 时，每个 Agent 会经历一个 inner loop，这个内部循环称为 reasoning（推理），它对应于我们之前讨论的思维过程，即生成解题思路和大目标的步骤。reasoning 过程包含两个主要部分：

1. Thought（思考） ：我将其定义为用人类自然语言描述的解题决策思路。但是，为了调度系统工具，LLM 需要发出指令，因此需要将这种人类语言翻译成系统能解析的研发语言（即下面的 action code）。
2. 生成 Action Code（动作代码） ：基于生成的 Thought，Agent 会继续生成 Action Code。这个 Code 不直接执行 Action，而是执行 action 的指令。Action Code 是基于 Thought 解析出来的，因为 Thought 是拆分多步骤的解题思路，所以 Action Code 是对应的一系列任务。每个任务的定义可能非常复杂，提取 JSON 中的一些简单字段来说明：

• 1. 调度对象：告诉系统你要调度的工具是谁，比如 Master Agent 可能会调度其他 Agents 或 API。

  2. 输入信息：提供给调度对象的信息，即函数的输入参数。

  3. Job Description：如果调度的是 Agent，需要让 Agent 明白分配给它的任务是什么，类似于工作描述。

  4. Trust_Mode：这是考虑性能和 Agent 质量的一个字段，它决定了 Agent 在接收到工具返回的 observation（观察结果）后，是再次进行 reasoning 还是直接输出结果。

     Action Code 是服务端可解析的代码，它会与环境中广义的 Agents API 和 Tools 进行交互并执行代码。当这些工具完成工作并将 observation 返回给 Agent 时，Agent 将进行下一轮的 reasoning。这个过程会一直持续，直到 Agent 生成了一个 Trust_Mode 变为 1 的输出，这意味着 Agent 认为所有的推理和调度都已完成，可以将结果推送给用户。

 Multi-Agent 的工作流程

打开 Mario X 首先会与商家打招呼。第一轮商家提问：“在京东开店需要交多少保证金？”时，用户和 Master Agent 之间建立了联系，它会再从 Memory 中获取与用户相关的近期和远期特征。

接下来，Master agent 开始内部推理。在这个阶段，Master agent 的 LLM 理解商家提出的问题，但意识到缺少必要的条件，因此无法直接派发任务。LLM 需要向商家追问一个条件，因为保证金与商家经营的类目密切相关。这时，它会调用一个名为 Echo 的工具，Echo 的作用仅仅是将信息传递给用户，不做任何处理。此时 Master agent 将 Trust_Mode 设置为 1，因为 Echo 的任务是单向传递信息，不需要再返回给 LLM 进行推理。Action Code 开始执行，Echo API 被唤起，将问题传回给用户，同时将上下文信息推送给 Memory。

第二轮，商家回答说他卖花，这时用户的信息再次流向 Agent，LLM 根据商家提供的信息和 Memory，生成解答思路在 Thought 中。LLM 知道现在需要调度的对象是 Consulting Advisor，即前面提到的平台咨询顾问 Agent 版。LLM 向 Advisor 传递了一个 Job Description，因为 Advisor 是一个 Agent，需要与之沟通并分配任务。Agent 之间的通信协议也是基于 Action Code，告知 Advisor 商家需要查询的类目对应的入住保证金费用。此时 Trust_Mode 设置为 1，意味着 Advisor 完成任务后不需要再返回给 LLM，因为 LLM 信任 Advisor 专门执行此类咨询任务。这是出于性能考虑，避免让用户等待过久。随后，Advisor Agent 执行任务并返回输出，同时更新 Memory。最终，Master agent 回答用户的问题。

第三轮，当客户提出为花店起名时， Master Agent 的 LLM 识别出这是一个明确的问题。为了解决这个问题，将会进行 3 轮 ReAct。第一轮：不需要调用其他 Agents，而是直接调用一个特定的 API 会更加高效。它调用的是一个名为“Shop Name Generator”的 API，这是一个基于大语言模型的起名工具，它需要接收的输入参数是店铺的类目信息。他从 Memory 中提取了之前 Advisor Agent 提供的信息，即商家经营的是“生活鲜花”，并将这个信息作为参数传递给 Shop Name Generator。在这一步，Trust_Mode 为 0，这意味着 API 生成的店铺名字将返回给 Master Agent 做其他的推理，而不是直接输出给用户。我们回到了 ReAct 流程中，API 输出了一系列的店铺名字，但用户此时还不会看到任何输出的结果。

所有这些步骤完成后，相关信息都会被推入 Memory，这就是 Multi-Agent 工作架构的一个例子。对于普通的 Agent 与 Master Agent 的区别在于，Master Agent 直接与用户交互，而普通 Agent 则接收来自 Master Agent 的 Action Code，这些 Action Code 转化为服务层协议，作为它们的输入参数。

 分层次架构

Multi-agent 架构采用分层次的方法，将一个大模型的复杂生成任务，拆解成了多个层级化的下一步文本预测。这样，每个模型需要处理的推理难度就相对较小，因此模型的规模不需要很大，从而减少了训练和部署的计算资源消耗，并且可以快速迭代。同时，也可方便灵活地接入各种资源方，比如营销的 Agent，我们可以迅速地将其整合进我们的系统中。

这种架构也有一些潜在问题。首先，可能导致风险的累积。如果 Master Agent 出错，那么整个任务的结果可能就会受到影响。因此，我们实施了全链路监控，以确保系统的稳定性和可靠性。此外，由于可能需要经过多个 LLM 生成步骤，响应时间有时可能会较长。此外，商家面临的问题通常涉及工具操作，这些问题都需要结合具体的业务情境来解决。因此，对于我们的 Agent 来说，它们也需要“死记硬背”所有 Tools 的能力。目前，我们正在进行的工作包括在整个推理流程的多个环节中整合 Retrieval（检索）过程。例如在生成 Thought 之后，Agent 可以暂停并调用检索工具或 Agent，等待 Observation 返回后再明确调用哪个 Tools，然后生成 Action Code。这意味着 Thought 和 Action 可以分两轮生成，这是我们正在努力实现的一些改进。

商家智能助手：关键落地技术

今年 2 月份，我们推出了一个专门处理招商入驻问题的 Agent，并将其部署在京东的招商站点上。这个 Agent 帮助许多商家解答了他们关于入驻的相关问题和操作步骤。目前，这个全新的 muiti-Agent 架构助手产品已经在京东商家端进行灰度测试阶段。

技术上，我们目前的系统能够解决商家经营场景中的一些确定性输出问题。所谓确定性输出，是指商家面临的一些答案明确的问题，比如关于平台规则的疑问或具体的操作步骤等，这些问题相对基础，并不包括那些开放式的问题，比如“告诉我如何做好生意”。

我们在建设一个能够真正帮助商家做生意的靠谱助手，搭建完整 AI agent 经营团队。这个系统将涉及非常广泛的知识领域，处理的问题也不会有确定的答案，可能需要引入强化学习等更先进的技术来解决。

 ReAct SFT：垂域样本构建

在解决相对确定性输出的问题时，我们的核心工作在于构建垂直领域的知识。这意味着将人类专家的知识传授给系统，特别是针对商家领域的知识。对于这类问题，通常使用标准的 SFT 加上一些预训练模型基本上就足够了。

如何构建样本？鉴于我们先解决比较确定性的问题，我们可以从在线客服、运营和产品的回复，以及商家满意度收集的接口等获得真实的数据，然后对这些数据进行清洗。接着，研发团队会根据系统的调用路径构建一个全面的路径树。最后，业务人员将构造一些剧本，描述可能的问答场景。

将这两部分结合起来，我们就得到 SFT 样本 的基础池。接下来，对基础池进行丰富度扩充。其中最主要的是对问题（Q）的扩充。有了问题和答案（A），以及调用路径，我们接下来需要生成中间的标签（label）即 thought 和 action code，这就需要依赖先验的知识库。此外，还需要研发的配合，他们需要按照标准来注册 API。因为工具的调用靠注册信息的质量，如果两个不同的工具，它们的描述写成一样的，那么我们的大模型也无能为力，因为它只能通过工具的自我介绍来选择工具来执行任务。因此，知识的准确性非常重要。

 复杂输入下的 Thought 生成

复杂输入的问题，不像简单输入那样直接。解决这类问题，关键在于遵循 Agent 推理的流程：先生成 Thought，再解析 Action Code。因此，生成一个强大的 Thought 变得非常重要。下面看一个复杂输入下，确定性输出的例子，我们来对比单纯用 RAG 和用 LLM agent 解题的效果，比较一下有和没有好的 Thought 的区别。

（1）RAG 解题

例如，用户提出了一个问题：“在京东卖红酒要多少钱？”如果直接使用 Retrieval（检索增强）来解决问题，按照经典的方式，先进行 Query（查询）并计算 Similarity（相似度），然后召回一些文本。在召回的文本中，可能会看到白酒、黄酒等，但实际上并没有答案，因为红酒这个类目在我们的知识库中并不存在，它不是开店保证金的一个选项。基于错误的信息片段，再加上用户模糊的问题，即使是非常强大的 Summary Model（总结模型）也无法给出正确的答案。

要解决这个问题，我们需要让模型理解红酒实际上与哪些类目是有关联的。这就需要模型不仅要有检索能力，还要有推理和关联的能力，以便正确地将问题与相关的知识库内容关联起来，从而提供准确的答案。

（2） LLM Agent 解题

助手中的 Advisor 在经过训练后，会以特定的方式解题。还是开始于 Master Agent 与用户的对话。Master Agent 并不直接理解这个问题，而是将用户的询问，例如“京东红酒入住资费是多少？”通过 Action Code 传递给 Advisor。Action Code 中的 Job Description 是“请回答京东红酒入住资费”。

Advisor 在处理这个查询时，首先理解红酒实际上属于葡萄酒这一类别。因此，Advisor 的 Thought 中生成出应该查询的是葡萄酒类目的入住资费，并确定了使用哪些关键词来传给调度的检索 API 做关键入参。在生成 Action Code 时，Advisor 会传递给检索 API 这个关键入参，即 Search Query“葡萄酒保证金“。这个参数不再是用户的原始问题，而是根据 Advisor 的推理进行了调整。API 本身没有决策能力，但由于 Agent 具有推理能力，它能确保传递给工具的输入是正确的，从而用正确的参数唤起正确的工具。

在第二个任务中，Summary API 接收到一个关键的输入参数，称为 Thought for Answer，即回答思路。这个思路是 Advisor 在推理过程中在 thought 生成的关于红酒与葡萄酒类目关系的理解。Advisor 告诉用户红酒和葡萄酒之间的关系，并按照葡萄酒类目的答案来回答用户的问题。

接下来，advisor 继续遵循经典的 RAG 流程。此时，Search Query 变为“葡萄酒保证金”。虽然召回的葡萄酒与原始问题的“红酒”相似性不高，但由于顾问使用了“葡萄酒”和“保证金”作为搜索关键词，并将回答问题的思路作为 Prompt 的一部分传递给总结 API，API 就能够根据 Advisor 提供的推理思路，正确地回答关于红酒保证金的问题，即通过查看葡萄酒的保证金来得知红酒的保证金情况。

 复杂输入下的 Thought 训练

在复杂输入的情况下，训练出能够准确生成 Thought 的模型是关键。由于这类问题的答案并不直接存储在知识库中，我们需要从算法层面进行构建。我们的方法是分析 Bad case（不良案例），从中发现问题并拓展解题思路。

当遇到一个新案例时，我们会与业务团队沟通，以获取新的知识点，并按照既定的模式进行预先处理。理解不同类目之间的关系是解决相关问题的关键。因此，我们为模型提供了大量类似的文本进行预训练（pretrain）。

在自监督学习阶段，模型学习了与业务相关的各种关键词、相似词以及它们与类目的关系。这样，当模型遇到葡萄酒相关的问题时，它已经通过预训练了解了如何处理这类问题。随后，我们对模型进行标准的 SFT，在这个阶段，模型会学习到具体的知识点，比如葡萄酒的相关信息。模型已经知道如何回答关于葡萄酒的问题，并且通过训练了解了葡萄酒与其他类目的关系。当用户询问关于红酒保证金的问题时，模型能够通过分析和推理，提供准确的答案。

通过这种方式，我们可以训练出能够处理复杂输入并生成有效 Thought 的模型，这些模型能够更好地理解和解决商家面临的实际问题。

 全链路 ReAct 监控

为了定位 Bad Case，我们实施了全链路 ReAct 监控。具体来说，我们会收集在线推理生成的 Thought、Action Code 和 Observation，然后通过人工打标 + 大模型来进行评估。

评估函数会将人工打标的输出与 Agent 生成的输出进行比较，以确定两者之间的差异。这个评估与 Agent 的具体定义紧密相关，因为不同的 Agent 可能有不同的评估标准。评估主要基于三个结果：Thought、Action Code 和 Observation。值得注意的是，Observation 虽然是作为下一轮推理的输入，但它本身并不是由 LLM 生成的，它的质量会影响下一轮的 Thought 生成。

对于 Observation 的评估可能包括预测销量的准确性或用户对生成图像的满意度等，这些指标并不完全由 LLM 控制，因此 Observation 的评估也与服务的业务指标相关。

基于这些评估结果，我们会有一个流程来决定 Agent 的表现。如果 Agent 在第一轮的 ReAct 得分很低，我们会继续累积这个分数，但如果得分低于某个阈值，我们将停止后续的推理，并且该 Agent 将不再参与后续得分的累加，意味着它已经退出了推理过程。如果 Agent 的得分符合要求，我们会检查是否为最后一轮推理。如果不是最后一轮，Agent 将更新后进入下一轮评估。如果是最后一轮，将触发结束流程。

在多轮推理和评估后，当触发结束评估时，我们会得到一个全链路累积的 ReAct 得分。这个推理过程是链式的，涉及到递减的折扣因子γ和η，这些因子会影响 Agent 的 ReAct 得分和整体得分。我们的评价核心在于能够快速定位问题节点，这是由我们的架构决定的，必须通过这种方式来尽早发现并解决问题，防止问题在推理过程中蔓延。

展    望

我们需要帮助商家更好地经营生意。尽管在平台上有许多类似参谋的工具，比如供应链管理、选品、定价等，但目前还没有一种方式能够让商家根据自己的业务思路，按照黄金流程组合使用这些工具。无论是问答数据、沟通数据还是交互数据，这些都需要我们去收集和整合。

我们需要将人们做生意的思维方式从人脑中提取出来，这包括训练大型模型来寻找和学习人类专家的知识。此外，我们还需要引入强化学习。 因为对于商家提出的复杂问题，如“我的生意做得怎么样？”可能存在多种解决方案，每个团队的解法可能都不同。要判断哪一个更好，可能需要每个做生意的人根据自己的打分逻辑来评估，同时还需要在市场反馈中验证。