浙大推出讓AI會「導(dǎo)演」的角色扮演框架！四通道消息沉浸式交互

AdaMARP團(tuán)隊 投稿
量子位 | 公眾號 QbitAI

AI能實現(xiàn)真正的沉浸式扮演了。

大語言模型在角色扮演任務(wù)上進(jìn)展迅速，但現(xiàn)有系統(tǒng)往往缺乏沉浸感和適應(yīng)性：

環(huán)境信息未被充分建模，場景與角色也多為靜態(tài)，難以支撐多角色調(diào)度、場景切換、動態(tài)引入新人等復(fù)雜敘事需求。

現(xiàn)在，浙江大學(xué)聯(lián)合騰訊優(yōu)圖實驗室提出AdaMARP（Adaptive Multi-Agent Interaction Framework for General Immersive Role-Playing）——

一種面向通用沉浸式角色扮演的自適應(yīng)多智能體交互框架。

該框架通過四通道消息格式和場景管理器，讓AI不僅會「說」，還會「想」、會「動」、會「感知環(huán)境」，并在復(fù)雜敘事中靈活切換場景、動態(tài)引入新角色。

目前該工作已被ACL 2026接收。

從跟AI聊天到和角色共處

大語言模型在角色扮演任務(wù)上的應(yīng)用正快速普及：

用戶可以設(shè)定任意角色（歷史人物、小說角色、原創(chuàng)人設(shè)），與AI進(jìn)行持續(xù)的敘事互動。

理想狀態(tài)下，AI應(yīng)當(dāng)能夠代入這個角色，在情境中保持人設(shè)一致、對環(huán)境敏感、對他人話語做出貼合關(guān)系的回應(yīng)。

但現(xiàn)實中，大多數(shù)系統(tǒng)更像是會說話的聊天機器人：對話雖流暢，卻缺少情境感和敘事張力。

以探案為例，故事往往在一個固定場景、固定人物之間反復(fù)進(jìn)行，無法四處搜證、無法與不同證人輪番對質(zhì)、無法讓環(huán)境線索真正參與推理，缺乏真正的劇情推進(jìn)和世界變化。

現(xiàn)有方法缺了環(huán)境信號，也缺了“組織者”

研究團(tuán)隊指出，當(dāng)前角色扮演系統(tǒng)主要存在兩類局限。

一、沉浸感不足：環(huán)境被當(dāng)成「背景板」

不少工作只建模角色的臺詞（Speech）；后來有研究加入了動作（Action）或內(nèi)心獨白（Thought），但在敘事中，環(huán)境并非可有可無的裝飾。

它會塑造氛圍、推動因果，連接角色的行動、世界的變化與后續(xù)對話。

例如：案發(fā)現(xiàn)場地毯上的蠟痕、煤氣燈照出的陰影角度、證人住所門口未干的泥漬……

這些環(huán)境信號既能支撐推理（蠟痕指向婚禮蠟燭，泥漬暗示來客方向），也能成為劇情轉(zhuǎn)折的契機（換一個場景，就換一批證人和線索）。

若系統(tǒng)不把環(huán)境當(dāng)作與臺詞、動作同等重要的信號來建模，角色就容易像是在一個空房間里自言自語，探案也就失去了「搜證」的實感。

二、互動結(jié)構(gòu)過于靜態(tài)：缺一個「會調(diào)度的導(dǎo)演」

多數(shù)系統(tǒng)假定：場景不變、人物不變、用戶與某個固定角色一問一答。

但探案恰恰需要四處搜證：從案發(fā)現(xiàn)場到蘇格蘭場，從房東太太的公寓到嫌疑人的宅邸，每個場景都有不同的環(huán)境和證人。

誰來接下一句？是先問管家還是先問馬車夫？何時換場景、何時引入新證人？

現(xiàn)有框架很少系統(tǒng)性地回答這些問題。

沒有這些能力，故事就很難自然地「演下去」，更像是在一個封閉的聊天室里重復(fù)對話，而非一場真正的調(diào)查。

