插拔式外部记忆层：为任意大模型添加可持久化工作记忆

1. 项目概述：不是“插上就用”，而是“插上就能记”

你有没有遇到过这样的情况：训练好一个大模型，它在测试集上表现亮眼，但一放到真实业务场景里——比如客服对话、知识库问答、甚至内部文档摘要——就开始“忘事”？明明前一句用户刚说“我上周提交的工单编号是2023-ABCD”，下一句它就问“请问您的工单号是多少？”；或者你反复教它公司内部的报销流程、审批节点、附件命名规范，它却像没听过一样，每次都要重新解释。这不是模型能力不够，而是它缺乏一种最基础、却常被忽略的“工作记忆”——不是长期记忆（那需要微调或RAG），也不是短期缓存（那只是临时变量），而是一种可持久化、可定向注入、与模型推理解耦的外部记忆层。

这个标题里的“This Plug-and-Play AI Memory Works With Any Model”，说的正是这样一套机制：它不修改模型权重，不重写推理引擎，不绑定特定框架（PyTorch/TensorFlow/JAX），甚至不关心你用的是Llama 3、Qwen2、Phi-3还是本地部署的Gemma 2。它像给任何一辆车加装一个标准化OBD接口的行车记录仪——无论你是丰田卡罗拉还是特斯拉Model Y，只要接口协议一致，记录仪就能即插即用、实时录像、按需回放。这里的“Plug-and-Play”，核心不在“快”，而在“无侵入”；“Works With Any Model”，关键不在“兼容”，而在“零假设”——它不预设模型有KV缓存、不依赖flash attention优化、不强求支持LoRA适配器，甚至连tokenizer都不需要它自己加载。

我过去三年在金融和医疗两个强合规领域落地AI助手，踩过太多“记忆陷阱”：有人硬改transformer层加memory token，结果模型精度掉2.3个点；有人用Redis存对话历史再拼进prompt，但超长上下文直接触发OOM；还有人把所有用户档案向量化塞进FAISS，查一次要500ms，根本扛不住并发。直到去年底在arXiv看到一篇叫《MemPool: A Decoupled, Schema-Aware External Memory for LLMs》的论文，才真正理清思路——记忆不该是模型的负担，而应是它的外设。这篇博文，就是我把MemPool原理吃透后，在生产环境跑通三套不同架构（vLLM服务端、Ollama本地推理、HuggingFace Transformers脚本）的真实复现手记。它不讲抽象概念，只说你明天就能抄作业的配置、参数、避坑点，以及为什么某些“看起来很美”的方案在实际压测中会崩得悄无声息。

2. 内容整体设计与思路拆解：为什么必须“解耦”，又为何能“通用”

2.1 核心矛盾：模型原生记忆的三大硬伤

要理解这套“插拔式记忆”为何成立，得先看清当前主流方案的结构性缺陷。我拿三个真实压测数据说话：

• KV缓存复用率低到反直觉：我们在某银行信贷助手场景中，对10万条真实客服对话做KV缓存分析。发现超过68%的query，其attention key与前序token的key相似度＜0.15（cosine距离）。这意味着模型在生成“请提供身份证后四位”时，并未有效复用“用户刚输入的身份证号”对应的KV对——不是模型不会，而是缓存管理策略太粗放，把“用户信息”“业务规则”“历史动作”全混在一个线性buffer里，检索时像在图书馆用书名找作者。

• Prompt拼接的“长度税”呈指数级增长：当把用户档案（2KB）、产品条款（5KB）、最近3轮对话（1.2KB）全拼进prompt，总长度达8.2KB。实测vLLM在A100上吞吐量从128 req/s暴跌至23 req/s，首token延迟从320ms跳到1.8s。更致命的是，模型开始“选择性失忆”——它优先记住最后200个token（因为attention softmax归一化后尾部权重衰减慢），导致关键条款被覆盖。

• RAG的“语义漂移”无法规避：我们曾用ChromaDB存全部监管文件，query“贷款展期是否收取罚息”返回top3 chunk，但其中两条出自2021年旧规，一条是2023年修订稿的模糊表述。模型基于这三条生成答案，准确率仅61%。问题不在embedding模型，而在RAG本质是“概率匹配”，它无法像数据库一样执行WHERE effective_date = (SELECT MAX(effective_date) FROM rules)。

这三点指向同一个结论：记忆必须脱离模型的计算流，成为独立可验证、可版本化、可审计的数据实体。

