Smart Zone：AI 编程助手的“黄金上下文区间”到底是什么

00摘要：十条核心论断

如果把这篇报告压缩成一页，只需读这十条。每条都可以被证伪，括号内标注了它主要依赖的证据类型。

01范式判定：Smart Zone 是什么，不是什么

在中文技术社区里，“smart zone”常被直接译成“智能区 / 黄金上下文区间”，并被当作模型的一个固有属性来讨论。这个用法有双重偏差：它既高估了概念的严谨性，又低估了它的实用价值。先把三个被混为一谈的含义拆开。

1.1 同一个词，三种互不相同的边界

Horthy 最初的 40% 说法，实际上是三条边界的一个粗略上界——他观察的是“什么时候开始不值得继续在这个会话里干”。把它当成模型的物理常数，是后续所有误用的根源。

1.2 概念演进时间轴

1.3 六个相邻概念的判别表

以下六个词在日常讨论中几乎被当作同义词，但它们的测量方式、责任方和修法完全不同。分不清它们，就会用错药。

1.4 一个可用的判别式

把上面这些收敛成一个可操作的判断：一个任务是否处在 smart zone，取决于两个量的比值，而不是绝对 token 数。

这个判别式的价值在于：它把“我该不该 /clear”从“我现在几 % 了”变成“我窗口里有多少东西跟当前任务无关”。后者才是可执行的。

02理论根基：为什么一定会这样

“上下文变长会变笨”不是玄学，它有明确的机制来源。理解机制的回报是：每条机制都能直接推导出一个工程动作。反过来，如果你听完一段解释仍不知道明天该改什么，那段解释就是没用的。

2.1 注意力是有限预算，不是可扩展内存

Transformer 让每个 token 与其它所有 token 建立联系，n 个 token 对应 n² 组两两关系。当上下文从 10K 涨到 100K，模型需要处理的关系数量从 1 亿涨到 100 亿。Anthropic 在《Effective context engineering for AI agents》中把这表述为一个注意力预算（attention budget）：每引入一个新 token，都会消耗掉一部分预算。这不是容量问题——容量还在，是每个 token 能分到的注意力被稀释了。

这也解释了一个反直觉的实验结果：Chroma 在 18 个模型上发现，结构连贯的文本作为“大海”时表现更差，打乱句子顺序反而更好。因为连贯的结构让无关内容看起来更有相关性，从而更有效地参与竞争那份固定预算。

2.2 位置外推带来的是“位置理解退化”，不是“记不住”

模型的长上下文能力大量依赖位置编码外推（如 RoPE 缩放 / YaRN）。这意味着超出训练分布的长度上，模型对“这个 token 排在第几位”的理解本身就是含噪的。结果是经典的首尾偏好：开头与结尾被认真处理，中间被系统性低估。这就是 Lost in the Middle（Liu et al., arXiv:2307.03172）。

关键区别：位置效应是“重排问题”，长度效应是“容量问题”。把关键约束从中间挪到结尾，不需要减少一个 token 就能拿回大部分损失；而减少总长度则要动别的手段。两者常被混为一谈，导致人们用压缩去解决本可以靠重排解决的问题。

2.3 长度本身要交税：即使完美检索、即使全部掩码

arXiv:2510.05381（EMNLP 2025 Findings）做了一组很干净的实验：在数学、问答、编程任务上，先保证所有相关信息 100% 被检索到，只改变无关内容的多少。结果性能仍随长度下降 13.9%–85%。更关键的两步：把无关 token 换成干扰极小的空白，仍至少掉 7%；把无关 token 全部掩码、强制模型只看相关 token，仍至少掉 7.9%。

2.4 训练分布里长序列更少

模型是在“短序列远多于长序列”的数据分布上训练出来的，因此针对长程依赖的专门参数更少、经验更少。这一条解释了两件工程上很常见的事：为什么长上下文能力在不同任务族上退化速度不同（检索慢、多跳快）；以及为什么厂商能把长尾段做好——它更多是训练与推理栈的工程问题，而不是不可逾越的架构墙。

