Dynamic context discovery

algorithm blog-dynamic-context-discovery — Cross-paper Synthesis
→ Detail (L2) ← algorithm Survey ← All Syntheses

Dynamic context discovery — 本篇 vs 真·相关 (L3) #

目标 entity: Cursor 的 "Dynamic context discovery" 博客 —— 把所有 agent 辅助上下文 (tool output / chat history / MCP schema / skills / terminal) 统一为文件系统上的 惰性加载对象，A/B 显示 MCP-heavy session token 消耗下降 46.9% [blog-dynamic-context-discovery]。 本文把它放进 "long-context agent 的上下文管理" 这一簇 5 篇同行中定位。

1. 相关论文 #

这 5 篇全部落在同一个母问题上：**当 agent 反复面对超出 context window 的辅助信息时，

harness 应该如何决定"放什么进窗口、何时取、丢什么"**。它们沿一条从"惰性接口"到

"主动产物"的谱系分布，本博客处在最朴素、最工程化的一端。

Entity与本篇的关系共享的核心机制
2512.24601 (RLM)最近的 paradigm 同源 —— 都把 prompt/辅助内容移出窗口、只留 constant-size metadata把 $P$ 绑为 REPL 变量、root 只见 metadata [2512.24601]，与博客"文件路径 + 按需 read"同构
2603.28052 (Meta-Harness)最强佐证 —— 独立论文用受控消融证明"文件系统暴露全保真 trace + grep/cat 按需取"优于压缩反馈 [2603.28052]文件系统作为非 Markov 长期记忆，proposer 用 grep/cat 检索
2604.14228 (Dive into Claude Code)同一生产范式的"对照实现"—— Claude Code 用 5 层 compaction 而非纯惰性文件，代表博客明确反对的路线 [2604.14228]append-only transcript + context-as-scarce-resource 原则
2602.22402 (CMV)互补的 userland 工具 —— 把会话历史建成 DAG + 三遍裁剪，量化了"惰性持久化 + caching"的经济模型 [2602.22402]历史落盘为 JSONL、剥离 tool 输出、保留元数据
2605.19932 (PEEK)反向命题 —— 主张某些场景下"被动惰性取"不够，需要主动维护一个 orientation cache [2605.19932]context map 常驻 system prompt，与博客的"惰性发现"形成 active vs passive 对立

共同祖先问题：博客称之为 context allocation problem（任务未知前就要决定窗口内容

[blog-dynamic-context-discovery]），RLM 称之为 context rot

（窗口未满质量已塌 [2512.24601]），CMV 称之为 autocompaction 摧毁累积理解

（132k→2.3k，98% 损失 [2602.22402]）。三种命名指向同一痛点的不同侧面。

2. 本篇 vs 相关论文的 delta #