2.2 设计哲学：把记忆变成“数据库”，而非“缓存”

MemPool的设计反直觉之处在于：它彻底放弃让模型“自己记住”，转而构建一个带schema的、可索引的、事务安全的外部记忆池。类比一下：

• 传统KV缓存 ≈ 把所有会议纪要手写在便利贴上，贴满整面墙，找某条记录得挨张翻；
• RAG ≈ 用关键词在一堆PDF里全文搜索，结果可能包含过期文件；
• MemPool ≈ 建立一个MySQL表：user_memory (user_id, memory_type, content, version, created_at, expires_at)，每条记录有明确类型（如identity、preference、consent）、版本号、过期时间，查询时直接SELECT content FROM user_memory WHERE user_id='U123' AND memory_type='identity' AND version=(SELECT MAX(version) FROM user_memory WHERE user_id='U123')。

这种设计带来三个决定性优势：

1. 零模型侵入：模型只接收结构化JSON片段（如{"user_identity": {"id_number": "11010119900307231X", "phone": "138****1234"}}），无需任何代码修改；
2. 强一致性保障：通过memory_id+version双键锁定，避免并发更新导致的脏读（比如用户同时修改手机号和邮箱，旧版本手机号覆盖新版本）；
3. 审计友好：每条记忆变更都落库，可追溯到具体操作时间、操作人、变更前/后值，这对金融、医疗场景是刚需。

提示：很多团队误以为“插拔式”等于“轻量级”，其实恰恰相反——MemPool的存储层必须支持ACID事务。我们试过用SQLite做POC，但在200QPS下出现锁等待超时；最终生产环境强制要求PostgreSQL 14+，并开启idle_in_transaction_session_timeout=30s防长事务阻塞。

2.3 为何能“适配任意模型”：协议层抽象是关键

标题里“Works With Any Model”的底气，来自它定义了一套极简的内存交互协议（Memory Interaction Protocol, MIP），只有三个HTTP endpoint：

• POST /memory/query：输入{user_id, memory_types:[], context_hint}，返回结构化JSON；
• POST /memory/update：输入{user_id, memory_type, content, version}，原子写入；
• DELETE /memory/clear?user_id=xxx&memory_type=xxx：按类型清理。

注意：这里没有model_name、tokenizer、max_length等字段。因为MemPool根本不关心模型怎么算，它只管“谁要什么，给什么”。模型侧只需在prompt template里留个占位符，比如：

<|system|>你是一名专业客服，严格遵守以下用户信息： {user_memory} 请基于此回答问题。 <|user|>{user_input}

推理服务（vLLM/Ollama/Transformers）在渲染prompt前，调用/memory/query拿到JSON，用json.dumps()塞进去即可。至于模型能否处理这个JSON——那是模型自己的事，MemPool不背锅。

我们验证过：同一套MemPool服务，上游连着Llama 3-8B（用vLLM部署）、下游连着Qwen2-7B（用Ollama run），中间还穿插了本地跑的Phi-3-mini（用transformers pipeline），三者共享同一份用户记忆库，从未出现格式错乱。原因很简单：JSON是通用协议，就像USB-C接口，不管手机还是笔记本，只要认这个协议，插上就能传数据。

3. 核心细节解析与实操要点：从协议到落地的七处生死关

3.1 Memory Type Schema设计：别让“用户偏好”和“用户身份”挤在同一张表里

很多人一上来就想建个大而全的memory表，字段堆满content_text、content_json、metadata……结果半年后查个“用户是否同意短信营销”，得写WHERE content_json->>'consent_sms' = 'true' AND metadata->>'source' = 'web_form'，性能惨不忍睹。MemPool强制要求按语义分表，这是性能和可维护性的分水岭。

我们生产环境的schema设计如下（PostgreSQL）：

注意：user_preference用preference_key作主键的一部分，是因为用户可能同时设置notify_email=true和notify_sms=false，若用(user_id, version)，版本升级时会丢失旧偏好。而session_context用created_at，是因为它天然有时效性，按时间范围查询比按版本查更高效。

实操心得：我们曾把compliance_consent和user_identity合并在一张表，结果在审计时发现，当用户撤回某项授权（如“允许调用通讯录”），系统需同时更新revoked_at和生成新evidence_hash，但旧记录的evidence_hash仍指向已失效的授权文本。分表后，每类操作原子性清晰，审计报告自动生成脚本也从300行降到87行。

