为什么 AI 群聊场景比单角色对话更难协调
单角色对话只有一个声音和一条需要跟进的对话线索。而多角色 AI 场景还必须决定接下来由谁发言、每个角色知道什么、正在展示谁的话语，以及共享的情境如何发生变化。为了让群聊场景保持连贯，应将这些视为独立的协调任务：设定发言规则、按角色追踪认知信息、一致地标记每个发言轮次，并明确记录重要的情节变化。
群聊场景包含不止一项对话任务
在一对一的交流中，模型通常可以直接将最新消息视为下一个需要回答的内容。而在群聊场景中，某个角色可能会对用户以外的人说话、回答另一个角色的提问，或者在场景推进时保持沉默。选择一句合理的台词只是任务的一部分；系统还必须选定发言者，并明确是谁在回应谁。
这种区别在多方对话研究中有所体现。一项关于多方目标追踪的研究描述了人们共享目标、相互应答，以及提供有关其他参与者目标的信息——这些互动在双人对话中不会以相同的方式发生。作者还指出，对于他们评估的语言模型而言，该任务依然充满挑战。该发现涉及的是面向任务的对话，但它说明了为什么增加参与者会改变问题的结构，而不仅仅是增加声音的数量。Multi-party Goal Tracking with LLMs
规划场景的一个有效方法是在每个节拍（beat）区分三项决策：刚刚发生了什么、谁有理由作出回应，以及什么样的回应能够推动共同场景的发展。如果一个角色发言仅仅是因为该轮次需要有人填补，结果往往会感觉像在点名。如果允许一个角色主导每个节拍，场景可能会退化为附带额外名字的单角色交流。
发言顺序需要场景可遵循的规则
对于每个创作场景来说，并不存在单一的最佳轮流顺序。固定轮询易于预测，在每个角色都需要有规律的表达机会时很有用。情境选择则感觉更具响应性：当最新的动作或问题给某个角色提供了明确的理由时，该角色才会发言。受约束的序列可以保护特定的结构，例如让一个角色在其他人作出反应之前先提出计划。
多智能体群聊框架明确了这些区别。微软的 AutoGen 文档描述了模型选择发言者、轮流循环（round-robin）轮次以及可定制的选择函数；其选择器可以使用参与者姓名、描述和对话历史记录。该文档还指出了一种默认选项，可防止同一参与者在连续轮次中发言。这些是编排层面的选择，而非故事创作的死板规则，但它们为场景设计提供了实用的菜单。AutoGen Selector Group Chat
对于创作场景，在生成前用自然语言定义一个简单的选择规则。例如：“让被直接提问的人先回答。否则选择其既定目标或当前动作最相关的角色。跳过没有任何有用反应的人。避免让一个人连续发言两次，除非他们正在完成某项动作。”这是一条建议性的设计规则，而非具有量化保证的标准。它的价值在于为系统提供了选择发言者的理由，而不是依赖任意的轮替。
角色知晓的信息必须单独追踪
处于同一场景并不意味着每个角色都应该知道每一件事实。一个角色可能看到了便条，另一个角色可能只听到了部分解释，而第三个角色可能还没到场。如果写作过程仅存储一份未经区分的单一对话历史记录，模型很容易将聊天中某处提到过的事实视为全体角色的共识常识。
在场景摘要旁使用一份简单的知识账本。对于每项重要事实，记录谁知晓它以及他们是如何知晓的。将不确定的信息与已确认的信息区分开来：“米拉怀疑信封是写给乔的”不等于“米拉已经读了信封”。在轮到某人发言之前，对照该账本检查拟定的发言者。如果他们缺少该信息，他们可以询问、观察、猜测或保持不知情；他们不应将其作为自己已知的事情说出来。
关于角色驱动的故事续写研究指出，人设一致性、角色关系和逻辑情节推进是相关的挑战。该研究将角色关系信息添加到故事上下文中，并报告称这比基线模型提高了故事续写的准确性。它并没有为每个 AI 场景中的知识追踪确立通用的唯一方法，但它支持了一个更广泛的设计原则：角色与角色之间的上下文是场景状态的一部分，而不是装饰性的背景传记。Telling Stories through Multi-User Dialogue by Modeling Character Relations
发言者标签是含义的一部分
对话旁的姓名看起来可能像是排版格式，但正确的归属有助于保持对话流畅。一句话的含义会因说话者的不同而改变：主人提出的问题可能是在邀请回答，而访客提出的相同问题可能表示不确定或质疑。如果标签发生漂移，读者就无法准确判断是谁注意到了某件事、作出了承诺，或者谁在回复谁。
一项关于具有发言者感知能力的多方对话分类研究明确指出了这种联系：该研究认为，了解发言者有助于在语境中复原话语的意图，并且随着对话者数量的增加，对互动的建模会变得更加困难。研究人员测试了在局部对话语境中表征发言者行为的方法。这是对话理解领域的研究，而非创意写作评估，但它印证了为什么稳定的发言者标签属于结构性信息。Who Is Speaking? Speaker-Aware Multiparty Dialogue Act Classification
尽可能长时间地将发言者身份保留为结构化数据，然后再将其呈现为可见的标签。每个角色使用一个规范名称，如果可能会引起归属混淆，请勿在昵称、头衔和名字之间随意切换。叙述与对话也应保持区分。诸如 米拉：“我把它放在门边了。” 这样的台词清晰地将话语及其表述的内容归属于米拉；而在拥挤的场景中未标明归属的台词则容易引发歧义。
共享的故事状态需要明确更新
角色可以记住发生过的事情，但场景本身也需要一份关于当前既定事实的简洁记录。在有实质意义的节拍过后，更新相关事实，例如地点、谁在场、哪个物体移动了、作出了什么决定，以及哪些问题仍未解决。将其视为可观察事件的记录账本，而不是对对话的冗长复述。
这一点之所以重要，是因为群聊场景包含对同一序列的多个视角。一个人的说法可能是错误的，另一个人可能会纠正它，而第三个人可能在听到这两者之前就已采取了行动。将结果与说出的台词分开记录，有助于避免将每句断言都变成既成事实。一条有用的记录可能会写道：“钥匙在厨房柜台上；乔把它放在了那里。米拉还没有看到它。”这单次更新就涵盖了共享的世界状态和个人的认知边界。
群聊编排文档描述了在每个轮次之前在参与者之间同步对话历史记录，并广播每个回复，以便其他人可以使用更新后的上下文。这种工程模式为小说创作提供了一个有益的类比：参与者需要访问当前的场景记录，但角色的认知仍需要拥有自己的边界。Microsoft Agent Framework: Group Chat Orchestration
起草前实用的协调梳理
在生成场景之前，写下四条简短的笔记：出场角色及其各自的直接目标；当前共享的情境；针对非人人皆知的事实的知识账本；以及选择下一位发言者的规则。在起草过程中，对照这些笔记检查每个轮次。起草完成后，排查发言者标签错误、无根据的知情、无理由的重复轮次以及从未被记录的场景变化。
例如，假设三个朋友正在选择穿过周末市场的路线。一个人注意到一个手工艺品摊位即将收摊；另一个人正在对比小吃摊的排队情况；第三个人尚未看到任何一个招牌。第一个角色可以提及即将收摊的摊位，第二个角色可以将此与排队情况进行权衡，第三个角色可以询问他们错过了什么。如果第三个人在未被告知且未看到的情况下直接提到了该招牌，知识账本就会暴露出连贯性错误。这只是一个示例场景，并非报告的实验。
关键的区别在于协调：单角色回复主要是延续一条对话，而群聊场景必须同时保持轮次、身份、知识和共享事件的高度一致。理清这些职责，可以更轻松地打造生动的场景，而无需让每个角色在每个轮次都发言，也不会让每个人都拥有相同的信息。