长任务 Agent 的记忆管理，从会话恢复到经验复用
核心结论： OpenAI Agents API 把“持续运行数天”的 Agent 推向标准化，也暴露了长任务的另一面：上下文可以被压缩，进程可以被恢复，但一条状态为什么值得长期保留、何时失效、谁有权使用，仍然需要独立的系统判断。
2026 年 9 月 10 日，OpenAI 发布 Agents API 公开测试版，将会话编排、上下文压缩和任务恢复等能力整合到托管的 Agent 运行框架（harness）中。开发者可以通过 API 启动 Agent，配置工具调用与子 Agent 协作，并在后续交互中继续推进已有任务。
当 Agent 的工作从单轮问答扩展到跨会话、跨工具的连续执行，系统就需要持续跟踪任务进度、用户要求和阶段性结果。模型的推理能力、工具执行能力与状态管理能力，共同影响长任务的完成质量。
在这样的任务中，上下文管理有助于保留当前步骤所需的信息。对于需要跨会话复用的内容，还要进一步明确四个问题：哪些信息值得长期保存？新信息与旧信息冲突时采用哪条？多个 Agent 可以共享什么？任务结束后哪些信息应当删除？
长期记忆管理围绕这些问题展开。它以用户、任务或 Agent 为关联对象，管理信息如何跨会话保留、随时间更新，以及在什么范围内被调用，并与上下文管理、检索和底层存储配合工作。
长任务 Agent 为什么需要记忆管理？
短任务所需的信息通常可以保留在当前上下文中。长任务则会不断生成工具结果、文件、计划、错误日志、用户反馈和阶段性结论。随着这些内容积累，将完整历史持续放回上下文，会带来三个需要处理的问题。
第一，历史内容会增加输入规模。如果每轮请求都携带完整历史，输入会随任务推进而增长，其中与当前步骤无关的内容也会反复进入上下文。筛选本轮所需的信息有助于控制输入规模；实际成本和延迟还取决于模型、缓存等机制。
第二，压缩需要保留信息来源和状态。对话摘要可以缩短文本，但如果省略了必要标记，就可能模糊“用户明确要求”“模型推测”“工具返回事实”和“已经失效的计划”之间的区别。后续任务需要据此判断哪些内容可以沿用，哪些仍需核实。
第三，信息的使用范围需要明确。一个子 Agent 写下的中间结论，是否已经核实，能否供其他 Agent 使用？一次失败尝试，哪些部分值得作为经验保存，哪些只需留在执行日志中？这些选择决定了历史信息如何影响后续工作。
因此，设计长任务 Agent 时，可以按四类管理对象明确分工。
| 管理对象 | 典型内容 | 主要职责 |
|---|---|---|
| 任务执行状态 | 执行进度、工具调用记录、等待中的步骤 | 由运行框架和应用保存，用于继续执行与异常恢复 |
| 工作上下文 | 当前指令、计划、最近的工具结果、召回的信息 | 组织模型本次推理可见的内容，按需压缩和替换 |
| 外部知识 | 产品手册、项目文档、业务制度 | 从来源系统检索，维护文档版本和访问范围 |
| 长期记忆 | 用户偏好、历史要求、可复用的任务经验 | 明确保存对象、适用范围、更新方式和删除路径 |
这些管理职责可以相互配合。上下文窗口限定一次推理能够容纳的信息范围；RAG 将检索到的信息用于生成回答，既可以检索外部知识，也可以召回历史记忆；向量数据库则可以提供向量存储与相似性检索能力。长期记忆管理关注信息如何写入、跨会话保留、随时间更新，以及在什么范围内使用。
以跨会话的报告任务为例，任务执行状态记录报告做到哪一步，工作上下文包含当前处理的章节，知识库提供需要引用的产品资料，长期记忆保存用户对报告格式的持续要求。下一次生成报告时，应用可以召回这些要求，并结合当次指令决定如何使用。
涉及订单支付状态、审批结果等业务数据的操作，则要以相应业务系统确认的当前状态为依据。记忆中的历史描述用于补充背景。
生产环境中的记忆管理
长任务中的记忆会不断变化。用户补充了新的要求，旧计划需要更新；多个 Agent 接手同一项工作，共享信息需要有明确范围。记忆架构需要把这些变化纳入持续运行的流程，让信息的写入、使用、更新和删除相互衔接。
| 职责 | 管理内容 |
|---|---|
| 写入 | 选择需要保存的内容，区分用户陈述、工具结果和模型推断，记录可供核对的来源、时间和关联主体 |
| 组织 | 明确记忆属于哪个项目、用户或 Agent，划分个人记忆与共享知识的存放范围 |
| 检索 | 按任务需要选择记忆种类、过滤条件和返回数量，并在服务端执行相应的访问控制 |
| 更新 | 区分信息补充、状态变化与错误纠正，核对更新后的内容及后续检索结果 |
| 删除与保留 | 明确保留期限、删除对象和验证方式；应用自行保存的副本、日志与缓存按各自的保留规则处理 |
| 运行记录 | 关联任务、记忆操作与实际送入模型的记忆，为异常排查提供依据 |
这些操作需要在同一条流程中衔接。例如，用户修改了报告格式要求，系统要更新对应记忆，让后续检索能够获取新的要求，并留下可供核对的修改记录。涉及多个 Agent 时，还要限定各自可读取和修改的范围。
MemOS 如何把记忆职责从应用逻辑中拆出来
在 MemOS 中，我们将记忆的读写与维护组织为独立的系统能力。开发者可以通过组件和接口配置记忆处理流程，管理哪些信息被保存、何时召回，以及如何更新和删除。
通过 MemOS Cloud 接入时，应用可以调用写入、检索、修改、反馈和删除接口，并通过项目 API Key、用户标识及 Agent 过滤条件设置记忆的检索范围。会话标识 conversation_id 用于提高当前会话相关记忆的召回权重，不承担强制隔离职责。
面对偏好变化和状态更新，MemOS Cloud 的时间感知能力会结合查询中的时间线索，选择当前或历史记忆。用户纠正信息时，自然语言反馈可以触发相关记忆的校正与更新；需要精确修改时，也可以直接修改指定记忆条目。处理后的内容和检索结果可供应用查询核对。
长任务中的工具使用过程和任务经验，同样可以成为后续工作的参考。应用写入工具调用参数、真实返回结果及其关联信息后，MemOS Cloud 可以提取和保存工具使用轨迹。
对于可复用的任务方法，MemOS Cloud 的记忆自进化功能可以从历史对话中提炼技能，也支持上传已有的技能文件。检索时选择相应的记忆种类，即可召回相关轨迹或技能，交给 Agent 参考使用。
对于不再保留的内容，MemOS Cloud 支持按记忆 ID 删除当前项目中的指定条目，并通过查询核对结果。
MemOS 的开源架构采用 Components + Handlers 模式，将系统组件与请求处理逻辑分开。MemCube 统一组织记忆模块，支持为不同用户和应用场景划分记忆容器；Handlers 协调组件完成添加、搜索和反馈等操作；MemScheduler 在后台分发记忆更新、组织和反馈等任务，并提供任务状态与操作日志，便于跟踪异步处理进度。
接入应用时，这些记忆操作需要与现有的身份认证、业务授权和监控流程关联。应用服务端依据业务规则确定读写范围，并处理自身保存的副本与缓存。
如何验证长任务中的记忆流程
记忆流程的验证需要覆盖多次交互。保存的信息能否在新会话中被找到，用户的修正能否进入后续任务，切换用户或 Agent 后检索范围是否符合预期，都要结合具体任务检查。验证时，可以从以下七个问题展开。
- 任务跨会话恢复时，系统使用的是原始历史、摘要，还是结构化状态？这些信息分别由哪一层保存和恢复？
- 一条长期记忆是否保留来源、时间、主体和作用域？
- 模型、嵌入模型或 Agent 版本升级后，旧记忆的检索和使用是否经过兼容性测试？
- 多个子 Agent 同时写入时，是否有明确的并发和冲突处理规则？
- 错误记忆能否被反馈、修正和删除？如果已经影响后续任务，能否定位并处理相关记录？
- 检索范围能否按身份、权限、时效和任务阶段设置，并由应用服务端执行相应的访问控制？
- 一次异常操作能否关联到当时的输入、实际送入模型的记忆和工具执行结果？
当 Agent 持续参与多个任务和会话，记忆就需要与模型、工具和执行环境一起被设计和维护。通过 MemOS，我们将记忆的读写、更新和删除提供为可调用的系统能力，使跨会话积累的信息能够被持续管理，并在后续任务中按需使用。
了解更多：MemOS 官方网站｜MemOS 文档｜MemOS GitHub
关于记忆张量MemTensor
记忆张量（上海）科技有限公司（以下简称“记忆张量MemTensor”）是由上海算法创新研究院孵化，并由中国科学院院士担任首席顾问的新一代大模型与长期智能基础设施企业。
公司以“低幻觉、个性化、自我学习进化”为核心，长期聚焦大模型长期记忆与持续学习问题，围绕 Memory³ 相关记忆机制研究、MemOS 记忆操作系统、Agent 和记忆基础设施产品化，以及记忆原生通用基座模型，构建从理论探索、系统工程化到模型层探索的递进式技术路线，推动 AI 从一次性生成走向长期智能。
公司已与招商、海诚、荣耀等重要合作伙伴建立深度协同关系，并在 AI 陪伴、游戏、端侧智能硬件、金融及工业等多个重点行业实现商业化落地，先后累计完成近两亿元融资，由中金、孚腾、华为哈勃、商汤、和玉等众多知名投资机构参投。