Context Rot：AI Agent 变蠢的真相，是上下文管理失控

很多团队在做 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来实现目前主流的方案叫 RoPERotary Position Embedding旋转位置编码。问题在于模型的位置编码是在训练时学到的而训练时它只见过有限长度的上下文。比如一个模型训练时最长见过 32K token 的文本现在你让它处理 200K token 的上下文。这就像你拿一把只标到 30 厘米的尺子去量 2 米的东西——前 30 厘米量得很准后面的刻度全是外推出来的越往后越不靠谱。模型对什么信息在什么位置的感知会随着上下文长度的增加而逐渐失准。虽然现在的模型通过各种技术手段在努力缓解这个问题但它本质上是一个训练分布外的挑战模型在推理时遇到的上下文长度越超出训练时见过的位置编码就越不可靠。3.「检索噪声累积」书桌上的纸越堆越多找东西越来越难这个最好理解。想象你的书桌一开始很干净上面只有你正在看的那份文件。你需要的信息一眼就能找到。但随着工作推进桌上堆的文件越来越多工具调用返回的数据、中间步骤的计算结果、调试日志、错误信息、历史对话记录。每一份文件可能都有一点用但大部分和你当前这一步要做的事情关系不大。这就是 Agent 运行过程中上下文的真实状态信噪比持续恶化。Chroma 的研究给出了一个很具体的数据当检索集包含 20 条结果时通常只有 3-4 条真正相关其余都是噪声。模型在推理时被迫花费大量注意力来过滤这些噪声既浪费了有限的注意力资源又增加了被噪声误导的概率。4.三个缺陷的叠加效应这三个问题不是互相独立的它们会叠加放大注意力被稀释了同时位置编码还不准信噪比又在恶化三重打击叠加在一起就是 Context Rot 持续、渐进、不可避免地发生的原因。三、什么条件会加速 Context Rot四个容易踩中的陷阱上一节讲了 Context Rot 的底层原因它是 Transformer 架构的先天缺陷一定会发生。但在实际系统中有些条件会让它恶化得更快。Chroma 的研究揭示了四个常见的加速器理解它们有助于在设计系统时主动规避。因素影响为什么危险低语义相似度模型更难定位目标信息用户问法几乎不可能和文档表述一模一样语义干扰项比纯随机噪声更致命长得很像但实际无关的内容模型容易被骗结构化内容⚠️ 反直觉逻辑清晰的长文档比随机打乱的更难处理结构化内容让注意力在多个看起来相关的区域分散长检索集k20 时信噪比极低不如只取 Top-3 到 Top-5 精准1.「低语义相似度」用户的问法和文档的表述不一样当查询和目标信息之间的语义相似度低时模型更难在上下文中定位目标信息。换个生活化的说法你在一个大图书馆里找一本书如果知道书名一秒钟就能在目录里找到但如果你只知道大概讲什么的而且你的描述和书的标题用的是完全不同的措辞你说怎么让 AI 不瞎编书的标题叫检索增强生成中的忠实性约束那找起来就难多了。在现实场景中这是极其常见的。用户的提问方式几乎不可能和知识库文档的表述一模一样。语义差距越大模型在长上下文中找到正确信息的难度就越大Context Rot 的影响也越明显。2.「语义干扰项」长得像的假答案比随机垃圾更危险当上下文中存在与目标信息语义相似但实际无关的内容时检索和推理性能的下降幅度显著大于随机噪声。还是那个图书馆的例子。如果书架上混入了一堆完全不相关的书比如菜谱你很容易忽略它们因为一眼就能看出不对。但如果混入的是一堆标题看起来很像、但内容完全不对的书那就容易被骗了。你以为找到了打开一看不是再找又被另一本骗了。这就是语义干扰项比纯随机噪声更致命的原因。模型的注意力被这些看起来相关的内容吸引过去浪费了本就稀缺的注意力资源甚至可能基于错误的信息做出推理。3.「结构化内容」组织得越好的长文档反而越难处理逻辑结构清晰的长文档比同等长度的随机打乱内容更容易导致性能下降。这个发现非常反直觉。直觉上我们觉得结构清晰的文档应该更容易处理毕竟有标题、有层次、有逻辑。但实验表明恰恰相反。原因是结构化内容中有大量看起来相关的区域每个小节的标题都可能匹配你的问题每个段落都像是可能的答案来源。模型的注意力在这些区域之间反复跳转、过度分割反而比在一堆乱序文本中定位目标更困难。就像在一个所有门都长得一样的走廊里找一间特定的房间反而比在一堆明显不同的建筑中找到目标建筑更难。4.「长检索集」检索结果越多不等于越好增加检索返回的结果数量k 值会导致信噪比快速下降模型性能反而恶化。这个最实用。很多人做 RAG 的时候想多检索一些结果总不会错吧万一有用呢实验数据告诉你会错。Chroma 测试表明当 k20检索返回 20 条结果时通常只有 3-4 条真正相关其余全是噪声。这些噪声不仅无用还会主动损害性能前面讲过无关上下文会导致准确率下降 15%-25%。所以Top-K 不是越大越好k3~5 往往比 k20 效果更好。 宁缺毋滥。四、为什么 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 等机构提出的ACEAgentic 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 GraphGartner 有一个值得注意的预测到 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 RotTransformer 架构的物理特性。注意力在稀释位置编码在漂移噪声在累积。指望靠更大的窗口解决它就像指望靠更大的水杯解决漏水一样。真正的解法是管理好进入窗口的每一滴水。•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大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。