03三条边界：Smart Zone 的真实形状

把第 1 节拆出的三种含义放到同一根坐标轴上，就能看出为什么“smart zone 是 40%”这句话既不算错、也几乎没用：四条不同性质的边界落在不同位置，而真正的可用区间是其中最靠左的那一条决定的。

3.1 四条边界各自的依据与强度

3.2 为什么经济边界常常最先到期

工程讨论通常只盯准确率，但还有两个机制会提前把可用区间压窄，而且它们的作用是乘法的：

• 每轮重发整个上下文。第 20 轮时你发送的不是第 20 轮的内容，而是一到二十轮的全部内容。100K 的会话在第 20 轮意味着 100K×20 的输入计费。窗口越大，这个乘数越贵。
• KV-cache 把“稳定前缀”变成硬约束。Manus 团队的实测口径：缓存命中 $0.30 / MTok，未命中 $3.00 / MTok，而 agent 负载的输入输出比约 100:1。系统提示里加一个时间戳就会让整个前缀失效——这是纯粹的成本事故，与模型聪明程度无关。
• 延迟随输入线性增长。OpenAI 在 GPT-4.1 发布时给出的数据：128K 上下文下首 token 约 15 秒，1M 上下文下约 1 分钟。agent 的每一步都要等这个延迟，多步任务里它会复利成“不可用”。

04证据全景（一）：单次推理层的有效上下文

这一节回答一个模型层面的问题：宣称的窗口，有多少是真正能用的？四组研究给出的答案高度一致——多数模型的有效上下文只有标称的一半甚至更少，而且这个折扣无法通过“把检索做得更好”来抹平。

4.1 RULER：第一个把“有效长度”变成数字的基准

NVIDIA 的 RULER（arXiv:2404.06654，COLM 2024）用 13 个合成任务覆盖四类能力——检索、多跳追踪、聚合、长文档问答，长度 4K 到 128K，每个长度 500 个样本。它定义一个模型在某个长度上“达标”的门槛是 Llama-2-7B 在 4K 时达到的 85.6%，然后把“仍能达标的最长长度”称为有效上下文长度。

结果是：在被评估的 17 个宣称 32K 以上窗口的模型中，只有 4 个在 32K 上仍维持达标水平。有效长度普遍落在标称值的 1/2 到 1/4 之间。

4.2 NoLiMa：把“字面匹配”这根拐杖拿走之后

RULER 之后最有力的推进来自 Adobe Research 与 LMU 慕尼黑合作的 NoLiMa（arXiv:2502.05167，ICML 2025）。它指出 NIAH 类测试的一个致命漏洞：问题与“针”之间存在字面重合，模型其实可以靠关键词匹配过关。NoLiMa 重新设计了针集，让问题与针几乎不共享词汇，必须依赖潜在关联（例如问“哪个角色去过赫尔辛基”，而针是“Yuki 住在 Kiasma 博物馆附近”——你得知道 Kiasma 在赫尔辛基）。

公平起见的另一面：Chroma 在《Context Rot》中对 NoLiMa 提出了方法论质疑——NoLiMa 中约 72.4% 的问题-针对需要外部世界知识，因此它实际测的是“检索 + 外部知识推理”两个任务，而不是纯粹的语义检索。这个批评成立。但结论方向未被推翻：一旦取消字面匹配的便利，退化会早得多、陡得多。

4.3 Chroma《Context Rot》：长度本身、干扰项与结构

2025 年 7 月，Chroma 的 Kelly Hong、Anton Troynikov、Jeff Huber 发布了 18 个模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3）的受控实验，方法是固定任务复杂度、只改变输入长度，从而把“长度效应”与“任务变难”分离开。主要发现：

需要标注的利益相关：Chroma 是向量数据库厂商，其商业利益与“检索优于全量塞入”的结论一致。但该报告公开了完整实验代码、采用固定复杂度对照设计，且结论与 NoLiMa、RULER 相互独立地指向同一方向，因此仍按受控实验使用。全实验的拒绝率仅 0.035%（194,480 次调用中 69 次），说明这不是“模型不配合”造成的伪像。

