一、上篇留下的问题

上篇从认知科学出发，拆解了 Agent 记忆的四种类型。并给出了工程上的三层存储方案：结构化 KV 存规则与事实向量库存语义记忆，对话窗口存短期上下文。

分层解决了"记忆存在哪"的问题。但还有四个工程问题没有回答：

1. 记忆从哪来？不过， —— 不能让开发者手动写 API 调用。Agent 得自己从对话中提取值得记住的信息。
2. 提取错了怎么办？ —— LLM 有幻觉。如果把错误信息写入长期记忆，后续会持续影响决策。
3. 记忆多了怎么找？ —— 条件可遍历，条目太多时纯向量检索够不够？说起来，
4. 记忆会无限膨胀吗？ —— 使用者和 Agent 交互次数后记忆库会不会变成一场灾难？

这四个问题，每一个都指向一套具体的工程机制。说起来，今天把它们逐一拆开。

二、记忆提取：让 LLM 自己决定“记什么”

主要挑战

传统程序的“记忆”靠开发者手动写入——调 save_memory 接口。写什么、什么时候写，都是代码控制。

User 关注点：如果需要每次手动调用，那就增加工作量；怎么说呢，如果忘掉关键信息，就失去业务价值。

主流方案的分歧

目前主流框架走了两条路线：

• 路线 A：结构化提取 用 Prompt 让 LLM 直接输出结构化的记忆条目。比如 Mem0 把记忆分为 facts、preferences、goals 三类，每次对话后让模型从对话中提取并填入对应分类。
• 路线 B：摘要压缩 先把对话压缩成摘要，再从摘要中提取关键事实。多了一步压缩，但能处理更长的对话上下文。

User 痛点：结构化提取精准但只能处理短信息；摘要压缩覆盖范围广但可能丢失细节，需要权衡成本与准确度。

至于一种工程实践，结构化提取 + 置信度

结合两条路线的优点。一种更灵活的方案是：让 LLM 输出结构化 JSON，同时给出置信度评分。

• 限定提取类型和数量："请仅抽取三条事实和两条规则"，避免过度噪声。
• "只提取明确表述的信息": 防止模型推理或脑补导致误导。
• "兜底逻辑": 如果没有值得记录的新信息，各字段留空。
• "置信度自评": 模型给每条结果打分。越高越确定，为后续路由提供依据。

User 常见担忧：如何保证抽到的是业务真正需要的信息？置信度是否足够可靠，怎么说呢，如何防止低质量数据污染长期库？老实说，以上设计正是针对这些痛点而生。

你是一个记忆提炼器，从对话中提取值得长期记住的信息。- facts：使用者明确表述的事实- rules：使用者明确要求的行为规则- status_updates：当前状态更新{
"facts":,"rules":,"status_updates":,"confidence": }
- 只提取对话中明确提及的信息，不要推理或编造
-confidence -，越高越确定
无新信息则各字段为空
} 

提取 Pipeline 的工程实现

def extract_memory_pipeline:
"""记忆提取主流程"""
# Step : 预处理 —— 拼接对话上下文 + 注入使用者特点
context = build_context
# Step : LLM 结构化提取
raw_result = llm_extract
# Step : 输出校验 —— JSON Schema 验证 + 字段合法性检查
validated = validate_extraction
if not validated:
log_warning
return None
# Step : 去重预检 —— 与已有记忆做余弦相似度比对
duplicates = check_duplicates(validated。existing_memories,threshold=SIMILARITY_THRESHOLD)
if duplicates:
update_access_time # 更新访问时间而非新增
return None
# Step : 置信度分流
route_result = route_by_confidence
return route_result

• Pitfall： 溢出导致截断错误；JSON解析失败需重试，过度抽样产生噪声。

三、置信度分流：不同确定度走不同通道

LMM 提供置信度后可按阈值将内存划分为三类：

User 常见疑问：阈值该如何选？如果设得太低，会导致幻觉污染；设得太高，又可能漏掉有价值的信息。最佳阈值需结合业务场景与标注数据进行网格搜索。以达到精确率与召回率平衡，并随运营数据持续校准。><\/em>

阈值调优的工程方法

• Step ：建立标注数据集 采样真实对话，让标注员判断每条抽出的结果是否正确且有价值。其实，
• Step ：绘制阈值‑指标曲线 遍历不同 配置。并计算 Precision / Recall / Cost。主要矛盾是 Precision 与 Recall 随阈值变化而互相牵制，而 Cost 随待审区间增大而提高。
• Step ：选点策略 客服场景优先 Precision 高。个人助手偏好 Recall 高，电商导购侧重 F1 最佳峰值点。
• Step ：持续校准 每积累一定审核量后重新评估，如漂移超过 % 即调整阈值。

四、HITL：人机协作的质量兜底

为什么需要人？<\/b>

 

LLM 在判断“这句话该不该被记住”时存在几个已知局限：


高风险信息。如金额承诺等，一旦误写会造成不可逆损失；

模糊暗示，例如“以后别这么说”，可能被误解为规则；

隐含偏好，即使字面表达不一致，也可能影响后续决策。<\/ul>
<\/ li>

HITL 即在完全自动与完全人工之间加一道审核缓冲区，以防范误判带来的风险。

<\/ul>

工作流程<\/b>

<对话输入>
<- LLM 提取+计算置信度>
<- 若 Confidence ≥ X → 自动写入 ✅ &
<- 否若 Confidence ≥ Y → 入 Pending Queue 👀 &
<- 否跳过 ❌&
              

-> 审核员看到：
• 提取得到内容 + 原始片段 + 信心评分；-> 确认 / 修改 / 拒绝;-> 若通过 → 写入长期存储 ✅;-> 若拒绝 → 标识丢弃;其实，