為什麼 AI 群體場景比單一角色對話更難協調
單一角色對話只有一種聲音和一條需要跟進的對話脈絡。多角色的 AI 場景還必須決定下一位發言者是誰、每個角色知道什麼、正在顯示誰的發言，以及共用的情境如何變化。為了讓群體場景保持連貫，應將這些視為獨立的協調工作：設定發言規則、按角色追蹤認知資訊、一致地標記每個對話輪次，並明確記錄重要的情節變化。
群體場景具有不只一項對話任務
在一對一的交流中，模型通常可以將最新訊息視為接下來要回答的內容。在群體場景中，角色可能會向使用者以外的其他人說話、回答另一個角色的問題，或者在場景繼續推進時保持沉默。選擇一句合理的台詞只是任務的一部分；系統還必須選擇發言者，並維持誰在回應誰的關係。
這種差異出現在多方對話的研究中。一項關於多方目標追蹤的研究描述了人們分享目標、互相回答，並提供有關另一位參與者目標的資訊——這些互動在雙方對話中不會以相同的方式發生。作者還指出，這項任務對他們評估的語言模型來說仍然具有挑戰性。該研究結果關注的是任務導向的對話，但它說明了為什麼增加參與者改變的是問題的結構，而不僅僅是聲音的數量。Multi-party Goal Tracking with LLMs
規劃場景的一個實用方法是在每個節奏點區分三個決策：剛剛發生了什麼、誰有理由回應，以及什麼樣的回應能推動共用場景向前發展。如果角色發言只是因為輪次需要填補，結果往往感覺像在點名。如果允許一個角色主導每個節奏點，場景可能會退化為附帶額外名稱的單一角色交流。
發言順序需要場景可以遵循的規則
對於每個創意場景來說，並不存在單一的最佳輪流順序。固定輪替很容易預測，且在每個角色都需要定期獲得貢獻機會時非常有用。情境式選擇可以讓人感覺更有呼應性：當最新的行動或問題給了角色明確的理由時，該角色就會發言。受限制的序列可以保護特定結構，例如讓一個角色先提出計劃，然後其他人再做出反應。
多代理人群聊框架明確指出了這些區別。微軟的 AutoGen 文件描述了模型選擇發言者、輪流發言（round-robin）以及可自訂的選擇函數；其選擇器可以使用參與者姓名、描述和對話歷史記錄。該文件還提到了一個預設選項，可防止同一參與者在連續的輪次中發言。這些是編排上的選擇，而不是敘事規則，但它們為場景設計提供了實用的選項清單。AutoGen Selector Group Chat
對於創意場景，在生成之前用日常語言定義一個簡短的選擇規則。例如：「讓被直接搭話的人先回答。否則選擇其既定目標或當前行動最相關的角色。跳過任何沒有實質反應的人。避免讓一個人連續發言兩次，除非他們正在完成一項行動。」這是一個建議的設計規則，而不是經過驗證的保證。它的價值在於為系統提供選擇發言者的理由，而不是依賴隨機輪替。
角色的認知資訊必須分開追蹤
身處同一個場景並不意味著每個角色都應該知道每件事實。一個角色可能看到了一張便條，另一個角色可能只聽到了部分的解釋，而第三個角色可能還沒有到達。如果寫作過程只儲存單一、未經區分的對話歷史，模型很容易將聊天中某處提到的一件事實視為全體角色的共同常識。
在場景摘要旁使用簡單的知識帳本。對於每個重要事實，記錄誰知道它以及他們是如何獲知的。將不確定的資訊與已確認的資訊區分開來：「Mira 懷疑信封是寄給 Jo 的」並不等同於「Mira 已經讀過信封」。在輪次開始前，根據該帳本檢查擬定的發言者。如果他們缺乏該資訊，他們可以詢問、觀察、猜測或保持不知情；他們不應將其作為自己已知的事情來說明。
針對角色驅動故事延續的研究指出，角色設定一致性、角色關係以及情節的邏輯推進是相關的挑戰。該研究將角色關係資訊添加到故事脈絡中，並報告稱這相較於其基準提高了故事延續的準確性。它並沒有為追蹤每個 AI 場景中的認知資訊建立單一的通用方法，但它支持了一個更廣泛的設計原則：角色之間的脈絡是場景狀態的一部分，而不是裝飾性的背景介紹。Telling Stories through Multi-User Dialogue by Modeling Character Relations
發言者標籤是語意的一部分
對話旁邊的姓名可能看起來只是排版格式，但正確的歸屬有助於維持對話的流暢度。一句台詞會根據說話者是誰而改變含義：主持人的提問可能是在邀請回答，而訪客提出同樣的問題可能表示不確定或質疑。如果標籤發生偏差，讀者就無法可靠地分辨出是誰注意到了某個事件、做出了承諾，或者是誰在回應誰。
一項關於具備發言者感知能力的多方對話分類研究明確指出了這種連結：它認為知道是誰在說話有助於在情境中還原語句的意圖，而且隨著對話人數的增加，對互動進行建模變得更加困難。研究人員測試了在局部對話脈絡中表徵發言者行為的方法。這是對話理解的研究，而不是創意寫作的評估，但它強化了為什麼穩定的發言者標籤屬於結構性資訊。Who Is Speaking? Speaker-Aware Multiparty Dialogue Act Classification
盡可能長久地將發言者身份保留為結構化資料，然後將其呈現為可見的標籤。每個角色使用一個規範名稱，如果可能導致歸屬混淆，請不要隨意在暱稱、稱謂和名字之間切換。敘述部分也要與對話保持區隔。像 Mira：「我把它留在了門邊。」這樣的句子清楚地將發言及其主張歸於 Mira；在擁擠的場景中插入未標註歸屬的台詞會引發歧義。
共用的故事狀態需要明確更新
角色可以記住發生了什麼，但場景也需要一份關於當前事實的精簡記錄。在一個有意義的節奏點之後，更新諸如位置、在場人員、移動了什麼物體、做出了什麼決定以及什麼問題仍未解決等事實。將其視為可觀察事件的帳本，而不是對對話的冗長複述。
這很重要，因為群體場景包含了對同一序列的多種視角。一個人的主張可能是錯誤的，另一個人可能會糾正它，而第三個人可能在聽到任何一方的說法之前就採取了行動。將結果與口頭台詞分開記錄，有助於避免將每一句陳述都變成權威事實。一條有用的記錄可能會寫道：「鑰匙在廚房櫃檯上；Jo 把它放在那裡。Mira 還沒看到它。」這單一條更新涵蓋了共用的世界狀態和個人的認知邊界。
群聊編排文件描述了在每個輪次之前跨參與者同步對話歷史記錄，並廣播每個回覆，以便其他人可以使用更新後的情境。這種工程模式為小說創作提供了一個有益的類比：參與者需要存取當前的場景記錄，但角色的認知資訊仍然需要有自己的界限。Microsoft Agent Framework: Group Chat Orchestration
起草前實用的協調檢查
在生成場景之前，寫下四個簡短的備忘：登場角色及每個人當前的目標；當前共用的情境；針對並非每個人都知道的事實建立的知識帳本；以及選擇下一位發言者的規則。在起草過程中，對照這些備忘檢查每個輪次。起草完成後，仔細檢查是否有發言者標籤錯誤、缺乏根據的認知、無故重複的輪次，以及從未記錄的場景變化。
例如，假設三個朋友正在選擇穿過週末市集的路線。一個人注意到一家手工藝品攤位即將打烊；另一個人正在比較美食攤位的排隊人潮；第三個人還沒有看到任何一個告示。第一個角色可以提到快打烊的攤位，第二個角色可以將其與排隊情況進行權衡，第三個角色可以詢問他們錯過了什麼。如果第三個人在沒有被告知或看見的情況下立即提到該告示，知識帳本就會揭示這個連貫性錯誤。這是一個用於說明的場景，而非報告的實驗。
關鍵的區別在於協調：單一角色的回覆主要是延續單一對話，而群體場景必須同時保持輪次、身分、認知資訊和共用事件的一致。分開處理這些職責，可以更輕鬆地創造生動的場景，而無需讓每個角色在每個輪次都發言，或讓每個人都掌握相同的資訊。