4.4 决定性的一组实验：即使完美检索，长度仍然伤害性能

arXiv:2510.05381（EMNLP 2025 Findings）是这条证据链上最干净的一环。作者在 5 个开源与闭源模型、数学 / 问答 / 编程三类任务上，先保证相关信息 100% 被检索到，然后只改变无关内容的数量。三档对照：

作者给出的缓解手段也很朴素：让模型先复述检索到的证据，再解题，把长上下文任务改造成短上下文任务——在 RULER 上让 GPT-4o 提升约 4 个百分点。这与 Manus 的 “recitation” 实践（不断重写 todo.md 把目标推回注意力热点）在原理上是同一件事。

05证据全景（二）：Agent 层的有效上下文

上一节测的是“一次调用能处理多长输入”。但编程助手不是一次调用，它是一个循环：探索、读文件、跑命令、看报错、再改。这个循环里的上下文是自己长出来的。2026 年出现的第一个可控基准，给出的答案比单次推理层更悲观。

5.1 LOCA-bench：把“环境变大”与“任务变难”分开

HKUST 的 LOCA-bench（arXiv:2602.07962，Zeng / Huang / He）解决了长期困扰这个领域的一个混淆：在真实 agent 任务里，上下文变长往往也意味着任务变难，因此无法判断退化来自长度还是难度。它的做法是自动放大环境状态、同时保持任务语义完全不变——例如把待处理的邮件、表格、数据库记录成倍增加，但“把 A 表按 B 规则汇总”这个指令一个字都不改。

方法细节：15 个种子任务（改编自 Toolathlon），280 个工具，7 档环境描述长度（8K / 16K / 32K / 64K / 96K / 128K / 256K），每档 5 个随机种子，共 525 个样本，统一使用 ReAct scaffold，模型在各自最大上下文内运行。

5.2 与 40% 规则的正面对账

把 LOCA-bench 的数字换算成窗口占比，就能直接检验 40% 规则：

结论有两层：

• 对绝对长度而言，拐点在 32K 附近——这比 40% 规则（200K 窗口下的 80K）早了将近三分之二。
• 对窗口占比而言，40% 反而过于乐观。Gemini-3-Flash 的拐点只占其标称窗口的 3%；Claude-4.5-Opus 也只占 16%。换句话说，40% 规则在“大窗口模型”上是完全失效的——它把标称容量当成了分母。

5.3 轨迹本身的行为变化：模型不只是变笨，还变得不愿探索

LOCA-bench 记录的不只是准确率，还有轨迹长度、工具调用次数与工具输出量。一个重要发现是：随着环境变大，这些量先上升、然后趋于平台。作者的解释是——面对过长的上下文，模型会减少探索。这正好与 context anxiety 的机制吻合：不是能力不够，是行为收窄。论文归纳出四类被长上下文放大的失败模式：

论文还测试了六种上下文工程策略在同一环境（128K）下的效果：工具结果清除、思考块清除、上下文压缩、上下文感知（实时告知余量）、记忆工具、程序化工具调用（让 agent 写代码来编排工具，只把最终结果返回给模型）。结论是：程序化工具调用效果最稳定、最显著，同时缩短轨迹长度；而记忆工具与上下文感知对 Gemini-3-Flash、GPT-5.2-Medium 有帮助，却反而伤害了 DeepSeek-V3.2-Thinking。这是一个很实用的警告：上下文工程手段不是通用药，对部分模型会有负作用，必须实测。

论文自陈的局限：任务域仅限电商与教育场景；策略是规则式的；只测到 256K；环境描述中包含较多脚手架，绝对数值可能偏悲观。作者认为模型间的相对排序仍可信，因为造成退化的机制（位置偏置、注意力稀释、softmax 锐化）是架构级的、所有模型共享。

5.4 真实编程任务的轨迹有多长？

arXiv:2602.16069《The Limits of Long-Context Reasoning in Automated Bug Fixing》提供了一个很实用的对照数据。作者统计了在 SWE-bench Verified 上运行 agent 的完整对话长度：

