引言

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

第一階段：B商城工單自動回復，LLM和RAG結(jié)合知識庫應答，無法解決工具調(diào)用。

第二階段：京東招商站，單一Agent處理知識庫問答和工具調(diào)用，準確率低 & LLM模型幻覺，場景區(qū)分度差。

第三階段：京麥智能助手，引入multi-agent架構，master + subagents協(xié)同工作模式，把問題分而治之，顯著提升準確率。

?

商家助手的算法底座是基于大語言模型（LLM）構建的Multi-agent系統(tǒng)，模擬的是現(xiàn)實中電商商家團隊的經(jīng)營協(xié)作方式。商家只需使用他們最熟悉的自然語言，與京麥平臺上的這個助手進行溝通，就可以獲得7*24小時的經(jīng)營代理服務。本文檔將從模擬的現(xiàn)實商家經(jīng)營空間映射到Multi-agent算法空間，逐步解析電商平臺業(yè)務場景下商家助手的業(yè)務動機、算法技術架構以及關鍵技術。

商家助手Multi-agent是一個通用&開放的商家經(jīng)營服務多種能力（比如銷量預測，營銷投放，定價，商機詞推薦等）接入的宿主，可隨著建設的不同階段友好的面向其他能力提供方的Tools，包括Agent、API等形式。

1.商家經(jīng)營：從多角色現(xiàn)實空間到Multi-Agent算法空間

Multi-Agent系統(tǒng)架構的設計動機來自于“Agent模擬的是現(xiàn)實世界的人的解決問題過程”的本質(zhì)。首先介紹現(xiàn)實世界商家和他的團隊是怎么經(jīng)營的，以及他們和AI世界怎么進行角色映射。

?

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

?

?

?

2、Multi-Agent Planning關鍵技術：

2.1 Agent構建技術：ReAct范式的多模型集成

1. Agent構建集成四類模型，實現(xiàn)了Agent大腦的智能化逆向規(guī)劃能力：

?LLM：審題并提煉終極目標，為逆向規(guī)劃定向，同時校驗調(diào)用鏈路的合理性。

?Embedding：快速匹配終極節(jié)點工具，避免LLM冗長prompt和選擇工具幻覺問題。

?Tools DAG：進行多路徑逆向推理，結(jié)合LLM抽取參數(shù)工具，精確得到調(diào)度策略。

?運籌優(yōu)化：理論上可加速解題，提升逆向規(guī)劃效率，待實際測試驗證。

2. ReAct規(guī)劃動態(tài)更新

動態(tài)規(guī)劃更新：在規(guī)劃正向執(zhí)行中，ReAct范式實現(xiàn)每一步根據(jù)執(zhí)行結(jié)果的動態(tài)規(guī)劃更新。

3.技術挑戰(zhàn)和收益：

?提升規(guī)劃效率，降低推理成本：多個模型編排替代超大模型，顯著提高推理速度與規(guī)劃效率，同時節(jié)約推理成本。

?提升架構穩(wěn)定性，效果、風險可控：任務拆分后，小模型處理簡單明確任務，大模型專注單一復雜任務，合理分工使效果與風險均可控，減少模型迭代對整體的影響。

?治理LLM幻覺提升規(guī)劃質(zhì)量：Embedding解決LLM帶來的不確定性與幻覺，Tools DAG確保規(guī)劃邏輯性與準確性，京麥場景工具調(diào)用準確率提升10%。

?減少LLM樣本工程量：LLM僅處理文本理解，不直接選工具，避免新工具需大量樣本訓練的問題，系統(tǒng)擴展性與維護效率提高60%以上。

?實時性和準確性：通過ReAct動態(tài)規(guī)劃更新，實時調(diào)整策略，優(yōu)化執(zhí)行鏈路。

?

2.2 Multi-Agent Online Inference

2.2.1 技術特色

1. 任務分層動態(tài)規(guī)劃與分布式協(xié)作：基于ReAct范式，通過Master Agent和Sub Agents在不同層級進行任務動態(tài)規(guī)劃和動態(tài)調(diào)度，支持分布式協(xié)作。

