Stable Diffusion提示词工程：从基础原理到实战技巧
2026/8/7 10:30:57
Agent 用得越多，越能感受到一个反直觉的痛点：会话一结束，它就把项目背景忘得干干净净。下一次你得重新解释"老鉴权模块别动，移动端还在用"；它得重新把整个仓库的目录翻一遍；好不容易跑通的工作流，下次又要从零摸索。真正贵的往往不是算力，而是已经付过的"学习成本"——上下文解释过一次、文档读过一遍、流程跑通过一次，这些信息理应被存下来、组织好、复用给下一个 Agent。
本文解读腾讯云开源的 TencentDB Agent Memory（v2.0.0，2026-08-03 发布），看它如何把对话、文档、代码沉淀成四种可治理的"记忆资产"，并用 L0–L3 分层与混合检索按需注入上下文。所有数据均来自项目 README、CHANGELOG 与 GitHub API（查询日期 2026-08-06），可追溯；其中性能基准为项目自述，非本文独立复现，文中会明确标注。
它要解决的问题：Agent 的"失忆"与重复学习
项目给自己定的出发点很具体：如何减少使用 Agent 时的重复劳动。如果项目上下文已经讲过，就不该在新会话里重讲；如果文档已经读过，每个 Agent 就不必再从第一页开始；如果某条工作流已经跑通，下次就不该重新发现。它对"记忆"的定义也比"记住对话"更宽——任何能帮下一个 Agent 少走弯路的信息，都应被保存、组织、复用。
项目的核心抽象是Memory Hub：一个面向 Agent 团队的记忆中枢，把"工作产出资产 → 资产在团队中流通 → 新成员直接读档"这一闭环串起来。定位上它强调三点：自动从对话/任务中提取资产、与 Agent 框架解耦可跨框架迁移、对冷启动友好（可导入既有文档/代码库/会话）。
先放一张可核实的事实表，便于读者判断项目状态：
| 维度 | 取值 | 来源 |
|---|---|---|
| 仓库 | TencentCloud/TencentDB-Agent-Memory | GitHub API |
| 最新版本 | v2.0.0（2026-08-03，commit0aff21a） | GitHub 提交历史 |
| 首次公开版本 | v2.0.0-beta.1（2026-07-21） | CHANGELOG.md |
| 仓库创建 | 2026-04-07 | GitHub API |
| Star / Fork | 10,367 / 993（2026-08-06 查询） | GitHub API |
| 主语言 | TypeScript | GitHub API |
| 协议 | README 标注 MIT | README 徽章 |
| 默认分支 | feat/server_team | GitHub API |
需要说明的一点：GitHub API 把 license 字段识别为other（NOASSERTION），与 README 徽章标注的 MIT 不一致，这在 LICENSE 文件未被 licensee 确切解析时常见。本文采用更保守的表述"README 标注 MIT"，读者若要商用请以仓库 LICENSE 文件为准。
四种记忆资产：把经验变成可治理的对象
项目把记忆拆成四类资产，每类解决一种"重复学习"：
- Chat Memory：保留偏好、事实、决策与交互历史。每个 Agent 创建时自动拥有自己的记忆，下次不必重新自我介绍。原始对话按
L0 → L1 → L2 → L3逐层蒸馏。 - Skill：从跑通的任务里提炼可复用 SOP。它不是一段提示词，而是带版本、资源文件、触发边界、执行步骤与验证规则的对象；个人 Skill 默认私有，审核后可共享给团队并装配给其他 Agent。
- Wiki：把产品文档、设计稿、运维手册变成带链接图谱的结构化页面（灵感来自 Karpathy 的 LLM 知识库实践）。
- CodeGraph：索引代码的符号、文件、调用关系与影响路径。Agent 改代码前能先做 impact analysis——不仅知道"代码在哪"，还知道"改这里会影响哪些地方"。
图 1：TencentDB Agent Memory 架构示意（本文依据 README 描述绘制，非官方运行时截图）。四种资产统一注册为 Memory Asset，经 Memory Hub 做 Owner/版本/状态/可见性管理，再按 Agent 负载装配。
项目用一张对比表把自身与"聊天历史"和"标准 RAG"区分开，本文转述其要点：标准 RAG 回答"能找到什么"，而 Team Memory 还要回答"谁能用、哪个版本有效、该发给哪个 Agent"。前者只做检索，后者在检索之上叠加了所有权、版本、状态与团队共享/装配。
| 能力 | 聊天历史 | 标准 RAG | TencentDB Agent Memory |
|---|---|---|---|
| 跨会话用户理解 | △ | △ | ✅ Chat Memory |
| 可执行的提炼经验 | — | — | ✅ Skill |
| 文档结构与关系 | — | △ 分块检索 | ✅ Wiki + 链接图谱 |
| 代码调用图与影响范围 | — | △ 文本匹配 | ✅ CodeGraph |
| 所有权/版本/状态 | — | — | ✅ |
| 团队共享与 Agent 装配 | — | — | ✅ |
| 私有/团队/ACL | — | △ | ✅ |
L0–L3 分层：记忆不是平铺记录，而是逐层蒸馏
记忆不做"全量平铺"，而是先以 L0 保存原始对话，再由异步流水线蒸馏成多粒度层级：
| 层级 | 存储内容 | 主要用途 |
|---|---|---|
| L0 Conversation | 带完整上下文的原始对话 | 核对原话、时间戳与来源 |
| L1 Atom | 从对话中抽取的事实、偏好、约束、事件 | 精确召回可执行信息 |
| L2 Scenario | 围绕项目/场景组织的知识块 | 快速恢复工作上下文 |
| L3 Core / Persona | 长期画像、稳定模式、高层认知 | 让 Agent 快速进入用户与团队语境 |
生成与检索都是分层的：常态下 L2/L3 提供快速上下文引导；需要具体事实时，再用BM25 + 向量检索 + RRF回落到 L1/L0。结果还会按条数、字符预算与超时上限截断，避免记忆撑爆上下文窗口。这个设计要点在于"按需取用"——文档与代码并不整块塞进 prompt，而是先通过/v3/tools/list发现能力，再用/v3/tools/call按需读取相关页面、源码或影响路径。
Memory Hub：把记忆做成团队控制台
Hub 的定位是"控制台而非展板"。打开一个资产时，重要的不只是"写了什么"，还有"来自哪里、是哪个版本、装配给谁、最近是否被用过"。它提供几种玩法：建 Team 并加入人员与 Agent、在资产库浏览/搜索/审核四类资产、给不同 Agent 绑定不同资产并调整优先级、在知识工坊构建 Wiki 与 CodeGraph、按需切换 private/team/ACL 访问。
可见性模型是这套设计里值得注意的一环——共享是显式动作，而非默认泄露：
| 可见性 | 语义 |
|---|---|
private | 仅 Owner 可读，团队管理员也不可见 |
team | 团队成员可读，Owner/Admin 可管理 |
restricted | 通过 User/Role/Agent ACL 精确授权 |
agent | 同团队内对 Agent 定向装配 |
角色分两层：全局 System Admin 管理用户与团队；团队级有 Admin 与 Member，负责团队内资产协作与访问控制。资产所有权由 Owner 追踪，Owner 自动拥有其资产的管理权限。这样可以把"发布 Skill"装配给发布 Agent、把"架构 Wiki"装配给所有开发 Agent、把 CodeGraph 装配给 Coder 与 Reviewer，做到"不同角色不同负载，少给噪声"。
一键部署与 SDK 调用
v2.0.0 把三件套（memory-core + memory-hub + proxy）打成多架构镜像（linux/amd64 + linux/arm64），发布到 Docker Hub 的agentmemory组织，公开可拉取。一键启动的命令如下（来自 README 与 CHANGELOG，请在 Bash/WSL 环境执行）：
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git cd TencentDB-Agent-Memory/deploy/global-images cp .env.example .env $EDITOR .env # 填入两组 LLM 参数（memory 组 + proxy 组） ./start-all.sh # 一键起三件套，完成后打印一行可直接粘进 Claude 的命令启动后面板开在http://localhost:8125。start-all.sh首次启动会自动init-admin、生成形如sk-mem-...的 admin 密钥并落盘到.admin-key，自检/v3/meta/auth/verify后输出可复制的启动命令；stop-all.sh --purge可彻底清 volume 与 admin key 以便重置。三个镜像与职责如下：
| 镜像 | 职责 |
|---|---|
| memory-core | 记忆内核，资产存储与检索 |
| memory-hub | Panel + Knowledge Service，团队控制台 |
| memory-proxy | Claude Code 等 coding agent 接入团队记忆的通道 |
proxy 值得一提：它同时支持 Anthropic 与 OpenAI 双协议（/claude-code/<spaceId>/v1/messages和/v1/chat/completions），首轮通过AskUserQuestion让用户选 team/agent/task 并记住绑定，每轮把该 Agent 的 L2/L3 记忆、匹配到的 Skill、Wiki/CodeGraph 拼进 system prompt 再转发上游；鉴权用x-tdai-user-key换user_id，按用户维度控制资产可见性。
官方提供两套 SDK，调用时需注意 v3 严格隔离——teamId/agentId/userId三项必填：
import { MemoryClient, SkillClient, MetadataClient } from "@tencentdb-agent-memory/memory-sdk-ts-v2"; const memory = new MemoryClient({ endpoint, apiKey, serviceId, teamId, agentId, userId, // v3 严格 isolation：三项必填 });from tencentdb_agent_memory.v3 import MemoryClient, MetadataClient, SkillClient # pip install tencentdb-agent-memory-sdk-python一个自述基准：PersonaMem
README 给出了一个基准 PersonaMem，测试 Agent 在长交互后能否正确理解并应用用户信息。需要强调：这是项目自述结果，并非本文独立复现，列出供参考。
图 2：PersonaMem 基准对比（数据源：项目 README Benchmark 表；图表由本文用 matplotlib 生成）。未启用 48%、启用 76%，相对提升约 59%。
该图的数据另存为 JSON 源文件（data/personamem-benchmark.json），图中数值与正文、JSON 完全一致：未启用 48、启用 76、相对提升(76-48)/48 ≈ 59%。单组基准不足以概括全部场景，读者应把它视作"项目方选择的一个代表性指标"，而非普适结论。
限制与适用边界
诚实列几条 README Notes 中明示的限制，避免误用：
- CodeGraph 暂以公网 HTTPS 仓库为主，私有仓库与 SSH 凭据支持仍在完善。
- Wiki 与 CodeGraph 异步构建，需要等待处理到
ready状态后才可用。 - 资产绑定目前以手动为主，全自动记忆路由仍在迭代。
- 客户端范围有限：当前支持 OpenClaw、Hermes、Claude Code、CodeBuddy 与 SDK 集成，更广的跨框架迁移在路线图上。
- 上述基准为项目自述，未由本文独立复现；star/fork 数为 2026-08-06 查询快照，会随时间变化。
结论
TencentDB Agent Memory 把"Agent 失忆"当作一个工程问题来拆：用四种资产把经验对象化，用 L0–L3 分层把记忆从平铺记录变成可检索的多粒度结构，用 Memory Hub 把记忆从"个人记事本"升级为"团队控制台"，再用 private/team/restricted/agent 的可见性模型守住共享与隐私的边界。对想给 Agent 团队加一层长期记忆的团队，它提供了一个可一键部署、有 SDK、与既有 coding agent 解耦的起点；但 CodeGraph 的私仓支持、自动路由的成熟度、客户端覆盖范围，是落地前需要逐项评估的。