上下文驱动 AI 效能 | Context Rot 根因、挑战与 MIT 创新解决方案

……

斐夷所非

1002人浏览 · 2026-01-04 18:11:56

斐夷所非 · 2026-01-04 18:11:56 发布

注：本文为 “上下文驱动 AI 效能” 相关合辑，了解一下上下文工程的进阶之路。
图片清晰度受引文原图所限。
略作重排，未整理去重。
如有内容异常，请看原文。

什么是上下文工程？

原创 amazinday 汤屋 THouse 2025 年 12 月 9 日 20:01 重庆

什么是上下文工程？

上下文工程（Context Engineering），指在大模型（大语言模型，LLM）的推理过程中，筛选并维护最优 token 集合的一系列策略。

简单来说，就是在大模型思考时，帮助它挑选出重点关注的内容、筛去无关信息，让它把注意力花在刀刃上。

从提示工程到上下文工程

在大语言模型发展的早期阶段，其主要应用场景大致可分为两类：

以日常对话为代表的多轮交互任务（例如你不断询问大模型问题）；
面向特定目标的单轮推理或生成任务（例如让大模型处理数据）。

在上述两类任务中，提示词（prompt）均扮演着至关重要的角色。提示工程（Prompt Engineering）的核心目标，即通过精心设计输入提示——尤其是系统提示（system prompt）——来引导模型行为，从而提升任务执行的准确性、一致性与有效性。

然而，随着智能体（Agent）技术的快速发展，研究者和开发者日益倾向于构建能够支持多轮推理、长期任务执行以及复杂问题求解的高能力智能体。

在此背景下，需要管理的对象不再只是单一的提示词，而是一整套上下文策略。这套策略包括：系统提示、可调用工具、模型上下文协议（MCP，一种模型与外部工具对接的接口）、外部知识源（如文件或数据库），以及完整的消息历史等。

在智能体进行多轮循环推理的过程中，上下文信息会持续累积。因此，上下文工程的核心目标，便是在海量动态生成的信息中，高效筛选并保留对当前任务最具价值的内容，以适配有限的上下文窗口容量。

值得注意的是，上下文工程是迭代式的：每一次模型生成新内容后，都会产生新的上下文，此时又需要把这部分也加进上下文窗口，再作为信息传递给模型。所以在每次把信息传递给模型前，都要进行一次上下文的筛选和处理。

Prompt engineering vs. context engineering

为何上下文工程如此重要？

Anthropic 的研究人员在实验和观察中总结出“上下文衰减（Context rot）”的概念，指出随着上下文窗口中 token 数量的增加，大模型从中准确提取出需要的信息的能力在下降，推理能力也会随之下降。

如下图所示，在“重复词语识别”任务中，多个主流大模型（包括 Claude Sonnet 4、GPT-4.1、Qwen3-32B 和 Gemini 2.5 Flash）的性能均随输入长度的增长而显著下滑。

这是由于大模型基于 Transformer 这个底层架构导致的。Transformer 的注意力机制使得每个 token 都能关注到上下文窗口中所有的其他 token。

对于长度为 n 的上下文窗口，就会产生 n²个注意力对，计算复杂度为 O（n²）。随着 n 的增大，注意力不断地被稀释，导致模型更难以聚焦于关键信息。

另一部分的原因是大模型训练时使用的更多是短序列数据，长序列数据的缺乏导致大模型更难学到长距离的依赖关系。

使用位置编码插值（position encoding interpolation，一种在不重新训练模型的前提下扩展上下文长度的技术）等技术可以高效拓展上下文长度，但代价是“把一张大图放进一个小屏幕里”：虽然信息都存在，但是整体变模糊了，位置分辨率下降了。

因此，我们需要将上下文视作一种有限的资源。如何利用好宝贵的上下文窗口，正是上下文工程的价值。

高效上下文的组成要素

基于大模型有限的上下文预算，我们首先需要精打细算地处理好其中的每一个部分，以达到更好的智能体效果。

1.系统提示词

系统提示词作为大模型任务执行的引导框架，其撰写应该遵循两个原则，一是力求简洁精炼，二是表达必须清晰，以达到一个恰恰好的中间态：

既不是用硬编码（类似规则匹配，把规则都写死了）试图精确控制智能体，反而导致系统变得很脆弱、难维护；
也不是只给出模糊的高层次指导，指望大模型能够 get 到其中的含义。

Pasted image 20251208152050.png

我们建议使用<背景信息>、## 工具指南这类使用 XML 标签或 md 格式的文本进行系统提示词编写，至少以现在的大模型水平来说明确的格式化文本能够提升其理解能力：因为大模型在训练时使用了大量的结构化文本，也学到了其中的层级知识；同时当前的大模型尚难以从非结构化提示中自动推导出清晰的任务层级。

2.工具

工具（Tools）是智能体可以调用已解决具体问题的功能模块或接口，作为智能体与环境交互的手臂，在工具设计的阶段就应该保证构建出大模型易于理解、功能重叠部分最小的工具。

此外，不要把工具一股脑的放进工具集里，当大模型也不知道用哪个工具最好的时候，它也很难给出满意的答案。所以，我们需要配置的是最小可行工具集：尽可能用最少的工具覆盖最全面的使用场景，同时避免功能重叠。

3.提供示例

提供示例（即少样本提示，few-shot prompting）是一种很有效的方法，但在实践中最好是精心挑选一组高质量的典型事例，重质不重量，覆盖常见的情景（关键任务；成功失败路径；边界情况等），而不是将大量的事例全部放到提示词中，试图通过穷举来固定大模型的规则。

使用少样本提示时一定要强调样本质量，如果示例中存在错误、冲突和模糊，反而会对大模型造成很大的负面影响。

如何在运行时动态检索上下文

传统的 AI 智能体应用将所有可能用到的数据通过嵌入的方式加载进上下文中，以供后续推理使用，但这种方法会大大占用上下文窗口，大量无关信息可能会淹没关键信息。

所以越来越多的人开始使用**即时上下文（Just-in-Time Context）**的方法（也称为 Offload 方法）。

简单来说，即时上下文不再将大段数据放进上下文窗口中，取而代之的是轻量级的标识符（如文件路径、URL、数据库查询语句等）。

当大模型需要数据时，使用工具动态地获取各种内容。这就像我们不会背下整本书，而是记住书中大致知识点的位置，等到需要的时候拿起翻阅即可。

除了占用窗口小、存储效率高的优点外，这些引用的元数据本身就很有价值：即使大模型没有加载全文，只是看到文件路径、文件命名、时间戳等元信息，就可以让大模型产生初步判断，帮助它确定是否要继续查询、深入读取内容。

