为什么精选上下文优于
AI代理的上下文数量
研究证明：精准检索配合代理式上下文收集显著优于大量上下文加载
证据确凿：向AI模型加载更多上下文实际上会损害性能。斯坦福大学、Anthropic的研究以及领先AI编码工具的生产数据表明，模型在大约25-30k个token时开始出现问题——远低于声称的上下文窗口大小。
制胜方法是将精准检索与代理式上下文收集相结合，让AI自己决定需要什么信息。这份研究汇编提供了具体统计数据、引用结果和具体示例，证明对于代码审查和其他AI编码任务，更少但高度相关的文档比大量上下文转储高出10-20%，而代理式检索方法相比静态上下文注入实现了7倍的改进。
"中间迷失"问题削弱了大型上下文窗口
2024年的里程碑论文《Lost in the Middle: How Language Models Use Long Contexts》（刘等人著，斯坦福/加州大学伯克利分校，发表于TACL）揭示了LLM处理长上下文方式的根本缺陷。研究人员发现，当相关信息出现在长上下文的中间位置时，性能显著下降——即使是专门为扩展上下文设计的模型也是如此。
该论文记录了所有测试模型（包括GPT-4和Claude）的典型U形性能曲线。当关键信息位于上下文的开头或结尾时，模型表现良好，但对于位于中间的信息，准确性明显下降。作者表示：
"向模型提供更长的输入上下文是一种权衡：提供更多信息可能有助于模型执行后续任务，但这也增加了模型必须推理的内容量。"
Chroma Research在2025年的"上下文衰减"研究扩展了这些发现，测试了18个LLM进行了数千次实验。他们的结论是："在所有实验中，模型性能随输入长度的增加而持续下降。模型并不均匀地使用其上下文；相反，随着输入长度的增加，其性能变得越来越不可靠。"
这不是微不足道的影响——IBM Research的崔晓东总结道："我们已经证明，示例的质量很重要。换句话说，无限扩大上下文窗口在某个点上可能会适得其反。"
相同token数量下更少的文档显著提高准确性
也许最引人注目的证据来自希伯来大学的研究《More Documents, Same Length》（Levy等人，2025年），该研究在保持总上下文长度不变的情况下，隔离了文档数量的影响。通过在减少文档数量的同时扩展剩余文档，他们消除了上下文长度这一混淆变量。
10-20%
在保持相同总token数的情况下，减少文档数量带来的性能提升
结果明确无误：在保持相同总token数的情况下减少文档数量，在MuSiQue上提高了5-10%的性能，在2WikiMultiHopQA上提高了10-20%。添加更多文档导致高达20%的性能下降——尽管模型接收的文本量相同。
研究人员得出结论："LLM在处理大量文档时遇到困难，即使总上下文长度保持不变。这可能与处理多个文档的独特复杂性有关，涉及处理分布在多个来源的信息，这可能引入冲突或重叠的细节。"
生产环境AI编码工具发现约25k token的上限
Aider（流行的开源AI编码工具）的创建者Paul Gauthier提供了来自实践者的直接证据：
"根据我在AI编码方面的经验，非常大的上下文窗口在实践中是无用的。当你给它超过约25-30k个token时，每个模型似乎都会迷失。模型停止遵循系统提示，无法正确找到/转录上下文中的代码片段等。"
他指出，这"可能是AI编码助手用户面临的头号问题"。
Cursor研究团队通过A/B测试量化了选择性检索的价值。他们的语义搜索系统在问答任务中实现了12.5%更高的准确率（根据模型不同，从6.5%到23.5%不等），代码更改更有可能在代码库中被保留。
在拥有1000+文件的大型代码库中，使用语义搜索后代码保留率提高了+2.6%，而禁用它会使用户不满意请求增加2.2%。Cursor团队强调："语义搜索目前对于实现最佳结果是必要的，尤其是在大型代码库中。我们的代理在语义搜索的同时积极使用grep，两者的组合产生最佳结果。"
代理式检索比静态上下文注入高出7-21倍
从静态RAG到"代理式RAG"的新兴范式转变展示了显著的性能改进。传统RAG有根本性的局限性：它是"一次性解决方案，意味着上下文只检索一次。没有对检索上下文质量的推理或验证"，而且它总是"检索相同数量的top-k块，无论查询复杂性或用户意图如何"。
代理式方法将自主代理集成到检索管道中，使用四种设计模式：反思、规划、工具使用和多代理交互。主导模式是ReAct（推理+行动），它在思考 → 行动 → 观察的迭代循环中工作。
ReAct循环架构：
- 生成推理步骤
- 决定行动
- 执行工具
- 基于观察更新上下文
性能提升是实质性的：
+21百分点
IRCoT在多跳推理上的检索改进
7倍
Devin相比静态检索在SWE-bench上的改进
91%
Reflexion pass@1 vs GPT-4在HumanEval上的80%
代码审查清晰展示了精确度与召回率的权衡
特别是对于AI代码审查，证据明确支持精确度而非召回率。多项研究报告称，优化召回率的工具有60-80%的误报率，并且40%的AI代码审查警报被忽略，原因是警报疲劳。
失败模式已有详细记录。最初的实现通常具有极高的误报/正报比率，"没有考虑更改行之外的上下文"。优化后，领先工具通过专注于高置信度建议，将此大幅降低，达到5-8%的预期误报率。
一项分析了22,000多条AI代码审查评论的大规模研究发现：
- 3倍简洁的评论更有可能被采纳执行
- 更优代码块级别的工具（专注于特定代码片段）优于文件级别的工具
- 更高手动触发的审查比自动推送的审查具有更高的接受率
代码审查的实用上下文层次结构
根据研究，代码审查的上下文类型按价值排序：
核心上下文
- diff本身及其周围代码
- 编码在配置文件中的编码标准
- 与任务关联的PR描述——揭示意图而非仅是更改
高价值上下文
- 相关文件（导入、测试、依赖项），通过代码图分析构建
- 以前的PR/提交历史用于模式识别
情境上下文
- Git blame用于代码所有权模式
- 来自集成工具（如Notion或Linear）的项目文档
多代理架构：精选上下文的实践
实现精选上下文最有效的方法之一是多代理架构。不是将所有内容传递给单一模型，而是让专门的代理各自专注于自己的领域——安全、性能、架构、缺陷——配合它们所需的精确上下文。
这种方法自然地解决了上下文量的问题：安全代理不需要性能基准，缺陷检测代理不需要代码风格文档。每个代理都获得针对其特定任务优化的专注、精选的上下文窗口。
在diffray，我们基于这一原则构建了我们的代码审查平台。我们的多代理系统已在生产中证明了其有效性，与基于单代理的方法相比，实现了显著更低的误报率和更高的开发者接受度。
了解更多关于我们的多代理架构 →结论：有效上下文的三个原则
研究汇聚于AI代理上下文管理的三个原则：
1. 精选时，少即是多
希伯来大学的研究证明，即使在token数量相同的情况下，更少的高质量文档也比多个片段高出10-20%。模型在综合分布在多个来源的信息时遇到困难——整合改善了推理。
2. 位置和结构与内容同样重要
"中间迷失"现象意味着关键信息应该出现在上下文的开头或结尾。对于代码审查，这意味着优先考虑diff和编码标准，而不是详尽的历史上下文。
3. 自行收集上下文的代理优于静态注入
从一次性RAG到代理式检索的转变——具有迭代推理、工具使用和自我评估——在复杂编码任务上产生了7倍以上的改进。当代理能够决定"我需要查看这个函数的测试文件"并获取它时，结果上下文本质上比任何预计算的检索更相关。
对于像diffray.ai这样的代码审查工具，这些发现建议了最佳架构：一个选择性检索系统，仅为每个特定更改获取最相关的上下文，结合代理能力，让审查者根据需要探索相关代码——将上下文视为需要预算的有限资源，而不是要最大化的转储。