插拔式AI记忆增强协议：模型无关的外置记忆系统

1. 项目概述：不是“插件”，而是一套可即插即用的AI记忆增强协议

你有没有遇到过这样的情况：用一个大模型写周报，写到第三段突然忘了第一段提过的客户名字；调试一段Python代码，刚在终端里查完某个库的版本号，转头写requirements.txt时又得重新敲一遍命令；甚至只是和朋友聊旅行计划，前一秒说好去京都，后一秒打开机票App却记不清是岚山还是伏见稻荷——这些都不是你记性差，而是当前绝大多数AI系统根本就没有“记忆”这个概念。它们像一位极度专注但只有三秒记忆的专家，每次对话都从零开始，不记得上一句你问了什么，更不会主动关联三天前你提过的项目背景。这就是标题里“This Plug-and-Play AI Memory Works With Any Model”真正要解决的问题：它不是给某个特定模型（比如GPT-4或Claude 3）打补丁，也不是封装一个新API，而是一套与底层模型完全解耦的记忆增强协议。我把它理解为给AI装上了一块“外置缓存硬盘”——这块硬盘不依赖CPU型号（即不绑定模型架构），不挑主板插槽（即不依赖部署框架），只要你的AI系统能接收文本输入、输出文本响应，就能把这块“硬盘”接上去，立刻获得跨会话、跨任务、可检索、可更新的长期记忆能力。核心关键词——插拔式（Plug-and-Play）、模型无关（Any Model）、记忆增强（AI Memory）——每一个词都直指当前AI应用落地中最痛的软肋。它适合谁？如果你正在用LangChain做客服机器人，却苦于用户反复问“我上次投诉的单号是多少”；如果你在用Llama 3搭建内部知识库，却无法让模型记住“张工上周提交的报销流程已简化”；甚至如果你只是用Ollama本地跑Phi-3写小说，希望角色设定能自动延续到下一章——那你就是这个方案最直接的受益者。这不是一个炫技的Demo，而是把“AI该有记忆”这件事，从论文里的模糊构想，变成了工程师可以今天下午就clone下来、改两行配置、明天就上线的生产级能力。

2. 内容整体设计与思路拆解：为什么必须“模型无关”，又如何做到“即插即用”

2.1 根本矛盾：模型原生记忆能力的三大硬伤

要理解这个方案的设计哲学，得先看清现有技术栈的结构性缺陷。目前主流的“记忆”实现，基本逃不出三类，但每一类都带着无法忽视的镣铐：

• 第一类：模型微调（Fine-tuning）嵌入记忆。比如在训练数据里塞入大量“用户历史对话”样本，让模型学会从上下文中提取信息。问题在于：这相当于给汽车发动机重新铸造缸体来适应不同油品——成本极高、周期极长、且一旦模型升级（比如从Qwen2-7B换成Qwen2.5-7B），所有微调工作全部归零。我去年帮一家电商公司做过测算，仅为了支持500个VIP客户的个性化推荐记忆，微调一次Qwen2-7B的成本就超过8万，还不算后续维护。

• 第二类：RAG（检索增强生成）强行“借脑”。这是目前最流行的方案，把历史记录存在向量数据库里，每次提问前先检索相关片段，再喂给模型。但它本质是“临时抱佛脚”：每次都要重检、重排、重融合，响应延迟翻倍，而且检索结果质量严重依赖分块策略和Embedding模型——我见过最典型的失败案例，销售记录里“合同金额：¥1,200,000”被切分成“合同”、“金额”、“¥1”、“200”、“000”，导致检索完全失效。

• 第三类：Session级上下文拼接。最简单粗暴，把最近10轮对话全塞进prompt。但这是饮鸩止渴：上下文长度一卡，模型就开始胡言乱语；更致命的是，它只记“最近”，不记“重要”。用户说“我司年会预算上限是50万”，这句话可能被第11轮新消息挤出上下文，而模型永远不知道该优先保留哪条信息。

这三类方案的共同死穴，就是把记忆逻辑和模型推理逻辑绑死在同一根线上。而本项目的核心突破，恰恰在于主动斩断这根线——它不碰模型权重，不改推理代码，不依赖任何特定Tokenizer，只在模型的“输入-输出”管道之外，构建一条独立的记忆读写通道。

2.2 架构设计：三层解耦，让记忆真正成为“外设”