例如，一个名为 2024_Q3_sales_summary.csv 的文件，仅凭名称就能让模型推断其可能包含季度销售汇总数据，从而决定是否值得读取。但如果文件名是 data_final_v2_updated.xlsx，则几乎无法提供有效线索——这说明良好的命名规范本身就是上下文工程的一部分。

在这样的自主探索中，智能体还能实现渐进式披露（Progressive Disclosure）：它会像人一样，通过数据结构、命名选择是否要进一步探索；搜索小部分数据进行验证；逐步构建起自己的理解，找到真正需要的信息，只把这部分必要内容保存进工作记忆中，并可以通过结构化笔记实现记忆持久化等等。这种方法通过只保留重要信息避免了信息过载，从而提高了整体的推理效率和准确性。

但这种方法不可避免的存在一些代价：每次都需要调用工具、等待结果，比直接把所有信息都放进上下文窗口中所需时间更长；同时，如果没有好的工具和启发式规则设计，大模型可能会出现执行无意义的操作、忽略关键文件、陷入死循环等问题。

即时上下文可看作 RAG 思想在智能体架构中的自然延伸——但不同之处在于，智能体能主动决定何时、何地、以何种方式触发检索，而非被动响应单次查询。

那么使用何种检索方法效果最好呢？

在 LangChain 的一次编程基准测试中，文件工具检索效果最好，效果明显优于向量检索和直接进行 context 填充。

文件工具检索更接近于生成式搜索，做法是提供一个包含所有文档 URL 和简要描述的 Markdown 文件，让 agent 可以借助工具调取所需文档，后来 LangChain 长期保持这种做法。

动态检索本质上是在‘计算/等待时间’和‘上下文效率’之间做权衡。高频、低延迟场景（如客服对话）可能更倾向预加载；而复杂推理任务（如科研分析）则更适合渐进式探索。

所以在某些场景下，混合策略可能是一种好的选择：先将重点的信息进行预加载，再动态检索所需要的细节信息，以实现更好的效果。

长期任务中的上下文工程

长期任务通常是指需要在较长的时间跨度内（几分钟到几小时甚至更久），通过多步骤、多交互、持续推理于行动才能完成的复杂目标。

目前许多 AI 公司都推出了能解决长期任务的智能体，例如 Anthropic 的 Claude Code、KIMI 的 OK Computer 以及千问、豆包、秘塔等 AI 具备的深入研究功能。

对于一些复杂的项目（大规模代码重构、综合性研究等），目前大模型的上下文窗口远不能满足。而且在可预见的未来，无论上下文窗口能扩大到多大，都不可避免地面临上下文污染和信息相关性的问题。

因此可以说，上下文工程是实现长期任务处理的必经之路。

针对这样的问题，Anthropic 团队提出了这三种方法：压缩（compaction）、结构化笔记（structured note-taking）和多智能体架构（multi-agent architectures）。

1.压缩

压缩指的是在上下文窗口快装满时，对其进行总结摘要，并用该摘要开启一个新的上下文窗口。这种方法使智能体最大限度的提炼关键信息，能以最小性能损失继续工作，使得原本有限的上下文窗口在逻辑上实现了“无限”。

Cognition 在其博客中强调，压缩是一个需要着重对待的步骤，无论是反复打磨 prompt 或者专门微调一个模型来做压缩，都是值得的。

压缩更适用于需要大量来回交互、保持对话连贯性的任务。

要做好压缩，一定要把握好度：过度的压缩导致大模型可能会失去关键的细微信息，保守的压缩又会浪费一部分上下文窗口。

在 Anthropic 的实践中，压缩的做法通常是首先将快满的上下文窗口传给大模型，由其进行总结提炼。在此过程中，模型会重点保留架构决策、未解决的 bug 和实现细节，而重点丢弃用完的工具、消息和日志。随后，模型将总结的信息加上五个最近使用的文件传给智能体继续工作。

在压缩的调试细节方面，Anthropic 建议首先最大化召回率，当大模型确保不漏掉任何有用的信息，之后再提高精确率，分析压缩后的信息冗余进行剔除。

在 Manus 的实践中，使用了一种称为 context offload 的方法：在每次压缩前，先将全部文本保存到数据库中，确保原始数据不丢失；这样即使压缩导致信息损失，仍然可以回溯到原始数据。

此外，还存在一个具有争议的问题：智能体运行过程中的错误路径是否需要压缩保存？部分观点认为如果幻觉被写入上下文窗口，就会持续污染后续的推理决策；也有部分观点认为保留错误能让智能体更好的学习，例如在编程场景中，保留完整的历史信息能带来更好的表现。

2.结构化笔记

结构化笔记（又称智能体笔记），指智能体定期将笔记写入上下文窗口外的持久化存储中，有需要时又能将其读取回上下文窗口的技术。这种技术能够以极低的开销维持住长久的记忆，常见的例子是智能体在推理过程中写的待办列表或者 todo.md。

“结构化笔记”这一术语虽在近期被明确提出并工程化，但其核心思想在 AI 领域早有广泛实践，只是命名和实现方式不同。例如：

Anthropic 在多智能体研究中提出外部记忆（External Memory） + 引用智能体（CitationAgent）；
Google DeepMind 在 2022 年提出的 ReAct 框架以及工作记忆（Working Memory）；
Meta 提出的 LlamaIndex（带元数据的知识节点）等。

结构化笔记更适用于有明显里程碑的开发任务。

3.多智能体架构

多智能体架构（也称为子智能体架构）的想法是，使用主智能体总揽全局，发号施令，让子智能体在分配的具体任务上进行深度研究和信息查找。每个子智能体可能会在研究中使用大量 token，但最终返回到主智能体的只是工作的报告摘要（几千 token）。

这种方法实现了清晰的关注点分离，智能体们各司其职，在复杂任务上显著优于单智能体系统。

多智能体架构更适用于使用并行探索能带来显著收益的研究和分析任务。

然而 Cognition 认为多智能体架构听上去很有诱惑力，因为这符合人类分工协作的直觉，而且从工程化角度来说更加模块化，实际却非常脆弱。这其中包含几种故障类型：

大多数任务都包含多层细微差别，极易在传递中失真，尤其是在多轮对话中，任何细节偏差都可能导致子任务偏离原意。
多个子智能体并行工作，却彼此看不到对方在做什么，可能导致最终结果缺乏一致性。

因此，若要成功应用多智能体架构，必须严格遵循两个关键原则：

共享上下文：子智能体不能只看到分配给它的孤立指令，而应能访问主智能体完整的执行轨迹（包括之前的思考、决策依据和中间结论）；
行动蕴含决策：分配给子智能体的任务本身，必须隐含明确的假设和目标边界，避免模糊指令引发歧义。

