很多团队在做 AI Agent 时都经历过类似的困惑：Agent 刚启动时表现还不错，跑了 20 步之后开始犯低级错误，到 50 步就像换了个模型——胡编乱造、忘记之前的决策、重复做已经做过的事。

第一反应通常是：模型不够强，换个更大的。换了之后好了一点，但跑到第 80 步又开始恶化。再加更多 token 预算、更长的上下文窗口，问题依然存在。

如果你遇到过这种情况，那你碰上的其实是 AI Agent 领域最核心的工程挑战之一。它有一个名字：Context Rot，上下文腐烂。

用长途自驾来类比，油箱（token）有限，路况（任务）不断变化。你需要的不是更大的油箱，而是一个更好的导航系统——知道什么时候加油、走哪条路、丢掉哪些行李。

一、什么是 Context Rot：当 AI Agent 的"记忆"开始腐烂

先给出一个明确的定义：Context Rot（上下文腐烂）指的是随着上下文窗口中的信息不断累积，LLM 的信息检索和推理能力会持续、渐进地下降。这不是某个模型的 bug，而是当前 Transformer 架构的固有特性。

这个定义有三个关键词值得注意："持续"、"渐进"、"固有"。

2025 年，向量数据库公司 Chroma 发了一项非常重要的研究，系统性地测量了这个现象。他们测试了 18 个前沿模型，给每个模型喂入不同长度的上下文，然后测量它们的信息检索和推理能力变化。

研究结果里有几个发现值得仔细看。

第一，「持续下降」而非突然崩溃。Context Rot 不是到某个点一下子失灵，而是连续、渐进地衰减。这意味着你很难设一个简单的阈值来避免它，它从上下文开始增长的那一刻就在发生。

第二，远在窗口上限之前就开始了。一个 200K 窗口的模型可能在 50K token 时就开始显著衰减。所以"模型支持 200K token"并不意味着你可以放心地用到 200K。

第三，所有模型都有这个问题。Chroma 测试了 18 个前沿模型，没有一个模型免疫。这不是某个模型的 bug，是 Transformer 架构的根本特性。

理解上面的定义和研究结论很重要，因为它直接否定了两个常见的"直觉解法"：

•❌ "换更大的模型" → 不管多大的模型，Context Rot 都存在

•❌ "用更长的上下文窗口" → 窗口长了只是让你能塞更多信息，但衰减照样发生

它解释了为什么换更大的模型或更长的上下文窗口解决不了问题。

Context Rot 是架构性的，不是容量性的。

二、Context Rot 为什么会发生：Transformer 的三个先天缺陷

知道了 Context Rot 的存在，自然要问下一个问题：它为什么会发生？

原因不在任何一个模型的实现细节，而在所有现代大模型共用的底层架构Transformer。Transformer 有三个先天特性，导致它在处理长上下文时不可避免地性能下降。

1.「注意力稀释」：教室里学生太多，老师顾不过来

想象一个老师在教室里上课。如果教室里有 5 个学生，老师可以关注到每个学生的状态——谁走神了、谁没听懂、谁有问题。但如果教室里有 500 个学生呢？老师的注意力必然被极度稀释，大部分学生会被忽略。

大模型的注意力机制（Attention）面临的就是同样的问题。

技术上说，Transformer 在处理上下文时，需要计算每对 token 之间的注意力关系。如果上下文有 N 个 token，就需要处理 N² 对关系。100K token 意味着 100 亿对关系。每个 token 能分到的"关注度"越来越少。

更麻烦的是，这种注意力的分配还不是均匀的。大量研究发现，模型的注意力呈现出强烈的位置偏好：

•上下文开头的内容获得较多注意力（首因效应——就像你记得一本书的开头）

•上下文末尾的内容也获得较多注意力（近因效应——就像你记得刚刚看过的东西）

•中间位置的内容被系统性忽略

