Coding Agents Don’t Need Bigger Context Windows — They Need a Context Compiler
Coding Agents Don’t Need Bigger Context Windows — They Need a Context Compiler
编码智能体不需要更大的上下文窗口——它们需要一个“上下文编译器”
Agentic AI Coding Agents Don’t Need Bigger Context Windows — They Need a Context Compiler. Most coding agents waste 70% of their context window on irrelevant code. A compiler would never do that. It resolves dependencies, discards unreachable code, and keeps only the interfaces where implementation isn’t needed. Coding agents do the opposite—and it’s costing them the exact thing a shrinking context budget can’t afford to lose. AI 编码智能体不需要更大的上下文窗口——它们需要一个“上下文编译器”。大多数编码智能体将 70% 的上下文窗口浪费在无关代码上。编译器绝不会这样做。它会解析依赖关系、丢弃不可达代码,并仅保留那些不需要实现细节的接口。而编码智能体恰恰相反——这让它们付出了在日益缩减的上下文预算中无法承受的代价。
TL;DR: I built a three-pass Context Compiler in pure Python. Before sending anything to the model, it figures out what your target file actually depends on, trims non-essential code down to pure interfaces, and drops everything unreachable. Tested it on two real Python repos: it cut prompt sizes by 69–74% and ran in under 75 ms. All the numbers below are pulled straight from captured terminal runs. If the tool couldn’t determine something with certainty, it explicitly marked it instead of guessing. 简而言之:我用纯 Python 构建了一个三遍式(three-pass)上下文编译器。在将任何内容发送给模型之前,它会计算出目标文件实际依赖的内容,将非必要代码精简为纯接口,并丢弃所有不可达的代码。在两个真实的 Python 代码库上测试后,它将提示词(prompt)大小减少了 69%–74%,且运行时间不到 75 毫秒。以下所有数据均直接摘自终端运行记录。如果工具无法确定某项内容,它会明确标记出来,而不是进行猜测。
Compilers Don’t Just Compile Code
编译器不仅仅是编译代码
Compilers are just filters that know what to keep. You give one an entry point and a codebase, it traces what actually gets called, throws out the dead weight, and outputs an intermediate representation with only the detail the next step needs. Nothing extra. 编译器本质上是知道“保留什么”的过滤器。你给它一个入口点和一个代码库,它会追踪实际被调用的内容,剔除冗余部分,并输出仅包含下一步所需细节的中间表示。不多不少。
Most coding agents don’t treat prompt construction like a compiler. They build some form of repository map, gather files they believe are relevant, and send them to the model with relatively little structural reduction. Larger context windows help, but they don’t remove irrelevant context. That extra context competes for attention with the code that actually matters. 大多数编码智能体并不像编译器那样处理提示词构建。它们构建某种形式的代码库映射,收集它们认为相关的文件,并在几乎没有进行结构化精简的情况下将其发送给模型。更大的上下文窗口确实有帮助,但它们无法消除无关的上下文。这些额外的上下文会与真正重要的代码争夺模型的注意力。
And when window sizes shrink, that bloat triggers compaction. Compaction sounds like routine cleanup until it happens mid-task: the agent summarizes its own context to make room, then spends the next few turns trying to reconstruct implementation details from a lossy summary of a summary. Half the time an agent “forgets” something, it is just its own memory management degrading its recall. 当窗口大小缩减时,这种臃肿会导致“压缩”。压缩听起来像是常规清理,但如果它发生在任务执行过程中,情况就不同了:智能体为了腾出空间而总结自己的上下文,然后在接下来的几轮对话中,试图从一个“总结的总结”这种有损信息中重建实现细节。智能体“忘记”某事的一半原因,其实就是它自身的内存管理导致了召回能力的下降。
Pass 1: Symbol Resolution
第一遍:符号解析
Pass 1 answers one basic question: starting from the file you are editing, what else in the repo actually matters? It traces explicit imports first. If a call like .save() cannot be explained by an import, it falls back to checking a repo-wide symbol table, expanding outward breadth-first up to a set hop limit.
第一遍回答了一个基本问题:从你正在编辑的文件开始,代码库中还有什么真正重要的内容?它首先追踪显式导入。如果像 .save() 这样的调用无法通过导入来解释,它会退而求其次,检查整个代码库的符号表,并以广度优先的方式向外扩展,直到达到设定的跳转限制。
Two mechanisms drive this output:
- A standard module index. Every Python file maps to its importable dotted path (like app/models.py becoming app.models). Importing resolves through a fast dictionary lookup instead of guessing against the filesystem.
- A symbol map fallback. When an import does not explain a call, the compiler checks a table of every function and class definition across the repo to find where it lives. Traversing this is strictly breadth-first. Everything discovered at hop 1 gets parsed for its own calls to build the hop 2 frontier. 该输出由两种机制驱动:
- 标准模块索引。每个 Python 文件都映射到其可导入的点分路径(例如
app/models.py变为app.models)。导入通过快速字典查找来解析,而不是在文件系统中进行猜测。 - 符号映射回退。当导入无法解释某个调用时,编译器会检查代码库中每个函数和类定义的表,以找到其所在位置。遍历过程严格遵循广度优先原则。在第一跳(hop 1)中发现的所有内容都会被解析其自身的调用,以构建第二跳(hop 2)的边界。