Agent 记忆系统:别一上来就上向量库
你想给 Agent 加"记忆",打开教程,第一步就是:装个向量数据库,选个嵌入模型,写分块逻辑。 我见过太多团队这么干,然后卡在"为什么它检索出来的东西牛头不对马嘴"上,卡好几周。 这里有个反常识的事实:2026 年真正在干活的 Agent——Claude Code、Cursor、Devin——它们理解你的代码库,靠的是 grep、读文件树、find,不是向量库。一个能调试整个工程的 Agent 都不需要语义检索,你那个客服机器人凭什么需要? 记忆不是一个"功能",是一条演进路径。绝大多数 Agent 走到第二级、第三级就够用了一辈子。向量库是这条路的终点,不是起点——而且很多人这辈子都到不了终点,也不需要到。 这条路长什么样 flowchart TD A[对话历史窗口原始消息全塞进 prompt] -->|上下文要满了| B[摘要压缩把旧消息缩成几句话] B -->|要记的事多且结构清晰| C[结构化记忆用户画像 / 事实表键值或 SQL] C -->|要回忆的东西多又模糊| D[向量检索嵌入 + 语义搜索] style A fill:#d6f5d6,stroke:#3c9e3c style B fill:#fdf3c2,stroke:#e8c83c style C fill:#fde7c2,stroke:#e8b23c style D fill:#f5d6d6,stroke:#c23c3c 绿色那级,90% 的 Agent 起步就够用。每往下一级,复杂度都明显涨一档。升级的触发条件很具体,不是"感觉该升了"就升。 下面一级一级讲。 第一级:对话历史窗口,够用就别折腾 最朴素的记忆:把这轮对话的所有消息,原封不动塞进 prompt。用户说一句、Agent 答一句,全在上下文里。 听起来太简单了,简单到不像"记忆系统"。但你得算一笔账:2026 年主流模型的上下文窗口普遍 20 万 token 起步,长的到 100 万。一轮普通的客服对话、一次代码调试会话、一场旅行规划,撑死了几千到几万 token。整段对话原样塞进去,窗口连一半都用不满。 这一级的好处不只是简单: 零信息损失。模型看到的是逐字原文,不是被你提炼过、可能丢了关键细节的二手货。 零检索错误。没有检索这一步,就没有"该召回的没召回"“召回一堆噪音"这类问题。 零额外基础设施。不用嵌入服务,不用向量库,不用同步任务。 什么时候该往下走?只有一个信号:上下文真的要满了。 不是"对话有点长了”,是你把 token 数打出来,发现已经吃掉窗口的 60%~70%,再聊下去要溢出。在那之前,任何"我们是不是该上个记忆框架"的讨论都是过早优化。 ...