这就是著名的 Lost in the Middle（中间丢失）问题。不是模型选择忽略中间内容，而是它的注意力机制在数学上就是这么分配的。

这对 Agent 而言意味着：第 5 步做的一个关键架构决策，到了第 30 步时可能已经落入了注意力的盲区。Agent 不是忘了这个决策，而是看不见了，信息还在上下文中，但模型的注意力没有分配到那个位置。

2.「位置编码漂移」：尺子太短，后半段全靠猜

大模型需要知道每个 token 在上下文中的位置，第 1 个词、第 100 个词、第 10 万个词。这靠位置编码（Position Encoding）来实现，目前主流的方案叫 RoPE（Rotary Position Embedding，旋转位置编码）。

问题在于：模型的位置编码是在训练时学到的，而训练时它只见过有限长度的上下文。比如一个模型训练时最长见过 32K token 的文本，现在你让它处理 200K token 的上下文。

这就像你拿一把只标到 30 厘米的尺子去量 2 米的东西——前 30 厘米量得很准，后面的刻度全是外推出来的，越往后越不靠谱。模型对"什么信息在什么位置"的感知会随着上下文长度的增加而逐渐失准。

虽然现在的模型通过各种技术手段在努力缓解这个问题，但它本质上是一个训练分布外的挑战，模型在推理时遇到的上下文长度越超出训练时见过的，位置编码就越不可靠。

3.「检索噪声累积」：书桌上的纸越堆越多，找东西越来越难

这个最好理解。想象你的书桌一开始很干净，上面只有你正在看的那份文件。你需要的信息一眼就能找到。但随着工作推进，桌上堆的文件越来越多：工具调用返回的数据、中间步骤的计算结果、调试日志、错误信息、历史对话记录。每一份文件可能都有一点用，但大部分和你当前这一步要做的事情关系不大。

这就是 Agent 运行过程中上下文的真实状态：信噪比持续恶化。

Chroma 的研究给出了一个很具体的数据：当检索集包含 20 条结果时，通常只有 3-4 条真正相关，其余都是噪声。模型在推理时被迫花费大量注意力来过滤这些噪声，既浪费了有限的注意力资源，又增加了被噪声误导的概率。

4.三个缺陷的叠加效应

这三个问题不是互相独立的，它们会叠加放大：

注意力被稀释了，同时位置编码还不准，信噪比又在恶化，三重打击叠加在一起，就是 Context Rot 持续、渐进、不可避免地发生的原因。

三、什么条件会加速 Context Rot：四个容易踩中的陷阱

上一节讲了 Context Rot 的底层原因：它是 Transformer 架构的先天缺陷，一定会发生。但在实际系统中，有些条件会让它恶化得更快。Chroma 的研究揭示了四个常见的加速器，理解它们有助于在设计系统时主动规避。

因素	影响	为什么危险
低语义相似度	模型更难定位目标信息	用户问法几乎不可能和文档表述一模一样
语义干扰项	比纯随机噪声更致命	"长得很像"但实际无关的内容，模型容易被骗
结构化内容	⚠️ 反直觉：逻辑清晰的长文档比随机打乱的更难处理	结构化内容让注意力在多个"看起来相关"的区域分散
长检索集	k=20 时信噪比极低	不如只取 Top-3 到 Top-5 精准

1.「低语义相似度」：用户的问法和文档的表述不一样

当查询和目标信息之间的语义相似度低时，模型更难在上下文中定位目标信息。

换个生活化的说法：你在一个大图书馆里找一本书，如果知道书名，一秒钟就能在目录里找到；但如果你只知道"大概讲什么的"，而且你的描述和书的标题用的是完全不同的措辞：你说"怎么让 AI 不瞎编"，书的标题叫"检索增强生成中的忠实性约束"，那找起来就难多了。

在现实场景中，这是极其常见的。用户的提问方式几乎不可能和知识库文档的表述一模一样。语义差距越大，模型在长上下文中找到正确信息的难度就越大，Context Rot 的影响也越明显。

