动态记忆更新：让 Agent 在 Harness 中持续学习

动态记忆更新：让 Agent 在 Harness 中持续学习

2. 引言 (Introduction)

2.1 痛点引入 (Hook)

嘿，各位做过 LLM Agent 项目的前端、后端、DevOps 或者 AI 应用开发者们，是不是都踩过这个“死循环”大坑：你花了好几天时间，把一堆知识库文档塞给 Agent，甚至给它写了复杂的 Prompt Chain、工具调用逻辑，刚开始用起来还挺顺——比如你让 Harness CI/CD 里的一个“运维小助手”查下昨天 microservice-order 服务的部署日志，它能精准找到 Kubernetes Pod 的 CrashLoopBackOff；让它分析下 PR 质量报告，能结合 ESLint 规则和单元测试覆盖率给你个不错的建议。

但过了两周？糟了！新上线的 microservice-inventory 日志格式改了，小助手完全认不出；你把 DevOps 规范从 3.0 升到 4.0，它还在给你念旧文档里的“提交前必须手动触发本地 Smoke Test”；更气人的是，上周你让它帮忙修复过的一个 Helm Chart 镜像拉取凭证配置问题，这周它居然问你“凭证通常放在 values.yaml 哪个位置呀？”——合着它是个“金鱼脑”加“活化石”？

这根本不是 LLM 本身能力的问题——GPT-4o 或者 Claude 3 Opus 肯定能理解新规范、新日志、过去的修复经验。问题出在哪？传统的 Agent 架构里，记忆要么是“静态的 RAG 知识库切片”，要么是“短期对话窗里的几百条 Token 限制上下文”，要么是“人工手动维护、更新成本极高的结构化文档”：

• 静态 RAG 知识库切片：你需要定期写脚本爬取、解析、嵌入、存储新数据，慢则几天、快也要几小时，而且知识库越大，检索冗余越高、精准度越差；
• 短期对话窗：超过 Token 窗口（比如 GPT-3.5-turbo 是 16k、普通版 GPT-4 是 8k）的历史对话全丢，根本记不住“两周前、上周三、某个特定 PR 里的某个细节问题”；
• 人工手动结构化：比如你想让 Agent 记住“Helm Chart 凭证配置修复记录”，得手动把每次修复的时间、服务名、问题描述、修复步骤、相关责任人整理成 JSON/YAML 存到数据库里，写一堆复杂的 SQL/GraphQL 查询逻辑——这工作量，运维小助手没帮你省，反而给你加了！

那有没有一种办法，能让 Agent 像人类一样“持续学习”：

• 能自动记录和更新对话、工具调用、知识库访问的所有“关键事件”？
• 能从这些事件里自动提取、抽象、结构化有价值的“经验知识”？
• 能动态检索、筛选、排序这些经验知识，精准匹配到当前的任务需求？
• 甚至能遗忘不重要的信息，避免记忆库爆炸、检索效率下降？

答案是肯定的！这就是我们今天要聊的核心主题：动态记忆更新（Dynamic Memory Update）机制，以及如何在 Harness 这个强大的 DevOps 平台里，把这套机制落地成一个真正“越用越聪明”的 Agent。

2.2 文章内容概述 (What)

本文不会讲那些“飘在天上的理论架构图”，而是会从 0 到 1，手把手带你：

1. 先理解动态记忆更新的核心概念、数学模型、算法逻辑——让你知其然，更知其所以然；
2. 再搭建一个基于 LangChain + Harness SDK + Milvus（向量数据库）+ Redis（短期记忆缓存）的 Agent 原型框架；
3. 然后把这个框架无缝集成到 Harness 平台里：比如让它监听 Harness CI/CD 流水线事件、PR 评论事件、监控告警事件，自动触发记忆更新；
4. 接着实战演示：让 Agent 从一个“只会读初始文档的小白”，在处理了 10 个左右的真实 DevOps 任务后，自动学会新的日志格式、Helm Chart 修复经验、DevOps 新规范，并且能精准复用这些经验；
5. 最后探讨性能优化、边界与外延、行业发展趋势——给你打开一扇门，让你能把这套机制应用到更多场景。

