开发者

三个接口，让你的产品记住用户

写入对话、召回上下文、生成总结。不用自建向量库，不用调抽取与遗忘策略——记忆的脏活我们做完了，你只管把召回结果塞进 prompt。

cURL

curl -X POST "https://ms.seemem.com/api/v2/memory/recall" \
  -H "Authorization: Bearer $SEEMEM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "u_10086",
    "query": "上周聊的那个方案后来定了吗"
  }'

五分钟接入

标准 REST + JSON，任何 HTTP 客户端都能直接调。三步跑通，不需要先读完全部文档。

拿到凭证

在开发者平台注册后进入「租户管理」，添加租户即可拿到租户 ID 与租户 token。租户 token 就是 API Key，请只在服务端持有。

shell

export SEEMEM_TOKEN="你的租户 token"

写入一轮对话

把原始对话原样发过来即可，不需要你先判断哪句值得记。默认异步落库，接口立即返回。

cURL

curl -X POST "https://ms.seemem.com/api/v2/memory/save" \
  -H "Authorization: Bearer $SEEMEM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "u_10086",
    "session_id": "s_20260823_01",
    "occurred_at": "2026-08-23T09:00:00",
    "messages": [
      {"role": "user", "content": "今天开了项目评审，方案 B 通过了",
       "idempotency_key": "s_20260823_01-1"},
      {"role": "assistant", "content": "记下了，方案 B 什么时候开始排期？",
       "idempotency_key": "s_20260823_01-2"}
    ]
  }'

召回并使用

召回是纯读接口，不写会话、不触发抽取。返回的 response 是序列化好的记忆文本。

JSON

{
  "code": 0,
  "msg": "成功",
  "data": {
    "response": "召回记忆文本（已序列化，可直接作为提示词使用）",
    "user_id": "u_10086",
    "medias": []
  }
}

召回结果怎么用

不需要再做切分、排序或去重——服务端已经按相关性挑过一遍。把 response 原样拼进系统提示词，模型就有了这个用户的长期上下文。

基础地址：https://ms.seemem.com/api/v2/memory

Python

# 把 recall 的 response 原样拼进系统提示词即可，
# 不需要再做切分、排序或去重
messages = [
    {"role": "system", "content": f"以下是关于该用户的记忆：\n{recalled}"},
    {"role": "user", "content": user_input},
]

接口能力

接口共用一套租户凭证，路径前缀统一为 /api/v2/memory。记忆网络是唯一例外——它是另一个域名上的网页，鉴权靠服务端算出的签名。

写入与召回

把每一轮对话原样写进来，召回时拿到的是跟当前提问相关的那部分，不是全量历史。

POST/save
POST/recall

记忆总结

按时间、人物或事件生成日报周报月报，可查列表与详情；人物选择器用来拿「按人物总结」的目标。

POST/summary
POST/summary/list
GET/summary/{summary_id}
DELETE/summary/{summary_id}
GET/person/options

检索

图片、语音随消息一起入库后可按描述与标签检索；话题事件按关键词与时间范围翻页查询。

POST/media/search
POST/topic-event/search

记忆修正

一句「我说错了，是周四不是周三」，服务端沿推演链把受影响的碎片与总结一并重算。异步执行，可轮询状态。

POST/corrections
GET/corrections/{correctionId}
POST/corrections/{correctionId}/retry

记忆网络

免登录查看用户完整记忆图谱的网页，可直接打开或嵌进你的产品（如 App 内 webview）。不是 JSON 接口，鉴权靠服务端算出的签名。

GETsee-link.seemem.com/graph

记忆是怎么长出来的

接一个「记忆 API」最该问的问题是：我 save 进去之后，服务端到底做了什么。

写入

把每一轮对话原样 save 进来，可以带图片和语音。不需要你预先判断「这句话值不值得记」——那是服务端的活。

加工

长对话按会话切成段，从中抽出记忆碎片与话题事件。同一件事的多次提及会合并成一条，被后来的说法推翻的内容会退场。

召回

只返回跟这次提问相关的那部分，序列化成一段可以直接进 prompt 的文本，而不是把全部历史丢给模型。

为什么不是「把历史全塞给模型」

全量历史既贵又不准：上下文越长，模型越容易被无关内容带偏，真正相关的那几句反而被稀释。召回只给相关的那一部分，token 成本和回答质量是同一个方向的收益。

时延与预期

记忆是加工出来的，不是写完就能查。接入前先知道各项能力什么时候生效，能省掉大量排查。

能力	生效时间
/recall 召回	写入后数秒至数分钟内生效
/topic-event/search 话题事件	非实时产出，当天写入的对话通常次日可检索
/media/search 媒体检索	媒体入库需短暂处理，写入后稍等片刻再搜
/summary 记忆总结	同步 LLM 调用，耗时数秒偶有重试，客户端超时建议 ≥ 60 秒
/save 且 async_exec=false	可能包含媒体处理与模型调用，客户端超时建议 ≥ 90 秒
/corrections 记忆修正	异步执行，提交后立即返回受理结果，全链路重建在后台跑，轮询查状态

业务错误的 HTTP 状态码大多仍为 200，成败请以响应体里的 code 字段判断，不要只看 HTTP 状态。

计费

按调用量计费

接口调用消耗积分，没有阶梯套餐门槛，也不需要先谈年框。记忆总结这类会真实调用大模型的接口单次成本更高，纯读接口更低。

余额与流水自助可查

开发者平台的「积分中心」能看到余额、冻结、累计收入与消耗，以及每一笔的消费来源明细，支持按收支方向筛选。

查看积分中心批量与私有化询价

常见问题

怎么鉴权？

请求头带 Authorization: Bearer <租户token>。租户 ID 由 token 自动解析注入，不用在请求体里传；但 user_id 每个接口都要显式传 —— POST 放请求体，GET / DELETE 放 query 参数。所有 POST 接口需要 Content-Type: application/json，其他类型会被拒。

user_id 应该填什么？

你自己系统里的用户主键，原样传过来即可，我们不做账号映射、也不需要预先注册。同一个 user_id 下的记忆互通，不同 user_id 之间天然隔离。

数据是怎么隔离的？

租户与 user_id 两层命名空间。租户之间完全不可见，租户内按 user_id 分。租户 token 只携带租户身份，越不过自己的命名空间。

有 SDK 吗？

目前提供 HTTP 接口与各语言的调用示例，官方 SDK 在规划中。接口是标准 REST + JSON，任何 HTTP 客户端都能直接调，接入成本主要在业务侧怎么用召回结果，而不在调用本身。

支持私有化部署吗？

支持。私有化涉及模型、存储与硬件资源的具体配置，方案请联系商务一起评估。

老的 /v1 接口还能用吗？

保留兼容，存量接入不受影响。新接入请用 /v2 —— 认证方式从裸 token 改为 Bearer。两套鉴权不通用（/v1 要裸 token，/v2 必须加 Bearer），不要混着调。

先跑通一次召回
再决定要不要接

注册后建一个租户就能拿到 token，写入一轮对话、召回一次，五分钟能看到效果。需要私有化部署或按场景定制记忆策略，也可以直接找商务聊。

获取 API Key 接口文档