Library、Scope、Topic、Atom：随 Agent 规模扩展的记忆模型

四个问题，四层结构

• Library — 哪个隔离记忆库？传 memoryLibraryId；引擎绑定 libraryKey（library-{uuid}）。 • Scope — 哪个领域？计费、基础设施、法务、产品路线图。 • Topic — 领域内哪个主题？Q2 续约、VPC 迁移、API 限流。 • Atom — 可检索、可引用的原子事实或叙事。

接入 REST 或 MCP 前请先阅读 概念指南 中的完整术语。

层级为何优于纯标签

扁平标签会腐烂。团队不断加 customer-id、project-id、随意标签——检索变成「全库搜一把」。层级提供可预期过滤：在 Topic 内 recall、在 Scope 内 search，Library 之间绝不泄漏。

多租户 SaaS Agent 应将每个终端客户映射到 Scope（或 Topic）边界，避免 A 用户的 Atom 出现在 B 用户会话中。

Atom 是检索单元

Atom 不是 chunk。它是刻意设计的记忆单元——通常一项决策、一条偏好、一步流程——可选附件存对象存储并建立语义索引。

通过 POST /api/v1/memory/atoms 或 memory_save_atom 创建 Atom 时务必填写层级字段。检索质量取决于元数据，不亚于 embedding 文本。

路径回链

Atom 可链接相关 Atom——支撑证据、被取代的决策、上游政策。唤醒与 recall 沿路径遍历，Agent 看到的是上下文链，而非孤立片段。

入门步骤

在第一个记忆库中建模一个 Library 与两个 Scope，保存十条带清晰 Topic 的 Atom。在 Cursor 中运行 memory_wake_up 与 memory_search 验证检索，再扩大入库规模。