你的 AI Agent 没有记忆问题,而是选择问题

@eng_khairallah1
الإنجليزية17 يونيو 2026
427K
257
28
67
480

ليرة تركية؛ د

AI Agent 在处理长任务时表现不佳,是因为过大的上下文窗口会导致错误累积和噪声干扰。本文指出,真正的瓶颈在于“选择”——即决定模型应关注哪些信息,而非仅仅是存储容量的大小。

我们给了智能体百万 token 的上下文窗口,但它们仍然无法正常工作。

收藏这个吧 :)

你给一个有能力的模型一些工具和一个长期任务。在前十五步中,它表现得非常出色。专注且精确。能够很好地回答用户的问题并进行深入追问。

然而,随着对话开始扩展,智能体开始偏离轨道。它开始与十步前做出的决策自相矛盾。它开始用编造的信息污染上下文窗口。它知道用户偏好的存在,但无法可靠地获取它们。而与此同时,你还在努力弄清楚问题出在哪里。

于是你开始寻求更多。一个更大的上下文窗口的模型,以便让任务维持更久。尝试优化 RAG 流水线。在网上寻找智能体记忆解决方案。

但没有任何东西能如你所愿地工作。

理解这背后的原因,直接指向了整个智能体堆栈中最有价值、但最不被理解的层面。

失败是一个循环

智能体性能下降的原因并非能力不足。而是一个反馈循环,它有四个环节。一旦你看清了这四个环节,那些常见的修复方法就不再像是解决方案了。

Khairallah AL-Awady - inline image

环节一:模型无法平等地使用其整个上下文,并且随着上下文的填充,情况会变得更糟。

这是大多数人从未真正内化的一点。模型使用信息的能力在其上下文窗口内并非均匀分布。模型能够可靠地使用位于开头和末尾的信息,而系统性地忽略中间部分,即使它们是为长输入专门构建的。塞入更多内容,可靠性会进一步下降。这一点甚至在像重复一个单词列表这样简单的任务中也会显现出来。添加一个干扰项,性能就会明显下降。如果添加多个复合干扰项,情况更糟。

因此,有效上下文,即模型能够可靠推理的部分,远小于包装盒上的数字。而且随着你塞入更多内容,它还会缩小。

现在想一想智能体在做什么。它在不断累积。每个工具结果、每步历史记录、每条自我备注都会被追加到上下文中。这意味着智能体在持续降低每一步的质量。不断增长的上下文正在制造每一步的错误。

环节二:这些单步错误不会相加,而是相乘。

如果智能体只执行几步,那么一点单步错误问题不大。但它们会执行数十步。而且失败会复合,而不是累积。一个在五步任务中 95% 可靠的智能体,在二十步任务中不会保持 95% 的可靠性。运行足够多的步骤,你会不断接近抛硬币的概率。

更糟糕的是,错误是自我强化的。一次稍微偏离轨道的工具调用会让下一次更有可能偏离。叠加在环节一之上——随着窗口填满,基础错误率本身也在攀升——你就会得到长周期智能体的标志性失败模式。它们不会优雅地退化。它们会保持稳定,然后突然断崖式下跌。

环节三:任务很长,模型是无状态的,所以你必须把状态放在模型之外。

语言模型在调用之间不保留任何信息。每次调用都从空白开始。模型知道的唯一信息就是你反馈给它的内容。因此,对于任何长任务,你必须将状态外部化。便签本、进度文件、检查点、向量存储、专用的记忆层来提取事实并在跨会话中重新提供。

这是正确且必要的。而且它看起来像一个干净的修复方案。智能体不会忘记任何重要信息,因为所有重要信息都保存在持久存储中。

环节四:存储的记忆是静止的,而将其拉回会加剧它本应解决的问题。

这就是循环闭合的地方。模型无法对数据库进行推理。它只能推理当前上下文窗口中的内容。因此,记忆只有在被拉回的那一刻才有帮助。而且每次检索都会增加 token。智能体为跟踪进度而写的每一条摘要,都是它稍后必须重新读取的 token。每一个压缩历史以腾出空间的步骤都是有损的,它丢弃的细节往往是那些微妙而重要的、其重要性后来才显现出来的信息。