聪明的你看到这就能想到，执行轨迹的传递过程中，既然主智能体的完整执行轨迹可能很长，直接传递会带来效率问题，那就能用“压缩”的方法进行优化。

图示链接

LangChain 在对比过前两家的多智能体架构后指出，不存在“放之四海而皆准”的解决方案，如何应该使用多智能体架构，需要取决于任务类型：

如果任务偏向“读取型（read）”，例如信息收集、整理等，那么多智能体架构效果更好；
如果任务偏向“写入型（write）”，例如代码生成、文档创作等，那么单智能体架构会更加可靠。

结语

随着智能体能解决的任务越来越复杂，我们面临的挑战不再局限于写好一个完美的提示词，更在于如何高效的管理上下文窗口中的信息，分配好注意力预算。

无论你要完成的任务如何，指导原则始终如一：

找到最小的高信号密度的 token 组合，以最大化实现预期结果的可能性。

参考文献：

Anthropic 官方博客：《Effective context engineering for AI agents》
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Cognition 官方博客：《Don’t Build Multi-Agents》
https://cognition.ai/blog/dont-build-multi-agents
LangChain 官方博客：《How and when to build multi-agent systems》
https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/
LangChain 官方博客：《How agents can use filesystems for context engineering》
https://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/

7 大根因分析：Context Rot (上下文腐烂) 如何毁掉你的 AI 应用效果

Solo Scale 2025 年 8 月 27 日 21:11 美国基于 Context Engineering 相关研究的深度分析

什么是 Context Rot？

Context Rot（上下文腐烂） 是指大语言模型（LLM）在处理长序列输入时，随着输入 token 数量增加，模型输出质量和推理能力逐步下降的现象。这个概念由 Chroma 的 Kelly Hong 在深入研究长上下文 LLM 表现时提出，揭示了一个看似矛盾的现象：尽管 Sonnet-4/Gemini 等模型宣称支持百万甚至千万级 token 的上下文窗口，但实际处理长文本时的表现却远不如预期。

Context Rot 的核心特征

性能递减性：模型准确率随输入长度增加而显著下降
非线性衰减：输出质量的下滑并非平稳递减，而是在某些临界点出现突然恶化
任务敏感性：越是需要综合推理的复杂任务，Context Rot 现象越明显
不可预测性：即使是简单的字符串替换任务，长上下文下也会出现随机错误

引用 Chroma 研究的关键发现：

“任务本身没变，但随着输入变长，模型输出表现急剧下降。”

Context Rot 的根本机制

Context Rot 并非简单的技术局限，而是源于 LLM 架构的本质特性：

1. 注意力机制的分散效应

当输入序列变长时，Transformer 架构中的注意力权重被迫分散到更多 token 上，导致关键信息的注意力密度降低。这类似于人类注意力的有限性——信息越多，单个信息获得的关注度越少。

2. 位置编码的衰减

现有的位置编码方案（如 RoPE、ALiBi 等）在超长序列中的有效性会衰减，模型难以准确理解 token 之间的位置关系，影响序列理解的连贯性。

3. 训练数据分布的不匹配

大多数 LLM 的训练数据中，超长文本相对稀少。模型在推理时遇到的长上下文场景可能超出其训练分布，导致泛化能力下降。

导致 Context Rot 的具体问题

有七大类导致 Context Rot 的具体问题：

1. 歧义累积（Ambiguity Accumulation）

问题描述：随着上下文长度增加，模糊和歧义信息不断累积，模型的判别能力急剧下降。

具体表现：

在短上下文中，即使存在歧义，模型仍能做出正确判断
当相同程度的歧义出现在长上下文中时，模型性能显著恶化
歧义度与上下文长度呈乘数效应，共同加剧性能衰减

实际案例：用户询问"帮我看看这个程序为什么报错"，在包含大量代码片段的长上下文中，模型难以准确定位问题核心，容易被无关的代码段误导。

2. 干扰项混淆（Distractor Interference）

问题描述：长上下文中混杂的语义相近但实际无关的信息会严重干扰模型的判断。

关键发现：

短上下文中，LLM 能轻松区分干扰项与正确答案
长上下文中，语义相似的干扰信息会导致模型"张冠李戴"
干扰项数量与模型错误率呈正相关

典型例子：目标答案是"write every week"，但上下文中还包含"write each essay in three different styles"等相似表述，模型在长上下文中容易混淆这些相似但不同的信息。

3. 信息检索失效（Information Retrieval Failure）

问题描述：在真实的多文档场景中，但凡遇到需要"抓取每一份文档"（Leave No Document Behind）的信息整合任务就会暴露了模型的根本局限。

基础定位 vs 高阶推理：模型在简单信息定位任务上表现尚可（如 GPT-4o 达到 85.67 分），但在需要跨文档比较、聚类、链式推理的任务上表现急剧下滑
分散证据综合困难：当答案证据均匀分散在多个文档中时，模型很难进行有效的信息综合
RAG 的局限性：检索增强生成在此类场景下效果有限，因为碎片化检索往往导致证据链断裂

4. 记忆管理失效（Memory Management Failure）

问题描述：在多轮对话等需要长期记忆的场景中，简单地将所有历史信息塞入上下文会导致噪声淹没有用信息。

实证数据：

全量历史（12 万 token）的表现明显劣于相关摘要（300token）
关键信息被大量无关历史对话稀释，模型难以准确召回早期重要信息

现实场景：用户在第 1 轮对话中提到自己在旧金山，经过 500 轮对话后询问"阳光明媚的日子有什么好的户外活动？"，模型很难从海量历史中准确关联地理位置信息。

5. 计算不可靠性（Computational Unreliability）

问题描述：LLM 并非可确定的计算系统，在长上下文中这种不可靠性被显著放大。

实验证据：

在简单的逐字替换任务中，模型在 500token 时准确率就开始明显下降
会出现随机替换、遗漏或重复片段的现象
可用编辑距离（Levenshtein distance）量化这种随机错误

核心洞察：

“模型对上下文的处理并不均匀，长输入条件下极易爆出隐晦、不可预测的失效点。”

6. 基准测试误导（Benchmark Misalignment）

问题描述：现有的"大海捞针"（needle-in-the-haystack）等基准测试过于简化，无法反映真实应用中的 Context Rot 问题。

关键问题：

基准测试主要考察表层的信息匹配能力，而非深层推理
真实应用中的问题远比基准测试复杂且模糊
简单的字符串匹配任务掩盖了模型在复杂推理上的不足

7. 训练与推理分布不匹配（Train-Inference Distribution Gap）

问题描述：模型在训练时很少接触真正的长文档，导致实际处理能力远低于宣称的上下文窗口。