3.2 Context Hint机制：让记忆检索从“大海捞针”变“精准定位”

/memory/query接口有个关键参数context_hint，它不是可选的，而是性能命脉。想象这个场景：用户问“我的保单到期日是哪天？”，模型需要的不是全部记忆，而是policy_info类型下的最新记录。如果context_hint为空，MemPool就得扫描该用户所有memory_type，再过滤出policy_info——在百万级用户库中，这相当于全表扫描。

我们的context_hint设计为两级提示：

• 一级hint：由前端或业务逻辑注入，如{"intent": "insurance_inquiry", "entities": ["policy_number"]}；
• 二级hint：由模型在生成过程中动态反馈，如模型输出<memory_ref type="policy_info" version="20240520">，MemPool捕获后立即触发/memory/query?user_id=U123&memory_types=["policy_info"]&version=20240520。

这个机制的关键在于hint必须可被正则解析。我们约定所有hint字段名小写+下划线，值必须是字符串或字符串数组（禁止嵌套对象），这样MemPool可用re.search(r'"type"\s*:\s*"([^"]+)"', hint_str)毫秒级提取。

提示：千万别用LLM自己解析hint！我们早期让Qwen2-7B去parse JSON hint，结果发现它把"version": "20240520"识别成数字20240520，再传给PostgreSQL时因类型不匹配报错。后来改成前端用JSON.stringify()确保字符串化，后端用Pythonast.literal_eval()安全解析，稳如磐石。

3.3 Versioning策略：不是“最新版就行”，而是“指定版才准”

版本控制是MemPool区别于普通缓存的核心。我们采用语义化版本+时间戳双轨制：

• 对user_identity等强一致性数据，版本号为YYYYMMDDHHMMSS（如20240520143022），精确到秒，确保同一秒内多次更新也能区分；
• 对user_preference等弱一致性数据，版本号为v1.2.3，遵循semver，便于前端做灰度发布（如v1.2.x用户看到新UI，v1.1.x用户保持旧版）；
• 所有/memory/update请求必须携带version，MemPool会校验：若新版本≤旧版本，拒绝写入并返回409 Conflict。

这个设计解决了我们最大的线上事故：某次发版，运维误将测试环境的user_identity版本号（20240101000000）同步到生产库，导致所有用户最新身份信息被覆盖为测试数据。现在，任何低于当前最大版本的写入都会被拦截，且告警自动触发SELECT * FROM user_identity WHERE user_id='U123' ORDER BY version DESC LIMIT 5，5分钟内定位问题源头。

3.4 Expires At设计：让“过期记忆”自动消失，而非堆积成山

expires_at不是可选项，而是强制字段。我们按数据敏感度分级：

• user_identity：NOW() + INTERVAL '5 years'（身份证号长期有效）；
• session_context：NOW() + INTERVAL '24 hours'（对话状态不过夜）；
• compliance_consent：NOW() + INTERVAL '10 years'（法律要求存档期）；
• user_preference：NULL（用户偏好永不过期，除非主动清除）。

关键技巧：用数据库分区表+定时job双保险。PostgreSQL中，我们按expires_at范围分区（PARTITION BY RANGE (expires_at)），每月一个分区。同时，后台运行pg_cronjob，每天凌晨执行：

DELETE FROM session_context WHERE expires_at < NOW() - INTERVAL '1 hour'; VACUUM session_context;

为什么删前加1小时缓冲？因为避免正在处理的会话被误删。实测下来，分区表使DELETE速度提升17倍，且VACUUM不再阻塞业务查询。

3.5 Security Boundary：记忆不是“共享硬盘”，而是“带锁保险柜”

MemPool默认不开放跨用户访问。所有/memory/query请求必须携带user_id，且该user_id需经上游服务JWT验证。我们强制要求：

• JWT payload中必须含sub（用户唯一标识）和scope（权限范围，如memory:read:user_identity）；
• MemPool网关层校验scope是否包含请求的memory_type，例如user_preference需memory:read:user_preference；
• 对compliance_consent等高敏数据，额外校验scope中是否含compliance:audit。

注意：绝不能把user_id从JWT里取出来就直接拼SQL！我们用psycopg2的sql.SQL和sql.Placeholder构造查询：

query = sql.SQL("SELECT content FROM {table} WHERE user_id = %s AND version = (SELECT MAX(version) FROM {table} WHERE user_id = %s)").format( table=sql.Identifier(f"user_{memory_type}") ) cur.execute(query, (user_id, user_id))

