SillyTavern群聊玩法：三张角色卡实现AI角色自动接戏

这次我们来还原一个很实际的玩法：在 SillyTavern（中文社区常叫“AI酒馆”）里搭一个群聊房间，把三个角色卡丢进去，然后我不参与对话，让 AI 角色之间自己接戏、自己推剧情。这个方案是我在 B 站 AI 创造公开赛期间尝试的一个方向，本质并不是写插件，而是把酒馆的群组模式、角色卡和世界书组合成一套“多角色自动演绎”的配置方法。

先说结论，免得看到一半才发现不适合自己：SillyTavern 本身是 Node.js 写的浏览器前端，启动它不需要独立显卡。真正吃显存的是模型后端。你可以继续用 OpenAI 兼容 API，也可以把模型全部放到本地跑。如果走云端 API，本机几乎不占显存；如果走 Ollama、llama.cpp 这类本地推理程序，显存占用取决于模型尺寸、量化等级和上下文长度，不能一概而论。

这篇博文会讲清楚四件事：一是本地怎么启动酒馆并接上模型后端；二是角色卡怎么写，才能让三张卡放进同一个房间后“性格不串味、说话能接上”；三是群聊模式下怎么控制发言顺序和剧情走向；四是稳定性排查、Token 开销和自动化导出思路。适合想用 SillyTavern 做多角色剧情创作、本地角色扮演、对话小说生成，或者想比赛作品做技术复盘的读者。

1. 核心能力速览

从上面的表格能看出来，这次改造的技术重心不在“前端功能开发”，而在“让多个角色在同一条上下文里保持各自人设并互相驱动”。

2. 这个玩法适合谁：场景与边界

2.1 适合的场景

第一个场景是角色扮演测试。你写好一个侦探、一个记者、一个嫌疑人，设定一起案件，然后让三个角色在群聊里分别推理、试探、撒谎。这个玩法比起单角色对话，更能观察模型在不同人格提示词之间的切换能力。

第二个场景是对话小说生成。你不需要手动给每个角色补全下一句，只要把场景、人物关系和“当前冲突”预设好，模型就会按角色卡自动生成对话冲突。酒馆单轮只返回一个角色的发言，这有点像让一个模型演员轮流戴三顶帽子，但上下文是连续的，叙事逻辑能保持一致。

第三个场景是角色关系压力测试。你想知道某个模型能不能稳定区分“毒舌的朋友”和“礼貌的上司”，不需要分别开两个会话，直接把这两个角色放进同一个房间，让一段对话里同时出现两种语气，很快就能判断模型的角色跟随能力。

2.2 不适合的场景

这个玩法不适合需要严格指令执行的场景，比如让 AI 整理表格、生成代码、做结构化输出。群聊模式为了保证叙事流畅，会把大量上下文交给角色卡和场景描述，模型会更倾向用自然语言回答，而不是给你一个工整的 JSON。

另外，如果只是想要“一男一女加一个旁白”的固定轮播对话，酒馆群聊其实属于杀鸡用牛刀。你不一定需要三张完整角色卡，只需要一个预设的 Prompt 模板就能实现。

2.3 内容安全与授权提醒

多角色接戏自由度很高，所以内容边界要提前定好。不要让 AI 生成违法、色情、暴力引导或违背公序良俗的内容。如果你的角色卡使用已有的小说角色、影视角色、画师立绘素材或真人声线，在公开演示、参赛展示、商业发布前，必须确认素材版权和肖像授权。AI 生成的长对话还存在事实错误和观点偏差，不能把模型输出当成可靠信息，更不能把没有经过复核的内容直接用于正式出版物。

3. 本地部署环境准备

3.1 需要准备什么

开始前，先确认你具备以下条件，避免装到一半缺依赖：

3.2 模型后端的选择

这里区分两个概念：酒馆负责组织上下文，真正的文本生成由模型后端完成。

如果你不想折腾显卡，最简单的方式是使用 OpenAI 兼容的 API 服务，在酒馆设置里填 base_url 和 key，之后所有角色对话都会转发到这个服务上。

如果你想本地推理，优先考虑 Ollama。它的安装简单，命令行启动后默认监听 11434 端口。模型的显存占用取决于你拉取的模型大小。常见 7B 量化模型大概需要 6GB 到 8GB 显存量级，但具体要看量化方式、模型架构和上下文窗口长度。建议第一次用最小参数量模型跑通流程，再逐级换更大的模型做质量对比。

4. 一键启动酒馆并配置模型

4.1 下载并运行 SillyTavern

官方项目使用 SillyTavern-Release 仓库分发稳定版本，下载后进入目录执行启动脚本即可。Windows 下通常双击 Start.bat；如果环境更干净，也可以用 Node 手动启动。