整个系统采用清晰的三层洋葱架构，每一层都严格隔离职责：

• 最内层：模型执行层（Model Layer）。这里可以是任何LLM：OpenAI API、Anthropic Claude、本地Ollama的Llama 3、vLLM托管的Mixtral，甚至是你自己用PyTorch写的简易Decoder-only模型。它只做一件事：接收纯文本prompt，输出纯文本response。对它而言，这个记忆系统根本不存在，就像USB设备对电脑主机而言，只是一个标准接口的外设。

• 中间层：记忆协议层（Memory Protocol Layer）。这是整个方案的灵魂，也是“Plug-and-Play”的技术基石。它定义了一套极简的、基于HTTP的RESTful API规范，只包含四个核心端点：

  1. POST /memory/store—— 存储一条记忆，带key（唯一标识）、content（文本内容）、tags（标签数组，如["user_profile", "contract_2024"]）、priority（优先级数值，0-100）
  2. GET /memory/retrieve—— 检索记忆，支持按tags过滤、按priority排序、按similarity（语义相似度）或recency（时间倒序）召回
  3. PUT /memory/update—— 更新指定key的记忆内容
  4. DELETE /memory/clear—— 清空指定tags下的所有记忆

  关键在于，这个协议不规定存储实现。你可以用SQLite存本地小文件，用PostgreSQL存结构化关系，用ChromaDB存向量，甚至用Redis存高速缓存——只要你的后端服务实现了这四个端点，它就是合规的“记忆硬盘”。

• 最外层：应用胶水层（Application Glue Layer）。这才是开发者真正要写的代码。它像一个智能调度员，在每次向模型发送prompt前，先调用/memory/retrieve获取相关记忆，把它们格式化成一段自然语言提示（例如：“用户李明，职位：CTO，上月反馈系统登录慢，已安排优化”），插入到原始prompt开头；在模型返回response后，再根据response内容和业务规则，决定是否调用/store存入新记忆（例如，当response中出现“已为您创建工单#20240501”时，自动存入一条tag为["support_ticket"]的记忆）。这一层代码量极少，通常50行以内就能完成基础集成。

这种设计带来的直接好处是：当你明天想把后端从SQLite换成Milvus，只需重写那四个API的后端逻辑，应用胶水层代码一行都不用动；当你后天想换用另一个模型，也只需调整胶水层里调用模型的那几行代码，记忆协议层完全透明。这正是“即插即用”的工程本质——不是一键安装，而是职责清晰、边界明确、替换成本趋近于零。

2.3 为什么选择HTTP协议而非SDK或中间件？

你可能会问：为什么不直接提供一个Python SDK，或者做成LangChain的一个内置模块？这背后有非常实际的考量。我在三个不同行业的客户现场踩过坑：金融客户用Java Spring Boot，医疗客户用Go Gin，教育客户用Node.js Express。如果强制他们引入一个Python SDK，意味着要么重构整个后端栈（成本不可接受），要么在Java服务里硬塞一个Python子进程（运维噩梦）。而HTTP协议是真正的“通用母语”——任何现代编程语言都有成熟的HTTP客户端库，连嵌入式设备上的C语言都能用libcurl轻松调用。更重要的是，HTTP天然支持服务发现、负载均衡、鉴权和监控。当你的记忆服务需要横向扩展时，前端应用胶水层完全无感，运维团队只需在Nginx或Kubernetes Ingress里加一条路由规则。这比任何SDK都更贴近企业级应用的真实战场。

3. 核心细节解析与实操要点：从零搭建一个可用的记忆系统

3.1 最小可行实现（MVP）：用SQLite+Flask跑通全流程

别被“协议”二字吓住，我们先用最轻量的方式跑通闭环。以下是一个可在30分钟内完成的、生产就绪的最小实现，所有代码均可直接复制粘贴运行。

第一步：准备环境与依赖

# 创建虚拟环境（推荐） python -m venv memory_env source memory_env/bin/activate # Linux/Mac # memory_env\Scripts\activate # Windows # 安装核心依赖 pip install flask flask-sqlalchemy python-dotenv

第二步：编写记忆后端（app.py）

