在 Databricks 上推出 Agent Memory：让过去的工作可复用
Databricks 已以 beta 形式推出 agent memory，挑战了让企业 agent 在每次新对话中重新发现此前所学内容的做法。其 10 月 20 日发布的《Introducing Agent Memory on Databricks》将持久化上下文嵌入该公司的 agent 开发平台 Agent Bricks。实际问题在于：保留经验是否能在不断变化的业务任务中带来可靠的改进。
核心比较在于托管式 memory，与反复重新发现及自建 memory 基础设施之间的取舍。企业开发者必须判断，继续维护自有系统是否仍值得承担相应的工程成本。Amazon 的 AgentCore 已提供托管式 memory，因此 Databricks 加入了一场既有竞争：agent 积累的知识应存放在哪里。
对采购方而言，这项公告引出了一个比助手是否记住偏好回复格式更具体的问题：平台能否保留有用的修正、恰当地应用这些修正，并说明记忆中的信息何时影响了回答？这种组合决定了 memory 会成为运营优势，还是新的错误来源。
在 Databricks 上推出 Agent Memory，让上下文持久化
Databricks 将跨会话 memory 封装为托管服务，把部分实施负担从应用团队手中转移出去。
公司发布的 agent memory 公告介绍了托管式对话历史、持久 memory，以及用于整合 agent 应保留内容的后台流程。该服务运行在 Lakebase 上，即 Databricks 托管的 Postgres 数据库。Databricks 表示，开发者可以检查、导出和删除已记住的条目。
这改变了企业应用的起点。过去，团队若自行构建持久化能力，必须将存储与筛选、检索有用信息的规则连接起来。托管选项让团队可以在投入自建方案前，先评估现成实现。
这种区别很重要，因为保留对话记录并不会自动形成有用的 memory。对话记录保存了发生过的一切，包括错误、被放弃的方法和临时假设。有用的 memory 则要求判断哪些内容值得影响未来工作。
以一个示例性分析助手为例，它收到一条关于收入定义的修正。这项修正可能只适用于某个部门、某个报告周期或特定仪表板。若只记住这句话而不保留其适用范围，就可能把昨天的答案错误地用于另一个问题。
这正是该公告超越个性化层面而具有意义的地方。关于语气的偏好会影响呈现方式；记住的业务定义则影响回答的实质内容，以及后续可能采取的行动。
因此，工程决策关乎责任，不只是存储。如果开发者采用托管式 memory，仍须确定哪些保留的信息应当属于其应用。他们也需要有办法质疑某个看似权威、却已不再适用的条目。
在 Databricks 上推出 Agent Memory，为这些团队提供了一种基础设施选择。但这并不能证明每段对话都应生成持久知识。选择性保留仍是产品决策，尤其当用户将长期偏好与临时请求混在一起时。
应用可以合理地记住用户偏好的报告格式，同时拒绝保留暂定预测。这两类信息都通过对话到达，但承载着不同预期。若同等对待，会让持久化更易实现，却更难获得信任。
眼下的变化具体但有限。Databricks 现在为开发者提供了一个托管位置，用于跨对话保留经验。这些经验是否值得复用，取决于应用的规则以及每条 memory 背后的证据。
这一边界塑造了商业层面的利害关系。团队可以将基础设施工作转移给平台，却无法转移自己对于何为有效业务知识的判断。
企业团队面临不同的自建或采购决策
承受压力的是那些在维护 memory 基础设施的同时，还要维护依赖它的 agent 的团队。
对于内部平台团队而言，自定义 memory 带来持续承诺。必须有人调查缺失条目、不当检索、相互冲突的修正以及更新失败。这些责任不会因最初的演示成功而消失。
托管服务将比较标准从功能可用性转向运营价值。问题变成：自定义实现是否提供了足够的控制力或专业化能力，以证明其维护成本合理。这比仅仅证明 agent 能保存信息的标准更高。
保留自定义方案有合理理由。组织可能需要专门的保留规则、特殊的部署边界，或在既有系统间共享的 memory 格式。这些要求值得评估，而不应假定托管基础设施总能胜出。
反过来，需求常规的团队，若仅因自己已拥有应用便重建熟悉的底层设施，获益很小。其稀缺的工程资源通过更好的评估或更清晰的用户控制，或许能创造更大价值。
Databricks 的入场也为企业采购方增加了一个比较对象。Amazon 的 AgentCore memory 类型文档描述了原始交互存储，以及通过后台处理提取的长期记录；它还描述了跨后续会话的整合与检索。
这种重叠确立了竞争基线。持久 memory 已是另一家大型提供商提供的平台能力。Databricks 必须凭借实现质量、运营适配度，以及与客户实际运行工作负载的集成来竞争。
现有文档并不能确定这些服务之间的性能优胜者。架构说明阐释的是预期行为，不能替代等效测试。公平的比较应保持任务、模型、历史记录和评分规则一致。
对采购方而言，这意味着供应商选择应遵循应用的失败模式。会忘记偏好的支持助手，与反复选择错误来源的分析 agent，面临不同要求。必须针对希望通过采购解决的具体问题来衡量 memory 质量。
采购讨论还需要区分便利性与依赖性。整合基础设施可以减少组织需要运营的系统数量；但当积累的上下文成为应用行为的一部分时，也会使迁移的影响更为重大。
可导出的条目有所帮助，但单靠导出并不能保证在其他地方获得等效行为。另一个系统可能选择不同的 memories，或对同一保留文本作出不同解释。可移植性既值得做数据传输测试，也值得做行为测试。
因此，购买托管 memory 的最有力理由是务实的：服务应在保留应用所需控制能力的同时，减少维护工作。采购方应期待看到这两方面的证据，才应将基础设施整合视为改进。
压力同时落在自定义实现和托管供应商身上。双方都必须说明其方法如何改善已完成的工作，而不只是增加 agent 能保留的信息量。
这一机制取决于筛选值得复用的内容
核心设计问题是决定哪些经验应影响下一项任务。
Databricks 的 memory pipeline 文档描述了后台处理机制：提取持久信息、合并重叠条目，并重组已存储的 memories。开发者可以提供有关应保留内容的指令。文档中的设计倾向于可复用的事实和流程，而非应从实时来源获取的动态数值。
这种区别会直接影响企业分析。记住某项指标的计算方式，可以帮助 agent 重复有效的工作流；记住该指标此前的数值，则可能在底层业务发生变化时生成过时回答。
一个示例性的销售助手清楚说明了这种差异。它可以保留某团队在特定报告中排除已取消合同的规则。但在编制下一份报告时，它仍应获取当前合同数据。
保留该规则减少了重新发现的需求，却不能取代新鲜证据。然而，如果组织改变该规则，memory 就需要得到恰当修正。因此，成功复用既依赖保留，也依赖修订。
后台处理带来了另一个决策边界。pipeline 文档允许手动运行或大约每 24 小时定时运行。因此，定时整合应被理解为延迟处理，而非保证每一项新修正都会立即重塑所有未来交互。
对应用设计者来说，其含义很直接。用户下一次请求所需的修正，应与可以等待后续整合的知识采用不同处理方式。用户不应必须了解处理时间表，才能知道修正是否已生效。
文档还指出，维护流程可以修改 agent 直接保存的条目。这意味着已存储的 memory 是对话演变性解释的一部分，并不一定是原始陈述的永久副本。
这为产品团队带来了问责问题。如果某条记忆中的指令在整合期间发生变化，应用应有足够证据解释由此产生的行为。否则，用户会看到助手改变其理解，却得不到可理解的理由。
一个有用的类比是分析师维护工作笔记。只有在笔记保留相关条件、并且始终可与已验证源材料区分开来时，它才有帮助。agent 保留的摘要也应接受类似审视。
同样的区别也出现在 个人知识管理中：收集信息和让信息变得有用，是相关但独立的任务。对于企业 agent，有用性还取决于保留的信息是否仍适合当前请求。
这一机制使 memory 成为应用行为中的活跃部分。它会在下一项任务开始前筛选、压缩和更新经验。评估该服务的团队应审视这些转换，而不应把成功存储视为终点。
该基准支持一项有限的性能主张
Databricks 报告称其企业基准有所改善，但这些结果并不能证明其具有普遍收益。
该公司的 MemCurrent research 介绍了此次发布背后的架构。在其内部基准测试中，Databricks 报告称，使用 MemCurrent 的通过率为 68.4%，而未使用记忆时为 22.3%。该公司还称，Token 使用量减少了 31%，执行速度提升了 26%。
该内部基准包含 114 个案例，涉及 29 名用户和 2,233 段历史会话。Databricks 表示，其评估由企业数据对话构建而成，并对案例进行了审查。这些是公司自行报告的结果，并非对每项部署的独立验证。
该研究还报告了一项示例性的工作流改进：在此前一项任务需要 11 次工具调用、耗时近六分钟后，相关的后续任务仅需两次工具调用和 41 秒。该示例支持了避免重复探索这一拟议机制，但并不能证明客户应预期的平均改善幅度。
示例与预期结果之间的区别很重要。具备可复用上下文的重复任务，为记忆功能创造了有利机会。需求毫不相关的新任务，可能几乎无法从历史信息中获益。
同样，较低的 Token 数量衡量的是一种特定资源，而非全部运营负担。团队仍需将生成、维护、检查和评估记忆所需的工作纳入考量。部署决策应评估完整的应用体系。
这些发现最适合作为检验一项具体假设的理由。如果代理反复重新发现稳定的业务知识，保留的经验应能减少这种重复。当过往对话几乎不提供相关信息时，这一假设便不那么成立。
评估还应包含记忆本应保持未使用状态的任务。否则，系统可能通过在每个回答中插入历史上下文而显得成功。选择性很重要，因为无关的回忆本身也会造成干扰。
独立研究提供了更广泛的评估框架。发表于 ICLR 2025 的 LongMemEval benchmark 测试了信息提取、跨会话推理、时间推理、知识更新和弃答能力。弃答是指当可用证据不足以支持回答时，选择不作答。
这些类别揭示了为什么简单的回忆并不是完整的衡量标准。助手可以准确检索到旧陈述，却仍在错误的时机应用它；当其记忆中没有相关证据时，它也可能自信地作答而失败。
因此，对企业买家而言，有用的问题比“记忆是否提升基准分数”更具体：它是否能改善员工实际执行的任务，包括定义已变更或指令相互冲突的情况？
在 Databricks 上推出 Agent Memory，为借助托管基础设施进行这一比较创造了机会。已发布的结果值得关注，但应用自身的评估必须确定所报告的机制能否迁移到实际场景。
这是对证据的一种站得住脚的解读。该公司提出了可量化的主张，并说明了评估方式。客户仍需获得反映自身历史记录、权限和业务决策的结果。
记忆所有权不止需要一个用户标识符
持久化上下文需要明确的安全与删除规则，因为被记住的信息可能比产生它的对话存续得更久。
Databricks 的 memory and sessions documentation 指出，删除会话并不会删除记忆。文档还区分了用户分区与访问控制。行为主体标识符决定一项操作使用谁的条目，但拥有存储访问权限的主体可以读取属于其他行为主体的条目。
该文档建议在受信任的应用代码中，从经过验证的身份信息派生这一标识符。对于严格的租户隔离，它建议使用独立的存储。文档还警告称，测试版的接口和行为可能发生变化。
对于评估此次发布的买家而言，这些都是影响重大的实现细节。按用户标记信息的字段，并不会自动形成安全边界。应用必须正确连接身份、权限与存储结构。
一个示例性的客户支持部署说明了这一担忧。在客户自己的账户内，被记住的偏好可能无害；但出现在另一位客户的对话中则可能并不合适。正确检索要求应用在模型请求任何记忆之前，先确立正确的身份。
删除则带来另一类问题。用户完全可能认为，移除一段对话就会移除助手从中学到的内容。如果派生信息仍然保留，产品需要清楚说明这种区别。
这是一项应用设计层面的影响，而非证明某个特定部署错误处理了删除操作的证据。文档所明确的分离，使其成为团队必须回答的问题。完整的删除政策应同时涵盖原始交互及从中保留的信息。
纠错同样值得关注。替换一条错误记忆应影响未来行为，但团队还需要了解这种纠正如何与剩余历史互动。否则，相同的底层证据可能再次支持错误的解读。
记忆还可能保留本不应获得长期权威性的指令。设想一份包含误导性运营指示的文档：如果代理将该指示概括为已被接受的惯例，这一错误便可能影响后续任务，而不止于最初的文档审查。
这种情形需要评估来源权威性与保留行为，不应被表述为 Databricks 中已发现的漏洞。相关问题在于，应用能否区分用户认可的偏好与工作过程中遇到的不可信内容。
这里的产品体验与后端同样重要。用户需要以易于理解的方式检查重要记忆、进行纠正并请求删除。如果控制功能仍无法被受影响的人实际使用，技术能力的实际价值便十分有限。
对开发者而言，运营层面的教训很明确：记忆引入了信息抵达回答的另一条路径。因此，调试还需要考虑代理记住了什么、为何检索这些信息，以及应用是否授权其使用。
这些责任不会因采用托管存储而消失。它们会成为判断托管服务是否符合应用信任边界的一部分。
Beta 公告之后需要关注什么
下一轮证据应将托管记忆与可重复的客户成果及更清晰的运营边界联系起来。
第一个信号是针对重复性企业任务的独立评估或客户公开评估。有效的结果应在包含纠正、事实变化和无关请求的情况下，对比同一应用在有无记忆时的表现。这类证据将检验保留的上下文是否能在公司选定案例之外改善工作。
一项令人信服的评估应同时解释失败与成功。如果性能只在高度重复的问题上得到改善，其益处仍比持久的业务理解更有限。如果收益能持续存在于相关但不同的任务中，可复用经验的论据就更有力。
第二个信号是围绕运营约束和用户控制的产品进展。买家应关注有关调度、规模、隔离、检查及删除行为的文档化变更。这些细节决定了哪些应用能够依赖该服务，而无需构建大量配套基础设施。
这些控制能力的进展将强化自建还是采购的论据。如果团队仍需大量定制机制来管理常规记忆行为，其运营优势就不那么有说服力。相关衡量标准是该服务实际消除了多少责任。
第三个信号是竞争对手如何让其自身的记忆主张更易验证。Amazon 现有的产品意味着该类别已具备替代选择。更清晰的比较评估将帮助客户区分行为差异与术语差异。
竞争响应本身并不能证明 Databricks 的优势。它们会表明，托管记忆已成为平台选择的又一个维度。有关应用能否跨服务保留有用行为的证据，也将澄清买家可以期待多大程度的可移植性。
这些信号应被综合看待，因为采购对象是一个持续运行的系统。没有控制能力的性能会带来棘手的运营问题；没有实际任务改善的控制能力，则会让买家维护另一项价值仍不确定的功能。
对知识工作者而言，成果应在日常使用中可见。助手应需要更少的重复纠正，同时在情况变化时保持响应能力。以更高的一致性记住过时假设，反而偏离了重点。
对开发者而言，这一公告带来了一个聚焦的实验。选择一个存在可识别记忆相关失败的重复性工作流，然后在一致条件下比较结果。将实时证据与已记住的指导分开，并检查历史信息本应不进入回答的案例。
在 Databricks 上推出 Agent Memory，为企业团队提供了一项可与现有方法进行评估的具体服务。应从代理反复出错或不必要重复的工作着手。识别哪些纠正值得持久保留，哪些事实必须始终与当前来源绑定。随后检验保留的上下文能否改善后续决策，同时不将过时假设带入未来。还应追问：谁可以检查一条记忆，谁可以修改它，以及删除在整个应用中意味着什么。将已发布的基准测试视为值得在自身任务中验证的假设。在扩大采用之前，你的团队能否证明代理记住了正确的经验，并在这一经验不再适用时停止使用它？
