Mem0 integrations 目录工程解析九类 Agent 集成包的构建矩阵、pnpm 工具链与 CI/CD 接入规范【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain本文以 integrations/AGENTS.md 为主体完整讲解 Mem0 单仓内integrations/目录的组织原则每个集成包如何做到自带 package.json、锁文件、构建与测试、无共享工具链各包Vercel AI SDK、OpenClaw、Claude Code 插件、n8n、Zapier、Strands 等的构建/测试命令差异以及新增一个集成时必须落地的 7 步 CI/CD 接入流程发布标签路由、CI Gate 注册、marketplace 五处注册。读完你能独立看懂并操作该目录下的任意集成包并知道把新集成接入仓库发布体系的完整链路。一、设计原则自包含包没有共享工具链integrations/是 Mem0 的 Agent 与编辑器集成目录。integrations/AGENTS.md 开篇即给出硬性约束每个子目录都是自包含的自己的package.json、锁文件、构建和测试。不存在共享工具链。做任何操作前先查表。这意味着你不能假设在某个上层目录pnpm install一次就能驱动全部集成也不能把一个包的脚本命令套用到另一个包。文档给出的九行构建矩阵是整个目录的权威索引目录包名构建Lint测试vercel-ai-sdk/mem0/vercel-ai-providertsup (CJSESM)ESLint Prettierjest vitest (edge/node)openclaw/mem0/openclaw-mem0tsup (ESM)无vitestmem0-plugin/Claude Code / Cursor / Codex 插件无无pytestmem0-plugin/.opencode-plugin/mem0/opencode-pluginBun无tsc 类型检查pi-agent-plugin/mem0/pi-agent-plugintsup无vitestdeepseek-plugin/mem0/deepseek-plugintsup (ESM)无vitestn8n-nodes-mem0/mem0/n8n-nodes-mem0tscESLint (n8n-nodes-base)无zapier-mem0/mem0/zapiertsc无离线单元测试 zapier validatemem0-strands/mem0-strandsPyPIhatchRuff mypypytest当前仓库目录结构与该矩阵完全一致integrations/ 下另有AGENTS.md、CLAUDE.md两份 Agent 指引即deepseek-plugin/、mem0-plugin/含嵌套的.opencode-plugin/、mem0-strands/、n8n-nodes-mem0/、openclaw/、pi-agent-plugin/、vercel-ai-sdk/、zapier-mem0/。这个矩阵还隐含了一条发布拓扑信息zapier-mem0/不在 npm 发布路由器中它是手动部署到 Zapier 的见第五节n8n-nodes-mem0/测试列为 none 而 CI 里另有社区节点校验其余 npm 包都有对应的-cd.yml发布流水线。二、工具链约定pnpm 一统Bun 与 Python 为例外矩阵之外文档用一句话划定了工具链红线除.opencode-plugin/Bun和mem0-strands/Pythonpip / hatch外处处 pnpm。永远不用 npm永远不用 yarn。这一点可以从仓库文件得到印证integrations/vercel-ai-sdk/package.json、integrations/openclaw/package.json 等包旁都随附了pnpm-lock.yaml和pnpm-workspace.yaml而 integrations/mem0-strands/python/pyproject.toml 声明requires [hatchling]、requires-python 3.10构建脚本由 hatch 管理dev 依赖列表里含hatchintegrations/mem0-plugin/.opencode-plugin/ 是mem0-plugin/下唯一走 Bun 的嵌套包因此 CI 中它的路径过滤器被单独排除在mem0-plugin之外见第四节 ci-gate.yml 中的!integrations/mem0-plugin/.opencode-plugin/**反选规则。文档给出的标准操作序列以vercel-ai-sdk和openclaw为例cd integrations/vercel-ai-sdk pnpm install pnpm run build # tsup pnpm run lint # eslint pnpm run type-check # tsc --noEmit pnpm run prettier-check pnpm run test # jest pnpm run test:edge # vitest, edge runtime pnpm run test:node # vitest, node runtime cd integrations/openclaw pnpm install pnpm run build # tsup pnpm run test # vitest这些脚本名并非示例性文字而是与 integrations/vercel-ai-sdk/package.json 中scripts段逐字对应build: tsup、lint: eslint \./**/*.ts*\、type-check: tsc --noEmit、prettier-check、test: jest、test:edge/test:node分别指向vitest.edge.config.js与vitest.node.config.js两份配置。也就是说同一包内同时维护了 Jest主测试与 Vitest 双运行时edge/node测试这是该目录中唯一测试列包含两套运行器的包对应矩阵中jest vitest (edge/node)的标注。文档最后强调了一条面向 AI 协作者的规则每次 TypeScript 变更后都要跑类型检查命令名以各包自己定义的为准——pnpm run typecheck或tsc --noEmitvercel-ai-sdk 用的是带连字符的type-check。这条规则直接源于无共享工具链原则脚本名不可跨包假设。三、逐个解析九种集成各自的形态与能力边界文档Each one is what章节说明了每个包到底是什么。以下按文档顺序结合仓库实现逐一展开。3.1 vercel-ai-sdkcreateMem0 包装层文档定性vercel-ai-sdk/通过createMem0provider 封装 Vercel AI SDKAI-SDK 仓库的集成必须走这个包装层而不是直接用MemoryClient。从源码结构看src/目录的拆分印证了这一职责边界integrations/vercel-ai-sdk/src/mem0-provider.tsprovider 主体、mem0-facade.ts对上层暴露的门面、mem0-generic-language-model.ts泛型语言模型抽象、mem0-provider-selector.ts、mem0-types.ts、stream-utils.ts 与 provider-response-provider.ts。package.json的 dependencies 里同时列出了ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google、ai-sdk/groq、ai-sdk/cohere与其tests/目录下按厂商组织的mem0-provider-tests/openai、anthropic、google、groq、cohere 五个测试文件一一对应——包装层同时兼容多个 AI SDK provider这正是AI-SDK 生态走统一入口的落地方式。3.2 mem0-pluginMCP 连接 生命周期钩子文档定性mem0-plugin/把 Claude Code、Cursor、Codex 连接到mcp.mem0.aiMCP 服务器并安装生命周期钩子实现自动记忆捕获对外暴露 9 个 MCP 工具add_memory、search_memories、get_memories、get_memory、update_memory、delete_memory、delete_all_memories、delete_entities、list_entities。仓库内可以对照其真实形态integrations/mem0-plugin/mcp_config.json 声明了 MCP 服务器连接serverUrl: https://mcp.mem0.ai/mcp/请求头携带Authorization: Token ${MEM0_API_KEY}——即九个工具最终都通过这个托管 MCP 端点访问 Mem0 平台hooks/目录下的 hooks.json、cursor-hooks.json、codex-hooks.json 分别是三个宿主编辑器的钩子清单对应文档安装生命周期钩子的说法scripts/目录42 个.py/.sh脚本承载钩子的具体行为如auto_capture.py、capture_session_summary.py、on_session_start.sh、on_pre_compact.py等tests/下 18 个 pytest 用例如test_auto_capture.py、test_session_stats.py对它们做回归验证——对应矩阵中无构建、无 lint、pytest的极简工具链。该插件是目录内唯一的纯 Python 插件且同时通过五个marketplace.json对外发布见第四节第 5 步。3.3 openclaw / pi-agent-plugin / deepseek-plugin同构的编辑器与 Agent 插件文档定性三者是同一形状same shape的编辑器/Agent 插件其中deepseek-plugin/注册为 DeepSeek HarnessCordis的原生插件把 Mem0 的 search/add 工具挂进去。仓库侧可佐证integrations/deepseek-plugin/cordis.example.yml 即其 Cordis Harness 示例配置src/含 index.ts 与formatting.ts、scoping.ts、output.ts、telemetry.tstests/下五个 vitest 用例与之一一对应integrations/openclaw/package.json 的 description 写着 Mem0 memory backend for OpenClaw — platform or self-hosted open-source说明该插件同时支持托管平台与自托管 OSS 两种后端tools/目录实现了 memory-add / search / get / list / update / delete 与事件查询等工具模块integrations/pi-agent-plugin/src/index.ts 是其入口src/按capture/、config/、dream/、memory/组织tests/八个 vitest 用例覆盖工具、捕获与遥测逻辑。3.4 n8n-nodes-mem0社区节点形态文档定性n8n-nodes-mem0/是 n8n 社区节点能力为 add、search、get、update、delete。目录形态也完全符合 n8n 社区节点规范nodes/Mem0/Mem0.node.ts节点实现、nodes/Mem0/Mem0.node.json节点描述、credentials/Mem0Api.credentials.ts凭据定义、index.js 入口与gulpfile.js资源打包测试仅有 test/Mem0.node.test.ts 一个 Jest 用例故矩阵中 Test 列标 none无独立测试命令lint 走 n8n-nodes-base 的 ESLint 约定。3.5 zapier-mem0部署到 Zapier不走 npm文档定性zapier-mem0/是 Zapier Platform CLI 应用能力为 add、search、get、delete它部署到 Zapier 而非 npm因此不在 release router 中。文档给出的部署命令是gh workflow run zapier-mem0-cd.yml --ref main且需要ZAPIER_DEPLOY_KEY仓库 secret。仓库中 zapier-mem0-cd.yml 的头部注释与其workflow_dispatch触发器、ZAPIER_DEPLOY_KEY: ${{ secrets.ZAPIER_DEPLOY_KEY }}的注入点与文档描述逐字吻合。应用本体在src/下按 Zapier CLI 约定分creates/add_memory.ts、delete_memory.ts与searches/search_memories.ts、get_memories.ts入口 src/index.ts 与顶层 index.js。3.6 mem0-strandsPyPI 上的原生 MemoryStore文档定性mem0-strands/是 Strands 的原生MemoryStorePythonPyPI 发布名mem0-strands可插入 Strands 的MemoryManager实现自动召回与服务器端抽取后端可指向托管 Mem0 平台或自托管 Mem0 OSS代码包位于mem0-strands/python/。pyproject.toml 佐证了包名、Python ≥3.10 门槛与 hatch 构建后端实现位于python/src/mem0_strands/client.py、store.py等tests/含test_client.py、test_store.py等 pytest 用例与矩阵pytest Ruff mypy一致。四、Monorepo 级机制标签路由、CI Gate 与 marketplace 注册文档Adding an integration一节把新增集成的 CI/CD 落地拆成 7 步。理解这 7 步需要先看懂仓库现有的两个中枢工作流。4.1 release.yml单一发布路由器与标签前缀release.yml 是全仓唯一发布入口。其注释解释了设计动机各包的 CD 工作流不再自己监听 release 事件而是由路由器检查 release 标签、只派发匹配的那条流水线——每次发布产生一次被路由的运行而不是一次真实运行加七次跳过。路由核心是一段 bashcase分支当前仓库实际注册的前缀为case $TAG in ts-v*) workflowts-sdk-cd.yml ;; cli-node-v*) workflowcli-node-cd.yml ;; cli-v*) workflowcli-python-cd.yml ;; vercel-ai-v*) workflowvercel-ai-cd.yml ;; openclaw-v*) workflowopenclaw-cd.yml ;; opencode-v*) workflowopencode-plugin-cd.yml ;; pi-agent-v*) workflowpi-agent-plugin-cd.yml ;; deepseek-plugin-v*) workflowdeepseek-plugin-cd.yml ;; n8n-nodes-mem0-v*) workflown8n-nodes-mem0-cd.yml ;; mem0-strands-v*) workflowmem0-strands-cd.yml ;; v*) workflowcd.yml ;; # Python SDK *) exit 1 ;; # 未匹配则报错并终止 esac注意文档强调的裸v*分支必须保持在最后case按顺序匹配若把v*放前面vercel-ai-v*、openclaw-v*这类同样以v开头的标签会被误路由到 Python SDK 流水线。路由器匹配成功后通过gh workflow run ... --ref refs/tags/$TAG -f tag$TAG派发到该标签所在的 commit 上保证构建与 provenance 签名精确对应打标签的代码。这也解释了为什么 Zapier 包不在路由器中——它没有v*标签发布路径只有workflow_dispatch手动触发。4.2 ci-gate.yml路径过滤 单一必需检查ci-gate.yml 的头部注释解释了它存在的必要性路径过滤的 CI 工作流无法在分支保护里设为必需检查PR 没碰它的路径时它永远不汇报必需检查会一直挂在 Expected 状态所以用一个对每个 PR 都运行的 Gate 来聚合。其结构为changesjob用dorny/paths-filterv3检测变更包。integrations/下每个包都有独立过滤器例如openclaw: [integrations/openclaw/**, ...]、mem0_plugin: [integrations/mem0-plugin/**, !integrations/mem0-plugin/.opencode-plugin/**, ...]——那条!反选规则正是为了把嵌套的 Bun 包.opencode-plugin/交给独立的opencode_plugin过滤器每个包一个call job形如uses: ./.github/workflows/openclaw-checks.ymlsecrets: inherit仅在对应过滤器命中时执行最终gatejob 在needs中列出全部调用 jobif: always()用jq聚合各流水线结果全部通过或跳过即成功任一failure/cancelled即失败。注释明确分支保护只需要求一条状态检查CI Gate。文档第 4 步所说的在ci-gate.yml注册 CI 工作流落到代码就是三处改动changesjob 的filters加一条路径规则、加一个uses:包工作流的 call job、把该 call job 加入gatejob 的needs列表。4.3 新增集成的 7 步清单原文完整继承文档给出的接入流程原文如下逐条说明创建integrations/name/并在其中构建自包含。不得依赖仓库其他包的产物或脚本。若发布到 registry在package.json中设置repository.directory: integrations/name使 npm provenance 链接指向正确的子目录。仓库现例vercel-ai-sdk/package.json 中repository.directory即为integrations/vercel-ai-sdk。添加.github/workflows/name-checks.yml与name-cd.ymlpaths:触发器、working-directory、cache-dependency-path三处都使用integrations/name在 release.yml 的case块中注册发布标签前缀裸v*分支保持在最后。文档同时警告工作流文件名是承载语义的load bearing——npm OIDC trusted publishing 绑定的是仓库 工作流文件名重命名工作流文件会直接弄断发布链路。在 ci-gate.yml 注册 CI 工作流changesjob 下的路径过滤器、一个 call job、gate jobneeds列表中的一个条目机制见 4.2 节。若是 Claude Code 或编辑器市场插件必须在五个marketplace.json中注册其路径根目录 marketplace.json、.claude-plugin/marketplace.json、.cursor-plugin/marketplace.json、.codex-plugin/marketplace.json、.agents/plugins/marketplace.json。现例根目录与.claude-plugin/下的清单都指向./integrations/mem0-plugin.claude-plugin/版本还携带version字段如0.2.15。在docs/integrations/下写文档并把页面加入 docs/docs.json 与 docs/llms.txt。在 integrations/AGENTS.md 的表格与 [../.github/AGENTS.md] 的 CI/CD 表格中各加一行。原文中该链接写作../.github/AGENTS.md以仓库根目录为起点应写作 github/AGENTS.md——即 .github/AGENTS.md。五、验证与排错速查结合前文操作integrations/时可验证的事实与常见陷阱工具链先查 integrations/AGENTS.md 的矩阵确定该包的构建/lint/测试命令除.opencode-plugin/Bun与mem0-strands/pip/hatch外用 pnpm永不使用 npm/yarn。TypeScript 变更改完即跑类型检查命令名以该包package.json的scripts为准如 vercel-ai-sdk 是type-check而非typecheck或退而执行tsc --noEmit。发布标签新包发布前确认 release.yml 的case块已注册前缀且位于v*之前未匹配的标签会直接exit 1并在日志提示查看 AGENTS.md 的前缀表。工作流文件name-checks.yml/name-cd.yml的命名不可改动OIDC trusted publishing 按仓库 文件名绑定。CI 状态PR 上只看 CI Gate 一条必需检查若新包没被 Gate 触发检查 ci-gate.yml 的过滤器、call job 与needs三处是否齐备。Zapier 发布gh workflow run zapier-mem0-cd.yml --ref main前置条件是仓库配置了ZAPIER_DEPLOY_KEYsecret见 zapier-mem0-cd.yml。插件市场新增编辑器插件后核对五个 marketplace 清单根、.claude-plugin/、.cursor-plugin/、.codex-plugin/、.agents/plugins/都已登记路径。六、关键文件索引文件作用integrations/AGENTS.md本文主体构建矩阵、命令约定、7 步接入流程integrations/vercel-ai-sdk/src/mem0-provider.tscreateMem0provider 入口integrations/mem0-plugin/mcp_config.jsonMCP 服务器连接mcp.mem0.aiintegrations/mem0-plugin/hooks/hooks.json生命周期钩子清单Cursor/Codex 各有对应文件integrations/deepseek-plugin/cordis.example.ymlDeepSeek HarnessCordis示例配置integrations/n8n-nodes-mem0/nodes/Mem0/Mem0.node.tsn8n 社区节点实现integrations/zapier-mem0/src/index.tsZapier CLI 应用入口integrations/mem0-strands/python/pyproject.tomlPyPI 包定义hatch 构建Python ≥3.10.github/workflows/release.yml发布标签路由器case前缀分派.github/workflows/ci-gate.ymlCI Gate路径过滤 聚合必需检查marketplace.json / .claude-plugin/marketplace.json插件市场注册共五处见第四节第 5 步.github/AGENTS.md仓库级 CI/CD 表格与 integrations 表互相引用【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mem0 integrations 目录工程解析：九类 Agent 集成包的构建矩阵、pnpm 工具链与 CI/CD 接入规范
Mem0 integrations 目录工程解析九类 Agent 集成包的构建矩阵、pnpm 工具链与 CI/CD 接入规范【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain本文以 integrations/AGENTS.md 为主体完整讲解 Mem0 单仓内integrations/目录的组织原则每个集成包如何做到自带 package.json、锁文件、构建与测试、无共享工具链各包Vercel AI SDK、OpenClaw、Claude Code 插件、n8n、Zapier、Strands 等的构建/测试命令差异以及新增一个集成时必须落地的 7 步 CI/CD 接入流程发布标签路由、CI Gate 注册、marketplace 五处注册。读完你能独立看懂并操作该目录下的任意集成包并知道把新集成接入仓库发布体系的完整链路。一、设计原则自包含包没有共享工具链integrations/是 Mem0 的 Agent 与编辑器集成目录。integrations/AGENTS.md 开篇即给出硬性约束每个子目录都是自包含的自己的package.json、锁文件、构建和测试。不存在共享工具链。做任何操作前先查表。这意味着你不能假设在某个上层目录pnpm install一次就能驱动全部集成也不能把一个包的脚本命令套用到另一个包。文档给出的九行构建矩阵是整个目录的权威索引目录包名构建Lint测试vercel-ai-sdk/mem0/vercel-ai-providertsup (CJSESM)ESLint Prettierjest vitest (edge/node)openclaw/mem0/openclaw-mem0tsup (ESM)无vitestmem0-plugin/Claude Code / Cursor / Codex 插件无无pytestmem0-plugin/.opencode-plugin/mem0/opencode-pluginBun无tsc 类型检查pi-agent-plugin/mem0/pi-agent-plugintsup无vitestdeepseek-plugin/mem0/deepseek-plugintsup (ESM)无vitestn8n-nodes-mem0/mem0/n8n-nodes-mem0tscESLint (n8n-nodes-base)无zapier-mem0/mem0/zapiertsc无离线单元测试 zapier validatemem0-strands/mem0-strandsPyPIhatchRuff mypypytest当前仓库目录结构与该矩阵完全一致integrations/ 下另有AGENTS.md、CLAUDE.md两份 Agent 指引即deepseek-plugin/、mem0-plugin/含嵌套的.opencode-plugin/、mem0-strands/、n8n-nodes-mem0/、openclaw/、pi-agent-plugin/、vercel-ai-sdk/、zapier-mem0/。这个矩阵还隐含了一条发布拓扑信息zapier-mem0/不在 npm 发布路由器中它是手动部署到 Zapier 的见第五节n8n-nodes-mem0/测试列为 none 而 CI 里另有社区节点校验其余 npm 包都有对应的-cd.yml发布流水线。二、工具链约定pnpm 一统Bun 与 Python 为例外矩阵之外文档用一句话划定了工具链红线除.opencode-plugin/Bun和mem0-strands/Pythonpip / hatch外处处 pnpm。永远不用 npm永远不用 yarn。这一点可以从仓库文件得到印证integrations/vercel-ai-sdk/package.json、integrations/openclaw/package.json 等包旁都随附了pnpm-lock.yaml和pnpm-workspace.yaml而 integrations/mem0-strands/python/pyproject.toml 声明requires [hatchling]、requires-python 3.10构建脚本由 hatch 管理dev 依赖列表里含hatchintegrations/mem0-plugin/.opencode-plugin/ 是mem0-plugin/下唯一走 Bun 的嵌套包因此 CI 中它的路径过滤器被单独排除在mem0-plugin之外见第四节 ci-gate.yml 中的!integrations/mem0-plugin/.opencode-plugin/**反选规则。文档给出的标准操作序列以vercel-ai-sdk和openclaw为例cd integrations/vercel-ai-sdk pnpm install pnpm run build # tsup pnpm run lint # eslint pnpm run type-check # tsc --noEmit pnpm run prettier-check pnpm run test # jest pnpm run test:edge # vitest, edge runtime pnpm run test:node # vitest, node runtime cd integrations/openclaw pnpm install pnpm run build # tsup pnpm run test # vitest这些脚本名并非示例性文字而是与 integrations/vercel-ai-sdk/package.json 中scripts段逐字对应build: tsup、lint: eslint \./**/*.ts*\、type-check: tsc --noEmit、prettier-check、test: jest、test:edge/test:node分别指向vitest.edge.config.js与vitest.node.config.js两份配置。也就是说同一包内同时维护了 Jest主测试与 Vitest 双运行时edge/node测试这是该目录中唯一测试列包含两套运行器的包对应矩阵中jest vitest (edge/node)的标注。文档最后强调了一条面向 AI 协作者的规则每次 TypeScript 变更后都要跑类型检查命令名以各包自己定义的为准——pnpm run typecheck或tsc --noEmitvercel-ai-sdk 用的是带连字符的type-check。这条规则直接源于无共享工具链原则脚本名不可跨包假设。三、逐个解析九种集成各自的形态与能力边界文档Each one is what章节说明了每个包到底是什么。以下按文档顺序结合仓库实现逐一展开。3.1 vercel-ai-sdkcreateMem0 包装层文档定性vercel-ai-sdk/通过createMem0provider 封装 Vercel AI SDKAI-SDK 仓库的集成必须走这个包装层而不是直接用MemoryClient。从源码结构看src/目录的拆分印证了这一职责边界integrations/vercel-ai-sdk/src/mem0-provider.tsprovider 主体、mem0-facade.ts对上层暴露的门面、mem0-generic-language-model.ts泛型语言模型抽象、mem0-provider-selector.ts、mem0-types.ts、stream-utils.ts 与 provider-response-provider.ts。package.json的 dependencies 里同时列出了ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google、ai-sdk/groq、ai-sdk/cohere与其tests/目录下按厂商组织的mem0-provider-tests/openai、anthropic、google、groq、cohere 五个测试文件一一对应——包装层同时兼容多个 AI SDK provider这正是AI-SDK 生态走统一入口的落地方式。3.2 mem0-pluginMCP 连接 生命周期钩子文档定性mem0-plugin/把 Claude Code、Cursor、Codex 连接到mcp.mem0.aiMCP 服务器并安装生命周期钩子实现自动记忆捕获对外暴露 9 个 MCP 工具add_memory、search_memories、get_memories、get_memory、update_memory、delete_memory、delete_all_memories、delete_entities、list_entities。仓库内可以对照其真实形态integrations/mem0-plugin/mcp_config.json 声明了 MCP 服务器连接serverUrl: https://mcp.mem0.ai/mcp/请求头携带Authorization: Token ${MEM0_API_KEY}——即九个工具最终都通过这个托管 MCP 端点访问 Mem0 平台hooks/目录下的 hooks.json、cursor-hooks.json、codex-hooks.json 分别是三个宿主编辑器的钩子清单对应文档安装生命周期钩子的说法scripts/目录42 个.py/.sh脚本承载钩子的具体行为如auto_capture.py、capture_session_summary.py、on_session_start.sh、on_pre_compact.py等tests/下 18 个 pytest 用例如test_auto_capture.py、test_session_stats.py对它们做回归验证——对应矩阵中无构建、无 lint、pytest的极简工具链。该插件是目录内唯一的纯 Python 插件且同时通过五个marketplace.json对外发布见第四节第 5 步。3.3 openclaw / pi-agent-plugin / deepseek-plugin同构的编辑器与 Agent 插件文档定性三者是同一形状same shape的编辑器/Agent 插件其中deepseek-plugin/注册为 DeepSeek HarnessCordis的原生插件把 Mem0 的 search/add 工具挂进去。仓库侧可佐证integrations/deepseek-plugin/cordis.example.yml 即其 Cordis Harness 示例配置src/含 index.ts 与formatting.ts、scoping.ts、output.ts、telemetry.tstests/下五个 vitest 用例与之一一对应integrations/openclaw/package.json 的 description 写着 Mem0 memory backend for OpenClaw — platform or self-hosted open-source说明该插件同时支持托管平台与自托管 OSS 两种后端tools/目录实现了 memory-add / search / get / list / update / delete 与事件查询等工具模块integrations/pi-agent-plugin/src/index.ts 是其入口src/按capture/、config/、dream/、memory/组织tests/八个 vitest 用例覆盖工具、捕获与遥测逻辑。3.4 n8n-nodes-mem0社区节点形态文档定性n8n-nodes-mem0/是 n8n 社区节点能力为 add、search、get、update、delete。目录形态也完全符合 n8n 社区节点规范nodes/Mem0/Mem0.node.ts节点实现、nodes/Mem0/Mem0.node.json节点描述、credentials/Mem0Api.credentials.ts凭据定义、index.js 入口与gulpfile.js资源打包测试仅有 test/Mem0.node.test.ts 一个 Jest 用例故矩阵中 Test 列标 none无独立测试命令lint 走 n8n-nodes-base 的 ESLint 约定。3.5 zapier-mem0部署到 Zapier不走 npm文档定性zapier-mem0/是 Zapier Platform CLI 应用能力为 add、search、get、delete它部署到 Zapier 而非 npm因此不在 release router 中。文档给出的部署命令是gh workflow run zapier-mem0-cd.yml --ref main且需要ZAPIER_DEPLOY_KEY仓库 secret。仓库中 zapier-mem0-cd.yml 的头部注释与其workflow_dispatch触发器、ZAPIER_DEPLOY_KEY: ${{ secrets.ZAPIER_DEPLOY_KEY }}的注入点与文档描述逐字吻合。应用本体在src/下按 Zapier CLI 约定分creates/add_memory.ts、delete_memory.ts与searches/search_memories.ts、get_memories.ts入口 src/index.ts 与顶层 index.js。3.6 mem0-strandsPyPI 上的原生 MemoryStore文档定性mem0-strands/是 Strands 的原生MemoryStorePythonPyPI 发布名mem0-strands可插入 Strands 的MemoryManager实现自动召回与服务器端抽取后端可指向托管 Mem0 平台或自托管 Mem0 OSS代码包位于mem0-strands/python/。pyproject.toml 佐证了包名、Python ≥3.10 门槛与 hatch 构建后端实现位于python/src/mem0_strands/client.py、store.py等tests/含test_client.py、test_store.py等 pytest 用例与矩阵pytest Ruff mypy一致。四、Monorepo 级机制标签路由、CI Gate 与 marketplace 注册文档Adding an integration一节把新增集成的 CI/CD 落地拆成 7 步。理解这 7 步需要先看懂仓库现有的两个中枢工作流。4.1 release.yml单一发布路由器与标签前缀release.yml 是全仓唯一发布入口。其注释解释了设计动机各包的 CD 工作流不再自己监听 release 事件而是由路由器检查 release 标签、只派发匹配的那条流水线——每次发布产生一次被路由的运行而不是一次真实运行加七次跳过。路由核心是一段 bashcase分支当前仓库实际注册的前缀为case $TAG in ts-v*) workflowts-sdk-cd.yml ;; cli-node-v*) workflowcli-node-cd.yml ;; cli-v*) workflowcli-python-cd.yml ;; vercel-ai-v*) workflowvercel-ai-cd.yml ;; openclaw-v*) workflowopenclaw-cd.yml ;; opencode-v*) workflowopencode-plugin-cd.yml ;; pi-agent-v*) workflowpi-agent-plugin-cd.yml ;; deepseek-plugin-v*) workflowdeepseek-plugin-cd.yml ;; n8n-nodes-mem0-v*) workflown8n-nodes-mem0-cd.yml ;; mem0-strands-v*) workflowmem0-strands-cd.yml ;; v*) workflowcd.yml ;; # Python SDK *) exit 1 ;; # 未匹配则报错并终止 esac注意文档强调的裸v*分支必须保持在最后case按顺序匹配若把v*放前面vercel-ai-v*、openclaw-v*这类同样以v开头的标签会被误路由到 Python SDK 流水线。路由器匹配成功后通过gh workflow run ... --ref refs/tags/$TAG -f tag$TAG派发到该标签所在的 commit 上保证构建与 provenance 签名精确对应打标签的代码。这也解释了为什么 Zapier 包不在路由器中——它没有v*标签发布路径只有workflow_dispatch手动触发。4.2 ci-gate.yml路径过滤 单一必需检查ci-gate.yml 的头部注释解释了它存在的必要性路径过滤的 CI 工作流无法在分支保护里设为必需检查PR 没碰它的路径时它永远不汇报必需检查会一直挂在 Expected 状态所以用一个对每个 PR 都运行的 Gate 来聚合。其结构为changesjob用dorny/paths-filterv3检测变更包。integrations/下每个包都有独立过滤器例如openclaw: [integrations/openclaw/**, ...]、mem0_plugin: [integrations/mem0-plugin/**, !integrations/mem0-plugin/.opencode-plugin/**, ...]——那条!反选规则正是为了把嵌套的 Bun 包.opencode-plugin/交给独立的opencode_plugin过滤器每个包一个call job形如uses: ./.github/workflows/openclaw-checks.ymlsecrets: inherit仅在对应过滤器命中时执行最终gatejob 在needs中列出全部调用 jobif: always()用jq聚合各流水线结果全部通过或跳过即成功任一failure/cancelled即失败。注释明确分支保护只需要求一条状态检查CI Gate。文档第 4 步所说的在ci-gate.yml注册 CI 工作流落到代码就是三处改动changesjob 的filters加一条路径规则、加一个uses:包工作流的 call job、把该 call job 加入gatejob 的needs列表。4.3 新增集成的 7 步清单原文完整继承文档给出的接入流程原文如下逐条说明创建integrations/name/并在其中构建自包含。不得依赖仓库其他包的产物或脚本。若发布到 registry在package.json中设置repository.directory: integrations/name使 npm provenance 链接指向正确的子目录。仓库现例vercel-ai-sdk/package.json 中repository.directory即为integrations/vercel-ai-sdk。添加.github/workflows/name-checks.yml与name-cd.ymlpaths:触发器、working-directory、cache-dependency-path三处都使用integrations/name在 release.yml 的case块中注册发布标签前缀裸v*分支保持在最后。文档同时警告工作流文件名是承载语义的load bearing——npm OIDC trusted publishing 绑定的是仓库 工作流文件名重命名工作流文件会直接弄断发布链路。在 ci-gate.yml 注册 CI 工作流changesjob 下的路径过滤器、一个 call job、gate jobneeds列表中的一个条目机制见 4.2 节。若是 Claude Code 或编辑器市场插件必须在五个marketplace.json中注册其路径根目录 marketplace.json、.claude-plugin/marketplace.json、.cursor-plugin/marketplace.json、.codex-plugin/marketplace.json、.agents/plugins/marketplace.json。现例根目录与.claude-plugin/下的清单都指向./integrations/mem0-plugin.claude-plugin/版本还携带version字段如0.2.15。在docs/integrations/下写文档并把页面加入 docs/docs.json 与 docs/llms.txt。在 integrations/AGENTS.md 的表格与 [../.github/AGENTS.md] 的 CI/CD 表格中各加一行。原文中该链接写作../.github/AGENTS.md以仓库根目录为起点应写作 github/AGENTS.md——即 .github/AGENTS.md。五、验证与排错速查结合前文操作integrations/时可验证的事实与常见陷阱工具链先查 integrations/AGENTS.md 的矩阵确定该包的构建/lint/测试命令除.opencode-plugin/Bun与mem0-strands/pip/hatch外用 pnpm永不使用 npm/yarn。TypeScript 变更改完即跑类型检查命令名以该包package.json的scripts为准如 vercel-ai-sdk 是type-check而非typecheck或退而执行tsc --noEmit。发布标签新包发布前确认 release.yml 的case块已注册前缀且位于v*之前未匹配的标签会直接exit 1并在日志提示查看 AGENTS.md 的前缀表。工作流文件name-checks.yml/name-cd.yml的命名不可改动OIDC trusted publishing 按仓库 文件名绑定。CI 状态PR 上只看 CI Gate 一条必需检查若新包没被 Gate 触发检查 ci-gate.yml 的过滤器、call job 与needs三处是否齐备。Zapier 发布gh workflow run zapier-mem0-cd.yml --ref main前置条件是仓库配置了ZAPIER_DEPLOY_KEYsecret见 zapier-mem0-cd.yml。插件市场新增编辑器插件后核对五个 marketplace 清单根、.claude-plugin/、.cursor-plugin/、.codex-plugin/、.agents/plugins/都已登记路径。六、关键文件索引文件作用integrations/AGENTS.md本文主体构建矩阵、命令约定、7 步接入流程integrations/vercel-ai-sdk/src/mem0-provider.tscreateMem0provider 入口integrations/mem0-plugin/mcp_config.jsonMCP 服务器连接mcp.mem0.aiintegrations/mem0-plugin/hooks/hooks.json生命周期钩子清单Cursor/Codex 各有对应文件integrations/deepseek-plugin/cordis.example.ymlDeepSeek HarnessCordis示例配置integrations/n8n-nodes-mem0/nodes/Mem0/Mem0.node.tsn8n 社区节点实现integrations/zapier-mem0/src/index.tsZapier CLI 应用入口integrations/mem0-strands/python/pyproject.tomlPyPI 包定义hatch 构建Python ≥3.10.github/workflows/release.yml发布标签路由器case前缀分派.github/workflows/ci-gate.ymlCI Gate路径过滤 聚合必需检查marketplace.json / .claude-plugin/marketplace.json插件市场注册共五处见第四节第 5 步.github/AGENTS.md仓库级 CI/CD 表格与 integrations 表互相引用【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考