from flask import Flask, request, jsonify from flask_sqlalchemy import SQLAlchemy from datetime import datetime import os app = Flask(__name__) app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///memory.db' app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False db = SQLAlchemy(app) class MemoryRecord(db.Model): id = db.Column(db.Integer, primary_key=True) key = db.Column(db.String(255), unique=True, nullable=False) content = db.Column(db.Text, nullable=False) tags = db.Column(db.String(500)) # 简单用逗号分隔，生产环境建议用JSON或关联表 priority = db.Column(db.Integer, default=50) created_at = db.Column(db.DateTime, default=datetime.utcnow) updated_at = db.Column(db.DateTime, default=datetime.utcnow, onupdate=datetime.utcnow) with app.app_context(): db.create_all() @app.route('/memory/store', methods=['POST']) def store_memory(): data = request.get_json() key = data.get('key') content = data.get('content') tags = data.get('tags', []) priority = data.get('priority', 50) if not key or not content: return jsonify({'error': 'key and content are required'}), 400 # 如果key已存在，则更新 record = MemoryRecord.query.filter_by(key=key).first() if record: record.content = content record.tags = ','.join(tags) if isinstance(tags, list) else tags record.priority = priority record.updated_at = datetime.utcnow() else: record = MemoryRecord( key=key, content=content, tags=','.join(tags) if isinstance(tags, list) else tags, priority=priority ) db.session.add(record) db.session.commit() return jsonify({'status': 'success', 'key': key}), 201 @app.route('/memory/retrieve', methods=['GET']) def retrieve_memory(): tags = request.args.getlist('tags') # 支持多个tags参数，如 ?tags=user&tags=contract priority_min = request.args.get('priority_min', type=int, default=0) limit = request.args.get('limit', type=int, default=5) query = MemoryRecord.query.filter(MemoryRecord.priority >= priority_min) if tags: # 简单的tags包含查询（生产环境应使用全文索引或JSON函数） for tag in tags: query = query.filter(MemoryRecord.tags.contains(tag)) records = query.order_by(MemoryRecord.priority.desc(), MemoryRecord.updated_at.desc()).limit(limit).all() result = [{ 'key': r.key, 'content': r.content, 'tags': r.tags.split(',') if r.tags else [], 'priority': r.priority, 'updated_at': r.updated_at.isoformat() } for r in records] return jsonify(result) @app.route('/memory/update', methods=['PUT']) def update_memory(): data = request.get_json() key = data.get('key') if not key: return jsonify({'error': 'key is required'}), 400 record = MemoryRecord.query.filter_by(key=key).first() if not record: return jsonify({'error': 'memory not found'}), 404 if 'content' in data: record.content = data['content'] if 'tags' in data: record.tags = ','.join(data['tags']) if isinstance(data['tags'], list) else data['tags'] if 'priority' in data: record.priority = data['priority'] record.updated_at = datetime.utcnow() db.session.commit() return jsonify({'status': 'updated', 'key': key}) @app.route('/memory/clear', methods=['DELETE']) def clear_memory(): tags = request.args.getlist('tags') if not tags: return jsonify({'error': 'at least one tag is required'}), 400 # 删除匹配任意一个tag的记录 for tag in tags: MemoryRecord.query.filter(MemoryRecord.tags.contains(tag)).delete() db.session.commit() return jsonify({'status': 'cleared', 'tags': tags}) if __name__ == '__main__': app.run(host='0.0.0.0', port=5001, debug=True)

第三步：启动服务

python app.py # 服务将在 http://localhost:5001 运行

第四步：验证API（用curl测试）

# 存储一条用户记忆 curl -X POST http://localhost:5001/memory/store \ -H "Content-Type: application/json" \ -d '{"key":"user_john_doe", "content":"John Doe, Senior DevOps Engineer, joined company in Jan 2023, prefers Ansible over Terraform", "tags":["user_profile","devops"], "priority":90}' # 检索所有devops标签的记忆 curl "http://localhost:5001/memory/retrieve?tags=devops&limit=1" # 更新记忆（比如John升职了） curl -X PUT http://localhost:5001/memory/update \ -H "Content-Type: application/json" \ -d '{"key":"user_john_doe", "content":"John Doe, Lead DevOps Architect, joined company in Jan 2023, prefers Ansible over Terraform"}'

提示：这个SQLite实现虽小，但已具备生产可用的核心能力。它的priority字段是关键设计——不是所有记忆都平等。比如用户身份证号（priority=100）必须永远在检索结果顶部，而“用户昨天点了杯美式”（priority=20）可以被自动淘汰。这比单纯按时间或相似度排序更符合真实业务逻辑。

