16 篇博文 含有标签「memory」

针对你的智能体记忆层的第一次合规升级，几乎从不以监管机构信函的形式出现。它往往是以你企业级销售工程师发来的一张 Jira 工单的形式出现的，上面写着：“客户的隐私团队正在阻碍合同签署——他们想知道在你的系统中‘忘记我的用户’到底是什么意思，并且他们要求在周五前给出书面答复。”这张工单通常在记忆层发布 6 到 12 个月后送达，而构建该功能的工程团队在读完问题的那一刻就会发现，他们不小心构建了一个没有任何记录管理系统（records-management system）应有原语的记录管理系统。

这是智能体产品中长期记忆的结构性问题。构建它的团队通常会针对记忆功能的卖点进行优化——检索质量、延迟、存储成本，以及让助手感觉很懂用户的个性化体验。在设计评审中，没有人会去估算同时被构建出来的那个并行系统的代价：一个按用户、按租户、跨区域的数据存储，它带有保留义务、删除语义、审计导出要求，而且从第一个用户数据进入其中的那一刻起，监管机构的倒计时就开始了。记忆并不是一个功能。它是每个隐私制度、每份企业采购调查问卷以及每个被遗忘权（right-to-erasure）请求最终都会找上的运营界面（operational surface）。

那些发布了带有显著性加权内存驱逐（salience-weighted memory eviction）功能智能体的团队，在不知不觉中，已经为每一次模型升级预订了一个内存迁移项目。驱逐策略表面上看起来是一个质量杠杆——选择最聪明的评分方法，获得最好的召回——但它实际上是一个隐秘的版本契约。当评分模型发生变化时，智能体实际上的“过去”也会随之改变。现有的围绕提示词和评估（evals）构建的工具链都无法捕捉到这一点，因为发生漂移的产物既不是提示词也不是评估，而是几个月前由一个已经不存在的模型做出的一系列关于“该忘记什么”的决定。

LRU（最近最少使用）和 LFU（最不经常使用）没有这个问题。它们是确定性的、与模型无关的，并且可以干净利落地在升级中幸存。但它们也会丢弃掉那些审慎的裁判模型会保留的信息。这是大多数团队在第一天——当 Demo 的召回率指标是衡量一切的唯一标准时——会做出的妥协。然而，这种妥协在智能体余下的生命周期里，每季度都会反噬你一次。

周一，一位客户在 Slack 上询问你的助手如何启用某项功能，得到了清晰的回答，然后继续工作。到了周五，他们发邮件要求确认之前的决定，而运行在不同会话存储上的助手——完全不知道周一的聊天发生过——给出了截然相反的建议。客户不会针对两个产品提交两张工单，他们会针对你的 AI 提交一张工单，而且他们是对的。对他们来说，只有一个助手。你写了三个助手并将它们粘在三个特定渠道的会话存储上，这本该是你不该泄露的实现细节。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E8%B7%A8%E6%B8%A0%E9%81%93%E8%AE%B0%E5%BF%86%EF%BC%9A%E5%BD%93%E4%BD%A0%E7%9A%84%E6%99%BA%E8%83%BD%E4%BD%93%E5%BF%98%E8%AE%B0%E9%82%AE%E4%BB%B6%E5%BE%80%E6%9D%A5%E6%97%B6"]

这就是跨渠道记忆问题，它处于两个被团队低估的因素的交汇点：用户对连续性的假设有多强烈，以及渠道团队为了快速交付而编写各自会话存储的行为有多普遍。最近的行业数据清晰地揭示了这一差距——只有 13% 的组织成功实现了全渠道的完整对话上下文衔接。碎片化多渠道支持的 CSAT（客户满意度）仅为 28%，而真正的全渠道支持则为 67%。这 39 个百分点的差距并不是模型质量的差距，而是记忆架构的差距。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

一个长时间运行的 Agent 每 12 轮就会达到其压缩阈值。每一次压缩的成本都相当于一次规模等同于当前运行窗口的 LLM 调用——首先是 8K tokens，然后是 14K，接着是 22K——因为被总结的内容跨度随着每次触发而增长。到了第 60 轮，用户在观察 Agent 自我总结上花费的 token，已经超过了在实际推理上花费的 token。成本仪表盘将“用户推理成本”显示为一个单一数字，完全没有意识到其中一半是为用户永远不会再看的上下文压缩而付费的。

这就是“总结税”：一类随着对话长度增加而增长的开销，在用户回合之间悄然触发，并作为一个单一项目出现，将用户付费的工作与系统为自我管理而进行的内务处理混为一谈。这是现代 Agent 架构中最接近“垃圾回收停顿时间（garbage-collection pause time）”的东西——而大多数团队在生产环境中运行时都关闭了 -verbose:gc。

你的智能体正确完成了一项多步研究任务的 80%，然后自信地给出了一个完全错误的结论。你翻查日志，在第三步找到了罪魁祸首：一次工具调用返回了过时数据，智能体将其作为事实整合，之后的每个推理步骤都建立在这个被毒化的前提之上。到会话结束时，智能体对一切都是正确的——除了最关键的那件事。

这就是智能体记忆污染——它是生产智能体系统中最隐蔽的可靠性故障之一。与崩溃或超时不同，它产生的是自信的错误答案。可观测工具记录的是一次成功运行，用户带着错误信息离开。