2.「语义干扰项」：长得像的假答案比随机垃圾更危险

当上下文中存在与目标信息语义相似但实际无关的内容时，检索和推理性能的下降幅度显著大于随机噪声。

还是那个图书馆的例子。如果书架上混入了一堆完全不相关的书（比如菜谱），你很容易忽略它们，因为一眼就能看出不对。但如果混入的是一堆标题看起来很像、但内容完全不对的书，那就容易被骗了。你以为找到了，打开一看不是，再找又被另一本骗了。

这就是语义干扰项比纯随机噪声更致命的原因。模型的注意力被这些看起来相关的内容吸引过去，浪费了本就稀缺的注意力资源，甚至可能基于错误的信息做出推理。

3.「结构化内容」：组织得越好的长文档反而越难处理

逻辑结构清晰的长文档，比同等长度的随机打乱内容更容易导致性能下降。

这个发现非常反直觉。直觉上，我们觉得结构清晰的文档应该更容易处理，毕竟有标题、有层次、有逻辑。但实验表明恰恰相反。

原因是：结构化内容中有大量看起来相关的区域，每个小节的标题都可能匹配你的问题，每个段落都像是可能的答案来源。模型的注意力在这些区域之间反复跳转、过度分割，反而比在一堆乱序文本中定位目标更困难。

就像在一个所有门都长得一样的走廊里找一间特定的房间，反而比在一堆明显不同的建筑中找到目标建筑更难。

4.「长检索集」：检索结果越多不等于越好

增加检索返回的结果数量（k 值），会导致信噪比快速下降，模型性能反而恶化。

这个最实用。很多人做 RAG 的时候想：多检索一些结果总不会错吧？万一有用呢？

实验数据告诉你：会错。Chroma 测试表明，当 k=20（检索返回 20 条结果）时，通常只有 3-4 条真正相关，其余全是噪声。这些噪声不仅无用，还会主动损害性能（前面讲过，无关上下文会导致准确率下降 15%-25%）。

所以 Top-K 不是越大越好，k=3~5 往往比 k=20 效果更好。 宁缺毋滥。

四、为什么 Agent 往往是 Context Rot 最先爆雷的地方

前三节把 Context Rot 的机制讲完了：它来自 Transformer 的工作方式，只要上下文变长、变杂，就会慢慢变差。这一节只回答一个更贴近工程的问题：为什么大家体感上，Agent 特别容易先出事？

其实Context Rot，对所有使用大模型的场景都成立，包括最简单的单轮问答。Agent 并没有发明一种"新的腐烂"，它只是更容易把上下文推到又臭又长的状态，于是第二节那三条（注意力稀释、位置漂移、噪声累积）被同时、反复地踩中。

用一个对比来解释。

很多单轮问答像开卷考一题：上下文由产品形态基本框住了，答完这一轮往往就结束，模型不容易背着一整车历史跑很远。

Agent像长跑：为了完成一个目标，它可能自动跑几十、几百步；每一步都会往窗口里加东西：工具返回、报错栈、重试记录、中间结论。更麻烦的是，后一步经常默认前几步已经对了。所以它不是偶尔看错一段话，而是看错一次，就可能被下一步当成事实继续往下砌，错误会像链条一样传下去。

在这种结构下，第二节那三个底层问题会被反复触发：上下文越长，注意力越稀释、位置感知越容易漂、桌上的"废纸"越多（噪声累积）。Agent 不是发明了新的物理定律，而是把"长上下文 + 高噪声 + 强步骤依赖"这三件事叠在一起，所以体感上往往更惨烈。

再说具体一点，和单轮场景相比，Agent 通常还有两类额外压力。

一是信息类型更杂：除了指令和检索结果，往往还要塞工具 schema、工具输出、日志、子任务状态……类型一杂，"该保留什么、该扔掉什么"的工程难度就上去，噪声也更容易滚雪球。