5.5 多智能体的上下文经济学

Anthropic 在多智能体研究系统的复盘中给出了一组常被引用的成本比例（经二次来源转述）：单智能体消耗约为普通对话的 4 倍，多智能体约为 15 倍；并且在 BrowseComp 评测中，token 使用量解释了约 80% 的性能方差，工具调用次数与模型选择是额外因素。

这组数字的含义是双面的：它说明长任务的上限确实与“能消耗多少上下文”强相关，因此 subagent 隔离不只是省钱手段，也是能力手段；同时它也说明，多智能体是一种昂贵的能力购买，只在任务价值足以覆盖 15 倍成本时才成立。

06模型横评：2026 年的衰减曲线有多陡、差多少

这一节只用厂商官方发布的评测数据（OpenAI、Anthropic、Google DeepMind 的模型页与模型卡）与同行评议论文数据，不用聚合站的二手整理。原因很简单：长上下文这个指标上，二手数据的偏差极大——同一个模型在不同来源里的“有效上下文”可以差一倍以上。

6.1 MRCR v2 8-needle：目前最接近“长上下文推理”的公开标准

MRCR（Multi-Round Coreference Resolution）最初来自 Google DeepMind 的 Michelangelo 评测套件，OpenAI 在 2025 年 4 月把它公开化：在长合成对话中插入多个近乎相同的请求（2 / 4 / 8 个），要求模型取回“第 3 首关于貘的诗”这种需要区分同形项的结果。它比大海捞针难得多——因为所有针都是同一个模型写的，彼此高度相似，靠关键词匹配无法区分。它测的是检索 + 实体区分 + 序列定位，接近“在 500K 行的 PR 里找第 4 版实现”这种真实需求。

6.2 分桶原始数据

数值单位皆为百分比。GPT-5.4 / GPT-5.5 数据来自 OpenAI 官方模型页；Gemini 3.1 Pro 的 128K（84.9%）与 1M（26.3%）来自 Google DeepMind 的 Gemini 3.1 Pro 模型卡。注意 Gemini 的一行里，1M 分数与它的前一代 Gemini 3 Pro 完全相同（26.3%）——这一代在长上下文检索上没有改进。

6.3 同代内部的差距，比跨代差距更大

Anthropic 在 2026 年 2 月发布 Claude Opus 4.6 时给出了一个很有说服力的对照：在 MRCR v2 的 8-needle 1M 变体上，Opus 4.6 得 76%，而同一家族的 Sonnet 4.5 只有 18.5%。Anthropic 的表述是这代表了“模型实际可用上下文长度的一次质变”。

这句话值得认真对待。它说明“1M 窗口”这个规格本身早已不是区分度——真正的区分度是在 1M 处还能不能干活。同一个产品线内的两个模型在这项指标上相差 4 倍，意味着任何按“窗口大小”做的选型都是无效的。

另外一个值得注意的信号是：Anthropic 在 Opus 4.6 上明确把 context compaction 写进了评测方法——Humanity's Last Exam 的测试中压缩在 50K token 处触发、累计跑到 3M；BrowseComp 中同样 50K 触发、累计跑到 10M。这等于厂商自己在承认：“长上下文能力”的正确形态是“压缩 + 长任务的组合能力”，而不是一次性塞入的能力。

6.4 SWE-bench Verified 已经饱和，长上下文鲁棒性正在接棒成为区分维度

2026 年 4 月的 SWE-bench Verified 榜单前五名：Claude Opus 4.5（80.9%）、Claude Opus 4.6（80.8%）、Gemini 3.1 Pro（80.6%）、MiniMax M2.5（80.2%）、GPT-5.2（80.0%）。前五名相差不到一个百分点，排名会随脚手架选择而月度重排。

与此同时，同一批模型在长上下文指标上差异巨大：Gemini 3.1 Pro 的 SWE-bench Verified 是 80.6%，与 Opus 4.6 几乎持平；但它在 MRCR v2 的 1M 上是 26.3%，远低于 Opus 4.6 的 76%。短任务能力趋同、长任务能力分化——这正是“smart zone”在 2026 年重新变得重要的原因。