?Master Agent：在領域?qū)用孢M行任務規(guī)劃，將復雜場景拆解為多個獨立子任務調(diào)度sub-Agens協(xié)同工作。

?Sub Agents：在領域內(nèi)執(zhí)行任務規(guī)劃，負責具體的子任務執(zhí)行，支持分布式調(diào)度和協(xié)同工作。

2. Agent協(xié)作基于標準通信協(xié)議：

通過標準通信協(xié)議確保Muti-agent高效協(xié)同工作，支持多步聯(lián)動和全局思維鏈規(guī)劃。

?Agent標準通訊協(xié)議：確保Muti-agent系統(tǒng)中的各agent高效協(xié)同工作，支持任務的分層規(guī)劃和執(zhí)行。

?多步聯(lián)動：支持多個相互依賴的任務，通過ReAct單步執(zhí)行和回調(diào)機制，完成復雜任務。

2.2.2 Multi-Agent Online Inference 演示：

為了展示multi-agent的協(xié)同在線推理流程，錄制了一個視頻。結(jié)合京麥前臺的助手產(chǎn)品形態(tài)，同步展示后臺multi-agent的后臺算法推理服務，方便大家理解。干貨見以下視頻：

?H-MAP_4k.mp4?

?

2.2.3 架構小結(jié)

特色：

推理難度低：將超大模型的全鏈路多步計劃的生成任務，轉(zhuǎn)化成next task prediction

成本低：多個小型模型的協(xié)同更容易落地，訓練、部署成本低

迭代快：問題定位迅速，模型快速迭代

?

待解決：

響應時間長：面對復雜問題，用戶更長的等待耗時，需要在產(chǎn)品上做引導

風險積累：多agents鏈式推理有錯誤累計風險。 解決方案研究中，如多智能體聯(lián)合學習

?

多Agent架構與單Agent及LLM-MoE架構對比，多Agent架構在同等大模型能力下具有更強的穩(wěn)定性，能更好支持復雜業(yè)務場景和任務的協(xié)作與擴展，但需要更多的工程開發(fā)量和更復雜的推理鏈路。

?技術方案調(diào)研?

?

2.3 Agent全鏈路ReAct評估技術

1.Agent全鏈路ReAct效能綜合評估

?全鏈路評估：從全局視角出發(fā)，通過任務拆解和鏈路調(diào)度，對系統(tǒng)中每個Agent進行加權評分，以計算Multi-Agent系統(tǒng)的整體效能。

?局部評估：使用Reward Model對每個Agent的ReAct循環(huán)中存在的thought/action/observation進行評估，識別性能瓶頸和低效模型環(huán)節(jié)，提供針對性優(yōu)化建議。

2.多樣化Reward Model

?業(yè)務自定義：支持業(yè)務自定義規(guī)則函數(shù)/reward模型，用于靈活適應不同業(yè)務需求的評估。

?現(xiàn)有大模型：利用現(xiàn)有的高階Sota大模型進行評估，確保評估的通用性和準確性。

?訓練Reward模型：通過訓練專門的模型進行評估，提升對特定任務和場景的適應能力。

?

Reward Model-平臺化AI評估模型案例說明：