AdaMARP：四通道消息格式+場景管理器

AdaMARP從兩個方向回應(yīng)上述問題。

沉浸式消息格式： Thought–Action–Environment–Speech

AdaMARP 為每一輪交互定義了一種四通道交織的消息格式：

這樣，一個完整的回應(yīng)可以同時包含思考、動作、環(huán)境感知和言語，且順序可靈活交織。

例如，福爾摩斯在訊問證人時：<煤氣燈搖曳，證人下意識地瞥向壁爐上的時鐘> [他在回避具體時間，那段時間他不在場]（用煙斗輕輕敲了敲桌面）案發(fā)當(dāng)晚八點到九點，您究竟在哪里？

環(huán)境線索 → 內(nèi)心推理 → 施壓動作 → 追問話語，四者形成一條清晰的因果鏈，更貼近真實探案的節(jié)奏。

同時，環(huán)境不再只是點綴。

案發(fā)現(xiàn)場的物證擺放會支撐角色的推理鏈條；證人住所的布置（凌亂的書桌、未拆的信件）可以暗示性格與行蹤；場景切換則自然引入新的證人與線索。

環(huán)境既參與氛圍營造，也參與推理與敘事的因果。

自適應(yīng)框架：三智能體+場景管理器的五種動作

AdaMARP將角色扮演建模為三個智能體的協(xié)作：

• Actor模型：扮演所有非用戶角色；
• User模型：代表用戶方（可由 LLM 模擬或真人替代）；
• 場景管理器（Scene Manager）：負(fù)責(zé)高層調(diào)度與控制。

場景管理器通過一組離散動作來驅(qū)動整場「演出」：

• init_scene：初始化場景（如：貝克街 221B，或某起兇案現(xiàn)場）；
• pick_speaker：選擇下一句由誰來說——是福爾摩斯追問、華生補充，還是證人陳述？并給出理由；
• switch_scene：切換場景（從案發(fā)現(xiàn)場到證人公寓，從蘇格蘭場到嫌疑人宅邸）；
• add_role：在敘事中動態(tài)引入新角色（新發(fā)現(xiàn)的證人、突然登門的訪客，含人設(shè)與動機）；
• end：結(jié)束本場互動。

每一步?jīng)Q策都會輸出對應(yīng)的理由，使調(diào)度過程可解釋、可約束。這樣，系統(tǒng)既能決定「誰來接話」，也能決定「何時換場景搜證」「何時引入新證人」，從而支持更復(fù)雜、更開放的多角色探案敘事。

上述設(shè)計在實踐中如何運轉(zhuǎn)？不妨看一段福爾摩斯探案敘事的拆解。

各環(huán)節(jié)均由場景管理器調(diào)度，需要注意的是本案例僅僅用于理解，省略了部分細(xì)節(jié)例如詳細(xì)的角色檔案、角色動機場景管理器的原始輸出等

完整示例：探案敘事中的AdaMARP

角色：福爾摩斯、華生。

初始場景：倫敦東區(qū)某寓所三層，案發(fā)后的深夜。厚重的窗簾半掩，煤氣燈在風(fēng)中搖曳，在墻面上投下晃動的影子。壁爐已熄，余燼旁的地毯上有一小塊凝固的蠟痕，不遠(yuǎn)處散落著幾根燒盡的火柴。福爾摩斯與華生立于現(xiàn)場中央，窗外隱約傳來泰晤士河上的汽笛聲。

場景管理器

• 選擇的動作為：pick_speaker（speaker: 福爾摩斯）
• 理由：偵探應(yīng)先勘察現(xiàn)場并給出初步推理

福爾摩斯：<煤氣燈昏黃，蠟痕在陰影中隱約可見> [燭淚的位置和形狀……婚禮蠟燭，而且是左手持燭]（蹲下身捻起碎屑嗅了嗅，站起身）華生，去查查最近三個月內(nèi)舉辦過婚禮、且家中有人左撇子的家庭。

場景管理器

