项目简介
Supermemory 是面向 AI 的记忆与上下文引擎。它从对话中提取事实，构建用户画像，并提供混合搜索（RAG）。既适用于开发者集成 API，也适合终端用户使用应用。
README 预览
\n \n \n \n \n \n\n\n\n State-of-the-art memory and context engine for AI. And yes - you can use it as a company/personal brain.\n\n\n\n Docs ·\n Quickstart ·\n Dashboard ·\n Discord\n\n\n\n \n \n \n\n\n---\n\nSupermemory is the memory and context layer for AI. **#1 on [LongMemEval](https://github.com/xiaowu0162/LongMemEval), [LoCoMo](https://github.com/snap-research/locomo), and [ConvoMem](https://github.com/Salesforce/ConvoMem)** — the three major benchmarks for AI memory. \n\nWe are a research lab building the engine, plugins and tools around it.\n\nYour AI forgets everything between conversations. Supermemory fixes that.\n\nIt automatically learns from conversations, extracts facts, builds user profiles, handles knowledge updates and contradictions, forgets expired information, and delivers the right context at the right time. Full RAG, connectors, file processing — the entire context stack, one system.\n\n| | |\n|---|---|\n| 🧠 **Memory** | Extracts facts from conversations. Handles temporal changes, contradictions, and automatic forgetting. |\n| 👤 **User Profiles** | Auto-maintained user context — stable facts + recent activity. One call, ~50ms. |\n| 🔍 **Hybrid Search** | RAG + Memory in a single query. Knowledge base docs and personalized context together. |\n| 🔌 **Connectors** | Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks. |\n| 📄 **Multi-modal Extractors** | PDFs, images (OCR), videos (transcription), code (AST-aware chunking). Upload and it works. |\n\nAll of this is in our single memory structure and ontology. \n\n\n\n\n---\n\n## Use Supermemory\n\n\n\n\n\n🧑💻 I use AI tools\n\nBuild your own personal supermemory by using our app. Builds **persistent memory graph across every conversation**.\n\nYour AI remembers your preferences, projects, past discussions — and gets smarter over time.\n\n**[→ Jump to User setup](#give-your-ai-memory)**\n\n\n\n\n🔧 I'm building AI products\n\nAdd memory, RA
常见问题 (4)
故障排除为什么在使用 AI SDK 6 时，withSupermemory 会抛出 AI_UnsupportedModelVersionError？
withSupermemory 函数使用 object spread 来包装语言模型，但 AI SDK 6 模型存储了 non-enumerable/prototype 属性，例如 specificationVersion、provider、modelId 和 supportedUrls。Spread 不会复制这些属性，导致产生 undefined 值，从而触发错误。修复方法：将 wrapVercelLanguageModel（packages/tools/src/vercel/index.ts）中的 spread 模式替换为来自 'ai' 的标准 wrapLanguageModel middleware 方法（import { wrapLanguageModel, LanguageModelV3Middleware } from 'ai'）。作为临时解决方法，在库更新之前，手动使用 wrapLanguageModel 实现一个 wrapper。受影响的版本：@supermemory/tools@1.4.1, ai@6.0.158, @ai-sdk/provider@3.0.8。
故障排除如何修复在为浏览器或 edge 运行时打包 supermemory SDK v5 时出现的 esbuild "Could not resolve fs/stream" 错误？
**原因：** 自 supermemory v5.0.0-rc.6 起（从 Speakeasy 切换到 Fern codegen），生成的核心代码中包含字面量动态导入——generated/core/file/file.js 中的 await import("fs") 和 generated/core/form-data-utils/FormDataWrapper.js 中的 await import("stream")。像 esbuild 这样的打包器会在构建时解析字面量的 import() 说明符，即使该代码路径从未执行，因此任何浏览器/边缘环境的打包（Cloudflare Workers、Vercel Edge、Convex 默认运行时、Vite/esbuild）都会失败，报错 Could not resolve "fs" / Could not resolve "stream"，即使你从未上传文件。
**变通方法：**
1. 固定到最后一个可正常打包的版本：npm i supermemory@5.0.0-rc.5（Speakeasy 生成的构建可以正常打包）。
2. **Convex：** 在每个导入该 SDK 的模块文件顶部添加 'use node' 指令，将这些模块移到 Convex 的 Node 运行时中，因为默认的 Convex 运行时无法使用 Node API。
3. **对于 SDK 维护者 / 本地补丁：** 应用一个生成后补丁（例如在 scripts/generate.ts 中），将字面量说明符替换为计算生成的说明符，使 esbuild 将其保留为运行时导入：用 import(["f","s"].join("")) 替代 import("fs")（注意：const s = "fs"; import(s) 和 /* @vite-ignore */ 注释都**不起作用**——esbuild 在启用 --minify-syntax 时会内联常量并仍然解析它们）。添加 /* webpackIgnore: true */ 以同时覆盖 webpack。Node 在运行时仍能解析这种计算形式，因此上传功能在 Node 中仍可正常工作。
4. 添加一个 CI 检查，针对浏览器目标打包构建产物（esbuild entry.js --bundle --platform=browser --format=esm），并在出现解析错误时使检查失败，以防止回归。
故障排除为什么 Supermemory SDK 的 client.fetch() 抛出 "Failed to parse URL" 错误，或返回 401 且缺少 Authorization 请求头？
这是一个已知的 bug（v5.0.1）：client.fetch() 透传会忽略默认环境。与类型化方法不同，它不会回退到 SupermemoryEnvironment.Default，因此相对路径没有可用于拼接的 base URL（抛出 Failed to parse URL），而绝对 URL 会跳过附加 Authorization 请求头的身份验证检查，从而导致 401 错误。临时解决方法：在创建客户端时显式传入 base URL：
import { Supermemory } from "supermemory"
import { SupermemoryEnvironment } from "supermemory/environments"
const client = new Supermemory({
apiKey: "sm_test",
baseUrl: SupermemoryEnvironment.Default, // or "https://api.supermemory.ai"
})
await client.fetch("/v3/settings") // now resolves and sends Bearer auth一旦设置了 baseUrl，相对路径解析和 targetsBaseUrl 的身份验证附加都能正常工作。永久修复需要在生成的客户端中将 base 解析为 this._options.baseUrl ?? this._options.environment ?? environments.SupermemoryEnvironment.Default。
故障排除如何阻止自托管（self-hosted）文档的 upsert 操作在文件中部小幅编辑后，对几乎所有 chunks 重新生成 embedding？
发生这种情况是因为分块边界对位置敏感。在文件开头附近的插入或删除会使下游的所有边界发生偏移，导致内容哈希不再匹配，几乎所有分块都会被重新嵌入。追加操作则没有问题，因为它们不会移动现有的边界。
修复方法：将自托管服务器升级到包含 PR fix(chunking): stable content-defined chunking with hash-based reuse planning（即 issue #1649 的修复）的版本。该版本使用稳定的、内容定义的分块方式以及基于哈希的复用规划，因此文件中间的编辑只会使受影响的分块失效，而不是整个文档。
在能够升级之前，可以使用以下变通方法：
1. 尽可能优先采用仅追加的更新方式。
2. 将大型且频繁变动的文档拆分为更小、相对稳定的文档，例如每个主要 Markdown 标题对应一个文件。
3. 将频繁编辑的章节移动到文档末尾。
4. 使用更快的嵌入服务提供商、GPU 加速或更小的本地嵌入模型，以降低不可避免的全量重新嵌入的成本。
升级后，后续使用相同 customId 的 /v3/documents upsert 操作应该会复用未更改的下游分块，而不是重新嵌入它们。