1M上下就好么？Claude Code的上下文设置分析

一、引论：1M 上下文窗口成为新常态

1.1 里程碑：从 200K 到 1M

2026年3月13日，Anthropic 宣布 Claude Opus 4.6 和 Sonnet 4.6 的 1M token 上下文窗口正式进入 GA（General Availability），取消了此前超过 200K 即收取约 2 倍溢价的 Beta 长上下文附加费（Anthropic 官方 Blog, 2026-03-13）[1]。这一变化使得 1M 窗口从实验性功能升级为标准能力。

同期，行业竞争加剧：DeepSeek V4 于 2026 年 4 月 24 日发布，宣布「1M 上下文将是 DeepSeek 所有官方服务的标配」[2]；GLM-5.2 于 2026 年 6 月 13 日发布，同样支持 1M token 上下文窗口[3]；Gemini 3.1 Pro 支持高达 2M token 上下文（Hozaki, Context Engineering 综述）[4]。1M 上下文窗口已从差异化卖点转变为行业准入门槛。

1.2 调研方法与数据来源

本报告综合以下来源，交叉验证所有关键论断：

学术论文：MBZUAI VILA Lab 对 Claude Code v2.1.88 源码的逆向分析论文（arXiv:2604.14228, 2026）[5]
官方文档：Anthropic Claude Code 最佳实践、会话管理博客、环境变量文档[1][6][7]
社区深度分析：LoreAI 源码分析、CSDN/掘金/腾讯云社区技术文章、开源社区实践记录[8][9][10]
基准测试与实验数据：MRCR v2 评测、Chroma Research 的 Context Rot 跨模型研究、独立开发者实测报告[11][12]
行业专家观点：Mitchell Hashimoto 的 Harness Engineering 理念、OpenAI Codex 工程实践报告[13][14]
二、Claude Code 的上下文管理机制深度解析

2.1 Harness 六层架构中的 Context 层

MBZUAI 论文对 Claude Code v2.1.88 的 ~512,000 行 TypeScript 源码分析揭示了一个核心事实：仅有 1.6% 的代码是 AI 决策逻辑，98.4% 是基础设施（Harness），而上下文管理（Context Engineering）是 Harness 中工程含量最高、最精密的部分[5]。

Claude Code 的 Harness 架构被拆分为六层，Context 层是 Layer 3，位置关键：

层级 解决的问题 关键机制
Layer 1: Loop 模型如何持续运行 ReAct 循环：调模型→执行工具→追加结果→再调模型
Layer 2: Tools 模型能做什么 5 大类内置工具 + MCP 外部工具 + 子 Agent 委托
Layer 3: Context 模型能看到什么 五层压缩、CLAUDE.md 层级、path-scoped rules、auto memory
Layer 4: Persistence 信息如何跨 Session 存活 JSONL transcript、checkpoints、memory 目录、session resume
Layer 5: Verification 如何确认结果正确 Stop hooks 阻止提前结束、/goal 持续检测、交叉验证
Layer 6: Constraints 如何防止危险操作 deny-first 权限、PreToolUse 拦截、sandbox 文件系统隔离
核心洞察：上下文窗口是 Agent 产品最稀缺的计算资源。关键不是「装不装得下」，而是「该不该装进去」。Context 层如果管理不当，即使模型推理再强，看到的信息也会越来越差，最终导致整个 Agent Loop 失效。
2.2 五层上下文压缩流水线

根据源码分析和官方文档，Claude Code 在每次调用模型前执行一套五层压缩流水线[5][8]：

