引言

多智能體的架構演進過程：

第一階段：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世界怎么進行角色映射。

?

?QCon_京東商家智能助手.mp4?

?

?

?

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 技術特色

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的后臺算法推理服務，方便大家理解。干貨見以下視頻：

?H-MAP_4k.mp4?

?

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評估模型案例說明：

輸入總結模型的目標是針對用戶歷史的會話記錄與本輪的提問分析其具體意圖，作為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}}

工具調度類模型需要針對用戶提問、結合可用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選擇': '正確', '參數解析': '錯誤'}}

輸出總結模型需要針對用戶提問與召回的語料進行總結回答，因此需要對模型最終的總結效果進行評價。

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策略，系統能夠對線上推理過程中生成的樣本進行持續的自動化標注和積累。這使得樣本庫能夠不斷擴展和優化，提高模型的在線推理能力。

?

?

?

?

=============

References

?H-MAP planning：Multi-Agent通信協議?

Step 1. 調用方發起調用請求。Master Agent的調用方只能是用戶，領域Agent的調用方可以是Master Agent或其他領域Agent。請求的消息內容和格式見4.2中的請求消息體。Step 2. Agent進行Planning/Reasoning。Agent應用接收到消息請求后,調用內部的Memory管理系統獲取會話歷史信息；Step 3.Reasoning，即生成Thought和Action Code； Thought和Action Code具體含義如下：thought：text. 是指用人類自然語言形式表達的解題決策過程，即任務的大目標和解決問題需要執行的tasks的文字描述。比如：這是一個xxx問題，可以通過先xxx、再xxx來解決。action_code：list of tasks. 是根據thought生成可供應用系統進行調度執行的研發語言，即tasks的結構化描述，支持包含多個tasks的list結構，通常使用采用一個task（即執行完一個拿到observation再執行下一個）。一個task包含4個核心要素：（1）tool_name: 調度對象唯一標識，領域agent或者待調用的api的注冊名稱"name"；（2）parameter：工具調用所需要傳遞的參數；（3）job_desc：調用工具的任務描述，即需要工具來干什么，只對調用Agent生效，api通常只會使用parameters；（4）trust_mode：對tool調用完成后，tool輸出observation的處理方式，1代表agent不基于observation進行下一輪ReAct、直接進入下一個task（通常出現在len(list of tasks) > 1)，0表示需要基于observation更新ReAct。Step 4. Agent執行工具調用Tools call。應用解析 Thought和Action code生成請求消息體。如果Action code中包含工具調用，則執行，否則跳過此步。如果要調用的tool是Agent，調用時傳遞的請求消息體同上面1；如果要調用的工具是API，調用時傳遞的請求消息體見“4.3 API調用協議”中的請求消息體。Step 5. 被調用工具返回結果。若在上一步沒有執行工具調用，則跳過此步。工具調用執行完成后，需要把執行結果返回給調用方。如果被調用的工具是Agent，那么需要返回的關鍵信息包含調用狀態status和結果Observation；如果被調用的工具是API，那么需要返回的關鍵信息包含調用狀態status、observation，具體消息內容和格式見“4.3 API調用協議”中的響應消息體。Step 6. Agent本輪ReAct信息寫入Memory，并同步計入日志系統 。Agent完成一輪ReAct后必須把內部reasoning生成的如Thought、Action code、tools call、出入參、調用時間等關鍵信息通過日志接口寫入助手日志系統。見4.4日志系統接口。Step 7. Agent響應調用請求。Agent在完成step 2-6后，根據step 2生成的trust mode，判定是否向調用方返回響應結果。若trust mode值為1，則可以把observation返回給調用方，具體響應消息內容和格式見4.2的響應消息體；若rust mode值為0，則繼續進行下一輪ReAct，重復 step 2-6。

審核編輯 黃宇