• 選擇的動作為：pick_speaker（speaker: 華生）
  理由：福爾摩斯已下達(dá)指令，助手應(yīng)領(lǐng)命執(zhí)行

華生：（點點頭）明白（推門而出）<走廊里傳來漸遠(yuǎn)的腳步聲，隨后是馬車駛離的聲響>

場景管理器

• 選擇的動作為：switch_scene
• 理由：華生已前往調(diào)查，需切換至下一個搜證地點——案發(fā)地鄰居的住所
• 新場景：白教堂附近一棟老式公寓，房東太太的住處。狹窄的木樓梯吱呀作響，扶手蒙著一層油膩。二樓的走廊昏暗，燉菜的氣味從盡頭的廚房飄來。門廳狹小，壁爐上擺著一只廉價的瓷鐘，墻角堆著未拆的信件。

場景管理器

• 選擇的動作為：add_role（new_role: 房東太太，案發(fā)現(xiàn)場的鄰居，這棟公寓的房東）
• 理由：作為案發(fā)地鄰居，可能掌握關(guān)鍵證詞，需引入訊問

場景管理器

• 選擇的動作為：pick_speaker（speaker: 福爾摩斯）
• 理由：訊問應(yīng)由偵探主導(dǎo)開場

福爾摩斯：（摘下禮帽，微微頷首）夫人，案發(fā)當(dāng)晚八點到九點，您是否聽見三樓有任何異常聲響？

場景管理器

• 選擇的動作為：pick_speaker（speaker: 房東太太）
• 理由：需聽取證人對時間線的陳述。

房東太太：<下意識地瞥向壁爐上的時鐘>

場景管理器

• 選擇的動作為：pick_speaker（speaker: 福爾摩斯）
• 理由：證人出現(xiàn)回避跡象，應(yīng)繼續(xù)追問施壓

福爾摩斯：[她在回避具體時間]（用煙斗輕輕敲了敲桌面）那段時間，您究竟在哪里？

場景管理器

• 選擇的動作為：pick_speaker（speaker: 房東太太）
• 理由：給證人回答的機會

房東太太：（咬了咬嘴唇，正要開口——）

場景管理器

• 選擇的動作為：add_role（new_role: 雷斯垂德探長）
• 理由：新證人線索出現(xiàn)，探長需匯報調(diào)查進(jìn)展

場景管理器

• 選擇的動作為：pick_speaker（speaker: 雷斯垂德）
• 理由：探長帶來新線索，應(yīng)由其先行說明。

雷斯垂德：福爾摩斯先生，我們發(fā)現(xiàn)了新的證人，馬車夫說他當(dāng)晚載過一名黑衣男子……
……

初始場景、發(fā)言調(diào)度、場景切換、角色引入均由場景管理器驅(qū)動，且每步均以「選擇的動作為：Action_name | 理由：Reason」的形式可解釋。

這種結(jié)構(gòu)化、多通道、多場景、多角色的連貫敘事，恰恰是AdaMARP旨在支撐的探案節(jié)奏。

訓(xùn)練數(shù)據(jù)：從文學(xué)提取+從主題合成

為訓(xùn)練上述能力，研究團(tuán)隊構(gòu)建了兩個數(shù)據(jù)集，分別面向Actor模型和場景管理器。

AdaRPSet：讓角色「會演」

AdaRPSet面向Actor模型，由兩個互補子集構(gòu)成：

AdaRPSet-Extracted（文學(xué)提取）

從Goodreads「最佳書籍」榜單選取81本代表性文學(xué)作品，經(jīng)三階段管道構(gòu)建：

(1) 分塊：按章節(jié)切分并合并為合適長度的文本塊；

(2) LLM提取：識別連貫場景與多角色互動軌跡，將對話直接轉(zhuǎn)化為統(tǒng)一的Thought–Action–Environment–Speech 格式，嚴(yán)格區(qū)分角色動作與環(huán)境信號；

(3) 角色畫像生成：按角色聚合全書證據(jù)，合成七維畫像（身份與外貌、性格與心理、說話風(fēng)格、能力興趣、社會背景、個人經(jīng)歷、人際關(guān)系）。