层级 机制 特点 触发条件
Layer 1: Budget Reduction 对单次工具结果截断（非删除） 规则驱动，几乎零成本；原始数据保留在 JSONL 中，模型可二次读取 每次工具调用后自动执行
Layer 2: MicroCompact 按时间/白名单清理旧工具结果 规则驱动；判断 Anthropic 服务端 cache 状态，走精细/粗放路径 系统默认自动触发
Layer 3: Session Memory 提取结构化事实到文件 保留任务描述、文件列表、工作流状态、错误经验 会话进行中持续积累
Layer 4: Context Collapse 对一段对话进行摘要压缩 在窗口 90% 开始提交、95% 执行阻塞 auto-compact 触发时
Layer 5: Full LLM Compact 对整个历史进行完整总结 调用模型生成摘要，成本最高但保真度最好 接近上限或手动 /compact
2.3 自动压缩（Auto-Compact）机制详解

Claude Code 的自动压缩触发机制设计得非常精密，不是按对话轮数或 token 比例，而是基于一个工程化的绝对缓冲值[6][7]：

// 源码中的触发逻辑（autoCompact.ts）
const AUTOCOMPACT_BUFFER_TOKENS = 13_000; // 固定缓冲
const effectiveContextWindow = getEffectiveContextWindowSize(model);
const threshold = effectiveContextWindow - AUTOCOMPACT_BUFFER_TOKENS;

// 当实际使用量 ≥ threshold 时触发压缩
// 200K 窗口：约 187K 触发（约 93.5%）
// 1M 窗口： 约 987K 触发（约 98.7%）
13,000 这个数字从哪来？源码注释明确指出：这是基于模型摘要任务的 p99.99 输出长度 统计出来的——即 99.99% 的压缩摘要输出都小于 13K tokens。不是 p99，不是 p99.9，而是 p99.99。Anthropic 跑了大规模数据统计才敢把这条线定死[6]。
2.4 真实可用上下文：固定开销吃掉的部分

许多人低估了上下文窗口的固定开销[9][15]。一个看似 200K 的窗口，实际可用空间远小于这个值：

组件 200K 窗口下的消耗 1M 窗口下的消耗
系统指令 (System Prompt) ~2-3K ~2-3K
所有 Skill 描述符 ~1-5K ~1-5K
MCP Server 工具定义（每个 4-6K） ~10-42K（接 3-7 个 Server） ~10-42K
CLAUDE.md ~2-5K ~2-5K
Memory ~1-2K ~1-2K
Compact Buffer 预留 ~13K ~13K
固定开销合计 ~30-70K (15-35%) ~30-70K (3-7%)
实际动态可用 ~130-170K ~930-970K
这意味着：从 200K 升到 1M，实际可用空间不是 5 倍，而是约 6-8 倍。腾讯云 TVP 杨芳贤的实际验证数据确认了这一点：相同 Skill 配置下，Sonnet 4.6 (200K) 打开对话就用掉 25%（~50K），而 Opus 4.6 (1M) 仅用 4%——实际可用空间比约 7.8 倍[16]。

三、1M 上下文窗口的真实利弊

3.1 关键数据：模型在 1M 上下文下的实际表现

上下文窗口大小不等于模型在这个窗口上的有效使用能力。以下是关键基准测试数据[1][11]：

模型 MRCR v2 @ 256K MRCR v2 @ 1M 衰减幅度
Claude Opus 4.6 91.9% 78.3% -13.6%
Claude Sonnet 4.6 90.6% 65.1% -25.5%
GPT-5.4 ~79.3% 36.6% -42.7%
Gemini 3.1 Pro 59.1% 25.9% -33.2%
关键发现：Opus 4.6 在 1M 上下文下的 MRCR v2 得分 78.3% 是目前所有前沿模型中的最高分，且与第二名之间的差距极大（Sonnet 4.6 65.1%，GPT-5.4 36.6%）。这证实了 Anthropic 在长上下文检索方面确实拥有结构性的竞争优势。
3.2 「上下文腐烂」（Context Rot）——大窗口的双刃剑

上下文腐烂并非臆想，而是被跨模型验证的客观现象。

Chroma Research 在 2025 年测试了 18 个前沿模型（覆盖 GPT、Claude、Gemini、Qwen、Llama 全系列），得出一个无例外的结论：每个模型都随输入长度增加而持续退化，没有任何例外[11][12]。

