一.⼈⼯介⼊（Human-in-the-Loop/HITL）
1.什么是⼈⼯介⼊
a.HITL(⼈在回路）
Human-in-the-Loop 是指在 AI Agent 或⾃动化系统中引⼊⼈类的监督、⼲预或审批环节。当 Agent遇到不确定、⾼⻛险或需要判断的任务时，会主动暂停、向⼈类请求输⼊或确认，⼈类完成⼲预后系统再继续运⾏。其核⼼作⽤是提升安全性、降低错误⻛险，并能将⼈的知识和直觉融⼊⾃动化流程中。
核⼼逻辑：AI提供预判，但最终决策权/执⾏权必须经⼈⼯确认。系统是“助理”，⼈是“审批流”的必经节点。
⽐如你买完单，⼿机⾃动识别你的脸。如果识别清晰、⾦额⼩，直接⽀付（Agent⾃动）；但如果⾦额超过500元，⼿机会弹窗让你 输⼊⽀付密码或按指纹确认 —— 这就是“把⼈拉进来决策”，防⽌误刷。
b.HOTL（⼈在环上——监督与叫停模式）
运作逻辑：AI先全⾃动执⾏，⼈类不参与每⼀个决策，但保留“紧急制动”和“宏观调参”的权限。系统持续运⾏，⼈类在旁边实时监控仪表盘，只有当AI的置信度跌破阈值、或检测到异常指标时，⼈类才“拍下暂停键”接管，或调整策略后让AI继续。
核⼼区别：HITL是“必须等你点头才能继续”（阻塞式）；HOTL是“你先⼲着，我盯着，出⼤事我叫停”（⾮阻塞式）。
核⼼逻辑：AI负责99%的常规操作，⼈负责监控⻓尾⻛险和策略调参。⼈是“空中交通管制员”，不指挥每⼀次起降，但管航路和应急处置。
⽐如⾃动驾驶 L3 级别：⻋辆正常时⾃⼰开，驾驶员不需要碰⽅向盘（⼈在环上监控路况）；但当系统检测到前⽅施⼯且路径模糊时，会发出警报要求驾驶员⽴即接管。
c.HOOTL（⼈在环外——完全⾃治模式）
运作逻辑：⼈类彻底退出运⾏链路。系统不向⼈类请求实时输⼊，也不接受实时覆盖。⼈类只在系统设计、训练、部署前设定好终极⽬标和约束条件，上线后⼀切决策由AI⾃主完成，且没有暂停键（或暂停键有极⾼的延迟）。
核⼼区别：HITL和HOTL⾥“⼈还在场”，HOOTL⾥⼈已经离场，系统完全依赖初始设定的规则和⾃学习进化。
核⼼逻辑：⼈是“⽴法者”，AI是“执法者”。系统上线后不依赖任何实时⼈类输⼊，⼀切依赖预设的奖励函数和约束边界。
⽐如⾼频量化交易：算法以微秒级执⾏买卖，⼈类根本来不及反应，⼀旦启动就全⾃动运⾏（但事先设定了最⼤亏损熔断线）。
2.为什么⼈⼯介⼊
这是一张关于 HITL（Human-in-the-Loop，人机回环） 的说明表格，展示了在不同场景下AI的局限性以及人类介入的必要性。
总⽽⾔之，⼈⼯介⼊并⾮要取代AI，⽽是构建了⼀种“⼈机协同”的伙伴关系：AI负责⼴度和效率，⼈类负责深度和良知。
在未来，好的设计不是追求“零介⼊”，⽽是追求“精准介⼊”——即在关键决策点引⼊最⾼质量的⼈类判断，⽤最⼩的⼲预成本，换取最⼤的系统安全性和社会信任度。
3.⼈⼯介⼊的基本⼯作流程
举个发票的例子进行说说明：
用户查询 --> Agent：财务人员说"帮我审核今天报销的50张发票"
LLM思考层：AI自动识别每张发票的公司名称、税号、金额、日期、发票代码
判断是否需要人工介入：AI检查是否有异常情况
无需介入则执行：所有发票信息完整金额正常，AI自动标记审核通过完成入账
需要介入则触发断点：发现某张发票金额10万超出常规或税号不匹配或发票代码查不到，触发人工介入
保存现场：AI记录已审核49张卡在第50张，发票代码XXX金额10万系统识别为可疑
人工介入：财务主管收到通知人工查看这张发票
三种处理方式：同意则主管确认特殊业务AI继续执行通过；拒绝则主管发现假发票拒绝报销AI记录驳回原因；编辑完善信息则主管发现税号少一位修正后AI继续处理
恢复现场：AI从第50张发票继续按主管决策完成后续操作
执行：全部50张发票处理完毕生成最终审核报告
⼈类审核时往往有3种选择，每种对应不同的 Agent ⾏为：
4.HITL 的核⼼步骤
HITL模式主要有三步：
- 中断：流程在重要节点先暂停，不继续执⾏。
- 保存：把现场所有状态都记住，⽅便后续恢复。
- 恢复：等⼈类审核确认后，流程再接着⾛。
5.HITL 的触发机制
触发机制是 HITL 的⻔禁，常⻅的有四种逻辑：
- 敏感动作触发 (High-Stakes Actions)： 涉及转账、删除数据、法律协议签署等不可逆的“红线”操作。
- 业务逻辑触发 (Guardrails)： 违反了预设的硬规则（如：预算超标、字数超限、包含敏感词）。
- 异常死循环触发 (Loop Detection)： AI 连续多次尝试同⼀错误操作⽆法跳出时，强制请求⼈⼯接管。
- 低置信度触发 (Low Confidence)： AI 对当前决策的概率评分低于设定阈值（例如 P < 0.8）。
6.实战-体验下⼈⼯介⼊
提示词如下：
# 项⽬：个⼈导航⽹站
## 项⽬背景
我需要⼀个简洁、美观的个⼈导航⽹站，⽤来集中管理⽇常⼯作和学习常⽤的⽹站链接。
## 核⼼功能需求
1. **⽹站展⽰**：以卡⽚⽹格展⽰所有⽹站，卡⽚包含名称、⽹址和图标。
2. **优先级排序**：⽀持设置“⾼、中、低”优先级，⾼优先级排在前⾯。
3. **点击统计**：⾃动记录每个⽹站的点击次数，并⽀持按点击量排序。
4. **数据持久化**：使⽤浏览器的 `localStorage` 保存数据，刷新不丢失。
## 技术约束
- 纯前端：HTML + CSS + JavaScript。
- 界⾯适配移动端和桌⾯端。
## ⾮功能需求
- 加载速度快，UI 现代简洁。
## ⼯作流要求
1. **计划⽣成与⽂件输出**：在编写任何代码前，请先分析需求并⽣成⼀份详细的开发计划（包含技
术选型、UI设计、数据结构、实现步骤）。**除了在对话中输出计划摘要外，你必须同时将完整的计划
内容写⼊项⽬根⽬录下的 `plan.md` ⽂件中**（如果项⽬没有根⽬录，则在当前⼯作区根⽬录创
建）。计划⽂件应使⽤标准 Markdown 格式，结构清晰。
2. **暂停等待确认**：完成计划输出和⽂件写⼊后，**必须暂停**，明确提⽰“计划已写⼊
plan.md，请审核确认后再继续”，等待我审核或提出修改意⻅。在我明确回复“确认”之前，不得开始
编码。
3. **确认后⾃动执⾏**：在我确认后，请⼀次性完成全部代码开发，⽆需中途汇报。如果我需要调
整，会随时主动提出，你可以随时响应并修改。1. 我们启动Trae，Agent模式搭建⼀个个⼈导航⽹站
新建文件选择Agent模式
2. 可以看到计划已经写⼊到⽂件
3. 明确提出来需要我们审核⽅案
4. 我们审核⽅案问题，进行提示修改：
⽅案有问题
1. 我们连不上⾕歌
2. 明确⽣成50条以上的演⽰数据，需要看下效果5. 等待⽅案更新
6. 更新完成后，我们检查⽅案没有问题就开始执⾏
7. 我们看下效果
二.记忆管理（Memory）
1.Memory是什么
Agent Memory，即AI智能体的记忆系统，是专⻔为AI智能体（Agent）设计的、能够跨会话、跨任务持久保留和召回信息的外部记忆机制.
没有记忆的Agent，就像⼀位每天重置的临时⼯——你每次开⼝，他都会礼貌地问：“您好，请问您贵姓？”你告诉他“姓王”，五分钟后换了个话题，他再问：“您好，请问您贵姓？”他从不留任何记
录，每⼀次对话都是全新的开始。
有记忆的Agent，则像⼀位随⾝携带“全能档案夹”的专属秘书：
- ⽐如你今天跟他说“我喜欢靠窗的座位”“对芒果过敏”，他当场记下；明天你再让他订机票，他会直接问：“还是靠窗吗？”后天你让他推荐餐厅，他会主动提醒：“您对芒果过敏，这家甜品没有芒果，可以放⼼。”
- 更厉害的是，这个档案夹是持续累积的——你三个⽉前随⼝提过“讨厌嘈杂的环境”，现在让他找咖啡馆，他会避开热⻔⽹红店，只推荐安静的⻆落。他不需要翻什么“笔记本”或“便签”，只需看⼀眼那本统⼀的档案，所有信息⾃然浮现。
2.为什么需要记忆
1. LLM没有状态
⼤语⾔模型从根本上是⽆状态的。发送⼀条消息产⽣⼀个回复，每次新对话都是⼀块⽩板。
这是因为模型本⾝就是⼀个巨型函数：输⼊进去，token 出来，模型权重中没有任何持久化存储能在会话之间保留对话历史。简单聊天机器⼈不在乎这⼀点。让它写⼀封求职信，写完就结束不需要连续性。
Agent ⾯对的情况截然不同。它们需要处理⻓期运⾏的任务，在时间推移中学习⽤⼾偏好，跨多个会话与其他 agent 协作。⽆状态性构成了根本性障碍，没有⼈能接受⼀个每周⼀早上都要重新⾃我介绍的个⼈助理。
2. 上下⽂问题
最初业界认为可以⽤巨⼤的上下⽂窗⼝填满所有信息，但现实击碎了这种幻想：
- 上下⽂腐烂：当上下⽂中包含⼤量与当前任务⽆关的信息时，模型需要在更⼤的信息空间中寻找相关内容，注意⼒资源被分散，容易出现关键信息遗漏、指令遵循能⼒下降以及推理质量下降等问题，⽐如你塞给它 100 万字的对话历史，⾥⾯ 99% 是废话、重复、⽆关信息。模型看花了眼，注意⼒被稀释，该记住的关键信息（⽐如“⽤⼾要求⽤摄⽒度⽽不是华⽒度”）反⽽被淹没了。
学术界常⻅现象：
- Lost in the Middle（中间内容遗忘） ：当关键信息位于上下⽂窗⼝的正中间时，模型的召回率（准确率）会跌到最低点，甚⾄不如把关键信息放在开头（Primacy效应）或结尾（Recency效应）。
- Attention Dilution（注意⼒稀释） ：当⽆关的废话越多，模型就必须把原本集中在“关键信息”上的概率权重，强⾏分给成千上万个⽆意义的词语（如“的、了、嗯、⽽且”）。
- Context Interference（上下⽂⼲扰）：⽆关信息不仅仅占位置，它们包含的语义特征（Semantic Features）在模型的向量空间中与有效信息产⽣了负向交互（NegativeInterference）。你给⼀群⼈开了个“跨部⻔辩论会”。第⼀个发⾔的⼈说“⽤⼾喜欢简洁答案”，第⼆个⼈说“⽤⼾是⾏业专家，需要详尽分析”，第三个⼈⼜说“⽤⼾今天赶时间，越快越好”。它们三个在会议室⾥互相打架。
研究者将这种现象称为“上下⽂腐烂”（Context Rot）。它的本质不是“信息变旧了”，⽽是
“信噪⽐（Signal-to-Noise Ratio）急剧下降”。当上下⽂膨胀时，模型的注意⼒头（Attention
Heads）被迫分配⼤量权重去处理⽆关的噪⾳。结果就是，模型为了“看完”所有内容，不得不压
缩信息的内部表征（Representation Compression），这种压缩过程会直接抹去细微但关键的⽤
⼾偏好（⽐如你喜欢的摄⽒度，或者⽤⼾名的⼤⼩写规则）。
- 检索昂贵：⻓上下⽂检索成本呈指数级增⻓，计算复杂度通常随上下⽂⻓度呈平⽅增⻓，上下⽂越⻓，模型定位相关信息的代价越⾼。每次你问 AI ⼀个问题，它都要把整个⼯作台上的所有东西从头到尾捋⼀遍，才能找到和问题相关的⼏⾏字。⼯作台越⼤，它捋得就越慢、越费劲。
- 成本失控：每个请求都携带⼤量历史token，费⽤迅速累积。你每说⼀句话，AI 都要把之前所有的对话历史（哪怕是⼀年前的废话）重新打包，⼀起发给⼤模型处理。就像你每次倒⼀杯⽔，快递员都要把你家整个游泳池的⽔⼀起运过去。
3. 追踪⻓期⽬标，胜任复杂任务
许多现实任务不是⼀次性的。任务连续性：Agent需要记住“任务进⾏到哪⼀步了”，⽐如订机票-->选座位-->⽀付，或“哪些⽅案已经被否决过”标⼀致性：确保在跨越数天、数周的任务中，Agent的
⾏为和决策始终围绕最终⽬标，保持⼀致
4. 构建个性化画像，从“通⽤”⾛向“专属”
当Agen能够回忆过去的对话时，它感觉更个⼈化、更协作。情感连续性建⽴信任，改变⼈类对AI的感受。
看个简单的例⼦
- 失忆AI（机械）：你深夜说“我最近特别焦虑，感觉做什么都做不好”。它回复：“焦虑是常⻅的情绪，建议深呼吸，转移注意⼒……”——虽然正确，但像在听录⾳机。
- 记忆AI（共情）：它回复：“记得上个⽉你搞定那个难缠客⼾时，也说过同样的‘做不好’。但后来你复盘时发现，其实是你对⾃⼰要求太⾼了。今天是不是⼜遇到类似‘全盘否定⾃⼰’的瞬间了？要不要像上次那样，我们先把⼤⽬标拆成三个今天能做的⼩事？”
3.记忆分类
学术界和⼯程界最常⻅的分类，是借鉴⼈类认知科学的⼆分法：短期记忆和⻓期记忆。
a.短期记忆
在 Agent 的语境下，短期记忆指的是在当前⼀次对话或任务执⾏过程中，临时存储的、上下⽂相关的信息。
- 核⼼作⽤：维持对话的连贯性，⽀撑多步推理。
- 技术本质：它通常就是⼤语⾔模型的上下⽂窗⼝（Context Window）内的内容。例如，你们刚刚聊的对话、当前⽤⼾提供的临时指令（“帮我查⼀下明天北京的天⽓”），都会被放在这个“⼯作台”上。
- 特点：
- 容量有限：受限于模型⽀持的最⼤ tokens 数（如 4K、128K、1M）。
- ⽣命周期短：对话结束时，这部分记忆通常被直接清除（不保存到数据库）。
- 访问极快：直接作为输⼊的⼀部分传给模型，⽆需检索。
短期记忆你正和朋友坐在咖啡厅聊天。你们正在说的这⼏句话，以及前五分钟聊过的话题。因为都在脑⼦⾥转，所以你说话⾮常连贯，不会前⾔不搭后语。
b.⻓期记忆
⻓期记忆指的是跨会话、持久化存储的信息，包括⽤⼾的历史⾏为、偏好、事实知识等。
- 核⼼作⽤：实现个性化、持续学习与知识积累。
- 技术本质：通常通过外部向量数据库（如 Chroma、Pinecone）或传统数据库实现。Agent 会在需要时，根据当前问题去检索相关的历史记忆⽚段。
- 特点：
- 容量近乎⽆限：理论上可以存储海量信息。
- ⽣命周期⻓：可以保存数天、数⽉甚⾄永久。
- 访问较慢：需要经过“检索-排序”的过程，不能直接使⽤。
⻓期记忆在⼼理学上⼜分为以下⼏类
1.语义记忆
- 定义：存储客观事实、概念、知识，与个⼈经历⽆关。
- 特点：就像⼤脑⾥的百科全书，告诉你“世界是什么样的”。
- Agent 例⼦：
助⼿知道“勾股定理是 a² + b² = c²”、“⽔的沸点是 100°C”、“Paris 是法国的⾸都”。
这些知识是通⽤的，不关⼼“是谁、什么时候”学到的。
2.程序记忆
- 定义：存储如何做某件事的技能、流程、习惯。
- 特点：通常难以⽤语⾔说清楚（内隐记忆），是“知道怎么做”⽽不是“知道是什么”。
- Agent 例⼦：
助⼿如何调⽤天⽓ API：先获取城市代码 --> 拼接 URL --> 解析 JSON 返回温度。
这些“操作流程”就是程序记忆。
3.情景记忆
- 定义：存储个⼈经历的特定事件，包括时间、地点、情绪。
- 特点：⾃传体式的记忆，告诉你“我经历过什么”。
- Agent 例⼦：
助⼿记得：“昨天下午3点，⼩明问过我⼀个⽅程 2x+5=15，他当时要求我解释每⼀步。”
或者：“上周⼆，⽤⼾抱怨过推荐算法不准，后来他⼿动选了⼀部科幻⽚。”
简单理解：
- 语义记忆 = What（是什么）
- 程序记忆 = How（怎么做）
- 情景记忆 = When/Where/Who/What（在什么时间、地点，谁经历了什么事）
4.短期记忆与⻓期记忆的区别
5.短期记忆的处理
短期记忆就是当前对话的⼯作台。策略的核⼼是：在有限的窗⼝⾥，只放最精华的信息。
常⻅的处理策略:
- 滑动窗⼝：只保留最近 N 轮对话，更早的⼀⼑切扔掉。
- Token 截断：只保留最近 N 个 token
- 摘要：不直接扔掉旧对话，⽽是让模型定期把“⽼对话”压缩成⼀段简短摘要。保留摘要 + 最近⼏轮原始对话。
- 过滤：不按轮数或 token 数切，⽽是识别关键信息（实体、指令、数字、偏好）单独提取出来，存到⼀个“关键信息⼝袋”⾥，普通对话内容直接删
在真正的⽣产环境中，这四种逻辑单独使⽤都有缺陷，但组合起来就是⽆敌的。当前最先进的短期记忆处理范式是“三层记忆架构”：
- 底层（缓存层）：使⽤ 滑动窗⼝ 保留最近 5-10 轮原始对话，保证模型对当前话题的流畅接话。
- 中间层（摘要层）：对窗⼝之外的较早对话，采⽤ 滑动摘要（每隔 N 轮将旧摘要+新对话合并⽣成新摘要）。
- 顶层（事实层）：贯穿全程使⽤ 信息过滤，实时维护⼀个“事实⼝袋”（User Profile），并随对话动态更新。
这张图展示了一种大模型分层记忆方案，整个流程分为记忆更新和模型推理两个阶段。
在记忆更新阶段，用户发来新消息后由消息分发器分成三路处理：
- 缓存层保存最近 5‑10 轮原始对话，轮数过多就删掉最早的记录；
- 摘要层把旧摘要和新对话合并压缩，生成简短的对话梗概；
- 事实层提取实体、爱好、关键数字，保存成结构化的用户画像。
在模型推理阶段，上下文组装器按照优先级调取记忆：优先读取事实层，其次读取摘要层，最后读取缓存层，再加上固定系统提示词，一起交给大模型生成回答并返回给用户。
简单来说，系统把对话分成短期原始记录、中期对话梗概、长期用户信息三类记忆，提问时按重要程度加载记忆，让大模型在长对话里记住更多内容。
⼀个特别值得警惕的坑：
“Token 截断”和“滑动窗⼝”会导致“顺序反转”问题。如果从最早的消息开始截断，模型会丢失
“初始系统指令”（System Prompt）。所以通常的⼯程做法是：System Prompt 和“关键信息⼝
袋”永远锚定在窗⼝最前⾯，绝不参与滑动或截断，只把⽤⼾和助⼿的普通聊天内容拿去滚动。
6.⻓期记忆的基本⼯作流程
⻓期记忆是跨会话的、持久化存储的信息，⽬标是在未来的、新的对话中，能够被检索并注⼊到上下⽂窗⼝⾥。它的处理⽅式不只是在当前窗⼝⾥“裁剪”或“压缩”，⽽是围绕 “存储、更新、检索、遗忘” 这些个核⼼动作展开。
1.存储/写⼊
⽬标
将对话中的关键信息、⽤⼾偏好和任务进度，经结构化处理后，持久化写⼊对应的记忆存储层（如向量库、图数据库或关系型数据库），供后续跨会话检索使⽤。
触发时机
| 触发类型 | 具体场景 | 处理方式（结合三层记忆架构） | 示例 |
|---|---|---|---|
| 显式指令 | 用户主动要求系统记住某条信息 | 提取关键信息存入事实层，更新用户结构化画像 | “记住我叫小明”、“我喜欢科幻片，帮我记一下” |
| 短期记忆溢出 | 上下文窗口即将满载，容纳不下更多对话 | 自动提取对话核心要点，压缩后存入摘要层 | 多轮长对话后，系统提炼重点保存到长期梗概中 |
| 会话终止 | 用户结束对话或者聊天超时 | 对本次全部对话生成完整摘要，归档保存至摘要层 | 用户发送 “再见”，系统自动整理本次对话摘要存档 |
| 高频信号 | 同一偏好、事实在对话里反复多次出现 | 识别稳定不变的信息，写入事实层长期保存 | 多次提到使用 Python，达到次数后自动记录用户偏好 |
| 定期反思 | 每日或者每周定时执行复盘任务 | 分析历史日志，总结用户习惯与需求模式，更新事实层 | 每周复盘发现用户常在周日询问理财问题，记录周期性需求 |
注意：所有类型触发后都会进入记忆更新阶段，由消息分发器完成分层存储；模型推理时，系统按事实层＞摘要层＞缓存层的优先级读取记忆，拼接系统提示词交给大模型生成回答。
写⼊动作（具体怎么存？）
每个写⼊操作都需要经过以下⼏步：
- 类型归类（语义/情景/程序）。
- 冲突检测与合并（保持不变）。
- 差异化索引构建（根据类型分流）：
- 若为 固定属性（标量）→ 构建 B-Tree索引（存SQL）；
- 若为 模糊偏好/⻓⽂本（需理解含义）→ 构建 向量索引（存Vector DB）；
- 若为 实体关系数据→ 构建 知识图谱（存图数据库库）。
存储数据库
- 向量数据库（这个后面会有具体的章节在讲）
- 关系数据库
- 图数据库
DB-Engines Ranking - popularity ranking of graph DBMS
2.更新
⽬标
修正或取代Agent⻓期记忆中的过时、错误或⽤⼾偏好变更的信息，同时保留历史变更轨迹，确保记忆的准确性与可追溯性。
触发时机
⼯作过程
1. 找到要修改的那条旧记忆
系统会从所有存储的记忆中，把⽤⼾提及的那条旧记忆精准找出来（⽐如通过关键词、时间、场景
等）。
2. 判断新信息属于哪⼀类
新来的更正信息，需要先判断它是什么类型：
- 是客观事实（如姓名、⽣⽇、城市）？
- 是主观偏好（喜欢的⻝物、讨厌的⻛格）？
- 还是可重复使⽤的⽅法（⽐如“做PPT时先列⼤纲”）？
不同类型的信息，后续处理⽅式会略有不同。
3. 决定如何处理冲突
如果新旧信息有⽭盾，系统按以下顺序做决定：
a. ⽤⼾今天亲⼝说的优先于过去说的（因为⼈可能改变主意）。
b. 如果新信息更加具体（⽐如“我不喜欢《流浪地球》”），⽽旧信息⽐较宽泛（“我喜欢科幻
⽚”），那我们会保留宽泛的，同时把具体的特例记下来。
c. 如果新旧信息的来源可信度不同（⽐如来⾃权威资料 vs ⽤⼾随⼝⼀提），取更可信的个。
d. 如果以上都差不多，则以时间最新的为准。
4. 保存更新，并保留历史
- 我们不会直接覆盖旧记忆，⽽是把旧记忆标记为“已过期”，同时写⼊⼀条新记忆，并附上“本条替代了哪条旧记忆”的说明。
- 这样任何时候都能回头查看这条记忆的演变过程。
- 如果新信息只是对旧记忆的补充（没有⽭盾），就直接附加进去，不影响原有的。
3.检索/读取
⽬标
根据当前⽤⼾查询和上下⽂，从⻓期记忆中⾼效、精准地检索出最相关的历史信息，并注⼊到短上
下⽂窗⼝中，以⽀持当前对话。
触发时机
检索⽅式
在实际⼯程中，常采⽤混合策略：结合向量相似度检索和结构化查询，前者通过嵌⼊匹配找到语义相近的记忆⽚段，后者可针对知识图谱执⾏精确匹配，有效降低漏检⻛险。
降级策略（检索失败时的处理）
4.遗忘
⽬标
通过主动或被动策略，淘汰过时、低价值或违反隐私规定的记忆，控制存储规模，维持检索的信噪
⽐。
触发时机
| 触发类型 | 主动 / 被动 | 具体场景 | 处理方式（结合三层记忆架构） | 示例 |
|---|---|---|---|---|
| 精确删除 | 主动 | 用户要求遗忘某一条具体记忆 | 定位并删除事实层 / 摘要层中指定的单条记忆，保留其余内容 | “忘掉我刚才说的那个地址”、“把刚才那条记录删了” |
| 遗忘全部 | 主动 | 用户要求删除所有个人信息 | 清空事实层全部用户画像数据，清除本次会话摘要，触发隐私合规流程，需要二次确认 | “忘记所有关于我的事”（触发隐私合规流程，需二次确认） |
| 时间衰减 | 被动 | 某条记忆超过 90 天未被访问 | 后台扫描，将长期不用的记忆标记为待清理候选，逐步淘汰陈旧信息 | 系统每日后台扫描，自动标记长期未使用的记忆为候选 |
| 低访问频率 | 被动 | 某条记忆每月被调取不足 1 次 | 识别长期很少用到的记忆，降低优先级，列入清理候选 | 低频记忆可能价值较低，进入候选 |
| 容量限制 | 被动 | 记忆总量达到系统存储上限（10^6） | 按照重要性分数从小到大，删掉价值最低的多条记忆，释放存储空间 | 删除重要性分数最低的 M 条记忆 |
处理步骤
1.触发检测：检查是否满⾜遗忘条件（主动指令或被动策略）
2.筛选候选：根据条件查询出待遗忘的记忆ID列表
3.执⾏遗忘：
- 硬删除：物理删除，不可恢复
- 软删除：标记为已删除，检索时跳过
- 降权：降低检索得分系数（如乘以0.2），但仍可能被召回
4.级联处理：若删除的记忆存在关联依赖，同步处理关联记忆
5.⽇志记录（可选）：记录遗忘操作及原因，供后续审计追溯
7.记忆开发框架
| 名称 | 简介 | 地址 |
|---|---|---|
| Mem0 | 业界广泛应用的核心记忆层，专注于长期记忆管理和个性化 AI。它将记忆编排、检索与知识图谱结合，能节省 90% 以上的 token 成本，并支持细粒度的用户 / 会话隔离和结构化更新 | GitHub：https://github.com/mem0ai/mem0官网：https://mem0.ai |
| LangMem | LangChain 团队推出的专属记忆 SDK，深度集成 LangGraph 生态。它同时提供了 “热路径工具” 用于对话中的实时记忆，以及 “优化技巧” 用于长期优化 Agent 行为（如更新系统提示词） | GitHub：https://github.com/langchain‑ai/langmem |
| Zep | 构建动态的 “时序知识图谱”，擅长记忆信息间随时间变化的复杂关系，并始终保持高效检索 | GitHub：https://github.com/getzep/zep官网：https://www.getzep.com |
| TencentDB Agent Memory | Agent 记忆服务（TencentDB Agent Memory）由腾讯云数据库团队从底层完全自研。作为一款独立的记忆管理底座，它原生提供自动写入、分层沉淀、按需召回与治理增强等核心能力。强力支撑智能体在跨会话、长周期、多任务场景中持续沉淀业务知识，保障上下文的连续性，并使记忆资产具备更全局维度的管理与高效复用能力。 | https://cloud.tencent.com/product/agm |
| Polar Agent Memory | Polar Agent Memory 是部署于 PolarDB for AI 节点的长期记忆引擎，通过向量数据库与知识图谱双模存储，将历史对话中的关键信息持久化，并在后续会话中自动检索、更新和关联，使大模型具备跨会话的个性化记忆能力。 | https://help.aliyun.com/zh/polardb/polardb‑for‑mysql/polardb‑agent‑memory?spm=a2c4g.11186623.help‑menu‑2249963.d_5_2_4_6.6f4166ea nvPwqX&scm=20140722.H_3015094…OR_help‑T‑cn~zh‑V_1 |
| AgentKit Memory | AgentKit Memory 为 Agent 提供企业级的长期记忆管理能力。通过统一接口对接主流记忆库框架（mem0、Viking 等），帮助 Agent 实现跨会话的上下文感知、个性化交互和持续学习与演进。 | https://www.volcengine.com/docs/86681/1844843?lang=zh |
| Letta (原 MemGPT) | 借鉴操作系统内存管理思想，让 Agent 将上下文窗口视为有限内存，通过自主调用 “记忆工具” 实现管理，支持跨会话的持久化。作为记忆领域的元老级框架，它更具系统架构层面的灵活性 | GitHub：https://github.com/letta‑ai/letta官网：https://www.letta.com |
| MemOS | 从 “操作系统” 高度管理 AI 记忆的全栈框架，将记忆提升为一级计算资源，采用分层架构实现统一调度、更新与演化 | https://github.com/MemTensor/MemOS |
大致说明：
- Mem0：社区成熟、开箱即用，自带记忆增删改查，论文 / 毕业设计首选。
- Letta（MemGPT）/MemOS：主打分层内存管理思想，和三层记忆架构理论契合度最高，适合做架构分析、原理研究。
- LangMem：仅限 LangChain/LangGraph 项目，生态绑定强。
- Zep：优势是时序知识图谱，适合带有时间线记忆场景。
- TencentDB / PolarDB / AgentKit Memory：云厂商商用服务，适合企业开发，不适合本地部署实验。
8.实战-Mem0记忆体验
1. 登录mem0官⽹(Mem0 - AI Memory Layer for your Agents & Apps | Persistent Context)
2. 点击Start For Free进⾏注册
3. 我们可以使⽤⾕歌账号或者⾃⼰的邮箱完成
这是登陆后的界面：
点击dashboard的页面表示我们发了多少请求，因为我是第一次注册所以，requets显示为0
点击docs：
点击API reference有各种各样的记忆：
4. 进⼊后我们点击Playground
5. 我们进⼊⼀个体验环境
6. 我们输⼊下⾯的提示词
我叫hjq。我每天下午17:00有个内部沟通会议，给我⼀个会议模板参考点击add memories:
点击search memories:
可以看到回复信息
扫一扫
1761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