这样既防SQL注入，又利用PostgreSQL的prepared statement缓存，QPS提升40%。

3.6 Fallback Behavior：当记忆库不可用时，模型不能“装死”

生产环境必然面对网络抖动、DB连接池耗尽等问题。MemPool定义了严格的fallback策略：

• query失败时，返回空JSON{}，绝不抛错中断推理；
• update失败时，记录error log并发送Sentry告警，但不阻塞主流程；
• 所有fallback路径必须有监控埋点，我们用Prometheus暴露mem_pool_query_fallback_total{type="user_identity"}指标。

这个设计源于血泪教训：某次PostgreSQL主库切换，vLLM因等待MemPool响应超时（默认3s），触发熔断降级为“抱歉，系统繁忙”，用户投诉暴增。现在，即使MemPool完全宕机，模型仍能基于prompt中静态system message运行，只是失去个性化——体验降级，但服务不中断。

3.7 Monitoring & Alerting：不看指标的运维，等于蒙眼开车

我们为MemPool部署了7个黄金指标（Golden Signals）：

特别说明mem_pool_version_skew_seconds：MemPool集群各节点若时钟偏差过大，会导致user_identity版本号生成混乱（如节点A生成20240520143022，节点B生成20240520142955，但B的时间快30秒）。我们用chrony强制同步，告警触发时自动执行sudo chronyc makestep。

4. 实操过程与核心环节实现：从零部署MemPool服务的完整链路

4.1 环境准备：最小可行配置清单

我们坚持“最小可行”原则，避免过度工程。生产环境配置如下（Kubernetes Helm Chart）：

• MemPool API服务：2核4G × 3副本，镜像mempool-api:v2.1.0（基于FastAPI + uvicorn）；
• PostgreSQL：8核32G × 1主2从，版本14.10，开启pg_stat_statements；
• Redis：4GB × 1，作为二级缓存（缓存/memory/query结果，TTL=60s）；
• 备份策略：每日全量pg_dump+ WAL归档，保留7天；
• 网络策略：MemPool API仅允许vLLM/Ollama服务网段访问，禁止公网；

提示：别迷信“云托管数据库”。我们对比过AWS RDS PostgreSQL和自建，发现RDS在pg_cron定时任务调度上延迟高达12s（官方文档承认），而自建+pg_cron稳定在100ms内。对session_context这种时效性强的数据，12s延迟意味着大量过期数据残留。

4.2 数据库初始化：五步完成Schema部署

执行顺序不可颠倒，否则会引发数据不一致：

1. 创建专用DB与用户：

   CREATE DATABASE mempool_prod; CREATE USER mempool_app WITH PASSWORD 'strong_password_here'; GRANT CONNECT ON DATABASE mempool_prod TO mempool_app; \c mempool_prod

2. 启用pg_cron扩展（需superuser）：

   CREATE EXTENSION IF NOT EXISTS pg_cron; GRANT USAGE ON SCHEMA cron TO mempool_app;

3. 创建分区父表与子表（以session_context为例）：

   CREATE TABLE session_context ( id SERIAL PRIMARY KEY, session_id VARCHAR(64) NOT NULL, context_type VARCHAR(32) NOT NULL, content JSONB NOT NULL, expires_at TIMESTAMPTZ NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW() ) PARTITION BY RANGE (expires_at); -- 创建2024年6月分区 CREATE TABLE session_context_202406 PARTITION OF session_context FOR VALUES FROM ('2024-06-01') TO ('2024-07-01');

4. 创建索引（这是性能核心！）：

   -- 必须！按查询模式建复合索引 CREATE INDEX idx_session_context_lookup ON session_context (session_id, expires_at) WHERE expires_at > NOW(); -- 只索引未过期数据 -- 对user_identity，按user_id+version高效查询 CREATE INDEX idx_user_identity_version ON user_identity (user_id, version DESC);

5. 注册定时清理job：

   SELECT cron.schedule( 'cleanup-session-context', '0 3 * * *', -- 每天凌晨3点 $$DELETE FROM session_context WHERE expires_at < NOW() - INTERVAL '1 hour'; VACUUM session_context;$$ );

4.3 MemPool API服务配置：关键YAML片段

values.yaml中必须显式配置的参数：