三种并发的退化机制：

「迷失在中间」（Lost in the Middle）：Liu et al. (Stanford/TACL 2024) 发现所有模型的性能在上下文位置呈 U 型曲线——开头和结尾的信息回忆准确率高，中间部分下降 30%+。即使是专门为长上下文设计的模型也无法幸免[12]。
注意力稀释（Attention Dilution）：Transformer 自注意力是二次方复杂度。在 100K token 下，模型追踪 ~100 亿个配对关系；在 1M 下达到 ~1 万亿个。Softmax 归一化意味着每个 token 获得的注意力随窗口增大而等比稀释——这是数学结构上的根本性限制，不是训练能够解决的[12]。
干扰器效应（Distractor Interference）：Chroma 研究发现，语义相似但不相关的内容会主动误导模型，导致其生成偏离准确方向。对于编程 Agent 来说，搜索结果中大量同名函数、测试桩、mock 对象都是天然的「语义干扰器」[11]。
实践边界：虽然 Opus 4.6 的 MRCR v2 在 1M 处达到 78.3%，但 Sonnet 4.6 仅 65.1%——意味着 Pro 用户在 1M 上下文下约有 1/3 的多点检索会失败。Anthropic Claude Code 工程师 Tariq 指出，在实际使用中，上下文退化早在 300K-400K token（约 40% 容量）就开始显现，而非等到接近上限[17]。
3.3 实测证据：正面影响

来源 数据/结论
Anthropic CPO Jon Bell 1M 窗口上线后，Claude Code 自动压缩事件减少了 15%（基于真实用户使用数据）[1][16]
独立开发者实测 (Abhishek Ray, claudecodecamp) 在 50K→600K token 梯度测试中，1M 窗口对一次性大批量注入代码库有显著价值——无需分块即可让模型全局理解项目结构；但对长对话来说成本增加 3 倍[18]
腾讯云 TVP 杨芳贤 1M 上下文下实际可用空间 ~923K（92.3%），vs 200K 下 ~118K（58.8%），实际增益 ~7.8 倍[16]
DeepSeek V4 论文 (SWE-bench) 在 SWE Verified 上获得 80.6 分，团队将长上下文窗口列为 Agent 完整任务执行的关键使能因素[2]
Context Engineering 综述 (Hozaki) 2026 年 ~25% Agent 会话会触发上下文窗口压力；~70% 的会话中上下文成本超过原始模型调用成本[4]
3.4 实测证据：负面影响

来源 数据/结论
GetUnblocked 实测 Sonnet 4.5 在 1M 下多针检索（8-needle MRCR v2）准确率仅 18.5%，4/5 的检索会失败。社区反馈称 1M 窗口在 300K-400K 就开始显著退化（GitHub issue #35296）[19]
TechManiacs 深度报告 2026 年 3-4 月归因分析确认：1M 上下文下的 Prompt Cache 未命中、长空闲后的全历史重读、自动压缩丢失细粒度上下文 —— 是用户感知「Claude 变笨」的三大核心原因之一[20]
Claude Code 社区实践 200K 下 85% 触发压缩时可能卡死（耗时 16 分钟+），社区有开发者选择关闭 1M 回到 200K 以获得更可预测的表现[21]
Context Rot 综合研究 「更长的窗口不解决腐烂问题——它只是给你更多空间装满不相关的 token」——MorphLLM 对 18 个前沿模型的跨模型验证结论[11]
四、调整上下文大小对 Harness 控制能力的影响

4.1 Harness 的概念：模型提出，Harness 裁决

Mitchell Hashimoto (HashiCorp 联合创始人) 在 2026 年 2 月首次明确提出 Harness Engineering 的核心理念[13]。其公式为：