二是步骤之间的硬依赖：单轮问答里，模型偶尔"看错中间一段"，有时还能靠最后的用户追问纠偏；Agent 里一个错误可能被下一步当成事实继续用，错误会像链条一样传下去。

除此之外，还有上下文漂移（Context Drift）（它不是 Agent 的专属，长会话也会有）。

上下文漂移指的是随着上下文变长、新内容不断堆进来，模型对"最初要做什么、必须遵守哪些约束"的把握变弱，输出开始偏离最初目标。它最典型的体感是聊着聊着忘了本，或做着做着跑题了。

这种现象不只出现在 Agent。你和 ChatGPT 连续对话 30 轮、每一轮都把完整历史塞进窗口，同样可能出现"最早说好的格式/边界条件，后面不再遵守"。单次会话只要足够长、堆进窗口的信息足够多，漂移就会发生，本质还是长上下文里的注意力与噪声问题，只是 Agent 往往更快、更自动地把上下文撑长，所以更容易被看见。

把它理解成人类工作里的走神也行：你打开电脑本来要写报告，查资料时点进一条新闻，再点一个链接——半小时后你在看无关视频。上下文里"最新、最响"的东西，总是更容易抢走模型的"当下注意力"。

Zylos Research 曾引用企业侧数据：近 65% 的 AI 失败与上下文漂移或记忆丢失相关，很多人以为是 token 用完了才崩，更多时候是上下文质量在触顶之前就已经劣化。

多 Agent 协作：这才更接近 Agent 场景的特有难题

当多个 Agent 协作时，上下文管理从单点问题变成了分布式问题：

•哪些上下文需要在 Agent 之间共享？共享多少？太多会造成噪声，太少会导致信息断层

•共享的时机？实时同步还是按需查询？

•冲突怎么办——两个 Agent 对同一个问题有不同理解？

每一个问题都会加速 Context Rot，因为每一次不恰当的信息共享都在往各个 Agent 的上下文里注入噪声。

这一节的结论可以收敛成一句：上下文漂移长对话里就有；Agent 往往更容易、更剧烈地撞上它。多 Agent 的协作与分工，才是更偏 Agent 侧的结构性难题。

五、面对 Context Rot，行业在探索哪些解法

问题讲清楚了，接下来自然要问：怎么办？

Context Rot 是架构层面的问题，没有银弹能一劳永逸地解决它。但行业在多个方向上的探索正在取得实质进展。我按从近到远的顺序梳理三个值得关注的方向。

1.让上下文自己进化：微软 ACE 框架

最让我印象深刻的是微软研究院联合斯坦福、UC Berkeley 等机构提出的 ACE（Agentic Context Engineering）框架，已被 ICLR 2026 收录。

ACE 的核心假设很简单但很有力：与其反复调模型权重（微调），不如让上下文本身"进化"。 它把一部分"该记住的经验"写进一份可维护的 playbook（攻略手册）里，下一轮任务开始时，模型先读到这份手册，再动手。手册会随着真实跑任务的结果不断更新。

你可以把它想成公司里的新人手册：第一版可能很薄、甚至有几条是错的；但每出一次事故、每复盘一次，就把教训补进手册里。手册越来越厚不是目的，越来越准才是目的。ACE 用三个角色分工来做这件事：

生成器（Generator）：就是干活的。它按当前 playbook + 当前任务去执行，留下完整轨迹。哪一步做对了、哪一步翻车了、翻车前后上下文里到底有什么。

反思器（Reflector）：像复盘会议。它不直接改模型参数，而是读成功和失败的轨迹，尽量抽出可复用的规则。例如处理发票类任务时，如果日期字段格式不统一，先统一校验再汇总，否则后面必错。

策展器（Curator）：像知识库管理员。把反思器产出的规则增量写回 playbook，重点是往手册里补一条/改一条，而不是每次把手册整本重写。