Scale Law 警示：基于 Loong 基准的发现，模型若要"真能处理 128K Token"，训练时必须持续采样更长文本，否则实际表现与标称窗口差异巨大。

Context Engineering：对抗 Context Rot 的实践方法

应对 Context Rot 需要系统性的 Context Engineering 实践：

1. 摘要策略（Summarization Strategy）

多轮交互场景下定期摘要，只保留核心关键信息
丢弃重复、无关、冗余内容，仅留后续必需的部分

2. 检索增强（Retrieval Augmentation）

利用向量数据库等方案，按相关性动态检索
只检索最相关材料，避免盲目增加 Token 数量

3. 多阶段处理（Multi-stage Processing）

元数据过滤 → 全文检索 → 矢量检索的渐进式筛选
用 LLM 进行重排序（rerank），精细筛选最相关内容

4. 持续实验迭代

建立黄金数据集，持续评估和优化上下文策略
基于真实业务场景进行 A/B 测试，不断改进

关键洞察与未来方向

核心认知转变

从"上下文越大越好"转向"精准优化输入结构最重要"。扩充上下文不是目标，优化信息相关性、动态管理和精准调优才是关键。

Context Rot 的本质

Context Rot 并非简单的技术 bug，而是当前 LLM 架构面临长序列处理时的根本性挑战。它反映了：

注意力机制的有限性
训练数据分布的局限性
推理能力的不可靠性
现实应用与基准测试的鸿沟

应对策略的哲学

正如 InCA 方法提出的，解决 Context Rot 需要从根本上重新思考 AI 系统的设计：

将复杂性从模型内部转移到外部可控的工程系统中
用确定性的规则和逻辑替代不可预测的参数更新
建立可审计、可回溯的知识管理机制

结论

Context Rot 是制约当前 LLM 在真实长文本场景中应用效果的核心瓶颈。理解其机制和成因，对于开发者构建可靠的 AI 应用至关重要。通过系统性的 Context Engineering 实践，结合摘要、检索、多阶段处理等策略，可以有效缓解 Context Rot 的影响，但根本性的解决仍需要在模型架构和训练方法上的重大突破。

AI Agent 的上下文腐烂，该怎么破？

原创 Breezedeus CraftWarmAI 2025 年 12 月 4 日 18:30 北京

背景介绍

AI 智能体（AI Agents）**的迅速发展带来了管理其处理海量信息的新挑战。其中最关键的一项是**上下文工程（Context Engineering），这是一门专注于优化智能体系统中大型语言模型（LLM）信息流的技术。本文综合了 LangChain 的 Lance 和 Manus 联合创始人兼首席科学家 Peak 在一场网络研讨会上的关键见解，旨在全面解析上下文管理的高级技术，特别是 Manus 的创新方法。

Context Engineering：其他系统与大模型之间的沟通桥梁

Context Engineering：跨越认知鸿沟的熵减工程

Context Engineering 2.0: The Context of Context Engineering[6] 这篇论文把 Context Engineering 这个概念放在更大的背景下看待，很有意思。

人类智能与机器智能的发展轨迹持续存在 “Intelligence Gap”（智能鸿沟）。这条鸿沟的本质，是信息熵的不对称。人类在交流时拥有天然的"熵减能力"——我们能够通过共享的文化背景、情感线索、情境感知来主动补全对话中的缺失信息，将高熵的、模糊的意图转化为低熵的、清晰的理解。而机器，至少在目前，熵减这种能力还不够好。

Context Engineering 正是为了弥补这一熵减能力差距而存在的系统工程。 当我们与 AI 交互时，如果只是抛出一个简单的问题，AI 面对的是一个高熵状态：缺乏背景、没有记忆、不了解你的意图偏好。Context Engineering 的核心工作，就是主动为机器进行熵减预处理——通过构建知识库、维护记忆系统、部署 RAG 检索、集成外部工具，我们将原本高熵的、碎片化的信息转化为结构化的、低熵的上下文表示，让机器能够"理解"。

上图展示了 Context Engineering 从 1.0 到 4.0 的演进路径，揭示了一个核心规律：随着 AI 智能水平的提升，其上下文处理能力不断增强，人机交互成本持续降低。

Context 1.0 - Context as Translation（上下文作为翻译）| Era 1.0: Primitive Computation (1990s-2020)

在这个阶段，机器仅能处理结构化输入和简单的环境线索，缺乏对意义和意图的深层理解。AI 表现为"被动执行者"（Passive Executor），人机交互依赖于刚性的、预定义的格式——菜单选择、简单传感器数据等。虽然超越了二进制命令层面，但所有上下文仍必须由人类显式准备并"翻译"成机器可直接处理的格式。此时人机交互成本最高，人类需要投入大量精力来适应机器有限的理解能力。

Context 2.0 - Context as Instruction（上下文作为指令）| Era 2.0: Agent-Centric Intelligence (2020-Present)

2020 年 GPT-3 的发布标志着 context engineering 的转折点。机器展现出中等智能水平，能够理解自然语言输入并推断部分隐含意图，成为"主动代理"（Initiative Agent）。上下文不再局限于显式定义的信号，可以包含模糊性和不完整信息。AI 通过先进的语言理解和情境学习（in-context learning）主动推理上下文缺口，提供更自适应的交互。人类可以用对话方式表达需求，系统能解释大部分潜在含义，人机协作变得切实可行。

Context 3.0 - Context as Scenario（上下文作为场景）| Era 3.0: Human-Level Intelligence (Future)

随着预期的突破，智能系统将接近人类水平的推理和理解能力，AI 进化为"可靠协作者"（Reliable Collaborator）。Context engineering 超越当前模式，使 AI 能够像人类一样感知上下文并吸收高熵信息。可解释上下文的范围显著扩展，包括社交线索、情绪状态和更丰富的环境动态。通过知识库、记忆系统和 RAG 检索，AI 能够在复杂场景中持续协作，实现真正自然的人机协同，AI 将作为知识丰富且高效的伙伴存在。我们目前正处于从 Era 2.0 向 Era 3.0 的过渡阶段。

Context 4.0 - Context as World（上下文作为世界）| Era 4.0: Superhuman Intelligence (Speculative)

当智能系统超越人类能力，它们将拥有"上帝视角"，比人类自己更深刻地理解人类意图，成为"深思熟虑的大师"（Considerate Master）。传统的主客体关系发生反转：机器不再被动适应人类定义的上下文，而是主动为人类构建新的上下文，发现隐藏需求，引导人类思维。这一转变的迹象已经出现——在围棋领域，职业棋手正在向 AI 学习超人类的新策略。此时，机器成为洞察和灵感的来源，从根本上重新定义了人机协作的本质。