Agent = Model + Harness
模型负责推理，Harness 负责约束与执行。模型提出什么都可以，但 Harness 决定放不放行。
Claude Code 的创造者 Boris Cherny 总结了一年来的经验教训：「轨迹是朝着越来越自主的 Agent 走，而自主性只有在控制基础设施增长速度快于模型能力增长速度时才可持续。」[5]

4.2 Context 窗口增大对 Harness 各层的具体影响

Harness 层级 200K 下表现 1M 下变化 风险评估
Loop (循环) ~50-80 轮触发压缩 ~200-400 轮触发压缩，Coding Agent 可连续运行 1-2 小时不间断 正面 减少中断，提升任务连续性
Context (上下文管理) 紧凑管理，每 30 分钟压缩 压缩频次大减，但压缩触发时到达「模型智力最低点」的风险更大 临界 压缩质量决定成败
Verification (验证) 上下文较短，回溯验证较容易 长上下文中关键约束可能被稀释，增加 Goal Drift 风险 中等风险 需配合更结构化的任务追
Constraints (安全约束) 不受上下文大小影响 不受影响：Permissions 层、Sandbox 层独立于 Context 无影响
Persistence (持久化) Session Memory 正常积累 JSONL 存储增加（但本地磁盘不受影响） 低风险
Prompt Cache 缓存命中率高 长时间 idle 后的 Cache 未命中导致全历史重读是已知痛点 高风险 成本和延迟双增
4.3 核心判断：Harness 本身不会因窗口增大而失效

安全性结论：Claude Code 的 Harness 中 Constraints 层（权限控制 + 沙箱）和 Loop 层（ReAct 循环）与 Context 大小解耦——它们不直接读取模型上下文来做决策，而是通过独立于模型调用的 Hook 系统、Permission Gate 和 Sandbox 来运作。因此，将上下文窗口从 200K 调整到 1M 不会削弱 Harness 的安全控制能力。 但是，Context 层和 Verification 层确实会受到影响：更大的上下文意味着更多的信息淹没关键的验证信号和任务约束。Harness 的设计假设是「上下文越小，信号越清晰」——如果单方面增大窗口而不加强验证机制，Goal Drift（目标漂移）的风险会上升。
4.4 专家共识窗口：上下文不是越大越好

多位行业专家的观点高度一致：

Anthropic Claude Code 团队：「模型在压缩时是最不可靠的时刻——此时它被剥离了系统提示等支持性上下文，注意力完全集中在摘要本身。」因此官方建议在 1M 窗口下更需要主动、提前手动 compact，而非被动等待自动压缩[17]。
Paul Gauthier (Aider 创始人)：实际使用中模型在 ~25K-30K token 后就开始「犯糊涂」，建议的安全操作区是 窗口容量的 10-25%[12]。
Albert Sikkema (开发者实践)：主动将 Claude Code 的上下文窗口回调到 200K，并将压缩触发点从默认的 95% 降到 70%，报告长会话一致性显著提升[22]。
MorphLLM 团队：「模型已经足够了。瓶颈是你放在模型面前的内容」——上下文工程的本质不是「如何塞更多 token」，而是「如何让无关 token 远离模型」[11]。
五、调整决策矩阵：升还是不升？

5.1 决策框架

基于以上分析，是否将 Claude Code 的默认上下文窗口从 200K 调整到更大的值（如 400K、800K 或 1M），不应是简单的是/否回答。需要根据任务类型、模型选型和成本预算做三维决策。

判断维度 建议保持 200K 建议升级到 400K-800K 建议升级到 1M
任务类型 交互式日常开发、小范围重构、快速问答 跨模块重构、持续 1 小时的 Debug 会话 全仓库架构审查、一次性大批量代码注入、完整项目文档分析
使用的模型 Sonnet 4.5 及更低 Sonnet 4.6 Opus 4.6
预期会话长度 < 30 分钟 1-2 小时 数小时的持续工作，或多阶段长任务
成本敏感度 高（Pro 用户） 中等（Team 用户） 低（Enterprise / Max 用户，已包含 1M）
5.2 不推荐一刀切升级到 1M 的原因

