你的动态网关比喻切中要害,但LLM直接接管协议层会碰到状态同步的硬伤。这个问题的根因是把“语义理解”和“状态机”强耦合了。
MUD的底层逻辑不是“能听懂人话”,而是“世界状态可回溯”。传统正则虽然死板,但它是确定性的。LLM输出是概率分布,同一句“跟守卫扯个谎”可能触发三种不同分支,存档回滚时直接崩盘。这就像混音时没做总线压缩,动态范围一开大,底噪全出来了。建议解耦:LLM只负责生成意图向量(Intent Vector),由确定性规则引擎(FSM或行为树)做合法性校验和状态跳转。
实时交互的延迟阈值在200ms以内。云端LLM的RTT加上Token生成,轻松破500ms。本地部署7B模型又吃显存。架构上建议走分层路由:高频基础指令(move, take, look)走本地轻量级NLU(意图分类+槽位填充),复杂叙事/社交走云端LLM。上下文管理用滑动窗口+关键状态快照(State Snapshot),别把整个MUD世界塞进prompt,token烧钱不说,上下文污染会导致逻辑漂移。
其实叙事权倾斜不等于放弃设计。完全动态生成容易变成“流水账模拟器”。可以参考Hip-hop的采样逻辑:预设高质量叙事锚点(Anchor Nodes),LLM负责在锚点之间做动态桥接(Bridge Generation)。玩家自由度在桥接段,但核心剧情走向由锚点约束,这样既有生成式的惊喜,又不会丢主线节奏。
搭中间件可以按这个链路跑:
- Input -> ASR -> Intent Classifier (本地FastText/BERT-mini)
- Intent -> State Validator (FSM/规则库) -> 拦截非法状态跃迁
简单说3. Valid Intent -> LLM Router (云端/本地) -> 生成自然语言响应 & 状态Delta
- Delta -> World State DB (SQLite/Redis) -> 广播给客户端
周末湖边钓鱼回来如果跑通PoC,记得压测一下并发下的状态一致性。这玩意儿跟debug一样,日志打全了,问题自己会浮出来。你打算用Rust还是Go写中间件?我这边有套现成的状态同步模块可以fork给你测测。