📰 AI 资讯

从上下文到经验资产：Agent 记忆系统的工程化路径与 MemOS 实践

2026-07-14 10:30

在大模型技术从对话式交互向自主式 Agent 演进的浪潮中，记忆（Memory）正从一个提升效率的辅助功能，蜕变为决定 Agent 能否执行连续复杂任务的生死线。本文整理自记忆张量 MemTensor 创始人 & CEO 熊飞宇博士在 QCon 全球软件开发大会 2026 北京站的分享《从上下文到经验资产：OpenClaw 热潮下的 Agent 记忆系统工程实践》。在本次分享中，熊飞宇系统性地阐述了记忆张量对大模型记忆技术的深层思考与实践成果。覆盖了记忆增强的行业趋势与整体落地应用链路、MemOS 1.0 与 2.0 的核心架构迭代、其在主流 agent 的无侵入式插件增强方案，以及面向企业多 Agent 协同产品的 ClawForce 的设计思路。以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。<h2 data-type="heading" data-id="heading0">记忆为何成为大模型应用的核心瓶颈</h2>无论是大模型自身的记忆能力，还是面向 Agent 的长期记忆系统，随着 AI 应用从单轮问答走向连续任务执行，其重要性都在持续提升。这背后有几个关键推动因素。首先，OpenAI 对记忆能力的持续探索，使行业进一步认识到长期记忆在用户体验和任务连续性中的价值。Sam Altman 也是这一方向的重要倡导者之一，他曾多次强调，模型需要更好地理解用户的长期偏好、历史信息和持续变化的需求。我们在实际使用中也观察到，当系统能够稳定记住用户偏好、过往上下文和关键约束后，用户不再需要在每次交互中重复提供大量背景信息，模型也能基于更完整的历史信息给出更贴近需求的回答。因此，记忆能力逐渐从一个提升效率的辅助功能，发展为大模型产品和 Agent 系统中的关键基础能力。另一个重要推动因素来自 OpenClaw 这类连续任务 Agent 的出现。过去，记忆更多被视为效率优化问题：有了记忆，系统可以提升回答准确率和召回率，并降低 token 消耗。但在需要自主规划和执行长流程任务的 Agent 场景中，记忆已经进一步关系到系统可靠性。若 Agent 无法准确记录自身状态、任务进度和环境反馈，就容易出现重复执行、步骤跳转错误或连续任务中断等问题。这促使业界重新评估记忆在 Agent 系统中的基础性作用。从工程实践看，单次 session 内的交互已经包含大量上下文信息：用户输入、工具调用结果、静态知识、动态信息、模型推理过程以及用户反馈都会影响最终回答。当范围进一步扩展到跨 session、跨用户、多 Agent 协同乃至多应用协同时，系统需要处理的上下文关系会急剧增加。因此，Agent 和大模型应用需要一个专门的记忆增强层，用于屏蔽复杂的状态管理、知识组织与上下文调度问题。这也是 MemOS 的核心出发点。记忆增强层的核心链路可以拆分为五类能力：抽取、组织、检索、更新与共享。抽取解决“什么信息应该被记住”的问题，需要从对话、工具调用和企业文档中识别关键事实、偏好、约束和知识片段；组织解决时间、版本与关系建模问题，因为记忆会随事件和时间变化而不断演进；检索负责在合适的时机调用相关记忆，以辅助推理和生成；更新负责对过时、冲突或不再适用的记忆进行修正、替换、遗忘与隔离；共享则需要在多 Agent、多应用和企业协同场景中平衡知识复用与数据安全。此外，生成式模型在记忆抽取和归纳阶段可能产生错误。与普通回答中的幻觉不同，错误记忆一旦被写入，就可能在后续检索、更新和共享环节持续传播，最终影响整个记忆库的可靠性。因此，记忆系统不仅要关注召回效率，还必须引入校验、版本管理和治理机制，降低错误写入和记忆漂移的风险。<h2 data-type="heading" data-id="heading1">模型内生驱动与应用外向驱动的双路径融合</h2>从实现路径看，当前记忆增强主要有两类方向。一类是模型内生驱动，通过改进基座模型架构、训练目标或参数编辑方法，让模型自身具备更强的记忆能力。例如团队早期提出的忆³（Memory³）框架，核心思想就是对不同形态的记忆进行分层建模；也有研究团队尝试通过模型参数编辑来更新模型记忆。另一类是应用外置驱动，通过提示流、检索系统和记忆管理层在应用层模拟记忆过程，Mem0、Zep 等工具大体属于这一思路。两类路径各有优势。模型内生路径从底层嵌入记忆机制，理论上具有更高的能力上限，新的架构、训练策略和建模方式也可能提升记忆读取效率；但其训练成本、工程复杂度和迭代周期都较高。团队在 2024 年初训练忆³基座模型时，即使规模仅为 2.4B，也需要大规模 A100 集群和较长训练周期，工程风险较高。应用外置路径则更适合快速落地，可在应用层管理交互内容和外部信息，部署效率和扩展性更强；但它更依赖底层模型能力，也需要额外机制来控制错误写入、记忆漂移和幻觉传导。MemOS 的设计思路，是在系统层融合模型内生路径与应用外置路径。具体而言，系统需要统一管理模型参数外的明文记忆、模型参数内的参数记忆，以及运行时缓存中的激活记忆，并通过多层次协同和多触点调度，在读取效率、写入成本、更新速度与治理能力之间取得整体平衡。MemOS 1.0 的系统框架主要包含两部分：一是记忆调度系统，负责明文记忆、激活记忆和参数记忆之间的调度与协同；二是记忆治理系统，面向个人隐私、企业知识安全和生命周期管理，提供记忆的权限、隔离、更新和管控能力。在核心技术上，首先是记忆分层架构。该架构源自忆³模型的分层思想，将 MemOS 中的记忆划分为参数记忆、激活记忆和明文记忆三类。明文记忆以可读、可治理的方式存储，优势在于更新灵活、修改成本低，但检索—生成链路会引入额外时延。激活记忆主要对应 KV Cache 管理，重点是将合适的信息提前放入缓存，以提升缓存命中率、降低首 token 时延并减少 token 成本。参数记忆则沉淀在模型内部，读取效率高，但训练和更新成本最高。不同形态的记忆在读写效率和更新成本上存在差异，因此需要将合适的记忆放在合适的位置。第二个关键技术是记忆调度管理，即围绕 Agent 场景构建记忆调度与生命周期管理机制。例如，当对话主题从用户长期偏好转向某个临时业务议题时，系统可以根据用户行为、交互内容和推理状态进行异步调度，提前检索相关知识并写入激活缓存。这样即使话题发生变化，系统仍能维持较高的缓存命中率，从而提升整体响应效率。第三个关键点是图结构化的记忆组织架构。记忆具有时间、版本和关系演化特征，系统需要通过图化组织方式表达事件之间的逻辑关系、冲突关系和时间关系，从而更有效地支持记忆管理、检索、校验和治理。<h2 data-type="heading" data-id="heading2">MemOS 2.0：面向长程任务的可成长记忆系统</h2>MemOS 2.0 发布于 25 年 12 月，面向长程任务场景进一步扩展了记忆管理能力。1.0 版本主要解决记忆读写所需的分层管理和调度问题；到 2.0 阶段，游戏、情感陪伴、企业复杂任务等场景中的 Agent 任务复杂度持续提高，系统需要更好地支持长期运行、复杂计划和状态演进。如果说 1.0 的重点是让记忆可管理、可调度，那么 2.0 的目标就是让记忆在长程任务中可用、可成长。随着 OpenClaw、Hermes 等持续性任务 Agent 的普及，运行态记忆、状态管理和经验沉淀的需求变得更加集中，MemOS 的使用量也一路攀升。MemOS 2.0 的第一个核心思路，是以用户和 Agent 为中心进行运行状态管理。长程任务 Agent 的常见失败之一，是对自身执行状态判断不准确。例如，一个任务包含十个步骤，Agent 已经完成第二步却误判为未完成，进而反复执行；或者在某一步尚未完成时直接进入下一步。其根本原因在于系统缺乏对对话记忆、行为记忆和环境反馈的准确记录与调度。MemOS 希望通过记忆系统识别用户行为阶段和环境状态，评估状态的重要性与实时性，并进一步支持状态预测、调度与演化。这里的核心思想是：记忆不再只是查询时调用的静态对象，而是需要被实时调度的运行态资源。第二个思路是记忆的版本化管理与进化。对于处理长程任务的 Agent，系统会不断产生不同阶段的记忆快照。MemOS 可按策略保存关键状态快照，并对用户偏好、任务目标和核心事实的变化进行版本化管理。在此基础上，系统可以判断哪些任务或记忆应被淘汰、替换、回滚或遗忘，哪些知识和经验应被沉淀下来，最终推动记忆从简单累积走向可验证、可治理的持续进化。第三个思路，是持续探索记忆原生的基座模型。记忆不应只存在于外挂系统中，也应成为模型能力本身的一部分。在模型架构、训练目标、状态表示和推理机制中，系统需要原生支持信息的存储、更新、压缩、检索和跨时间调用。除 Common Transformer Block 外，团队也在架构上探索 Local Memory 和 Hyper Memory 等模块，希望进一步提升模型对不同记忆形态的处理能力。在社区和云服务层面，MemOS 是一个开源框架，目前在 GitHub 上获得 9.7k star（截止 2026.6.8），并保持增长。团队建立了 OpenMem 社区，汇聚了超过 1.7 万名开发者，其中约 1000 名来自大型企业。开发者在微信、Discord 等社区中围绕技术问题、使用经验和代码贡献进行交流。该社区由记忆张量联合上海交大、北大、人大等高校共同建设，旨在推动 AI Memory 技术与开源生态发展。在云服务调用方面，MemOS 日调用量已超过 100 万次，前三大场景包括各类企业级复杂任务 Agent ，游戏和情感陪伴类应用，以及来自消费电子、端侧智能等硬件应用。在具体案例方面，MemOS 首先应用于某头部情感陪伴类 App，用于提升虚拟角色的长期一致性和沉浸式体验。此类应用对记忆准确性要求较高，如果虚拟角色忘记关键事件或错误理解过往交流，就会直接影响用户体验。MemOS 通过多维结构化属性树和关系阶段建模，使虚拟角色不仅能记住用户基本信息，还能持续理解双方关系所处阶段以及关系演化路径。上线测试后，接入记忆系统的整体对话轮数提升约 16%。第二个案例来自某家电品牌的全屋智能助手。传统智能家居助手通常依赖 App 手动操作，通过预设场景控制灯光、窗帘和家电。引入记忆能力后，系统可以构建更立体的家庭画像，识别春夏秋冬、寒暑假、上学放学等多时间、多场景变化，从而使全屋智能从被动响应走向主动服务。应用 MemOS 后，项目中的基础信息准确率和偏好记忆召回率均有明显提升，系统响应时延也达到全屋智能场景的要求。第三个案例来自工业场景，目标是将资深师傅的一线经验转化为可复用的知识资产。合作企业是工业领域的重要解决方案提供商，其核心痛点在于，工厂长期沉淀的大量经验分散在设备说明书、检测报告、运维手册和故障记录中，缺乏统一整理和结构化沉淀，导致 AI 难以直接继承和复用。通过 MemOS，这些经验可被结构化为“问题—原因—处理方案—结果”记忆单元，并进一步组织为“工业记忆图谱”。当 Agent 和一线运维工程师处理故障时，系统能够快速召回相似处理逻辑，辅助定位和决策；每次维修反馈也可反哺生成新的记忆单元，持续完善记忆库，形成从知识沉淀到反馈学习的闭环。<h2 data-type="heading" data-id="heading3">Agent Memory：让 Agent 从「能用」到「好用」的六维度记忆增强</h2>围绕 Agent Memory，首先需要回答一个基础问题：智能体到底需要什么样的记忆。智能体能力的提升，不应只依赖离线日志分析或人工编写技能模板，而应在与环境和人的持续交互中逐步沉淀。换言之，记忆不是旁路功能，而是智能体持续学习、不断积累经验的重要载体。目前，部分智能体记忆实现更接近轻量化的持久化检索方案，而非一体化记忆系统。其主要问题在于：写入过程较依赖启发式判断，缺少结构化机制；当记忆规模扩大时，写入稳定性和一致性难以保障，容易出现冗余、漂移和冲突。同时，部分架构将 Memory 与 Context 引擎完全分离，导致检索到的记忆未必能被正确组装进上下文，长期记忆也未必能在压缩后稳定沉淀。此外，对上下文压缩的过度依赖可能损害主任务连贯性，尤其在代码生成、复杂工作流等场景中，细节缺失会影响后续任务执行。因此，Agent Memory 需要从文件级存储升级为真正的系统化记忆能力。针对上述问题，MemOS Agent Memory 从六个维度进行增强。第一，在存储方面，系统从单一向量存储和文本型记忆，扩展为文本、激活、参数、偏好四类记忆的统一管理。第二，在检索方面，系统从 BM25 加向量的双路召回，升级为多记忆层级的多路融合召回，并结合 MMR 多样性算法和时间衰减机制，在多样性、准确性和时效性之间取得平衡。第三，在去重方面，系统构建了从 SHA-256 精确哈希、向量余弦检查到大模型判断的三层漏斗去重机制。第四，在进化方面，系统新增 Memory-to-Skill 转化能力，可从沉淀记忆中自动抽取可复用技能。第五，在可视化方面，Memory Viewer 面板让记忆从黑盒变得透明，便于开发者调试和治理。第六，在团队协作方面，Hub 支持技能发布、共享、隔离和复用，帮助组织沉淀团队经验。在产品形态上，Agent Memory 提供云服务和本地部署两种模式。云服务形态支持通过 API Key 快速接入，适合 SaaS 产品进行验证和规模化调用，并支持高并发、低时延和多模态记忆。本地部署版面向企业私有化部署和开发者隐私需求，核心记忆处理可在本地环境中完成，并集成 Mem2Skill、Viewer、Hub 等能力。在实现细节上，Agent Memory 通过对接智能体上下文引擎的六个 Hook，实现全链路的无侵入式记忆增强。这六个 Hook 包括两个同步 Hook、三个异步 Hook 和一个 ON_SPAWN Hook：同步 Hook 负责环境初始化和上下文组装；异步 Hook 负责记忆处理、压缩去重和后处理；ON_SPAWN 用于子 Agent 记忆的继承与管理。每个 Hook 模块都支持插拔，开发者可以根据业务需求单独启用或禁用。在记忆优化方面，三层漏斗去重最高可实现约 75% 的压缩率，使系统文件冗余更低、结构更清晰。Mem2Skill 是另一个核心功能，其路径是将对话碎片转化为结构化任务，再沉淀为参数化技能。系统首先完成记忆捕获、去重和归档，然后从归档记忆中归纳复杂事件的处理逻辑。为了保证技能准确性，系统还会引入反事实校验，判断记忆证据是否对技能形成具有稳定贡献，避免偶然相关信息被错误沉淀为技能。Memory Viewer 面板用于实现记忆黑盒的可视化，支持记忆时间线、向量空间可视化和记忆热力图。系统还提供质量看板，用于监控记忆重复率、关联强度、召回命中率和技能成功率等指标。更重要的是，溯源追踪能力可以记录每条记忆产生自哪个会话、哪个任务，被哪些任务引用过，以及经历过几次合并和去重，从而为审计、调试和治理提供依据。团队协作 Hub 则面向组织级知识复用。通过 Hub Server，底层建立存储系统，上层封装登录、记忆、Skill 和 Search 等内核能力，实现技能流转和团队级复用。例如，在 K8s 内存泄露排查场景中，资深贡献者定位、解决和预防问题的过程可以被自动沉淀为 Skill，并在 Hub Server 中完成排序和质量追踪。后来者遇到类似问题时，可复用已有处理流程，从而显著缩短处理时间。相关评测显示，使用后回答质量有所提升，单次 Session 输入的上下文成本下降约 30%，用户交互负担减少 50% 以上，最终可实现约 50% 的 token 节省。<h2 data-type="heading" data-id="heading4">ClawForce：面向企业多 Agent 协同的记忆驱动平台</h2>基于 MemOS 的记忆能力，团队开发了企业级多 Agent 协同办公产品 ClawForce。该产品面向企业环境中的批量部署、经验沉淀、事件感知、业务执行和安全治理需求，目标是帮助企业将 Agent 从“能用”推进到“敢用、好用、持续用”。企业级 Agent 落地通常面临五类挑战：第一是部署复杂，个人在本地部署单个 OpenClaw 已有较多实践，但企业需要同时部署数十个、上百个甚至更多 Agent，并要求它们相互协同；第二是经验分散，老员工离职后，经验往往难以沉淀和复用；第三是事件感知不足，邮件、CRM、审批系统等业务事件仍需要人工持续关注；第四是业务执行深度有限，许多系统仍停留在对话和检索阶段，难以进入复杂业务流程；第五是治理困难，数据边界、操作追溯、能力审核和回滚机制都需要被系统化解决。ClawForce 正是围绕这些问题，在 MemOS 之上构建企业多 Agent 协同平台。从产品架构看，ClawForce 可分为三层。底层是智能中枢，包括 MemOS 记忆层、Skill 引擎、事件监听和工具连接等核心能力；中间层是管理端，面向企业 IT、CTO 团队或业务管理员，支持组织接入、Agent 方案配置、审批下发和持续优化；顶层是员工端，主要通过 IM 等入口提供开箱即用的任务协作体验。以商务 Agent 模板配置为例，系统可结合企业内部经验和模型能力，快速生成 SOP、Agent.md 和 User.md。企业 IT 或业务管理员在管理侧完成审核和校验后，可继续配置模型、外挂 Skill、工具权限，并将 Agent 下发到飞书、企业微信等 IM 侧的指定岗位和策略中。策略下发本身也是安全管控的一部分。配置完成后，特定岗位的员工即可在 IM 对话框中调用对应 Agent，并直接完成相关任务。在 Skill 沉淀和回流方面，ClawForce 采用人机协同的知识传承机制。以参展方案制定为例，若初始输出缺乏结构化和可执行性，使用者可以补充关键经验和业务要点；系统一方面更新任务流程，另一方面识别 Skill 的改进点，并在用户确认后生成候选 Skill。候选 Skill 进入后台后，系统会先进行质量评分，再由管理后台执行变更审批。由于 Skill 是企业核心经验资产，审批过程需要保持可追溯、可审核。一旦审批通过，该 Skill 即可沉淀为组织资产，并按权限范围分配给其他适用场景。安全机制是企业落地最关注的问题之一。ClawForce 覆盖事前、事中、事后的全周期治理：事前阶段，可按部署模式提供独立数据库实例、网络隔离和数据边界控制；事中阶段，支持端侧敏感信息脱敏、网关侧安全插件链，以及对群发、批量操作等高危操作的二次确认；事后阶段，系统完整记录操作日志和调用链，并提供异常行为告警和标准化导出能力，便于企业进行审计和复盘。多 Agent 协同是 ClawForce 的重要特性。这种协同既包括单一员工名下多个 Agent 的协作，也包括跨员工、跨岗位的 Agent 协作。例如，商务人员的热点追踪 Agent 可以持续向商务分析 Agent 提供信息；当分析 Agent 判断某一热点具备产品价值时，可以将结构化结论同步给产品经理的 Agent，用于后续产品设计。这个流程展示了企业环境中 Agent 之间如何按需共享记忆、隔离敏感信息，并确保状态传递的准确性。目前，ClawForce 已在研发、电商运营、工艺协作、销售等多个场景进入落地或 POC 阶段，并在部分项目中观察到任务处理效率、知识复用效率和协同透明度的提升。同时，团队也提供适配英伟达硬件和各类国产信创硬件的不同解决方案，以满足不同企业的部署需求。<h4 data-type="heading" data-id="heading5">作者介绍</h4><p d

🔗 查看原文 ↗

← 返回资讯列表