上下文腐烂在 300K-400K 就开始：Anthropic 工程师 Tariq 明确指出，退化不会等到接近上限[17]。大窗口 = 更长的退化前时间窗口，但一旦开始退化，影响范围更大。
成本线性累积：在多次 Agent 循环中，每个 turn 都要重新处理累积的上下文。一个跑到 500K token 的会话，每个 turn 的成本大幅高于一个在 100K 时就被压缩回 ~20K 的会话。
延迟线性增长：处理 1M token 比处理 100K token 需要更多计算。对于实时交互场景（2 秒内需要看到响应），1M 并不合适[18]。
压缩陷阱：更大的窗口意味着压缩触发更晚——但触发时上下文已经积累了更多噪声，压缩质量更差。「模型在压缩时是不可靠的，但 1M 窗口下压缩来临时积压更多」[17]。
5.3 推荐：渐进式、差异化升级策略

推荐策略：不将默认窗口一刀切升级到 1M，而是采用差异化路由的方式——
日常交互式开发：保持 200K（默认值），主动 /clear 和 /compact
全仓库分析 / 架构审查：升级到 1M（一次性任务，完成即清理）
长时间 Agent 运行：设置中间值 400K-500K，配合更早触发压缩（70-75%）
这与 AgentMarketCap 2026 年 4 月分析报告的建议一致：「成熟架构应该对 有界批处理任务 使用长上下文，对 交互式查询 使用 RAG，对 跨窗口 Agent 会话 使用上下文压缩——在同一应用中路由分配。」[23]
六、配套参数调整建议

如果确定要调整上下文窗口大小（向上或向下），以下是必须配合调整的参数[6][7][24][25]：

6.1 核心参数总览

参数 默认值 推荐调整 说明
CLAUDE_CODE_AUTO_COMPACT_WINDOW 模型上下文窗口大小（200K 或 1M） 如果使用 400K-500K 中间值，设为 400000 或 500000 决定压缩计算的「有效窗口」大小。只能缩小，不能超出模型实际窗口。Anthropic 团队内部已在考虑将默认值设为 400K 以减少 Prompt Cache 未命中的损伤[6][20]
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE ~83.5%（源码内置） 如使用 1M：70-75
如使用 200K-400K：75-80 控制压缩触发的百分比。更早触发 = 更频繁但质量更高的压缩。Albert Sikkema 验证 70% 触发在长会话中一致性更好[22]
CLAUDE_CODE_DISABLE_1M_CONTEXT 未设置（1M 启用） 如使用 200K 限制：设为 1 强制关闭 1M 上下文支持。仅影响模型选择器[6][24]
CLAUDE_CODE_MAX_CONTEXT_TOKENS 模型实际限制 如有特定需求可设硬上限 强制上下文 token 上限（部分第三方接入方案使用）[25]
6.2 分场景配置建议

场景 A：保持 200K，追求稳定可靠（推荐日常开发）

{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "75"
}
}
// 效果：在 ~150K 触发压缩，留足 50K 缓冲，避免压缩失败和卡死
场景 B：使用 1M，减少压缩中断（推荐 Max/Team/Enterprise）

{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "70"
}
}
// 效果：在 ~700K 触发压缩，在退化显著恶化之前（300K-400K 之后）预留主动 compact 空间
// 配合在 CLAUDE.md 中写入压缩指引：如 "When compacting, always preserve
// the full list of modified files and any test commands"
场景 C：中庸方案，400K-500K 中间窗口

{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "400000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "75"
}
}
// 效果：有效窗口 400K（约为 200K 的 2 倍），在 ~300K 触发压缩
// 这是 Anthropic 团队内部正在考虑的方向，兼顾扩展性和可靠性
6.3 非技术参数：工作流和行为调整

上下文窗口调整固然重要，但 Anthropic 官方多次强调，真正影响 Claude Code 效率的是会话管理习惯，而非窗口大小本身[1][7]：