輸入總結(jié)模型的目標是針對用戶歷史的會話記錄與本輪的提問分析其具體意圖，作為Master Agent的思考的核心環(huán)節(jié)，需要對其意圖總結(jié)效果進行評價。

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶當前輪次提問與歷史的會話記錄，對線上推理的準確性進行評價。
2.自動化評分指令（簡化）：
你是一個擅長問題意圖理解的專家。現(xiàn)在需要你評估一個電商平臺AI助手對于商家用戶提問的意圖理解質(zhì)量，并要求你從以下維度對回答進行評估，評分為0-10分，分數(shù)必須是整數(shù):1.正確性:意圖是否正確表達出用戶當前的問題；2.關聯(lián)性:當前問題的意圖可能和歷史對話強關聯(lián)，也可能無關，判斷助手理解的意圖是否正確關聯(lián)歷史對話。
我們會給你提供用戶本輪提問、歷史與AI助手的對話，和需要你評估的AI助手答案。有可能為你提供一個參考答案，當給出參考答案時，你需要判斷AI助手總結(jié)的意圖和給出的參考意圖的相似度，該維度名為“和人工理解相似程度”。
按照以下字典格式（包括括號）返回你所有的打分結(jié)果：{{'維度一': 打分, '維度二': 打分, ..., '綜合得分': 打分}}。例如：{{'正確性': 6, '關聯(lián)性': 9, ..., '綜合得分': 7}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[歷史對話開始]n{history_conv}n[歷史對話結(jié)束]
[參考意圖開始]n{reference}n[參考意圖結(jié)束]n
[助手意圖理解開始]n{intention}n[助手理解意圖結(jié)束]n

2、待評估案例：
假設用戶本輪提問、歷史對話、助手意圖理解分別如下：
1.用戶本輪提問：
我這個是京東小店的
2.歷史對話：
【顧客】：什么類目的標題可以不帶品牌的名字
【客服】：都需要帶上品牌的
3.助手意圖理解：
說明店鋪類型為某平臺小店

3、不同標注場景下的打分結(jié)果：
1.存在人工標注：此時人工標注即為指令中的“參考意圖”
參考意圖：
詢問京東小店的商品標題是否需要帶品牌名字
評分結(jié)果：
    1.正確性: 助手理解的意圖并沒有準確表達出用戶當前的問題。用戶當前的問題是詢問京東小店的商品標題是否需要帶品牌名字，而助手理解的意圖只是說明了店鋪類型為某平臺小店，未能準確捕捉用戶的真實意圖。
    2.關聯(lián)性: 助手理解的意圖與歷史對話沒有正確關聯(lián)。歷史對話中用戶詢問的是商品標題是否需要帶品牌名字，而助手理解的意圖并未涉及這一點。
    3.和人工理解相似程度: 助手理解的意圖與人工意圖有明顯差異。人工意圖準確捕捉了用戶的問題，而助手理解的意圖只是說明了店鋪類型，未能反映用戶的真實需求。
    綜合評價:助手理解的意圖未能準確表達用戶的真實意圖，也未能正確關聯(lián)歷史對話，與人工意圖差異較大，因此綜合評分較低。
    綜合來說：{{'正確性': 3, '關聯(lián)性': 2, '和人工理解相似程度':2, '綜合得分':2}}
2.不存在人工標注：此時指令中的“參考意圖”為“無”
評分結(jié)果：
    1.正確性: 助手理解的意圖與用戶當前提問的主要內(nèi)容不符。用戶想了解的是京東小店的商品標題中是否需要說明品牌名稱，助手理解的用戶意圖為說明自身為京東小店，意圖理解錯誤。
    2.關聯(lián)性: 助手理解的意圖與歷史對話未正確關聯(lián)。在之前的會話中，用戶詢問的目的是商品標題攜帶品牌名的必要性，助手未理解該意圖。
    綜合評價:助手理解的意圖在正確性和關聯(lián)性上均有不足，因此綜合評分較低。
    綜合來說：{{'正確性': 3, '關聯(lián)性': 2, '綜合得分':3}}

工具調(diào)度類模型需要針對用戶提問、結(jié)合可用API的具體描述，進行API選擇與相關的參數(shù)解析，因此需要對模型解析出的action code進行準確度評價。

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶提問、API資料庫，對線上推理的準確性進行評價。
2.自動化評分指令（簡化）：
你是一個擅長評價API使用合理性的助手?，F(xiàn)在需要你評估一個電商平臺AI助手要解決商家用戶提問時，所調(diào)用的API是否正確；如果正確選擇了API，需要進一步判斷對該API的參數(shù)解析是否正確。請注意：你只需要評價API選擇以及參數(shù)解析的正確與否，不需要生成正確的調(diào)用方法。
我們會給你提供用戶的提問、API，和需要你評估的AI助手答案。可能為你提供用戶提問的對應參考答案，當存在參考答案時，準確性評價必須與參考答案對比得出；不存在參考答案時，僅需要根據(jù)助手答案自身展開評價。
按照以下字典格式（包括括號）返回你所有的評價結(jié)果：{{'API選擇': 正確或錯誤, '參數(shù)解析': 當API選擇錯誤時，結(jié)果為“無”；當API選擇正確時，結(jié)果為正確或錯誤}}。例如：{{'API選擇': '錯誤', '參數(shù)解析': '無'}}；{{'API選擇': '正確', '參數(shù)解析': '正確'}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[API信息開始]n{retrivals}n[API信息結(jié)束]n
[參考解析結(jié)果開始]n{reference}n[參考解析結(jié)果結(jié)束]n
[助手解析結(jié)果開始]n{answer}n[助手解析結(jié)果結(jié)束]n 

2、待評估案例：
假設用戶本輪提問、API信息、助手解析結(jié)果分別如下：
1.用戶本輪提問：
我有多少訂單是王萍萍買的？    
2.API信息：
【1】{
    "name": "check_shop_qualifications",
    "description": "當用戶提出有關經(jīng)營過程中資質(zhì)要求（如上傳材料、營業(yè)執(zhí)照、行業(yè)資質(zhì)等）相關的問題時，需要調(diào)用此工具查詢具體資質(zhì)要求的相關信息，然后根據(jù)查詢到的信息回答用戶問題。",
    "parameters": {
        "type": "object",
        "properties": {
            "keyword": {
                "description": "用戶經(jīng)營的主要類目、商品類型或者商品品牌，例如：洋酒、玩具、阿迪達斯等。如果沒有提供該類信息，必須反問用戶要求其提供"
            },
            "shop_body": {
                "description": "店鋪主體，只能是以下三種：企業(yè)、個人和個體工商。"
            },
            "shop_type": {
                "description": "店鋪類型，只能是以下六種：旗艦店、專賣店、專營店、賣場店、普通企業(yè)店和小店。"
            }
        },
        "required": ["keyword"]
    }
}
【2】{
    "name": "search_order_code",
    "description": "該工具用于根據(jù)用戶提供的信息（如訂單編號、下單時間、下單賬號等）查詢訂單的詳細信息，包括商品詳情與訂單詳情。",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {
                "description": "訂單編號：12位純數(shù)字，用于記錄訂單的唯一標識"
            },
            "consumer_name": {
                "description": "客戶姓名：用戶姓名、買家姓名、收件人、收貨人、顧客、客戶等"
            },
            "user_pin": {
                "description": "下單賬號：下單賬戶、買家pin，買家、顧客、用戶等，通常由客戶姓名+數(shù)字或純英文組成"
            },
            "sku_id": {
                "description": "商品編號：14位純數(shù)字信息，"
            },
            "sku_name": {
                "description": "商品名稱：商品信息的描述，可能攜帶品牌信息或商品具體屬性"
            },
            "consumer_mobile_phone": {
                "description": "客戶電話：用戶手機號碼，11位純數(shù)字信息，可能會以區(qū)號+86，400等開頭。"
            },
            "search_keys": {
                "description": "用戶希望查詢的目標，枚舉值只能從[商品、訂單]中選擇。若用戶希望查詢的是訂單中的商品id、商品名稱、商品詳情等，枚舉值為商品；若用戶希望查詢的目標是訂單編號、訂單數(shù)量等，枚舉值為訂單。"
            }
        },
        "required": []
    }
}
3.助手解析結(jié)果：
{
    "action_code": {
        "api_name": "search_order_code",
        "parameter": {
            "consumer_name": [
                "王萍萍"
            ],
            "search_keys": [
                "商品"
            ]
        },
    }
}