2.3 读者收益 (Why)

读完这篇文章，你将能够：

1. 彻底理解动态记忆更新的底层逻辑：不再是只会用 LangChain 的 ConversationBufferMemory 或者 VectorStoreRetrieverMemory 的“调包侠”，而是能根据自己的业务场景（比如 Harness DevOps、客服机器人、代码助手），自定义记忆的提取、抽象、检索、遗忘策略；
2. 快速搭建一个可复用的动态记忆更新 Agent 框架：我会提供完整的 Python 源代码（包含核心算法、Harness SDK 集成、向量数据库和 Redis 的配置），你只需要改改配置文件，就能用到自己的项目里；
3. 在 Harness 平台里落地这套机制：我会教你如何利用 Harness 的 Webhooks、Events API、Custom Stage、Trigger Templates 这些强大的功能，让 Agent 真正“融入”你的 DevOps 流程，而不是一个“独立的插件”；
4. 应对常见的动态记忆更新问题：比如“知识库检索冗余怎么办？”“短期记忆和长期记忆如何平衡？”“如何让记忆的抽象更符合业务需求？”“如何保证记忆的一致性？”——这些都是我在真实项目里踩过的坑，会给你具体的解决方案。

3. 准备工作 (Prerequisites)

在开始动手之前，你需要具备以下的知识、环境和工具：

3.1 技术栈/知识

3.1.1 核心技术知识

1. Python 基础：熟悉 Python 3.8+ 的语法（比如类、函数、装饰器、异步编程 asyncio），因为我们的 Agent 原型和 Harness SDK 集成都是用 Python 写的；
2. LangChain 基础：熟悉 LangChain 的核心概念（比如 LLM、PromptTemplate、Chain、Tool、Memory、Retriever），不需要你精通所有的 LangChain 组件，但至少要知道如何用 ChatOpenAI 或者 ChatAnthropic 调用大模型，如何用 VectorStore 存储和检索向量；
3. DevOps 基础：熟悉 Harness 平台的基本功能（比如 CI/CD 流水线、PR 评论、监控告警、Webhooks），不需要你是 Harness 认证专家，但至少要知道如何创建一个 Harness 项目、如何配置一个 Webhook、如何调用 Harness 的 REST API；
4. 大语言模型基础：了解什么是嵌入（Embedding）、什么是向量相似度搜索、什么是 Token 窗口、什么是 Prompt Engineering——这些是动态记忆更新的基础；
5. 数据库基础：熟悉 Redis（作为短期记忆缓存）和至少一种向量数据库（比如 Milvus、Pinecone、ChromaDB——本文用 Milvus，因为它是开源的、性能好、容易部署）。

3.1.2 可选但有用的知识

1. LangGraph 基础：如果你想让 Agent 的任务处理流程更复杂、更可控（比如有分支、循环、重试逻辑），LangGraph 会比普通的 LangChain Chain 好用很多——本文会简单提一下，但不会深入；
2. Harness Pipeline As Code (YAML)：如果你想把 Agent 集成到 Harness 的 CI/CD 流水线里，YAML 语法肯定要会；
3. 异步编程进阶：如果你需要处理大量的 Harness Webhook 事件，或者需要并行调用多个工具（比如同时查 Harness CI/CD 日志、监控告警、PR 评论），asyncio 的进阶用法（比如 asyncio.gather、asyncio.Semaphore）会有用；
4. 自然语言处理基础：如果你想自定义记忆的提取、抽象策略，比如用 NER（命名实体识别）提取 DevOps 任务里的“服务名”、“时间”、“问题类型”，NLTK、spaCy、Transformers 这些库会有用。

3.2 环境/工具

3.2.1 本地环境