SWE-bench 与 Terminal-Bench 数据来自各厂商发布材料与榜单聚合；跨厂商比较存在脚手架差异，仅用于说明“短任务趋同”。Terminal-Bench 2.0 与 SWE-bench 的难度、口径不同，不可横向互推。

07Harness 横评：七个编程助手怎么处理同一个问题

“模型能力”只是上限的一半。同一个模型放进不同 harness（脚手架），长任务表现可以差出数倍。这一节对比各主流 agent 的上下文机制——重点不是谁做得更好，而是它们对“上下文为什么会坏”给出了四种互不兼容的诊断，且都能跑通。

7.1 机制对比表

Claude Code、Cursor、Cline 的部分机制来自各自官方文档与官方博客；Codex、OpenCode、Amp 的细节来自一份六家横评的技术分析（二手转述，未获官方文档逐一验证），已按“参考”而非“事实”对待。

7.2 四种互相不兼容的诊断

把这些机制放回第 1 节的三条边界，可以看出它们其实是在治不同的病：

7.3 Anthropic 自己承认的一件事：Harness 会过期

这是本报告里最重要的一条组织性教训，来自 Anthropic 的工程博客《Scaling Managed Agents》与《Harness design for long-running application development》：

他们由此提出的架构解法是把“brain”（模型 + harness）与“hands”（沙箱与工具）以及 session（append-only 事件日志）解耦：上下文窗口是 session 日志的一个视图，而不是日志本身。这样压缩策略可以放在平台层，模型改进时不必重写 harness。

对自建 agent 产品的团队，这条教训可以直接翻译成一个工程要求：把“为当前模型缺陷打的补丁”显式登记成一份清单，并在每次换模型时逐条复验。不登记，它们就会变成没人敢删的死代码，并且持续拖慢系统。

7.4 从七家里提炼出的六条共识

08上下文预算解剖：token 到底被谁吃掉了

前面的证据说明“不能用满”。这一节回答“那到底花在哪了”。结论有点出人意料：在一次正常的编程会话里，聊天内容几乎不占预算，真正的开销是启动固定值、文件读取和工具 schema。

8.1 进入对话之前就已经花掉的部分

Anthropic 在 Claude Code 文档里放了一个可交互的上下文窗口模拟器，给出了一份“代表性会话”的 token 成本（官方标注为示意值）。它在设计上有两个用途：让你知道启动阶段并非免费；以及让你意识到——一个调试细节的代价，可能等于一整套工具链的启动成本。

把启动开销放回整场会话，官方同一份材料给出的比例是：

这三行数字加起来就能推出大部分“最佳实践”。既然聊天只占 1%，那么“少说两句”几乎没有收益；而“少读 3 个无关文件”能省下接近 25% 的预算。“用 @path 直接给文件，而不是让模型自己找”之所以有效，是因为它把“可能读 10 个文件”变成“确定读 2 个”。

8.2 MCP 税：从 1.6% 到 80%，它是设计变量而不是常数

工具定义（JSON schema）会被注入上下文，且与你是否调用它无关。围绕它流传着一批差异极大的数字。把它们并列之后你会发现：区间之宽本身就是结论。

关于成本量级，还有两个可直接采用的估算：简单工具约 300–400 token，复杂工具约 800–1,200 token；主流生态里开发者平均连接 4–7 个 MCP server。用这两个数乘一下，就能在接入任何 MCP 之前先算清楚代价。

8.3 一个可执行的 200K 预算模板

把上面所有约束落在同一张表上。注意最后一行的“余量”不是浪费——它同时服务三件事：真实的能力缓冲、context anxiety 的安抚、以及出错时的回旋空间。

09最佳实践：三层可执行清单

前面的证据都指向同一个动作序列：先删无用的，再隔离探索，然后才压缩，最后才考虑换模型。下面按“个人日常 / 团队工程 / Agent 产品”分三层给出具体动作，每一条都能追溯到前文的一条证据。

