上下文管理到Runtime操作系统，问什么？

在 LLM 发展的上半场，我们执着于不断拉长 Context Window，从 8K 到 128K 甚至百万级别。但在下半场，资深开发者们逐渐意识到：盲目拉长上下文是在用昂贵的算力掩盖逻辑管理的无能为例。 这一章我们围绕Coding这个核心视角来寻找一些新的上下文管理的思路：以 Coding 为核心，将 Context 视为“内存（RAM）”，将 Runtime 视为“状态（State）”，构建一套属于智能体的“操作系统”。 最近，ByteDance 的 Context-Folding、MIT 的 RLM、以及热门项目 Ralph 的出现，共同指向了一个极其明确的趋势：未来的智能体不再是“文本生成器”，而是Stateful Runtime Operator。 这一章我们不精读论文，而是围绕coding的上下文管理，分别看下以下论文中相关的点。 内存折叠：上下文的“分级治理”与垃圾回收 Scaling Long-Horizon LLM Agent via Context-Folding 在长程任务（如 Deep Research 或全库代码修改）中，Agent 会产生海量的中间工具调用日志。传统的做法是全量堆叠，但这会导致上下文迅速“通胀”。 核心工程实现：Branch & Return 字节的方案非常 Native 地借鉴了 Git 分支管理的概念： Branch(description, prompt)：创建一个子分支，开启子任务，此时所有的中间逻辑（搜索结果、读取的长文件）仅在子分支内流转。 Return(message)：子任务结束，物理删除子分支内所有过程 Token，仅将精炼后的执行结果 merge 回主分支。 这里字节是使用了GRPO来通过训练优化模型调用Branch和Return工具的准确程度，不过这个折叠的思路其实是可以通过工具描述结合Git的相关操作来实现。 近期Claude 2.1的最新迭代中，SKILLS已经支持了fork功能，让SKILLS在隔离的上下文中运行，不会污染外层会话。所以在当前这个阶段，大家的想法都趋于一致性~ RLM：把上下文当作“外部存储”的渐进式加载 RECURSIVE LANGUAGE MODELS RLM 的思路与数据预处理中的“渐进式加载”如出一辙：当内存（Context Window）装不下超大文件（Long Prompt）时，不要强行负载，而是通过编程手段分片处理。 核心范式：上下文即变量 RLM 将提示词加载为 Python REPL 环境中的全局变量 ctx。模型不再是“阅读”指令，而是通过以下操作“操控”指令： Probe：通过 print(ctx[:500]) 观察指令局部。 Split & Loop：根据关键词分割指令，并进行循环递归。 Regex：利用正则精准定位关键信息。 llm_query：这是论文中很有意思的一个点（哈哈虽然我对效果存疑）——在代码环境中反向暴露大模型能力，实现“模型嵌套代码，代码调用模型”。 这里对比Context-Folding在每个branch开始还需要主Branch向子branch发送全部信息，而RLM只需要通过全局的变量持久化，就可以实现主要信息的直接传递，无需大量显式的信息传递。 这里就有两个点感觉有试验下的价值 通过持久化变量传递信息：不过需要注意的是通过print打印变量的关键信息，因为coding是不随多轮对话传递的，因此需要在观测中暴露必要信息，这一点其实是不稳定的根源 在code环境中引入模型操作: 使用例如RLM定义的llm_query这个函数，在代码工具中反向暴露大模型操作，从而把简单的代码工具，进一步拓展成拥有模型能力的独立子智能体 使用GPT5的完整指令如下，仅参考思路，个人更倾向从工具角度去做结合（还是要顺着模型native能力的发展方向去做）~ CaveAgent：双流架构下的“状态化”运行时 CaveAgent: Transforming LLMs into Stateful Runtime Operators CaveAgent 进一步强化了“变量即记忆”的思路。它提出 LLM 应该在两个流中切换： 1. Dual-stream Architecture Semantic Stream（语义流）：轻量级推理上下文，仅记录“想了什么”。 Runtime Stream（运行时流）：持久化的 Python 环境，记录“存了什么”。模型直接操作外部变量的“句柄（Handle）”而不是内容。