1. Python 3.8+：建议用 Python 3.10 或者 3.11，因为 LangChain 的最新版本对这两个版本的支持最好；
2. pip 或者 conda：用来安装 Python 依赖包——本文用 pip；
3. Docker 和 Docker Compose：用来部署 Milvus（向量数据库）和 Redis（短期记忆缓存）——如果你不想用 Docker，也可以直接安装 Milvus 和 Redis，但 Docker 会更方便、更不容易出问题；
4. Git：用来克隆本文的示例代码仓库（如果我有的话——即使没有，我也会在文章里提供完整的代码）；
5. 文本编辑器或者 IDE：比如 VS Code、PyCharm——建议用 VS Code，因为它有很多 Python、LangChain、Harness 的插件。

3.2.2 云端/第三方服务

1. 大语言模型 API 密钥：
   • 推荐用 OpenAI GPT-4o 或者 GPT-3.5-turbo（因为便宜、速度快、能力强，而且 LangChain 对它的支持最好）；
   • 也可以用 Anthropic Claude 3 Opus/Sonnet/Haiku，或者 Google Gemini 1.5 Pro/Flash——只需要改改 LangChain 的 LLM 初始化代码；
   • 如果你有本地大模型（比如 Llama 3、Qwen 2、GLM 4），也可以用 LangChain 的 Ollama 或者 HuggingFacePipeline 来调用——本文为了简化，会用 OpenAI GPT-3.5-turbo；
2. Harness 免费账号：
   • 去 Harness 官网 注册一个免费账号，免费账号可以使用 Harness CI/CD、PR 评论、监控告警、Webhooks 等大部分核心功能；
   • 注册成功后，创建一个 Harness 项目，获取你的 API Key 和 Account ID——这些是调用 Harness SDK 或者 REST API 必须的；
3. 可选的云端向量数据库：
   • 如果你不想在本地部署 Milvus，可以用 Pinecone（免费版有 1GB 向量存储、100k 向量索引、5k 检索请求/天）或者 Zilliz Cloud（Milvus 的官方云服务，免费版有 5GB 向量存储、1M 向量索引、10k 检索请求/天）——本文为了简化，会用本地部署的 Milvus。

4. 核心概念：彻底搞懂动态记忆更新

在开始动手写代码之前，我们必须先把动态记忆更新的核心概念、概念之间的关系、数学模型、算法逻辑彻底搞懂——否则你只会是一个“调包侠”，遇到问题根本不知道怎么解决。

4.1 问题背景与问题演变发展历史

4.1.1 问题背景

正如引言里所说的，传统的 Agent 架构（尤其是 RAG 架构）存在三大致命问题：

1. 知识时效性差：静态 RAG 知识库切片需要定期人工或半人工更新，无法实时反映业务的最新变化；
2. 记忆容量有限：短期对话窗受限于 LLM 的 Token 窗口大小，无法记住长期的历史对话、工具调用、知识库访问记录；
3. 记忆精准度低：
   • 静态 RAG 知识库切片的检索方式通常是“纯向量相似度搜索”，没有考虑“记忆的重要性”、“记忆的时效性”、“记忆与当前任务的语义关联强度”、“记忆的来源可靠性”这些因素；
   • 长期记忆（如果有的话）通常是“全部历史记录的平铺”，没有进行任何的“抽象”、“分类”、“关联”，导致检索结果冗余极高、精准度极低。

这些问题在 DevOps 场景（比如 Harness）里尤其突出，因为：

• DevOps 业务的变化非常快：新服务上线、日志格式更新、DevOps 规范升级、工具配置修改——这些变化可能每天、甚至每小时都会发生；
• DevOps 任务的处理非常依赖历史经验：比如“修复 Helm Chart 镜像拉取凭证配置问题”、“排查 Kubernetes Pod CrashLoopBackOff 问题”、“优化 CI/CD 流水线执行时间”——这些任务的解决方案通常不是“读一遍初始文档就能搞定的”，而是需要结合过去的“类似问题的修复记录”、“类似服务的配置经验”、“类似流水线的优化方案”；
• DevOps 场景的信息非常多、非常杂：Harness 平台本身就有 CI/CD 流水线日志、PR 评论、监控告警、资源清单（比如 Kubernetes Pod、Deployment、Service）、工具配置（比如 Docker Registry、Helm Repository、AWS IAM）等大量的信息，再加上外部的知识库文档（比如 DevOps 规范、技术博客、GitHub Issues）——如果没有一套好的动态记忆更新机制，Agent 根本无法从这么多信息里找到有用的东西。