# 选择一个工作目录，把货仓代码拉下来 git clone https://github.com/SillyTavern/SillyTavern-Release.git cd SillyTavern-Release # 手动启动，首次运行会自动安装依赖 node server.js

启动成功后，终端会输出监听地址。默认情况下，打开浏览器访问http://localhost:8000就能看到酒馆界面。如果你看到端口被占用，酒馆会发生警告，这时可以通过环境变量调整端口。例如：

# 换到 8010 端口启动 node server.js --port 8010

需要注意，这段命令只是展示调整端口的方式，具体参数名以你下载的版本文档为准。

4.2 配置模型后端

进入页面后，最核心的配置点是顶部的 API 连接区。你需要在酒馆里选择与后端匹配的连接类型，再填写 API 地址、Key 和模型名。以 OpenAI 兼容代理服务为例，通常在 Chat Completion 类型下填入形如http://127.0.0.1:8001/v1的地址，模型名填 API 服务支持的模型 ID。

如果你的后端是 Ollama 这类本地服务，思路也是一样的：先确认本地模型能正常生成，再把地址和模型名配进酒馆。

4.3 用 curl 自检模型后端是否可用

很多角色卡生成失败的问题，其实都卡在模型后端没连通、地址写错、Key 失效或模型名不存在。所以在酒馆界面调参前，我建议先用 curl 验证一次。

# 假设你有一个 OpenAI 兼容的本地接口 curl http://127.0.0.1:8001/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "your-model-name", "messages": [ {"role": "user", "content": "请回复一句话"} ], "max_tokens": 50 }'

如果返回内容和 HTTP 状态都正常，说明模型接口没问题；如果返回 404、401 或模型名不存在，就不要在酒馆里浪费时间，先解决接口层。自检通过后，接着从酒馆左侧选择一个预设或从空白对话开始，发送一条普通消息确认页面本身能正常生成，然后再进入多角色房间。

5. 三个角色互相接戏：角色卡与群聊配置

5.1 角色卡不是简单写几句话

多角色群聊最容易翻车的点，不是“三个角色能不能同时出现”，而是三张卡的语气、目标和说话习惯区别不够大。如果性格描述只写了“一个温柔的人”“一个冷酷的人”，模型很容易在长对话里慢慢把它们拉平，最后变成同一种口吻在说话。

所以角色卡至少要区分四个维度：

这里给一张精简角色卡 JSON 示例。实际酒馆角色卡字段会更复杂，但核心思路相同：

{ "name": "夏洛特", "description": "冷静的女侦探，擅长观察细节。说话简短，喜欢先给结论再解释。", "personality": "冷静、敏锐、略带毒舌", "scenario": "在晚宴谋杀案发生后，与记者陆明和嫌疑人程叙共同留在会客厅。", "first_mes": "走廊残留着雪松味。这不是凶手身上带进来的，就是刚才有人站在窗外。*她看了程叙一眼*", "mes_example": "*她用指节敲了敲桌面* 管家说没有人离开过书房，但地板上的划痕说明有人翻过窗。" }

写群聊角色卡时，特别注意要给“说话对象”留空间。像上面的first_mes已经包含“看了程叙一眼”，这会让模型在下一次生成时有明确的接话线索。

5.2 创建群聊房间并加入三个角色

酒馆的群聊位置在不同版本里叫法可能有差异，但逻辑基本一致：先进入一个群聊/房间，把已经创建好的三张角色卡全部加入进来，然后由用户发第一句场景导入话，或者直接让其中一张角色卡用开场白拉起剧情。

三张卡最好分别建好后再加入房间，不要在房间里临时编辑角色属性。这样方便后续做“同一个角色在不同房间里的对照实验”，也方便出问题时快速定位是哪张角色卡导致其他角色行为漂移。

5.3 让角色之间对话，而不是都对用户说话

很多第一次玩群聊的人会遇到一种情况：三个角色明明在一个房间里，但每次回复都像是在向用户汇报。这个问题的本质是：角色卡和系统预设都没有告诉模型“你旁边还有别人，你应该接别人的话”。

解决办法是，在每一张角色卡的 description 或系统提示区域写明群聊关系。比如侦探卡写“你是受邀请调查案件的侦探，现在房间里坐着记者陆明和嫌疑人程叙”，记者卡写“你想从侦探嘴里套出案件进度，同时怀疑程叙在说谎”，嫌疑犯卡写“你不想被侦探发现你和死者发生过争执”。

这样模型在生成时，目标对象就不是唯一的用户，而是当前上下文里已经出现的其他角色。

5.4 接戏规则可以使用显式格式

如果你的模型对角色关系的理解较弱，可以通过 mes_example 提供一段多角色互相对话的示例。SillyTavern 同样支持用描述性行为代替纯对话，比如角色在做某件事的同时说某句话，后续角色就会对这件事产生反应。