实践 时机 效果
/clear 勤切换会话 切换不相关任务时 O(1) 清理，比 compact 更干净
/compact 主动提前 在自动压缩触发前手动操作 可以加引导指令，控制保留内容
使用 Subagent 隔离 大规模搜索、探索代码库时 子 Agent 独立上下文，仅返回摘要
/rewind + Summarize 走错方向时回到检查点 丢弃失败路径，保留学习成果
/btw 旁路问答 临时问题不需要留在上下文中 零上下文增长
在 CLAUDE.md 中写压缩指引 项目配置 "When compacting, always preserve the full list of modified files and any test commands"
核心原则（来自 Anthropic 官方）：每当你开始一个新任务，就开启一个新会话（Start a new session for a new task）。1M 窗口虽然让你可以走得更远，但并不意味着你应该走得那么远。上下文腐烂是真实存在的，最好的防御就是不积累不相关的上下文。
七、综合结论与建议

7.1 一级结论：不需要将默认上下文窗口一刀切升级到 1M

基于交叉验证的多方证据，不建议将 Claude Code 的默认上下文窗口从 200K 直接升级到 1M。原因如下：

上下文腐烂是确定的物理现象：18 个前沿模型无一例外（Chroma Research 2025），1M 窗口下 Sonnet 4.6 的准确率从 90.6% 降到 65.1%。增加窗口不会消除腐烂——它只是推迟腐烂发生的时间，并让腐烂发生时你有更多的垃圾需要清理[11][12]。
Harness 的 Context 层设计哲学是「精选」而非「堆量」：Claude Code 的五层压缩、CLAUDE.md 四层体系、Subagent 上下文隔离——所有这些设计的出发点都是「上下文窗口是最稀缺的计算资源，关键不是装不装得下，而是该不该装进去」[5][8]。
Anthropic 团队自身也持审慎态度：团队公开表示正在考虑将默认 auto-compact 窗口从 1M 降回更小的值（如 400K），以缓解 Prompt Cache 未命中和长空闲后的全量重读问题[20]。
7.2 二级结论：差异化升级是正解

但这不等于 1M 上下文没有价值——恰恰相反，它很有价值。正确的方法是按任务类型差异化路由：

日常开发：保持 200K 默认值，主动管理会话
全仓库分析 / 架构审查 / 一次性大批量任务：临时升至 1M，完成后清理
长时间 Agent 运行：使用 400K-500K 中间值 + 更早压缩（70-75%）
7.3 对 Harness 控制能力的影响结论

调整上下文窗口大小 不会削弱 Harness 的安全控制层（Constraints/Loop），因为权限系统、沙箱和 Hook 机制与上下文大小解耦。但会 影响 Verfication 层和目标追踪的可靠性——更大的上下文意味着更嘈杂的环境，关键约束更容易被埋没。

7.4 最重要的建议

在讨论上下文窗口大小时，不要忘记 Harness Engineering 的核心教训：

「模型的推理再强，如果 Layer 3 (Context) 管理不好，它看到的信息越来越差；如果 Layer 5 (Verification) 缺失，它输出的质量无人检验；如果 Layer 6 (Constraints) 没有，它可能执行危险操作。Harness 的价值在于让每一层都稳定，模型才能在这个稳定的环境里发挥最大能力。」
—— arXiv:2604.14228, MBZUAI VILA Lab, 2026[5]
投资于上下文工程（Context Engineering）——压缩策略、Subagent 隔离、会话管理习惯——比单纯扩大上下文窗口本身的投资回报率更高。

八、参考文献与数据来源

