进阶 📋 6 个步骤 第 241 / 460 篇

腾讯云 Agent Memory 开源 80 天破 1.5 万 Star:用 Team Memory 给多 Agent 团队装一套共享大脑

TencentDB Agent Memory 开源 80 天 Star 破 1.5 万,8 月 6 日发布 Team Memory,把记忆从个人扩展到团队。四类记忆资产按角色装配给 CodeBuddy、OpenClaw、Claude Code 等不同 Agent,换框架也不用重建记忆。本教程拆解冷启动导入、角色装配矩阵、权限分级与「一人公司」最小配置。

2026.08.07· 16 分钟阅读· 约 2005 字· 🧩 Agent Memory / 🛠️ CodeBuddy

2026 年 8 月 6 日,腾讯云数据库开源项目 TencentDB Agent Memory 发布新版本 Team Memory,把长期记忆能力从个人使用扩展到团队协作。该项目今年 5 月中旬开源,上线 80 天 GitHub Star 数超过 15000,并多次登上 GitHub Trending 第一。

如果你已经在用它做个人长期记忆(可以先看第 115 篇教程),这次的变化值得单独讲一遍:它不再只保存历史对话,而是把团队协作里产生的经验拆成四类资产,按角色分别装配给不同的 Agent。

🧩 本教程适合:同时使用多个 Agent(CodeBuddy / OpenClaw / Claude Code 等)的开发者、需要在团队里共享 Agent 经验的技术负责人,以及一个人带一堆 Agent 干活的「一人公司」(OPC)实践者。

Step 1:先搞清楚它解决的到底是什么问题

1 三个反复出现的浪费

Agent 进入真实研发流程后,团队普遍遇到三件重复劳动:

症状具体表现代价
项目背景反复介绍每开一个新会话都要把架构、约定、历史决策讲一遍上下文预算被开场白吃掉
历史方案重新理解三个月前踩过的坑,换个 Agent 又踩一次重复排障
验证过的方法难复用A 同事调好的排障流程,B 同事和别的 Agent 用不上经验困在个人会话里

Team Memory 的定位很明确——它不是一个新的 Agent,而是位于 Agent 与大模型之间的「团队记忆层」。负责把对话、知识、代码和工作经验沉淀下来,并在下一次任务中把正确的记忆交给正确的 Agent。

Step 2:认识四类记忆资产

2 不同来源,走不同的加工管线

这是 Team Memory 与「把聊天记录存下来」最本质的区别:不同来源的经验被加工成结构不同的资产

资产类型原料加工结果典型用途
Chat Memory历史 Agent 对话结构化的对话记忆延续讨论、复用结论
LLM-Wiki项目文档可被模型检索的知识库业务背景、架构说明
CodeGraph代码仓库代码结构、符号关系、调用路径图让 Agent 真懂这套代码
Skill一次成功的排障 / 需求拆解 / 代码评审可复用技能下次同类任务直接调用
💡 最容易被低估的是 CodeGraph。纯向量检索的代码记忆只能找到「看起来相似」的片段,而调用路径图能回答「改这个函数会影响谁」——这恰恰是修 Bug 类任务最需要的信息。

Step 3:冷启动——不用从零开始积累

3 三类存量直接导入

记忆系统最劝退的一点是「要用很久才有用」。Team Memory 支持冷启动,把已有存量直接转成资产:

冷启动三件套(都可直接导入并自动生成资产)

  ① GitHub 代码仓库   ──→  自动生成 CodeGraph
  ② 项目文档          ──→  自动生成 LLM-Wiki
  ③ 历史 Agent Session ──→  整理为 Chat Memory

落地顺序建议:
  先导代码仓库(收益最直接、最不需要人工整理)
  再导文档(挑真正在维护的,别把过期文档灌进去)
  最后导历史 Session(挑排障和评审类,闲聊别导)

别把过期文档一次性全灌进去。记忆层的价值在于「给对的记忆」,不在于「给得多」。一份两年前的架构图和当前代码冲突时,Agent 不会自动判断谁更新——它只会自信地按错的那份回答。导入前先删一遍明显过期的内容,这一步省不得。