这解决了两个棘手问题：

•上下文坍缩：反复重写导致细节逐渐消失

•简洁偏差：为保持简洁而丢弃有用洞察

小结：把上下文工程做好，往往比单纯换更大的模型更划算。ACE 也不需要人工一条条标注数据，它利用自然的执行反馈来学习。它证明在相近的工程预算下，优化 playbook/上下文有时比堆参数量更能抬上限，尤其对长链路、强依赖、反复复盘的 Agent 任务。

这也恰好验证了 Context Engineering 的核心论点：模型能力的上限往往不由模型本身决定，而由上下文质量决定。

2.标准化 Agent 与外部世界的连接——MCP 及其争议

Agent 需要连接外部工具和数据来获取上下文。在 2024 年之前，每个平台、每个工具的接入方式都不一样，给 Claude 写的工具定义拿到 GPT 上要改一遍。

MCP 是 Anthropic 在 2024 年 11 月发布的开源标准协议，目标是把怎么连外部世界收敛成一种通用接口（很多人用 USB 来类比）。它确实缓解了一个真实问题：N×M 的连接器地狱。

但 MCP 也面临严肃的批评，而且这些批评值得认真对待。

最大的问题恰恰和 Context Engineering 直接相关——Context Bloat（上下文膨胀）。MCP 需要把所有工具的描述（参数、类型、用法说明）预加载到上下文窗口里。还没开始干活，窗口先被 schema 吃掉一大截。公开讨论里有人测到多 Server 场景下仅工具元数据就占到数万 token；极端案例里，单个 Server 暴露上百个工具时，工具定义本身就能逼近六位数 token。这不是在解决 Context Rot，这是在加速它。

行业里也在补洞。例如按需加载/工具检索（不是一上来全量塞 schema），用搜索把相关工具挑进窗口，能显著压低这块固定税。但这也说明：协议解决连接，不自动解决上下文预算。

另外，MCP 还带来安全面（工具即能力，配置不当就是攻击面）和排障成本（分布式进程、JSON-RPC、对比 shell/脚本的可见性）等工程负担。

所以我把 MCP 放在这里，不是把它当正确答案，而是当现实世界里你会遇到的一条路径：它让集成变快，但也可能让上下文更胖；它回答的多半是"能不能接上"，Context Engineering 还要回答"接上之后给模型看什么、给多少、何时给"。

3.从「连接」到「理解」——Context Graph

Gartner 有一个值得注意的预测：到 2028 年，60% 仅依赖 MCP 而缺乏语义基础的 Agent 项目将失败。 这句话可以翻译成更朴素的需求：你把工具都接上了，模型也能调用了，但企业真正缺的是：这些调用在业务上意味着什么、和别的系统里的事实如何对齐、过去类似决策是怎么做出来的。

Context Graph（上下文图谱）想补的，就是这一层。

为了更好的理解，我先用大家更熟的概念来解释：知识图谱（Knowledge Graph）。知识图谱更像企业的"黄页 + 关系网"：公司、人、产品、合同、条款……谁和谁有关、属性是什么。它擅长回答"是什么"。

Context Graph在此基础上，更强调「过程与证据」：一次审批为什么过、为什么拒；一个客户问题为什么这样回；某次发布谁拍板、依据了哪些条款和历史案例。它把决策链路、工作流痕迹、事件时间线也结构化起来，让系统不仅能查到"事实表"，还能解释当时为什么这么走。

对企业来说，这直接对应三件事：跨系统的可解释性、合规审计、以及多 Agent/多应用之间的对齐。否则每个 Agent 各自揣一份自己的局部真相，很容易互相打架。

你可以把它理解成：不只存地图上的点，还存你走过的路线、路口为什么转弯、当时导航提示了什么。Agent 越多、自动化越深，这种“可回放、可对齐”的层就越值钱。

