代码执行 AI 代理如何让 128K 上下文窗口变得过时

Source: Dev.to

问题：上下文腐烂

长上下文窗口成本高、速度慢，而且常常被浪费。
当一个代理分析一篇 50,000 字的文档时，它通常会把整篇文本全部加载进上下文，处理一次，然后在回忆中部的某个具体句子时感到吃力。这种现象——上下文腐烂——是因为注意力分数在大量 token 上被稀释，导致模型忘记刚刚读过的内容。

买更大的上下文窗口就像买更大的行李箱，因为你决定不了该装什么；这并不能解决根本的组织问题。

RLM 逆转：不直接处理，而是编排

递归语言模型 (Recursive Language Model, RLM) 颠覆了传统思路。它不是直接摄取数据，而是 与 数据 交互。

“LLM 的上下文不是储存罐，而是工作台。”

RLM 获得一个持久的 Python REPL。数据——无论是 10,000 页的 PDF 还是庞大的数据库——都不会被加载进模型的上下文，而是作为变量 input_data 存在，只能通过代码访问。这迫使行为发生根本性转变：

1. 搜索，而非阅读

RLM 不能直接“看到”数据。它必须编写 Python 代码来搜索关键词、过滤实体或切片特定章节，只检索它需要的部分。

2. 存在 RAM 中，而非神经元里

中间结果存放在 Python 变量中，而不是模型的上下文历史里。这相当于一种 “扩展记忆”，不会受到注意力衰减的影响。

3. 委派，而非自行推敲

对于大规模数据集，RLM 可以生成 子‑LLM——全新的模型实例，拥有干净的上下文。它可以通过 llm_batch() 并行处理 100 个文档块。主 RLM 只看到摘要，从而保持自身上下文的清晰。

“扩散”答案：多轮推理

传统聊天模型一次性给出答案；一旦写出句子，就固定下来。RLM 的工作方式不同。它初始化一个 answer 状态，并在多个推理回合中 扩散 其答案，进行草稿、事实核查、修订，只有在产出经过完善后才将 ready=True。

# Diffusion answer skeleton
answer = {"content": "", "ready": False}

# Example workflow
while not answer["ready"]:
    # generate a draft fragment
    fragment = llm_generate(...)
    answer["content"] += fragment

    # optional verification step
    if verify(answer["content"]):
        answer["ready"] = True

传统上下文 vs. RLM

参与方式

RLM 不是空想，而是一套可以今天就开始探索的架构。基于 PydanticAI 和 FastAPI 的参考实现已开源。

代码仓库：

未来不属于记忆最长的模型，而属于懂得不必记住一切的模型。