每條軌跡采用多視角增強：同一場景下，輪流指定不同角色為主角，其余為NPC，從而擴展訓(xùn)練樣本。

提取數(shù)據(jù)天然具有文學(xué)質(zhì)感與人味，適合學(xué)習(xí)格式規(guī)范與基礎(chǔ)演繹能力。

AdaRPSet-Synthesis（主題合成）

文學(xué)提取的軌跡多為單場景、角色固定的互動，對場景切換與動態(tài)引入新角色的覆蓋不足。

研究團(tuán)隊因此構(gòu)建合成數(shù)據(jù)：在20類主題（冒險、探索、探案、解謎、密謀、營救、逃亡、戰(zhàn)斗、浪漫、友誼、競爭、背叛、和解、談判、策略、魔法、末世等）下，由LLM生成情節(jié)級軌跡。

每條軌跡明確包含：初始情境、主控角色與多個輔助角色、多輪對話（統(tǒng)一格式），以及場景管理器的控制消息（如 switch_scene、add_role）。

每條軌跡至少包含一次場景切換和一次角色引入，用以強化模型對動態(tài)敘事的適應(yīng)能力。

合成數(shù)據(jù)與提取數(shù)據(jù)在訓(xùn)練時合并，使Actor模型既能學(xué)格式與人味，又能學(xué)動態(tài)調(diào)度下的演繹。

關(guān)于兩個互補子集對應(yīng)的細(xì)節(jié)信息如下表所示。

其中Plots指的是初始情節(jié)片段（包含初始場景和初始角色）的數(shù)量，Roles指的是不重復(fù)的角色數(shù)量，Convs指的是指的是完整的角色扮演記錄（初始情節(jié)片段和衍生的不同對話軌跡）的數(shù)量，Utterances指的是所有角色扮演記錄中對話的數(shù)量，Avg. Turns 指的是每個角色扮演記錄的平均對話數(shù)量。

AdaSMSet：讓系統(tǒng)「會導(dǎo)」

AdaSMSet面向場景管理器，在AdaRPSet-Synthesis的基礎(chǔ)上構(gòu)建。

合成軌跡已包含init_scene、switch_scene、add_role、end等控制動作，但缺少最核心的發(fā)言者選擇監(jiān)督。

研究團(tuán)隊在每兩段角色發(fā)言之間插入 pick_speaker 動作，由強指令遵循模型為每次選擇生成自然語言理由（reason），并約束理由需具體、上下文相關(guān)，避免套路化表述。

AdaSMSet因而覆蓋場景管理器的全部五類動作，為「何時換場景」「何時加人」「誰來接下一句」及對應(yīng)理由提供端到端監(jiān)督。

由于AdaSMSet源于AdaRPSet-Synthesis，因此對應(yīng)的Plots、Roles和Convs的統(tǒng)計信息與其一致，由于添加了pick_speaker記錄，因此最終的Utterances數(shù)量為496493，Avg.Turns為50.15。

兩者的互補

AdaRPSet與AdaSMSet共同支撐AdaMARP：前者讓角色「會演」（保持人設(shè)、響應(yīng)環(huán)境、推進(jìn)劇情），后者讓系統(tǒng)「會導(dǎo)」（合理切換場景、引入角色、安排發(fā)言順序）。

二者共享統(tǒng)一的角色畫像與消息格式，確保Actor與場景管理器在同一敘事框架下協(xié)同工作。

AdaptiveBench：為什么還要自建評測？

有了訓(xùn)練數(shù)據(jù)和框架，還需要回答一個關(guān)鍵問題：

怎樣評估「沉浸式、可適應(yīng)」的角色扮演是否真的做得好？

現(xiàn)有很多評測更偏向「一句話好不好」或「單輪對話像不像這個人設(shè)」，難以覆蓋AdaMARP所關(guān)心的幾點：

