这次我们来还原一个很实际的玩法在 SillyTavern中文社区常叫“AI酒馆”里搭一个群聊房间把三个角色卡丢进去然后我不参与对话让 AI 角色之间自己接戏、自己推剧情。这个方案是我在 B 站 AI 创造公开赛期间尝试的一个方向本质并不是写插件而是把酒馆的群组模式、角色卡和世界书组合成一套“多角色自动演绎”的配置方法。先说结论免得看到一半才发现不适合自己SillyTavern 本身是 Node.js 写的浏览器前端启动它不需要独立显卡。真正吃显存的是模型后端。你可以继续用 OpenAI 兼容 API也可以把模型全部放到本地跑。如果走云端 API本机几乎不占显存如果走 Ollama、llama.cpp 这类本地推理程序显存占用取决于模型尺寸、量化等级和上下文长度不能一概而论。这篇博文会讲清楚四件事一是本地怎么启动酒馆并接上模型后端二是角色卡怎么写才能让三张卡放进同一个房间后“性格不串味、说话能接上”三是群聊模式下怎么控制发言顺序和剧情走向四是稳定性排查、Token 开销和自动化导出思路。适合想用 SillyTavern 做多角色剧情创作、本地角色扮演、对话小说生成或者想比赛作品做技术复盘的读者。1. 核心能力速览能力项说明项目类型AI 角色扮演前端 / 多角色群聊叙事容器基础项目SillyTavernAI 酒馆浏览器访问主要功能多角色卡管理、群聊房间、角色互相接戏、世界书、作者注释、API 接入本机显卡要求酒馆本体不需要 GPU模型端可选云端 API 或本地 Ollama/llama.cpp显存占用取决于模型后端与上下文长度酒馆前端本身占用很低支持平台Windows / Linux / macOS只要有可用的 Node.js启动方式node server.js或官方 Start 脚本启动后浏览器开 8000 端口是否支持 API模型端支持 OpenAI 兼容 API可对接云端或本地推理服务是否支持批量任务原生没有“群聊批量生成”按钮可通过脚本把场景/轮次参数化跑批量适合场景多角色剧情推演、对话小说生成、AI 角色扮演、角色关系测试从上面的表格能看出来这次改造的技术重心不在“前端功能开发”而在“让多个角色在同一条上下文里保持各自人设并互相驱动”。2. 这个玩法适合谁场景与边界2.1 适合的场景第一个场景是角色扮演测试。你写好一个侦探、一个记者、一个嫌疑人设定一起案件然后让三个角色在群聊里分别推理、试探、撒谎。这个玩法比起单角色对话更能观察模型在不同人格提示词之间的切换能力。第二个场景是对话小说生成。你不需要手动给每个角色补全下一句只要把场景、人物关系和“当前冲突”预设好模型就会按角色卡自动生成对话冲突。酒馆单轮只返回一个角色的发言这有点像让一个模型演员轮流戴三顶帽子但上下文是连续的叙事逻辑能保持一致。第三个场景是角色关系压力测试。你想知道某个模型能不能稳定区分“毒舌的朋友”和“礼貌的上司”不需要分别开两个会话直接把这两个角色放进同一个房间让一段对话里同时出现两种语气很快就能判断模型的角色跟随能力。2.2 不适合的场景这个玩法不适合需要严格指令执行的场景比如让 AI 整理表格、生成代码、做结构化输出。群聊模式为了保证叙事流畅会把大量上下文交给角色卡和场景描述模型会更倾向用自然语言回答而不是给你一个工整的 JSON。另外如果只是想要“一男一女加一个旁白”的固定轮播对话酒馆群聊其实属于杀鸡用牛刀。你不一定需要三张完整角色卡只需要一个预设的 Prompt 模板就能实现。2.3 内容安全与授权提醒多角色接戏自由度很高所以内容边界要提前定好。不要让 AI 生成违法、色情、暴力引导或违背公序良俗的内容。如果你的角色卡使用已有的小说角色、影视角色、画师立绘素材或真人声线在公开演示、参赛展示、商业发布前必须确认素材版权和肖像授权。AI 生成的长对话还存在事实错误和观点偏差不能把模型输出当成可靠信息更不能把没有经过复核的内容直接用于正式出版物。3. 本地部署环境准备3.1 需要准备什么开始前先确认你具备以下条件避免装到一半缺依赖项目要求Node.js需要能运行 SillyTavern 的新版本 LTS具体版本以官方 Release 说明为准浏览器Chrome / Edge 均可酒馆是纯前端页面模型后端OpenAI 兼容 API 服务地址或本地 Ollama / llama.cpp 推理进程磁盘空间酒馆本体很小约几百 MB 级别本地模型按参数规模和量化类型另算网络打开模型服务端口以及首次下载依赖时的网络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, jsonpayload, timeout120) 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. 常见问题与排查方法问题现象可能原因排查方式解决方案页面打不开端口被占用或服务未启动查看终端日志、检查 8000 端口换端口启动或重启 Node 服务模型一直不回复API 地址、Key、模型名错误先用 curl 自检模型接口修正模型后端配置三个角色都像在跟用户汇报角色卡没有写清房间里还有其他角色查看最终 Prompt 中的角色关系在角色 description 中写明在场者与其他角色的关系角色性格逐渐趋同角色卡细节不足上下文覆盖了差异对比各角色对话首句风格增加行动描述、口头禅和多轮对话示例一个角色一直抢话角色卡缺少发言频率控制检查自动发言设置为谁优先手动指定发言人或给活跃角色写“不抢话”风格长对话后剧情失控上下文过长或世界书关键词命中过多查看是否发生截断、是否命中大量世界书条目缩短上下文长度、精简关键条目本地推理显存溢出模型过大、量化等级偏高、上下文过长观察生成时的显存变化换更小模型或降低上下文长度也可改用云端 API回复开始变得重复温度过高模型进入高重复路径查看同一开局的多轮生成结果降低 temperature、开启重复惩罚参数导出对话格式乱想批量自动化但没有工具先跑通单次 API 请求把角色卡文本和模型历史拼成 messages 后逐步批量新手最容易踩的坑是第一步没有先验证模型接口就直接跑到酒馆里调角色卡。实际上模型接口通不通和群聊能不能生成是两个独立问题。建议把失败排查顺序固定为“接口是否连通 - 单角色是否正常 - 多角色房间是否正常 - 角色语气是否正常”不要跳级。10. 最佳实践多角色群聊的工程化建议给角色卡做版本管理。每改一次角色性格就另存一个文件不要直接在原文件上覆盖。群聊里三张角色卡的调参过程很像联调三个模块A 的性格一变B 的应对策略也要跟着改。只在文件上改动后很难回看之前的稳定版本。给开局做“最小可用集”。保留一套已经验证成功的角色卡和开场设定作为训练新模型或测试新后端时的基准。不管换模型还是换 API先跑这套最小可用集能很快判断是新端不行还是配置疏忽。对话流程建议加日志。不管是手动跑还是脚本跑都要记录每一轮由哪个模型、哪个角色、在什么上下文长度下生成的。这样当你看到精彩的一局时不是只有一段感动还能知道它是怎么复现出来的。涉及真人肖像、声音、真实姓名或者受版权保护的角色形象时必须确认授权。不要让 AI 生成可能造成误导或冒犯的内容也不要在公开场合用没有授权的素材做演示。如果项目要进入生产环境比如做成“多角色自动剧情生成器”作为工具给别人使用要在输入和输出端都增加内容安全过滤并明确用户需要自行承担素材授权责任。11. 小结与下一步回到最初的目标给 AI 酒馆加群聊让三个角色真的互相接戏。从实际体验看SillyTavern 原生群聊机制已经够用真正的工程量在角色卡和场景控制上。只要三张卡的目标、语气、说话对象有足够差异并用世界书把关键背景锁定AI 角色之间确实能形成来回交锋而不是各讲各话。最容易踩的坑也是我前面反复提到的模型后端没自检、角色卡差异不够、上下文被无关角色抢占。任何一个点出问题都会让“三人接戏”退化成“三个助手在客套”。建议你先从两个角色的小房间试起跑通一遍完整的“开局 - 接戏 - 剧情推进 - 导出存档”流程再扩展成三个角色。这样后续每个新增角色都像给一套正常的接口加并发你能清楚看到是角色卡的问题还是模型记忆长度的问题。下一步如果继续深入优先级最高的是两件事让“谁在什么时候接话”从固定轮流变成真正的剧情驱动以及给角色卡写更丰富的多轮示例让模型学会在动态环境中保持自己的语言指纹。这两件事直接决定群聊观感是否自然。角色卡记得随时备份一次调好的配置值得保存下来反复做对比实验。