我是独立开发者，已经花了大约一年时间在这个项目上。 Mythloom基本上是这样的：如果群组聊天可以运行D&D活动，并且不需要实际GM。 AI可以在Android上为1-5人运行。 我最初认为LLM调用的难点是最大的。事实并不是这样。 这里是实际耗时一年的事情。骰子。我的第一版让模型讲述它没有掷出的骰子。测试者马上就发现了这个问题。人们讨厌假骰子比我想象的要多。所以现在服务器上的一个枯燥的确定性引擎掷出所有骰子，模型只需要要求一个检查（谁，什么技能，什么DC）并接收结果作为一个事实。 我还clamp每个数字的建议，因为如果有足够的回合，它会绝对地尝试给某人一个DC 45。 与此相关的事情也伤害了我：一个大而严格的工具调用的整个回合一次死于语法大小限制。最终，我将其分成两个：一个严格的调用用于重要的内容（叙述，检查，机密）和一个松散的调用用于战利品和剧情线索，后者我也在服务器端重新清洗。 内存。掷骰子上下文会在第3章时忘记招待员。实际上有效的方法是非常枯燥的结构化状态。NPC卡片具有重要性分数，以便重要的卡片不会从窗口中掉出。 每10个回合重写一个概要。 而我又蠢又骄傲的部分是：GM保留自己的未解决剧情线索清单，并显示哪些线索它已经保持沉默最长时间。所以你在第3个回合设置的东西在第20个回合就会回来，而不是简单地消失。 秘密。玩家可以发送没有其他人看到的行动（暗杀者的事情）。仅靠提示规则无法阻止泄露，甚至没有。所以秘密文本永远不会触摸客户端可读的行，并且有一个傻瓜式的服务器检查，扫描公共叙述以确定秘密之前它会发送。带子和吊带。 最大的教训，我学到了两次：我将通过测试通过的功能交付给生产，因为模型永远不会发出该字段。一次我的验证器静默地丢弃了密钥。一次我的缓存提示告诉模型跳过工具，该字段所在的工具。测试证明你的管道工作。它们告诉你什么都没有关于模型实际做了什么。只有实时运行才能捕捉到这一点。 无论如何，我很好奇其他人在长期记忆方面做了什么。结构化状态像这样的东西？RAG？ 只是更多地将上下文投入它并希望？ 由于风格就是这样：我很乐意为前5个想在多人模式下攻击这个应用的团队提供一个月的Pro。将您的党派代码传递给我，我将在服务器端翻转它，没有任何附加条件。免费，如果您想探索：https://play.google.com/store/apps/details?id=com.lmfd.mythloom