• 整段故事，而不是單句回復(fù)：真實體驗來自整條對話軌跡是否連貫、有張力，而非某一句是否優(yōu)雅。
• 環(huán)境與動作是否被真正用起來：環(huán)境線索有沒有參與推理和敘事，動作是否和內(nèi)心、臺詞呼應(yīng)。
• 多角色與場景切換是否自然：場景管理器有沒有「帶好這場戲」，包括什么時候換場景、什么時候加新角色、誰來接下一句。

為此，研究團(tuán)隊提出了AdaptiveBench：一個面向自適應(yīng)角色扮演的仿真評測框架。

它從AdaRPSet-Synthesis的保留子集中選取劇情種子（20個話題，每個話題5個初始Plots，總共100個評估樣本），在每個種子上同時運行三方角色：

• 用戶模型（可以是真人或LLM Agent）
• 作為「演員」的Actor模型
• 負(fù)責(zé)調(diào)度的場景管理器

在每個種子上，場景管理器連續(xù)發(fā)出若干輪pick_speaker、switch_scene、add_role動作，驅(qū)動Actor與用戶側(cè)完成一整段多輪對話。完整軌跡生成后，再由評估模型從軌跡級別給出多維評分。

具體而言，AdaptiveBench主要從軌跡級別（Trajectory-level）評估模型，評分包含以下維度：

一、針對Actor模型的五大維度：

1. 角色一致性（Character Consistency）：角色內(nèi)心、動作、臺詞是否自洽？說話風(fēng)格、身份背景、核心動機是否在整場戲中保持一致？
2. 環(huán)境基礎(chǔ)（Environmental Grounding）：角色是否對環(huán)境有感知（如記住地毯上的蠟痕），并利用環(huán)境線索做出行動，而不是將環(huán)境當(dāng)成死物？
3. 人際互動（Interpersonal Interaction）：能否聽懂他人的話外音，并根據(jù)人物關(guān)系（如偵探對證人、偵探對助手）做出貼切的互動響應(yīng)？
4. 敘事推進(jìn)（Narrative Progression）：每一次發(fā)言是否提供了新信息、新動作或情緒發(fā)展，推動故事向前走，而不是原地打轉(zhuǎn)？
5. 指令遵循（Instruction Compliance）：是否嚴(yán)格遵守了四通道格式要求，不越俎代庖替其他角色或系統(tǒng)說話？

二、針對場景管理器（Scene Manager）的四大維度：

1. 場景理解（Scene Understanding）：能否正確跟蹤當(dāng)前場景的進(jìn)展，判斷何時該切換到下一個場景（比如搜證結(jié)束，轉(zhuǎn)往證人公寓）？
2. 發(fā)言紀(jì)律（Speaker Discipline）：能否合理安排輪次？是否讓所有人在恰當(dāng)?shù)臅r機說話，不冷落用戶，也不讓NPC連續(xù)霸麥？
3. 角色引入判斷（Role Introduction Judgment）：何時需要引入新角色？引入的時機和理由是否能推動劇情？
4. 整體評價（Overall Assessment）：這三個維度的配合是否流暢，整場「戲」的導(dǎo)演節(jié)奏感好不好？

通過 AdaptiveBench，AdaMARP 不只是「有一個好看的框架設(shè)計」，而是可以在統(tǒng)一的仿真環(huán)境下，對不同模型、不同訓(xùn)練方式的優(yōu)劣進(jìn)行可重復(fù)、可量化的比較。

從敘事邏輯與情境交互能力來看，AdaMARP能夠產(chǎn)出更連貫的內(nèi)心—行為—言語鏈，更好地利用環(huán)境推動敘事（例如探案中的物證與場景線索），并在多角色、多場景的復(fù)雜情境中實現(xiàn)靈活調(diào)度（例如切換場景搜證、與不同證人輪番對質(zhì)）。

這為無論是探案推理、冒險敘事還是其他需要情境與調(diào)度的互動的更沉浸式的AI角色扮演提供了一個新的技術(shù)路徑。

項目主頁：
https://xuzhenhua55.github.io/AdaMARP/#overview