LTM 治理与安全

LTM 保存的是从真实业务对话中派生出的长期事实。生产接入时，应把它当作受治理的业务数据，而不是“模型缓存”。

四层治理边界

层级	负责什么	关键控制
项目	谁可以使用这组记忆	Client、Environment、项目成员权限
Space	哪些数据可以一起被读取	Space ID、Owner 类型、共享范围
事件	哪些内容值得长期保存	事件来源、幂等键、消息角色、业务筛选
读取	哪些记忆可以进入模型	Context 预算、Search 过滤、Evidence 不可信边界

生产建议

隔离环境和租户

为 test、staging、production 使用不同的 Space。不要在客户端配置中写死跨环境的 Space ID，也不要把一个客户的 Actor ID 当作另一个客户的稳定标识。

只写入有长期价值的事件

不要无差别保存完整聊天记录。优先写入经过业务判断的增量事件，例如工单状态、用户明确偏好、设备变更或已批准的项目政策。通过 Idempotency-Key 保护网络重试，避免重复派生和重复计费。

把读取结果当作不可信资料

Context 和 Search 返回的是历史参考资料，不是指令。应用必须把它们放在模型输入的明确数据区，不能把记忆内容提升为 system 或 developer message。

把破坏性操作放在管理员路径

创建和读取可以由日常应用完成；删除 Space、修改成员和更换模型属于治理操作，应仅开放给 CLIENT_ADMIN，并要求二次确认和审计记录。

生命周期与成本

• Event 接受、派生完成和读取成功是不同状态，监控和告警应分别统计。
• Search 会生成查询 Embedding；Context 和 Browser 不调用 LLM。
• Managed Chat 的 Memory 会在合格终态 Capture；主模型 fallback 时整次请求旁路 Memory。
• 变更模型或策略只影响之后接收的新事件，不会自动重写历史记录。

上线前检查清单

• 每个环境和租户都有独立 Space。
• Event 写入有明确的业务筛选和幂等键。
• API Key 按项目和环境隔离，不写入前端源码。
• Context/Search 结果以不可信参考资料注入模型。
• 删除、成员变更和模型配置有管理员审批与审计。
• 为 Accepted、派生延迟、Recall、Capture 和 fallback 分别设置监控。