9.1 先给一个决策树

9.2 个人日常（10 条）

9.3 团队工程（8 条）

9.4 Agent 产品（7 条）

9.5 成熟度阶梯

9.6 30 / 60 / 90 天落地路线

10反模式清单

每一条都对应前文的一条证据。分三层：战略层决定方向，工程层决定日常效率，治理层决定这套东西能不能活过下一次模型换代。

10.1 战略层

10.2 工程层

10.3 治理层

11结论与判断

以下内容中，凡是标注为“判断”的，是本报告基于前述证据的推论，不是行业共识，也不来自任何单一来源。

11.1 三个可以确定的结论

11.2 四条判断（非共识）

11.3 尚未解决的问题（本报告未能回答）

11.4 给三类角色的最短建议

12参考来源

按证据类型分组。本报告的原则是：中文二手转述只用于线索发现，所有引用数据回溯一手来源；引用前做数量级反推自洽性检查。

A · 同行评议论文与预印本（一手研究）

1. Liu, N. F. et al. Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172（TACL）。位置效应的原始来源。
2. Hsieh, C.-P. et al. RULER: What's the Real Context Size of Your Long-Context Language Models? arXiv:2404.06654（COLM 2024，NVIDIA）。有效上下文长度指标的提出者。
3. Modarressi, A. et al. NoLiMa: Long-Context Evaluation Beyond Literal Matching. arXiv:2502.05167；ICML 2025，PMLR 267:44554–44570（Adobe Research / LMU 慕尼黑）。13 个模型中 11 个在 32K 跌破基线 50%。
4. Du, Y. et al. Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. arXiv:2510.05381（EMNLP 2025 Findings）。完美检索下仍退化 13.9%–85%；掩码后仍 ≥7.9%；recitation 缓解方案。
5. Igbinedion, I., Ross, J., Ricardez, E., Karaman, S., So, E. Lost in Context: Addressing Context Anxiety in Large Language Models. arXiv:2607.21616（ICML 2026，MIT）。首次系统测量 context anxiety：token 估计偏差 24%、准确率 −15%、token 消耗 +54%；SFT 可降低焦虑 >50%。
6. Zeng, W., Huang, Y., He, J. LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth. arXiv:2602.07962（HKUST）。本报告第 5 节的核心数据源，525 个样本、7 档长度、280 个工具。
7. The Limits of Long-Context Reasoning in Automated Bug Fixing. arXiv:2602.16069。SWE-bench 轨迹长度统计（普遍 <20–30K）与 64K 完美检索下的近零解决率。
8. The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason. arXiv:2506.12286。用于说明 SWE-bench 结果的解释边界。

B · 厂商一手工程文档与官方评测

