1. 項(xiàng)目概述當(dāng)智能體開始“組隊(duì)”上網(wǎng)最近多智能體Multi-Agent協(xié)作在AI圈子里火得不行。大家不再滿足于讓一個“全能”的AI單打獨(dú)斗而是開始琢磨怎么讓一群各有所長的“AI專家”組隊(duì)去完成更復(fù)雜、更貼近真實(shí)世界的任務(wù)。這就像從“超級英雄”電影轉(zhuǎn)向了“復(fù)仇者聯(lián)盟”——單個英雄再強(qiáng)也有短板但團(tuán)隊(duì)協(xié)作卻能解決更棘手的難題。而“上網(wǎng)”——也就是基于Web的操作恰恰是檢驗(yàn)這種協(xié)作能力的絕佳沙盒。想想看我們?nèi)粘５暮芏喙ぷ鞅热缫?guī)劃一次旅行、研究一個課題、完成一份市場報(bào)告不就是在瀏覽器里開一堆標(biāo)簽頁查資料、比價(jià)格、填表格、發(fā)郵件嗎這個過程天然就是多任務(wù)、多步驟、需要信息整合與決策的?！癆gentWebBench”這個項(xiàng)目瞄準(zhǔn)的就是這個前沿且極具實(shí)用價(jià)值的領(lǐng)域?qū)Χ嘀悄荏w在Web環(huán)境下的協(xié)同能力進(jìn)行系統(tǒng)性評測。它不是一個具體的應(yīng)用而是一個“考場”和“標(biāo)尺”。簡單說它構(gòu)建了一系列模擬真實(shí)網(wǎng)頁交互的復(fù)雜任務(wù)場景然后放一群AI智能體進(jìn)去看它們?nèi)绾瓮ㄟ^溝通、分工、接力來完成目標(biāo)并用量化的指標(biāo)來評價(jià)它們協(xié)作得好不好。這背后的核心挑戰(zhàn)在于Web環(huán)境是開放、動態(tài)且充滿不確定性的。一個智能體可能擅長信息檢索另一個擅長表單填寫但如何讓它們理解彼此進(jìn)度、處理沖突、在任務(wù)失敗時靈活調(diào)整策略才是真正的難點(diǎn)。AgentWebBench要做的就是把這些難點(diǎn)變成一道道可測量、可比較的“考題”從而推動整個多智能體協(xié)作技術(shù)的發(fā)展。2. 核心設(shè)計(jì)思路如何為“AI團(tuán)隊(duì)”設(shè)計(jì)一場網(wǎng)頁端的高考設(shè)計(jì)一個多智能體Web協(xié)作的基準(zhǔn)測試遠(yuǎn)比設(shè)計(jì)單智能體測試復(fù)雜。你不能只關(guān)心最終任務(wù)成功與否更要關(guān)注協(xié)作的過程是否高效、魯棒。AgentWebBench的設(shè)計(jì)思路我認(rèn)為可以從以下幾個層面來拆解。2.1 任務(wù)場景的層次化構(gòu)建首先基準(zhǔn)測試的任務(wù)不能太簡單比如“打開百度搜索‘天氣’”這體現(xiàn)不出協(xié)作價(jià)值也不能是天馬行空、無法評估的。AgentWebBench的任務(wù)設(shè)計(jì)很可能遵循一個從易到難、從封閉到開放的層次。第一層流程化任務(wù)Orchestration Tasks。這類任務(wù)有明確、線性的步驟。例如“預(yù)訂航班和酒店”任務(wù)智能體A需要搜索航班信息并選擇合適選項(xiàng)智能體B需要同步搜索酒店信息然后兩者需要將信息如日期、價(jià)格進(jìn)行比對和協(xié)調(diào)最終由智能體C完成支付頁面的填寫。這里的協(xié)作模式更像是“流水線”或“指揮與執(zhí)行”考驗(yàn)的是任務(wù)分解與順序執(zhí)行的協(xié)調(diào)能力。第二層信息整合任務(wù)Information Synthesis Tasks。這類任務(wù)需要從多個異構(gòu)信息源中提取、交叉驗(yàn)證并綜合成結(jié)論。例如“對比三款手機(jī)的最新評測并總結(jié)優(yōu)缺點(diǎn)”智能體A去科技媒體網(wǎng)站智能體B去電商平臺看用戶評價(jià)智能體C去專業(yè)測評機(jī)構(gòu)網(wǎng)站。它們不僅需要各自收集信息還需要能識別信息中的矛盾比如A說續(xù)航好B說續(xù)航差并通過進(jìn)一步查詢或協(xié)商形成一份統(tǒng)一的對比報(bào)告。這考驗(yàn)的是信息感知、沖突消解和知識融合的能力。第三層突發(fā)處理與決策任務(wù)Contingency Handling Decision Tasks。這是最高難度的層級模擬真實(shí)網(wǎng)頁交互中的不確定性。例如任務(wù)目標(biāo)是“購買一本下周前打折的特定書籍”。在執(zhí)行過程中可能出現(xiàn)各種意外智能體A發(fā)現(xiàn)目標(biāo)書籍缺貨智能體B在支付頁面遇到驗(yàn)證碼或者中途發(fā)現(xiàn)另一個網(wǎng)站有更優(yōu)惠的促銷。這時智能體們需要自主識別這些突發(fā)狀況重新協(xié)商策略是等待補(bǔ)貨、嘗試其他平臺還是更換書籍并做出新的聯(lián)合決策。這直接考驗(yàn)多智能體系統(tǒng)的魯棒性和自適應(yīng)能力。2.2 智能體角色與交互協(xié)議的定義要讓智能體們協(xié)作必須先定義好“游戲規(guī)則”。AgentWebBench需要一套清晰的智能體角色框架和交互協(xié)議。角色分工通常不會讓所有智能體能力同質(zhì)化。常見的角色包括協(xié)調(diào)者Coordinator/Manager負(fù)責(zé)頂層任務(wù)規(guī)劃、分解子任務(wù)、分配資源比如指定哪個智能體去哪個網(wǎng)站、并監(jiān)控整體進(jìn)度。它像團(tuán)隊(duì)的“項(xiàng)目經(jīng)理”。執(zhí)行者Executor負(fù)責(zé)具體的網(wǎng)頁操作如點(diǎn)擊、輸入、滾動、提取文本。它們根據(jù)協(xié)調(diào)者的指令行動并反饋執(zhí)行結(jié)果成功、失敗、遇到了什么異常。專家Specialist擁有特定領(lǐng)域知識或技能的智能體。例如一個“表單填寫專家”擅長理解各種輸入框的語義并生成合規(guī)內(nèi)容一個“反爬蟲處理專家”擅長應(yīng)對驗(yàn)證碼、登錄彈窗等障礙。驗(yàn)證者Verifier負(fù)責(zé)檢查其他智能體工作的質(zhì)量。例如在執(zhí)行者提交了提取的信息后驗(yàn)證者會去核對信息的準(zhǔn)確性或完整性。交互協(xié)議智能體之間如何“說話”這通常通過一個共享的“工作空間”或“消息總線”來實(shí)現(xiàn)。智能體將它們的觀察我看到了什么、行動我做了什么、意圖我接下來打算做什么以及請求我需要什么幫助發(fā)布到這個空間中。其他智能體訂閱自己關(guān)心的信息。協(xié)議需要定義清晰的消息格式例如采用類似智能體框架如AutoGen、CrewAI中的AgentMessage結(jié)構(gòu)包含發(fā)送者、接收者、消息類型如TASK_ASSIGNMENTACTION_RESULTERROR_REPORTCONFIRMATION_REQUEST和具體內(nèi)容。2.3 評估指標(biāo)的多維度體系這是基準(zhǔn)測試的靈魂。單一的“任務(wù)完成率”遠(yuǎn)遠(yuǎn)不夠。AgentWebBench的評估體系一定是多維度的旨在全面刻畫協(xié)作效能。有效性Effectiveness任務(wù)完成率Task Success Rate最基礎(chǔ)的指標(biāo)任務(wù)是否在限定步驟或時間內(nèi)被正確完成。子目標(biāo)達(dá)成率Sub-goal Achievement Rate對于復(fù)雜任務(wù)衡量每個關(guān)鍵步驟是否成功。結(jié)果質(zhì)量Result Quality對于信息整合類任務(wù)需要評估生成報(bào)告的信息準(zhǔn)確性、完整性和組織邏輯性可以采用人工評分或與標(biāo)準(zhǔn)答案的相似度如Rouge-L, BERTScore來衡量。效率Efficiency總步數(shù)Total Steps完成整個任務(wù)所消耗的交互步數(shù)如點(diǎn)擊、輸入的總次數(shù)。步數(shù)越少通常說明規(guī)劃越優(yōu)、操作越精準(zhǔn)。總耗時Total Elapsed Time模擬時鐘下的任務(wù)執(zhí)行總時間。這包含了智能體“思考”LLM推理的時間和模擬操作的時間。通信開銷Communication Overhead智能體之間交換的消息數(shù)量或總token數(shù)。過度的通信可能意味著協(xié)調(diào)低效或存在冗余討論。協(xié)作質(zhì)量Collaboration Quality沖突解決成功率Conflict Resolution Rate當(dāng)智能體間出現(xiàn)信息或決策沖突時能否成功協(xié)商解決。資源利用率Resource Utilization是否所有智能體都發(fā)揮了作用有沒有智能體一直閑置或者出現(xiàn)“一智能體干活其他圍觀”的情況恢復(fù)能力Recovery Capability在遇到預(yù)期外的網(wǎng)頁錯誤如404、元素未找到時系統(tǒng)能否自主調(diào)整策略并繼續(xù)推進(jìn)任務(wù)而不是直接失敗。成本Cost總Token消耗Total Token Consumption由于智能體核心多是LLM它們與LLM API的交互token量直接關(guān)聯(lián)著經(jīng)濟(jì)成本。一個高效的協(xié)作系統(tǒng)應(yīng)能在保證效果的前提下盡可能減少不必要的LLM調(diào)用。一個設(shè)計(jì)良好的基準(zhǔn)測試會為上述不同類別的指標(biāo)分配權(quán)重最終計(jì)算出一個綜合得分用于橫向比較不同的多智能體系統(tǒng)架構(gòu)或策略。3. 關(guān)鍵技術(shù)實(shí)現(xiàn)與實(shí)操要點(diǎn)理解了設(shè)計(jì)思路我們來看看要具體實(shí)現(xiàn)這樣一個基準(zhǔn)測試需要攻克哪些技術(shù)難關(guān)以及在實(shí)際操作中需要注意什么。3.1 網(wǎng)頁環(huán)境的高保真模擬測試環(huán)境必須足夠真實(shí)但又可控、可重復(fù)。直接用真實(shí)的互聯(lián)網(wǎng)網(wǎng)站進(jìn)行測試是不可行的因?yàn)榫W(wǎng)站內(nèi)容隨時在變且可能觸發(fā)反爬機(jī)制。因此AgentWebBench的核心基礎(chǔ)設(shè)施是一個高保真、可編程的網(wǎng)頁模擬環(huán)境。主流技術(shù)選型目前業(yè)界主要有兩種路徑無頭瀏覽器 靜態(tài)快照使用Playwright或Selenium等工具預(yù)先對目標(biāo)任務(wù)涉及的一系列網(wǎng)頁進(jìn)行“錄制”保存下完整的DOM結(jié)構(gòu)、CSS樣式甚至JavaScript狀態(tài)生成一個靜態(tài)的、可交互的“網(wǎng)頁快照”。測試時智能體在這個快照副本上操作。優(yōu)點(diǎn)是環(huán)境完全穩(wěn)定、速度快缺點(diǎn)是交互動態(tài)性有限無法模擬那些高度依賴后端實(shí)時響應(yīng)的操作如實(shí)時搜索提示。輕量級模擬器如WebShop、MiniWoBMini World of Bits所采用的思路。它們用簡化的HTML片段和JavaScript來定義一個任務(wù)空間智能體通過有限的動作如點(diǎn)擊[button_id] 在[input_id]中輸入文本進(jìn)行交互。優(yōu)點(diǎn)是極其輕量、運(yùn)行速度快適合大規(guī)模測試缺點(diǎn)是視覺和交互保真度低與真實(shí)網(wǎng)頁差距較大。實(shí)操建議對于AgentWebBench這種旨在評測“智能體協(xié)作”而非“計(jì)算機(jī)視覺”能力的基準(zhǔn)我傾向于采用一種混合模式。對于任務(wù)的核心流程頁面如電商的產(chǎn)品頁、結(jié)算頁使用精心制作的靜態(tài)快照確保關(guān)鍵交互元素按鈕、表單的語義和屬性完全真實(shí)。對于輔助性的、信息展示為主的頁面如搜索結(jié)果列表、文章詳情頁可以采用簡化模擬甚至直接以結(jié)構(gòu)化數(shù)據(jù)JSON的形式提供給智能體以降低環(huán)境復(fù)雜性對評測的干擾。關(guān)鍵在于要明確標(biāo)注出每個頁面或組件的“可操作接口”讓智能體知道它能做什么。注意在構(gòu)建模擬環(huán)境時務(wù)必為每個可交互元素如按鈕、鏈接、輸入框賦予唯一且語義化的ID或?qū)傩岳?class ManagerAgent: def __init__(self, llm_client, worker_agents): self.llm llm_client self.workers worker_agents # 字典key為角色value為智能體實(shí)例 def execute_task(self, main_task): # 步驟1任務(wù)規(guī)劃與分解 plan_prompt f 你是任務(wù)經(jīng)理。你的目標(biāo)是{main_task}。 請將任務(wù)分解為一系列子任務(wù)并為每個子任務(wù)指定最適合的執(zhí)行角色。 可用的角色有{list(self.workers.keys())}。 輸出格式JSON列表每個元素包含‘sub_task’和‘a(chǎn)ssigned_role’。 sub_tasks self.llm.generate_json(plan_prompt) results [] for st in sub_tasks: role st[assigned_role] worker self.workers[role] # 步驟2分配任務(wù)給執(zhí)行者 result worker.execute(st[sub_task], contextresults) # 傳入上下文 results.append(result) # 步驟3監(jiān)控與簡單協(xié)調(diào)例如檢查結(jié)果是否有效是否需要重試 if result[status] FAILED: # 可能重新分配或調(diào)整策略 pass # 步驟4結(jié)果整合 synthesis_prompt f 原始任務(wù){(diào)main_task}。 以下是各個子任務(wù)的結(jié)果{results}。 請整合這些結(jié)果形成最終答案。 final_result self.llm.generate(synthesis_prompt) return final_result4. 評測流程與結(jié)果分析實(shí)踐搭建好環(huán)境和智能體后真正的評測是如何進(jìn)行的這涉及到一整套自動化的流水線。4.1 自動化評測流水線搭建一個完整的評測流水線通常包括以下組件任務(wù)加載器從基準(zhǔn)測試的題庫中讀取任務(wù)定義包括任務(wù)描述、初始URL、成功條件如最終頁面需包含特定文本、特定表單需被提交等。環(huán)境控制器負(fù)責(zé)初始化模擬環(huán)境將任務(wù)加載到環(huán)境中并在每個測試步重置環(huán)境如果需要。多智能體系統(tǒng)運(yùn)行器這是核心執(zhí)行模塊。它實(shí)例化所需的各種智能體注入任務(wù)并啟動智能體間的協(xié)作循環(huán)。它需要處理智能體的行動執(zhí)行、環(huán)境狀態(tài)更新、消息路由等。監(jiān)控與記錄器詳細(xì)記錄整個執(zhí)行過程每一步是哪個智能體、執(zhí)行了什么動作、環(huán)境狀態(tài)如何變化、智能體間發(fā)送了哪些消息、LLM的調(diào)用內(nèi)容和消耗等。這些日志是后續(xù)分析的黃金數(shù)據(jù)。評估器根據(jù)預(yù)先定義的評估指標(biāo)對執(zhí)行日志進(jìn)行自動分析計(jì)算各項(xiàng)得分。實(shí)操工具鏈可以使用Python作為主語言Playwright用于高保真環(huán)境模擬LangChain或AutoGen等框架來快速搭建智能體原型使用像Weights Biases或MLflow這樣的實(shí)驗(yàn)管理工具來跟蹤每次運(yùn)行的超參數(shù)、日志和評估結(jié)果便于對比分析。4.2 基準(zhǔn)任務(wù)的具體執(zhí)行案例讓我們以一個具體的“旅行規(guī)劃”任務(wù)為例走一遍評測流程。任務(wù)描述“請為一位計(jì)劃下周從北京前往上海進(jìn)行三天兩夜商務(wù)旅行的用戶預(yù)訂一趟合適的航班經(jīng)濟(jì)艙和一家位于市中心、評分4.0以上的酒店?？傤A(yù)算控制在5000元以內(nèi)。最終需要提供航班號、起降時間、酒店名稱、地址和總費(fèi)用估算。”成功條件最終生成的報(bào)告包含所有要求的字段航班號、時間、酒店名、地址、總費(fèi)用。航班和酒店的選擇符合所有約束時間、地點(diǎn)、評分、預(yù)算。信息必須是從模擬的“航班預(yù)訂網(wǎng)站”和“酒店預(yù)訂網(wǎng)站”上真實(shí)提取的而非捏造。智能體團(tuán)隊(duì)配置協(xié)調(diào)者Coordinator1個。負(fù)責(zé)解析任務(wù)分解為“查航班”和“查酒店”兩個并行子任務(wù)并最終整合信息。信息檢索員Retriever2個。一個專攻航班網(wǎng)站一個專攻酒店網(wǎng)站。他們負(fù)責(zé)在網(wǎng)站上執(zhí)行搜索、篩選、信息提取等具體操作。驗(yàn)證與預(yù)算員Verifier/Budgeter1個。負(fù)責(zé)核對檢索員提取的信息是否符合要求如酒店評分并計(jì)算總費(fèi)用是否超預(yù)算。執(zhí)行過程可能如下協(xié)調(diào)者啟動將任務(wù)分解并分別向航班檢索員和酒店檢索員發(fā)送指令。兩個檢索員同時開始工作。航班檢索員進(jìn)入模擬的“航班搜索”頁面輸入北京、上海、下周日期等條件篩選經(jīng)濟(jì)艙瀏覽結(jié)果列表提取幾個備選航班的信息航班號、時間、價(jià)格。酒店檢索員類似地操作篩選市中心、評分4.0的酒店提取備選信息名稱、地址、價(jià)格。兩個檢索員將初步結(jié)果發(fā)送給驗(yàn)證與預(yù)算員。驗(yàn)證與預(yù)算員檢查酒店評分是否真實(shí)達(dá)標(biāo)并計(jì)算“航班價(jià)格酒店價(jià)格*2晚”的總和。假設(shè)第一次計(jì)算發(fā)現(xiàn)超預(yù)算。驗(yàn)證與預(yù)算員將“超預(yù)算”的結(jié)論反饋給協(xié)調(diào)者。協(xié)調(diào)者發(fā)出調(diào)整指令“請航班檢索員和酒店檢索員分別尋找更便宜的選項(xiàng)?！睓z索員們調(diào)整篩選條件如選擇更早或更晚的航班、選擇價(jià)格稍低的酒店進(jìn)行第二輪檢索。重復(fù)步驟4-5直到找到符合預(yù)算的組合。協(xié)調(diào)者收到最終合格的航班和酒店信息將其整合成一份格式化的報(bào)告任務(wù)完成。評估器會分析這個過程的日志計(jì)算總步數(shù)所有智能體行動之和、總耗時、通信輪次、LLM總token消耗并檢查最終報(bào)告是否滿足所有成功條件給出有效性得分。4.3 結(jié)果分析與洞見挖掘運(yùn)行完一批任務(wù)后你會得到一堆數(shù)據(jù)。如何從中得出有意義的結(jié)論橫向?qū)Ρ冗@是基準(zhǔn)測試的主要目的。你可以對比不同的多智能體框架比如用AutoGen搭建的系統(tǒng) vs. 用CrewAI搭建的系統(tǒng)在同一個AgentWebBench上的表現(xiàn)?？茨膫€在綜合得分上更高或者在效率、協(xié)作質(zhì)量等特定指標(biāo)上更優(yōu)。消融實(shí)驗(yàn)這是深入理解的關(guān)鍵。例如你可以設(shè)計(jì)以下實(shí)驗(yàn)實(shí)驗(yàn)A完整的智能體團(tuán)隊(duì)協(xié)調(diào)者檢索員驗(yàn)證員。實(shí)驗(yàn)B移除驗(yàn)證員讓協(xié)調(diào)者自己核對信息。實(shí)驗(yàn)C移除協(xié)調(diào)者讓檢索員們直接通過簡單的規(guī)則通信如“誰找到便宜的就廣播一下”。通過對比A、B、C的結(jié)果你可以量化地分析“專門的驗(yàn)證角色”和“集中協(xié)調(diào)機(jī)制”各自帶來了多少性能提升。你可能會發(fā)現(xiàn)在簡單任務(wù)上C可能效率更高因?yàn)橥ㄐ砰_銷小但在復(fù)雜任務(wù)上A的魯棒性和成功率遙遙領(lǐng)先。瓶頸分析仔細(xì)查看執(zhí)行日志特別是那些失敗或耗時的任務(wù)。常見的瓶頸包括規(guī)劃錯誤協(xié)調(diào)者做出了錯誤的任務(wù)分解導(dǎo)致智能體在做無用功。通信低效智能體間傳遞的消息冗長、模糊或者陷入了循環(huán)討論。環(huán)境理解失敗智能體無法正確解析頁面內(nèi)容點(diǎn)擊了錯誤的按鈕或提取了錯誤的信息。沖突解決僵局在遇到信息矛盾時智能體們無法達(dá)成一致導(dǎo)致任務(wù)卡住。針對這些瓶頸你可以提出改進(jìn)方向例如為協(xié)調(diào)者提供更好的規(guī)劃示例Few-shot Learning設(shè)計(jì)更結(jié)構(gòu)化的通信模板或者增強(qiáng)智能體對網(wǎng)頁元素的語義理解能力。5. 常見挑戰(zhàn)、避坑指南與未來展望在實(shí)際構(gòu)建和運(yùn)行多智能體Web協(xié)作基準(zhǔn)測試時你會遇到不少坑。這里分享一些我總結(jié)的經(jīng)驗(yàn)和需要注意的問題。5.1 典型問題與排查技巧問題1智能體陷入“死循環(huán)”或無效行動。現(xiàn)象智能體反復(fù)執(zhí)行相同或相似的操作無法推進(jìn)任務(wù)。例如在搜索頁面反復(fù)點(diǎn)擊“下一頁”但找不到目標(biāo)。排查首先檢查觀察信息是否充分。也許頁面上的關(guān)鍵篩選條件如“按價(jià)格排序”沒有被正確表征并提供給智能體。其次檢查行動空間是否受限。智能體可能想進(jìn)行一個操作如“使用下拉菜單選擇日期”但你的行動空間只定義了CLICK和TYPE沒有定義SELECT。最后檢查提示詞。智能體的系統(tǒng)提示詞可能沒有明確告訴它在遇到困境時如翻了三頁還沒找到應(yīng)該向上級協(xié)調(diào)者報(bào)告或嘗試其他策略。解決豐富環(huán)境觀察的語義信息擴(kuò)展行動空間以覆蓋更細(xì)粒度的操作在提示詞中加入“超時”或“重試上限”邏輯并明確失敗后的上報(bào)流程。問題2協(xié)作效率低下通信開銷巨大?，F(xiàn)象任務(wù)能完成但智能體間消息往來頻繁大量時間花在“討論”上總token消耗驚人。排查分析消息日志。消息內(nèi)容是否過于冗長是否有很多確認(rèn)性消息“你收到了嗎”“我開始做了”智能體是否在反復(fù)詢問相同的信息解決設(shè)計(jì)簡潔、結(jié)構(gòu)化的消息格式。使用共享狀態(tài)黑板Blackboard智能體將關(guān)鍵信息如“已找到航班CA1234價(jià)格1200元”寫入黑板其他智能體按需讀取避免點(diǎn)對點(diǎn)重復(fù)詢問。為協(xié)調(diào)者設(shè)計(jì)更果斷的決策機(jī)制減少“民主討論”。問題3評估指標(biāo)難以自動化計(jì)算尤其是結(jié)果質(zhì)量。現(xiàn)象任務(wù)成功與否容易判斷例如“是否成功提交訂單”但生成報(bào)告的信息準(zhǔn)確性、完整性很難用規(guī)則自動評分。排查與解決對于這類主觀性較強(qiáng)的評估可以結(jié)合多種方法規(guī)則匹配關(guān)鍵詞提取對于結(jié)構(gòu)化信息航班號、價(jià)格可以編寫規(guī)則從最終輸出中提取并與環(huán)境日志中真實(shí)操作記錄的數(shù)據(jù)進(jìn)行比對。使用強(qiáng)大的LLM作為評判員將任務(wù)要求、智能體最終輸出、以及從環(huán)境日志中提取的“真實(shí)”數(shù)據(jù)作為參考一起提交給一個更高級的LLM如GPT-4讓它按照評分標(biāo)準(zhǔn)如1-5分進(jìn)行評判。這種方法成本較高但靈活性強(qiáng)。人工標(biāo)注抽樣檢查對一定比例的任務(wù)結(jié)果進(jìn)行人工審核并將人工評分作為自動化評分系統(tǒng)的校準(zhǔn)基準(zhǔn)。5.2 對智能體能力邊界的再思考通過構(gòu)建AgentWebBench你會更深刻地認(rèn)識到當(dāng)前AI智能體尤其是基于LLM的智能體的能力邊界。長程規(guī)劃與狀態(tài)跟蹤LLM在短期推理上表現(xiàn)優(yōu)異但維持一個復(fù)雜任務(wù)的長程規(guī)劃并精確跟蹤所有子任務(wù)狀態(tài)仍然是挑戰(zhàn)。智能體容易“遺忘”或“混淆”上下文。對動態(tài)環(huán)境的真正理解即使在高保真模擬中智能體對網(wǎng)頁的“理解”也停留在文本和元素標(biāo)簽層面。它無法像人類一樣通過視覺布局、顏色對比等隱含信息來快速定位重點(diǎn)或理解元素之間的關(guān)系。常識與模糊處理任務(wù)描述中常常包含隱含常識。例如“市中心”的酒店。不同城市對“市中心”的定義不同智能體需要具備這些地理常識或能通過查詢來界定。對于模糊要求如“合適的航班”智能體需要權(quán)衡時間、價(jià)格、航空公司等多個因素這涉及到復(fù)雜的多目標(biāo)決策目前仍很困難。5.3 項(xiàng)目的延伸價(jià)值與個人體會AgentWebBench的價(jià)值遠(yuǎn)不止于給現(xiàn)有的多智能體系統(tǒng)排個名次。它是一個強(qiáng)大的研究工具和開發(fā)指南。對于研究人員它提供了豐富的、可復(fù)現(xiàn)的實(shí)驗(yàn)場景用于測試新的協(xié)作算法、通信協(xié)議或?qū)W習(xí)范式。對于開發(fā)者它像一個“功能測試集”在開發(fā)自己的多智能體應(yīng)用前可以先用AgentWebBench的標(biāo)準(zhǔn)任務(wù)跑一跑快速發(fā)現(xiàn)系統(tǒng)架構(gòu)中的薄弱環(huán)節(jié)。從我個人的實(shí)踐經(jīng)驗(yàn)來看構(gòu)建或使用這樣的基準(zhǔn)測試最大的收獲是迫使你進(jìn)行系統(tǒng)化思考。你會被迫去厘清智能體到底需要感知什么它們之間最小的有效通信單元是什么如何定義“好”的協(xié)作這個過程本身就是對智能體系統(tǒng)設(shè)計(jì)理念的一次深度梳理和提升。它讓你從“能跑通一個例子”的興奮進(jìn)入到“如何穩(wěn)定、高效、可擴(kuò)展地解決一類問題”的嚴(yán)肅工程化思考。未來我期待看到AgentWebBench這類基準(zhǔn)測試能向更多維度演進(jìn)例如加入對多模態(tài)智能體能“看”網(wǎng)頁截圖的評測加入對安全與倫理智能體是否會被誘導(dǎo)點(diǎn)擊惡意鏈接或泄露隱私信息的考量以及設(shè)計(jì)更開放、更具涌現(xiàn)性的任務(wù)看看智能體團(tuán)隊(duì)是否能協(xié)作完成一些從未被明確編程過的、新奇的任務(wù)。這條路才剛剛開始而扎實(shí)的基準(zhǔn)測試正是照亮前路的第一盞燈。