3.2 应用胶水层：如何无缝注入现有AI流程

假设你正在用OpenAI API构建一个客服助手，原始代码可能是这样：

# 原始代码：无记忆 def get_customer_response(customer_query): response = openai.ChatCompletion.create( model="gpt-4-turbo", messages=[{"role": "user", "content": customer_query}] ) return response.choices[0].message.content

现在，只需增加6行胶水代码，就能赋予它记忆能力：

import requests import json def get_customer_response_with_memory(customer_query): # 1. 从记忆服务检索相关记忆（这里用customer_id作为key前缀） customer_id = extract_customer_id(customer_query) # 你需要自己实现这个函数，比如从query中正则提取手机号 if customer_id: try: # 2. 调用记忆协议API mem_resp = requests.get( f"http://localhost:5001/memory/retrieve?tags=user_profile&tags=customer_{customer_id}&limit=3" ) memories = mem_resp.json() # 3. 将记忆格式化为自然语言提示 memory_context = "\n".join([f"记忆{i+1}: {m['content']}" for i, m in enumerate(memories)]) except Exception as e: memory_context = "（记忆服务暂时不可用）" else: memory_context = "（未识别客户ID）" # 4. 将记忆上下文注入prompt full_prompt = f"请基于以下客户背景信息回答问题：\n{memory_context}\n\n客户当前问题：{customer_query}" # 5. 调用模型（保持原有逻辑不变） response = openai.ChatCompletion.create( model="gpt-4-turbo", messages=[{"role": "user", "content": full_prompt}] ) # 6. （可选）根据response内容自动存入新记忆 if "工单" in response.choices[0].message.content and "已创建" in response.choices[0].message.content: ticket_id = extract_ticket_id(response.choices[0].message.content) requests.post("http://localhost:5001/memory/store", json={ "key": f"ticket_{ticket_id}", "content": f"客户{customer_id}的工单#{ticket_id}，状态：已创建，类型：系统故障", "tags": ["support_ticket", f"customer_{customer_id}"], "priority": 80 }) return response.choices[0].message.content

注意：这里的extract_customer_id函数是业务关键点。实践中，我们通常用三种方式组合识别：

• 显式识别：用户说“我是会员号123456”，用正则\b会员号(\d+)\b提取；
• 隐式关联：用户说“我昨天在APP里提交的申请”，结合会话时间戳和数据库查询，关联到最近一条记录；
• 设备指纹：Web端用localStorage存用户ID，移动端用设备ID哈希值。 没有银弹，但必须有一套稳定的ID锚点，否则记忆就成了无根浮萍。

3.3 生产级增强：从SQLite到向量检索的平滑演进

SQLite MVP足够验证概念，但当记忆库增长到10万条以上，纯文本LIKE检索会明显变慢。此时，无需重写整个系统，只需升级记忆后端的/retrieve实现。以下是用ChromaDB替换SQLite检索的增量步骤：

第一步：安装ChromaDB

pip install chromadb

第二步：修改app.py中的retrieve_memory函数

import chromadb from chromadb.utils import embedding_functions # 初始化Chroma客户端（内存模式，生产环境用持久化） client = chromadb.Client() # 使用默认的Sentence Transformers嵌入模型 ef = embedding_functions.DefaultEmbeddingFunction() # 创建或获取集合 collection = client.get_or_create_collection( name="ai_memory", embedding_function=ef ) @app.route('/memory/retrieve', methods=['GET']) def retrieve_memory(): # ...（前面的参数解析逻辑不变）... # 新的向量检索逻辑 if tags: # Chroma支持元数据过滤，这里用tags作为元数据 results = collection.query( query_texts=[customer_query], # 用当前query作为检索向量 n_results=limit, where={"tags": {"$in": tags}} # Chroma的元数据过滤语法 ) # results['documents'] 是检索到的内容列表 # results['metadatas'] 是对应的元数据（含priority等） # 需要将它们合并成统一格式返回 records = [] for i, doc in enumerate(results['documents'][0]): meta = results['metadatas'][0][i] records.append({ 'key': meta.get('key', 'unknown'), 'content': doc, 'tags': meta.get('tags', []), 'priority': meta.get('priority', 50), 'updated_at': meta.get('updated_at', datetime.utcnow().isoformat()) }) return jsonify(records) else: # 无tags时，退回到SQLite的全局检索（兼容旧逻辑） # ...（原有SQLite查询代码）...

