夜雨聆风1
大模型懂不懂你，全靠智能体记性好不好。本篇就来详细谈谈智能体另外一个重要特性——记忆（Memory），从技术本质、发展演进到实操落地，全程干货无删减。
大语言模型（LLM）自诞生起就带有一个致命的工程缺陷：无状态（Stateless）。每一次API调用，模型都如同一张白纸，不记得上一轮对话的上下文，不记得用户的偏好，更不记得自己曾经犯过的错误。
早期，业界凭借大模型惊人的涌现能力，普遍误以为“只要参数够大、提示词够巧，记忆就不是问题”。但随着智能体（Agent）的兴起，这一认知被彻底打破——当Agent的任务链超过5-10步，就会开始出现“幻觉循环”、重复执行操作，甚至彻底偏离任务目标。其根本原因十分简单：模型没有工作记忆，也没有长期记忆，无法实现复杂任务的连贯推进。
智能体记忆作为一个独立的技术概念与架构模块，正式成型于2023年春夏。这一时期有两个标志性事件，直接推动了智能体记忆赛道的爆发：
一是斯坦福大学提出了Agent记忆的三层架构：记忆流（Memory Stream）→ 检索（Retrieval）→ 反思（Reflection）。这是业界第一次有人用计算架构，模拟人类记忆的“编码-存储-提取-巩固”完整过程，为智能体记忆的落地提供了核心框架，也直接点燃了“Agent Memory”赛道的热度。
二是伯克利MemGPT明确提出了全新定位：LLM的上下文窗口就相当于CPU的寄存器，而外部存储则对应RAM（内存）/硬盘。基于这一认知，MemGPT设计了分层记忆管理机制，让模型能够自主决定哪些信息保留在主上下文（Main Context），哪些信息归档到外部存储（External Storage），并通过函数调用实现“虚拟上下文管理”，首次将“记忆”从简单的“检索问题”，升级为“操作系统级的资源调度问题”。
这两个关键节点，标志着“智能体记忆”正式脱离Prompt Engineering（提示词工程）的附属地位，成为Agent架构中独立、可设计、可优化的核心模块，开启了其快速发展的新阶段。
自那以后，智能体记忆经历了三次明显的范式迁移，每一次迁移都推动其向更成熟、更实用的方向发展：
第一阶段是向量数据库统治期，核心理念是“RAG即记忆”。这一时期，记忆体的实现方式相对单一，主要采用“向量数据库（Vector DB）+ 嵌入模型（Embedding）”的组合，通过向量检索实现基础的记忆存储与提取，满足简单场景下的记忆需求。
第二阶段是架构分化期，智能体记忆从“单纯的存储”走向“精细化管理”，三条清晰的技术路线逐渐形成：
1. OS派（以Letta/MemGPT为代表）：坚持“记忆是资源调度问题”的核心逻辑，认为记忆不该由开发者硬编码设定，而应该由Agent自主管理。为此，该流派引入了“记忆编辑函数”、“上下文窗口预算控制”、“自动归档策略”等功能，让Agent能够根据任务需求自主调控记忆。
2. 开发者中间件派（以Zep为代表）：Zep的定位十分明确，不做完整的Agent框架，只专注于打造“记忆层（Memory Layer）”这一核心模块。它内置了实体抽取、对话摘要、时间线重建、自动遗忘机制等实用功能，采用“托管服务+SDK”的方式，将记忆模块变成类似“数据库连接池”的基础设施，方便开发者快速集成到自己的Agent项目中。
3. 平台黑盒派（以Dify、Coze、FastGPT为代表）：主要面向非技术用户或需要快速搭建原型的团队。这些平台将记忆功能封装为简单的“开关”或“滑块”，用户无需关注底层技术，只需简单设置短期记忆（最近N轮对话）、长期记忆（向量检索）、用户画像（自动提取）等参数，就能快速启用记忆功能。
第三阶段是当下正在经历的长上下文冲击期，智能体记忆的定位发生了微妙但深刻的转变：从“弥补上下文不足的外挂硬盘”，转向“管理状态、沉淀身份、协调多智能体的中枢系统”。如今，记忆的核心作用不再只是“记住信息”，更重要的是“理解用户是谁”、“知道双方曾经进行过什么对话”、“决定下一步该调用什么工具、执行什么操作”，成为智能体实现自主决策的核心支撑。
记忆架构演进至今，行业内的共识逐渐清晰：混合架构（Hybrid Memory）才是最终方向。其中，长上下文承担“工作记忆”的角色，用于处理当前任务的即时信息；外部记忆则承担“长期记忆+程序性记忆”的角色，用于存储长期用户偏好、项目规范、历史操作等内容，二者协同发力，实现高效的记忆管理。
值得注意的是，智能体记忆的发展，并非一条“技术自然演进”的直线，而是一条“被成本、延迟、精度、产品定位反复拉扯”的曲线。每一个关键节点的技术选择，都不是“技术最优解”的胜利，而是“当下约束条件下的可行解”的妥协与迭代。记忆模块的演进历程，本质上也是AI工程从“玩具级demo”走向“工具级应用”，再走向“系统级产品”的生动缩影。
智能体有哪些具体的记忆方式呢？我们以OpenCode为例，详细说明其记忆功能的实现与使用方法，兼顾理论与实操，方便大家快速上手。
OpenCode自带基础会话记忆，同时也支持长期记忆（跨会话/跨项目），不过长期记忆功能需要安装对应插件才能启用，具体分为以下两种情况：
一、自带基础记忆（开箱即用，无需额外配置）
1. 会话内上下文：在同一次对话中，OpenCode会自动记住对话历史、代码修改记录、工具调用结果等信息；当上下文存储空间满时，系统会自动进行智能压缩（该功能默认开启），确保对话的连贯性。
2. 会话持久化（Session）：所有会话数据会存储在本地SQLite数据库中，即使重启OpenCode，之前的会话也能正常恢复，无需重新开始对话。
相关操作指令：
查看会话：opencode session list
恢复会话：opencode --session <id>（其中<id>为会话唯一标识）
3. 项目级永久记忆（AGENTS.md）：在项目根目录下放置AGENTS.md文件，在该文件中编写项目架构、开发规范、踩坑记录等内容，OpenCode在每次会话时都会自动加载该文件中的信息，实现项目级别的记忆共享。示例（AGENTS.md文件内容）：
#项目规范-数据库：MySQL-API：RESTful-代码：用const/let，禁用var
二、长期记忆（跨会话/跨项目，需安装插件）
OpenCode支持两种长期记忆插件，分别对应不同的技术流派，大家可根据自身需求选择：
1. 官方插件：opencode-supermemory
该插件与Zep一样，属于中间件派，其记忆层采用托管服务模式，使用前需要申请API-Key才能正常启用。核心功能包括：跨会话/跨项目记住用户偏好与项目信息、自动将记忆注入对话上下文、智能压缩记忆数据、保护本地隐私等。
2. 社区插件：opencode-mem
该插件与MemGPT一样，属于OS派，记忆数据存储在本地，通过工具调用实现记忆的管理与调用。核心依托本地向量库（SQLite+USearch），实现项目记忆与用户画像的持久化存储，支持多种记忆操作模式。
记忆操作指令：memory({mode:"add/search/profile/list"})，其中mode参数可根据需求选择，add为添加记忆、search为检索记忆、profile为查看用户画像、list为列出所有记忆。
下面我们重点安装opencode-mem插件，实际操作一下记忆的存取过程，步骤简单易懂，新手也能轻松完成：
一、安装 opencode-mem 插件
在终端中直接运行以下一条命令，无需额外配置：
opencode plugin opencode-mem等待系统自动下载并安装，当终端中出现“success”字样时，就代表插件安装完成。
二、配置插件
插件安装完成后，需要在配置文件中添加插件信息才能启用，具体步骤如下：
1. 找到配置文件路径：~/.config/opencode/opencode.json
2. 在该文件中添加插件配置，具体内容如下：
{"plugin":["opencode-mem"]}
3. 保存配置文件后，重启一次OpenCode，插件就会自动加载并开始正常工作，后续对话的记忆会自动存储。
三、测试插件是否生效（可选操作）
为了确认插件已正常启用，我们可以进行简单测试，步骤如下：
1. 启动OpenCode后，输入指令让它记住特定信息，例如：“记住我喜欢用 React + TypeScript”；
2. 关闭OpenCode，然后重新打开；
3. 向OpenCode提问：“我喜欢用什么技术栈？”；
4. 如果它能准确回答“React + TypeScript”，说明超级记忆功能已经正常工作 ✅。
四、opencode-mem配置项详解（可选配置）
一般情况下，我们不需要额外配置，系统会按默认值运行，但为了让大家更好地理解插件的运行机制，这里详细介绍其配置项，可根据自身需求修改：
在~/.config/opencode 目录下新建 opencode-mem.jsonc 文件，将以下配置项复制进去，按需修改即可（不改动则可删除，系统按默认值处理）：
{// ===== 基础存储与模型配置 ====="storagePath": "~/.opencode-mem/data", // 数据存储路径"embeddingModel": "Xenova/nomic-embed-text-v1", // 文本向量化模型"maxMemories": 10, // 最大记忆检索数量// ===== 用户身份配置 ====="userEmailOverride": "user@example.com", // 覆盖自动分析的用户邮箱"userNameOverride": "John Doe", // 覆盖自动分析的用户名// ===== Web 界面与通知 ====="webServerEnabled": true, // 启用 Web 管理界面"webServerPort": 4747, // Web 界面端口"showAutoCaptureToasts": true, // 显示自动捕获通知"showUserProfileToasts": true, // 显示用户画像分析通知"showErrorToasts": true, // 显示错误通知// ===== 自动捕获与画像分析 ====="autoCaptureEnabled": true, // 启用自动捕获对话"autoCaptureLanguage": "auto", // 自动捕获语言"userProfileAnalysisInterval": 10, // 用户画像分析间隔(会话次数)// ===== AI 提供商配置 =====// 推荐复用OpenCode配置"opencodeProvider": "anthropic", // AI 提供商，可删掉，则采用agent的大模型"opencodeModel": "claude-haiku-4-5-20251001", // AI 模型，可删掉，则采用agent的大模型// ===== 高级功能：记忆压缩 ====="compaction": {"enabled": true, // 启用记忆压缩"memoryLimit": 10 // 压缩后的记忆保留数},// ===== 高级功能：对话注入 ====="chatMessage": {"enabled": true, // 启用注入历史记忆到新会话"maxMemories": 3, // 最多注入的记忆数"excludeCurrentSession": true, // 排除当前会话中的记忆"maxAgeDays": undefined, // 记忆有效期（天）"injectOn": "first" // 注入时机（"first"/"every"）},// ===== 记忆查询范围 ====="memory": {"defaultScope": "project" // 查询范围("project"/"all-projects")}}
五、避坑
这里重点提醒两个避坑点，避免大家在使用过程中遇到问题：
1. 嵌入模型访问问题：配置项中的"embeddingModel": "Xenova/nomic-embed-text-v1"，默认是从Hugging Face上加载的，而国内网络环境无法直接访问Hugging Face。解决方法是：从魔搭社区找到该模型并下载到本地，然后将配置项修改为本地模型路径，示例如下：
"embeddingModel": "C:/Users/admin/.cache/huggingface/hub/models/Xenova/nomic-embed-text-v1",2. 记忆存储失灵问题：刚开始使用opencode-mem插件时，可能会出现记忆体存储失灵的情况，这是正常现象，只需通过多轮对话、明确的记忆指令多训练几次，插件就能正常捕获和存储记忆。
六、记忆如何发给大模型
启动OpenCode后，当第一次对话发生时，opencode会自动把记忆体中的最近3条记忆存入上下文中，并发送给大模型，同时会用“[MEMORY]”标识记忆内容，方便大家区分记忆信息与当前对话内容，示例如下：
{ "role": "user", "content": [ { "type": "text", "text": "[MEMORY]\n\nProject Knowledge:\n- [100%] 喜欢的技术栈是 React + Python\n- [100%] 用户喜欢研究智能体的各种特性，比如智能体Memory\n- [100%] 测试数据" }, { "type": "text", "text": "今天天气如何" } ] }
七、查看记忆
opencode-mem存储的记忆内容可以通过访问 http://127.0.0.1:4747查看，如下：
结语