这一演进过程的本质，是 AI 逐步接管人类原本需要承担的"上下文熵减工作"。随着 Context Engineering 能力的提升，人类可以用更自然、更高熵的方式表达意图，而将复杂的信息结构化、情境理解和知识整合工作交给 AI 系统来完成。这正是 Context Engineering 作为系统工程的价值所在：不是让人类学会如何更好地与机器对话，而是让机器学会如何更好地理解人类——最终，在 Era 4.0，机器甚至能比人类更好地理解人类自己。

从 1963 年的 Sketchpad 到 1999 年的 Ubiquitous Computing，再到今天的 Langchain、Claude Code、Cursor 等工具，Context Engineering 一直在努力缩小智能鸿沟。下图中的紫色区域标注了 “Human = Machine” 的交汇点，那将是 Context Engineering 的终极目标：当我们成功将人类的高熵意图系统化地转化为机器可理解的低熵表示时，人机协作的效率将达到前所未有的高度。这不仅是技术的进化，更是一场持续的熵减革命。

在模型微调和后训练日益普及的今天，Context Engineering 是应用和模型之间最清晰、最实用的边界。Manus 认为，初创公司应避免过早陷入模型专门化的陷阱，因为这会将产品的创新速度与模型的迭代速度捆绑在一起。即使是使用强大的基础模型进行微调，也可能因为 AI 领域快速的技术颠覆而变得危险。例如，MCP（Manus Code Playground）的推出彻底改变了 Manus 的设计，从一个紧凑的静态行为空间转变为一个几乎无限扩展的开放域环境，这种变化对于已经专门训练过的模型来说是极难适应的。因此，坚定地依赖通用模型和上下文工程，是保持产品灵活性和未来适应性的关键策略。

Context Engineering 为什么有必要

接下来回到 AI Agents 架构中的上下文工程理解视角。为什么从 2025 年 3 月份开始，上下文工程越来越受到大家的重视？

AI 智能体通过自主与工具交互并积累观察结果，交互轮次变长后会导致**“上下文腐烂（Context Rot）”现象。每次工具调用都会生成一个观察结果并附加到聊天历史中，导致消息数量不受限制地爆炸式增长。这种不断增长的上下文长度会降低 LLM 的性能，形成一个悖论：智能体需要大量的上下文，但更长的上下文会损害其效率和准确性。**

AI 智能体能做的事情越来越复杂，交互轮次越来越多。

Prompt Engineering

Prompt Engineering 是我们与 AI 交互的起点——通过精心设计静态的提示词结构（角色、任务、格式、约束、示例、输入），让 AI 理解我们的需求并给出准确答案。这种方法简单直接，但每次对话都是独立的**“单次任务”**，AI 没有记忆，也无法访问外部知识。

常见的 Prompt 结构：

角色定义 - 设定身份
任务描述（整合了背景信息）- 说明要做什么
输出格式 - 规定输出形式
约束条件 - 硬性限制
示例 - 参考模板
输入数据 - 实际内容

一个示例：

从 Prompt Engineering 到 Context Engineering：从静态到动态的进化

Context Engineering 可以理解为 Dynamic Prompting 的系统化升级。它的核心思想是：不再手动编写固定的提示词，而是根据对话情境、历史记忆、知识库内容，动态组装最适合当前任务的上下文。当用户提出问题时，系统会自动从知识库检索相关信息（RAG）、调取历史对话记忆、整合外部工具的数据，然后将这些动态获取的上下文与用户的问题结合，形成一个"信息丰富、情境完整"的增强提示词。

这不仅仅是提示词的动态化，更是整个交互架构的升级：

知识库提供领域专业知识和事实依据
记忆系统维护对话历史和用户偏好
RAG 检索按需获取最相关的上下文片段
工具集成连接数据库、API 等外部资源
系统级设计确保一致性和可扩展性

简单说，Prompt Engineering 是"手工制作每一个提示词"，而 Context Engineering 是"搭建一个能自动生成最优提示词的智能系统"。这就是从手动到自动化、从静态到动态、从单次任务到系统工程的进化。

上下文工程的核心原则与实践

上下文腐烂（Context Rot）是指在长上下文场景中，当上下文窗口超过某个"腐烂阈值"（Pre-rot threshold）后，AI 模型对远端信息的理解和利用能力急剧下降的现象。如图所示，在 0-128K token 范围内（绿色区域），模型能够有效处理上下文信息；当进入 128K-200K 范围（橙色区域）时，性能开始衰减，这就是"腐烂阈值"；而超过 200K 之后的大部分上下文（白色区域）则几乎被模型"忽略"，无法有效利用。

这一现象揭示了上下文过程面临的核心挑战：即使模型声称支持百万级 token 的上下文窗口，实际可用的有效上下文往往远小于这个数字。因此，上下文过程不仅要构建丰富的知识环境，还必须通过智能检索（RAG）、上下文压缩、记忆管理等技术，确保关键信息始终处于模型的"有效感知区域"内，避免重要上下文在长对话中"腐烂"而失效。

面对上下文腐烂的挑战，Context Engineering 形成了几大核心原则：上下文优化 —— 通过缩减与检索技术，提取最相关信息而非盲目堆砌；上下文隔离 —— 借助多智能体设计，为不同任务建立独立上下文空间，避免信息混杂；上下文分层 —— 通过卸载与分层行动空间，将系统知识、历史记忆、当前任务按生命周期分层管理。这些原则通过四大核心技术得以落地实践。

1. 上下文缩减：压缩与摘要的艺术

上下文缩减（Context Reduction） 旨在压缩或总结信息。Manus 将其细分为两种形式：

压缩（Compaction）：一个可逆的过程，将可以从外部状态（如文件系统）重建的信息（例如，用文件路径代替完整文件内容）从上下文中剥离。这样，没有任何信息真正丢失，只是被外部化了。这种可逆性至关重要，因为智能体可能在后续步骤中需要依赖早期的精确行为。Manus 的工具调用和工具结果都存在完整和紧凑两种格式，紧凑版本会剥离可从文件系统或外部状态重建的信息，例如，一个文件写入操作在执行后，其内容字段可以被安全移除，只保留文件路径。当智能体需要时，可以通过路径再次检索。

摘要（Summarization）：一个不可逆的过程，用于浓缩信息。Manus 对此非常谨慎，通常在摘要前会将关键上下文部分卸载到文件中，并始终保留最后几次工具调用的完整细节以保持连贯性。

为了使摘要过程更可靠，Manus 避免使用自由形式的提示，而是采用结构化模式 (Schema)。通过定义一个包含特定字段（如“修改的文件”、“用户目标”、“上次停止的位置”）的表单让 AI 填写，可以确保输出的稳定性和一致性。这种方法强制 AI 概括特定信息，而非随意生成，从而提高摘要的质量和可控性。

