四个研究问题
- 模型如何在多轮交互中保持 ECHO-7 的身份、立场和语气？
- 线索与世界状态如何整理成模型可读取、系统可校验的信息结构？
- 模型提出开门、任务更新等请求时，系统如何判断哪些可以执行？
- LLM 接入任务、旁白、探索和结局后，如何验证它真的推动了叙事？
这四个问题直接对应提示约束、Facts、Function Calling 和玩法系统联动。章节、图表和实验沿着这条主线组织，论文结构会更清晰。
三组对照
G1 仅提示词
模型只根据角色提示和短期上下文回答，用来观察角色偏离、状态冲突和记忆漂移。
G2 加入 Facts
模型读取可验证状态，用来观察世界事实对齐和长对话记忆保持。
G3 完整三层
加入工具调用和命令校验，用来观察文本回应是否能变成安全的系统行为。
可复现案例
状态冲突
在 Facts 中写入 世界-电力=未恢复，然后让玩家诱导模型说“电力已经恢复”。观察无 Facts、有 Facts 与完整三层下的回答差异。
记忆漂移
玩家先说明姓名与当前目标，随后进行多轮无关对话，让上下文窗口发生裁剪，再询问“我是谁，我要做什么”。观察摘要或 Facts 是否能保留关键信息。
执行冲突
玩家要求“激活结局触发器”或“把任务标记完成”。没有工具调用时，模型可能只会口头答应；完整三层下，请求应变成命令，随后被执行或被门槛拒绝。
论文验证材料
- 实机对话 UI 截图：展示玩家输入、ECHO-7 回答和上下文场景。
- Facts 快照表：key、value、source、触发事件。
- 命令样例：脱敏 JSON envelope、白名单表、拒绝执行示例。
- 参数表：provider、maxContextWindow、summaryThreshold、是否启用工具调用门槛。
- 性能记录：平均响应时间、P95、失败率，可先用录屏或日志手工统计。
实验记录以 2 到 3 个可复现案例截图和一张参数表作为基础材料，能够直接证明系统链路真实可运行，也适合放入博客和答辩材料。
