一、为什么 Agent 需要“记事本”

去年开发智能客服时，最棘手的并非回答不准确，而是“失忆”问题。用户第一轮提供了订单号，第三轮再问“刚才那个订单退款了吗”，模型便毫无头绪。每次对话都像从零起步，用户被迫反复重复上下文，体验极为糟糕。

症结何在？大模型自身的上下文窗口虽颇具容量，但面对长对话与跨会话场景，单纯依赖“死记硬背”既不经济也不可靠。接入 Gemini 3.5 Flash 后，耗费数天搭建了一套分层记忆系统。选择 Gemini 3.5 Flash 而非推理能力更强的模型，出于两个核心考量：284 token/s 的生成速率使记忆提取与压缩几乎感觉不到延迟；不到 GPT-5.5 一半的单价，让频繁的记忆读写得以实现。以下是这套体系的完整设计方案。

二、记忆分层架构：该记的记，该忘的忘

智能体的记忆不应是“大杂烩”，而应像人脑那样分层处理。我们将其拆解为三层：

工作记忆依靠模型原生上下文窗口承担，但窗口无法无限填充。短期记忆解决“这次聊完，下次还能接上”的问题。长期记忆则让 AI 越来越懂你——记住你的技术栈、编码习惯与项目结构。

三、短期记忆：实时摘要，挤出水分

短期记忆的核心技术是“摘要压缩”。每对话 5 轮，自动触发一次压缩。将冗长的对话历史交给 Gemini 3.5 Flash，由它提炼成 200 字以内的结构化要点。

要点中仅保留四类信息：已确认的需求、已完成步骤、当前待处理问题、用户明确提出的约束。那些“嗯”“好的”“请继续”等无意义用语，一律剔除。

如此处理立竿见影。多轮对话的 Token 消耗可降低 45% 以上，且模型注意力不再被无关信息分散，后期回答的准确率反而更高。

四、长期记忆：精准检索，随用随取

跨会话记忆不能每次都全量加载，必须借助向量数据库进行语义检索。每当一个会话结束，系统会自动将压缩后的短期记忆、用户的显式偏好（例如“我喜欢简洁的回答”）以及项目关键信息存入向量库。

下次用户提问时，系统先拿问题去库中检索最相关的几条记忆，然后作为隐藏的背景知识注入到系统提示词中。这好比给 Agent 配了一个随身携带的“项目档案袋”。

下面这段代码展示了记忆检索的核心逻辑：将用户问题向量化，去数据库中寻找相似度最高的片段，然后拼接成一段摘要供模型使用。

def retrieve_context(query, top_k=3):
    query_vec = embed(query)
    results = vector_db.search(query_vec, top_k)
    return "n".join([r["text"] for r in results if r["score"] > 0.75])

五、避坑指南与工程边界

成本控制。 虽然 Gemini 3.5 Flash 价格低廉，但无节制地读写向量数据库、频繁触发摘要压缩，仍会增加额外开销。建议为记忆更新设定触发阈值，避免“为了记而记”。

冲突处理。 当用户的旧偏好与新指令产生冲突时（例如以前用 Java，这次要求 Go），系统必须能识别并覆盖旧记忆。做法是让模型在检索时优先考虑“最近更新时间”的权重，同时低置信度的旧记忆自动降级为“待确认”状态。

隐私安全。 用户的敏感项目信息在存入数据库前必须脱敏。可在存入前再经过一道轻量模型，将 IP、密码等高风险字段过滤掉。

六、总结

记忆系统让 Gemini 3.5 Flash 从一个“一次性工具”转变为一个“持续成长的伙伴”。它的高性价比是这套方案能够落地的根基——高频的记忆读写没有拖垮预算，极快的响应速度使摘要压缩毫无等待感。

记忆系统的本质，不在于存储了多少信息，而在于你需要时，它能精准回忆起最关键的那件事。这或许正是智能体走向真正“智能”的必经之路。