你的智能体已经与同一个用户对话了400次。六个月前她说她更喜欢Python。三个月前她的团队迁移到了Go。上周她提到了一个新的TypeScript项目。这三个事实现在都存储在你的向量数据库中——语义相似、时间顺序混乱、权重相同。下次她请求代码帮助时，你的智能体会同时检索到这三条信息，将这团矛盾的内容递给模型，然后自信地为TypeScript场景生成带有Go风格的Python代码。

这就是幽灵上下文：那些永不消亡的过时信念，与其替代版本一同被检索，悄然腐蚀智能体的推理。

这个问题之所以被低估，是因为它不会产生可见错误。智能体不会崩溃，不会拒绝响应，而是生成流畅自信的输出——只是微妙地、代价高昂地出错了。

你长期运行的智能体（agent）所做的最危险的事情，也是它做得最自信的事情：根据记忆回答。客户的地址在上周二更改了。智能体认为“开启”的工单在昨天被人工关闭了。智能体拥有整洁解释笔记的产品功能，其实际交付的形式与智能体三周前阅读的规范不同。在教科书定义上，这些都不属于幻觉——模型准确地召回了它存储的内容。只是在智能体看向别处时，世界已经发生了变化。

大多数团队将记忆视为一个写入问题：智能体应该记住什么、我们如何总结、嵌入（embedding）策略是什么、如何防止存储爆炸。这种思维方式产生的架构会随着错误程度的增加而变得更加自信。更难的问题——那个决定你的智能体在第三周后是否仍然有用的问题——是对账（reconciliation）：这是一个明确的、持续的闭环，用于比较智能体认为真实的情况与底层系统当前显示的真实情况。

针对 Agent 类产品，生产环境下最常见的投诉通常是某种形式的“它忘记了我们刚才说的话”。这种投诉往往出现在第 8 轮、第 15 轮或第 30 轮——绝不会在第 2 轮出现。团队的第一反应往往如出一辙：扩大上下文窗口。但这其实是错误的直觉，因为 Bug 不在模型本身，而在于团队将对话历史视为了终端的滚动回放（scrollback）——追加一行、渲染尾部、满了就截断。实际上，他们不知不觉中构建的是一个读多写少的数据库，具有仅追加写入、热工作集、隐藏在截断规则中的淘汰策略，以及取决于所提问题类型的查询模式。一旦你接受了这一点，整个问题的本质就改变了。

滚动回放模式之所以如此诱人，是因为聊天界面看起来就像一份对话记录。消息向下流动，用户自上而下阅读，而喂给模型的自然方式就是将最新的 N 轮对话拼接到提示词中。这种数据结构感觉是“免费”的：没有 Schema，没有索引，没有查询——只需追加、渲染、重复。在最初的几轮对话中，任何架构都表现良好。模型拥有完整的上下文，费用低廉，演示效果极佳。

一名用户在上午 9 点开始在她的电脑上与你的智能体谈判合同。她收到一条 Slack 消息，在午休时间切换到手机问了一个澄清问题，并在下午 4 点重新打开电脑标签页来修改草案。对她来说，这是一项任务 —— 处理一份合同的三个小时工作。对你的系统来说，这是两个设备上的三个会话，每个都有自己的 conversation-id，每个都有自己的记忆窗口，每个都呈现全新的问候并要求她重新粘贴已经讨论过两次的草案。

Bug 不在模型中。Bug 在于你的平台将“会话 (session)” —— 一个关于单一连接的传输层产物 —— 编码为上下文单位，而你的用户将“任务 (task)” —— 即合同 —— 编码为上下文单位。市面上的每个框架都悄悄地混淆了这两者，而它们之间的差距正是智能体 UX 损耗了一半的地方。

第一次痛苦的智能体记忆（agent-memory）迁移总是教会我们同一个教训：存在两个模式（schema），而你只迁移了其中一个。存储层没问题 —— 每一行都已重写，每个键（key）都是新的形态，回填（backfill）作业也记录了成功。但智能体还是坏了。它继续向 user.preferences.theme 写入，却检索不到任何内容，然后从上下文中煞有介事地合成一个默认值，就好像这个键从未存在过一样。迁移操作手册显示一切正常。用户却报告记忆过时。

这种不对称是结构性的。一个依赖于重命名列的传统服务会收到硬错误，然后你进行修复。而一个依赖于重命名记忆键的智能体则会遇到软缺失，并围绕它进行胡编乱造。模式存在于两个地方 —— 你的存储和模型的上下文 —— 而你只能通过 SQL 脚本迁移其中的一个。

Protobuf 在二十年前通过规范化“仅限增加”的准则解决了这类问题的一个变体：字段是永恒的，数字是永恒的，网络类型永远不变，删除被弃用（deprecation）所取代。这一准则是智能体记忆的一个良好起点，但有一个额外的约束使其变得更加困难。Protobuf 接收者在设计上会忽略未知字段。智能体则不会。

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词，换一个更强的模型，添加更多上下文。

真正的原因往往更平凡，也更危险：并发写入导致的共享状态损坏。两个智能体读取同一块内存，都计算出更新，其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出，没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的，在测试环境中难以复现，仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现，36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。