AI 角色“会聊天”不等于“记得你”：记忆、状态与剧情后果的三层设计

能接住上一句话只是上下文；能提起旧偏好才是记忆；只有旧互动改变今天能发生什么，角色才拥有剧情状态。把三者混在一起，会造成“说得像记得，行动却完全遗忘”。

保存近期主题、用户称呼、稳定偏好和明确承诺，减少重复。不要永久保存全部聊天；用户应能查看、纠正和删除记忆，敏感信息应有更严格边界。

把信任、戒备、亲密或债务显式建模。与其保存“用户是好人”，不如记录“角色亲眼见用户履行承诺，trust +1”，让状态来源可追溯。

剧情状态决定事件是否发生、资源是否仍在、承诺能否撤回和哪些节点可进入。核心状态应由规则管理，不能让生成模型随口改写。

例如用户交出证据：对话层记住讨论，关系层改变双方信任，剧情层记录证据不再持有并关闭“出示证据”。三层共同工作，后果才可信。

读取当前状态，检索本轮必要记忆，生成受角色目标约束的回应，提出候选记忆与状态变化，再由规则校验后写回。模型不应直接读取全部用户数据或自行宣布核心事件成立。

memory: {fact, source, confidence, created_at, expires_at}
relationship: {character_id, dimension, value, reason}
story_state: {event_id, status, evidence, version}

会聊天带来新鲜感，会记得带来关系感，让记忆改变后续机会才带来故事感。

适合长期保存的是稳定偏好、明确承诺、共同经历和用户主动要求记住的事实。一次性情绪、模型对性格的推断、未经确认的敏感信息，不应自动进入长期记忆。

每条记忆包含来源、置信度、时间和过期规则。用户后来明确纠正时，新事实应覆盖或标记冲突，而不是让模型随机选择版本。

角色可以喜欢玩家，却不信任他保守秘密；可以尊重能力，却害怕他的做法。至少把与故事有关的维度分开，例如信任、亲密、戒备和债务。维度不宜过多，每一项都要有明确写入与读取。

状态变化还应有理由。trust +1 必须关联履行承诺或提供证据，而不是因为模型生成了一句友好对白。这样团队才能调试，用户也能理解后果。

记忆本身不会产生故事，节点条件才会。某角色记得玩家救过他，可以在危机中开放援助；记得玩家泄露秘密，则可能拒绝分享线索。读取时还要检查当前事件和立场，避免一条旧记忆永久控制所有场景。

不同角色可以对同一事件拥有不同版本，系统不应为了统一记忆抹去叙事冲突。同一角色的记忆也可能衰减，但关键承诺和剧情事实需要确定保留。遗忘应由产品规则控制，不能依赖上下文窗口偶然丢失。

用户应能查看系统记住了什么、纠正错误、删除不希望保存的内容，并知道删除是否影响剧情状态。对话日志、长期记忆和剧情状态的保留期限可能不同，界面应分别说明。

敏感数据只在完成明确功能所需范围内处理。记忆越多不等于关系越真实，确信地记错反而更伤信任。

测试即时复述、跨会话召回、纠错、删除、冲突事实、过期和剧情读取。还要注入错误候选记忆，确认校验器不会写入；关闭模型服务，确认核心剧情仍能正确运行。

最终验收不是角色能说出多少旧细节，而是它只记住应该记住的内容，在正确时机影响行动，并允许用户拥有可理解的控制。

玩家在第三章拒绝公开同伴的秘密。系统不应保存整段原始对话，而应写入结构化事件：对象、行为“保护秘密”、发生章节、同伴是否知情、可信度和过期条件。后续同伴得知此事时，提高的可能是信任而非亲密；若无人知道，关系不应凭空变化。

删除或更正记忆时，同时处理摘要、向量索引、关系状态和缓存，避免界面显示已删除，角色仍在对白中引用。测试者应能查看系统记住的大类信息、关闭长期记忆，并验证新会话不会继续调用已撤回内容。

上线监控关注错误回忆、过度重复、敏感信息留存和跨角色串线，而不是只统计命中率。一次被正确忘记的信息，可能比十次准确复述更能建立信任。