一个比较稳的配置方式是：每张角色卡都包含“行动描述 + 对上一个角色观点的回应 + 为什么这么回应”。这样每一轮都会产生一个可以接续的“钩子”，而不是三个人各说各话。

6. 叙事一致性调教：防止角色串味和失控

6.1 给群聊预设一个清晰的开局

不要一上来就让三个角色泛泛地聊天。没有冲突，没有目标，三张卡很容易进入“互相客套循环”。开局最好是一个需要立刻表态的场景，比如“尸体在书房被发现，三个人同时看到桌上的字条”。

场景越具体，角色接戏的方向就越明确。开局可以放在用户发起的首条消息里，也可以写进世界书，作为全局可随时触发的背景信息。

6.2 用世界书控制剧情要素

世界书（Lorebook）是酒馆里管理长期设定的重要工具。我建议把地点、关键道具、案件时间线一类的信息放在世界书条目里，而不是全部塞进角色卡，否则每条角色卡都塞大量背景信息，会挤占上下文窗口。

比如可以建立一个关键词为“雪松味”的世界书条目，里面写明“雪松味来自书房外花园的雪松树，任何角色闻到后都可能联想到有人从窗户进出”。当群聊里出现这个词时，酒馆会把对应背景注入上下文，让侦探做出更合理的推理。

6.3 发言顺序与“不让某个角色一直抢话”

群聊自由度高，随之而来的问题是某个高活跃角色可能主导对话，而另一个角色一整晚没有台词。这里有两种策略：

一种是手动控制。在群聊界面里，每轮由你决定让哪个角色先发言，导演感更强，适合比赛演示或成品录制。

另一种是依赖酒馆群聊自动生成，让模型自己选谁接话。但这种模式下，要让每个角色描述里都写一句“你正在积极寻找机会发言”，或者反过来写“你不喜欢抢话，只在被点名时才开口”。同样一段话，三个角色因为性格差异会自然形成不同的参与频率。

6.4 观察发送给模型的上下文

当群聊跑偏时，不要只改提示词，先去看酒馆实际发给模型的内容。很多酒馆版本可以通过调试界面查看最终 Prompt，里面包含系统提示词、角色卡、世界书条目、历史对话和作者注释。

多角色群聊的上下文比单角色更乱。如果某个角色的属性在其他角色的对话里被同时提及，模型就可能产生混淆，导致“刑侦能力”从一个角色转移到另一个角色身上。发现这种现象后，最有效的方法是精简世界书命中关键词，并让角色卡里写清“你对案件知道多少”和你一定不知道多少。

7. 从群聊到自动化：日志导出与批量思路

7.1 结果导出与保存

SillyTavern 本身提供了对话导出机制，但我更推荐在关键进度时把完整的群聊记录用 HTML 或 Markdown 方式存档，然后放进独立目录，比如按“日期_场景_参演角色”命名。这样后面如果发现剧情分支走歪了，可以随时回退到某个存档点重新开一局。

7.2 批量多组对话的可执行思路

酒馆原生没有“批量跑一百个开局”的按钮，但完全可以用脚本把模型接口、角色卡拆分到一个可控的流程里，这种做法适合批量测试不同模型或不同人设。

更轻量的做法是：先准备好几组不同开局文本，然后手动切换开局，每局固定跑相同轮数，最后统一导出记录。批量测试的目的是观察角色卡稳定性，而不是让模型快速产出大量同质化对话。如果要用代码批量调用，可以在酒馆之外写一个轻量 runner，把三张角色卡文本和场景文本拼接成消息序列，再请求模型接口：

import requests api_url = "http://127.0.0.1:8001/v1/chat/completions" payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "三人群聊规则：按剧情由合适角色发言。"}, {"role": "user", "content": "开场场景：晚宴结束后，侦探发现死者房门被反锁。"} ], "temperature": 0.8, "max_tokens": 300 } resp = requests.post(api_url, json=payload, timeout=120) print(resp.json())

这里的请求消息只是示意，需要按实际模型的聊天格式和角色卡格式调整。逐轮把模型返回追加到 messages 列表中，就能模拟出最简单的群聊自动回复循环。

7.3 输出需要人工复核

多角色接戏生成的对话文学性可能不错，但它仍然是概率生成的文本。角色说的话可能不符合设定，案件推理也可能有常识错误。如果要把生成结果用于参赛视频、公开博客或作品展示，请务必逐字过一遍，去掉逻辑硬伤，并确认文本中不存在抄袭、侵权或未授权角色素材。

8. 资源占用与性能观察

8.1 酒馆占资源不多，模型端才是大头

从资源占用角度看，SillyTavern 本体很轻。启动后浏览器里主要跑的是前端动画和聊天记录渲染，CPU 占用一般不高。真正的性能瓶颈在模型生成这一步。

