我们给了 Agent 一百万个 token 的上下文窗口，但它们仍然无法正常工作。
保存这条内容 :)
你给一个能力不错的模型一些工具和一个长任务。前十五步，它表现出色——专注且精准，能很好地回答问题并与用户互动。
然而，随着对话规模扩大，Agent 开始偏离轨道。它开始推翻自己十步前做出的决策，开始用编造的信息污染上下文窗口。它知道用户偏好的存在，却无法可靠地获取这些偏好。而你则在一旁努力找出问题出在哪里。
于是你开始寻求更多：一个更大的上下文窗口的模型，以便更长时间地保持任务；尝试优化 RAG 流水线；四处搜索 Agent 记忆解决方案。
没有一样能如你所愿。
理解背后的原因，会直接指向整个 Agent 技术栈中最有价值、却最被忽视的一层。
失败是一个循环
Agent 性能下降的原因并非能力不足，而是一个反馈循环，有四个环节。一旦你看清了这四个环节，那些常规的修复方法就不像解决方案了。
环节一：模型无法均等地使用上下文窗口，且随着上下文填满，情况更糟。
这是大多数人从未真正内化的部分。模型使用信息的能力在其上下文窗口中并不均匀。模型能可靠地使用开头和结尾的内容，但系统性地忽略中间部分——即使它们是为长输入专门构建的。塞入更多内容，可靠性进一步下降。即使在像复述单词列表这样简单的任务上也是如此。加入一个干扰项，性能就会明显下降。加入多个复合干扰项，情况更严重。
所以，有效上下文——模型能够真正可靠推理的部分——远小于标称的数字。而且随着你塞入更多内容，有效上下文会不断缩小。
现在想想 Agent 做了什么。它不断累积。每个工具结果、每一步历史、每一条备忘录都被追加到上下文窗口中。这意味着 Agent 在稳步降低它每一步的质量。不断增长的上下文正在制造每一步的错误。
环节二：这些每步错误不是相加，而是相乘。
如果 Agent 只执行几步，每步的小错误还好。但它们要执行几十步。失败是复合递增，而不是简单累加。一个在五步任务中可靠性为 95% 的 Agent，在二十步任务中不会保持 95%。运行足够多的步骤，你就会越来越接近抛硬币的概率。
更糟的是，这些错误是自我强化的。一次略微偏离轨迹的工具调用，会让下一次更可能偏离。再加上环节一——基础错误率本身就因窗口填满而不断攀升——你就得到了长周期 Agent 的典型失败模式：它们不会优雅地退化，而是保持稳定然后突然断崖式下跌。
环节三：任务很长，模型是无状态的，所以你需要将状态放在模型之外。
语言模型在两次调用之间不会保留任何东西。每次调用都从空白开始。模型只知道你喂给它的内容。因此，对于任何长任务，你必须将状态外部化。使用草稿本、进度文件、检查点、向量存储、专用的记忆层来提取事实并在会话之间重新提供。
这样做正确且必要。它看起来像一个干净的修复方案。Agent 不会忘记任何重要信息，因为重要信息都保存在持久化存储中。
环节四：存储的记忆是惰性的，而将其拉回上下文窗口恰恰加剧了它本应解决的问题。
这里循环闭合了。模型无法在数据库上进行推理，它只能推理上下文窗口中的内容。因此，记忆只有在被拉回上下文的那一刻才起作用。而每次检索都会增加 token。Agent 为了跟踪进度而写的每个摘要，都是以后必须重新读取的 token。每一个用于压缩历史以腾出空间的步骤都是有损的，丢弃的细节往往是那些后来才显出其重要性的微妙信息。
因此，你为了打破上下文限制而构建的记忆系统，最终反而在喂养这个限制。更多记忆意味着更多检索，进而意味着上下文中更多噪音，更多每步错误，这些错误复合递增，而这正是当初让你寻找记忆解决方案的原因。
这个循环是真实的，而且它不在乎你的上下文窗口有多大。
容量从来不是关键维度
一旦你看清了这个循环，标准修复方法的徒劳就显而易见了。
更大的上下文窗口并不能打破这个循环。 它只是提高了你在断崖之前可以累积的“腐烂”量的上限。与此同时，每一项关于有效上下文的研究都在不断显示同样的事实：可靠可用的比例增长远慢于宣传的数字。你购买的是你实际上无法使用的容量。
更多的记忆也不能打破它。 它增加了竞相重新进入一个已经无法容纳所有内容窗口的材料量。
下一个架构也不能打破它。 那些挑战注意力机制的新架构——比如 Mamba 及其混合体——通过将过去压缩成固定大小的状态（而不是让每个 token 都可寻址）来赢得线性时间推理和随序列增长而不会膨胀的内存足迹。但这无法换来完美的回忆。固定大小的状态无法容纳一切，因此它有意地遗忘。在大规模上，纯状态空间模型在正是外部记忆存在的目的上落后于 Transformer：从序列中任意较早的点拉回一个特定事实。这就是为什么认真的后注意力努力都是混合模型，保留少数注意力层来做回忆——而状态模型做不到。当你改变架构时，这堵墙并不会移动，你只是从另一边碰到了它。
所以教训不是“选一个更大的数字”。而是容量从来不是真正的制约。
真正的制约是决定每个步骤哪些 token 占据窗口的决策质量。
这才是全部的游戏。不是最大的可用上下文，而是最小的足够上下文。相关性高于回忆。有意的遗忘作为第一类操作，而不是截断的偶然结果。研究直接支持这一点：保持顺序地检索几千个精心挑选的 token，比将整个 128K 窗口倾倒给模型更好。优势在于选择什么进入，而不是能装多少。
而这正是大多数团队陷入的陷阱，因为他们用来做选择的工具形状不对。
相似性不等于相关性
决定拉回什么上下文的默认方法是相似性搜索。将一切嵌入，当 Agent 需要上下文时，检索与当前查询最接近的向量。
但相似性回答了错误的问题。它返回的是“接近的”，而不是“相关的”。这两者截然不同。
Agent 真正需要回答的问题从来不是“什么与这个相似”。而是“给定这个任务和当前状态，什么东西与此相关且重要”。这是一个关系性问题。它关乎依赖关系、来源、什么取代了什么、哪个决策导致了哪个结果。一个调优为检索相似向量的存储，交给模型的是一堆近似但不精确的匹配。而近似匹配恰恰是环节一中的干扰项，它们驱动着每步错误，这些错误复合递增，最终导致断崖式下跌。
这就是为什么修复方式不能是一个嵌入存储前面的薄缓存。智能不在查找中，而在结构中。
没有人计算在内的一层
在 Agent 技术栈中，最重要的一层既不是模型，也不是存储。而是中间那一层——决定模型关注什么的那一层。
而要真正做好这项工作，它必须具备三个特质。
它必须是中立的。 内部机制一直在变化：Transformer 到状态空间到混合体。从一代前沿模型到下一代，每几个月就有新的性价比领跑者。一个绑定在单一模型上的上下文策略，是在对一个移动的目标下注。你的组织真正积累价值的是它的上下文——你的 Agent 知道什么以及做了什么——这个来之不易的结构化记录。把它锁定在某一家供应商的记忆功能上，就等于把你最持久的资产当成了别人路线图的人质。一个独立于任何单一模型的选择层，能让同一套结构化上下文服务于你运行的所有模型，以及你尚未采用的下一代模型。
它必须是横向的。 一个框架的检查点只知道一次运行。一个模型的内置记忆只知道该模型的对话。一个向量索引只知道一个语料库。当你运行真实的工作负载时，没有一个能持有真正重要的全局图景：多个 Agent、多个会话、多个模型，都需要一个连贯、可查询的上下文视图。这种“记录系统”的角色，不是一个应用程序、框架或实验室能够胜任的，因为它们每个都只看到自己的一块。它本身就是一个独立的层，横向贯穿所有这些。
它必须是结构化的。 这就是它区别于“仅仅是一个更好的数据库”的地方。选择是一个相关性问题，而相关性是关系性的。上下文之上的结构——关系、依赖、来源、取代关系——将检索转变为选择。这是一个根本不同于存储的原语，正是循环所需要的。
“实验室不会直接推出这个吗？”
一个显而易见的反对意见是，模型实验室会吸收这个功能。他们不断推出记忆和上下文特性，并且他们对模型自身的注意力机制有特权访问。
他们会的，但这个反对意见只对了一半。对于包装单个应用的单一模型来说，让实验室处理可能就足够了。这没问题。
但是，实验室的动机是让自家模型更具粘性。这与可移植性相反。与单一模型内部机制绑定的策展功能，无法服务于多模型、组织级的场景。一个真正的上下文基础设施并非与这些功能正面竞争。它存在于实验室结构上不倾向于服务的情景中：你跨多个 Agent 和团队运行多个模型，并且你拒绝让决定 Agent 思考内容的这一层，归当前恰好使用的模型供应商所有。
而且趋势只会加剧这一点。模型能力越强，它们被用得越多。用得越多，组织运行的 Agent 就越多。Agent 越多，一个中立、横向、结构化的选择层就越有价值。
谁在构建这个？
这就是 Hydradb 登场的地方。它中立、横向且结构化。它持有的关系、依赖、来源和取代关系，正是相似性搜索所抹平的。它具有时间版本感知和偏好感知，因此不仅知道什么为真，还知道什么取代了它。它解锁了对某个 Agent 随时间学到什么的可见性。这种结构将检索转变为选择。
在底层，HydraDB 运行在分层存储上：热内存缓存用于活跃上下文，NVMe 用于温数据，对象存储用于冷数据。上下文根据新近度和重要性进行提升和降级，因此模型推理的工作集特意保持很小。它位于模型和它可能知道的全部信息之间。
每个 Agent 都必须回答的问题
抛开架构争论、记忆产品、上下文窗口军备竞赛。在所有这些之下，每个长期运行的 Agent 在每一步都回答同一个问题：
在它所知道的一切中，此刻它应该思考什么？
更大的窗口无法回答这个问题。它只是给了 Agent 更多需要忽略的东西。这个循环是真实的、永久的，没有多少容量能打破它。
业界仍在试图用容量买出一条路。它做不到。那些内化了一直以来都是一个选择问题的团队，将交付能正常工作的 Agent；而其他人交付的 Agent 则“几乎”能工作。
这从来不仅仅是模型的局限性。任何在有限预算下运作的系统都必须选择它关注什么。选择不是为了绕过今天的限制而采取的变通方法。它是在限制下进行推理一直所需要的东西。
如果你觉得这篇文章有用，请关注我 @eng_khairallah1 以获取更多类似的人工智能内容。我每周发布解析、课程和工具。
希望这对你有用，Khairallah ❤️
