权威状态与派生索引

先分配真相，再选择引擎

Task处于什么状态、用户拥有什么权限、文档哪一版有效，与某段文字向量最接近谁，是不同问题。事务数据库适合维护业务权威状态，对象存储保存原件和长产物，检索引擎保存可重建的倒排与向量索引；模型上下文则是一次调用的临时投影。

这一划分是建议架构，不要求为每个角色部署独立产品。一个托管PostgreSQL可以同时保存状态、元数据和向量；随着工作负载变化再独立检索服务。重要的是知道丢失或冲突时，以哪一份记录为准，能否从原始证据重建派生物。

显式定义一致性

把状态和向量放在同库可减少跨库同步，但不免除版本、索引和授权问题。使用独立服务时，数据库事务与索引更新通常不能天然原子提交。AWS的outbox模式是维持业务变更与事件发布一致的一种方法，应用还需追踪消费进度和索引generation。

建议为每类数据写出owner、更新权限、恢复来源、允许延迟、保留期和删除路径。原始消息与记忆抽取结果分开，执行checkpoint与自然语言摘要分开，正式制度与模型经验分开。只有这样，模型或框架替换时才能迁移显式合同，而非依赖隐藏状态。

用故障判断架构是否成立

可以故意丢弃检索索引并重建，确认不会丢失唯一原件或任务结果；让索引落后权威库，确认已撤回资料不能继续读取；恢复旧备份，确认新的tombstone和权限变更会重新应用。

如果某条“派生”摘要已成为唯一事实来源，或者缓存故障导致审批状态消失，说明角色边界已经被破坏。验收应报告恢复时间、资料新鲜度与丢失窗口，而不是只证明平时读写接口返回成功。