Manus 通过跟踪上下文长度阈值来管理这两种方法。当上下文接近“腐烂前”阈值（通常为 128k-200k Token）时，首先触发压缩。只有当压缩的收益变得微乎其微时，才会转向摘要。在压缩时，Manus 可能会选择压缩最旧的 50% 工具调用，同时保留较新的调用记录的完整细节，以确保模型仍有新鲜的少样本示例来学习如何正确使用工具。**在进行摘要时，Manus 总是使用完整版本的数据，**并保留最后几次工具调用和结果的完整细节，以帮助模型平滑地继续工作，避免风格和语气上的突然变化。

2. 上下文检索：文件系统工具的回归

上下文检索（Context Retrieval） 侧重于高效地获取相关信息。与依赖索引和语义搜索的系统不同，Manus 在其瞬时沙盒会话中优先使用更简单的基于文件的搜索工具，如 glob 和 grep。Peak 解释说，由于会话的瞬时性，动态构建索引是不切实际的，因为每次会话都是一个全新的环境，没有时间去动态构建索引。因此，依赖于对基于行的文本格式（如纯文本而非 Markdown）进行操作的成熟命令行工具，是更高效的选择。Manus 倾向于使用纯文本，因为 Markdown 有时会导致模型输出过多的项目符号，且基于行的格式更利于 grep 和按行范围读取。

然而，对于需要长期记忆或访问大型企业知识库的场景，外部向量索引仍然是必要的。

对于简单的搜索，Manus 会直接将完整的搜索结果附加到上下文中，并依赖压缩机制来管理。但对于需要整合多个查询结果的复杂搜索，Manus 会启动一个子智能体（即“智能体即工具”），由该子智能体负责处理、整合信息，并以主智能体预定义的固定输出模式返回结果。

3. 上下文隔离与多智能体设计

上下文隔离（Context Isolation） 通过多智能体架构实现。Manus 借鉴了 Go 语言的并发哲学，提出了两种不同的隔离模式：

通信模式（Communication Mode）：适用于简单的、指令清晰的任务。主智能体向子智能体发送指令，子智能体的上下文仅限于该指令。这种模式适用于主智能体只关心最终输出，不关心中间过程的任务。

共享上下文模式（Shared Context Mode）：适用于复杂的、依赖历史的任务。子智能体可以访问完整的先前上下文，包括所有的工具使用历史。这种模式在需要完整历史记录的场景下避免了信息检索的延迟和成本，但代价是每次子智能体调用都需要预填充更大的输入，且由于系统提示和行为空间不同，无法重用 KV 缓存。

Manus 的多智能体系统设计避免了基于角色（如设计师、程序员）的划分，认为这种拟人化类比效率低下。相反，系统由少数几个专业智能体组成：一个庞大的通用执行器、一个规划器和一个知识管理器。**知识管理器智能体的作用是回顾用户和智能体之间的对话，并判断哪些内容应该被存入长期记忆。*大多数子任务通过“**智能体即工具**”的范式实现，即一个子智能体被封装成一个工具供主智能体调用。在这种模式下，主智能体通过定义输出模式来确保从子智能体获得结构化、可靠的结果，而*子智能体则使用一个特殊的“提交结果”工具，通过约束解码来强制执行该模式。这种设计在 Manus 的“Wide Research”（内部称作“智能体版 MapReduce”）功能中得到了应用，通过共享同一个沙盒，文件系统在主子智能体之间共享，信息传递仅需传递不同的文件路径。**这种“智能体即工具”的设计使得主智能体向子智能体传递信息变得容易，更重要的是，通过定义输出模式和子智能体的“提交结果”工具，确保了从子智能体获得的输出是结构化且可靠。**这种模式解决了多智能体通信中的信息同步难题，尤其适用于复杂任务，它利用共享沙盒和文件系统，通过传递文件路径实现主子智能体间的信息共享。

4. 上下文卸载与分层行动空间

上下文卸载（Context Offloading）的核心思想是：并非所有信息都需要保留在智能体的消息历史中，而是可以将其存储到上下文窗口之外，在需要时再检索回来。另外，随着系统变得越来越复杂，特别是如果集成了 MCP，工具本身会占用大量上下文。上下文中工具过多会导致混乱，出现“上下文混淆”(Context Confusion)，模型可能会调用错误的工具，甚至是不存在的工具。

卸载最流行的实践是利用文件系统——将工具输出、搜索结果等消耗大量 Token 的完整内容转储到文件中，只向智能体返回必要的摘要信息，这样既保持了信息的可访问性，又避免了上下文窗口的持续占用。

Manus 正在试验新颖的**分层行动空间（Layered Action Space）*方法处理工具过多的情况*。*在分层行动空间设计中，上下文卸载不仅体现在工作内容的外部存储，更延伸到对工具本身的*分层管理：通过将大量命令行工具和 API 能力卸载到第 2 层和第 3 层，保持核心函数调用层（第 1 层）的简洁和稳定，从而避免因工具过多导致的"上下文混淆"问题。

分层行动空间（Layered Action Space）具体思路：

第 1 层：原子函数调用（Atomic Function Calls）：Manus 仅使用一小组（10-20 个）固定的原子函数，如读写文件、执行 shell 命令、在互联网和文件中搜索，以及一些浏览器操作。这些函数因约束解码而模式安全，且数量有限，避免了缓存失效和混淆。Manus 刻意避免使用与现有模型训练中工具名称相同的命名，以防止模型混淆不同工具的参数和预期行为。如果自定义函数与现有模型训练中学习到的工具具有相同的名称，可能会导致模型混淆参数和预期行为，从而影响其性能。
第 2 层：沙盒实用工具（Sandbox Utilities）：在完整的 VM 沙盒中，Manus 可以执行预装的命令行工具。LLM 通过系统提示得知这些工具的存在，并被鼓励使用 --help 标志来查询用法。例如，Manus 会被告知在 /usr/bin 目录下有许多命令行工具。对于最常用的工具，其名称会以紧凑格式注入到系统提示中。这极大地扩展了智能体的能力，而无需修改其核心函数调用空间。这些工具的好处在于，它们可以直接处理大输出（例如写入文件或分页返回结果），并可利用 Linux 工具（如 grep、cat、less）进行即时处理。
第 3 层：软件包和 API（Packages and APIs）：此层允许编写并执行 Python 脚本来调用预授权的 API 或自定义软件包。这对于内存密集型计算（如分析大量股票数据）是理想的，因为计算过程在 Python 运行时内存中完成，只有最终的摘要结果返回给模型。Manus 预装了大量的 API 密钥，用户无需单独购买和配置。这种方式虽然不具备模式安全性，但代码的高度可组合性允许在单一步骤中链接多个操作，例如在一个 Python 脚本中完成获取城市名称、城市 ID 和天气等多个任务。

