1. 项目概述Edge-DM 到底解决了一个什么问题先说结论这是一个把大语言模型接进 TRPG桌上角色扮演游戏的完整方案。跑团圈子里的老玩家应该深有体会找一个是合格的 DMDungeon Master游戏主持人有多难——要懂规则、会控场、能编故事还得配合玩家的脑洞临场发挥。而 Edge-DM 就是一个专门用来充当 AI 主持人的项目它不只是一个能用自然语言聊天的壳子它的核心是让 AI 在游戏里真正“主持”起来它会推进主线、扮演 NPC、判定行动、处理战斗数值并且能长期记住故事状态。我为什么对这类项目特别关注因为 AI 辅助跑团这个方向看起来简单做起来全是坑。随便接一个 GPT 接口当然也能“扮演 DM”但那样得到的结果大概率是开场白说得像模像样半程剧情开始扯皮规则判定前后矛盾玩家说“我要去酒吧找老板娘搭话”AI 却自顾自地把主线剧情往下推——这就能直接毁掉一场团。Edge-DM 的核心价值不在于“用了 AI”而在于它把“叙事状态管理”“规则引擎”“上下文压缩”和“多角色调度”这些工程问题放在了同一条主线上来解决这恰恰是市面上绝大多数类似 demo 没有做到位的。这个项目适合谁来参考如果你是跑团爱好者同时有那么一点编程基础想自己做一套能真正带团的本地 DM 工具这篇文章非常值得读完如果你研究 AI Agent 的应用架构也想看看在具象、多轮、强状态约束的场景下如何让大模型稳定输出结构化结果同样可以从里面拿到不少可以直接搬走的思路。我不打算逐行贴 Enterprise 级别的源码而是把它当成一个“别人已经踩过坑”的项目来复盘它为什么这么设计、关键模块怎么实现、实际跑起来会遇到哪些问题。2. 技术选型解析为什么没有直接调一个大模型了事2.1 Edge-DM 希望达成的四个硬指标看这个项目之前得先明确一个 AI 跑团工具和“AI 聊天伴聊”之间的本质差异。聊天伴聊只需要保证对话连贯而 AI DM 的要害在于四个指标同时满足剧情一致性第 3 幕引入的伏笔到第 10 幕被揭晓时 AI 必须还记得状态一致性玩家把一把魔法剑放在了储物袋里AI 不能在后面又让 NPC 把这把剑“从腰间抽出来”规则一致性玩家投了点命中率、伤害值需要根据当前等级、BUFF、怪物的护甲来计算而且不能让 AI 凭空改数字自由度与可控性的平衡玩家可以做出规则外行为但 AI 不能因此直接放弃整个故事主线。如果只是把整个对话上下文全部丢给模型模型理论上可以处理但实际运行中上下文会越来越长长到甚至超过模型的窗口限制或者在关键细节上被大量无意义对话淹没导致“记忆混乱”。而且每轮历史都要重新推理响应延迟会变得不可接受。Edge-DM 的应对方案是把“游戏状态”和“对话流”抽离开。对话流是模型自由发挥的空间游戏状态则由工程代码来托管。2.2 为什么选择“叙事状态机 动态指令”而不是“纯 Prompt 流”最初我看到 Edge-DM 的设计文档时差点以为它只是又一个“用复杂 Prompt 来约束大模型”的包装产物。后来认真看它的源码结构才发现它用的是更稳妥的混合架构一个结构化的“叙事状态机Narrative State Machine”作为骨干再配合模型动态生成内容。叙事状态机是什么可以把整场游戏看成一棵树。下面挂着当前场景、场景内活跃 NPC、玩家目标、关键伏笔、以及推进条件。每一轮 DM 要做的事就是读状态机 → 接收玩家话语 → 解析意图 → 决定是“推进分支”还是“维持当前节点” → 生成剧情 → 把结果回写状态机。不只使用单一 Prompt 方案的好处非常直接状态机里存放的是结构化的、不会出错的数据结构比如当前场景的 ID、倒计时回合数、某个 NPC 对玩家的好感度等。这些东西不被大模型随意改写。而模型只负责做它最擅长的事——把结构化的“剧情要点”扩写成“有画面感的叙述”生成 NPC 的语言和神态。叙事主干由程序把关血肉由模型生成这样即使模型抽风故事的大框架也不会崩掉。当然这也带来一个需要权衡的地方状态机需要提前建模也就是要把游戏里“可能出现的剧情分支”预先定义出来。这就要求项目采用“篇章制”而不是完全开放沙盒。Edge-DM 默认带的几个剧本都是“多章节 稀疏分支”的结构每个章节有一到两个关键分歧点玩家选 A 就走向 A 线选 B 就走 B 线。这种结构比大开放世界更容易维护也比纯线性剧情有可玩性。3. 核心细节解析与实操要点3.1 游戏状态的拆分短期、中期、长期需要区别对待这是 Edge-DM 设计中最值得学习的地方。它把游戏记忆拆成了三层第一层是长期设定。包括世界观背景、大反派动机、重要历史事件。这些内容是很少变化的常量每次请求时不会完整带进模型的上下文中只会在剧情推进到相关章节时由状态机的“触发条件”把它作为背景卡片灌给模型。这是一种“按需唤起”的思路避免无用信息长期滞留在大模型上下文里。第二层是战役状态。包括玩家目前所在的区域、队伍血量、背包里有几瓶药水、哪些任务还挂着。Edge-DM 把这些信息保存成一份 JSON 结构只有发生变化时才更新并且每次更新后生成一份简短的“剧情摘要”用来在上下文过长时替换掉早期的对话内容。第三层是短期对话上下文。这是模型实际看到的东西但它不是原始的对话记录堆叠而是一个经过裁剪的滑动窗口大约保留最近 8 到 10 轮完整对话再加一份来自状态机生成的“当前场景快照”。这种三层拆分直接解决了 AI 跑团最常见的“第一天还正常第二天就忘事”的问题。层与层之间靠一套接口联动任何对任务状态、物品、NPC 态度的修改都必须通过专门的 API 写入状态机模型本身没有任何直接改状态的权限它只能“请求”状态变更由代码来校验这个请求是否合法。这个设计值得作为通用经验记住在构建带记忆的 AI Agent 时不要让大模型直接拥有内存的写权限给它一个“写前校验”的工具会更安全。3.2 规则引擎与骰子机制AI 可以给故事建议但杀手不能由 AI 说了算跑团爱好者对规则一定不敏感。DND 5E 或 COC 这类规则书动辄几百页想让大模型把 CR挑战等级、难度等级DC、先攻骰、伤害骰全部背下来既没必要也不可靠。Edge-DM 的做法是规则核心全部手写为代码中的函数式判定模块模型只负责输出“语义意图”。展开来说当玩家说出“我想用匕首从背后偷袭那个守卫”时Edge-DM 的工作流是这样的——模型将这句话解析为意图“隐匿检定 近战攻击”规则引擎从状态机读取玩家的敏捷修正值、当前是否处于潜行状态、守卫的被动察觉值玩家点击“投骰”由规则引擎在本地生成随机数计算最终点数并输出结果模型根据这个结果去写“剧情反馈”。这里的关键点在于判定结果不由模型生成而是由规则引擎计算出来再喂给模型。为什么因为大模型对数字的处理本质上是对概率分布的采样你让它“生成一个 d20 掷出的点数”即使图灵测试过了它在数学上也不是均匀分布的而且——更致命的——它可能“为了戏剧性”给你掷出一个 20。规则引擎背下了随机性这个机器模型只是在旁边做叙事工作。AI 可以对故事走向提建议比如“根据目前的情报守卫只有 3 点的 HP”但谁死了谁没死由硬计算决定。实操时我强烈建议所有做同类项目的人遵守这个原则凡是涉及数值结算、概率判定、资源扣减的逻辑都要走确定的代码不许让模型用自然语言裁决。否则迟早会遇到“AI 为了救场手动把你的死亡判定改成了成功”的尴尬局面。3.3 NPC 调度让一个人管五个角色的“精神分裂”问题跑团团有一个经典场景AI 同时扮演店主、同行的 NPC 队友、一个反派的小喽啰。如果让一个大模型在一次输出里同时扮演多人大概率会得到三个说话像同一个人的对白。Edge-DM 的解决方案比较聪明它并没有为每个 NPC 加载独立的模型实例那太贵了而是把 NPC 的“记忆文件”和“角色卡”分开管理。角色卡定义了说话风格、目标、秘密、对玩家的态度是一段几百字的结构化文本。而记忆文件记录着这个 NPC 和玩家在历次对话中的交互历史。当一场对话进入“多人对话”阶段Edge-DM 会将场景中活跃角色的角色卡与各自记忆文件按需打包放入模型当前输入并在指令中强调“在每一次回复前先标注你正在扮演哪个角色”。你看它跑出来的实际效果三个人可能还不至于明显性格迥异但至少每个人都有了边界感店主记得玩家刚卖过什么队友有他自己的小心思反派小喽啰会恐惧逃跑而不是无限嘴硬。对没有代码基础的读者这一小节的实操启示是当你需要 AI 在一场对话中扮演多个角色时千万不要把多个角色全部塞进同一段自由发挥的提示里。你需要的是一个角色管理器把每一角色的设定拆出去按需取回。支持大模型输出“结构化角色标签”再在渲染层剥离出来是稳定处理多角色对话的必要手段。4. 实操过程与核心环节实现4.1 部署第一课环境选择与模型量化Edge-DM 有一个值得一提的取向它的名字里有“Edge”这意味着它的目标场景是“边缘设备”——也就是普通人家里的个人电脑。说实话如果你只想在线上玩一两局直接调用云端 API 是最省心的。Edge-DM 之所以走本地推理路线一是考虑到部分玩家对线上数据隐私不放心二是跑团通常是一个持续数小时的、需要高频交互的场景走本地部署可以显著降低单局成本。实操层面项目默认支持的模型方向是 llama.cpp 体系下的 GGUF 量化模型。以普通配置为例一张 4060 Ti 16GB 的显卡可以跑 7B 到 14B 参数的量化模型如果内存有 32GB甚至可以用 CPU 跑 14B 低量化模型。运行速度方面经过量化的 7B 模型在 16GB 显存上推理一段 500 字的剧情约需要 3 到 5 秒这个节奏在跑团场景中勉强可接受——正好给玩家留点茶歇时间。个人建议纯新手不要试图一开始就运行原版 Edge-DM 的完整代码。先把它拆成两个小实验来跑通第一个实验是仅调用本地模型加载一份预设角色卡测试模型能不能稳定输出符合风格的场景描述第二个实验是跑通内置的默认剧本。两个实验都过了再去折腾外部知识库和多人插件。为了缩短故障排查半径第一次跑通请务必用一个干净的 Python 3.11 虚拟环境依赖冲突会浪费你大量的时间。4.2 关键配置语法世界书与灵感库我看过的很多 AI 跑团类项目都有一个类似叫“世界书 / World Info”的机制Edge-DM 也沿用了这种思路。所谓“世界书”是一组由关键词激活的设定片段。比如玩家只要说出“黑森林”三个字模型输入中就会自动插入一段关于黑森林的地理、历史和当前危局的描述。这比把所有设定一次性塞给模型高效得多可以极大缓解上下文窗口压力。在 Edge-DM 的配置目录里一个世界书条目用的是键值对结构。下面是我在实操中总结的比较顺手的格式条目名称entry name关键词keywords建议 2 到 4 个命中后才会激活内容content与这个关键词对应的设定描述控制在 200 到 300 字以内优先级priority如果两个条目同时被激活优先级高的内容排前面。这里我踩过一个大坑最初我的世界书内容偏好工工整整的百科式排版比如“黑森林是位于大陆东北部的密林占地多少平方公里”。实际跑起来后 AI 的剧情里会出现生硬的解说感。后来我才想明白世界书的内容要给模型看的“写作素材”而不是用户看的产品文档。好的写法是带着氛围和具体人物。把“黑森林遍布毒蘑菇”改成“老猎人提醒过你黑森林里每一棵蘑菇都在等一个粗心的旅人”整体输出质感完全不一样。4.3 提示工程的两个关键段系统提示与环境快照首轮请求时用一份“系统提示”来保证 Agent 行为边界。Edge-DM 没有把规则全部写进超长的提示里比如将规则手册全文丢给模型是不可取的模型读不完还会被稀释。它只列了五条最核心的行为约定负责推进剧情但不要代替玩家做决定每次判定前调用规则接口不要自行输出数值NPC 只基于自己的记忆和动机行动描述场景时要有感官细节不要术语堆砌若玩家长时间无行动可以抛出事件引导剧情但不可突兀展开主线。复杂度更高的实现体现在“环境快照”这个变量。每次请求前代码会从状态机生成一份结构化的 JSON 快照包括当前场景 ID、天气/光照、区域内可见 NPC、玩家状态、最近的关键事件摘要。然后把这段 JSON 放在系统提示末尾模型每次看到的都是“当下此刻”最有信息量的世界状态。正是这两段不同信息的叠加让模型能分清“我是一个需要长期扮演的 DM”和“此刻我们正处在什么场景”。如果你自己搭过 AI 写作类的 Agent一定会理解这种分工的重要性前者把模型锁在正确的“人设”后者把模型推到正确的“时间点”。两者不能混淆。4.4 结构化输出如何把玩家话语“翻译”给状态机大模型在主叙事阶段输出的是非结构化的自然语言这没有问题。但处理玩家输入时Edge-DM 会用另一套“轻量解析工作流”把玩家的话送进一个小模型任务队列让它产出三个字段的 JSON意图类别act/ask/move/interact/free、目标对象、补充描述。为什么要这么做因为状态机本身无法理解自然语言它需要指令来更新状态。而且结构化输出能防止玩家过高自由的话语直接击穿后续规则逻辑。举个例子玩家说“我对老板释放一个魅惑法术”解析器给出的意图是 cast_spell目标对象 owner补充描述 charm。接下来规则引擎会去读玩家职业与法术位并判断在此场景用魅惑法术合不合适学校场景也可以用来判断 NPC 会不会因此把玩家轰出去。在实测中我遇到过解析歧义的问题。“我想和她聊聊”是 interact 还是 askEdge-DM 用了个比较实用的兜底策略——当置信度不足时默认按“靠近后自由行动”处理先让玩家进到 NPC 身边谈话再根据后续具体语句递归解析。简单说解析器不是万能读心术但它保证了状态机不会在模糊语境下走进死胡同。5. 常见问题与排查技巧实录5.1 上下文爆炸与剧情倒退把摘要系统加在不知不觉处跑团持续两个小时后最常见的毛病是模型开始“忘了”半小时前主角负过伤。观察 Edge-DM 的设计它用了一种“渐进式摘要”而不是简单丢弃旧对话。旧对话被清理前会先丢给模型生成一段 50 到 100 字的剧情摘要里面保留与当前目标相关的信息点。随着时间推移这些摘要又会被再次摘要形成金字塔结构。我在自己复现这套机制时发现几个需要注意的细节摘要的生成时机不要放在请求高峰段否则延迟会突然飚升放在一章节结束或游戏空闲时段批量处理比较合适摘要时给模型一个“必须保留玩家关键决定”的强制指令比如“不接受任何对已发生事件的改写描述”摘要可以被玩家主动查看告诉他“上一次冒险的最后记忆”——这种元认知对齐其实对长跑团的体验很有帮助。5.2 AI 编造物品和数值的幻觉问题有一次跑团AI 描述玩家“从口袋里掏出一个在酒馆里买来的臭气弹”。问题是玩家从头到尾没买过这个东西甚至背包里也没有。这种幻觉来源于模型的“默认常识”它觉得玩家里总该有些小零碎。Edge-DM 的防幻觉方式是“物品白名单”与“描述校验”。状态机里有一条物品清单模型输出的物品名称如果出现在状态机索引之外会被拦下来不允许作为道具生效。但若拦得太死会让叙事变僵所以我建议把这个校验设计成“软校验”——如果模型在描述场景中提及了普通的环境物品比如桌上有盏油灯放行如果试图从玩家背包中“凭空掏出”东西拦截。区别就在于环境物品只影响氛围背包物品影响游戏平衡。5.3 网络代理与本地推理的性能抖动很多人实测跑团项目时发现一个现象本地推理时快时慢生成文字非常流畅但碰到大段场景时卡到爆。这主要跟 KV Cache 的大小和 prompt 长度有关。当一段对话的输入 prompt 超过 4K tokens 后预填充pre-fill阶段会显著拉长这就是一个隐藏的瓶颈。我在自己的机器上测试时发现把 prompt 长度限制在 3K tokens 以内并配合动态截断能比硬塞 8K 历史快将近一倍。而 Edge-DM 的滑动窗口设计基本上就是在做这个事只带最近 8 到 10 轮对话。这从侧面说明了一个重要原则——AI Agent 的延迟问题很多不是出在模型推理本身而是出在盲目叠加的上下文长度上。记住过度的历史不等于好的输出质量把信息修剪成状态快照和摘要性能会立刻上一个台阶。5.4 玩家自由行为导致的剧情卡死最让我头疼的一个实际问题是玩家总喜欢做状态机里没有预设的事。在我测试 Edge-DM 时玩家在第一章就把 NPC 店主的店烧了而默认剧本里这位店主是后续重要线索的提供者。状态机没有分支能处理这个“世界被提前炸了”的情况。Edge-DM 的应对方式是“剧情重路由”。当状态机检测到关键 NPC 死伤或关键物品被毁它会从“宕机”状态自动进入“即兴模式”模型收到指令要求它生成一个新的替代线索入口但不得推翻玩家行为的后果。这种情况下店主没了线索可以由店里留下的账本或一个目击者来顶替而不是强制主角“存档读档”。这个过程让我学到的是完全固定的状态机并不适合自由跑团需要有一个即兴接管层让 AI 在权限范围内对突发事件做出合理的新剧情解释。但接管层的触发需要非常小心——只应代替剧情走向的“因”而不应改变世界规则的“果”。6. 扩展与进阶Edge-DM 式架构的更多应用想象不只是桌面游戏。我在跑通 Edge-DM 后最大的感受是这个架构完全可以迁移到很多需要“持续幻觉可控”的内容生成场景比如 AI 跑团工业的产品化自动生成互动小说、基于角色的多轮任务导向问答系统、甚至可以被改编成“AI 面试官”来长时间模拟面试场景。关键是它给了一个非常好的底座把不稳定的模型输出与稳定的规则引擎分离开让模型只做表达而非决策。我也在试第二批更轻量化的玩法在手机或小内存笔记本上部署一个“迷你版 Edge-DM”把 7B 模型换成 3B 模型世界书压缩到五六条。如果只是用来给线上语音跑团做一个“背景氛围补充”这个轻量版完全够用而且延迟会在 1 秒以内。这个内容后续还可以这样扩展接入语音输入让玩家直接说话由 Whisper 转换文字再进 DM 流程也可以接入 AI 绘图接口在关键场景生成一张概念图增强沉浸感——不过这些功能都需要额外的人数与成本管理不能随便塞进去。到这一步你手里就真正有一个可以长期打磨的 AI 桌游主持人项目了。根据我个人的实际体验这项目最吃功夫的地方不在模型选型而在数据状态设计和规则接口的调用。如果你的最终目标只是“给朋友跑团时增加一点新鲜感”保持轻量即可不必一开始就追求完全自动化但如果你想把“AI 当 DM”做成一个产品Edge-DM 提供的这套混合架构思路是值得认真踏踏实实读完的参考方案。