2026/9/10 18:44:24
FEATURED · 精选文章 
TencentDB Agent Memory 路线图深度解析v2.0.1 关键能力规划与mem:会话指令实战【免费下载链接】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本篇技术指南以仓库根目录的 ROADMAP.md及其简体中文版 ROADMAP_CN.md为骨架围绕 TencentDB Agent Memory 的下一步规划展开从 Memory Hub 冷启动默认 Agent、Memory Knowledge 的 Wiki 并发生成加速、Memory Core 的自定义 Prompt 与 provenance到 Memory Proxy 的 Codex 适配以及已随 v2.0.0 发布的mem:会话指令的源码级原理。读完你将掌握v2.0.1 各模块将带来哪些能力、每一项解决什么痛点、对应的底层实现位置在哪里以及如何在对话中直接用mem:指令完成资产刷新与 Skill 归档。需要说明路线图描述的是团队正在推进的工作不是承诺范围与时间可能调整。文中凡涉及将支持/计划支持的表述均以路线图原文为据凡涉及已经实现的表述则以仓库源码为准。已发布内容的完整清单见 CHANGELOG.md。一、路线图总览当前版本与下一站仓库当前版本为v2.0.0路线图面向的下一个版本是v2.0.1。整个项目由四大模块构成v2.0.1 的规划也按模块展开模块定位v2.0.1 相关规划Memory Hub面向团队的管控操作台Panel Knowledge Service默认 Agent 冷启动、Skill 导出、记忆时间过滤、Opik→Skill 导入器、面板体验优化Memory Knowledge文档/代码知识引擎Wiki、CodeGraphWiki 生成受控并发流水线Memory Core记忆内核抽取、召回、四类记忆资产用户级/团队级自定义 Prompt、导入会话时间戳保留Memory ProxyAgent 接入记忆的通道注入与回写Codex IDE Plan 模式适配、两项正确性修复四条主线贯穿 v2.0.1 的规划降低上手门槛默认 Agent、提升冷启动吞吐Wiki 并发生成、增强可配置性与可追溯性自定义 Prompt provenance、扩展框架覆盖Codex与修复正确性时间戳、检索字段、缓存清理。二、冷启动开箱即用默认 Agent 预置 SkillMemory Hub2.1 当前的痛点路线图明确指出当前上手流程过长部署 → 建团队 → 建 Agent → 绑资产 → 复制接入地址 → 才能说第一句话。在产生第一次有效对话之前中间步骤太多这是新用户流失的主要场景。2.2 v2.0.1 的目标跑完start-all.sh复制一行就能开始Memory Hub 将在初始化时准备一个默认 Agent创建即自带团队或用户一创建默认 Agent 就存在无需手工配置预置 Skill默认 Agent 自带预置 Skill在你还没有积累任何自有 Skill 之前就能执行有效工作预挂基础记忆资产默认预绑定基础记忆资产第一轮对话就能写入并召回 Chat Memory可粘贴的接入端点面板直接给出可复制的客户端接入地址并可选指向 Memory Proxy单机部署地址修正单机部署下接入地址解析为宿主机 LAN 地址而非容器内主机名外部客户端才能真正连上。这一规划与仓库现有的部署脚本呼应deploy/global-images/start-all.sh一键拉起完整三件套Memory Core / Memory Hub / Memory Proxyv2.0.1 之后的目标是把部署完成到第一次有效对话之间的距离压缩到一次复制粘贴。三、Wiki 生成加速受控并发的流水线Memory Knowledge3.1 现状串行生成是最大的等待瓶颈导入较大的文档集时页面从processing到ready是一页一页串行完成的——这是冷启动期间最明显的体感问题。3.2 v2.0.1 的改造方向v2.0.1 将 Wiki 生成改造为受控并发bounded-concurrency的流水线页面生成并发执行不再严格串行构建队列设置并发上限与限流避免单次大批量导入耗尽上游 LLM 配额单页失败不拖停整批失败页独立重试并保留错误原因进度可见构建进度与单页状态不再是黑盒。文档规模越大收益越明显——尤其冷启动首次导入既有知识库时。3.3 源码佐证当前的 Wiki 摄取引擎仓库中 MemoryKnowledge/src/engines/wiki/ingest-v2/index.ts 已经实现了单源摄取的核心编排逻辑可以对照理解 v2.0.1 将改造的对象两种生成模式mode支持two-stage默认先让 LLM 产出结构化抽取计划再据此生成页面质量更稳与single-stage源全文直接产出页面少一次 LLM 调用、省 token超长源分块SOURCE_CHAR_BUDGET约为 28000 字符超过预算的源文件通过chunkText分块逐块生成汇总所有 FILE 块结构性文件保护wiki/index.md、schema.md、purpose.md、log.md、overview.md属于STRUCTURAL_FILES摄取不会写入/覆盖路径规范化保证去重不变量canonicalizePagePath优先用页面 frontmatter 的typetitle推导规范落盘路径如entity→entities保证同一实体二次摄取 → 同一路径避免 LLM 路径漂移导致的漏合并落盘后维护索引写盘后重建wiki/index.md、追加wiki/log.md摄取日志且这两个动作失败不影响页面产出。当前实现中分块循环for循环逐 chunk 调 LLM仍是串行的——这正是路线图所说并发生成将要改造的核心热点。四、用户级 / 团队级自定义 PromptMemory Core4.1 为什么需要一套写死的 prompt 无法服务所有团队记忆抽取质量与业务语境强相关做基础设施的团队关心变更影响面做产品的团队关心用户诉求。一套硬编码 prompt 无法同时满足两种诉求——这是该规划的出发点。4.2 v2.0.1 的能力范围支持在user与team两个维度覆盖记忆抽取与召回prompt未配置时回落到内置默认值完全向后兼容生成的记忆携带provenance用了哪套 prompt、哪个模型、什么时间产出。有了 provenance「记忆质量变差了」就从一个靠猜的问题变成一个可追溯的问题是换了 prompt换了模型还是某个时间点之后数据源变了4.3 配置入口与边界路线图明确了两点边界该能力通过 Memory Core API 配置对应 MemoryCore 的元数据/记忆接口体系Memory Hub 面板上的自定义 Prompt 编辑能力尚未支持——即 v2.0.1 阶段配置仍走 API面板编辑要等后续版本。五、Skill 导出与记忆时间过滤Memory Hub5.1 Skill 导出把 Skill 当作一等资产带走路线图强调Skill 不是一段 prompt——它带版本、资源文件、触发边界、执行步骤和校验规则。目前这些内容只能留在 Hub 内。v2.0.1 将提供新增/v3/skill/export接口将 Skill 及其资源文件打包为可下载的zip放宽导出超时适配包含大体积资源的 Skill导出内容与运行时实际注入的内容保持一致包括列表注入的 header/footer。用途备份、跨环境迁移、在社区之间交换可复用的工作流。这与仓库中 Skill 资产的多版本结构见 CHANGELOG.md 中Skill — 版本/资源文件/触发边界/执行步骤/验证规则的描述相互印证正因为 Skill 是复合结构才需要一个完整的导出协议而非简单复制。5.2 记忆时间过滤给翻页式列表加时间维度当前面板的记忆列表只能整体翻页记忆一多就难以定位某段时间的内容。v2.0.1 将在面板支持按时间范围过滤记忆列表与同版本的时间戳修正配套导入的历史会话保留原始记录时间过滤结果才符合预期详见下文第七节。六、Codex 支持IDE Plan 模式Memory Proxy6.1 支持范围Memory Proxy 将新增 Codex 适配复用与其他框架相同的记忆注入与回写链路v2.0.1 支持范围仅 Codex IDE 的 Plan 模式在规划阶段Codex 可以读取Chat Memory、Skill、Wiki 与 CodeGraph——让方案建立在团队既有上下文之上而不是从零推断Codex CLI 与非 Plan 执行模式暂不支持按实际需求排优先级。6.2 框架支持矩阵v2.0.1 之后Memory Proxy 的框架覆盖将扩展为OpenClaw · Hermes · Claude Code · CodeBuddy · CodexIDE Plan· SDK6.3 源码佐证适配器架构已经为多框架铺路仓库中 MemoryProxy/src/agent-adapters/index.ts 已经实现了按agentSource解析适配器的工厂claude-code、codebuddy分别对应特化/桩实现未识别的客户端回退到default。而 MemoryProxy/src/agent-adapters/types.ts 定义的AgentAdapter接口包含两个核心适配点classifyRequest(body)把请求分类为main/fork/sidequery决定后续 stage 是否绕过注入、mem 拦截、L0 记录等副作用extractUserText(content)从 user message 中提取用户真正键入的文本——Claude Code 取最后一个 text block跳过system-reminder元数据CodeBuddy/未知客户端走保守的字符串拼接。Codex 适配器落地时将按照同样的接口补充自己的agentKind与两条规则实现即可复用整条注入与回写链路——这正是路线图所说复用同一路径的架构基础。七、v2.0.1 同期还会包含正确性修复与生态扩展除了上述六个主干能力路线图还列出了随 v2.0.1 一起落地的零散项Memory Core —— 正确性导入会话保留原始时间戳含 JSONL 镜像——导入历史对话后时间线不再被压平到导入时刻。这与第五节记忆时间过滤互为前提时间戳不对过滤结果就不可信。Memory Proxy —— 正确性修复多 Agent 场景下conversation/search读取字段错误导致检索恒为空的问题修复session refresh 未清理 hook 缓存、导致资产解绑不生效的问题。后者对应仓库中 MemoryProxy/src/routes/session-refresh.ts 所承载的重新执行 prewarmFromConfig、刷新 COS 上的注入缓存链路缓存清理是其中关键一环。Memory Hub —— 生态Opik → Skill 导入器可从外部 trace 平台Opik蒸馏 Skill——把已经跑通的 trace 沉淀为可复用资产。Memory Hub —— 面板加载骨架屏、过渡动效、无障碍改进各资产详情页头部统一。八、已发布的mem:会话指令源码级原理与实战Memory Proxy8.1 是什么mem:会话指令已随 v2.0.0 发布见 CHANGELOG.md不属于 v2.0.1 的新增项但路线图专门为它开设了一节——团队正在收集下一批要做哪些指令因此它同样属于路线图正在决定的内容。使用方式直接在对话里输入mem:开头的指令Proxy 会拦截并就地处理不用离开当前会话去开面板。指令说明mem:sync刷新本次会话的全部资产注入Skill / 记忆 / Knowledge / Task Agent 描述mem:create-skill [提示词]把本次对话归档为 Skill后台异步提取mem:help显示指令帮助格式为mem:command冒号后不加空格命令名大小写不敏感。8.2 源码级原理解析链路仓库中 MemoryProxy/src/mem-command/ 是完整的命令模块可以对照理解其实现细节。1命令检测与参数约束—— parser.ts从请求body.messages中取最后一条或checkFirst时取第一条roleuser消息通过resolveAgentAdapter按客户端规则提取用户真实键入文本extractUserText避免把system-reminder等内部元数据误判为用户输入trim后以mem:开头大小写不敏感才命中整条消息必须就是命令不能嵌在普通文字中间参数约束表MEM_COMMANDS_ARGS定义严格性help、sync为false命令后跟任何非空白内容即视为普通对话、透传上游 LLMcreate-skill为true接受可选 args即[提示词]未知命令如 typomem:helpp仍返回ParsedMemCommand交由执行层走未知命令兜底反馈。2执行分发与开关—— index.tsKNOWN_COMMANDS集合登记sync/create-skill/helpisMemCommandAllowed(config, command)检查memCommand功能开关并支持白名单白名单为空 全部允许否则只允许白名单内的命令executeMemCommand按命令分发到三个实现。3mem:sync的底层动作—— commands/sync.ts调用refreshSessionCache同 session-refresh.ts 的链路重新拉取 Agent / Task detail 覆写到 SessionStore描述、prompt、goal 跟着更新重跑所有声明了session_init/hybrid缓存策略的 hookSkill / 记忆 / Knowledge / 固定资产等把新块putMany到 HookCacheRepoCOS。成功文案形如✅ 所有资产注入已刷新Skill / 记忆 / Knowledge 资产、Task Agent 描述耗时 Xms——注意实现刻意只暴露用户能理解的概念不暴露 injector id、hook 名等内部术语。4mem:create-skill的底层动作—— commands/create-skill.ts调用forceArchiveSkill同 session-force-archive.ts 的链路强制归档当前 session 的 skill buffer从 SessionStore 取 session 状态 → 调 Core 的forceArchive接口三种结果文案归档成功✅ 本次对话已归档成功Skill 提取中、无可归档内容⚠️ 本次对话暂无可归档内容、失败❌ ...task_id/archive_key等内部字段保留在结构化data中供面板、日志、e2e 读取不拼进用户可见文案。8.3 下一步做什么由你的使用场景决定路线图明确表示指令是最轻量的入口——不用切界面、不用记 API、一行就能触发。但接下来做哪些指令取决于实际使用中反复需要什么。路线图抛出的三个思考题你希望在对话里直接完成哪些操作例如查看当前注入了什么、临时禁用某个资产、把某段对话存成记忆现有的三个指令哪里不好用参数设计是否别扭有没有你已经用工作流绕过的场景其实一个指令就能解决九、一起决定路线图如何参与Agent 记忆还没有形成公认标准优先做什么很大程度上取决于大家实际遇到什么问题。路线图给出了明确的参与渠道Bug 与问题→ Issues路线图承诺 24 小时内响应想法与提案→ Discussions️贡献代码→ 请先阅读 CONTRIBUTING.md特别欢迎的贡献方向新框架适配器、benchmark 复现、新颖的 Memory Hub 使用场景。在 Issues 中提出你想要的指令时描述清楚你当时所处的场景比直接给接口设计更有帮助——因为路线图的优先级正是由真实痛点驱动的。结语从路线图看项目演进逻辑纵览 v2.0.1 规划可以提炼出 TencentDB Agent Memory 当前的三个演进方向把能跑变成开箱即用默认 Agent、预置 Skill、LAN 地址修正、把能用变成用得稳、用得准并发流水线、provenance、时间戳与缓存正确性修复、把单一框架扩展成生态Codex 适配、Opik→Skill 导入器、Skill 导出交换。对使用者而言最值得现在上手的仍是已发布的mem:指令——它是理解 Memory Proxy 注入与回写链路最直观的入口也是影响下一批指令方向的最短反馈路径。后续迭代细节可持续关注 CHANGELOG.md 与 ROADMAP.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），仅供参考
TencentDB Agent Memory 路线图深度解析：v2.0.1 关键能力规划与 `mem:` 会话指令实战
TencentDB Agent Memory 路线图深度解析v2.0.1 关键能力规划与mem:会话指令实战【免费下载链接】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本篇技术指南以仓库根目录的 ROADMAP.md及其简体中文版 ROADMAP_CN.md为骨架围绕 TencentDB Agent Memory 的下一步规划展开从 Memory Hub 冷启动默认 Agent、Memory Knowledge 的 Wiki 并发生成加速、Memory Core 的自定义 Prompt 与 provenance到 Memory Proxy 的 Codex 适配以及已随 v2.0.0 发布的mem:会话指令的源码级原理。读完你将掌握v2.0.1 各模块将带来哪些能力、每一项解决什么痛点、对应的底层实现位置在哪里以及如何在对话中直接用mem:指令完成资产刷新与 Skill 归档。需要说明路线图描述的是团队正在推进的工作不是承诺范围与时间可能调整。文中凡涉及将支持/计划支持的表述均以路线图原文为据凡涉及已经实现的表述则以仓库源码为准。已发布内容的完整清单见 CHANGELOG.md。一、路线图总览当前版本与下一站仓库当前版本为v2.0.0路线图面向的下一个版本是v2.0.1。整个项目由四大模块构成v2.0.1 的规划也按模块展开模块定位v2.0.1 相关规划Memory Hub面向团队的管控操作台Panel Knowledge Service默认 Agent 冷启动、Skill 导出、记忆时间过滤、Opik→Skill 导入器、面板体验优化Memory Knowledge文档/代码知识引擎Wiki、CodeGraphWiki 生成受控并发流水线Memory Core记忆内核抽取、召回、四类记忆资产用户级/团队级自定义 Prompt、导入会话时间戳保留Memory ProxyAgent 接入记忆的通道注入与回写Codex IDE Plan 模式适配、两项正确性修复四条主线贯穿 v2.0.1 的规划降低上手门槛默认 Agent、提升冷启动吞吐Wiki 并发生成、增强可配置性与可追溯性自定义 Prompt provenance、扩展框架覆盖Codex与修复正确性时间戳、检索字段、缓存清理。二、冷启动开箱即用默认 Agent 预置 SkillMemory Hub2.1 当前的痛点路线图明确指出当前上手流程过长部署 → 建团队 → 建 Agent → 绑资产 → 复制接入地址 → 才能说第一句话。在产生第一次有效对话之前中间步骤太多这是新用户流失的主要场景。2.2 v2.0.1 的目标跑完start-all.sh复制一行就能开始Memory Hub 将在初始化时准备一个默认 Agent创建即自带团队或用户一创建默认 Agent 就存在无需手工配置预置 Skill默认 Agent 自带预置 Skill在你还没有积累任何自有 Skill 之前就能执行有效工作预挂基础记忆资产默认预绑定基础记忆资产第一轮对话就能写入并召回 Chat Memory可粘贴的接入端点面板直接给出可复制的客户端接入地址并可选指向 Memory Proxy单机部署地址修正单机部署下接入地址解析为宿主机 LAN 地址而非容器内主机名外部客户端才能真正连上。这一规划与仓库现有的部署脚本呼应deploy/global-images/start-all.sh一键拉起完整三件套Memory Core / Memory Hub / Memory Proxyv2.0.1 之后的目标是把部署完成到第一次有效对话之间的距离压缩到一次复制粘贴。三、Wiki 生成加速受控并发的流水线Memory Knowledge3.1 现状串行生成是最大的等待瓶颈导入较大的文档集时页面从processing到ready是一页一页串行完成的——这是冷启动期间最明显的体感问题。3.2 v2.0.1 的改造方向v2.0.1 将 Wiki 生成改造为受控并发bounded-concurrency的流水线页面生成并发执行不再严格串行构建队列设置并发上限与限流避免单次大批量导入耗尽上游 LLM 配额单页失败不拖停整批失败页独立重试并保留错误原因进度可见构建进度与单页状态不再是黑盒。文档规模越大收益越明显——尤其冷启动首次导入既有知识库时。3.3 源码佐证当前的 Wiki 摄取引擎仓库中 MemoryKnowledge/src/engines/wiki/ingest-v2/index.ts 已经实现了单源摄取的核心编排逻辑可以对照理解 v2.0.1 将改造的对象两种生成模式mode支持two-stage默认先让 LLM 产出结构化抽取计划再据此生成页面质量更稳与single-stage源全文直接产出页面少一次 LLM 调用、省 token超长源分块SOURCE_CHAR_BUDGET约为 28000 字符超过预算的源文件通过chunkText分块逐块生成汇总所有 FILE 块结构性文件保护wiki/index.md、schema.md、purpose.md、log.md、overview.md属于STRUCTURAL_FILES摄取不会写入/覆盖路径规范化保证去重不变量canonicalizePagePath优先用页面 frontmatter 的typetitle推导规范落盘路径如entity→entities保证同一实体二次摄取 → 同一路径避免 LLM 路径漂移导致的漏合并落盘后维护索引写盘后重建wiki/index.md、追加wiki/log.md摄取日志且这两个动作失败不影响页面产出。当前实现中分块循环for循环逐 chunk 调 LLM仍是串行的——这正是路线图所说并发生成将要改造的核心热点。四、用户级 / 团队级自定义 PromptMemory Core4.1 为什么需要一套写死的 prompt 无法服务所有团队记忆抽取质量与业务语境强相关做基础设施的团队关心变更影响面做产品的团队关心用户诉求。一套硬编码 prompt 无法同时满足两种诉求——这是该规划的出发点。4.2 v2.0.1 的能力范围支持在user与team两个维度覆盖记忆抽取与召回prompt未配置时回落到内置默认值完全向后兼容生成的记忆携带provenance用了哪套 prompt、哪个模型、什么时间产出。有了 provenance「记忆质量变差了」就从一个靠猜的问题变成一个可追溯的问题是换了 prompt换了模型还是某个时间点之后数据源变了4.3 配置入口与边界路线图明确了两点边界该能力通过 Memory Core API 配置对应 MemoryCore 的元数据/记忆接口体系Memory Hub 面板上的自定义 Prompt 编辑能力尚未支持——即 v2.0.1 阶段配置仍走 API面板编辑要等后续版本。五、Skill 导出与记忆时间过滤Memory Hub5.1 Skill 导出把 Skill 当作一等资产带走路线图强调Skill 不是一段 prompt——它带版本、资源文件、触发边界、执行步骤和校验规则。目前这些内容只能留在 Hub 内。v2.0.1 将提供新增/v3/skill/export接口将 Skill 及其资源文件打包为可下载的zip放宽导出超时适配包含大体积资源的 Skill导出内容与运行时实际注入的内容保持一致包括列表注入的 header/footer。用途备份、跨环境迁移、在社区之间交换可复用的工作流。这与仓库中 Skill 资产的多版本结构见 CHANGELOG.md 中Skill — 版本/资源文件/触发边界/执行步骤/验证规则的描述相互印证正因为 Skill 是复合结构才需要一个完整的导出协议而非简单复制。5.2 记忆时间过滤给翻页式列表加时间维度当前面板的记忆列表只能整体翻页记忆一多就难以定位某段时间的内容。v2.0.1 将在面板支持按时间范围过滤记忆列表与同版本的时间戳修正配套导入的历史会话保留原始记录时间过滤结果才符合预期详见下文第七节。六、Codex 支持IDE Plan 模式Memory Proxy6.1 支持范围Memory Proxy 将新增 Codex 适配复用与其他框架相同的记忆注入与回写链路v2.0.1 支持范围仅 Codex IDE 的 Plan 模式在规划阶段Codex 可以读取Chat Memory、Skill、Wiki 与 CodeGraph——让方案建立在团队既有上下文之上而不是从零推断Codex CLI 与非 Plan 执行模式暂不支持按实际需求排优先级。6.2 框架支持矩阵v2.0.1 之后Memory Proxy 的框架覆盖将扩展为OpenClaw · Hermes · Claude Code · CodeBuddy · CodexIDE Plan· SDK6.3 源码佐证适配器架构已经为多框架铺路仓库中 MemoryProxy/src/agent-adapters/index.ts 已经实现了按agentSource解析适配器的工厂claude-code、codebuddy分别对应特化/桩实现未识别的客户端回退到default。而 MemoryProxy/src/agent-adapters/types.ts 定义的AgentAdapter接口包含两个核心适配点classifyRequest(body)把请求分类为main/fork/sidequery决定后续 stage 是否绕过注入、mem 拦截、L0 记录等副作用extractUserText(content)从 user message 中提取用户真正键入的文本——Claude Code 取最后一个 text block跳过system-reminder元数据CodeBuddy/未知客户端走保守的字符串拼接。Codex 适配器落地时将按照同样的接口补充自己的agentKind与两条规则实现即可复用整条注入与回写链路——这正是路线图所说复用同一路径的架构基础。七、v2.0.1 同期还会包含正确性修复与生态扩展除了上述六个主干能力路线图还列出了随 v2.0.1 一起落地的零散项Memory Core —— 正确性导入会话保留原始时间戳含 JSONL 镜像——导入历史对话后时间线不再被压平到导入时刻。这与第五节记忆时间过滤互为前提时间戳不对过滤结果就不可信。Memory Proxy —— 正确性修复多 Agent 场景下conversation/search读取字段错误导致检索恒为空的问题修复session refresh 未清理 hook 缓存、导致资产解绑不生效的问题。后者对应仓库中 MemoryProxy/src/routes/session-refresh.ts 所承载的重新执行 prewarmFromConfig、刷新 COS 上的注入缓存链路缓存清理是其中关键一环。Memory Hub —— 生态Opik → Skill 导入器可从外部 trace 平台Opik蒸馏 Skill——把已经跑通的 trace 沉淀为可复用资产。Memory Hub —— 面板加载骨架屏、过渡动效、无障碍改进各资产详情页头部统一。八、已发布的mem:会话指令源码级原理与实战Memory Proxy8.1 是什么mem:会话指令已随 v2.0.0 发布见 CHANGELOG.md不属于 v2.0.1 的新增项但路线图专门为它开设了一节——团队正在收集下一批要做哪些指令因此它同样属于路线图正在决定的内容。使用方式直接在对话里输入mem:开头的指令Proxy 会拦截并就地处理不用离开当前会话去开面板。指令说明mem:sync刷新本次会话的全部资产注入Skill / 记忆 / Knowledge / Task Agent 描述mem:create-skill [提示词]把本次对话归档为 Skill后台异步提取mem:help显示指令帮助格式为mem:command冒号后不加空格命令名大小写不敏感。8.2 源码级原理解析链路仓库中 MemoryProxy/src/mem-command/ 是完整的命令模块可以对照理解其实现细节。1命令检测与参数约束—— parser.ts从请求body.messages中取最后一条或checkFirst时取第一条roleuser消息通过resolveAgentAdapter按客户端规则提取用户真实键入文本extractUserText避免把system-reminder等内部元数据误判为用户输入trim后以mem:开头大小写不敏感才命中整条消息必须就是命令不能嵌在普通文字中间参数约束表MEM_COMMANDS_ARGS定义严格性help、sync为false命令后跟任何非空白内容即视为普通对话、透传上游 LLMcreate-skill为true接受可选 args即[提示词]未知命令如 typomem:helpp仍返回ParsedMemCommand交由执行层走未知命令兜底反馈。2执行分发与开关—— index.tsKNOWN_COMMANDS集合登记sync/create-skill/helpisMemCommandAllowed(config, command)检查memCommand功能开关并支持白名单白名单为空 全部允许否则只允许白名单内的命令executeMemCommand按命令分发到三个实现。3mem:sync的底层动作—— commands/sync.ts调用refreshSessionCache同 session-refresh.ts 的链路重新拉取 Agent / Task detail 覆写到 SessionStore描述、prompt、goal 跟着更新重跑所有声明了session_init/hybrid缓存策略的 hookSkill / 记忆 / Knowledge / 固定资产等把新块putMany到 HookCacheRepoCOS。成功文案形如✅ 所有资产注入已刷新Skill / 记忆 / Knowledge 资产、Task Agent 描述耗时 Xms——注意实现刻意只暴露用户能理解的概念不暴露 injector id、hook 名等内部术语。4mem:create-skill的底层动作—— commands/create-skill.ts调用forceArchiveSkill同 session-force-archive.ts 的链路强制归档当前 session 的 skill buffer从 SessionStore 取 session 状态 → 调 Core 的forceArchive接口三种结果文案归档成功✅ 本次对话已归档成功Skill 提取中、无可归档内容⚠️ 本次对话暂无可归档内容、失败❌ ...task_id/archive_key等内部字段保留在结构化data中供面板、日志、e2e 读取不拼进用户可见文案。8.3 下一步做什么由你的使用场景决定路线图明确表示指令是最轻量的入口——不用切界面、不用记 API、一行就能触发。但接下来做哪些指令取决于实际使用中反复需要什么。路线图抛出的三个思考题你希望在对话里直接完成哪些操作例如查看当前注入了什么、临时禁用某个资产、把某段对话存成记忆现有的三个指令哪里不好用参数设计是否别扭有没有你已经用工作流绕过的场景其实一个指令就能解决九、一起决定路线图如何参与Agent 记忆还没有形成公认标准优先做什么很大程度上取决于大家实际遇到什么问题。路线图给出了明确的参与渠道Bug 与问题→ Issues路线图承诺 24 小时内响应想法与提案→ Discussions️贡献代码→ 请先阅读 CONTRIBUTING.md特别欢迎的贡献方向新框架适配器、benchmark 复现、新颖的 Memory Hub 使用场景。在 Issues 中提出你想要的指令时描述清楚你当时所处的场景比直接给接口设计更有帮助——因为路线图的优先级正是由真实痛点驱动的。结语从路线图看项目演进逻辑纵览 v2.0.1 规划可以提炼出 TencentDB Agent Memory 当前的三个演进方向把能跑变成开箱即用默认 Agent、预置 Skill、LAN 地址修正、把能用变成用得稳、用得准并发流水线、provenance、时间戳与缓存正确性修复、把单一框架扩展成生态Codex 适配、Opik→Skill 导入器、Skill 导出交换。对使用者而言最值得现在上手的仍是已发布的mem:指令——它是理解 Memory Proxy 注入与回写链路最直观的入口也是影响下一批指令方向的最短反馈路径。后续迭代细节可持续关注 CHANGELOG.md 与 ROADMAP.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），仅供参考 