实操心得：向量检索不是万能药。我们在线上A/B测试发现，对于精确匹配（如“我的订单号是多少”），传统关键词检索准确率98%，而向量检索只有82%——因为模型把“订单号”和“快递单号”判为相似。因此，最佳实践是混合检索（Hybrid Search）：先用关键词快速筛出候选集（如所有含“订单号”的记忆），再用向量在候选集内做语义精排。ChromaDB 0.4.20+已原生支持where_document参数，可完美实现此逻辑。

4. 实操过程与核心环节实现：真实场景下的完整工作流与参数详解

4.1 场景还原：为一家SaaS公司的销售助理添加记忆能力

让我们把抽象概念拉回地面。某SaaS公司销售团队每天要处理200+条客户咨询，其中30%涉及历史交互（“我上次试用的账号还能用吗？”、“你们说的API文档链接发我下”）。他们用Streamlit搭了一个内部销售助手，后端是FastAPI调用Llama 3-70B。接入记忆系统前，销售代表必须手动翻聊天记录或CRM系统，平均每次查询耗时2分17秒。接入后，目标是将此时间压缩到3秒内，并保证95%以上的记忆召回准确率。

第一步：定义记忆Schema（这是成败关键）

我们没有一上来就存所有聊天记录，而是和销售总监一起梳理出四类高价值记忆：

注意：Key的命名规则必须全局唯一且可预测。我们用{company_id}而非{customer_name}，因为公司名可能变更（“北京XX科技”改名“北京XX智联”），而CRM里的company_id是稳定主键。这是无数客户踩过的坑——用易变字段做key，导致记忆丢失。

第二步：胶水层集成（FastAPI版）

from fastapi import FastAPI, Depends, HTTPException from pydantic import BaseModel import httpx app = FastAPI() MEMORY_SERVICE_URL = "http://localhost:5001" class QueryRequest(BaseModel): query: str customer_id: str # 由前端或Auth中间件传入 @app.post("/sales-assistant") async def sales_assistant(request: QueryRequest): # 1. 并行检索多类记忆（提升速度） async with httpx.AsyncClient() as client: tasks = [ client.get(f"{MEMORY_SERVICE_URL}/memory/retrieve?tags=profile&tags=customer_{request.customer_id}&limit=1"), client.get(f"{MEMORY_SERVICE_URL}/memory/retrieve?tags=trial&tags=customer_{request.customer_id}&limit=1"), client.get(f"{MEMORY_SERVICE_URL}/memory/retrieve?tags=commit&tags=customer_{request.customer_id}&limit=3") ] responses = await asyncio.gather(*tasks, return_exceptions=True) # 2. 合并检索结果，按priority降序排列 all_memories = [] for resp in responses: if isinstance(resp, httpx.Response) and resp.status_code == 200: all_memories.extend(resp.json()) # 去重并排序 unique_memories = {m['key']: m for m in all_memories}.values() sorted_memories = sorted(unique_memories, key=lambda x: x['priority'], reverse=True) # 3. 构建记忆上下文（控制长度，避免超限） context_lines = [] total_chars = 0 for mem in sorted_memories: line = f"[{mem['tags'][0]}] {mem['content']}" if total_chars + len(line) < 2000: # 为模型prompt留足空间 context_lines.append(line) total_chars += len(line) else: break memory_context = "\n".join(context_lines) if context_lines else "（暂无相关客户记忆）" # 4. 调用Llama 3模型（此处简化为伪代码，实际用vLLM或Ollama） llm_response = await call_llama3_model( system_prompt="你是一名专业SaaS销售顾问，请基于客户背景和当前问题给出精准回答。", user_prompt=f"客户背景：{memory_context}\n\n当前问题：{request.query}" ) # 5. 智能记忆更新（基于LLM响应内容） if "承诺" in llm_response and "前" in llm_response: # 提取承诺内容和日期，自动生成commit记忆 commit_content = extract_commitment(llm_response) if commit_content: await client.post(f"{MEMORY_SERVICE_URL}/memory/store", json={ "key": f"commit_{datetime.now().strftime('%Y%m%d')}_{hash(commit_content)}", "content": commit_content, "tags": ["commit", f"customer_{request.customer_id}"], "priority": 85 }) return {"response": llm_response}

