提示词工程解决「怎么问」，上下文工程解决「把什么给模型看」。上下文窗口越做越大，问题反而变了：不是放不下，而是放进去之后模型用不好、还会忘。业界把这种现象叫中间遗忘（lost in the middle）：窗口太长时，模型对开头和结尾记得清楚，中间部分经常漏。

为什么长上下文不等于好上下文

  • 1M 窗口看着大，真实使用中大量内容利用率很低，还会稀释模型的注意力
  • 越长越贵：大部分 API 按 token 计费，塞满上下文等于烧钱
  • 检索噪音会干扰判断：不相关的内容混进来，比不放更糟

上下文工程的核心手段

  • 选择：只放与当前任务相关的片段，靠检索和路由决定「读哪些」
  • 压缩：对历史对话做摘要、对代码库做结构化索引，代替全文搬运
  • 记忆：把跨会话信息沉淀到外部存储，用时再取（参见 Agent 记忆）
  • 工具：用 MCP 按需拉取数据，而不是预先把数据堆进提示词

2026 年 GitHub 上这类项目开始成体系：有专门管理 Claude 上下文的 zilliztech/claude-context，有把代码库记忆做成 MCP server 的 codebase-memory-mcp，也有把上下文窗口变成显式可配置层的 context-mode。大模型厂商也在同一方向发力——DeepSeek 的前缀缓存与稀疏注意力，本质都是「少算无关内容」。

落地建议

  1. 长文档先摘要、再分段检索，别整篇塞进提示词
  2. 给关键信息设重复锚点：开头点题、结尾总结，中间放细节
  3. 用 token 用量做监控：哪个任务上下文暴涨，先优化检索而不是加窗口
上下文工程的本质是预算管理：token 有限，注意力更有限，每一段都要花在刀刃上。