Edge-DM：大模型与规则引擎驱动的AI跑团主持人辅助系统实践

上周五晚上我主持的《龙与地下城》团又翻车了。三个玩家围在桌前等我描述铁门背后的场景我却在第七次翻规则书确认坠落伤害的骰子配置——那一刻是真的想找个借口去洗手间冷静一下。每个DM都经历过这种时刻又要编剧情、又要算伤害、还要记得三小时前某个NPC随口说的一句话好在关键剧情里闭环。我做了个叫Edge-DM的项目一个把大模型能力装进桌面角色扮演游戏主持人流程的AI辅助系统这篇文章就聊聊它的设计思路、踩坑记录和一些实测经验。它适合谁用想自己开团但怕hold不住的新手DM以及带固定团几年、每次跑团前还要花两小时备课的老手还有其他在做AI Agent项目、想看看怎么把多智能体协作落到真实场景的人。1. 设计初衷跑团桌上最累的那个人值得被工具拉一把1.1 一场三小时跑团里DM承担的隐形工作很多没跑过团的人以为DM就是念剧情的实际上DM是整个桌上唯一一个同时干着编剧、裁判、配音演员、项目经理四种工作的人。我在一次带团时偷偷统计过自己的工作量三小时下来我要临时编出7个NPC的反应处理4场战斗的攻防判定记住玩家在酒馆里随口跟酒保说的话还得在队伍两条路线之间维持进度平衡。最崩溃的是玩家突然说我要跟那个兽人谈判——我根本没给这个兽人设计任何台词当时只能硬编事后复盘发现那条线跟后面的主线产生了设定冲突。这已经不是能力问题是纯纯的精力问题。玩家的期待是整个世界都活着但一个人的短期记忆和工作记忆是有上限的。我试过用纸笔记录、用Obsidian整理、甚至给NPC写性格卡片这些都有帮助但都解决不了一个核心矛盾桌上在跑团节奏不允许你停下来翻三分钟笔记。所以我对AI工具的定位从一开始就不是替代DM而是给DM配一个不会累的副手它去承担那些机械性、记忆性、需要快速反应的活把创意和临场判断留给人类。1.2 为什么项目名字叫EdgeEdge这个词有两层意思我都是故意的。第一层是边缘计算也就是本地部署模型不依赖云端的推理接口。第二层是站在桌子的边缘——一个不抢戏、但随时伸手就能拿到辅助工具的存在像个球场边的战术分析师而不是上场抢球的人。选定本地优先这条路线是因为我观察到一个很现实的情况跑团场景对延迟极其敏感。线下团大家面对面坐着中间隔着空气和零食如果每次AI响应要转5到8秒的圈玩家就会开始刷手机那个氛围就断了。云端API在很多场景下确实很强但网络抖动、服务限流、上下文变长后的排队等待都是桌边场景无法忍受的变量。另外一个不太会被提起但同样重要的理由是隐私。跑团过程中玩家会不自觉地暴露很多个人化的内容处事习惯、对某些局面的倾向性反应、甚至一些压在角色里的真实性格。这些内容被传到云端做推理多少会有顾虑。角色卡和剧情走向是玩家共创的东西我更希望它留在本地。2. 架构设计一个合格的AI主持人不是只会聊天的聊天机器人2.1 四个核心模块的分工Edge-DM的整体架构我拆成了四个模块语音/文本输入端、规则仲裁引擎、叙事生成器、对话与状态管理。早期的原型我犯过一个典型错误——把所有功能塞进一个超级Prompt里让大模型同时负责规则判定和剧情描写。结果非常灾难AI经常算出离谱的骰面结果又写得一手浓郁网文风。原因是规则判定是确定性逻辑需要精确的数值运算而剧情描写是非确定性创作需要自由发挥。把两者混在一起模型要么精确但不生动要么生动但乱来。后来我彻底改成模块分离四个模块各管一摊事模块职责实现方式输入识别把玩家语音/文本转成结构化动作宣言语音转文字 意图分类规则仲裁判定动作是否成功、计算伤害和状态效果自行编写的规则解析器不交给大模型叙事生成把判定结果写成生动的场景描述本地大模型带约束提示词状态管理记录角色血量、装备、剧情进度、NPC关系SQLite 内存缓存双重结构2.2 规则仲裁和叙事生成为什么要拆开举一个最典型的场景玩家说我想从悬窗跳下去抓住吊灯荡到对面看台上。如果直接把这个需求扔给大模型它会综合判断敏捷检定、坠落距离、杂技动作的难度级别然后给出一个听起来合理但不一定符合规则书的判定。但桌游规则是有明确数值基准的比如龙与地下城5e里这个动作涉及敏捷检定、杂技技能熟练加值、跳跃距离规则、可能的坠落伤害。大模型训练数据里混了大量房规和不同版本的内容它很容易把3.5版的规则和5e的规则缝在一起。规则仲裁模块的存在就是要把这段计算从幻觉里拉出来用代码写清楚这个动作需要哪些检定、难度等级是12还是15、骰子结果是多少、有没有优势或劣势。计算出成功且超出5点的结果之后再把数值结果交给叙事生成器让AI去写你单手扣住吊灯底盘借力荡出一道弧线靴尖精准踩上对面看台栏杆这种描述。这种数值走逻辑、描写走模型的分离是所有跑团AI工具能稳定使用的前提。2.3 三智能体协作主持人、判官、戏精只用单个模型实例做所有事还有一个问题角色的说话风格和主持人的旁白风格会互相污染。我试过让同一个模型既做旁白又配NPC台词后半程所有NPC说话都是一个腔调连兽人讲话都带着中古英语翻译腔。Edge-DM在这个版本里做成了三智能体协作一个主持人Agent负责接玩家的宣言、安排节奏一个判官Agent调用规则引擎做裁决并产出数值一个演员Agent专门生成角色台词和动作描写还要维持NPC人设的一致性。它们之间通过结构化的内部舞台说明通信不是互相聊天——比如主持人Agent收到我要威胁酒馆老板之后向判官发一条{intent:intimidate,target:barkeep,skill:intimidation}判官返回检定结果15 vs DC 13 成功然后主持人再把结果和场景背景打包发给演员Agent。这样分工之后每个模型的职责面变窄了反而更少出状况。多智能体协作看起来像是多绕了一道实际效果是分工明确、互不污染这也是我在踩了不知道多少次单一Agent精神分裂的坑之后切到的正确形态。3. 上下文工程让AI记住三小时前的伏笔3.1 跑团对话为什么比普通聊天更难喂给大模型普通聊天机器人的上下文管理逻辑是大致线性的你问它菜谱它答端上桌聊完就翻篇。跑团不一样玩家的一个决策可能在四小时后才产生呼应。我在一个魔法城市场景里埋过一把生锈的钥匙三个小时之后玩家在墓园门口提到之前那把钥匙会不会能开这里的门那一刻如果AI忘了这把钥匙的存在整个剧情的闭环感瞬间归零。token预算也是现实问题。一场三小时的跑团光是玩家发言和AI回应的原始对话文本就可能达到3到5万token。如果把这些全文塞进上下文窗口每次请求的价格和延迟都会随着session增长不断恶化。本地模型更是直接卡在显存上限上上下文稍微长一点就OOM。我做过一次粗测一条两小时的短团对话记录超过4万token用云端模型连续追问到后半段单次响应延迟从1.8秒涨到4秒以上而且模型开始出现遗忘前文的症状。这就是为什么要做专门的记忆工程——靠买大上下文窗口绝不是出路。3.2 分层记忆核心档案、场景短记、剧情简报我给Edge-DM设计了一套三层记忆结构灵感来自我最开始用的笔记方法但做成了自动化记忆层内容刷新频率存储位置核心档案玩家角色卡、NPC人设卡、世界观设定只在变更时更新长期存储场景短记当前场景的物品、NPC现状、临时状态每场景结束刷新短期存储剧情简报本段主线进度、关键伏笔、待回收线索每30分钟压缩一次长期存储操作逻辑是这样的每轮玩家行动推进之后会有一个压缩Agent很轻量的模型把刚才的对话摘要成结构化的短记合并进剧情简报。比如三十条关于在港口找船的信息最终只压缩成队伍决定前往黑帆港偷渡船长欠酒馆老板一个人情。注意这个压缩过程不能丢情绪细节。玩家是否在某一刻动了杀心、某个NPC的眼神有没有异常——这些东西是后面剧情爆点的种子。我在压缩指令里明确要求保留未解决的冲突角色的强烈情绪不确定的伏笔三类信息其他内容才允许精简。实测下来这样做之后即使原始对话有5万token每轮请求真正喂进模型的只有最近一小时的场景短记 压缩后的剧情简报 核心档案大概是6000到8000token效果反而比硬塞全文更稳。最主要的原因是任务相关性和噪声比大幅改善模型不再需要从4万token里自己捞关键了。3.3 角色一致性不靠运气靠锚点让同一个NPC下次见面还是那个人光靠跟模型说请保持角色一致是没用的。模型不是演员它没有我上次怎么演的这种记忆每次生成台词都是在做无状态预测。要让角色有灵魂必须给它一个锚点。我的做法是为每个重要NPC维护一张简短的角色人格卡结构大致是姓名酒馆老板铁手科恩 身份退役佣兵现经营断剑酒馆 口癖每句话结尾喜欢加对吧 核心动机想筹钱赎回自己被绑架的女儿 禁忌不愿意提起自己的假肢 对PC的态度表面热情暗地里在观察是否有利用价值 台词示例提供2-3条作为文风锚点这张卡不追求长关键是有口癖、核心动机、态度倾向三个锚点。我实测下来只要有这三个锚点配合生成约束以科恩的口癖和动机回应当前语气警惕模型产出的台词一致性就能从听着像换了个人进步到一个熟悉的老朋友在说话。台下功夫也很重要每轮结束之后花30秒让压缩Agent把玩家和NPC之间的最新关系变化更新到人格卡里。这也回应了前面说的记忆分层人物卡不是静态的它一直在被剧情推进刷新。4. 部署选型离线跑团的硬件底线与真实体验4.1 本地模型怎么选参数、量化与显存本地部署从来不是选一个最大的模型回来跑这么简单。参数规模、量化等级、显存大小、响应速度四者互为代价。我自己的机子是RTX 4090 24GB显存跑7B量化模型绰绰有余跑13B要压一下上下文长度70B只能看不能用——推理延迟拉胯到无法现场使用。给出一个基于我用过的开源模型的对照表不同卡都能参考模型规模量化等级显存要求单轮生成100token延迟跑团可用性评估7BQ4_K_M6-7GB0.8-1.5秒可用描述比较简单13BQ4_K_M9-11GB1.5-2.5秒良好细节丰富度明显更好13BQ813-15GB2.0-3.0秒良好但上下文稍受限70BQ4_K_M40GB5秒以上桌边实跑体验差不适合现场用对我个人而言13B Q4量化是体验和硬件的甜点。它的描写细腻程度在跑团场景里已经够用了尤其在扮演NPC、描写战斗场面这些任务上几分钟快速上手够流畅。4.2 本地模型和云端API的真实取舍我在Edge-DM里做了双后端支持既能用本地模型也能切云端API但两个方案定位完全不同。如果今天我开的是线上语音团队友分布在不同城市网络条件相对稳定那用云端API反而更省心——上下文管理交给服务端、生成质量高、不用担心本地显存。但线下团或者户外临时开团本地模型就是刚需。我有个朋友在咖啡厅开团、只带一台笔记本信号时断时续云端API一断线整个跑团气氛就崩了。Edge-DM本地模式下模型全部跑在笔记本上网络断了不影响。云端方案的另一个劣势是不可控的更新和审查机制这对跑团创作的自由度有影响。本地模型虽然能力上限略低但永远可用、永远忠于你的设定这个特性在创作场景里是致命的优势。4.3 延迟、token与真实的桌边节奏技术指标不能只停在benchmark上桌边的真实体验才决定一个工具能不能被接纳。我用13B本地模型实测一条30token的玩家宣言到AI产出120token的旁白回应全程大概1.5到2秒——这已经达到了玩家刚说完、气氛还没冷场的标准。同样任务用云端大模型虽然是1秒级生成但加上上传下载和排队真实感知延迟常常在3到5秒反而更慢。token开销的现实账也值得算。一个固定四人团每周开一次、每次三小时一个月大概消耗80万到120万token。如果用云端收费模型这是一笔不小的固定开销。而13B本地模型的成本就是电费和显卡损耗后端生成速度还随着并发度降低而更稳定。多人跑团场景中每多一个玩家云端方案的token成本和延迟就多一分不可控本地模型则几乎不受影响。5. 一场地精伏击战的完整复盘5.1 从玩家宣言到AI回应的完整链路用一个真实的测试团来说明整个流程三人小队进入废弃矿洞触发了我埋在场景里的伏击——三只地精藏在岩石后面偷袭。玩家的宣言是矮人战士想都没想就朝最近的地精冲过去举起斧子劈下去。这条宣言进入Edge-DM之后依次经过输入解析模块识别动作意图突击、近战攻击、目标地精一号判官Agent从角色卡读出矮人的力量加值和熟练加值向规则引擎发攻击检定规则引擎生成1d20的随机结果加上修正值对比地精AC判定命中判官把命中、伤害7点、地精仍有微弱战斗力的结构化结果回传演员Agent收到场景描述、命中结果和地精剩余状态之后输出一段旁白矮人踏着矿渣冲上前战斧划出一道弧线劈在地精肩上那家伙尖啸着后撤两步龇牙咧嘴重新握紧了锈刀。整个链路在15B模型下耗时不足3秒。主动权重新回到DM手里DM只需要在此基础上调度其他怪物的行动、补充一些即兴细节就行。5.2 翻车现场AI把地精演成了站桩木偶调试过程中不是没翻过车。第一版测试里出现了很多让人哭笑不得的画面三只地精被AI演成三根桩子——矮人劈地精一号时地精二号和三号就在旁边看着既不攻击也不逃跑像在排队等被砍。根因很快定位出来叙事生成模块只接收了当前行动的结果完全没有接收场景中其他怪物的状态和立场。那只被劈的地精对模型来说是唯一的存在其他地精只是背景板自然不会被安排行动。修复方式是在传给演员Agent的情景数据里始终携带一份完整的当前局面清单在场单位、各自态度、上一轮做了什么事、谁受伤了。模型知道了地精二号已经拉开短弓瞄准法师它自然会在矮人冲锋时做出地精二号放箭掩护同伴这类反应。这种问题不做复盘是根本发现不了的因为它不是报错而是内容质量不佳只有结合现场体验回头看才能找到结构性原因。5.3 调参之后温度、惩罚机制与约束词同一局面只改三组参数就能明显改善质量这是我在多次测试之后确定的三个旋钮温度temperature跑团场景我调在0.8左右。太低会变得像新闻稿太高会在一段正常的战斗描写里突然冒出地精用口音讲冷笑话这种失控发挥。上下采样惩罚top_p / repetition penalty跑团最怕角色台词场景化重复每个地精都只会说同一句话。repetition penalty保持在1.1到1.2之间能有效减少NPC台词和动作描述的格式化重复。约束提示词在每段生成前强行附加一个边界文本比如仅描写当前场景中可被感知的动作和对话不输出玩家角色的内心想法不给出任何指南或建议。这个约束核心必须每次带上否则模型很容易从旁白滑向人生导师。调参之后同一个伏击场景地精的输出变成地精二号看到同伴被劈立刻拉开弓瞄准法师地精三号把短剑插进腰袋、转身朝矿洞深处逃窜。这种有独立意志的行动让战斗的动态感一下子出来了。6. 高频翻车点与进阶玩法6.1 我最常遇到的五个坑整理一下目前最常踩的坑希望后来者能少交学费问题表现我最终的解法规则幻觉大模型把不同版本规则缝合在一起规则判定彻底从模型里剥离只走代码叙事节奏失控模型话痨一段旁白几百字设置单次输出最大长度并附上下限约束角色出戏NPC前后态度不连贯用固定人格卡模板锚定每个重要NPC剧情伏笔丢失玩家提到的线索被遗忘压缩Agent定期更新剧情简报保留伏笔项延迟不可感知但温度感失控玩家觉得AI回应太顺滑、太快像读稿故意加入行动等待节奏在关键场景强制停顿再输出最后一个坑可能和直觉相反AI反应太快太完美反而破坏了跑团桌的表演张力。玩家做一个庄重的仪式动作结果AI秒回你完成了仪式完全不给紧张感积累的时间。后来我在提示词里加入节奏指令——对重要仪式、解密、对峙场景生成前先停顿或者要求加入角色反应之前的一瞬沉默之类的描写桌面张力反而更足。6.2 让AI学会闭嘴叙事节奏控制跑团不是广播剧DM最重要的一项技能是知道什么时候不说话。AI模型天然有话痨倾向因为生成连贯文本是它的本能。Edge-DM里有一个专门的缄默策略模块它评估当前场景类型、玩家情绪、上一次AI输出长度决定这次回应是详细描写、简短点到为止、还是只给拟声词。举个例子如果玩家刚做出一个Cool点级别的操作比如大成功斩杀BOSS这时候才需要一段足够戏的描写来烘托气氛但如果玩家只是要开一扇普通的门模型需要控制输出在50字以内把关注度还给玩家在场上的互动。节奏控制做不好AI就变成了所有人都在等它讲完话的麦霸工具。6.3 下一步语音化、地图联动与更轻的开源模型Edge-DM现在跑得算是稳定了我接下来的计划集中在三个方向第一是语音识别与合成。线下跑团没人愿意打字这套系统要真正融入桌边必须有低延迟的语音输入输出能力。目前我在接本地ASR模型目标是让玩家直接说话AI旁白用语音合成读出来——这中间需要的中间处理比大多数人想的多包括把连续语音里的打断感和犹豫处理好。第二是和虚拟桌游地图工具联动。很多线上团习惯用地图方格来走位Edge-DM如果能把模型生成的怪物位置自动同步到地图上会省掉大量手动整理的时间。目前这个联动是靠解析规则引擎的结构化输出来实现的下一步想做到AI自己规划敌人站位。第三是持续关注更轻量的开源模型。本地模型的每次迭代都会带来体验提升过一段时间回头对比效果差距都挺明显的。把模型版本和角色卡配置做成可热切换是我在设计Edge-DM第一天就定下的原则——AI的底座升级不应该要用户推翻整个配置。最后说一个经验总结之外的小技巧如果你也想做类似的AI跑团工具先把规则引擎和大模型解耦想清楚再动手写对话逻辑。很多同类项目最后做不下去不是模型不够聪明而是从一开始就把什么活都丢给模型干到后期根本兜不住。Edge-DM做到现在的最大体会是AI工具最好的用法是当一个永远在线、记忆超好的工具人真正的创意和裁决权还是要留在桌上那个活人手里。