因此,你为克服上下文限制而构建的记忆系统最终却在助长这个问题。更多的记忆意味着更多的检索,这意味着窗口中有更多的噪音,这意味着更多的单步错误,这些错误会复合,而这正是你一开始去寻找记忆的原因。

这个循环是真实存在的。而且它不在乎你的上下文窗口有多大。

容量从来就不是关键轴

一旦你看到了这个循环,标准修复方法的徒劳性就变得显而易见了。

Khairallah AL-Awady - inline image

更大的上下文窗口无法打破它。 它只是提高了在你面临断崖之前可以积累的腐朽内容的上限。与此同时,每一项关于有效上下文的研究都在不断显示相同的结果:可可靠使用部分的增长速度远慢于宣传的数字。你购买的是你实际上无法使用的容量。

更多的记忆无法打破它。 它增加了试图重新进入一个已经无法容纳所有内容的窗口的材料数量。

下一个架构也无法打破它。 那些挑战注意力机制的候选者,比如状态空间模型 Mamba 及其混合体,通过将过去压缩成固定大小的状态而不是保留每个可寻址的 token 来获胜。这换来了线性时间推理和一个不会随序列增长的内存占用。但它无法换来召回。一个固定大小的状态无法容纳所有内容,因此它本质上就会遗忘。在大规模情况下,纯状态空间模型在外部记忆旨在提供的事情上落后于 Transformer:从序列中任意较早的点拉回特定事实。这就是为什么严肃的后注意力努力都是混合体,保留少数注意力层来执行召回任务——状态模型无法做到这一点。当你改变架构时,这堵墙并不会移动。你只是从另一面碰到了它。

因此,教训不是“选一个更大的数字”。而是容量从来就不是那个约束条件。

真正的约束条件是:每一步决定哪些 token 占据窗口的决策质量。

这才是全部的游戏。不是最大的可用上下文,而是最小的足够上下文。相关性优于召回。有意的遗忘是一个第一类操作,而不是截断的偶然结果。研究直接支持这一点:按顺序检索几千个精心挑选的 token,优于将完整的 128K 窗口一股脑地倒入模型。优势在于选择什么进入,而不是能进入多少。

而这正是大多数团队陷入的陷阱,因为他们用来进行选择的工具形状不对。

相似性不等于相关性

决定拉回哪些上下文的默认方法是相似性搜索。嵌入所有内容,当智能体需要上下文时,检索与当前查询最接近的向量。

但相似性回答了一个错误的问题。它返回的是接近的内容,而不是相关的内容。这两者是非常不同的东西。

智能体实际需要回答的问题从来不是“什么与这个相似”。而是“给定这个任务和当前状态,什么与重要的东西相关联”。这是一个关系性问题。它关乎依赖关系、出处、什么替代了什么、以及哪个决策导致了哪个结果。一个调优为检索相似向量的存储区,递给模型的是一堆近似匹配。而近似匹配恰恰就是环节一中的干扰项——那些导致单步错误并复合为断崖的因素。

这就是为什么修复方案不能是在嵌入存储前加一个薄缓存。智能不在于查找,而在于结构。

没有人定价的层面

在智能体堆栈中,最重要的层面不是模型,也不是存储。而是介于两者之间的那个层面。那个决定模型关注什么的层面。

Khairallah AL-Awady - inline image

而要真正做好这项工作,它必须具备三个特质。

它必须保持中立。 内部机制一直在变化。从 Transformer 到状态空间到混合体。从一个前沿模型到下一个,每隔几个月就会出现一个新的性价比领导者。一个焊死在单个模型上的上下文策略,就是在押注一个移动的目标。你的组织实际积累价值的是它的上下文——那是你的智能体所知道和所做的、来之不易的结构化记录。将其锁定在某一个供应商的记忆功能上,就等于把你最持久的资产变成了一个不属于你的路线图的人质。一个存在于任何单一模型之外的选择层,可以让同一个有组织的上下文服务于你运行的所有模型,以及你尚未采用的下一批模型。