如果你使用云端模型 API，本机只需承担网络请求和页面渲染，没有明显显存压力。如果你用本地 Ollama 或 llama.cpp，启动模型后可以通过命令行查看显存和内存占用。

# 观察显卡利用率，Linux/Windows 均可用 NVIDIA-SMI 或任务管理器 nvidia-smi -l 2

显存占用不只看模型大小，上下文长度、并发请求、批处理数量都会影响占用。你应该以实际模型运行时显示的数字为准，不建议照搬别人帖子里的“某个模型固定占多少 GB”作为唯一结论。

8.2 Token 消耗为什么比单角色高很多

群聊模式在每次模型请求时都会携带全局系统提示、所有角色卡摘要、世界书条目、历史消息，以及当前正在讲话角色的完整描述。三个角色共同存在的上下文，意味着大部分历史都会被反复传输给模型。

越长的上下文，首 Token 延迟越高。如果本地显存紧张，长对话还可能触发模型分段生成，导致回复缓慢。因此，群聊适合控制在“短中篇”规模，几百轮的多角色长聊既难维护原创性，也容易让模型忘记早期设定。

8.3 降低显存和 Token 占用的办法

最直接的办法是缩短上下文长度。在酒馆设置里把上下文长度从 8K 降到 4K，往往能明显提高本地小显存场景的生成速度。代价是更早触发“截断”，角色会忘记前面章节的细节。

第二个办法是减少对话参与角色数量。三个角色能接戏，四个角色也还行，五个以上很容易出现某两个人长时间没有戏份。与其用更多角色堆信息量，不如减少人数，把冲突集中到人物关系上。

第三个办法是修改历史消息的数量上限。酒馆可以调整发往模型的上下文压缩策略。对群聊来说，不要把所有历史都原样塞给模型，可以让较早的剧情通过“摘要”或世界书条目储存，而不是作为逐字记录保留到最后一轮。

9. 常见问题与排查方法

新手最容易踩的坑是第一步：没有先验证模型接口，就直接跑到酒馆里调角色卡。实际上，模型接口通不通和群聊能不能生成是两个独立问题。建议把失败排查顺序固定为“接口是否连通 -> 单角色是否正常 -> 多角色房间是否正常 -> 角色语气是否正常”，不要跳级。

10. 最佳实践：多角色群聊的工程化建议

给角色卡做版本管理。每改一次角色性格，就另存一个文件，不要直接在原文件上覆盖。群聊里三张角色卡的调参过程很像联调三个模块：A 的性格一变，B 的应对策略也要跟着改。只在文件上改动后很难回看之前的稳定版本。

给开局做“最小可用集”。保留一套已经验证成功的角色卡和开场设定，作为训练新模型或测试新后端时的基准。不管换模型还是换 API，先跑这套最小可用集，能很快判断是新端不行，还是配置疏忽。

对话流程建议加日志。不管是手动跑还是脚本跑，都要记录每一轮由哪个模型、哪个角色、在什么上下文长度下生成的。这样当你看到精彩的一局时，不是只有一段感动，还能知道它是怎么复现出来的。

涉及真人肖像、声音、真实姓名，或者受版权保护的角色形象时，必须确认授权。不要让 AI 生成可能造成误导或冒犯的内容，也不要在公开场合用没有授权的素材做演示。

如果项目要进入生产环境，比如做成“多角色自动剧情生成器”作为工具给别人使用，要在输入和输出端都增加内容安全过滤，并明确用户需要自行承担素材授权责任。

11. 小结与下一步

回到最初的目标：给 AI 酒馆加群聊，让三个角色真的互相接戏。从实际体验看，SillyTavern 原生群聊机制已经够用，真正的工程量在角色卡和场景控制上。只要三张卡的目标、语气、说话对象有足够差异，并用世界书把关键背景锁定，AI 角色之间确实能形成来回交锋，而不是各讲各话。

最容易踩的坑也是我前面反复提到的：模型后端没自检、角色卡差异不够、上下文被无关角色抢占。任何一个点出问题，都会让“三人接戏”退化成“三个助手在客套”。

建议你先从两个角色的小房间试起，跑通一遍完整的“开局 -> 接戏 -> 剧情推进 -> 导出存档”流程，再扩展成三个角色。这样后续每个新增角色都像给一套正常的接口加并发，你能清楚看到是角色卡的问题，还是模型记忆长度的问题。

下一步如果继续深入，优先级最高的是两件事：让“谁在什么时候接话”从固定轮流变成真正的剧情驱动；以及给角色卡写更丰富的多轮示例，让模型学会在动态环境中保持自己的语言指纹。这两件事直接决定群聊观感是否自然。角色卡记得随时备份，一次调好的配置，值得保存下来反复做对比实验。