数据截至 (上游 commit 149589ae7e6b)
数据与心智模型:文档 / 记忆 / 画像 / 空间
30 秒导读: 本章确立 Supermemory 全书的词汇表和 API 边界。你会先分清四个核心名词——文档 / 记忆 / 画像 / 空间——分别是什么、字段长什么样;再看它们如何被一层叫
SupermemoryClient的"HTTP 门面"暴露成 9 个方法。后面每一章(MCP 服务器、中间件、Memory Tool、图可视化)都建立在这套词汇之上。
本章只讲**"数据是什么、API 长什么样"。它不讲** MCP 工具怎么注册(见 02)、不讲框架中间件(见 03)、不讲图怎么渲染(见 05)。
上游重构提示: MCP 侧的
src/client.ts已拆成src/server/client/index.ts(门面类)与src/shared/types.ts(Zod/TS 类型)两处,本章引用已随迁;「project(项目)」在产品语义上已改称 「space(空间)」(同一个 containerTag 概念,工具面叫listSpaces);旧x-sm-project请求头 与getProjects方法已移除,换成listContainerTags+ 活跃空间 DO(见 §5)。
1. 先建立心智模型:四个名词
Supermemory 的对外数据只有四类东西。先用一句话各自点破,再逐个深入。
| 名词 | 白话 | 一句话 |
|---|---|---|
| document(文档) | 你喂进去的原始内容 | 一篇 PDF / 网页 / 一段文本,进来后被处理成可检索的东西 |
| memory entry(记忆) | 从文档里抽取出的一条事实 | "用户偏好 TypeScript"——是文档的产物,不是文档本身 |
| profile(画像) | 把记忆聚合成的用户速写 | 两串字符串:稳定偏好 + 近期活动 |
| space(空间) | 一个隔离的记忆分区 | 用 container tag 圈起来,A 空间看不到 B 空间 |
一句话直觉: 把 document 当"原始档案"、memory 当"从档案里划出来的重点句"。你存的是档案,但 AI 助手日常检索、拼进上下文的,是那些重点句。
三者是包含关系——一个文档"生出"多条记忆:
document(原始内容)
└── memoryEntries: [
memory entry #1 ← 从内容抽出的一条事实
memory entry #2
memory entry #3
]
这个包含关系在类型里是直接写死的:DocumentWithMemories 接口就带一个
memoryEntries: DocumentMemoryEntry[] 字段(apps/mcp/src/shared/types.ts:94-104,
documentWithMemoriesSchema)。
2. 数据的三层形态
上面的四个名词里,document 和 memory 之间还有更细的层次。理解这三层,是读懂后面所有 API 返回值的前提。
2.1 三层是什么
第 1 层 document 一份原始内容(有 title / summary / type)
│
│ 处理管线抽取
▼
第 2 层 memory entry 一条事实(有 version / parentMemoryId / isLatest …)
│
│ 被检索时命中
▼
第 3 层 chunk / result 搜索时返回的片段(memory 或 chunk 二选一)
- document = 原始内容的容器,本身不参与相似度检索,只作为"这条记忆从哪来"的出处。
- memory entry = 真正被 AI 用的知识单元,带版本链(见 §3)。
- 搜索结果(
Memory) = 检索时命中的东西,可能是一条完整记忆(memory字段),也可能是文档的一个切片(chunk字段)——二者互斥。
2.2 搜索结果为什么是"联合类型"
Memory 类型是一个 union(联合类型):要么带 memory 字段,要么带 chunk 字段,不会同时有。
// apps/mcp/src/server/client/index.ts:45-59 type Memory
export type Memory =
| { id; memory: string; similarity; title?; content? } // 命中一条记忆
| { id; chunk: string; similarity; title?; content? } // 命中一个文档切片
代码里到处用 "memory" in m 来区分这两支。取文本的辅助函数就是这么写的:
// apps/mcp/src/server/client/index.ts:77-79 getMemoryText
export function getMemoryText(m: Memory): string {
return "memory" in m ? m.memory : m.chunk
}
为什么重要: 后面 forgetMemory 的语义匹配里,有一句"只有真记忆能被遗忘、chunk 不能"——靠的正是这个 "memory" in r 判别(apps/mcp/src/server/client/index.ts:213,
searchResult.results.find((r) => "memory" in r))。
顺带一提:SDK 原始结果先经 mapSdkResults(apps/mcp/src/server/client/index.ts:95-114)做
Zod 校验 + 归一——content || memory || chunk || context 依次取文本,再决定标成
memory 还是 chunk。这是把松散的上游响应收进严格联合类型的闸门。
2.3 关键字段速查
搜索结果里每条记忆的字段(apps/mcp/src/server/client/index.ts:45-65,Memory + SearchResult):
| 字段 | 含义 |
|---|---|
id | 记忆/切片的唯一 ID |
memory 或 chunk | 文本内容(二选一) |
similarity | 与查询的相似度分数 |
title / content | 标题 / 原文(可选) |
total / timing | 所在 SearchResult 的总数与耗时 |
一个安全细节: 文本在映射时被
limitByChars截断到MAX_CHARS = 200000(约 5 万 token), 超长补...(apps/mcp/src/server/client/index.ts:81-83与:100,limitByChars)。这是防止 一条巨型文档撑爆调用方上下文窗口的护栏。
3. 记忆的版本链(memory 最独特的地方)
这是 Supermemory 区别于普通向量库的核心:记忆不是一次写死,而是带版本、能被新版本取代、能被"遗忘"。
3.1 要解决的问题
用户的偏好会变。今天"喜欢 React",下个月"改用 Next.js"。普通向量库只会堆两条互相矛盾的记录;Supermemory 用一条版本链把它们串起来,并标记谁是最新。
memory v1 "偏好 Vue" isLatest=false
│ parentMemoryId 指向上一版
▼
memory v2 "偏好 React" isLatest=false
│
▼
memory v3 "偏好 React + TS" isLatest=true ← 默认只返回这一条
(版本演化示意,事实佐证见 skills/supermemory/references/architecture.md 的 "Memory Versioning" 一节——该文件作为被研究的数据引用。)
3.2 版本链字段(核对源码)
MCP 侧的记忆条目类型 DocumentMemoryEntry 把版本链字段全列了出来
(apps/mcp/src/shared/types.ts:75-92,documentMemoryEntrySchema):
| 字段 | 类型 | 作用 |
|---|---|---|
version | number | 第几版 |
parentMemoryId | string | null | 指向上一版(链的"前驱指针") |
rootMemoryId | string | null | 指向链的源头(第一版) |
isLatest | boolean | 是否为当前最新版 |
isForgotten | boolean | 是否已被遗忘 |
isStatic | boolean | 是稳定事实还是动态信息(见 §4) |
forgetAfter / forgetReason | string | null | 定时遗忘的时间点 / 遗忘原因 |
spaceId | string | 所属空间 |
客户端侧还有一套含完整历史的 MemoryEntry(内嵌 history: MemoryEntryHistory[],
已挪到 apps/mcp/src/shared/types.ts:139-154,client 门面在 index.ts:42 转出口),listMemoryEntries 一次就能带回一条记忆的
整条版本链(:396-429)。
3.3 图可视化侧的同一套字段 + 关系边
图渲染包 memory-graph 用的 GraphApiMemory 是几乎同构的一套字段,额外多了"记忆之间怎么连"的关系边信息(packages/memory-graph/src/types.ts:5-27,GraphApiMemory):
// packages/memory-graph/src/types.ts:5-24 GraphApiMemory(节选)
export interface GraphApiMemory {
version: number
parentMemoryId: string | null
rootMemoryId: string | null
isLatest: boolean
isForgotten: boolean
spaceId: string
relation?: MemoryRelation | null // 这条记忆和别人的关系
memoryRelations?: Record<string, MemoryRelation> | null
nextVersionId?: string | null // 版本链的"后继指针"
// …
}
关系类型 MemoryRelation 只有三种取值(packages/memory-graph/src/api-types.ts,type MemoryRelation):
| edgeType | 白话 | 例子 |
|---|---|---|
updates | 新版取代旧版 | "偏好 React 18" 取代 "偏好 React 17" |
extends | 补充、丰富 | "完成了 TS 进阶课" 丰富 "喜欢 TS" |
derives | 推断出的新联系 | 从"每天读 ML 论文"推出"是 ML 工程师" |
一条边就是 { source, target, edgeType }(packages/memory-graph/src/types.ts:39-43,GraphApiEdge)。
边界提醒: 版本链字段在本章讲透即可;这些字段怎么被画成力导向图上的连线是 05-memory-graph.md 的事,本章不展开。
3.4 两处文档类型的差异(别混淆)
仓库里有两个"文档含记忆"类型,字 段名略有不同,别搞混:
| 来源文件 | 记忆数组字段名 | 文档类型字段名 |
|---|---|---|
apps/mcp/src/shared/types.ts:94 | memoryEntries | type |
packages/memory-graph/src/api-types.ts | memories | documentType |
前者是 MCP 门面的形状,后者是图渲染的形状。它们描述同一个概念,只是各自适配自己那层的消费方。
4. 用户画像:static + dynamic 两串字符串
画像是把散落的记忆聚合成的"用户速写"。它的数据结构极简——就是两个字符串数组。
4.1 结构
// apps/mcp/src/server/client/index.ts:67-75
export interface Profile {
static: string[] // 稳定偏好:名字、职业、长期习惯
dynamic: string[] // 近期活动:最近在做什么、刚问过什么
}
export interface ProfileResponse {
profile: Profile
searchResults?: SearchResult // 可选:附带与 query 相关的检索结果
}
- static ← 从
isStatic: true的记忆聚合(稳定、高优先级)。 - dynamic ← 从近期记忆聚合(时效性、会被更新)。
这两条线正好对应 §3.2 里记忆条目上的 isStatic 字段——画像不过是把记忆按这个标志分成两堆。
4.2 一次调用就拿到
不需要自己拉记忆再聚合;getProfile 一次调用直接返回成品(apps/mcp/src/server/client/index.ts:267-302,getProfile):
// apps/mcp/src/server/client/index.ts:267-281(节选)
async getProfile(query?: string): Promise<ProfileResponse> {
if (!this.hasExplicitContainerTag) {
return { profile: { static: [], dynamic: [] } } // 默认空间不出画像
}
const result = await this.client.profile({
containerTag: this.containerTag, // 限定在当前空间
q: query, // 可选:同时做一次相关检索
})
// …映射 static/dynamic,若传了 q 还带回 searchResults
}
两个要点: ① 传了 query 就顺带返回 searchResults(画像 + 相关记忆一次性给你);② 一个
诚实的边界——没有显式 containerTag(即用默认空间)时直接返回空画像(:268-275):
画像是有空间属性的,默认空间不聚合。
5. 空间(container tag):记忆的隔离墙
同一个 Supermemory 后端要服务很多用户、很多组织、很多上下文。container tag 就是把它们隔开的机制。产品语言里现在叫 space(空间),MCP 工具面用 listSpaces 列的就是它。
5.1 概念
一个 container tag = 一个独立空间。不同 tag 之间的记忆互相不可见。
container tag = "user_123" container tag = "org_acme"
┌───────────────────────┐ ┌──────────────── ───────┐
│ 记忆:偏好深色模式 │ │ 记忆:使用 AWS │
│ 记忆:使用 TypeScript │ ✗ │ 记忆:50 名员工 │
└───────────────────────┘ 互不 └───────────────────────┘
可见
好处:隐私隔离、多租户、把个人 / 工作 / 某个项目的上下文分开。(隔离语义佐证见 skills/supermemory/references/architecture.md 的 "Container Tag Isolation" 一节,作为数据引用。)
5.2 客户端怎么锁定 tag
SupermemoryClient 在构造时就把 container tag 定死;没传就用默认值 sm_project_default
(apps/mcp/src/server/client/index.ts:21 与 :155-156):
// apps/mcp/src/server/client/index.ts:145-157(节选)
constructor(bearerToken, containerTag?, apiUrl = "https://api.supermemory.ai") {
this.hasExplicitContainerTag = Boolean(containerTag)
this.containerTag = containerTag || DEFAULT_PROJECT_ID // "sm_project_default"
}
之后 createMemory / forgetMemory / getProfile 等调用都会自动带上 this.containerTag;
search 稍特殊——只有显式传过 tag 才带,否则不带让后端自行全空间检索
(apps/mcp/src/server/client/index.ts:246-248)。
5.3 tag 从哪来:显式参数 → 活跃空间 → 默认
旧版的
x-sm-project请求头(连接级钉死项目)与getProjects方法已移除。
现在的解析链在 MCP 服务器侧(apps/mcp/src/server/server.ts:70-73 的
resolveContainerTag,详见 02 §6.3):
工具参数里的 containerTag(显式,只影响本次调用)
▼ 没传
SpaceState DO 里的活跃空间(set-active-tag 持久化的用户选择)
▼ 没有
DEFAULT_PROJECT_ID = "sm_project_default"(客户端兜底)
一句话链路:
显式参数 / 活跃空间 DO / 默认 → new SupermemoryClient(…, tag) → 每次 API 调用都带 tag
空间的元信息(名字、emoji、描述、文档/记忆计数)由 listContainerTags 提供
(GET /v3/container-tags/list,apps/mcp/src/server/client/index.ts:304-330),
返回的是 ContainerTag 对象数组(apps/mcp/src/shared/types.ts:39-55)——不再是旧版的裸字符串列表。
6. 搜索:固定 hybrid 模式
检索是所有"记忆型 AI"的核心动作。
旧版
SearchOptions(searchMode/rerank/rewriteQuery/include 可调)已移除; MCP 侧现在把检索收敛成固定形态。
search 方法(apps/mcp/src/server/client/index.ts:239-265)的签名是
(query, limit = 10, threshold?, containerTagOverride?),内部固定:
// apps/mcp/src/server/client/index.ts:249-255(节选)
const result = await this.client.search.memories({
q: query,
limit,
...(containerTag ? { containerTag } : {}), // 只有显式 tag 才带
searchMode: "hybrid", // ← 固定 hybrid
threshold,
})
hybrid 的含义: 同时在"记忆层"和"文档层"检索,所以返回的 Memory[] 里会混着
memory 结果和 chunk 结果——这正是 §2.2 那个联合类型存在的原因。threshold 主要供
forgetMemory 的语义兜底复用(§7.2);需要不同模式的调用方走 SDK 直连(见 index 路径③)。
7. SupermemoryClient:引擎的 HTTP 门面
前面所有数据形态,最终都通过一个类对外暴露:SupermemoryClient。它是"记忆引擎"的HTTP 门面(facade)——把底层 SDK 和裸 fetch 包成 9 个语义清晰的方法。
7.1 全景:9 个方法打到哪
SupermemoryClient(apps/mcp/src/server/client/index.ts:135-492)
│
├── createMemory ──► SDK client.add ─┐
├── forgetMemory ──► SDK memories.forget ├─ 走 supermemory SDK(baseURL=apiUrl)
├── search ──► SDK search.memories │ (统一 x-sm-source 头)
├── getProfile ──► SDK client.profile │
├── listDocuments ──► SDK documents.list │
├── getDocument ──► SDK documents.get ─┘
│
├── listContainerTags ──► fetch GET /v3/container-tags/list ─┐
├── getDocuments ──► fetch POST /v3/documents/documents ├─ 裸 fetch
└── listMemoryEntries──► fetch POST /v4/memories/list ─┘
有意思的分工:六个走官方 SDK,三个走裸 fetch。SDK 方法由 supermemory 包封装;
空间列表、按 tag 拉文档、按版本链拉记忆这三个是直接 fetch 到 /v3、/v4 端点的。
7.2 逐方法速查
| 方法 | 底层调用 | HTTP 端点 | 关键行为 | 返回 |
|---|---|---|---|---|
createMemory | client.add | (SDK 内部,佐证为 POST /v3/documents) | metadata.sm_source = "supermemory-mcp" | { id, status:"queued", containerTag } |
forgetMemory | memories.forget | (SDK 内部) | 精确→404 语义兜底(0.85)→只删真 memory | { success, message, containerTag } |
search | search.memories | (SDK 内部,佐证为 /v4/search) | 固定 hybrid;显式 tag 才带 | SearchResult |
getProfile | client.profile | (SDK 内部) | 默认空间返回空画像 | ProfileResponse |
listDocuments | documents.list | (SDK 内部) | 分页列文档摘要(includeContent: false) | { documents, pagination } |
getDocument | documents.get | (SDK 内部) | 单文档详情 | DocumentDetails |
listContainerTags | 裸 fetch | GET /v3/container-tags/list | Zod 校验 ContainerTag[] | ContainerTag[] |
getDocuments | 裸 fetch | POST /v3/documents/documents | 默认一页 200 条,连带 memoryEntries | DocumentsApiResponse |
listMemoryEntries | 裸 fetch | POST /v4/memories/list | 记忆条目含 history 版本链 | MemoryEntriesResponse |
标 (SDK 内部) 的端点在源码里看不到具体路径——它们被
supermemorynpm 包封装了。/v3/documents、/v4/search这两个具体路径来自skills/supermemory/references/architecture.md的 "Data Flow" 图(作为数据佐证,非本仓源码直述,故标 (inferred))。裸fetch的三个端点 则是源码里写死的字符串,可直接核对(apps/mcp/src/server/client/index.ts:307、:340、:401)。
7.3 请求 / 响应长什么样
createMemory —— 存一条记忆,立即返回队列态(apps/mcp/src/server/client/index.ts:159-177):
// 请求
await this.client.add({
content,
containerTag: this.containerTag,
metadata: { sm_source: "supermemory-mcp" }, // 标记来源
})
// 响应
{ id: "…", status: "queued", containerTag: "…" }
注意 status 恒为 "queued"——写入是异步的,方法返回时内容还在处理管线里(extract → chunk → embed → index),并未就绪。
getDocuments —— 分页拉文档(连带其记忆条目)(apps/mcp/src/server/client/index.ts:332-366):
// 请求体
{ page: 1, limit: 200, sort: "createdAt", order: "desc", containerTags }
// 响应
{
documents: DocumentWithMemories[], // 每个含 memoryEntries[]
pagination: { currentPage, limit, totalItems, totalPages }
}
响应形状就是 §1 那个"文档包含记忆"的结构,再加分页信息(DocumentsApiResponse,
apps/mcp/src/shared/types.ts:113-118)。memory-graph 工具一次拉 200 条就是走它。
7.4 错误处理:两层收敛
每个方法的 catch 都调 handleOperationError(operation, error)(apps/mcp/src/server/client/index.ts:481-491)——它先让 handleError 归一化,再包上 "Create memory request failed: …" 这类操作前缀。handleError(:431-479)把各种失败归一化成给终端用户看的人话,只抛不返:
| 触发条件 | 抛出的消息(节选) |
|---|---|
AbortError / TimeoutError | "Request to Supermemory API timed out" |
TypeError 且含 "fetch"/"network" | "Network error. Please check your connection." |
| HTTP 400/422 | 上游 JSON 里的 error/message,兜底 "Invalid request…" |
| HTTP 401 | "Authentication failed. Please re-authenticate." |
| HTTP 402 | "Memory limit reached. Upgrade at supermemory.ai" |
| HTTP 403 | "Access forbidden. This connection may be read-only or scoped to specific spaces…" |
| HTTP 404 / 429 / ≥500 | "Not found." / "Rate limit exceeded…" / "Server error…" |
一处新细节:裸 fetch 的响应体会先过 extractApiErrorMessage(:124-133)解出
{"error": …} JSON 里的真实原因,再进状态码分支——用户看到的是上游的真实错误而不是笼统话术。
一个诚实的更正: 本方法是**抛异常(throw-based)**风格,handleError 的返回类型就是 never,
内部全是 throw new Error(...)(apps/mcp/src/server/client/index.ts:431)。代码里看不出任何
neverthrow 的使用。
forgetMemory 里有一处局部的容错逻辑值得一提:它先试精确内容匹配,若 SDK 抛的是 404
就吞掉、转而走语义搜索兜底(阈值 0.85,只删 memory 不删 chunk),否则原样重抛
(apps/mcp/src/server/client/index.ts:178-237)。这是"删记忆"这个动作特有的降级链,不是全局的错误模型。
8. 巧妙之处(可带走的设计)
- 文档 / 记忆分层。 存的是文档,用的是记忆——检索命中的最小单元是"事实"而非"整篇",既省上下文又可溯源(
apps/mcp/src/shared/types.ts:94-104)。 - 版本链而非覆盖。 用
parentMemoryId+isLatest把"偏好变了"表达成一条链,默认只回最新版,需要时可回溯历史(apps/mcp/src/shared/types.ts:75-92)。 - 画像即两串字符串。 复杂的聚合逻辑藏在后端,对外只暴露
static[]+dynamic[],一次调用即得;默认空间干脆不出画像,避免"无空间属性的用户速写"这种脏数据(apps/mcp/src/server/client/index.ts:268-275)。 - 构造即绑定空间。 container tag 在
new SupermemoryClient时锁定,之后每次调用自动携带;search 特例(无显式 tag 不带)显式区分"我只要这个空间"和"让后端全查"(apps/mcp/src/server/client/index.ts:135-157、:246-248)。 - SDK 结果进门先过 Zod。
mapSdkResults把松散的上游响应校验+归一 成严格联合类型,类型谎言进不了门面(apps/mcp/src/server/client/index.ts:95-114)。 - 200k 字符护栏。 映射时统一截断,防止单条巨型内容撑爆下游上下文(
apps/mcp/src/server/client/index.ts:81-83)。
9. 边界与本章不覆盖的
- SDK 端点不透明。 createMemory/forgetMemory/search/getProfile/listDocuments/getDocument 的确切 HTTP 路径封装在
supermemorynpm 包内,本仓源码看不到;§7.2 里标 (inferred) 的路径来自architecture.md(数据佐证),非源码直述。 - 写入是异步的。 createMemory 返回
"queued"即结束,内容尚未可检索;处理管线(extract/chunk/embed/index)的细节不在本仓 MCP 代码里。 - 检索形态固定。 MCP 门面只剩 hybrid 一种模式、
limit/threshold两个旋钮;要 rerank/include 等能力需直连 SDK。 - 本章不讲: MCP 工具注册与 schema(→ 02)、框架中间件
withSupermemory(→ 03)、Claude Memory Tool 桥接(→ 04)、版本链/关系边的图渲染(→ 05)。
10. 代码地图(导航索引)
| 主题 | 文件路径 | 符号名 |
|---|---|---|
| 搜索结果联合类型 | apps/mcp/src/server/client/index.ts:45 | Memory |
| SDK 结果 Zod 校验/归一 | apps/mcp/src/server/client/index.ts:95 | mapSdkResults |
| 取结果文本 | apps/mcp/src/server/client/index.ts:77 | getMemoryText |
| 搜索结果封装 | apps/mcp/src/server/client/index.ts:61 | SearchResult |
| 画像结构 | apps/mcp/src/server/client/index.ts:67 | Profile / ProfileResponse |
| 记忆条目(带版本链,schema) | apps/mcp/src/shared/types.ts:75 | documentMemoryEntrySchema / DocumentMemoryEntry |
| 记忆条目(含 history,客户端) | apps/mcp/src/shared/types.ts:139 | memoryEntrySchema / MemoryEntry |
| 文档含记忆 | apps/mcp/src/shared/types.ts:94 | documentWithMemoriesSchema / DocumentWithMemories |
| 文档 API 响应 | apps/mcp/src/shared/types.ts:113 | documentsApiResponseSchema |
| 空间元信息 | apps/mcp/src/shared/types.ts:39 | containerTagSchema / ContainerTag |
| HTTP 门面类 | apps/mcp/src/server/client/index.ts:135 | SupermemoryClient |
| 存记忆 | apps/mcp/src/server/client/index.ts:159 | SupermemoryClient.createMemory |
| 遗忘记忆(带语义兜底) | apps/mcp/src/server/client/index.ts:178 | SupermemoryClient.forgetMemory |
| 搜索(固定 hybrid) | apps/mcp/src/server/client/index.ts:239 | SupermemoryClient.search |
| 取画像 | apps/mcp/src/server/client/index.ts:267 | SupermemoryClient.getProfile |
| 列空间 | apps/mcp/src/server/client/index.ts:304 | SupermemoryClient.listContainerTags |
| 按空间拉文档 | apps/mcp/src/server/client/index.ts:332 | SupermemoryClient.getDocuments |
| 列文档(SDK) | apps/mcp/src/server/client/index.ts:368 | SupermemoryClient.listDocuments |
| 单文档(SDK) | apps/mcp/src/server/client/index.ts:388 | SupermemoryClient.getDocument |
| 记忆条目+版本链 | apps/mcp/src/server/client/index.ts:396 | SupermemoryClient.listMemoryEntries |
| 错误归一化 | apps/mcp/src/server/client/index.ts:431 | SupermemoryClient.handleError |
| 操作前缀包装 | apps/mcp/src/server/client/index.ts:481 | SupermemoryClient.handleOperationError |
| 上游错误解包 | apps/mcp/src/server/client/index.ts:124 | extractApiErrorMessage |
| 字符截断护栏 | apps/mcp/src/server/client/index.ts:81 | limitByChars / MAX_CHARS |
| 默认空间常量 | apps/mcp/src/server/client/index.ts:21 | DEFAULT_PROJECT_ID |
| 图侧记忆类型(含关 系边) | packages/memory-graph/src/types.ts:5 | GraphApiMemory / GraphApiEdge |
| 图侧文档类型 | packages/memory-graph/src/api-types.ts | GraphApiDocument |
| 关系类型三取值 | packages/memory-graph/src/api-types.ts | MemoryRelation |
| 空间解析优先级 | apps/mcp/src/server/space.ts:11 | resolveContainerTag |
| 客户端构造绑定 tag | apps/mcp/src/server/server.ts:67 | getClient(new SupermemoryClient(…)) |