3、不同標注場景下的打分結(jié)果：
1.存在人工標注：此時人工標注即為指令中的“參考解析結(jié)果”
參考解析結(jié)果：
{
    "action_code": {
        "api_name": "search_order_code",
        "parameter": {
            "consumer_name": [
                "王萍萍"
            ],
            "search_keys": [
                "訂單"
            ]
        },
    }
}
評分結(jié)果：
    1.API選擇：AI助手的答案中選擇調(diào)用search_order_code，與參考答案一致，API調(diào)用正確。
    2.參數(shù)解析：AI助手的答案中search_keys為商品，但參考答案中search_keys為訂單，因此參數(shù)解析錯誤。
    綜合來說：{{'API選擇': '正確', '參數(shù)解析': '錯誤'}}
2.不存在人工標注：此時指令中的“參考答案”為“無”
評分結(jié)果：
    1.API選擇：用戶希望查詢顧客王萍萍的訂單，AI助手的答案中選擇調(diào)用search_order_code，該工具可以進行訂單詳情查詢，因此API調(diào)用正確。
    2.參數(shù)解析：API助手解析的參數(shù)中，查詢目標為商品，但用戶希望查詢的內(nèi)容是訂單，因此參數(shù)解析結(jié)果與用戶提問意圖不符，解析錯誤。
    綜合來說：{{'API選擇': '正確', '參數(shù)解析': '錯誤'}}

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

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶提問與召回的語料得到線上推理的回答評分。針對有人工標注和無人工標注兩種情況，構造出一套通用的打分指令，兼容不同場景。
2.自動化評分指令（簡化）：
你是一個擅長評價文本質(zhì)量的助手。現(xiàn)在需要你評估一個電商平臺AI助手對于商家用戶提問的回答的質(zhì)量，并要求你從以下維度對回答進行評估，評分為0-10分，分數(shù)必須是整數(shù):1.滿足用戶需求:回答內(nèi)容是否解決用戶提問；2.事實正確性:回答是否從參考語料中得到，不允許過度推斷得到的回答；3.回答完備性:僅針對要回答的問題，是否完整地提取了語料中的全部信息。
我們會給你提供用戶的提問、需參考的核心語料，和需要你評估的AI助手答案?？赡転槟闾峁┯脩籼釂柕膶獏⒖即鸢?，當存在參考答案時，評分需要對比參考答案得出；不存在參考答案時，僅需要根據(jù)助手答案自身展開評價。
按照以下字典格式（包括括號）返回你所有的打分結(jié)果：{{'維度一': 打分, '維度二': 打分, ..., '綜合得分': 打分}}。例如：{{'滿足用戶需求': 6, '事實正確性': 9, ..., '綜合得分': 7}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[核心語料開始]n{retrivals}n[核心語料結(jié)束]n
[參考總結(jié)結(jié)果開始]n{reference}n[參考總結(jié)結(jié)果結(jié)束]n
[助手總結(jié)結(jié)果開始]n{answer}n[助手總結(jié)結(jié)果結(jié)束]n 

2、待評估案例：
假設用戶本輪提問、核心語料、助手總結(jié)結(jié)果分別如下：
1.用戶本輪提問：
偏遠地區(qū)發(fā)出了又不要了，運費誰承擔
2.核心語料：
【1】[售后-交易糾紛] 京東開放平臺運費問題糾紛處理標準鏈接：https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1
【2】[售后-交易糾紛] 當買賣雙方根據(jù)運費發(fā)生糾紛時，京東根據(jù)“誰過錯，誰承擔”的原則處理，但買賣雙方協(xié)商一致的除外。
【3】[售后-交易糾紛] 《運費問題的糾紛處理規(guī)則》判定運費糾紛責任：第十條 若買賣雙方就如上運費問題產(chǎn)生糾紛，申請京東介入的，京東將根據(jù)本標準內(nèi)容進行判定，如商家違反運費要求或舉證內(nèi)容無效，將判定商家責任。
3.助手總結(jié)結(jié)果：
當買賣雙方根據(jù)運費發(fā)生糾紛時，京東根據(jù)“誰過錯，誰承擔”的原則處理，但買賣雙方協(xié)商一致的除外。具體處理標準您可參考以下鏈接：[京東開放平臺運費問題糾紛處理標準鏈接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)

3、不同標注場景下的打分結(jié)果：
1.存在人工標注：此時人工標注即為指令中的“參考總結(jié)結(jié)果”
參考總結(jié)結(jié)果：
京東根據(jù)“誰過錯，誰承擔”的原則處理，但買賣雙方協(xié)商一致的除外：若消費者無正當理由拒絕簽收，發(fā)貨運費由消費者承擔；消費者有理由拒絕簽收（商品有質(zhì)量問題、少貨等），發(fā)貨運費由商家承擔。n詳細內(nèi)容請參考[京東開放平臺運費問題糾紛處理標準鏈接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)
評分結(jié)果：
    1. 滿足用戶需求:AI助手的答案部分解決了用戶的提問，提到了“誰過錯，誰承擔”的原則，但沒有具體說明在偏遠地區(qū)發(fā)貨后又不要了的情況下，運費由誰承擔。相比之下，參考答案更詳細地解釋了不同情況下的運費承擔方。因此，AI助手的回答在滿足用戶需求方面不夠全面。
    2. 事實正確性:AI助手的答案內(nèi)容來自核心語料，引用了“誰過錯，誰承擔”的原則，并提供了相關鏈接。這部分內(nèi)容是準確的。
    3. 回答完備性:AI助手的答案沒有完全提取核心語料中的全部信息，尤其是缺少了關于消費者無正當理由拒絕簽收和有理由拒絕簽收的具體情況的解釋。相比之下，參考答案更為詳細和完備。
    綜合評價:AI助手的回答在事實正確性方面表現(xiàn)良好，但在滿足用戶需求和回答完備性方面有所欠缺?？傮w來說，回答質(zhì)量中等。
    綜合評分如下：{{'滿足用戶需求': 5, '事實正確性': 10, '回答完備性': 4, '綜合得分': 6}}
2.不存在人工標注：此時指令中的“參考答案”為“無”
評分結(jié)果：
    1. 滿足用戶需求:AI助手的答案部分解決了用戶的提問。用戶詢問的是偏遠地區(qū)發(fā)貨后又取消訂單的情況下運費由誰承擔，AI助手回答了京東處理運費糾紛的原則是“誰過錯，誰承擔”，并提供了一個鏈接供用戶參考。然而，AI助手沒有明確回答在偏遠地區(qū)發(fā)貨后取消訂單的具體情況，是否由買家或賣家承擔運費。因此，AI助手的回答不完全滿足用戶需求。
    2. 事實正確性:AI助手的答案是從核心語料中提取的，引用了“誰過錯，誰承擔”的原則，并提供了相關鏈接。這些信息都準確無誤，符合核心語料的內(nèi)容。
    3. 回答完備性:AI助手的回答雖然引用了核心語料中的信息，但沒有完全提取所有相關信息。例如，核心語料中提到的“買賣雙方協(xié)商一致的除外”以及“京東將根據(jù)本標準內(nèi)容進行判定，如商家違反運費要求或舉證內(nèi)容無效，將判定商家責任”這些內(nèi)容沒有被提及。這些信息對于用戶理解運費糾紛的處理方式是有幫助的。
    綜合評價:AI助手的回答在事實正確性方面表現(xiàn)良好，但在滿足用戶需求和回答完備性方面還有提升空間。總體來說，回答質(zhì)量中等。
    綜合評分如下：{{'滿足用戶需求': 6, '事實正確性': 10, '回答完備性': 6, '綜合得分': 7}}

?

2.4 LLM離在線樣本增強技術

1. 自動化離線樣本生成與擴展

?離線接入的標準化語料：通過接入標準化的業(yè)務數(shù)據(jù)，能夠自動化生成和擴展用于LLM訓練的樣本，快速適配不同場景訓練需求，批量生成高質(zhì)量訓練樣本。

2. 自動化在線推理標注與樣本積累

?Agent在線推理數(shù)據(jù)：通過多種Reward Model策略，系統(tǒng)能夠?qū)€上推理過程中生成的樣本進行持續(xù)的自動化標注和積累。這使得樣本庫能夠不斷擴展和優(yōu)化，提高模型的在線推理能力。

?

?

?

?

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

References

?H-MAP planning：Multi-Agent通信協(xié)議?

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

審核編輯 黃宇