2.1 新颖之处（博客真正独有的） #

  1. "文件系统就是惰性接口"的极简主义 —— 博客的核心主张是没有新抽象：不是检索索引、

    2. 不是新协议，就是 LLM 已经会用的 rg/tail/read/jq

    [blog-dynamic-context-discovery]。RLM 同样移除窗口内容，但它引入了

    一个有状态 Python REPL + 符号递归 sub-call 的重型 scaffold

    [2512.24601]；博客刻意不要 scaffold，把惰性加载降到"几个标准 shell 工具"。

    delta = 零新 API 的采用成本。

    1. 覆盖面是横向统一，而非单点 —— 博客把 5 类辅助上下文（长 tool 输出、summarization

      2. 时的 chat history、skills、MCP schema、terminal）用同一个 lazy-load pattern 收编

      [blog-dynamic-context-discovery]。同行各自只攻一个面：CMV 只管会话日志裁剪

      [2602.22402]，PEEK 只管 orientation knowledge

      [2605.19932]，Meta-Harness 只管历史候选 trace

      [2603.28052]。

      1. MCP tool schema 的惰性化是博客最具体、最可量化的贡献 —— per-server 文件夹同步工具描述、

        2. prompt 里只留名字，A/B 测得 46.9% token 下降

        [blog-dynamic-context-discovery]。其余 4 篇都没碰 MCP tool explosion 这个具体问题。

        2.2 增量/重叠（别人已论证、博客复用） #

        • "把上下文移出窗口、只留 metadata" 的范式 RLM 已系统化并给出预算界

          • $\text{root iterations} \le K/c$ [2512.24601]。博客的"文件路径 + 按需读"

          本质是 RLM "metadata-only history" 的弱化、无递归版本 —— 博客是 RLM 思想的产品化降维。

        • "文件系统作为 agent 长期记忆 + grep/cat 按需取" Meta-Harness 已做受控验证：去掉原始 trace

          • 只给 score/summary，median 从 50.0 跌到 34.6/34.9 [2603.28052]。

          博客的 46.9% 是生产 A/B 的省钱数字，Meta-Harness 的是质量数字 —— 两者从不同指标轴

          互相佐证同一机制。

        2.3 矛盾/张力 #

        • 博客 vs Claude Code（2604.14228）：惰性文件 vs 5 层 compaction。

          • 博客把 summarization 列为三大失败模式之一（"摘要降级"会不可逆抹掉细节

          [blog-dynamic-context-discovery]），主张用可搜索的全量历史文件取代它。

          而 Claude Code 把 5 层渐进 compaction（snip → microcompact → context collapse →

          auto-compact）当成核心工程壁垒 [2604.14228]，仍以 model 生成 summary

          为最后手段。

          张力根源：两者部署约束不同。Claude Code 必须维护 append-only transcript invariant +

          prompt caching 经济学 [2604.14228]，compaction 是在已有 caching 架构

          下的不得已优化；博客则把 history 整体外置到文件，用"两级系统（窗口内摘要 + 盘上全量）"

          绕开 compaction 的有损性 [blog-dynamic-context-discovery]。

          二者在各自约束下都自洽，但博客的表述更激进（"summarization 应被视作可恢复而非最终"）。

        • 博客 vs PEEK（2605.19932）：passive 惰性取 vs active 主动维护。

          • 博客默认"agent 需要时自己去 grep/read"即可

          [blog-dynamic-context-discovery]。PEEK 的整篇论证恰恰是：对*反复查询同一

          大上下文*的工作负载，被动取不够 —— 必须主动蒸馏并常驻一个 constant-size orientation map，

          否则每次查询都要重新"认路" [2605.19932]。PEEK 还用消融指出，

          即便只是把 raw prefix 塞进 map（最接近"惰性取一段原文"）也只 +0.73%，远不如 curated

          orientation knowledge [2605.19932]。

          矛盾根源 = 工作负载假设不同：博客面向单次、任务多样的 coding session（稀疏访问，

          惰性取最优）；PEEK 面向同一 corpus 的 n 次重复查询（此时一次性蒸馏可摊销）。两者不互斥，

          而是 workload-dependent 的互补（见 §5）。

        3. 可攻击面 #

        针对博客的具体断言，逐条质疑：

        1. 46.9% 这个数字的可迁移性存疑。 博客自己承认"high variance depending on number of

          2. MCP servers installed" [blog-dynamic-context-discovery]，且证据等级仅

          MCP token 一项是 Strong，其余四项应用全是 Anecdotal/Engineering judgment

          [blog-dynamic-context-discovery]。换言之：**省的几乎全是

          MCP schema 注入这一块**，对不装 MCP 的用户该收益趋近于零。CMV 的分布数据正好印证这种

          bimodal 性质 —— 纯对话 session 缩减 <5%、只有 tool-heavy session 才有 39%

          [2602.22402]；惰性化的收益高度依赖 workload 的"膨胀来源"占比。

          1. "零新抽象"被夸大了。 博客主张 power 在于"没有新 API"

            2. [blog-dynamic-context-discovery]，但把 MCP schema、terminal、chat

            history 都同步成文件本身就是一套新的目录约定 + 同步机制。CMV 的经验显示，userland 操作

            会话日志会撞上 LLM API 的 tool_use/tool_result 严格配对约束，必须三遍扫描预收集孤儿 ID 才能

            避免 validation error [2602.22402]。博客对"惰性读一半 tool

            输出"是否会破坏这类配对不变量只字未提 —— 新失败模式并未消失，只是没被记录。

            1. 缺少 quality 维度的对照。 博客的 quality 改进全是定性

              2. [blog-dynamic-context-discovery]。而同簇论文反复警告：惰性/

              压缩取舍直接影响正确性。RLM 证明 compaction 在 dense-access 任务上崩到 0.1

              [2512.24601]；PEEK 证明"更省"未必"更准"，关键看取回的是不是 orientation

              knowledge [2605.19932]。博客只报省了多少 token，**没回答"agent 该 grep 时

              没去 grep 导致漏读关键信息"的失败率** —— 惰性加载把"该不该取"的决策推给了 model，这本身是

              新的错误来源。

              1. 对弱模型的假设未验证。 博客称 pattern "model-agnostic"

                2. [blog-dynamic-context-discovery]。但 RLM 明确发现弱 coder（Qwen3-Coder）

                随递归深度退化、syntax error 传播 [2512.24601]；让 model 自己用

                rg/jq 导航文件同样需要不弱的工具使用能力。"任何 LLM 都会用文件工具"这一前提对 frontier

                模型成立，对小模型很可能不成立。

                4. 生态位 #

                • 范式定位：博客是"context offloading"思潮的产品化拐点，不是理论首发。

                  • 把上下文外置的学术范式由 RLM 系统化（REPL 变量 + 符号递归 + metadata-only history

                  [2512.24601]）；Meta-Harness 把"文件系统 = 非 Markov 长期记忆"做成可消融的

                  研究对象 [2603.28052]。博客的独特生态位是：**剥掉所有 scaffold，只保留

                  文件系统这一最小公分母，并在真实产品里 A/B 验证**。它是把研究范式落到 frontier 编码 agent

                  harness 的"最后一公里"证据。

                • 采用证据等级：生产 A/B（最强一类）但单点。 不同于 PEEK/Meta-Harness 的多 benchmark、

                  • 多模型泛化矩阵 [2605.19932] [2603.28052]，博客只有

                  一个生产场景的统计显著结果。它的可信度来自"真实流量"，弱点是"单一指标 + 无开源复现"。

                  CMV（[实现已公开] [2602.22402]）和 RLM（公开实现

                  [2512.24601]）在可复现性上反而更强。

                • 与 Claude Code 的范式分野。 博客代表的 Cursor 路线 = "极简惰性文件 + 反 compaction"；

                  • Claude Code 代表的 Anthropic 路线 = "minimal scaffolding + 重度 compaction pipeline"

                  [2604.14228]。两者都信奉"context as scarce resource"

                  [2604.14228]，但在"满了怎么办"上分道：一个外置到盘、一个分层压缩。这是当前

                  生产级 coding agent 在 context 管理上的两条主流派系，博客是前者最清晰的宣言。

                5. 未探索方向 #

                从这一簇的交叉点看，最有价值的 hybrid / adaptive 方向：

                1. 惰性发现 × 主动 orientation cache 的混合（博客 ⊕ PEEK）。

                  2. 博客的纯被动惰性取在"反复查询同一大上下文"时会重复认路；PEEK 的主动 map 在"单次多样任务"时

                  是浪费 [2605.19932]。一个自适应策略应当：默认惰性（博客），检测到对同一

                  文件/目录的重复 grep 模式后，自动把"该上下文的 roadmap"蒸馏成一个常驻 PEEK-style map。

                  博客的文件系统正好是 PEEK Distiller 需要的 execution trajectory 来源

                  [2605.19932]。

                  1. 把惰性加载本身当成可搜索的 harness 参数（博客 ⊕ Meta-Harness）。

                    2. 博客的"哪些上下文外置、grep 的粒度多大"目前是手工调的工程判断

                    [blog-dynamic-context-discovery]。Meta-Harness 证明，把这类

                    "存什么/何时取"决策交给 coding-agent proposer 在代码空间搜索能超过手工

                    [2603.28052]。**让 Meta-Harness 直接搜索 Cursor 的 dynamic-context

                    配置**（per-server 文件夹结构、stub 阈值、何时同步 terminal）是一个现成的 end-to-end 优化对象。

                    1. 结构化裁剪 + 惰性文件的统一（博客 ⊕ CMV）。

                      2. 博客把 history 整体外置但没说"窗口内留多少摘要、盘上文件如何组织"；CMV 给出了

                      structurally-lossless 三遍裁剪 + cost model（mixed session 39% 缩减、10 轮 break-even

                      [2602.22402]）。把 CMV 的裁剪规则当成博客"两级历史系统"的盘上层格式，

                      能让博客那条定性的"summarization 可恢复"主张获得 CMV 式的量化经济学支撑。

                      1. 惰性加载的正确性基准缺失（全簇共同 gap）。

                        2. 没有一篇量化"agent 该取而没取"的漏读率。博客省 token、CMV 省钱、Meta-Harness 提质量，但

                        缺一个衡量"惰性决策错误"的 benchmark —— 即固定 harness，测 model 在"信息在盘上但需主动

                        grep"时的 recall。这是把博客 §4 那条未做的形式化（lazy policy 在 sparsity 假设下 dominate

                        eager 的证明 [blog-dynamic-context-discovery]）落到实证的前提。

                        1. MCP schema 惰性化的协议层固化。 博客在 userland 用 per-server 文件夹解决 MCP tool

                          2. explosion [blog-dynamic-context-discovery]，但这本质是 client 端补丁。

                          类比 CMV 指出的"API 松绑 tool_use 配对约束后三遍架构壁垒会消失"

                          [2602.22402]：若 MCP 协议原生支持"惰性 tool 描述 / 按需

                          schema 拉取"，博客这块收益就能标准化到所有 client，而非每家 harness 各自实现。