从模型的角度来看，所有三个层的操作最终都通过少数几个核心的原子函数（如 shell 和 file）来执行，从而为 LLM 维护了一个简单、缓存友好且正交的接口。这种混合模式，即结合了直接的工具调用和沙盒中的代码执行，平衡了约束解码的安全性与代码执行的灵活性。Peak 认为，只要是可以在编译器或解释器运行时内部处理的事情，都应该用代码来做；否则，就使用沙盒工具或函数调用。

5. More: 长期记忆、规划与模型适应性

长期记忆：Manus 采用一种显式的“知识”概念，需要用户确认才能将信息（如偏好设置）存入长期记忆。例如，用户可以告诉 Manus 每次都以 Excel 格式交付结果，系统会弹窗询问是否接受此项作为长期知识。**这种“知识”系统类似于一种显式记忆，用户可以主动选择接受或拒绝 Manus 从对话中学习到的偏好。**同时，系统也在探索利用集体用户反馈进行无参数的在线学习，以实现自我改进，例如通过识别用户对字体问题的共同修正来提升数据可视化能力。这种无参数的学习方式，旨在利用用户对智能体行为的纠正（如数据可视化中的字体问题），实现智能体的自我改进，而非依赖传统的参数化训练。
规划：Manus 已经从最初使用 todo.md 文件（被证明 Token 效率低下，浪费了大量交互轮次和 Token）演变为使用一个独立的、结构化的规划器智能体。还有一个独立的智能体**作为“外部审查员”，能够从不同视角审视计划，甚至可以利用不同模型（如 Claude Haiku）的独特见解，从而显著节省 Token 并提高规划质量。**它通过“智能体即工具”的范式实现，作为一个独立的工具供主智能体调用，不再像早期那样通过频繁更新 todo.md 文件来浪费 Token。
适应模型演进：为了应对 LLM 的快速迭代，Manus 采取了一种独特的评估策略：固定其智能体架构，然后在不同的模型（从弱到强）之间进行切换。如果一个架构从较弱的模型切换到较强的模型后能获得巨大提升，那么在某种程度上，该架构就更具未来适应性。Manus 通常每隔一两个月就会进行一次这样的架构审视，并经常在内部使用开源模型或提前试用专有模型，以便为下一个版本的模型发布做好准备。
模型选择与成本：Manus 目前没有使用开源模型，主要是因为在 Manus 的规模下，分布式 KV 缓存的实现难度和成本。与前沿 LLM 提供商合作，利用其强大的基础设施，有时反而比自建开源方案更经济。Manus 不仅使用 Anthropic 模型（认为其最适合智能体任务），也关注 Gemini 和 OpenAI 的进展，并进行任务级别的路由，根据子任务的特性选择最合适的模型（例如，Claude 擅长编码，Gemini 擅长多模态，OpenAI 擅长复杂数学和推理）。Manus 会利用模型提供商的输入缓存（Input Caching）功能，以优化 KV 缓存管理。

6. 安全与评估

安全与防护：Manus 在沙盒环境中投入大量精力进行防护，例如阻止信息泄露（如 Token）到沙盒之外，并对出站流量进行检查。**Peak 强调，如果用户被提示注入，系统会对出站流量进行检查，确保敏感信息如 Token 不会离开沙盒。**对于浏览器内的敏感操作（如登录持久化）或沙盒内的敏感操作，Manus 会要求用户手动确认或接管，因为网页内容本身可能存在提示注入的风险。Manus 与模型提供商紧密合作，共同增强防护措施。Peak 承认，设计一个完美无缺的解决方案非常困难，这是一个循序渐进的过程，目前 Manus 倾向于让用户在敏感操作时接管，并期待模型本身的防护能力增强。
评估策略：Manus 采用多维度的评估方法。首先是用户评分（1-5 星），这是衡量实际用户体验的黄金标准。其次是自动化测试，包括内部创建的、带有可验证结果的数据集，以及侧重于执行性或交易性任务的定制基准。最后，也是最重要的是真人评估，通过实习生评估网站生成、数据可视化等涉及品味和美观的任务，因为这些难以通过奖励模型进行自动化评估。
强化学习与工具调用智能体：Peak 认为，对于支持 MCP 这种非固定行为空间的智能体，难以设计有效的奖励函数进行强化学习。他指出，如果行为空间不固定，就很难设计好的奖励函数，生成的部署和反馈也会不平衡，这实际上是在重复构建基础模型提供商已经完成的工作。因此，Manus 倾向于无参数的在线学习方式，例如利用集体用户反馈进行自我改进，而不是投入大量资源进行强化学习，因为模型公司已经在基础模型层面做了类似的工作。

结论：简化胜于过度工程

尽管上下文工程的技术多种多样，但 Manus 最大的进步往往来自于简化——移除不必要的复杂性，并给予底层 LLM 更多的信任。上下文工程的真正艺术在于，在多个可能相互冲突的目标（如性能、成本、延迟、可逆性）之间找到微妙的平衡，并始终追求更简单、更稳定、更智能的智能体架构。“少做加法，多做理解 (build less and understand more)。”

MIT 团队推出递归语言模型！不改架构、不扩窗口，上下文处理能力扩展百倍

原创 KIK DeepTech 深科技 2026 年 1 月 4 日 14:08 北京

引言：RLM 横空出世，重构长文本处理思路

新年伊始，MIT CSAIL 的一纸论文在学术圈引发了不小的讨论。Alex L． Zhang 、 Tim Kraska 与 Omar Khattab 三位研究者在 arXiv 上发布了一篇题为《Recursive Language Models》的论文，提出了所谓“递归语言模型”（Recursive Language Models，简称 RLM）的推理策略。

图丨相关论文（来源：arXiv）

早在 2025 年 10 月，Zhang 和他的导师 Omar Khattab 就在博客上公开了初步想法，引发了一些关注。如今这篇正式论文带来了更系统的实验和更扎实的数据，论证了通过让语言模型把长文本当作“外部环境中的变量”来处理，可以让模型有效处理超出其上下文窗口 2 个数量级的输入。

Zhang 在推文中写道：“正如 2025 年是从语言模型到推理模型的转换之年，我们认为 2026 年将是递归语言模型的时代。”他还特别提到，RLM 是他们对推理时算力扩展（inference-time scaling）的“bitter lesson 式”解法，即与其精心设计复杂的人工规则，不如让系统自己去学、去算。RLM 的设计哲学与此一脉相承，它不试图从模型架构层面“修复”长文本处理的问题，而是提供一套通用的推理时框架，让模型自己决定如何与超长输入交互。