# 数据库连接 database: host: "postgresql.mempool.svc.cluster.local" port: 5432 name: "mempool_prod" user: "mempool_app" password: "strong_password_here" # 连接池关键参数 pool: min_size: 10 max_size: 50 acquire_timeout: 30 # 获取连接超时30秒 # Redis缓存 cache: host: "redis.mempool.svc.cluster.local" port: 6379 db: 0 ttl_seconds: 60 # 安全策略 security: jwt_issuer: "auth.company.com" jwt_audience: "mempool-api" # 显式声明所有memory_type，防止动态注入 allowed_memory_types: - "user_identity" - "user_preference" - "session_context" - "compliance_consent" # 监控 monitoring: prometheus_port: 8000 metrics_path: "/metrics"

4.4 与vLLM服务集成：三行代码注入记忆

vLLM本身不支持外部memory，但我们通过custom chat template实现无缝集成。在/path/to/vllm/examples/chat_template.json中：

{ "name": "mempool-chat", "template": "<|system|>你是一名专业客服，严格遵守以下用户信息：\n{user_memory}\n请基于此回答问题。\n<|user|>{user_input}\n<|assistant|>" }

然后启动vLLM时指定：

python -m vllm.entrypoints.api_server \ --model meta-llama/Llama-3-8b-chat-hf \ --chat-template /path/to/chat_template.json \ --enable-chunked-prefill \ --max-num-batched-tokens 8192

关键在{user_memory}占位符——vLLM在渲染template前，会调用我们写的get_user_memory函数：

# vllm_server.py import requests import json def get_user_memory(user_id: str, context_hint: str) -> str: try: resp = requests.post( "http://mempool-api.mempool.svc.cluster.local:8000/memory/query", json={"user_id": user_id, "memory_types": ["user_identity", "user_preference"], "context_hint": context_hint}, timeout=2.0 ) if resp.status_code == 200: return json.dumps(resp.json(), ensure_ascii=False) else: return "{}" # fallback except Exception as e: logger.error(f"MemPool query failed: {e}") return "{}"

实测心得：timeout=2.0是黄金值。设太短（如0.5s）会导致频繁fallback；设太长（如5s）会拖慢vLLM整体吞吐。我们压测发现，99%的query在85ms内返回，2s足够覆盖网络抖动。

4.5 与Ollama集成：用modelfile注入记忆逻辑

Ollama不支持chat template，但可通过modelfile定制system prompt。创建Modelfile：

FROM llama3:8b-instruct-q4_K_M # 设置system prompt，含memory占位符 SYSTEM """ 你是一名专业客服，严格遵守以下用户信息： {{ .UserMemory }} 请基于此回答问题。 """ # 注入自定义脚本，在推理前调用MemPool PARAMETER num_ctx 8192 RUN pip install requests RUN echo '#!/usr/bin/env python3\nimport sys, json, requests\nuser_id = sys.argv[1]\nresp = requests.post("http://mempool-api:8000/memory/query", json={"user_id": user_id, "memory_types": ["user_identity"]}); print(json.dumps(resp.json()))' > /usr/local/bin/get_memory.py RUN chmod +x /usr/local/bin/get_memory.py

构建并运行：

ollama create my-llama3-mem --file Modelfile ollama run my-llama3-mem --user-id "U123"

Ollama会自动把--user-id传给get_memory.py，脚本返回JSON后注入system prompt。虽然不如vLLM优雅，但胜在简单可靠。

4.6 与HuggingFace Transformers集成：Pipeline级改造

对本地脚本，我们改造pipeline：

from transformers import pipeline, AutoTokenizer import requests import json class MemoryAugmentedPipeline: def __init__(self, model_name): self.tokenizer = AutoTokenizer.from_pretrained(model_name) self.pipe = pipeline("text-generation", model=model_name, tokenizer=self.tokenizer) def __call__(self, user_input: str, user_id: str): # 1. 获取记忆 memory_json = self._fetch_memory(user_id) # 2. 构造带记忆的prompt prompt = f"<|system|>你是一名专业客服，严格遵守以下用户信息：\n{memory_json}\n请基于此回答问题。\n<|user|>{user_input}\n<|assistant|>" # 3. 生成 outputs = self.pipe(prompt, max_new_tokens=512, do_sample=True) return outputs[0]["generated_text"].split("<|assistant|>")[-1].strip() def _fetch_memory(self, user_id): try: resp = requests.post( "http://localhost:8000/memory/query", json={"user_id": user_id, "memory_types": ["user_identity"]}, timeout=2.0 ) return json.dumps(resp.json(), ensure_ascii=False) except: return "{}"

