电商助手是一款集合了多种电商经营决策功能的工具软件，旨在帮助电商从业者完成从商品发布到订单管理、客服沟通、数据分析等一系列电商运营任务。
京东零售基于 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），以便在更新决策时知道如何调度这些资源。此外，商家还需要能够理解每个专家返回的结果，这对商家来说也不是件容易的事情。当商家发展到一定阶段，他们通常会聘请一个“最强大脑”来代理所有这些调度工作。这个“最强大脑”可以被理解为一个“总管”。有了总管，所有的调度工作都由总管代理完成，而商家只需要与总管沟通即可。这样的协作模式可以极大地提高商家的经营效率。商家想要完成一个经营诊断，他只需向总管提出：“帮我看看最近经营得怎么样？”然后他就可以耐心等待。总管在接到任务后，会进行一系列的操作，最终给出结论：“你最近新客户的留存情况不太好，我这里有一些商品营销创意的建议，你看看是否采纳。”相关的专家们的输出材料会作为附件提供给商家。从单一个体到各个专业领域的专家团队，再到基础的执行工具，共同帮助商家完成了一个决策过程。在当前的团队配置中，可以关注三类主要角色：- 领域专家：以咨询顾问为代表，这类角色不仅具备决策能力，还能够调度工具。在 AI 空间中，他映射我们的 Agent。
- 工具：这类角色不具备决策能力，只能执行任务。在 AI 世界中，映射为软件系统中已有的多种原子服务能力接口 API。
- 总管：作为整个决策发起的引擎，总管不需要在某一领域深耕，但必须具备通用的电商知识，了解如何经营业务。在面对问题时，总管能知道如何发起调度，负责整体的专业服务流程编排，在 AI 空间中，他映射我们最强的 Agent。
商家经营团队的运作模式为我们提供了 AI Agent 的现实版样例。现在来到 AI 空间，请出我们的商家智能助手，我们暂且称呼它为 Mario X。将现实空间的团队映射到 AI 空间，我们用大量 Transformers 和研发代码构建了一个 AI 版的商家经营团队：一个由 Master Agent（主代理）领导的多领域 Agents 团队，团队同时掌控着一系列原子能力工具 API。1. 体验提升：商家可以享受到 7*24 小时的在线服务。
2. 效率提高：商家不再需要学习使用各种工具和专业知识，只需用他们最熟悉的经营语言与 Master Agent 沟通，即可直接享受系统提供的各种服务。
3. 决策质量提升：由于有大量的备选方案可供选择，商家的决策效率和质量自然会提高。
4. 成本节约：商家可以减少人力和时间的投入，平台也可以减少不必要的运营开支，让我们的业务人员从繁琐的问答中解放出来。构建 ReAct Agent 时，每个 Agent 会经历一个 inner loop，这个内部循环称为 reasoning（推理），它对应于我们之前讨论的思维过程，即生成解题思路和大目标的步骤。reasoning 过程包含两个主要部分：- Thought（思考）：我将其定义为用人类自然语言描述的解题决策思路。但是，为了调度系统工具，LLM 需要发出指令，因此需要将这种人类语言翻译成系统能解析的研发语言（即下面的 action code）。
- 生成 Action Code（动作代码）：基于生成的 Thought，Agent 会继续生成 Action Code。这个 Code 不直接执行 Action，而是执行 action 的指令。Action Code 是基于 Thought 解析出来的，因为 Thought 是拆分多步骤的解题思路，所以 Action Code 是对应的一系列任务。每个任务的定义可能非常复杂，提取 JSON 中的一些简单字段来说明：
- 调度对象：告诉系统你要调度的工具是谁，比如 Master Agent 可能会调度其他 Agents 或 API。
- 输入信息：提供给调度对象的信息，即函数的输入参数。
- Job Description：如果调度的是 Agent，需要让 Agent 明白分配给它的任务是什么，类似于工作描述。
- Trust_Mode：这是考虑性能和 Agent 质量的一个字段，它决定了 Agent 在接收到工具返回的 observation（观察结果）后，是再次进行 reasoning 还是直接输出结果。Action Code 是服务端可解析的代码，它会与环境中广义的 Agents API 和 Tools 进行交互并执行代码。当这些工具完成工作并将 observation 返回给 Agent 时，Agent 将进行下一轮的 reasoning。这个过程会一直持续，直到 Agent 生成了一个 Trust_Mode 变为 1 的输出，这意味着 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 经营团队。这个系统将涉及非常广泛的知识领域，处理的问题也不会有确定的答案，可能需要引入强化学习等更先进的技术来解决。在解决相对确定性输出的问题时，我们的核心工作在于构建垂直领域的知识。这意味着将人类专家的知识传授给系统，特别是针对商家领域的知识。对于这类问题，通常使用标准的 SFT 加上一些预训练模型基本上就足够了。如何构建样本？鉴于我们先解决比较确定性的问题，我们可以从在线客服、运营和产品的回复，以及商家满意度收集的接口等获得真实的数据，然后对这些数据进行清洗。接着，研发团队会根据系统的调用路径构建一个全面的路径树。最后，业务人员将构造一些剧本，描述可能的问答场景。将这两部分结合起来，我们就得到 SFT 样本 的基础池。接下来，对基础池进行丰富度扩充。其中最主要的是对问题（Q）的扩充。有了问题和答案（A），以及调用路径，我们接下来需要生成中间的标签（label）即 thought 和 action code，这就需要依赖先验的知识库。此外，还需要研发的配合，他们需要按照标准来注册 API。因为工具的调用靠注册信息的质量，如果两个不同的工具，它们的描述写成一样的，那么我们的大模型也无能为力，因为它只能通过工具的自我介绍来选择工具来执行任务。因此，知识的准确性非常重要。复杂输入的问题，不像简单输入那样直接。解决这类问题，关键在于遵循 Agent 推理的流程：先生成 Thought，再解析 Action Code。因此，生成一个强大的 Thought 变得非常重要。下面看一个复杂输入下，确定性输出的例子，我们来对比单纯用 RAG 和用 LLM agent 解题的效果，比较一下有和没有好的 Thought 的区别。例如，用户提出了一个问题：“在京东卖红酒要多少钱？”如果直接使用 Retrieval（检索增强）来解决问题，按照经典的方式，先进行 Query（查询）并计算 Similarity（相似度），然后召回一些文本。在召回的文本中，可能会看到白酒、黄酒等，但实际上并没有答案，因为红酒这个类目在我们的知识库中并不存在，它不是开店保证金的一个选项。基于错误的信息片段，再加上用户模糊的问题，即使是非常强大的 Summary Model（总结模型）也无法给出正确的答案。要解决这个问题，我们需要让模型理解红酒实际上与哪些类目是有关联的。这就需要模型不仅要有检索能力，还要有推理和关联的能力，以便正确地将问题与相关的知识库内容关联起来，从而提供准确的答案。助手中的 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 的模型是关键。由于这类问题的答案并不直接存储在知识库中，我们需要从算法层面进行构建。我们的方法是分析 Bad case（不良案例），从中发现问题并拓展解题思路。当遇到一个新案例时，我们会与业务团队沟通，以获取新的知识点，并按照既定的模式进行预先处理。理解不同类目之间的关系是解决相关问题的关键。因此，我们为模型提供了大量类似的文本进行预训练（pretrain）。在自监督学习阶段，模型学习了与业务相关的各种关键词、相似词以及它们与类目的关系。这样，当模型遇到葡萄酒相关的问题时，它已经通过预训练了解了如何处理这类问题。随后，我们对模型进行标准的 SFT，在这个阶段，模型会学习到具体的知识点，比如葡萄酒的相关信息。模型已经知道如何回答关于葡萄酒的问题，并且通过训练了解了葡萄酒与其他类目的关系。当用户询问关于红酒保证金的问题时，模型能够通过分析和推理，提供准确的答案。通过这种方式，我们可以训练出能够处理复杂输入并生成有效 Thought 的模型，这些模型能够更好地理解和解决商家面临的实际问题。为了定位 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 得分和整体得分。我们的评价核心在于能够快速定位问题节点，这是由我们的架构决定的，必须通过这种方式来尽早发现并解决问题，防止问题在推理过程中蔓延。我们需要帮助商家更好地经营生意。尽管在平台上有许多类似参谋的工具，比如供应链管理、选品、定价等，但目前还没有一种方式能够让商家根据自己的业务思路，按照黄金流程组合使用这些工具。无论是问答数据、沟通数据还是交互数据，这些都需要我们去收集和整合。我们需要将人们做生意的思维方式从人脑中提取出来，这包括训练大型模型来寻找和学习人类专家的知识。此外，我们还需要引入强化学习。 因为对于商家提出的复杂问题，如“我的生意做得怎么样？”可能存在多种解决方案，每个团队的解法可能都不同。要判断哪一个更好，可能需要每个做生意的人根据自己的打分逻辑来评估，同时还需要在市场反馈中验证。