第三步：关键参数调优实录

• Priority阈值设置：我们测试了不同priority组合。当profile类设为95，trial类设为90，commit类设为85时，检索召回率最高。但如果把feedback也设为85，就会挤占commit的展示位置——因为销售最关心的是“我答应了什么”，而不是“用户吐槽了什么”。最终定为70，并在UI上用灰色字体弱化显示。

• 检索Limit的黄金比例：/retrieve?limit=5看似合理，但实测发现，当同时检索3个tags时，每个tags返回5条，共15条记忆，远超模型上下文承载力。我们改为limit=2per tag，总记忆行数控制在8行以内，配合total_chars < 2000的硬限制，确保99.2%的请求不会触发模型截断。

• 向量嵌入模型的选择：最初用all-MiniLM-L6-v2，在“试用账号”类查询上准确率仅68%。切换到bge-m3后，提升至91%。但bge-m3体积大、推理慢。最终采用双模型策略：用MiniLM做首轮快速过滤（耗时<50ms），再用bge-m3对Top10结果做精排（耗时<200ms），综合耗时仍低于3秒，准确率达94.7%。

4.2 性能压测与稳定性保障：支撑2000QPS的实战配置

当系统上线后，我们面临第一个大考：销售早会期间，200人同时发起咨询，峰值QPS达1800。SQLite后端瞬间崩溃，平均响应时间飙升至8.2秒。以下是我们的生产级加固方案：

基础设施层

• 数据库：弃用SQLite，迁移到Amazon RDS PostgreSQL（db.t3.large），开启pgvector扩展支持向量检索。
• 缓存：在ChromaDB和PostgreSQL之间加入Redis集群，缓存高频检索结果（如profile_123）。缓存Key设计为mem:{tags}:{query_hash}，TTL设为30分钟（平衡新鲜度与性能）。
• 服务网格：用Envoy代理所有/memory/*请求，实现自动重试（3次）、熔断（错误率>5%时暂停10秒）、限流（单IP 100 QPS）。

协议层优化

• 批量API：新增POST /memory/batch-retrieve，允许一次请求携带多个检索条件，减少网络往返。销售助手前端将“查客户画像+查试用状态+查历史承诺”合并为一次请求。
• 增量同步：为避免ChromaDB和PostgreSQL数据不一致，实现一个后台Worker，每5秒扫描PostgreSQL中updated_at > last_sync_time的记录，同步到ChromaDB。同步失败时自动告警并重试。

压测结果对比表

实操心得：最大的性能陷阱不是数据库，而是前端重复请求。我们发现销售代表习惯连续点击“发送”按钮3次，导致同一记忆被检索4次。解决方案是在前端加防抖（debounce 300ms），并在Envoy层加X-Request-ID日志追踪，快速定位恶意请求源。这比优化数据库索引更立竿见影。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 典型问题速查表

5.2 独家避坑技巧：来自三年27个项目的总结

• 技巧1：用“记忆健康度”代替“记忆数量”做监控
  不要只看SELECT COUNT(*) FROM memory_record。我们定义了三个健康指标：
  

  • Freshness Ratio：updated_at在7天内的记录占比。低于60%说明记忆更新机制失效。
  • Tag Balance：各tags的记录数标准差。若profile有1000条而commit只有3条，说明销售未养成记录承诺的习惯。
  • Recall Accuracy：随机抽100条记忆，人工验证其key是否真能通过/retrieve召回。低于95%需检查Embedding质量。
    这些指标每天凌晨自动生成报表，邮件发送给销售总监——比任何技术指标都更能驱动业务改进。
    

• 技巧2：为“遗忘”设计API，而非回避它
  所有客户最终都会问：“怎么删掉这条错误记忆？”但我们发现，直接暴露DELETE /memory/{key}极其危险。正确做法是：
  

  1. POST /memory/request-delete：用户提交删除申请，附理由（如“信息已过期”）；
  2. 后台Worker将请求推入审核队列；
  3. 合规专员在管理后台审批，审批通过后才执行物理删除；
  4. 同时，系统自动将该记忆标记为is_deleted=true，后续/retrieve默认不返回，但审计日志永久留存。