TencentDB Agent Memory 本地安装部署指南三件套一键起与多 Agent 框架接入实战【免费下载链接】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本文是 TencentDB Agent Memory 的完整安装手册覆盖「Memory Core Memory Hub Proxy」完整三件套一键部署、仅装 Memory Hub 的轻量形态以及通过 Proxy 接入 Claude Code / CodeBuddy / Hermes / OpenClaw 等编码 Agent 的详细配置。读完本文你将掌握从零拉起整套团队记忆基础设施、在面板中建立 Team / Agent / Task 组织结构并让编码 Agent 在对话中自动获得团队记忆、Skill 与知识注入的完整实战能力。安装形态总览TencentDB Agent Memory 以三个镜像组件构成部署单元本文覆盖三种形态完整三件套推荐memory-corememory-hubproxy一条命令拉起能让 Claude Code 之类的 coding agent 直接用上团队记忆 / 知识 / skill 注入只装 Memory Hub本机已有 Memory Core 运行时的轻量部署只补一个团队记忆管理面板通过 Proxy 使用 Claude Code / CodeBuddy / Hermes / OpenClaw把各类 coding agent 挂到 proxy 上获得统一的记忆能力。三个服务在本地部署中的默认端口如下来自 deploy/global-images/README.md 的组件与端口表服务端口用途Memory Core8420记忆读写、鉴权、skill/RAG 数据面内核 gatewayPanel UI8125团队记忆管理面板memory-hub 容器Knowledge8424Wiki / Code-Graph 服务memory-hub 容器与 Panel 合并镜像Proxy8096LLM 请求代理Anthropic / OpenAI 双协议从部署脚本看三个容器的命名固定为tdai-memory-core、tdai-memory-hub、tdai-proxy共享一个名为tdai-memory-stack的 docker 网络容器间通过网络别名memory-core/memory-hub/proxy互相访问见 start-memory-core.sh 与 start-proxy.sh。形态一完整三件套 Memory Core Memory Hub Proxy推荐前置环境要求macOS / LinuxDockerDocker Desktop / colima / OrbStack 任一均可bash 4macOS 自带 3.2 也能跑两个可用的 LLM 端点可指向同一供应商也可分别指向不同供应商。四步安装流程# 1) 拿脚本 git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git cd TencentDB-Agent-Memory/deploy/global-images # 2) 准备 .env把 LLM 相关字段填成真值 cp .env.example .env $EDITOR .env # MEMORY_LLM_BASE_URL / MEMORY_LLM_API_KEY / MEMORY_LLM_MODEL ← memory hub 内部用 # PROXY_UPSTREAM_URL / PROXY_UPSTREAM_API_KEY / PROXY_UPSTREAM_MODEL ← proxy 转发到的上游 # 3) 干跑校验可选会真做 LLM 通路预检加 --skip-llm 跳过 ./verify.sh # 4) 一键起 ./start-all.sh提示升级到最新镜像时可改用PULL1 ./start-all.sh脚本会先docker pull三个镜像再启动见 start-all.sh 头部注释。两组独立 LLM 参数脚本设计的核心这是整个部署脚本设计的核心—— memory 组和 proxy 组的 LLM 完全独立可以指向不同供应商 / 不同模型。例如 memory 组用便宜模型做 embedding 与总结proxy 组用强模型做主对话。memory 组memory-core memory-hub 使用内核记忆的 embed/summarize、knowledge 的 wiki ingest / 总结走这组配置。变量说明示例MEMORY_LLM_BASE_URLOpenAI 兼容 base URLhttps://api.deepseek.com/v1MEMORY_LLM_API_KEY上述端点的 API Keysk-xxxxxxxxMEMORY_LLM_MODEL模型 IDdeepseek-chatMEMORY_LLM_PROTOCOLopenai或anthropic默认openaiopenaiproxy 组proxy 使用proxy 接到用户请求后转发到这组端点。变量说明示例PROXY_UPSTREAM_URL转发目标 base URLhttps://api.deepseek.com/v1PROXY_UPSTREAM_API_KEY转发用 API Keysk-xxxxxxxxPROXY_UPSTREAM_MODEL面向用户的模型 IDdeepseek-chat两组也可以填完全相同的值都指向同一个 LLM。参数缺失时脚本会在启动前一次性列出所有缺失项并exit 1不会跑到一半才失败 —— 这是 _lib.sh 中require_vars函数的行为任一必填变量为空或仍为REPLACE_ME占位符都会导致启动中止。verify.sh启动前的 LLM 通路预检verify.sh是干跑校验脚本不启动任何容器只检查环境是否就绪。默认会执行以下检查见 verify.sh 源码docker命令可用.env文件存在.env中所有必填参数已填写非REPLACE_ME且非空三个镜像是否已在本地未在本地只 warn不算失败启动时会自动 pull目标端口是否被占用lsof检查占用只 warnLLM 上游通路预检--skip-llm可跳过OpenAI 兼容协议GET {base}/models只验证 API key URL不消耗任何 tokenAnthropic 协议POST {base}/v1/messages发max_tokens1的最小消息消耗 ≤ 10 token可同时验证 URL / auth / 模型名memory 组与 proxy 组独立验证若两组配置完全相同自动跳过重复检查容器已运行时额外从容器内docker exec一次 curl验证容器 → LLM的网络可达性一些企业代理 / DNS 隔离环境下宿主机可达但容器不可达。失败时会直接给出可读的错误定位例如[error] memory 组 API key 无效HTTP 401https://api.deepseek.com/v1/models {error:{message:Authentication Fails, Your api key: ****abcd is invalid,...}}—— API key 错、URL 错、模型名错都会在启动前被拦下不会等到 wiki ingest / chat 时才报 401。start-all.sh一键拉起与自动初始化start-all.sh按依赖顺序依次执行先起 memory-core内核等待 healthy再起 memory-hub面板 知识等待 healthy最后起 proxy。任意一步失败会中止并打印容器日志见 start-all.sh。启动完成后脚本会自动完成两件事首次启动时用init-admin生成 admin useruser_key为随机 32 位sk-mem-32字符格式持久化到./.admin-key同一 volume 下每次重启复用。源码层面start-memory-core.sh 使用openssl rand生成随机串并通过umask 077以收紧权限落盘若.admin-key已存在则直接复用重启不会生成新 key。立即跑一次POST /v3/meta/auth/verify校验这把 key通过后打印一段可直接exportclaude的运行命令形如export ANTHROPIC_BASE_URLhttp://127.0.0.1:8096/claude-code/default export ANTHROPIC_AUTH_TOKENsk-mem-随机32位 claude --model PROXY_UPSTREAM_MODEL 里配的模型内部凭据与安全提醒生产环境必看三件套之间用MEMORY_CORE_GATEWAY_API_KEY互相认证首次启动还会通过init-admin建一个system_admin账户。为了零配置本地体验脚本的默认值如下变量默认值用途MEMORY_CORE_GATEWAY_API_KEYlocalmemory-hub / proxy → memory-core 的 BearerMEMORY_CORE_ADMIN_USERNAMEadmin初始化的 system_admin 用户名MEMORY_CORE_ADMIN_USER_KEYadmin该 admin 用户的登录 key⚠️ 注意这三个默认值只适合个人本地跑通流程。生产 / 联调 / 公网暴露前必须替换成随机长串否则任何拿到端口的人都能拿到 system_admin 权限。在.env里取消对应三行的注释并覆盖即可。另外有一个已知兼容性细节当前 memory-core 的 Bearer gate 与 proxy 的 auth 存在已知不兼容——proxy 调/v3/meta/auth/verify时不带 Bearer所以 proxy 启用 auth 时必须把MEMORY_CORE_GATEWAY_API_KEY留空start-memory-core.sh 中已默认置空并在 key 非空时打印警告。启动完成后可直接访问Panel UIhttp://localhost:8125/Knowledge APIhttp://localhost:8424/v3/Knowledge Swaggerhttp://localhost:8424/docsMemory Gatewayhttp://localhost:8420/Proxyhttp://localhost:8096/部署完成后把它跑起来服务起来只是第一步。要让 Claude Code 之类的 coding agent 用上团队记忆还需要在面板里建组织结构然后在 CC 会话里选它们。第 1 步登录管理面板打开浏览器访问http://localhost:8125Panel UI。第一次访问会看到登录页用start-all.sh结尾打印的 adminuser_key即deploy/global-images/.admin-key文件里那串sk-mem-...登录admin 登录后可以直接使用 Wiki、CodeGraph、Skill 等资产管理功能创建 Team / Agent / Task 等业务资产如果希望隔离运维与业务推荐可创建normal业务用户 → 复制新用户的user_key→ 退出 admin 换新用户登录。换句话说admin 是运维口用来管人业务用户是应用口用来管资产。单机本地体验也推荐遵循这个分层不要用 admin key 直接跑 CC。版本行为差异2.0.0-beta.1 中 admin 不能拥有业务资产2.0.0 正式版起 admin 也可以直接操作资产。Knowledge Service Swagger可选看接口调试用http://localhost:8424/docs第 1.5 步admin 建业务用户可选推荐隔离运维与业务面板左上角「用户管理」新建一个用户API 方式更明确面板里等价操作在「用户」→「新建」ADMIN_KEY$(cat ./.admin-key) curl -sS -X POST http://localhost:8420/v3/meta/user/create \ -H x-tdai-user-key: $ADMIN_KEY \ -H x-tdai-service-id: default \ -H Content-Type: application/json \ -d {username:you} | jq返回体里data.default_user_keysk-mem-...就是新用户的登录 key请立即保存好面板无处再看到全值只有创建时返回一次。之后面板退出登录用这把新 key 重新登录——现在你是normal用户可以在自己名下建 Team / Agent / Task 了。admin 也可以直接操作这里只是推荐隔离。第 2 步在面板里建 Team / Agent / TaskCoding agent 用记忆必须落到具体team / agent / task三元组上Team团队面板左侧「团队」→ 新建。一个 Team 是一组资产的归属容器memory、skill、knowledge 都归 TeamAgent智能体进入 Team → 「Agent」→ 新建。给它填一段清晰的descriptionsystem prompt就是这个 agent 的角色说明例如bug-fix 工程师、前端评审 agent、SQL 优化师Task任务可选Team → 「任务」→ 新建。Task 是这一次工作的抓手比如「修复登录页 XSS」「上线 v1.4 灰度」。记忆会关联到 Task不建 Task 也能用但 L2/L3 会缺 Task 维度。先建至少 1 个 Team 1 个 Agent可选建 Task。第 3 步用 Claude Code 走 Proxy跑 CC 时用 admin 或业务用户的user_key2.0.0 正式版起 admin 也可拥有资产export ANTHROPIC_BASE_URLhttp://127.0.0.1:8096/claude-code/default export ANTHROPIC_AUTH_TOKEN第 1.5 步建的业务用户的 sk-mem-... claude --model PROXY_UPSTREAM_MODEL 里配的上游模型三个环境变量的含义ANTHROPIC_BASE_URL把 CC 的 API 从 anthropic.com 改指到本机 proxy路径里的default是 memory 实例 IDx-tdai-service-id本地部署固定叫defaultANTHROPIC_AUTH_TOKEN是业务用户的 user_key就是第 1.5 步创建用户时返回的default_user_keyproxy 会用它去 core 反查 user_id只有这个 user own 的 team/agent/task 才会出现在下一步表单里--model用你在.env里PROXY_UPSTREAM_MODEL配的那个上游模型名proxy 会把请求转发到PROXY_UPSTREAM_URL。第 4 步CC 首次会话选 Team → Agent → Task每开一个新的 CC 会话proxy 会用 CC 自带的AskUserQuestion工具弹出 3 个连续选择┌─────────────────────────────────────────────────┐ │ 1. 请选择本次会话所属的 Team │ │ ○ Team A │ │ ○ Team B │ │ │ │ 2. 请选择「Team A」下要使用的 Agent │ │ ○ bug-fix 工程师 │ │ ○ 前端评审 agent │ │ │ │ 3. 请选择「Team A」下要关联的任务可选 │ │ ○ 修复登录页 XSS │ │ ○ [跳过任务关联] │ └─────────────────────────────────────────────────┘每个问题直接在 CC 里用箭头选、回车确认。选完之后proxy 记住这次会话的 team/agent/task 绑定后续每一轮请求proxy 会自动把这个 agent 的 L2/L3 记忆、skill、knowledge 注入到 system promptL0原始对话会自动落到 memory-core 的 SQLite 里满足触发条件时后台跑 L1抽 memory→ L2scene→ L3persona流水线。只有新 CC 会话才会弹表单同一次claude进程内的多轮不会再问。从 start-proxy.sh 生成的 config 可以看到这条完整流水线的构成auth校验 user_key→sessionInitteam/agent/task 表单支持 header 自动预选→injection注入器列表为skill、knowledge、tdai-memory三个→ 转发到上游 LLM。第 5 步观察记忆一层层长出来聊完一段之后在面板里看左侧「记忆」→ Chat Memory能看到 L0 原始对话被切分成的 scene「Agent」详情页 → Profileagent 的 L2 scene 与 L3 persona 会逐步累积「Skill」列表如果对话里 LLM 判定这是一条可复用的操作方法会自动抽出 skill 存下来。用 memory-core/health也能看后台 pipeline worker 有没有干活curl -s http://localhost:8420/health | jq .services.pipelineWorker期望看到tasksConsumed/tasksCompleted数字随着对话增长。关于记忆抽取行为start-memory-core.sh 生成的 gateway 配置默认promptMode: chat可通过.env的MEMORY_PROMPT_MODE覆盖为codechat模式对通用聊天 / 教学场景抽 memorycode模式会让 LLM 重点抽改了什么 / 发现什么问题 / 工具用法。常见问题Q: CC 会话没有弹选择表单可能 proxy 里PROXY_ENABLE_SESSION_INIT1没开。start-all.sh默认PROXY_FULL_STACK1已经打开如果你手动改过.env或用PROXY_FULL_STACK0起的重启 proxyPROXY_FULL_STACK1 ./start-proxy.sh。Q: 表单选择项里空空的或者只有别人的 team请确认当前使用的账号已在面板中创建过 Team 和 Agent。如果用的是 admin 账号确保已创建了相关资产如果用的是业务用户账号检查是否已在对应 team 下建过 Agent。Q: 面板显示Panel API 8125 未启动docker ps检查tdai-memory-hub是不是 healthy不 healthy 看docker logs tdai-memory-hub找报错大概率是REMOTE_INSTANCE_URL/LLM_BASE_URL之类配错。Q: L1/L2 一直没跑起来records/ 目录里没东西默认promptModechat对普通对话能抽出 memory如果你配了code而对话都是闲聊LLM 会认为没有可沉淀的东西返回 0。改回chat或跟 agent 做真实工作对话改文件、跑测试、给出结论。Q: 想切换到别的 team/agent起一个新的claude会话新窗口 / 新 session就会重新弹选择表单。形态二只装 Memory Hub已有 Memory Core 运行在本机8420端口时一条命令拉取 Memory Hub打开团队记忆面板docker pull docker.io/agentmemory/memory-hub:latest启动 Panel Knowledge Servicedocker run -d --name tdai-memory-hub \ --add-hosthost.docker.internal:host-gateway \ -p 8125:8125 -p 8424:8424 \ -v tdai-panel-data:/data/knowledge \ -e REMOTE_INSTANCE_URLhttp://host.docker.internal:8420 \ -e REMOTE_INSTANCE_KEYlocal \ -e KNOWLEDGE_PUBLIC_BASE_URLhttp://host.docker.internal:8424/v3 \ -e LLM_MODEcustom \ -e LLM_BASE_URLOPENAI_COMPATIBLE_BASE_URL \ -e LLM_API_KEYYOUR_API_KEY \ -e LLM_MODELMODEL_ID \ docker.io/agentmemory/memory-hub:latest打开 http://localhost:8125。参数说明REMOTE_INSTANCE_URL指向已有 Memory Core 的地址此处用host.docker.internal从容器访问宿主机LLM_MODEcustom表示 knowledge 直连用户提供的 LLM 端点不走 memory 的 LLM proxyKNOWLEDGE_PUBLIC_BASE_URL必须包含/v3后缀否则 Panel 会报错。形态三通过 Proxy 使用各类编码 Agent通过 Proxy 使用 Claude Codestart-all.sh已经把 admin user_key 写在deploy/global-images/.admin-key让 Claude Code 直接走 proxyexport ANTHROPIC_BASE_URLhttp://127.0.0.1:8096/claude-code/default export ANTHROPIC_AUTH_TOKEN$(cat ./.admin-key) claude --model PROXY_UPSTREAM_MODEL 里配的上游模型Proxy 会依次做auth校验 user_key→sessionInit选 team/agent/task 表单→injection把 L2/L3 记忆、skill、knowledge 注入 system prompt→ 转发到上游 LLM。关掉完整流水线只做透传PROXY_FULL_STACK0 ./start-proxy.sh。关于三个能力开关start-proxy.sh 的注释给出了精确定义PROXY_ENABLE_AUTH客户端凭x-tdai-user-key走内核 auth/verify → user_idPROXY_ENABLE_SESSION_INIT首轮弹表单选 team/agent/task依赖 auth tdaiPROXY_ENABLE_TDAIL2/L3 记忆注入 L1 召回依赖 memory-core。PROXY_FULL_STACK1会一键把三个都打开若单独开PROXY_ENABLE_SESSION_INIT1而未开 auth脚本会自动补开 auth。通过 Proxy 使用 CodeBuddyCodeBuddy 是腾讯推出的 AI 编程助手 IDE 插件。通过自定义模型配置可以把 CodeBuddy 的对话请求路由到 Proxy在 IDE 内获得与 Claude Code 相同的记忆能力。版本限制CodeBuddy4.10.2、4.10.3、4.10.4存在已知 Bug——这些版本不会在请求中携带sessionId导致 Proxy 无法完成 Session 初始化。请使用 CodeBuddy ≥ 4.10.5 或 ≤ 4.10.1。配置在开发机的~/.codebuddy/models.json文件中写入以下内容注意替换 API Key{ models: [ { id: claude-sonnet-4-20250514, name: proxy-memory-agent, vendor: claude, apiKey: 业务用户的 sk-mem-... user_key, maxInputTokens: 200000, url: http://127.0.0.1:8096/codebuddy/default, supportsToolCall: true, supportsImages: true } ] }各字段说明idProxy 上游 LLM 支持的模型 ID必须与 Proxy 配置的PROXY_UPSTREAM_MODEL或 upstream 模型列表中的某个模型匹配如claude-sonnet-4-20250514name在 CodeBuddy 对话框中显示的名称可自定义如proxy-memory-agentvendor模型供应商标识仅用于 UI 展示如claude、openai不影响实际请求apiKey使用业务用户的user_key与 Claude Code 的ANTHROPIC_AUTH_TOKEN相同不建议直接使用 admin keyurlProxy 地址 /codebuddy/default路径端口与 Claude Code 一致默认8096default是 memory 实例 ID。配置完成后在 CodeBuddy 对话框中选择刚才配置的模型名称即可开始对话。Session init 流程与 Claude Code 一致选 Team → Agent → Task。通过 Proxy 使用 HermesHermes 是一个开源的 AI Agent 框架。通过配置 extra headers可以让 Hermes 的对话请求经过 Proxy获得团队记忆能力。配置编辑~/.hermes/config.yamlmodel: default: gpt-5.5 provider: custom base_url: http://proxy-host:port/hermes/spaceId api_key: 从面板获取的 API Key extra_headers: x-team-id: 从面板获取的 team_id x-agent-id: 从面板获取的 agent_id x-task-id: 从面板获取的 task_id x-conversation-id: 自定义的会话标识各字段说明base_urlProxy 地址 /hermes/spaceId路径。spaceId是 memory 实例 ID从面板获取通常为defaultapi_key业务用户的user_key从管理面板API Key页获取x-team-id/x-agent-id从管理面板对应页面获取与 CodeBuddy / Claude Code 的获取方式相同x-task-id从管理面板任务管理页获取。当前版本必填——缺少此字段会导致 session 注册失败记忆功能不生效见下文[关于 x-task-id 的已知限制]x-conversation-id用户自定义的会话标识见下文[关于 x-conversation-id 的已知限制]。通过 Proxy 使用 OpenClawOpenClaw 是一个开源的 AI 编码 Agent。通过自定义 provider 配置可以让 OpenClaw 的请求经过 Proxy。配置编辑~/.openclaw/openclaw.json在models.providers中添加{ models: { mode: merge, providers: { memory-proxy: { baseUrl: http://proxy-host:port/openclaw/spaceId, apiKey: 从面板获取的 API Key, api: openai-completions, headers: { x-team-id: 从面板获取的 team_id, x-agent-id: 从面板获取的 agent_id, x-task-id: 从面板获取的 task_id, x-conversation-id: 自定义的会话标识 }, request: { allowPrivateNetwork: true }, models: [ { id: gpt-5.5, name: GPT-5.5, reasoning: false, input: [text], contextWindow: 128000, maxTokens: 32000, cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 } } ] } } } }各字段说明baseUrlProxy 地址 /openclaw/spaceId路径apiKey业务用户的user_keyheaders必须包含x-team-id、x-agent-id、x-task-id、x-conversation-id。其中x-task-id当前版本为必填见下文[关于 x-task-id 的已知限制]models[].id必须与 Proxy 上游配置的模型 ID 匹配。其他平台接入通用除 ClaudeCode / CodeBuddy / Hermes / OpenClaw 外任何兼容 OpenAI API 的平台或自行开发的 Agent 均可接入 Proxy获得团队记忆能力。接入方式将平台的 API base URL 指向 Proxyhttp://proxy-host:port/agent-source/spaceIdagent-source平台标识必须从 Proxy 支持的以下值中选用claude-code、codebuddy、hermes、openclaw。如果使用的是其他平台可伪装成其中某一个接入如使用codebuddy作为标识spaceIdmemory 实例 ID本地部署固定为default。请求 Path 自动拼接/v1/chat/completionsOpenAI 协议或/v1/messagesAnthropic 协议。必须携带的 HeaderHeader说明Authorization: Bearer user_key业务用户的 API Key从面板API Key页获取x-team-id团队 IDx-agent-idAgent IDx-task-id任务 ID当前版本必填见下文已知限制x-conversation-id会话标识由客户端自行生成和管理以上 header 缺一不可——Proxy 会通过 header 直接完成 session 注册跳过交互式表单。无法提供 headers 的平台将触发 session bypass记忆注入和对话回流均不生效。这一机制对应 start-proxy.sh 生成的 config 中sessionInit.headerAutoSelect配置teamHeader: x-team-id、agentHeader: x-agent-id、taskHeader: x-task-id、onMismatch: form——即 header 缺失或不匹配时回落到交互式表单。关于x-task-id的已知限制当前版本限制x-task-id在 Hermes / OpenClaw 场景下为必填项。Proxy 的 header 预选机制要求x-team-idx-agent-idx-task-id三者齐全才能完成 session 直接注册。缺少x-task-id时Proxy 会尝试弹出交互式表单让用户选择 task但 Hermes / OpenClaw 无法响应交互式表单最终导致 session bypass记忆注入和对话回流均不生效。这带来的不便用户需要预先在面板上创建 Task 并获取task_id增加了接入门槛切换不同任务时需要手动修改配置文件中的x-task-id。官方计划在下一个版本中支持x-task-id可选当 header 中未指定 task 时Proxy 自动选择该 agent 下的默认 task 或跳过 task 绑定直接完成 session 注册。关于x-conversation-id的已知限制当前版本限制Hermes 和 OpenClaw 需要在配置文件中静态指定x-conversation-id这与 Claude Code / CodeBuddy 不同它们由 SDK 自动管理 session ID。当前限制同一个 conversation ID 的所有请求共享同一个 session——记忆注入、对话回流都绑定到这个 ID每次开启新对话时需要手动更换 conversation ID否则会继续沿用上次的 session 状态部分客户端的 tool call 后续请求可能不携带 extra headers导致那些轮次跳过记忆注入和对话回流。官方计划在下一个版本中优化 conversation ID 的使用体验。停止 / 清理./stop-all.sh # 停容器保留 volume 数据 admin key ./stop-all.sh --purge # 连 volume、admin key、proxy config 一起清注意--purge会删除 named volumetdai-memory-core-data/tdai-panel-data与.admin-key属于彻底清理。若仅停容器下次启动数据仍在——admin user_key 也会保留复用start-memory-core.sh 会优先读取已有的.admin-key若 volume 被清但.admin-key还在需要./stop-all.sh --purge后重新初始化。运维补充独立组件、数据持久化与端口调整三个脚本可以单独执行方便调试或只需要部分能力时./start-memory-core.sh # 只跑内核 gateway8420 ./start-memory-hub.sh # 只跑面板 知识8125 8424需要 MEMORY_LLM_* 参数 ./start-proxy.sh # 只跑 proxy8096需要 PROXY_UPSTREAM_* 参数依赖关系来自 deploy/global-images/README.mdmemory-core无外部依赖可以独立起memory-hub能独立启动LLM_MODEcustom直连 LLM但内部 knowledge 调 memory-core 做 RAG 时会失败 → 建议 memory-core 先起proxy能独立启动cost-guard 不可用时自动降级 passthrough直接转发但 auth / tdai memory / skill 注入需要 memory-core 才有效。任意组件缺失时脚本会warn提醒但不阻塞。数据持久化tdai-memory-core-datanamed volume→ memory-core 的 SQLite / 记忆数据tdai-panel-datanamed volume→ memory-hub 里 knowledge 的 SQLite / git clone / wiki 文件。docker volume rm之前数据一直保留。改名可在.env里改MEMORY_CORE_VOLUME/PANEL_VOLUME。端口冲突如果8125/8420/8424/8096与本地已有服务冲突直接在.env改MEMORY_CORE_PORT18420 PANEL_PORT18125 KNOWLEDGE_PORT18424 PROXY_PORT18096 # knowledge 对外可达地址要跟着 KNOWLEDGE_PORT 走 KNOWLEDGE_PUBLIC_BASE_URLhttp://host.docker.internal:18424/v3查看日志docker logs -f tdai-memory-core docker logs -f tdai-memory-hub docker logs -f tdai-proxymemory-hub 内部有两个进程panel knowledge日志分别在容器内/data/knowledge/logs/panel.log与/data/knowledge/logs/knowledge.log。容器外访问宿主机其它服务Ollama、Langfuse 等脚本已默认--add-hosthost.docker.internal:host-gateway容器内用http://host.docker.internal:port即可。更多资源其它安装形态OpenClaw、Hermes、CodeBuddy、SDK、源码启动、K8s、平台说明参见 deploy/global-images/README.md 与 MemoryCore/README_CN.md项目总体介绍见 README_CN.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），仅供参考