4.7 压力测试与调优：从100QPS到3000QPS的实录

我们用k6进行阶梯式压测，目标：MemPool API在3000QPS下P99延迟＜100ms。原始配置（默认PostgreSQL）在1200QPS时P99飙升至420ms。调优步骤：

1. 数据库层面：
   • 调整shared_buffers从128MB→8GB（物理内存32G的25%）；
   • work_mem从4MB→64MB，避免sort溢出到磁盘；
   • 开启synchronous_commit = off（牺牲毫秒级持久性，换性能，WAL归档已保障数据安全）。
2. 应用层面：
   • 将uvicorn workers从4→12，但--limit-concurrency 100防OOM；
   • Redis连接池从10→50，retry_on_timeout=True；
3. 查询层面：
   • 对高频user_identity查询，增加覆盖索引：

     CREATE INDEX CONCURRENTLY idx_user_identity_covering ON user_identity (user_id, version DESC) INCLUDE (id_number, phone, email);

   • 对session_context，将WHERE expires_at > NOW()条件加入索引，避免seq scan。

最终结果：3000QPS下，P99=87ms，错误率0.02%，Redis缓存命中率82%。关键发现：索引优化贡献了65%的性能提升，远超硬件升级。

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

5.1 “Query返回空，但数据库里明明有数据”——时区陷阱

现象：前端传user_id=U123，MemPool返回{}，但手动查SELECT * FROM user_identity WHERE user_id='U123'能看到记录。
根因：PostgreSQL默认时区为UTC，而应用服务器时区为Asia/Shanghai（UTC+8）。expires_at字段存的是TIMESTAMPTZ，但查询时若未显式转换，NOW()在应用层是2024-05-20 14:30:00+08，在DB层却是2024-05-20 06:30:00+00，导致expires_at > NOW()永远为false。
解决：在所有涉及NOW()的查询中，强制用timezone('Asia/Shanghai', NOW())，并在应用启动时执行：

# Python app init import psycopg2 conn = psycopg2.connect(...) cur = conn.cursor() cur.execute("SET TIME ZONE 'Asia/Shanghai'")

5.2 “Update成功，但Query查不到最新版”——MVCC可见性问题

现象：/memory/update返回200，但立刻/memory/query仍返回旧版本。
根因：PostgreSQL MVCC机制下，新事务看不到未提交事务的更改。我们用READ COMMITTED隔离级别，但若update事务未及时提交，query事务就查不到。
解决：在/memory/updatehandler中，显式调用conn.commit()，而非依赖autocommit。我们曾因忘记commit，导致记忆更新“神隐”长达30分钟。

5.3 “Redis缓存击穿，DB瞬间被打垮”——热点Key防护

现象：某VIP用户U000001的user_identity被高频查询，Redis缓存过期瞬间，所有请求穿透到DB，CPU飙到98%。
解决：实现逻辑过期+互斥锁：

• 缓存value存{"data": {...}, "expire_at": "2024-05-20T14:30:00Z"}；
• 查询时，若expire_at < now()，不直接删缓存，而是：
  1. 尝试用SET key lock_value EX 10 NX获取锁；
  2. 若成功，异步更新DB并刷新缓存；
  3. 若失败，sleep 50ms后重试，最多3次，否则返回旧缓存（哪怕过期）。
     实测后，缓存击穿消失，DB负载平稳。

5.4 “Version冲突频繁，用户抱怨设置不生效”——前端并发写入

现象：用户在App和Web端同时修改手机号，后操作总是失败，报409 Conflict。
根因：前端未做乐观锁控制，两个请求都读到version=v20240520143022，都试图写v20240520143023。
解决：前端在/memory/update前，先GET /memory/query获取当前version，写入时带上。后端校验：IF new_version == old_version + 1 THEN ... ELSE RETURN 409。我们封装了useMemoryUpdateReact Hook，自动处理version协商。

5.5 “Fallback后模型胡言乱语”——Prompt鲁棒性缺失

现象：MemPool宕机，{user_memory}被替换为{}，模型生成“我不知道您的信息，请提供身份证号”，但用户刚在上一轮输入过。
解决：在system prompt中加入fallback兜底指令：

<|system|>你是一名专业客服。若用户信息为空（{}），请基于通用业务规则回答，切勿索要已提供信息。例如，若用户已说“我的保单号是ABC123”，则不要再次询问