TencentDB-Agent-Memory Docker Hub 镜像发布指南三件套多架构构建与安全发布实战【免费下载链接】TencentDB-Agent-MemoryTencentDB Agent Memory is a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks.项目地址: https://gitcode.com/GitHub_Trending/te/TencentDB-Agent-Memory本指南以deploy/dockerhub/README.md为核心系统讲解 TencentDB-Agent-Memory 项目如何将memory-core、memory-proxy、memory-hub三件套镜像构建并推送到 Docker Hub 的agentmemorynamespace覆盖发布脚本publish.sh的完整用法、全部环境变量、构建期 apt 加速、可选私有模块的处理策略以及发布后的镜像验证方法。读完本文你将掌握一套可直接复用的多架构amd64/arm64容器镜像安全发布流程。背景三件套镜像与发布目标TencentDB-Agent-Memory 是一个面向 AI Agent 的团队级记忆中心将对话、文档与代码沉淀为 Chat Memory、Skill、LLM-Wiki、Code-Graph 四类可治理、可共享、跨 Agent 与框架复用的记忆资产。整个系统由三个可独立部署的组件构成Docker Hub 发布脚本将其统称为三件套组件构建上下文镜像名memory-coreMemoryCore/agentmemory/memory-corememory-proxyMemoryProxy/rsync 到临时 contextagentmemory/memory-proxymemory-hubMemoryPanel/MemoryKnowledge/合并agentmemory/memory-hub三个组件各司其职memory-coreAgent 记忆核心网关提供记忆的采集、检索、技能管理等能力对应的生产镜像定义见 MemoryCore/Dockerfile入口为src/gateway/server.tsmemory-proxy代理层负责接入 Claude Code / CodeBuddy 等 Agent 客户端并注入记忆上下文生产镜像定义见 MemoryProxy/Dockerfile入口为src/index.tsmemory-hub合并镜像一个容器内同时运行 Team Memory ControlPanel 控制台与 Knowledge ServiceWiki / Code Graph 知识服务两个进程合并构建配方在 deploy/panel-knowledge-combined/。发布脚本 deploy/dockerhub/publish.sh 是自包含的只依赖各组件自己的 Dockerfile、deploy/panel-knowledge-combined/build.sh与MemoryPanel/scripts/secret-scan.sh不引用任何内网专用构建工具因此可以原样放到开源分支使用。前置条件发布前需要满足两个基础条件docker login docker.io # 账号需有 agentmemory 推送权限 docker buildx version # 需要 buildx脚本会自动创建 builder脚本内部对依赖做了显式校验需要docker与rsync命令见publish.sh中command -v docker与command -v rsync检查并确认secret-scan.sh存在。buildx builder 不存在时脚本会自动创建docker buildx create --name multiarch --driver docker-container使用方法一次发布三件套或单独发布进入发布目录后通过VERSION环境变量指定版本号并传入组件名作为第一个参数cd deploy/dockerhub # 三件套一次发布 VERSION1.0.0 ./publish.sh all # 单个组件 VERSION1.0.0 ./publish.sh memory-core VERSION1.0.0 ./publish.sh memory-proxy VERSION1.0.0 ./publish.sh memory-hub # 干跑只做 secret-scan 和 context 准备不构建不推送 DRY_RUN1 VERSION1.0.0 ./publish.sh all # 本地单架构构建并抽查镜像内容不推送 PUSH0 VERSION1.0.0 ./publish.sh memory-core # 同时更新 :latest ALSO_LATEST1 VERSION1.0.0 ./publish.sh all支持的目标组件为memory-core、memory-proxy、memory-hub与all传入未知名称或直接运行不带参数以及-h/--help时会打印脚本头部注释作为用法说明并退出。版本号规则VERSION必填且不接受dev-开头的值避免把开发 tag 推上公网。脚本中对应校验逻辑为[[ -n ${VERSION:-} ]] || die 请显式指定 VERSION例VERSION1.0.0 ./publish.sh $TARGET [[ $VERSION dev-* ]] die VERSION 不能以 dev- 开头避免把开发 tag 推上公网环境变量速查变量默认值说明VERSION无必填镜像 tagNAMESPACEagentmemoryDocker Hub namespaceREGISTRYdocker.io目标 registryPLATFORMSlinux/amd64,linux/arm64多架构构建目标ALSO_LATEST0是否同时推:latestPUSH1置0则本地--load单架构不推送DRY_RUN0置1只跑扫描与 context 准备LOAD_PLATFORMlinux/amd64PUSH0时本地构建的架构KEEP_CTX0置1复用上次的临时 contextAPT_MIRRORdeb.debian.org构建期 apt 源内网可设为加速镜像关键变量的行为细节PUSH1默认走docker buildx build --push按PLATFORMS指定的多架构目标构建并直接推送ALSO_LATEST1时会额外追加-t image:latest标签实现一个命令同时更新版本 tag 与浮动 tag。PUSH0改为--platform $LOAD_PLATFORM单架构--load到本地构建完成后脚本会自动执行一次spot check创建容器、docker export导出文件系统并用tar -t列出文件若发现/\.env$、metadata-instances.json、/\.admin-key$等疑似敏感文件则中止发布。这是镜像安全发布的重要一环。DRY_RUN1只执行 secret-scan 扫描与临时 context 的 rsync 准备跳过 build 与 push适合在 CI 中先验证上下文KEEP_CTX1可保留上一次生成的临时 context 以便排查问题。BUILDER脚本内默认multiarchbuildx builder 名称不存在时自动创建并 bootstrap。构建期 apt 加速四个 Dockerfilememory-core、memory-proxy、memory-hub 合并镜像的三个 builder stage 共用同一 base都通过APT_MIRRORbuild-arg 控制 apt 源默认走 Debian 官方源公网环境开箱可用。内网构建想加速时只需统一传一个变量镜像产物本身不受影响APT_MIRRORyour-debian-mirror VERSION1.0.0 ./publish.sh all以 MemoryCore/Dockerfile 为例其实现方式是在 deps-builder 与 runtime 两个 stage 中声明ARG APT_MIRRORdeb.debian.org当值不是默认源时用sed替换 Debian sources 文件中的deb.debian.org并配合 BuildKit cache mount--mounttypecache,target/var/cache/apt缓存 apt 包避免重复下载。三个组件的构建流程剖析publish.sh的主流程在解析完参数后执行ensure_builder并在PUSH1时尝试docker login未登录只告警不中断push 阶段才真正失败。随后按目标分发到三个构建函数memory-core直接以源目录为 context由于MemoryCore/.dockerignore已排除测试、文档、私有 submodule 与真值 yaml详见 MemoryCore/.dockerignore因此直接以源目录为 build context无需额外清理步骤。构建前先对src、package.json、openclaw.plugin.json执行 secret-scan。值得注意的是该 Dockerfile 的处理细节镜像内使用 npm 而非仓库开发用的 pnpm构建期会删除peerDependenciesopenclaw、node-llama-cpp会带入带损坏workspace:*引用的传递依赖并追加overrides防御--omitoptional精简体积后再单独--no-save安装esbuild以补齐 tsx 所需的平台二进制。运行时通过tini作为 PID 1HEALTHCHECK探测/health默认监听8420端口。memory-proxyrsync 到临时 context 私有模块 stubmemory-proxy 是唯一需要搬家的组件通过rsync -a --delete将MemoryProxy/同步到临时 context排除.git、node_modules、dist、coverage、.env*、config.yaml等并显式排除packages/cost-guard/*与packages/cost-guard/.*。随后执行make_cost_guard_stub在 context 中生成 cost-guard 的 stub 包详见下文可选私有模块并将 lockfile 替换为空壳package-lock.json源 lockfile 记录的是真实 submodule 结构与 stub 冲突换成空壳让 npm 重解析。构建前对src、package.json、packages再扫一遍。memory-hub复用 panel-knowledge-combined 的 context 准备memory-hub 复用 deploy/panel-knowledge-combined/build.sh 的 context 准备逻辑以PREPARE_ONLY1调用该脚本由它负责将MemoryPanel/与MemoryKnowledge/分别 rsync 到 context 的panel/与knowledge/子目录排除.env*、config/metadata-instances.json、config/*.yaml、文档、测试等并拷贝 Dockerfile、start-combined.sh等。构建前脚本会校验ctx/panel/package.json、ctx/knowledge/package.json与ctx/knowledge/openapi.yamlSwagger UI 运行时需要均存在。关于可选私有模块这是发布流程中容易踩坑、但设计得相当周到的部分MemoryProxy/packages/cost-guard是可选扩展成本守卫/智能路由不进公开镜像。publish.sh会在临时 context 里生成一个 stub 包让依赖图能解析stub 的package.json声明main: src/index.jssrc/index.js导出CostGuard undefined、setAnalyzerDebug undefined、resolveAgentProfile undefined。若 context 中该目录非空说明 rsync 排除规则失效、真实 submodule 混入脚本会直接报错中止。运行时src/guard-adapter.ts通过变量形式的模块名执行动态 importawait import(COST_GUARD_MODULE)见 MemoryProxy/src/guard-adapter.ts加载失败时静默降级为直通转发passthrough对外表现与内部镜像一致。MemoryCore/src/integrations同理已在 MemoryCore/.dockerignore 中显式排除src/integrations一行运行时走 fallback 逻辑。stub 包的典型结构如下由脚本生成{ name: context-proxy/cost-guard, version: 0.0.0-stub, description: Placeholder for the optional cost-guard extension. The proxy falls back to passthrough routing when the real module is absent., type: module, main: src/index.js, exports: { .: ./src/index.js }, private: true }安全基线secret-scan 双重扫描整个发布流程对敏感信息做了两道防线构建前扫描每个组件构建前都对源码目录执行 MemoryPanel/scripts/secret-scan.sh。该脚本内置三类正则规则sk-[a-zA-Z0-9_-]{15,}开头的 key、Bearertoken、以及api_key/secret/password/token等键后跟长值对 docs / README / example 等示例路径有白名单豁免--strict可关闭白名单。命中即exit 1中止发布。镜像内容抽查PUSH0本地构建后通过docker export tar -t检查镜像文件系统是否混入.env、metadata-instances.json、.admin-key等敏感文件spot_check函数。context 的 rsync 阶段还会二次扫描如 memory-proxy 对$ctx的src package.json packages再次执行 secret-scanmemory-hub 对 context 中的panel knowledge Dockerfile start-combined.sh再扫一遍。发布后验证推送完成后可按官方文档给出的方式验证镜像docker pull agentmemory/memory-core:1.0.0 docker buildx imagetools inspect agentmemory/memory-core:1.0.0docker buildx imagetools inspect可确认镜像的 manifest list 中同时包含linux/amd64与linux/arm64两个平台的 digest。publish.sh在成功收尾时也会打印同样的验证命令提示。发布流程总结一次完整的发布流程可归纳为以下步骤登录 Docker Hubdocker login docker.io账号需具备agentmemorynamespace 推送权限指定版本号禁止dev-前缀与目标组件运行publish.sh脚本依次执行参数校验 → 依赖检查 → 可选builder 创建 → 各组件 secret-scan → rsync 准备 contextmemory-proxy 含 stub 生成、memory-hub 复用 combined build 脚本→ context 二次扫描 →docker buildx build --platform linux/amd64,linux/arm64 --pushPUSH0时本地--load单架构并抽查敏感文件用docker pull与docker buildx imagetools inspect验证发布结果。这套流程把多架构构建、敏感信息防护与私有模块剥离三个发布难题统一收敛到一个自包含脚本中配合APT_MIRROR内网加速与DRY_RUN/PUSH0双保险无论用于 CI 自动化还是本地手工发布都足够安全可控。如需了解 memory-hub 镜像运行时的完整配置项实例配置、LLM 协议、TLS、日志、Langfuse 可观测性等可继续阅读 deploy/panel-knowledge-combined/README.md 与 README.docker.md。【免费下载链接】TencentDB-Agent-MemoryTencentDB Agent Memory is a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks.项目地址: https://gitcode.com/GitHub_Trending/te/TencentDB-Agent-Memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考