它必须是横向的。 一个框架的检查点只知道一次运行。一个模型的内置记忆只知道一个模型的对话。一个向量索引只知道一个语料库。当你运行真实工作负载时,这些都无法提供真正重要的全景:多个智能体、多个会话、多个模型,都需要一个统一、可查询的上下文视图。这种记录系统的角色,不是某个应用、框架或实验室能够承载的,因为每个只看到自己的一小部分。它是一个独立的层面,横向跨越所有这些部分。

它必须是有结构的。 这是它区别于“只是一个更好的数据库”的地方。选择是一个相关性问题,而相关性是关系性的。上下文的结构——关系、依赖关系、出处和替代关系——是将检索转化为选择的关键。这是一个与存储根本不同的原语,而正是循环所要求的。

“实验室不会直接推出这个吗?”

一个明显的反对意见是,模型实验室会吸收这个功能。它们不断推出记忆和上下文功能,并且拥有对模型自身注意力的特权访问。

它们会,而且这个反对意见只说对了一半。对于一个包裹单个应用的单个模型来说,让实验室来处理通常就足够了。这没问题。

但实验室的激励是让自己的模型更具粘性。这与可移植性恰恰相反。与单个模型内部深度绑定的策展无法服务于多模型、全组织的情况。一个真正的上下文基础层不是要与这些功能正面竞争。它存在的意义是为了服务实验室在结构上不愿意提供的情况:当你跨多个智能体和团队运行多个模型,并且你拒绝让决定你的智能体思考什么的层面被你今天碰巧使用的模型的供应商所拥有。

而趋势只会加剧这一点。模型越强大,它们被使用得就越多。它们被使用得越多,一个组织运行的智能体就越多。运行的智能体越多,一个中立、横向、有结构的选择层就越有价值。

谁在构建这个?

这就是 HydraDB 的用武之地。中立、横向且有结构。它保存了相似性搜索所扁平化的关系、依赖关系、出处和替代关系。它是按时间版本化的,并且具有偏好感知能力,因此不仅知道什么是真的,还知道什么替代了它。它能够洞察一个给定智能体随时间学到了什么。这种结构将检索转化为选择。

底层上,HydraDB 运行在分层存储上:一个用于活跃上下文的热内存缓存,NVMe 用于温数据,对象存储用于冷数据。上下文根据新鲜度和重要性进行升级和降级,因此模型所推理的工作集有目的地保持较小。它位于模型和模型可能知道的所有内容之间。

每个智能体都必须回答的问题

抛开架构争论、记忆产品、上下文窗口军备竞赛。在所有这一切之下,每个长期运行的智能体在每一步都要回答同一个问题。

在它知道的所有内容中,它现在应该思考什么?

更大的窗口不能回答这个问题。它只是给智能体更多的东西去忽略。这个循环是真实的,是永久的,没有多少容量能关闭它。

整个行业仍在试图用容量来解困。但这行不通。那些内化这一点——它始终是一个选择问题——的团队将交付能工作的智能体,而其他人则交付 几乎能工作 的智能体。

这从来不是模型的纯粹限制。任何在有限预算下运行的东西都必须选择它关注什么。选择不是针对今天限制的变通方案。它是在限制下进行推理一直以来的要求。

如果你觉得这个有用,请关注我 @eng_khairallah1 以获取更多类似的 AI 内容。我每周都会发布解析、课程和工具。

希望这对你有用,Khairallah ❤️

بنقرة واحدة حفظ

استخدم YouMind للقراءة العميقة للمقالات سريعة الانتشار بتقنية الذكاء الاصطناعي

احفظ المصدر، واطرح أسئلة مركزة، ولخص الحجة، وحوّل المقالة واسعة الانتشار إلى ملاحظات قابلة لإعادة الاستخدام في مساحة عمل واحدة تعمل بالذكاء الاصطناعي.

اكتشف YouMind
للمبدعين

حول Markdown إلى مقالة 𝕏 نظيفة

عندما تنشر كتاباتك الطويلة، فإن الصور والجداول وكتل التعليمات البرمجية تجعل تنسيق 𝕏 مؤلمًا. YouMind يحول مسودة Markdown كاملة إلى مقالة نظيفة وجاهزة للنشر 𝕏.

حاول Markdown إلى 𝕏

المزيد من الأنماط لفك التشفير

المقالات الفيروسية الأخيرة

استكشاف المزيد من المقالات الفيروسية