Step 4:按角色装配——本次更新的核心用法

4 不同任务的 Agent,加载不同的记忆

官方给出的两个典型装配示例,把思路说得很清楚:

Agent 角色装配的记忆刻意不装的
修复 BugCodeGraph + 历史排障经验 + 相关 Skill产品需求讨论、市场背景
需求分析项目 Wiki + 业务背景 + 历史讨论代码符号关系
实际使用流程:

  1. 创建 Team,并在 Team 下建立不同角色的 Agent
  2. 导入代码库 / 项目文档 / 历史 Agent Session
  3. 开启新会话时,选择:
       本次任务所属的 Team
       使用的 Agent
       具体 Task
  4. 系统自动把相关记忆、Skill、Wiki、代码知识注入上下文
🎯 「刻意不装」这一列比「装什么」更重要。往上下文里塞无关内容不是中性操作——它会稀释注意力、挤占预算,让模型在错误方向上更自信。角色装配的本质是做减法。

Step 5:治理——记忆共享绕不开权限

5 Memory Hub 与分级授权

本次同步上线了 Memory Hub 团队记忆控制台,可以创建 Team、Agent 和 Task,把散落在对话、文档、代码库中的记忆集中到一处,完成生成、审核、授权、分享和装配,并查看每项记忆的来源、版本和使用情况。

治理能力清单

  每项记忆支持:Owner / 版本 / 状态 / 使用记录
  权限维度:  按用户、按角色、按 Agent

  共享范围分级:
    个人私有
      └─ 团队共享
           └─ 指定用户或 Agent 授权

  典型用法:
    某开发者沉淀的排障 Skill  → 审核后共享给团队其他成员和 Agent
    一份架构 Wiki            → 统一提供给开发 / 测试 / 评审 Agent

「审核后共享」这个环节不要跳过。一条错误的排障 Skill 一旦进入团队共享,会被多个 Agent 反复调用、反复放大。记忆层最危险的失效模式不是「没记住」,而是「把错的记牢了,还传染给了整个团队」。建议把 Skill 晋升为团队级设为需人工确认。

Step 6:一人公司(OPC)的最小落地配置

6 一个人也能管理一支 Agent 团队

Memory Hub 明确把「一人公司」列为适用场景:一个人 + 多个 Agent,分别扮演调研、开发、评审等角色,各自配置所需的文档、代码知识、历史记忆和 Skill。

OPC 最小配置(三个角色起步)

【调研 Agent】
  装配:LLM-Wiki + 历史调研 Chat Memory
  产出:方案对比、可行性结论
  产出回流:结论写入 Wiki

【开发 Agent】
  装配:CodeGraph + 编码规范 Skill + 排障经验
  产出:代码变更
  产出回流:新踩的坑沉淀为 Skill

【评审 Agent】
  装配:CodeGraph + 评审清单 Skill + 架构 Wiki
  产出:评审意见
  产出回流:反复出现的问题升级为规范

关键:三个角色共用同一套 Team 记忆,
      但各自只加载与自身职责相关的部分。
📌 最容易被忽略的一环是「产出回流」。很多人只用记忆层做读取,从不往回写,结果它退化成一个静态知识库。真正的复利来自闭环:每次任务结束,问一句「这次有什么值得沉淀成 Skill 或写进 Wiki 的」,坚持两周就能看到差别。

迁移成本:为什么这件事值得现在做

场景没有记忆层有团队记忆层
团队换 Agent 框架经验随工具作废,从头再来已积累的记忆和 Skill 继续可用
团队换模型提示词与上下文习惯全部重调记忆层在 Agent 与模型之间,不受影响
新人 / 新 Agent 加入口头交接 + 自己翻代码直接装配现成资产,快速进入状态

一句话总结:Team Memory 把「记忆」从个人会话的附属品,升级成了可治理、可授权、可版本化的团队资产。它的价值不在于记得多,而在于每次都把对的那部分记忆,交给对的那个 Agent。项目主页:github.com/TencentCloud/TencentDB-Agent-Memory,具体能力与安装方式以官方仓库最新说明为准。

← 返回教程中心