這項由上海交通大學多智能體治理與智能團隊（MAGIC實驗室）聯合浙江大學、伊利諾伊大學厄巴納-香檳分校、牛津大學以及上海人工智慧實驗室共同完成的研究，發表於2026年第43屆國際機器學習大會（ICML 2026），論文編號為arXiv:2606.02470。有興趣深入了解的讀者可通過該編號查詢完整論文。
你有沒有想過，讓AI幫你管理日常的飛書日曆、給小紅書發帖、在Slack里給同事發消息，聽起來應該不難吧？畢竟這些AI已經能寫詩、編程、解數學題了，處理這點"小事"應該手到擒來。然而這項研究給出了一個讓人意外的答案：即便是目前全球最頂尖的AI模型，在面對這類"個人賬號管理"任務時，準確率普遍不超過50%，而且相當一部分任務幾乎完全失敗。
這背後究竟發生了什麼？研究團隊構建了一套名為MCP-Persona的測試平台，專門用來檢驗AI助手在真實個人應用場景中的實際表現。這不是那種讓AI在網上搜索資訊的簡單測驗，而是模擬真實的"你把自己的賬號交給AI管理"的場景——AI需要在你的飛書里創建會議，在你的小紅書里發內容，在你的Slack頻道里@同事，同時還得弄清楚誰是誰、誰的ID是什麼、哪個日曆是主日曆。研究結果清晰地揭示了當前AI助手在個性化工具使用上的真實短板，也為未來的改進指明了方向。
一、一個被忽視的關鍵問題：AI在"個人賬號"場景里為何如此吃力
要理解這項研究解決的是什麼問題，可以先想像這樣一個場景：你雇了一個剛入職的助理，第一天就讓他幫你安排飛書會議、通知群里的同事、更新Notion筆記本里的項目計劃。這個助理智商很高，能記住複雜的會議議程，但他不知道你飛書里哪個日曆是主日曆，不知道"小李"在飛書里的用戶ID是什麼，也不知道你的小紅書賬號發帖時用的是哪個標籤風格。結果呢？他可能會把會議建在錯誤的日曆上，把消息發給錯誤的人，或者乾脆因為找不到必要的資訊而卡住不動。
這正是當前AI助手面臨的困境。研究團隊注意到，目前學術界對AI工具使用能力的評測，基本都集中在"通用資訊查詢"這類任務上，比如讓AI搜索天氣、查詢股票、翻譯文字。這類任務有個共同特點：工具是公開的、無需賬號的、與用戶個人資訊無關的。然而現實生活中，人們最希望AI幫忙處理的，恰恰是那些與個人賬號緊密相關的任務——管理郵件、發社交媒體、協調團隊日程。這類任務有三個核心難點。
第一個難點是"賬號綁定"，這些工具必須登錄特定賬號才能使用，而每個賬號里的數據結構、權限設置、實體關係（比如某個群里有哪些成員）都完全不同，沒有統一的模板可循。第二個難點是"隱私壁壘"，真實的個人數據無法公開共享用於研究，這讓構建一個公開可復現的測試平台變得極為困難。第三個難點是"環境複雜性"，這些應用的狀態是動態變化的，AI執行的每一個操作都可能改變環境狀態，後續操作必須依賴前面操作的結果，任何一步出錯都會影響整個鏈條。
正是這三重難點疊加，導致了一個令人尷尬的研究空白：學術界幾乎沒有任何一個像樣的評測基準專門針對"個人賬號管理類"AI任務，儘管這類任務在現實中的需求量巨大。MCP-Persona就是為了填補這個空白而誕生的。
二、搭建一個"假賬號真考驗"的測試世界
研究團隊面臨的核心挑戰是：如何在不使用真實用戶數據的前提下，創建一個足夠逼真的測試環境來考察AI的真實能力？他們的解決方案是構建一套精密的模擬系統，整個系統由三個相互配合的部分構成，就像搭建一個精密劇本演出所需的舞台、演員和劇情一樣。
第一部分叫做"工具模擬器"（Tool-Traverse），負責創建虛擬版本的真實應用程式工具。研究團隊首先收集了12個真實的個人應用MCP
伺服器，涵蓋社交媒體（小紅書、Reddit、Instagram）、企業協作平台（飛書Lark、Slack、企業微信WeCom）、內容管理工具（Notion、Obsidian）以及電子郵件服務，此外還整合了12個通用資訊查詢伺服器（如高德地圖、百度地圖、醫療資訊查詢等），共計24個伺服器。
要模擬這些工具，團隊採取了一個"先探索、再復刻"的策略。他們首先手動部署真實的應用環境和測試賬號，由人工標註員構造一批"種子函數調用"——也就是示例操作指令，比如"獲取某個飛書日曆下的所有事件"。接著引入了一種受"自我指令"方法啟發的技術（Self-FC），讓AI模型自動生成更多樣化的操作指令，既包括正常成功的指令，也包括各種會失敗的錯誤指令，比如類型錯誤、缺少必填欄位、參數超出範圍、參數之間邏輯矛盾等四類典型錯誤。
收集到大量真實操作及其對應響應結果後，團隊讓AI模型分析這些"行為軌跡"，自動生成Python代碼來模擬每個工具的處理邏輯。這段生成的代碼既能正確處理合法請求，也能精確復現各種錯誤情況下的報錯資訊。驗證結果表明，這套模擬器與真實工具的行為一致率高達94%，而僅僅依靠閱讀文檔來猜測工具行為的對照方法，一致率只有58%。換句話說，光看說明書遠不夠，真正"把工具用一遍"才能理解它的全部脾氣。
第二部分叫做"情境樹"（Context-Tree），負責創建每個虛擬用戶的個人數據檔案。研究團隊為每個應用程式定義了一套樹狀的數據結構，清晰地描述用戶數據的層級關係。以飛書為例，結構是"用戶→日曆→日程事件"；以小紅書為例，結構是"用戶→帖子→評論"；以Slack為例，結構是"用戶→頻道→消息"。
填充這棵樹的方式頗為講究。對於需要隨機ID的欄位，系統會按照真實格式自動生成；對於地名、城市等有限選項的欄位，從預設列表中抽樣；對於自由文本欄位，由AI模型依據上下文自由生成；而對於需要體現真實感的內容性欄位（比如小紅書帖子的正文），團隊直接採用了經過脫敏處理的真實網路內容。敏感欄位如電話號碼則全部替換為虛假數據以保護隱私。這棵情境樹不是靜態的，AI助手執行的每個創建、修改、刪除操作都會實時更新樹的內容，從而真實模擬多輪交互中數據的變化狀態。
第三部分叫做"任務生成器"（Persona-Gen），負責創作真實可信的測試任務。這是整個系統最考驗人工參與的環節。研究團隊首先通過拓撲採樣方法，從工具之間的依賴關係圖中篩選出合理的工具調用鏈，確保每條鏈滿足五個條件：工具之間存在真實的邏輯依賴、鏈條中至少包含一個個人賬號工具、不同鏈條之間不重複、上下游工具的輸入輸出能夠銜接、整體場景符合現實使用邏輯。
基於這些工具鏈，系統自動生成"原型指令"，再將情境樹中的具體數據值填入，得到具體化的任務描述。接下來是最關鍵的"模糊化"處理：刻意刪去真實用戶在日常對話中不會說出口的參數細節，比如用戶ID、日曆ID這類技術性標識符。一個真實用戶會說"幫我給我的上司宋柯發個飛書消息"，而不會說"幫我調用im_v1_message_create接口，向user_id為o9k5jtwo的用戶發送消息"。這種"模糊化"處理模擬了現實中指令的自然性和不完整性，正是AI需要應對的真實挑戰。
最終，所有自動生成的任務都經過人工標註員的逐一審核、修改和打磨，確保每個任務在邏輯上完全自洽，在難度上足夠有挑戰性，在表達上真實反映用戶的日常語言習慣。經過這道嚴格的人工關卡，共產生173個高質量測試任務，平均每個任務需要調用多個工具，並包含若干需要從環境中自主發現的隱性資訊。
三、讓頂尖AI一一上場接受考驗
測試平台就位後，研究團隊邀請了超過十款當今最頂尖的AI模型來參加這場考核，陣容相當豪華。商業閉源模型方面，GPT-5、Claude-Sonnet-4.5、Claude-Opus-4.1、o4-mini、o3、GPT-4o、Grok-4、Gemini-3-Pro、Gemini-2.5-Pro悉數登場。開源模型方面，Qwen3-Max-Latest、Qwen3-235B-A22B、DeepSeek-V3、Qwen3-Coder也一同參與。每款模型都以相同的任務和工具集合為輸入，最多允許進行20輪工具調用來完成任務。
評分體系分三個維度。第一個維度是"檢查點準確率"，將每個任務分解成若干個子目標檢查點，由另一個AI模型（GPT-4o）擔任裁判，對每個檢查點獨立評分，取平均值作為任務得分。第二個維度是"成功率"，衡量模型得分超過0.8的任務比例，可以理解為"基本完成任務"的比率。第三個維度是"執行準確率"，直接檢查模型對資料庫的實際操作結果——創建了什麼、修改了什麼、刪除了什麼——是否符合預期，這是最直接、最客觀的評判標準。
結果令人警醒。表現最好的Claude-Sonnet-4.5，檢查點準確率是38.66%，GPT-5以36.99%緊隨其後。換句話說，即便是全球最頂尖的AI模型，平均而言也只能正確完成任務中不到四成的目標步驟。"成功率"這個指標更慘，Claude-Sonnet-4.5的成功率是10.40%，意味著只有大約十分之一的任務能被完整地基本完成。沒有任何一個模型的準確率超過50%。
從任務類型看，電子郵件任務是模型表現相對最好的一類，因為郵件的操作邏輯相對簡單，依賴鏈條也較短。社交媒體和企業協作平台的任務則更具挑戰性，因為涉及跨用戶的交互和複雜的實體關係識別。內容管理類工具（Notion、Obsidian）的表現最差，模型在面對長篇文檔的導航和編輯時尤為吃力。
跨應用任務（Cross-Server Tasks）的難度進一步升級：需要同時操作飛書和小紅書的任務，或者需要將高德地圖的路線資訊寫入Obsidian筆記再通知Slack頻道的複合任務，對所有模型都是嚴峻考驗。其中"雜燴"場景（任意組合多個應用的任務）是最難的一類，幾乎所有模型在這裡都跌入低谷。
四、AI到底在哪裡犯錯了
通過分析大量失敗案例，研究團隊總結出三種反覆出現的典型失敗模式，每種模式都揭示了AI在個性化工具使用上的特定短板。
第一種失敗模式叫"淺嘗輒止，不深挖環境"。許多任務中，用戶的指令並不會把所有必要資訊說清楚，AI需要主動去探索環境中已有的數據來補全這些資訊。但實驗中大量的弱模型選擇了"就近解決"的策略——根據表面指令生成一個看起來合理但實際上錯誤的操作，然後就此收手，根本不去驗證缺失的資訊是否可以從環境中找到。
一個典型例子是：任務要求"給我的上司宋柯發一條飛書消息，解釋我的請假原因"，同時環境數據中儲存著宋柯的飛書用戶ID（o9k5jtwo）。弱模型的做法是：繞過飛書，直接發了一條企業微信消息，收件人還是憑空捏造的——任務表面上"完成"了，實際上平台錯了、收件人也錯了，徹底失敗。正確的做法應該是：先調用工具查詢飛書的聯繫人列表，找到宋柯對應的ID，再調用飛書消息發送接口。
第二種失敗模式叫"跳過隱含的前置步驟"。飛書的許多操作需要先用手機號查找用戶的平台內部ID，再用這個ID來執行具體操作。正確的工作流程是兩步：先調用user_batchGetId工具把手機號轉成用戶ID，再把這個ID傳給calendarEvent_create工具來創建日程並指定主持人。但許多模型會跳過第一步，直接把手機號當成用戶ID填進去，或者乾脆偽造一個ID，結果要麼報錯，要麼在沒有錯誤提示的情況下靜默失敗——最糟糕的情況，因為沒有報錯，模型甚至不知道自己已經失敗了。
第三種失敗模式叫"上下文越長越迷糊"。情境樹設計確保了AI在與各個工具交互時，上下文中會積累越來越多的資訊。某些工具（比如本地文檔閱讀器）返回的內容本身就相當冗長，進一步撐大了整個對話窗口。隨著輪次推進，模型的注意力開始分散，越來越難以準確回憶早期對話中的關鍵資訊和約束條件，最終連一些本應簡單的步驟也開始出錯。這揭示了一個當前大語言模型普遍存在的弱點：在超長對話中維持高度精準的前後一致性，依然是未被很好解決的難題。
五、給AI裝上"專屬使用手冊"有沒有用
除了基礎評測，研究團隊還做了幾組有趣的對比實驗，探究不同條件下模型表現是否會有顯著變化。
其中一組實驗專門研究"技能文檔"的效果。在現實的AI助手生態中，用戶可以給AI配備針對特定應用的操作手冊，告訴它這個應用有哪些工具、各個參數是什麼含義、典型的操作流程是什麼。研究團隊測試了三種情況：不提供任何手冊、提供從社區平台ClawHub下載的最流行公共技能文檔、以及提供由研究人員手動精心編寫的專屬指南。
結論是：有手冊比沒手冊好，精心編寫的手冊比隨意下載的公共手冊更有效。以GPT-5在飛書任務上的表現為例，沒有手冊時檢查點準確率是37.5%，用公共手冊是42.5%，用精心編寫的手冊則達到45%。但即便如此，這個提升也相當有限，距離"令人滿意"還差得很遠。研究團隊分析指出，公共平台上的技能文檔質量參差不齊，有些內容已經過時，描述的接口參數不再與當前版本匹配，反而可能誤導模型。
另一組實驗研究"工具數量"對表現的影響。給模型提供整個平台的140個工具，還是只給出當前任務實際需要用到的少量工具？結果顯示，工具越少，模型表現反而越好，尤其是在需要處理更長上下文的任務中這種趨勢更明顯。這說明工具過多會對模型造成認知負擔，在大量不相關工具中找到正確工具本身就是一項挑戰。
還有一組實驗研究"干擾資訊"的影響。在提供給模型的上下文中額外加入五段與任務無關的文欄位落（來自維基百科描述等文本庫），結果大多數模型的表現都有一定程度的下滑。這表明模型在資訊篩選能力上存在明顯短板，容易被無關資訊干擾判斷。
六、評判結果可靠嗎，人類和AI裁判有多大分歧
一項評測研究還需要回答一個元問題：評判標準本身可靠嗎？研究團隊請人類專家對所有173個任務的970個檢查點結果進行了獨立評判，並與AI裁判（GPT-4o）的評分進行對比分析。
結果顯示，人類與AI裁判的整體一致率高達91.55%。分任務類別看，長文檔任務（Lark Long、Obsidian Long）的一致率略低於短任務，電子郵件任務的一致率相對較低（13.73%的分歧率）。不一致的情況主要來自兩個原因：其一，AI裁判在涉及複雜邏輯或細微語境的判斷上偶爾力不從心，這屬於模型能力本身的局限；其二，AI裁判有時會因為模型使用了不同於參考答案的工具（但最終結果正確）而過於嚴格地扣分。總體而言，這套評測體系的可靠性得到了初步驗證，但研究團隊也誠實地指出了其存在的局限性，以供後續研究改進參考。
在效率與成本分析上，研究團隊也給出了有價值的發現。不同模型在完成同等難度任務時，消耗的token數量（可理解為"思考量"）和產生的調用成本差異懸殊。GPT-5在效率上表現突出，平均每個任務花費約0.09美元，檢查點準確率達到36.99%，性價比在所有測試模型中最為出色。研究結論是：單純堆砌計算資源並不必然帶來更好的結果，在AI工具選型時，準確率與成本的綜合權衡比單純追求"燒最多錢的模型"更為重要。
---
說到底，這項研究揭示的不僅是技術層面的能力差距，更是當前AI發展階段與用戶真實期望之間的鴻溝。人們期待AI能夠真正融入個人數字生活，幫忙管理那些散落在飛書、小紅書、Slack、Notion中的日常事務，但現實是，即便最強大的模型，在面對"你把賬號交給我、我幫你打理"這種場景時，仍然會頻繁地找不到正確的人、用錯平台、遺漏關鍵步驟。
這不是對AI能力的否定，而是對"還差在哪裡"的精準定位。MCP-Persona提供的是一個可復現、保護隱私、覆蓋多類真實應用的標準化測試環境，讓研究者能夠清楚地看到不同模型的具體短板，並針對性地加以改進。下一步，如何讓AI學會主動探索環境、補全用戶遺漏的細節、在多工具協作中保持長程一致性，將是這一領域最值得攻克的方向。
對這項研究感興趣的讀者，可以通過arXiv編號2606.02470查閱完整論文，代碼和數據集也已在GitHub上公開，地址可通過論文獲取。
---
Q&A
Q1：MCP-Persona測試平台是如何在不使用真實用戶數據的情況下模擬真實賬號環境的？
A：MCP-Persona通過三套系統協同工作。工具模擬器方面，研究團隊實際運行了真實應用的API，收集大量真實操作記錄，再讓AI生成Python代碼來復刻工具邏輯，準確率達到94%。情境樹方面，團隊按照真實應用的數據結構生成虛擬用戶數據，其中文本內容部分來自脫敏的真實網路內容，敏感欄位全部替換為虛假數據。這兩套機制結合，既保證了環境的真實感，又完全避免了真實隱私數據的使用。
Q2：飛書、小紅書這類中國應用在AI助手評測中表現如何？
A：在MCP-Persona的評測結果中，飛書（Lark）任務和小紅書（Rednote）任務都屬於難度較高的類別。飛書任務的主要挑戰在於需要先通過手機號查詢用戶的平台內部ID才能執行操作，很多模型會跳過這個步驟直接失敗。小紅書任務難在內容操作涉及複雜的賬號狀態判斷。表現最好的模型Claude-Sonnet-4.5在飛書任務上的準確率約為40%，在小紅書任務上約為42%，整體仍處於較低水平。
Q3：給AI配備專屬使用手冊能明顯提升它使用飛書或小紅書的能力嗎？
A：有效果，但提升幅度有限。以GPT-5在飛書任務上的測試為例，不提供手冊時準確率約37.5%，使用社區公開手冊提升到約42.5%，使用研究團隊精心編寫的手冊則達到約45%。提升存在但並不顯著，原因在於公開平台上的手冊質量參差不齊，部分內容已過時，甚至會誤導模型。研究結論是，高質量、與任務高度對齊的專屬操作指南比隨意下載的公共資源更有價值。