行业困境：上下文窗口“军备竞赛”背后的隐忧

过去两年，几乎所有主流大模型都在竞相扩展上下文窗口。Gemini 把窗口拉到了百万级别，GPT 系列持续加码，Llama 更是喊出了千万 token 的口号。表面上看，这是一场“谁更能装”的军备竞赛。但问题在于，上下文窗口变大并不意味着模型就真的能把所有内容都“读进去、记得住”。

2025 年年中，向量数据库公司 Chroma 发布了一份技术报告，正式为这种现象命名，“context rot”（上下文腐烂）。Chroma 的研究团队测试了包括 GPT-4.1 、 Claude 4 、 Gemini 2.5 、 Qwen3 在内的 18 款主流模型，发现即便是在最简单的“大海捞针”（Needle in a Haystack，NIAH）任务上，模型的准确率也会随着输入长度的增加而显著下降。

更值得注意的是，当任务本身变得复杂，比如需要语义推理而非简单的字面匹配，性能下滑会来得更早、更陡峭。所谓百万 token 的上下文窗口，实际有效利用的可能只有一小部分。

图丨 Claude Sonnet 4、GPT-4.1、Qwen3-32B 和 Gemini 2.5 在重复词任务上的表现（来源：Chroma Research）

现有方案局限：难以突破的长文本处理瓶颈

针对长上下文的解决方案目前业界已经发展出几种主流策略。最常见的是“上下文压缩”（context condensation），也就是当上下文超出一定长度时，让模型先对前面的内容做摘要，再继续处理新内容。这种方法简单直接，但摘要本身是有损的，早期出现的细节可能在压缩过程中丢失。

另一种流行方案是检索增强生成（Retrieval-Augmented Generation，RAG），先把长文档切块存入向量数据库，根据问题检索相关片段再喂给模型。这避免了让模型一次性吞下整篇长文，但效果高度依赖检索质量，对于需要综合全文信息的问题往往力不从心。

还有一类是递归任务分解框架，允许模型把复杂任务拆解成子任务再递归调用。但这些方法的共同局限在于：它们要么损失信息，要么无法真正突破模型本身的上下文窗口限制。

RLM 核心原理：以“外存思维”重构模型与长文本交互方式

RLM 的核心思路在于换了一个角度来思考问题。与其绞尽脑汁让 Transformer 直接消化长文本，不如把长文本“外包”到一个独立的运行环境中，让模型通过编程的方式按需访问。具体来说，RLM 会启动一个 Python 的 REPL（Read-Eval-Print Loop，读取-求值-打印循环）环境，把用户的长文本作为一个字符串变量存进去。

然后模型不再直接阅读全文，而是编写代码来“窥探”这个变量，打印一小段看看、用正则表达式搜索关键词、按章节拆分等等。更关键的是，模型还可以在代码里调用另一个语言模型来处理子任务，并把结果存回变量中。整个过程是迭代式的：模型执行一段代码，观察输出，决定下一步怎么做，直到最终拼凑出答案。

图丨递归语言模型将提示视为环境的一部分（来源：arXiv）

这种设计的灵感据称来自“外存算法”（out-of-core algorithms）。在传统计算机科学中，当数据量超出内存容量时，系统会把数据存在硬盘上，通过精心设计的调度策略来回读取需要的部分。RLM 本质上是在给语言模型搭建一个类似的“内存管理层”。对外部用户而言，RLM 的接口与普通语言模型完全一样：输入一个字符串，输出一个字符串。但内部的处理方式已经不同。

实验验证：性能跃升同时兼顾成本优势

论文中的实验设计了 4 组不同复杂度的任务。S-NIAH 是最简单的大海捞针任务，答案固定，不随输入长度变化。OOLONG 要求模型对输入中的每一行进行语义分类并汇总，处理量与输入长度成正比。OOLONG-Pairs 更极端，要求找出满足特定条件的所有“用户对”，处理复杂度与输入长度的平方成正比。还有一组 BrowseComp-Plus，给模型 1,000 篇文档（总计约 600-1,100 万 token），要求回答需要跨文档推理的问题。

实验结果显示，裸跑 GPT-5 的表现随着输入长度和任务复杂度的增加而急剧下滑。在 OOLONG-Pairs 上，GPT-5 和 Qwen3-Coder 的 F1 分数都不到 0.1%。但套上 RLM 框架之后，GPT-5 的 F1 分数跃升至 58%，Qwen3-Coder 也达到了约 23%。

在 BrowseComp-Plus 的千文档场景下，RLM（GPT-5）取得了 91.33% 的准确率，而上下文压缩方案只有约 70%，检索工具代理是 51%。研究者还强调，RLM 的成本并不比直接调用基础模型贵多少，在某些任务上甚至更便宜，因为模型可以选择性地只查看需要的片段，而非一股脑把所有内容都送进 Transformer。

图丨不同方法在复杂程度不同的长上下文基准测试中的性能对比。（来源：arXiv）

局限与展望：RLM 范式的优化空间与未来可能

当然，任何新方法都有其适用边界。论文坦承，当输入较短、任务较简单时，直接使用基础模型可能比 RLM 更高效。毕竟 RLM 需要多次与环境交互，开销不可忽视。当前实现使用同步的、阻塞式子模型调用，端到端延迟较高，研究者认为通过异步调用和并行化还有优化空间。

此外，论文中的系统提示词是固定的，并未针对不同任务调优。另一个值得关注的问题是，让模型在 REPL 环境中自主编写和执行代码，在安全隔离和行为可预测性方面带来了新的工程挑战。

论文作者在文末提到，未来可能会出现专门针对 RLM 范式进行训练的模型，就像今天有专门针对推理任务训练的模型一样。他们认为 RLM 的轨迹本身可以被视为一种推理形式，理论上可以通过强化学习或蒸馏来优化。这个方向是否能走通，还需要更多后续工作来验证。

参考资料：

1.RECURSIVE LANGUAGE MODELS
https://arxiv.org/pdf/2512.24601

2.Context Rot: How Increasing Input Tokens Impacts LLM Performance | Chroma Research
https://research.trychroma.com/context-rot

3.X 上的 Alex L Zhang：“Much like the switch in 2025 from language models to reasoning models, we think 2026 will be all about the switch to Recursive Language Models (RLMs). It turns out that models can be far more powerful if you allow them to treat their own prompts as an object in an external https://t.co/6jCyZiLeQl” / X
https://x.com/a1zhang/status/2007198916073136152

运营/排版：何晨龙