Agent Runtime Memory 指智能体运行时负责管理的一层记忆能力。它把 Agent 在任务中产生的状态、对话和文件里的事实保存下来，在后续步骤或后续会话中按需取回，让 Agent 不必每次调用模型都从空白开始。
这个词在中文语境里有两层用法。泛称指 Agent 运行时提供的记忆能力，具体产品名则可能指 AgentRuntime 平台的 Memory 模块。产品命名并不统一，腾讯云 Agent Runtime 把记忆放在智能层能力里，阿里云 AgentRun 提供记忆存储实例。本文讨论它们共同指向的运行时记忆能力，具体产品只作为实现例子。对正在建设企业级 AI Agent 的团队，这个概念会直接影响三件事，长任务能不能恢复，多轮服务能不能连续，记忆带来的隐私和审计风险能不能控制。
Agent Runtime Memory 指什么
把 Agent 运行拆开看，一次任务通常包含多轮模型调用、工具调用、人工审批和外部系统回写。运行时负责调度这些步骤，记忆负责保存步骤之间需要延续的信息。
所以，Agent Runtime Memory 处理的是在正确的时机，把正确的历史和事实送回模型上下文。聊天记录只是它的一种原料，它还要判断什么时候不该记、什么时候不该取。
从范围上看，它通常包括当前步骤的工作记忆、一次任务的运行状态，以及跨会话的长期记忆。具体产品未必使用同一套命名，但分工相近。
这里要先划一条边界。运行时记忆管理的是 Agent 运行过程中的上下文，不负责替代业务数据库，也不负责定义企业的权威知识。订单状态、库存、余额应以业务系统为准；制度、指标口径、产品政策应放在知识库。记忆可以做补充，不能做唯一事实源。
为什么 Agent 需要运行时记忆
大模型本身没有状态。每次调用都从空白开始，上下文窗口是模型在这一次调用里能看到的全部信息。窗口有限、按 token 计费，调用结束就消失。AgentRuntime 在 2026 年 5 月的一篇工程文章里把这个前提讲得很清楚，长任务如果只靠不断增长的上下文，成本会随步骤线性上升，模型在长上下文中间位置的处理也会变得不稳定。
Agent 的任务形态又比聊天更长。一次客服处理可能要查订单、看历史工单、判断政策、生成回复；一次运营分析可能要跑多个数据步骤，中间还要等人审批。任务持续几分钟、几小时甚至几天，任何一次模型调用都不是完整任务。
只把状态放在上下文里，会出三类问题。会话一换，用户要重新说明背景；任务中断，前面步骤要重跑；多个角色接手，没人说得清当时为什么做这个决定。
运行时记忆要解决的是状态和事实的连续性，模型能力本身不负责这件事。 模型再强，也不会自动知道上一次任务做到哪一步。
运行时记忆分哪三层
可以按生命周期把运行时记忆分成三层。这个分法来自 AgentRuntime 的工程文章，也能和阿里云 AgentRun 的记忆存储能力对应上。不同平台的命名不完全一致，但边界大体相同。
| 层次 | 保存什么 | 生命周期 | 主要作用 |
|---|---|---|---|
| 工作记忆 | 当前步骤的输入、上一步输出、工具返回结果 | 单次模型调用或单步任务 | 让这一步有足够上下文 |
| 运行记忆 | 一次任务的状态、分支、决策、步骤结果 | 一次运行，可跨模型调用和中断 | 支持恢复、重放、审计 |
| 长期记忆 | 用户偏好、实体事实、历史决策 | 跨会话，按策略保留 | 下次不用重新了解 |
阿里云 AgentRun 的记忆存储分为长期记忆、会话历史和会话状态。会话状态用于单次会话内的上下文保存和恢复，会话历史用于完整对话回溯，长期记忆通过向量检索跨会话找回偏好和历史片段。AgentRuntime 则用工作记忆、运行记忆、长期记忆来区分。名称不同，核心问题都是把不同生命周期的信息放在不同的地方。
工作记忆，决定这一步能不能做对
工作记忆是当前步骤真正需要的信息，包括这一步的输入、上一步的输出、工具返回结果。它通常放在上下文窗口里，生命周期很短。
工作记忆的关键动作是筛选。把所有历史都塞进上下文，看起来信息完整，实际会推高成本，也会让模型更难抓住重点。每一步只取当前需要的信息，是运行时记忆和上下文管理配合的地方。
运行记忆，决定任务中断后能不能接上
运行记忆保存一次任务的完整状态，包括每一步的输入输出、走过的分支、做过的判断、等待中的审批。它要跨过多次模型调用，也要经得起进程崩溃和服务重启。
这类记忆通常落在持久化存储里，按步骤提交。AgentRuntime 的做法是把运行状态作为可持久化的步骤记录存入 PostgreSQL，每一步显式读写，任务可以检查、重放，也可以从最后一个提交点恢复。
运行记忆还支撑审计和重放。它让一次长任务变得可审计，出了问题能回到具体步骤，不必只看最后一句回答。
长期记忆，决定下一次还要不要重新介绍
长期记忆保存应该影响未来任务的信息，例如用户偏好、实体事实、历史决策、仍然有效的缓存结果。它通过检索按需取回信息，避免把所有历史都注入上下文。
长期记忆最难的部分是取舍。什么值得记，记多久，冲突时听谁的，用户要求删除时怎么删干净，这些问题没有处理好，记忆会从资产变成负担。
三层记忆分开管理，才能同时兼顾成本、可靠性和可审计性。 全部塞进上下文，短期看似省事，长期会把问题推到运维和合规环节。
它和聊天记录、知识库、长上下文有什么区别
这几个概念经常被混用，实际职责差别很大。
| 概念 | 主要解决 | 常见存放 | 什么时候会失效 |
|---|---|---|---|
| 运行时记忆 | 跨步骤、跨会话的状态与事实连续性 | 运行时记忆库、状态存储 | 未写入、索引未完成、检索不到 |
| 聊天记录 | 还原某次对话 | 会话表、日志 | 换会话、超过保留期 |
| 知识库与 RAG | 企业稳定知识的检索与引用 | 文档库、向量库、图谱 | 文档过期、口径冲突 |
| 长上下文 | 一次调用里放入更多信息 | 模型上下文窗口 | 超出窗口、成本上升、信息被淹没 |
| 模型微调 | 改变模型的行为倾向 | 模型参数 | 更新成本高，不适合频繁变化的事实 |
聊天记录保存的是某次对话的原始消息，适合回溯和审计，但它不会主动提取事实，也不会判断哪些内容值得跨会话保留。聊天记录是记忆的原料，不等于记忆系统。
知识库保存企业相对稳定的知识，例如产品文档、制度、指标定义、历史案例，重点是权威、版本和引用。运行时记忆保存动态上下文，例如用户这次提出的偏好、任务走到哪一步、上次为什么选择这个方案。知识库回答企业应该知道什么，运行时记忆回答这次任务发生过什么。
长上下文是另一种容易混淆的做法。它把更多信息放进一次模型调用，适合单次复杂推理，但不解决跨会话持久化，也不解决任务恢复。窗口再长，也有边界，成本也会随长度上升。AgentRuntime 的工程文章直接指出，上下文窗口不是数据库。上下文窗口承担工作记忆，不承担持久化。
模型微调改变的是模型参数和行为倾向，适合稳定的任务模式。记忆保存的是可变化的事实和状态，更新频率更高。两者可以配合，但不能互相替代。
记忆从写入到召回怎么走
不同产品的实现不同，完整链路通常包含六步。
- 写入。对话、文件、任务步骤结果进入记忆管道。AgentRuntime Memory 目前支持通过 index-conversation 和 index-file 接口索引对话与工作文件。
- 提取。系统从原始内容里抽取决策、偏好、事实等值得长期保留的信息，并按工作区和项目隔离。
- 存储与索引。索引在后台运行，任务完成后才能检索。AgentRuntime 的文档明确说明，索引不是即时完成，检索质量取决于索引了什么。
- 召回。Agent 在回复前搜索相关记忆。工作流只有 agent 步骤会使用记忆，LLM 步骤不会。
- 注入。检索结果按数量和上下文预算放进当前调用。取回太多会挤占工作记忆，取回太少又可能漏掉关键信息。
- 治理。权限、保留期、删除、审计、冲突处理贯穿整条链路，决定记忆能不能在企业环境里长期使用。
上图展示的是主链路，实际系统还会在每一步之后加入权限校验、来源记录和失败重试。
以 AgentRuntime 的 Memory 为例，官方文档把它定义为工作区的长期知识存储。它读取团队选择的对话和文件，抽取事实，之后可以搜索，几个月后仍能找回。索引会消耗 credits，搜索结果依赖索引任务是否完成。截至 2026 年 11 月，Memory 仍标注为 Preview，主要通过 API 使用，控制台还没有独立的 Memory 页面。
这些限制说明，运行时记忆已经进入可用阶段，距离开箱即用还有一段距离。 团队选型时，要把它当作需要治理的基础设施，不能当成一个开关。
AgentRuntime 在 2026 年 8 月的文档里还特别区分了记忆和工作流数据。工作流里的步骤结果只在一次运行中存在，记忆在运行结束后仍然保留。这个边界很重要，否则团队会把临时状态和长期事实混在一起。
企业选型要核对的五个方面
运行时记忆的强度要匹配企业场景。记得多意味着责任大。选型时可以先问五个问题。
| 判断项 | 要问的问题 | 合格信号 |
|---|---|---|
| 隔离 | 记忆按什么范围隔离 | 工作区、项目、用户三级边界清楚 |
| 权限 | 谁能写、谁能读、谁能删 | 读写权限分开，关键操作有审计 |
| 生命周期 | 记忆保留多久，如何删除 | 支持保留策略、删除请求、过期清理 |
| 质量 | 冲突和过期信息怎么处理 | 有来源、时间、置信度，支持人工修正 |
| 成本 | 索引、存储、检索怎么计费 | 能按项目核算，能限制召回预算 |
隔离和删除最容易被低估。 Agent 记得越多，错误记忆的传播范围越大。没有删除机制，一次错误偏好可能在多个会话里重复出现；没有隔离，一个项目的记忆可能被另一个项目检索到。
权限也要分开看。谁能写入记忆，谁能读取，谁能删除，谁能导出，应该是不同的权限。关键操作要留审计记录，否则出了问题无法定位。
这五项能力很难只靠模型解决，更多取决于运行时和平台层。ThinkingAI 的企业级知识库把稳定知识做成 Agent 可调用的基础设施，通过 SSOT 保证同一概念只有一处定义，解决统一指标口径的问题，通过 ChangeSet 让更新可追溯、可对比、可回滚。Agentic Engine 在主 Agent 层承载知识记忆、权限控制与执行审计，并支持私有化部署。运行时记忆负责动态上下文，知识库负责稳定知识，两者配合，才能既记得住，又不乱记。
ThinkingAI 服务全球超 1500 家企业、接入产品超 8000 款，企业知识治理是其 Agent 平台的基础能力之一。对准备把 Agent 放进生产环境的团队，Agent 安全与治理适合和记忆设计一起规划，上线后再补的成本更高。
哪些场景值得先用
运行时记忆的收益，来自重复解释、重复执行和上下文丢失。下面几类场景最容易看到价值。
- 多轮客服与售后。用户可能隔几天再来，Agent 需要记得产品、历史问题和上次承诺，避免让用户重复描述。
- 长流程审批与运营。任务要等人审批、等外部系统回写，运行记忆能让流程暂停后继续，也能在失败时从检查点恢复。
- 跨会话的个人助手。用户偏好、表达习惯、过去的选择会影响回答质量，长期记忆能减少重复沟通。
- 多步分析与报告。分析假设、数据口径、中间结果需要延续，运行记忆能减少重跑，也方便复盘。
也有几类情况可以先缓一缓。
- 一次性的问答。没有跨步骤、跨会话需求，长上下文或普通对话管理就够用，接入记忆会增加索引成本和治理负担。
- 稳定的政策与知识查询。知识库更适合，重点是版本、引用和权限，不需要把每次对话都变成记忆。
- 订单、库存、余额等权威状态。应以业务系统为准，记忆只保存上下文，不能保存权威状态。
- 高敏感数据且没有隔离方案。先解决权限、脱敏、保留和删除，再谈记忆。
记忆的边界，和记忆的能力同样重要。 把不该记的内容记下来，后面要用更高的成本清理。
运行时记忆进入生产的前提条件
运行时记忆是否值得进入生产，取决于三件事：任务是否跨步骤或跨会话工作，任务一次问答就结束的收益有限；错误记忆的代价是否可控，涉及交易、合规或客户权益时，记忆必须有来源、时效和人工修正机制；团队能否把记忆纳入权限、保留和审计。三项都成立才值得上线，否则它只是一个看起来聪明的功能，给后面留下更多清理工作。
FAQ
Agent Runtime Memory 和长上下文是一回事吗？
长上下文解决一次调用里能放多少信息，运行时记忆解决信息能不能跨步骤、跨会话保留，并在需要时取回。长上下文可以承载工作记忆，但不负责持久化和治理。两者可以配合，职责不同。
它会不会把错误信息一直记住？
有可能。记忆系统需要来源、时间、置信度和修正机制。企业还应该规定哪些内容不能进入记忆，例如未经确认的推测、敏感个人信息、以业务系统为准的交易状态。发现错误后，要能定位、修正和删除，不能只追加一条新记忆。
有了知识库还需要运行时记忆吗？
要看任务是否跨会话、是否会积累用户事实和任务状态。知识库适合稳定的企业知识，运行时记忆适合动态上下文。只做静态知识问答，知识库可能已经够用。如果 Agent 要连续服务同一个用户，或长任务要中断恢复，就需要运行时记忆。
自建还是采购？
先看隔离、权限、审计、保留和成本五项能力，再看团队是否具备长期运维记忆系统的工程能力。自建适合有强基础设施团队、数据边界特殊的企业。采购适合希望尽快上线、把治理能力交给平台的团队。无论哪种方式，记忆的写入规则和删除机制都要掌握在企业自己手里。