4.1.2 问题演变发展历史

为了解决这些问题，Agent 的记忆架构经历了四个阶段的演变：

4.2 核心概念与概念结构

4.2.1 核心概念

为了方便后续的讨论，我们先定义几个核心概念：

4.2.1.1 记忆实体（Memory Entity）

记忆实体是动态记忆更新机制里的最小存储单元，它包含了一个“有价值的信息片段”的所有属性。

根据记忆的来源和类型，记忆实体可以分为五大类：

1. 对话记忆（Dialogue Memory）：来自用户和 Agent 之间的多轮对话，比如用户的问题、Agent 的回答、用户的反馈；
2. 工具调用记忆（Tool Call Memory）：来自 Agent 调用的各种工具的结果，比如 Harness CI/CD 日志查询结果、PR 评论查询结果、监控告警查询结果、Helm Chart 配置检查结果；
3. 知识库访问记忆（Knowledge Base Access Memory）：来自 Agent 访问的外部知识库的结果，比如 DevOps 规范文档查询结果、技术博客查询结果、GitHub Issues 查询结果；
4. 外部事件记忆（External Event Memory）：来自 Harness 平台的 Webhooks 或者 Events API 的事件，比如 CI/CD 流水线失败事件、PR 评论事件、监控告警触发事件、新服务上线事件；
5. 抽象经验记忆（Abstract Experience Memory）：来自记忆更新引擎对上述四类记忆实体的自动抽象、总结、提炼，比如“修复 microservice-order 服务 Helm Chart 镜像拉取凭证配置问题的经验”、“优化 microservice-payment 服务 CI/CD 流水线执行时间的经验”、“新 DevOps 规范 4.0 里关于 PR 提交前检查的核心内容”。

每个记忆实体都必须包含以下核心属性：

4.2.1.2 记忆库（Memory Store）

记忆库是存储记忆实体的地方，根据记忆的时效性、重要性、使用频率，我们把记忆库分为四个层级：

1. 活跃短期记忆库（Active Short-Term Memory Store）：
   • 存储内容：当前正在进行的对话的所有对话记忆（或者最近的 5-10 轮对话记忆，根据 Token 窗口大小调整），以及 Agent 最近调用的 3-5 个工具的工具调用记忆；
   • 存储介质：Redis 缓存（因为 Redis 的读写速度非常快，适合存储需要频繁访问的活跃短期记忆）；
   • 更新策略：实时更新——每次用户输入一句话、Agent 输出一句话、Agent 调用一个工具，活跃短期记忆库都会立即更新；
   • 过期策略：
     • 对话结束后（比如用户关闭了聊天窗口，或者 30 分钟没有新的对话），活跃短期记忆库的所有对话记忆会被移到“短期对话记忆库”里；
     • 工具调用记忆会在 1 小时后自动过期（除非被标记为重要）；
   • 检索策略：直接检索——因为活跃短期记忆库的内容很少，不需要语义相似度搜索，直接按时间顺序或者重要性顺序检索即可。
2. 短期对话记忆库（Short-Term Dialogue Memory Store）：
   • 存储内容：最近 1-7 天的所有对话记忆（从活跃短期记忆库移过来的）；
   • 存储介质：Redis 缓存（或者结构化数据库 PostgreSQL 的内存表）；
   • 更新策略：
     • 对话结束后，从活跃短期记忆库移过来；
     • 记忆更新引擎会定期（比如每小时）对短期对话记忆库的记忆实体进行重要性评分调整和标签更新；
   • 过期策略：1-7 天后自动过期（可以根据业务需求调整），或者被遗忘引擎移到“归档记忆库”里；
   • 检索策略：
     • 语义相似度搜索：根据当前用户的问题，搜索短期对话记忆库中语义关联强度最高的 3-5 个对话记忆；
     • 时间筛选：只检索最近 N 天的对话记忆；
     • 重要性筛选：只检索重要性评分大于 0.3 的对话记忆。