Anthropic, "Claude's 1M Context Window Is Now Standard / GA Announcement", March 2026. claude.com/blog
DeepSeek, "DeepSeek V4 Technical Report", April 2026. SWE-bench Verified 80.6%, 1M context standard.
Z.ai, "GLM-5.2 Launch: 1M Token Context for Coding Agents", June 2026. frontiernews.ai
Hozaki, "Context Engineering: The Discipline of Getting the Right Information Into Working Memory", 2026. hozaki.com
Liu, Zhao, Shang, Shen (MBZUAI VILA Lab), "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems", arXiv:2604.14228, April 2026. arxiv.org/abs/2604.14228
Anthropic, "Claude Code Environment Variables", Official Documentation. claudecode.ac.cn/docs
Anthropic, "Best Practices for Claude Code", Official Documentation. anthropic.com/engineering
LoreAI, "拆解最强 AI Agent 的设计哲学: 512,000 行泄漏源码告诉我们 Claude Code 到底在造什么", 2026. loreai.dev
Tencent Cloud Developer Community, "细节拉满: Claude Code 上下文压缩流水线与 Prompt Cache 优化思路", 2026. developer.cloud.tencent.com.cn
掘金, "从 Claude Code 看 Harness Engineering: 2026 年 Agent 真正拉开差距的地方", 2026. juejin.cn
MorphLLM, "Context Rot: The Complete Guide to Why LLMs Degrade as Context Grows", 2026. morphllm.com
Byteiota, "Large Context Windows Lie: What AI Coding Agents Don't Tell You", 2026, citing Chroma Research (2025), Liu et al. (Stanford/TACL 2024), Paul Gauthier. byteiota.com
Mitchell Hashimoto, "My AI Adoption Journey: Harness Engineering", February 2026. Cited widely in community analysis.
OpenAI Codex Team (Ryan Lopopolo et al.), "Building Products with AI Agents: 1M Lines of Code, Zero Hand-Written", 2026.
CSDN, "你不知道的 Claude Code: 架构、治理与工程实践 — 真实上下文成本构成", 2026.
53AI, "Claude 这个更新，让模型能力提升 10%+! 200K vs 1M 实际可用空间对比", March 2026. 53ai.com
BuzzRag, "Claude's 1M Context Window Breaks at 40% Capacity — Tariq (Anthropic Claude Code Engineer)", 2026. buzzrag.com
Claude Code Camp (Abhishek Ray), "I Measured Claude's 1M Context Window. For Long Sessions, Stick to 200K.", 2026. claudecodecamp.com
GetUnblocked, "Claude Code Context Rot: Why Accuracy Drops at 200K Tokens", 2026. getunblocked.com
TechManiacs, "SPECIAL REPORT: Why Claude Has Seemed Slower, Lower-Quality, and Less Reliable", April 2026. techmaniacs.com
CSDN, "Claude Code 省钱小妙招! 200K 和自动压缩 — 社区实践记录", 2026. blog.csdn.net
Albert Sikkema, Developer practice report: capping CC at 200K with compaction at 70%. Cited in Byteiota (2026).
AgentMarketCap, "Claude Opus 4.6's 1M Context Window Is GA: The Agent Architecture Reckoning", April 2026. agentmarketcap.ai
Bingqiang Zhou, "【实践记录】Claude Code 接入第三方模型的自动压缩配置笔记", 2026. bingqiangzhou.github.io
Ling.AI / MiniMax / 火山引擎, 各平台 Claude Code 接入配置文档中的参数说明, 2026.
Diffray AI, "为什么精选上下文优于 AI 代理的上下文数量", 2026, citing Levy et al. (Hebrew University, 2025), Liu et al. (Stanford/TACL 2024). diffray.ai
搜狐, "面试官皱眉: 你知道 Claude Code 的上下文窗口管理吗", 2026, 源码级分析 auto-compact 触发逻辑. sohu.com
TurboAI, "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE: Complete Guide", 2026. turboai.dev
Verdent AI, "Claude Code: 1M Context Power — What Actually Changes for Large Codebase Work", 2026. verdent.ai
ClaudeFEST, "Claude 1M Context Window Goes GA: What Changes for Claude Code Users", March 2026. claudefa.st