MIT 的研究者最近提出了一个解决 context rot 的方案：递归语言模型（Recursive Language Models，RLM）。
先说 context rot 是什么体验：
你把一本 200 页的文档丢给 ChatGPT，问一个简单问题，答案错了——但信息就在第 53 页。你没有超出 context 窗口，模型就是处理不了这么多内容一起推理。
不是窗口问题，是推理失败
前沿模型在 needle-in-a-haystack（大海捞针）测试里表现极好。把一句话藏在大量填充文本里，让模型找，它能找到。
但这不是在测量推理能力，这只是测量检索能力。同样这些模型，让它们在数千条记录里做计数、分类、推理——性能崩溃。你自己可能也注意到了：长对话的 Claude Code 变慢了，ChatGPT 聊久了需要更多重复提醒。
模型不是在幻觉，是在随着 context 增长变笨。
递归语言模型的核心思路
一句话：不把所有东西同时塞给模型，让它把 context 拆成小块，递归地处理。
关键区别：
- Agents 是人类设计步骤，模型按脚本执行
- RLMs 是模型自己决定怎么分解 context
就像 Jupyter notebook：你把 dataframe 加载进变量 df，之后每个 cell 引用 df 而不需要每次重新上传 CSV。RLM 把 200 页文档变成一个叫 ctx 的变量，放在 REPL 环境里，模型通过工具调用来探索它。
四个工具
模型不直接读 ctx，设计成不成功便成仁的关键在于它拥有的工具：
- Peek：看前 2000 字符了解结构
- Grep：用正则过滤相关行
- Partition：拆成更小的 chunk
- 递归调用自己：对 chunk 继续处理
这四个工具覆盖了数据分析师会用到的所有访问模式。
一个具体例子
5000 条客服工单，问："用户 12345、67890、11111 里，有多少问题涉及账单？"
传统 LLM：把所有 5000 条工单全收进去，试图扫描全部，然后计数出错。
RLM 做法：
- Peek 结构：每行有 Date、User ID、Question
- Grep 目标用户，从 5000 条筛选到 50 条
- 递归调用："把每条分类为账单或其他"
- 返回 最终结果
根模型的 context 自始至终很小，没有 rot。
为什么这事值得重视
- 没有 context rot：不管文档多大，准确率稳定
- 无限 context：1000 万 Token？多 partition 几次就行
- 可解释：能看见模型具体做了什么
- 成本效率：多次小调用优于一次超大调用
- 自动受益：LLM 本身变强，RLM 自动变强