3. 中期关键事件记忆库（Mid-Term Critical Event Memory Store）：
   • 存储内容：最近 1-6 个月的所有关键事件记忆（包括对话记忆、工具调用记忆、知识库访问记忆、外部事件记忆中重要性评分大于 0.5 的记忆实体）；
   • 存储介质：结构化数据库 PostgreSQL（因为 PostgreSQL 支持复杂的 SQL 查询，适合存储带标签、带关联、带属性的结构化记忆实体） + 向量数据库 Milvus（因为 PostgreSQL 的向量搜索性能不如 Milvus，所以我们把记忆实体的 embedding 存储在 Milvus 里，把其他属性存储在 PostgreSQL 里，通过 memory_id 关联）；
   • 更新策略：
     • 记忆更新引擎会定期（比如每小时）从活跃短期记忆库和短期对话记忆库中，把重要性评分大于 0.5 的记忆实体移到中期关键事件记忆库里；
     • 记忆更新引擎会自动对中期关键事件记忆库的记忆实体进行抽象、分类、关联、标签更新、重要性评分调整；
   • 过期策略：1-6 个月后自动过期（可以根据业务需求调整），或者被遗忘引擎移到“归档记忆库”里，或者被抽象成抽象经验记忆后移到“长期抽象经验记忆库”里；
   • 检索策略：
     • 混合检索：先在 Milvus 里进行语义相似度搜索，找到语义关联强度最高的 10-20 个记忆实体的 memory_id，然后在 PostgreSQL 里根据 memory_id 查询其他属性，再根据时效性、重要性、来源可靠性、标签进行筛选、排序、融合；
     • 关联检索：如果当前记忆实体有 related_memory_ids，可以直接检索相关的记忆实体；
     • 分类检索：根据 memory_type、tags 进行分类检索。
4. 长期抽象经验记忆库（Long-Term Abstract Experience Memory Store）：
   • 存储内容：所有的初始知识库文档（抽象成记忆实体），以及记忆更新引擎从短期对话记忆库和中期关键事件记忆库中自动抽象出来的抽象经验记忆；
   • 存储介质：向量数据库 Milvus（因为长期抽象经验记忆库的内容主要是用于语义相似度搜索的，而且 Milvus 的向量搜索性能非常好） + 结构化数据库 PostgreSQL（用于存储抽象经验记忆的其他属性，比如 tags、related_memory_ids、expiration_timestamp）；
   • 更新策略：
     • 初始知识库文档的抽象：记忆更新引擎会在系统初始化时，或者管理员手动触发时，对初始知识库文档进行分块、嵌入、存储到长期抽象经验记忆库里；
     • 抽象经验记忆的生成：记忆更新引擎会定期（比如每天）从短期对话记忆库和中期关键事件记忆库中，把重要性评分大于 0.7 的记忆实体抽象成抽象经验记忆，存储到长期抽象经验记忆库里；
     • 初始知识库文档的更新：如果初始知识库文档有更新，管理员可以手动触发记忆更新引擎，对更新后的文档进行重新分块、嵌入、替换旧的记忆实体；
   • 过期策略：
     • 初始知识库文档的记忆实体：除非管理员手动删除，否则永久有效；
     • 抽象经验记忆的记忆实体：如果 1-2 年没有被检索到，会被遗忘引擎移到“归档记忆库”里；
   • 检索策略：
     • 混合检索：先在 Milvus 里进行语义相似度搜索，找到语义关联强度最高的 10-20 个记忆实体的 memory_id，然后在 PostgreSQL 里根据 memory_id 查询其他属性，再根据时效性、重要性、来源可靠性、标签进行筛选、排序、融合；
     • 关联检索：如果当前抽象经验记忆有 related_memory_ids，可以直接检索相关的中期关键事件记忆；
     • 分类检索：根据 tags 进行分类检索。
