引言
多智能体的架构演进过程：
第一阶段：B 商城工单自动回复，LLM 和 RAG 结合知识库应答，无法解决工具调用。
第二阶段：京东招商站，单一 Agent 处理知识库问答和工具调用，准确率低 & LLM 模型幻觉，场景区分度差。
第三阶段 ：京麦智能助手，引入 multi-agent 架构，master + subagents 协同工作模式，把问题分而治之，显著提升准确率。
商家助手的算法底座是基于大语言模型（LLM）构建的 Multi-agent 系统，模拟的是现实中电商商家团队的经营协作方式。商家只需使用他们最熟悉的自然语言，与京麦平台上的这个助手进行沟通，就可以获得 7*24 小时的经营代理服务。本文档将从模拟的现实商家经营空间映射到 Multi-agent 算法空间，逐步解析电商平台业务场景下商家助手的业务动机、算法技术架构以及关键技术。
商家助手 Multi-agent 是一个通用 &开放的商家经营服务多种能力（比如销量预测，营销投放，定价，商机词推荐等）接入的宿主，可随着建设的不同阶段友好的面向其他能力提供方的 Tools，包括 Agent、API 等形式。
1.商家经营：从多角色现实空间到 Multi-Agent 算法空间
Multi-Agent 系统架构的设计动机来自于 "Agent 模拟的是现实世界的人的解决问题过程" 的本质。首先介绍现实世界商家和他的团队是怎么经营的，以及他们和 AI 世界怎么进行角色映射。
2、Multi-Agent Planning 关键技术：
2.1 Agent 构建技术：ReAct 范式的多模型集成
1. Agent 构建集成四类模型，实现了 Agent 大脑的智能化逆向规划能力：
•LLM： 审题并提炼终极目标，为逆向规划定向，同时校验调用链路的合理性。
•Embedding：快速匹配终极节点工具，避免 LLM 冗长 prompt 和选择工具幻觉问题。
•Tools DAG：进行多路径逆向推理，结合 LLM 抽取参数工具，精确得到调度策略。
•运筹优化：理论上可加速解题，提升逆向规划效率，待实际测试验证。
2. ReAct 规划动态更新
动态规划更新：在规划正向执行中，ReAct 范式实现每一步根据执行结果的动态规划更新。
3.技术挑战和收益：
•提升规划效率，降低推理成本：多个模型编排替代超大模型，显著提高推理速度与规划效率，同时节约推理成本。
•提升架构稳定性，效果、风险可控： 任务拆分后，小模型处理简单明确任务，大模型专注单一复杂任务，合理分工使效果与风险均可控，减少模型迭代对整体的影响。
•治理 LLM 幻觉提升规划质量：Embedding 解决 LLM 带来的不确定性与幻觉，Tools DAG 确保规划逻辑性与准确性，京麦场景工具调用准确率提升 10%。
•减少 LLM 样本工程量：LLM 仅处理文本理解，不直接选工具，避免新工具需大量样本训练的问题，系统扩展性与维护效率提高 60%以上。
•实时性和准确性：通过 ReAct 动态规划更新，实时调整策略，优化执行链路。
2.2 Multi-Agent Online Inference
2.2.1 技术特色
- 任务分层动态规划与分布式协作： 基于 ReAct 范式，通过 Master Agent 和 Sub Agents 在不同层级进行任务动态规划和动态调度，支持分布式协作。
•Master Agent：在领域层面进行任务规划，将复杂场景拆解为多个独立子任务调度 sub-Agens 协同工作。
•Sub Agents：在领域内执行任务规划，负责具体的子任务执行，支持分布式调度和协同工作。
2. Agent 协作基于标准通信协议：
通过标准通信协议确保 Muti-agent 高效协同工作，支持多步联动和全局思维链规划。
•Agent 标准通讯协议：确保 Muti-agent 系统中的各 agent 高效协同工作，支持任务的分层规划和执行。
•多步联动：支持多个相互依赖的任务，通过 ReAct 单步执行和回调机制，完成复杂任务。
2.2.2 Multi-Agent Online Inference 演示：
为了展示 multi-agent 的协同在线推理流程，录制了一个视频。结合京麦前台的助手产品形态，同步展示后台 multi-agent 的后台算法推理服务，方便大家理解。干货见以下视频：
2.2.3 架构小结
特色：
推理难度低：将超大模型的全链路多步计划的生成任务，转化成 next task prediction
成本低：多个小型模型的协同更容易落地，训练、部署成本低
迭代快：问题定位迅速，模型快速迭代
待解决：
响应时间长：面对复杂问题，用户更长的等待耗时，需要在产品上做引导
风险积累：多 agents 链式推理有错误累计风险。 解决方案研究中，如多智能体联合学习
多 Agent 架构与单 Agent 及 LLM-MoE 架构对比，多 Agent 架构在同等大模型能力下具有更强的稳定性，能更好支持复杂业务场景和任务的协作与扩展，但需要更多的工程开发量和更复杂的推理链路。
2.3 Agent 全链路 ReAct 评估技术
1.Agent 全链路 ReAct 效能综合评估
•全链路评估：从全局视角出发，通过任务拆解和链路调度，对系统中每个 Agent 进行加权评分，以计算 Multi-Agent 系统的整体效能。
•局部评估：使用 Reward Model 对每个 Agent 的 ReAct 循环中存在的 thought/action/observation 进行评估，识别性能瓶颈和低效模型环节，提供针对性优化建议。
2.多样化 Reward Model
•业务自定义：支持业务自定义规则函数/reward 模型，用于灵活适应不同业务需求的评估。
•现有大模型：利用现有的高阶 Sota 大模型进行评估，确保评估的通用性和准确性。
•训练 Reward 模型：通过训练专门的模型进行评估，提升对特定任务和场景的适应能力。
Reward Model-平台化 AI 评估模型案例说明：
css
输入总结模型的目标是针对用户历史的会话记录与本轮的提问分析其具体意图，作为Master Agent的思考的核心环节，需要对其意图总结效果进行评价。
1、自动化评价方案：1.评价方法：以高阶模型（例如：GPT-4o）作为裁判模型，结合用户当前轮次提问与历史的会话记录，对线上推理的准确性进行评价。2.自动化评分指令（简化）：你是一个擅长问题意图理解的专家。现在需要你评估一个电商平台AI助手对于商家用户提问的意图理解质量，并要求你从以下维度对回答进行评估，评分为0-10分，分数必须是整数:1.正确性:意图是否正确表达出用户当前的问题；2.关联性:当前问题的意图可能和历史对话强关联，也可能无关，判断助手理解的意图是否正确关联历史对话。我们会给你提供用户本轮提问、历史与AI助手的对话，和需要你评估的AI助手答案。有可能为你提供一个参考答案，当给出参考答案时，你需要判断AI助手总结的意图和给出的参考意图的相似度，该维度名为"和人工理解相似程度"。按照以下字典格式（包括括号）返回你所有的打分结果：{{'维度一': 打分, '维度二': 打分, ..., '综合得分': 打分}}。例如：{{'正确性': 6, '关联性': 9, ..., '综合得分': 7}}。输入数据格式如下:用户本轮提问: {question}\n[历史对话开始]\n{history_conv}\n[历史对话结束][参考意图开始]\n{reference}\n[参考意图结束]\n[助手意图理解开始]\n{intention}\n[助手理解意图结束]\n
2、待评估案例：假设用户本轮提问、历史对话、助手意图理解分别如下：1.用户本轮提问：我这个是京东小店的2.历史对话：【顾客】：什么类目的标题可以不带品牌的名字【客服】：都需要带上品牌的3.助手意图理解：说明店铺类型为某平台小店
3、不同标注场景下的打分结果：1.存在人工标注：此时人工标注即为指令中的"参考意图"参考意图：询问京东小店的商品标题是否需要带品牌名字评分结果： 1.正确性: 助手理解的意图并没有准确表达出用户当前的问题。用户当前的问题是询问京东小店的商品标题是否需要带品牌名字，而助手理解的意图只是说明了店铺类型为某平台小店，未能准确捕捉用户的真实意图。 2.关联性: 助手理解的意图与历史对话没有正确关联。历史对话中用户询问的是商品标题是否需要带品牌名字，而助手理解的意图并未涉及这一点。 3.和人工理解相似程度: 助手理解的意图与人工意图有明显差异。人工意图准确捕捉了用户的问题，而助手理解的意图只是说明了店铺类型，未能反映用户的真实需求。 综合评价:助手理解的意图未能准确表达用户的真实意图，也未能正确关联历史对话，与人工意图差异较大，因此综合评分较低。 综合来说：{{'正确性': 3, '关联性': 2, '和人工理解相似程度':2, '综合得分':2}}2.不存在人工标注：此时指令中的"参考意图"为"无"评分结果： 1.正确性: 助手理解的意图与用户当前提问的主要内容不符。用户想了解的是京东小店的商品标题中是否需要说明品牌名称，助手理解的用户意图为说明自身为京东小店，意图理解错误。 2.关联性: 助手理解的意图与历史对话未正确关联。在之前的会话中，用户询问的目的是商品标题携带品牌名的必要性，助手未理解该意图。 综合评价:助手理解的意图在正确性和关联性上均有不足，因此综合评分较低。 综合来说：{{'正确性': 3, '关联性': 2, '综合得分':3}}复制代码
css
工具调度类模型需要针对用户提问、结合可用API的具体描述，进行API选择与相关的参数解析，因此需要对模型解析出的action code进行准确度评价。
1、自动化评价方案：1.评价方法：以高阶模型（例如：GPT-4o）作为裁判模型，结合用户提问、API资料库，对线上推理的准确性进行评价。2.自动化评分指令（简化）：你是一个擅长评价API使用合理性的助手。现在需要你评估一个电商平台AI助手要解决商家用户提问时，所调用的API是否正确；如果正确选择了API，需要进一步判断对该API的参数解析是否正确。请注意：你只需要评价API选择以及参数解析的正确与否，不需要生成正确的调用方法。我们会给你提供用户的提问、API，和需要你评估的AI助手答案。可能为你提供用户提问的对应参考答案，当存在参考答案时，准确性评价必须与参考答案对比得出；不存在参考答案时，仅需要根据助手答案自身展开评价。按照以下字典格式（包括括号）返回你所有的评价结果：{{'API选择': 正确或错误, '参数解析': 当API选择错误时，结果为"无"；当API选择正确时，结果为正确或错误}}。例如：{{'API选择': '错误', '参数解析': '无'}}；{{'API选择': '正确', '参数解析': '正确'}}。输入数据格式如下:用户本轮提问: {question}\n[API信息开始]\n{retrivals}\n[API信息结束]\n[参考解析结果开始]\n{reference}\n[参考解析结果结束]\n[助手解析结果开始]\n{answer}\n[助手解析结果结束]\n
2、待评估案例：假设用户本轮提问、API信息、助手解析结果分别如下：1.用户本轮提问：我有多少订单是王萍萍买的？ 2.API信息：【1】{ "name": "check_shop_qualifications", "description": "当用户提出有关经营过程中资质要求（如上传材料、营业执照、行业资质等）相关的问题时，需要调用此工具查询具体资质要求的相关信息，然后根据查询到的信息回答用户问题。", "parameters": { "type": "object", "properties": { "keyword": { "description": "用户经营的主要类目、商品类型或者商品品牌，例如：洋酒、玩具、阿迪达斯等。如果没有提供该类信息，必须反问用户要求其提供" }, "shop_body": { "description": "店铺主体，只能是以下三种：企业、个人和个体工商。" }, "shop_type": { "description": "店铺类型，只能是以下六种：旗舰店、专卖店、专营店、卖场店、普通企业店和小店。" } }, "required": ["keyword"] }}【2】{ "name": "search_order_code", "description": "该工具用于根据用户提供的信息（如订单编号、下单时间、下单账号等）查询订单的详细信息，包括商品详情与订单详情。", "parameters": { "type": "object", "properties": { "order_id": { "description": "订单编号：12位纯数字，用于记录订单的唯一标识" }, "consumer_name": { "description": "客户姓名：用户姓名、买家姓名、收件人、收货人、顾客、客户等" }, "user_pin": { "description": "下单账号：下单账户、买家pin，买家、顾客、用户等，通常由客户姓名+数字或纯英文组成" }, "sku_id": { "description": "商品编号：14位纯数字信息，" }, "sku_name": { "description": "商品名称：商品信息的描述，可能携带品牌信息或商品具体属性" }, "consumer_mobile_phone": { "description": "客户电话：用户手机号码，11位纯数字信息，可能会以区号+86，400等开头。" }, "search_keys": { "description": "用户希望查询的目标，枚举值只能从[商品、订单]中选择。若用户希望查询的是订单中的商品id、商品名称、商品详情等，枚举值为商品；若用户希望查询的目标是订单编号、订单数量等，枚举值为订单。" } }, "required": [] }}3.助手解析结果：{ "action_code": { "api_name": "search_order_code", "parameter": { "consumer_name": [ "王萍萍" ], "search_keys": [ "商品" ] }, }}
3、不同标注场景下的打分结果：1.存在人工标注：此时人工标注即为指令中的"参考解析结果"参考解析结果：{ "action_code": { "api_name": "search_order_code", "parameter": { "consumer_name": [ "王萍萍" ], "search_keys": [ "订单" ] }, }}评分结果： 1.API选择：AI助手的答案中选择调用search_order_code，与参考答案一致，API调用正确。 2.参数解析：AI助手的答案中search_keys为商品，但参考答案中search_keys为订单，因此参数解析错误。 综合来说：{{'API选择': '正确', '参数解析': '错误'}}2.不存在人工标注：此时指令中的"参考答案"为"无"评分结果： 1.API选择：用户希望查询顾客王萍萍的订单，AI助手的答案中选择调用search_order_code，该工具可以进行订单详情查询，因此API调用正确。 2.参数解析：API助手解析的参数中，查询目标为商品，但用户希望查询的内容是订单，因此参数解析结果与用户提问意图不符，解析错误。 综合来说：{{'API选择': '正确', '参数解析': '错误'}}复制代码
css
输出总结模型需要针对用户提问与召回的语料进行总结回答，因此需要对模型最终的总结效果进行评价。
1、自动化评价方案：1.评价方法：以高阶模型（例如：GPT-4o）作为裁判模型，结合用户提问与召回的语料得到线上推理的回答评分。针对有人工标注和无人工标注两种情况，构造出一套通用的打分指令，兼容不同场景。2.自动化评分指令（简化）：你是一个擅长评价文本质量的助手。现在需要你评估一个电商平台AI助手对于商家用户提问的回答的质量，并要求你从以下维度对回答进行评估，评分为0-10分，分数必须是整数:1.满足用户需求:回答内容是否解决用户提问；2.事实正确性:回答是否从参考语料中得到，不允许过度推断得到的回答；3.回答完备性:仅针对要回答的问题，是否完整地提取了语料中的全部信息。我们会给你提供用户的提问、需参考的核心语料，和需要你评估的AI助手答案。可能为你提供用户提问的对应参考答案，当存在参考答案时，评分需要对比参考答案得出；不存在参考答案时，仅需要根据助手答案自身展开评价。按照以下字典格式（包括括号）返回你所有的打分结果：{{'维度一': 打分, '维度二': 打分, ..., '综合得分': 打分}}。例如：{{'满足用户需求': 6, '事实正确性': 9, ..., '综合得分': 7}}。输入数据格式如下:用户本轮提问: {question}\n[核心语料开始]\n{retrivals}\n[核心语料结束]\n[参考总结结果开始]\n{reference}\n[参考总结结果结束]\n[助手总结结果开始]\n{answer}\n[助手总结结果结束]\n
2、待评估案例：假设用户本轮提问、核心语料、助手总结结果分别如下：1.用户本轮提问：偏远地区发出了又不要了，运费谁承担2.核心语料：【1】[售后-交易纠纷] 京东开放平台运费问题纠纷处理标准链接：https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1【2】[售后-交易纠纷] 当买卖双方根据运费发生纠纷时，京东根据"谁过错，谁承担"的原则处理，但买卖双方协商一致的除外。【3】[售后-交易纠纷] 《运费问题的纠纷处理规则》判定运费纠纷责任：第十条 若买卖双方就如上运费问题产生纠纷，申请京东介入的，京东将根据本标准内容进行判定，如商家违反运费要求或举证内容无效，将判定商家责任。3.助手总结结果：当买卖双方根据运费发生纠纷时，京东根据"谁过错，谁承担"的原则处理，但买卖双方协商一致的除外。具体处理标准您可参考以下链接：[京东开放平台运费问题纠纷处理标准链接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)
3、不同标注场景下的打分结果：1.存在人工标注：此时人工标注即为指令中的"参考总结结果"参考总结结果：京东根据"谁过错，谁承担"的原则处理，但买卖双方协商一致的除外：若消费者无正当理由拒绝签收，发货运费由消费者承担；消费者有理由拒绝签收（商品有质量问题、少货等），发货运费由商家承担。\n详细内容请参考[京东开放平台运费问题纠纷处理标准链接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)评分结果： 1. 满足用户需求:AI助手的答案部分解决了用户的提问，提到了"谁过错，谁承担"的原则，但没有具体说明在偏远地区发货后又不要了的情况下，运费由谁承担。相比之下，参考答案更详细地解释了不同情况下的运费承担方。因此，AI助手的回答在满足用户需求方面不够全面。 2. 事实正确性:AI助手的答案内容来自核心语料，引用了"谁过错，谁承担"的原则，并提供了相关链接。这部分内容是准确的。 3. 回答完备性:AI助手的答案没有完全提取核心语料中的全部信息，尤其是缺少了关于消费者无正当理由拒绝签收和有理由拒绝签收的具体情况的解释。相比之下，参考答案更为详细和完备。 综合评价:AI助手的回答在事实正确性方面表现良好，但在满足用户需求和回答完备性方面有所欠缺。总体来说，回答质量中等。 综合评分如下：{{'满足用户需求': 5, '事实正确性': 10, '回答完备性': 4, '综合得分': 6}}2.不存在人工标注：此时指令中的"参考答案"为"无"评分结果： 1. 满足用户需求:AI助手的答案部分解决了用户的提问。用户询问的是偏远地区发货后又取消订单的情况下运费由谁承担，AI助手回答了京东处理运费纠纷的原则是"谁过错，谁承担"，并提供了一个链接供用户参考。然而，AI助手没有明确回答在偏远地区发货后取消订单的具体情况，是否由买家或卖家承担运费。因此，AI助手的回答不完全满足用户需求。 2. 事实正确性:AI助手的答案是从核心语料中提取的，引用了"谁过错，谁承担"的原则，并提供了相关链接。这些信息都准确无误，符合核心语料的内容。 3. 回答完备性:AI助手的回答虽然引用了核心语料中的信息，但没有完全提取所有相关信息。例如，核心语料中提到的"买卖双方协商一致的除外"以及"京东将根据本标准内容进行判定，如商家违反运费要求或举证内容无效，将判定商家责任"这些内容没有被提及。这些信息对于用户理解运费纠纷的处理方式是有帮助的。 综合评价:AI助手的回答在事实正确性方面表现良好，但在满足用户需求和回答完备性方面还有提升空间。总体来说，回答质量中等。 综合评分如下：{{'满足用户需求': 6, '事实正确性': 10, '回答完备性': 6, '综合得分': 7}}
复制代码
2.4 LLM 离在线样本增强技术
1. 自动化离线样本生成与扩展
•离线接入的标准化语料：通过接入标准化的业务数据，能够自动化生成和扩展用于 LLM 训练的样本，快速适配不同场景训练需求，批量生成高质量训练样本。
2. 自动化在线推理标注与样本积累
•Agent 在线推理数据：通过多种 Reward Model 策略，系统能够对线上推理过程中生成的样本进行持续的自动化标注和积累。这使得样本库能够不断扩展和优化，提高模型的在线推理能力。
通过商家智能助手的场景对多智能体协同前沿AI技术的应用探索，为行业解决复杂分布式交互系统的全域动态智能化问题，提供了宝贵的实践经验和可复制的模式：
普适性与可复制性：多智能体协同的技术路线，为其他行业解决通用大模型在严谨产业应用中的"能力短板"--领域知识相对缺乏、复杂决策难以胜任，以及对话交互不等于有效协同，提供了借鉴。
行业标杆：通过实战验证，京东商家智能助手已成为电商领域内多智能体系统与大模型融合应用的标杆案例，对于推动电商行业的大模型产品应用落地具有重要意义。
商家智能助手展示了多智能体协同与大模型技术在电商领域的巨大潜力，未来智能化的用户体验，一定不是只靠一个大模型，而是需要全行业深度协作，需要很多的专业智能体共同参与、各司其职。为未来智能化的用户体验和行业深度协作提供了新的方向。（京东商家智能助手案例入选InfoQ研究中心 《中国AI Agent应用研究报告 2024》、2024 Top 100全球软件案例、甲子光年-2024中国科技产业最佳实践榜。）
加入我们：
京东零售数据算法团队负责大模型智能体建设，主要技术包括SFT/RLHF/RAG/KAG/Multi-Agent/Self-reflection/Distillation等。我们的团队成员来自国内外顶尖高校，致力于打造大模型智能体一流团队，用前沿技术驱动业务发展。我们诚邀对技术充满热情、富有创新的你加入，期待与您在京东相遇！简历投递邮箱：hanai5@jd.com。