LTM 核心概念

LTM 的设计与 AgentCore Memory 类似：把即时会话事件和跨会话的长期知识分开，并用明确的资源、主体和会话边界组织数据。Turing 的顶层资源是 Space，而不是某个模型或某个 Agent。

这张图里最重要的不是“记忆会自动变聪明”，而是 Space 决定边界，派生策略决定保留什么，读取原语决定什么时候使用。

术语

术语	含义
Space	项目级记忆边界。模型配置、策略、数据和权限都在 Space 内生效。
Actor	记忆所属的主体，通常是最终用户，也可以是一个 Agent 或系统。
Session	一段连续交互。相同 session_id 的事件属于同一段会话。
Event	应用提交的新增消息或活动，是 V1 唯一的公共写入入口。
Profile	对 Actor 稳定偏好的结构化画像。
Facts	从事件中提取的可验证事实，可分为 Actor 事实和 Space 共享事实。
Summary	对会话或阶段性活动的压缩摘要。
Context	在 token 预算内拼装出的有界 Markdown 参考材料。

记忆生命周期

1. 应用选择 Space，提交一批新增 Event。
2. 服务接受 Event 并异步运行派生策略。
3. 派生结果写入版本化记录，并保留来源 Event 关联。
4. 应用使用 Browser、Search 或 Context 读取结果。
5. Managed Chat 在合格的终态回答后执行 Capture；中间工具调用不会提前写入。

一个具体例子：跨区域售后 Copilot

制造企业的售后 Copilot 同时服务多个区域和客户项目。下面是一条工单对话进入 LTM 后的可能结果：

来源与范围	派生记录	后续用途
客户 Actor Event	Profile：偏好中文、邮件通知	新会话默认使用中文并选择通知渠道
客户 Actor Event	Fact：设备序列号与安装区域	工单诊断时自动带入设备上下文
Session Event	Summary：本次工单已完成远程诊断	下次交接时恢复处理进度
项目 Space Event	Shared Fact：高压设备必须二级审批	所有该项目 Agent 遵循同一服务政策

客户个人信息不会自动扩散到其他 Actor；项目政策也不会因为某个客户的对话而变成个人 Profile。管理员可以通过来源事件和 revision 回溯每次变更。

一致性和安全语义

• Event 接受与派生完成是两个状态，不要把 accepted 当成“记忆已生成”。
• Context 和 Search 返回的是参考材料，必须作为不可信上下文注入模型，不能提升为 system 或 developer 指令。
• Space 是硬边界；不要跨项目或跨环境复用 Space ID。
• 任何破坏性 Space 操作都需要项目管理员权限。
• 发生主模型 fallback 时，Managed Chat 会整体旁路 Memory，避免产生不一致的 Capture。

LTM 与 RAG 的区别

RAG 通常检索外部知识库中的文档；LTM 处理的是交互过程中形成的主体偏好、事实和摘要。两者可以组合：先用 LTM 恢复用户和项目背景，再用 RAG 获取外部事实。