5. 归档记忆库（Archived Memory Store）（可选）：
   • 存储内容：所有被遗忘引擎移过来的记忆实体（比如过期的短期对话记忆、过期的中期关键事件记忆、1-2 年没有被检索到的抽象经验记忆）；
   • 存储介质：对象存储（比如 AWS S3、阿里云 OSS、MinIO）——因为归档记忆库的内容很少被访问，不需要高性能的存储，对象存储的成本很低；
   • 更新策略：遗忘引擎会定期（比如每天）把过期的记忆实体移到归档记忆库里；
   • 检索策略：管理员可以手动触发检索，或者 Agent 在特殊情况下（比如用户明确要求“查找一年前的某个问题的修复记录”）可以触发检索——但检索速度会很慢，因为对象存储的读写速度不如 Redis、PostgreSQL、Milvus。

4.2.1.3 记忆更新引擎（Memory Update Engine）

记忆更新引擎是动态记忆更新机制里的核心组件之一，它负责：

1. 记忆提取（Memory Extraction）：从活跃短期记忆库、短期对话记忆库、工具调用结果、知识库访问结果、Harness 平台的 Webhooks 或 Events API 里，提取有价值的信息片段，生成初始的记忆实体；
2. 记忆嵌入（Memory Embedding）：用大语言模型的嵌入 API（比如 OpenAI text-embedding-3-small、Anthropic Claude 3 Embeddings、Google Gemini Embeddings），给每个记忆实体的 content 生成向量表示，存储在 embedding 属性里；
3. 记忆抽象（Memory Abstraction）：用大语言模型的文本生成 API（比如 OpenAI GPT-3.5-turbo、GPT-4o、Anthropic Claude 3 Sonnet），对中期关键事件记忆库中重要性评分大于 0.7 的记忆实体（或者一组相关的记忆实体）进行抽象、总结、提炼，生成抽象经验记忆；
4. 记忆分类（Memory Classification）：用大语言模型的文本分类 API（或者自定义的分类模型），给每个记忆实体分配 memory_type、tags；
5. 记忆关联（Memory Association）：用向量相似度搜索（或者大语言模型的关联推理 API），找出与当前记忆实体相关的其他记忆实体，把它们的 memory_id 存储在当前记忆实体的 related_memory_ids 属性里；
6. 记忆评分（Memory Scoring）：用大语言模型的评分 API（或者自定义的评分模型），给每个记忆实体计算 importance 评分，根据记忆实体的来源类型自动设置 source_reliability 评分；
7. 记忆存储（Memory Storage）：把生成、更新后的记忆实体存储到对应的记忆库里；
8. 记忆遗忘（Memory Forgetting）：根据记忆实体的 expiration_timestamp、importance 评分、last_retrieved_timestamp（上次检索时间），把过期的、不重要的、很久没有被检索到的记忆实体移到归档记忆库里，或者直接删除。

4.2.1.4 智能记忆检索引擎（Intelligent Memory Retrieval Engine）

智能记忆检索引擎是动态记忆更新机制里的另一个核心组件，它负责根据当前用户的问题（或者 Agent 的任务需求），从活跃短期记忆库、短期对话记忆库、中期关键事件记忆库、长期抽象经验记忆库里，动态检索、筛选、排序、融合有用的记忆实体，生成一个“定制化的上下文”，传给 LLM 用于生成回答或执行任务。

智能记忆检索引擎的核心逻辑是混合检索 + 重排序 + 融合：

1. 混合检索（Hybrid Retrieval）：
   • 先从活跃短期记忆库里直接检索最近的 5-10 轮对话记忆和最近的 3-5 个工具调用记忆；
   • 再从短期对话记忆库、中期关键事件记忆库、长期抽象经验记忆库里，分别进行语义相似度搜索（用 Milvus）、关键词搜索（用 PostgreSQL 的全文搜索功能）、标签搜索（用 PostgreSQL 的数组搜索功能），找到语义关联强度、关键词匹配度、标签匹配度最高的 20-30 个记忆实体；
