100万上下文只是噱头，你也不需要“上下文压缩”！

实施阶段需新开会话

本文基于Matt Pocock系列skills在AI Coding中的实践启发，描述的上下文管理现象脱离mattpocock/skills依然适用。其常用工作流程为：grill-with-docs -> to-spec -> to-tickets -> implement。在将需求写成方案（Plan/Spec）并拆成执行工作票（Tickets）后，下一步是实施（Implement）。关键步骤是：每个Ticket实施时，按推荐最好新开会话、按顺序逐个实施（依赖允许时可并行）。

Matt Pocock工作流示意图

LLM存在“愚蠢区间”

目前业界普遍认为，LLM处理长文本时存在显著的“愚蠢区间”，尤其在复杂逻辑、多步推理任务中，智力表现明显下降。这是因为LLM对信息的关注度呈U型分布：开头和结尾记忆最牢，中间部分准确率最低。

准确率 (Accuracy) 100% |  \                             /      |   \                           /      |    \                         /      |     \                       /      |      \______________________/  0% +-------------------------------------------> 文本位置    开头 (0%)                 中间 (50%)         结尾 (100%) (开头：记忆深刻)           (中间：彻底遗忘)      (最后：记忆清晰)

该现象最早由斯坦福大学、加州大学伯克利分校等机构学者在2023年论文《Lost in the Middle: How Language Models Use Long Context》中提出，揭示LLM提取和使用信息的能力取决于信息在文本中的位置。原文链接：https://arxiv.org/abs/2307.03172

LLM注意力分布示意图

在真实开发场景中，开头Token通常包含系统提示词、skills、AGENTS.md及部分项目上下文，结尾才是具体需求。许多Agent工作环境在开头就占满上下文，例如安装过多Skills、MCP或配置复杂AGENTS.md（CLAUDE.md）。目前难以消除“愚蠢区间”，这可能是Transformer架构注意力机制的固有缺陷，但可通过避免让关键信息落入该区间来规避。

150K是黄金推理区间

Matt Pocock基于真实编程工作流提出双区模型：

• 聪明区（SMART ZONE）：上下文约100K，LLM推理能力最强，代码生成与指令遵循处于最佳状态；
• 愚蠢区（DUMB ZONE）：上下文超过临界点，幻觉激增、遗漏指令、胡说八道。

随着LLM能力增强，该区间可适当放宽至150K甚至更高，但最高不宜超过上下文总长度的40%左右。AI大神Karpathy类比称：LLM上下文如同计算机内存，把全部硬盘数据塞进内存后果可想而知。

“大模型在面对长上下文时的表现，就像一个在考试前一天晚上临时抱佛脚（Cramming for an exam）的差生。你能够牢牢记住你复习的前几章（开头）和最后看的几章（结尾），但是夹在中间那 3 个小时复习的内容全都变成了浆糊（turn to mush）。”

厂商常以“大海捞针”测试说明LLM长上下文能力（如Anthropic），但AI编程属复杂多步推理任务，非简单检索任务。长上下文中做搜索式检索或可行，但不适用于多步推理。

必须做上下文减法

许多人给Agent装入大量Skills、MCP、插件，并撰写数百行AGENTS.md，导致LLM开口第一句即超100K，直接进入“愚蠢区间”。随着模型能力提升，过多Prompt反而成为污染与束缚——Anthropic发布Opus5、Fable5等新模型时，官方Claude Code工具移除80%系统提示词，性能反获提升。

你需要做减法：

• 重新审视安装的Skills、MCP等插件，剔除无关内容；
• 检查AGENTS.md（CLAUDE.md），它是否需要那么长？勿写成README.md；
• 将复杂任务拆分，不在单一会话中完成全部任务；
• 检查Codex/Claude Code配置，设置最长上下文不超过150K或其他合理阈值。

上下文优化对比示意图

若任务不得不占用超长上下文，应考虑任务拆解。例如Matt Pocock技能包中的wayfinder即为此类实践范例。此时你会发现，在大部分场景中你根本不需要“上下文压缩”。

克制才是上下文工程的核心

在AI Coding当下，顶级功法可能并非写出多么完善的上下文（Prompt），而是如何用克制、干净、高效的上下文，让LLM在最聪明的时候把问题解决。这或许就是上下文工程的关键一环。

JOTO 企业落地观察

• 对企业部署意味着：不应盲目追求最大上下文规格，而需根据任务类型设定硬性上限（如150K），并在CI/CD流水线中嵌入上下文长度校验，防止因AGENTS.md膨胀或插件叠加导致推理质量不可逆下降。
• 这类系统的取舍在于：将‘上下文压缩’从技术优先项降级为兜底手段，转而把工程重心放在任务粒度设计与会话生命周期管理上——例如强制Ticket级会话隔离，本质是用架构约束规避模型认知缺陷。
• 对RAG知识工程而言，本文揭示了传统‘全量注入文档’策略的风险：即使检索出正确片段，若混入冗余上下文导致关键指令落入‘愚蠢区间’，仍会触发幻觉。因此RAG输出必须配合上下文位置敏感的重排序与截断策略。
• AI安全治理需关注上下文污染带来的隐性风险：过长的系统提示或未经审核的Skills可能在开头占据大量Token，使用户指令被迫滑入低准确率区间，造成指令劫持或越权执行——这要求将上下文结构纳入安全审计清单。