Gartner 也预测到 2028 年 50%+ 的 AI Agent 系统会引入类似 Context Graph 的能力来做护栏、可观测与审计。

4.三个方向的关系

ACE 让单个 Agent 的上下文越用越好，MCP 让 Agent 能标准化地连接外部世界（虽然还有问题要解决），Context Graph 让 Agent 能真正理解业务上下文。

它们不是互相竞争的替代方案，而是解决 Context Rot 的不同层次。

六、Spotify Honk 实战：1500 个 PR 验证了上下文设计比模型选择更重要

最后来看一个真实的大规模落地案例。

1.背景

Spotify 的工程基础设施跨越数千个代码仓库。大量重复性代码维护任务：依赖升级、API 迁移、安全补丁，靠人工太慢，靠脚本质量不够。他们决定用 AI Agent 来做。系统叫 Honk。

2.失败与发现

Spotify 先试了开源方案（Goose、Aider），发现无法在大规模场景下可靠地生成可合并的 PR。自建 Agent 循环也遇到了复杂性和上下文管理瓶颈。最终的关键发现是：决定成败的不是模型能力，而是 Context Engineering。

3.他们具体做了什么（三件事）

第一，把工具关进笼子里。 Agent 不是工具越多越好，而是只允许一组非常克制的 bash / verify / git 能力。工具少了，schema 和中间输出就少了，上下文里的噪声更难滚雪球——这本质上是在用 隔离（Isolate）给 Context Rot 降噪。

第二，把指令写成 Agent 能稳定执行的规格。 不是写给人看的漂亮话，而是写清楚前置条件、给具体示例、用测试定义"什么叫做完"。这是在用 Write/Select 控制"模型一开始看到什么、每一步该以什么为准"。

第三，用独立验证把反馈变可靠。 让"改得对不对"由程序说了算，而不是由模型的自我感觉说了算（你可以理解成：不让 AI 自己宣布"我改好了"，而是让构建系统给出结论）。这些真实的命令行输出再写回对话，成为下一步模型继续修改的依据。这样做的好处特别好懂：模型下一步读到的不是一句含糊的"已完成"，而是具体失败原因（哪一步挂了、哪一行不对）。上下文里少了很多"听起来合理但其实没验过"的幻觉式中间结论，错误就不容易在后续步骤里被当成事实一路传下去，也就是用外部世界的硬结果，给 Agent 的上下文"消毒"。

4.结果

成功合并 1,500+ PR，覆盖数千个代码仓库。

复盘时他们强调的重点，并不是"我们押中了某一个最大号的模型"。他们把胜负手放在上下文治理上：工具面、指令面、验证面三件事，分别对准了第二节里那类问题（噪声、注意力、错误连锁）。在前沿模型都够用的区间里，这类工程往往比单纯换型号更能决定你能不能规模化落地。

最后

回到开头的那个场景：Agent 跑了 50 步后开始犯蠢。

现在你知道了——这不是 bug，不是模型不够强，不是 token 不够多。这是 Context Rot：Transformer 架构的物理特性。注意力在稀释，位置编码在漂移，噪声在累积。指望靠更大的窗口解决它，就像指望靠更大的水杯解决漏水一样。

真正的解法是管理好进入窗口的每一滴水。

•ACE 框架告诉我们，上下文可以自我进化，不需要调模型权重

•MCP 在标准化连接层面取得了进展，但也暴露了"连接 ≠ 理解"的局限

•Context Graph 指向了更深层的需求：Agent 需要的不只是数据，是对业务的理解

•Spotify 用 1,500 个成功的 PR 证明了：在前沿模型都够用的区间里，上下文治理往往比纠结"换更大号"更能决定规模化

Agent 的核心瓶颈不是推理能力，当前的前沿模型推理能力已经相当强了。瓶颈是上下文管理。 解决了上下文问题，很多看起来"模型不够强"的问题会自动消失。

   学习资源推荐

如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！​

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示

​因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

四、AI大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。