2. 重排序（Re-ranking）：
   • 用大语言模型的重排序 API（比如 OpenAI GPT-4o Mini、Anthropic Claude 3 Haiku、Cohere Rerank），或者自定义的重排序模型，对混合检索得到的 20-30 个记忆实体进行综合评分，综合评分的计算公式是：
     $$S_{total}=w_{semantic}\times S_{semantic}+w_{keyword}\times S_{keyword}+w_{tag}\times S_{tag}+w_{recency}\times S_{recency}+w_{importance}\times S_{importance}+w_{reliability}\times S_{reliability}$$
     其中：
     • $S_{total}$ 是记忆实体的综合评分，范围：0.0-1.0；
     • $w_{semantic}$、$w_{keyword}$、$w_{tag}$、$w_{recency}$、$w_{importance}$、$w_{reliability}$ 是权重系数，范围：0.0-1.0，且 $w_{semantic}+w_{keyword}+w_{tag}+w_{recency}+w_{importance}+w_{reliability}=1.0$——这些权重系数可以根据业务需求手动调整，也可以用机器学习的方法自动优化；
     • $S_{semantic}$ 是语义相似度评分，范围：0.0-1.0，由 Milvus 的向量相似度搜索返回（比如用余弦相似度，余弦相似度的范围是-1.0-1.0，我们可以把它归一化到 0.0-1.0：$S_{semantic}=(cosine\_similarity+1.0)/2.0$）；
     • $S_{keyword}$ 是关键词匹配度评分，范围：0.0-1.0，由 PostgreSQL 的全文搜索功能返回（比如用 ts_rank 函数，我们可以把它归一化到 0.0-1.0）；
     • $S_{tag}$ 是标签匹配度评分，范围：0.0-1.0，计算公式是：$S_{tag}=(number\_of\_matched\_tags)/(total\_number\_of\_tags\_in\_query)$——如果用户的问题里没有标签，我们可以用大语言模型先从用户的问题里提取关键词作为标签；
     • $S_{recency}$ 是时效性评分，范围：0.0-1.0，计算公式是：$S_{recency}=e^{-\lambda \times (current\_timestamp-memory\_timestamp)/(3600\times 24)}$——其中 $\lambda$ 是衰减系数，范围：0.0-1.0（$\lambda$ 越大，时效性衰减越快），$current\_timestamp$ 是当前的 Unix 时间戳，$memory\_timestamp$ 是记忆实体的创建时间的 Unix 时间戳，$(current\_timestamp-memory\_timestamp)/(3600\times 24)$ 是记忆实体的创建时间距离现在的天数；
     • $S_{importance}$ 是重要性评分，范围：0.0-1.0，直接取记忆实体的 importance 属性；
     • $S_{reliability}$ 是来源可靠性评分，范围：0.0-1.0，直接取记忆实体的 source_reliability 属性；
   • 然后按照综合评分从高到低排序，取前 5-10 个记忆实体（根据 Token 窗口大小调整，确保定制化的上下文加上用户的问题、Prompt Template 等其他内容，总 Token 数不超过 LLM 的 Token 窗口大小的 80%——留出 20% 的 Token 数给 LLM 生成回答或执行任务）；
3. 融合（Fusion）：
   • 把重排序后的 5-10 个记忆实体的 content 按一定的格式（比如 Markdown 的列表格式）融合成一个“定制化的上下文”；
   • 同时，把这些记忆实体的 tags、related_memory_ids 等属性也融合到上下文里（可选，取决于业务需求）。

4.2.2 概念结构与核心要素组成

为了更直观地理解动态记忆更新机制的概念结构，我们可以画一个分层架构图：

4.3 概念之间的关系

为了更直观地理解动态记忆更新机制中各个核心概念之间的关系，我们可以画一个ER 实体关系图和一个交互关系图。

4.3.1 ER 实体关系图（mermaid 架构图）