9. Anthropic. Effective context engineering for AI agents（2025-09-29）。注意力预算、context rot 的框架来源；compaction / 结构化笔记 / subagent 三技术；子智能体返回 1,000–2,000 token 摘要。
10. Anthropic. Effective harnesses for long-running agents。initializer agent + coding agent、进度文件、干净状态。
11. Anthropic. Harness design for long-running application development。context reset 的引入与移除；三智能体 harness（planner / generator / evaluator）。
12. Anthropic. Scaling Managed Agents: Decoupling the brain from the hands。“harness 假设会过期”；session 作为 append-only 日志与上下文的视图关系。
13. Anthropic. Claude Opus 4.6 发布公告。1M token 窗口（beta）、MRCR v2 8-needle 1M = 76%（Sonnet 4.5 为 18.5%）、context compaction（beta）、adaptive thinking、四档 effort、对 >200K 提示的溢价定价（$10 / $37.50）；compaction 在 HLE 于 50K 触发累计 3M、BrowseComp 累计 10M。
14. Anthropic. Claude Code 官方文档：Best practices（两次纠正规则、/clear、/compact 焦点、subagent、rewind 检查点、常见失败模式）；Explore the context window（启动开销示意值、压缩生存表、/autocompact 窗口）；Claude Code on the web（云端自动压缩在窗口中点触发）。
15. OpenAI. Introducing GPT-4.1 in the API。MRCR 与 Graphwalks 的公开化；首 token 延迟数据（128K ≈ 15 秒，1M ≈ 1 分钟）。
16. OpenAI. Introducing GPT-5.4。MRCR v2 8-needle 完整分桶成绩；Graphwalks BFS / parents 分档。
17. OpenAI. Introducing GPT-5.5。MRCR v2 8-needle 分桶（512K–1M = 74.0%）；Graphwalks；跨模型对照（含 Claude Opus 4.7、Gemini 3.1 Pro 部分档位）。
18. Google DeepMind. Gemini 3.1 Pro Model Card。1M 输入 / 64K 输出；MRCR v2（128K）= 84.9%，MRCR v2（1M）= 26.3%（与前代完全相同）；SWE-bench Verified 80.6%；Terminal-Bench 2.0 68.5%。
19. Cursor. Dynamic context discovery（官方博客）。长工具响应文件化、聊天记录作为文件、MCP 工具描述同步至文件夹、终端会话文件化；A/B 测试中调用 MCP 的运行总 token 消耗 −46.9%（统计显著，随已安装 MCP 数量波动）。
20. Cursor. Changelog — Context usage report in canvas（2026-06-03）。Context Explorer 的 token 细分与 “Debug with Agent”。
21. Cline. SDK 文档 — Context Compaction & Turn Management。basic / agentic 两种压缩策略、utilizationRatio 触发、默认 128K、手动目标比例 0.5。
22. GitHub Copilot CLI 文档 — Context and Conversations。/context、/compact、/clear、/usage 的三类 token 分解；128K 限制。
23. Peak Ji（Manus）. Context Engineering for AI Agents: Lessons from Building Manus。KV-cache 优先、append-only、mask 而非移除、文件系统作为上下文、todo 复述、保留错误、避免 few-shot 化；缓存与未缓存成本差 10 倍、输入输出比约 100:1。

C · 独立研究与行业分析

25. Chroma Research（Kelly Hong, Anton Troynikov, Jeff Huber）. Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025-07）。18 个模型、五类受控实验；结构连贯性反而损害性能；Claude 保守 / GPT 高幻觉。注意：Chroma 为向量数据库厂商，结论与其商业利益方向一致，但实验设计公开可复现。
26. Dex Horthy（HumanLayer）. No Vibes Allowed: Solving Hard Problems in Complex Codebases（AI Engineer World's Fair 2025）。smart zone / dumb zone 的原始出处；约 40% 的经验阈值；RPI 工作流；frequent intentional compaction。同作者 2025 年 4 月《12-Factor Agents》为 “context engineering” 一词的出处。
27. 跨厂商 agent 上下文压缩策略横评（腾讯云开发者社区 / 腾讯新闻，2026-06）。用于 Codex CLI、Amp、OpenCode、Cline 的机制细节与三条共识原则。二手转述，未逐条获得官方文档验证
28. LOCA-bench 的第三方解读（用于交叉核对论文 Table 1/2 数值与失败模式归纳）。二手转述

D · 明确不采信的数据

29. “Horthy 分析了 10 万+ 开发者会话得出 40% 拐点”。无任何一手材料支持。该表述见于多个上下文状态栏插件的说明页；数量级疑为与 DORA 类大型行业调查混淆。本报告全程按“经验法则”处理。
30. 聚合站的“有效上下文百分比”表格。例如“GPT-5.5 可用 512K（50%）”“Claude Opus 4.6 可用 500K”“Gemini 3.1 Pro 可用 128K（13%）”。这些表格未说明基准、阈值、needle 数量与位置分布，且不同站点互相矛盾。仅可作为调研线索。
31. “F1 下降约 45%”“幻觉率飙升至 40%”类数字。出现在部分上下文状态栏工具的说明页中，无出处，不采用。
32. 单一开发者自报的极端案例（如工具 schema 占窗口 80%、账单从 $387 降到 $180）。作为现象存在性证据引用，不作为量级依据。

E · 数据冲突与不确定项（供后续核验）