目录

用好 AI 的技术重心，正在从「提示词工程（prompt engineering）」转向「上下文工程（context engineering）」。除了打磨提示词（也就是指令）之外，你还要设计并管理交给模型的整体信息（也就是上下文）——在 2026 年，这已经成为用好 AI、尤其是构建 AI 智能体的一项必备技能。

本文面向初学者，梳理什么是上下文工程、它为什么重要（关键在于「context rot」），以及其中涉及的具体技巧。

CONTEXT ENGINEERING · 提示词之后的下一步

上下文是一笔「有限的预算」

— 只保留最精简、信号最强的信息的艺术

🎯

有所取舍

别什么都往里塞——只放入真正有用的信息。

🧹

勤于整理

把过时的历史和工具结果做摘要或删掉，保持轻量。

📥

按需取用

不在一开始就全部加载，需要的那一刻再去取。

1. 什么是上下文工程？

借用 Anthropic 的定义，上下文工程就是「在推理过程中，对交给模型的最优 tokens（信息）集合进行筛选与维护的一整套策略」（出自其《Effective context engineering for AI agents》，2026 年 3 月）。它涵盖的不只是提示词，而是所有进入上下文窗口的内容——系统提示词、工具、对话历史以及外部数据。

可以把它理解为「保持桌面整洁的艺术」。你只把需要的材料放在伸手可及的地方，用完的就收起来。如果在桌子（也就是上下文窗口）上堆满文件，效率反而会下降——AI 也是同样的道理。正因如此，「放什么、不放什么」才是一个值得认真对待的设计问题。

💡 一句话概括：提示词工程＝「打磨指令」。上下文工程＝「设计模型所看到的整体信息」。后者是一门更宽广的学问，并把前者包含在内。

2. 为什么重要：「context rot」这堵墙

「既然上下文窗口能装一百万 tokens，那干脆全都放进去不就行了？」陷阱就在这里：你加入的 tokens 越多，模型的准确率反而越会下降。这一现象被称为「context rot（上下文腐化）」。

2025 年 Chroma 对 18 个主流模型（GPT、Claude、Gemini 等）进行了测试，结果无一例外：输入越长，回答的可靠性就越低。原因在于模型的「注意力（attention）」是一笔有限的预算。每多一个 token，这笔预算就被摊薄一分，更容易漏掉相关信息——而放在长上下文「中间位置」的信息尤其容易被忽略（lost in the middle）。

输入越长，准确率越低（示意图）

短上下文（只放必要信息）高准确率
中等（历史与工具结果堆积）开始下降
过长（什么都塞进去）大幅下降

* 此为概念示意图。在实测研究中，例如 Stanford 的研究（2023）报告称，当提供约 4,000 tokens 的参考资料时，正确率从 70–75% 降到了 55–60%。任务越难，性能退化越明显。

简而言之，「上下文越长越好」是错的。正因如此，才需要上下文工程——只保留最精简、信号最强的 tokens。尤其是对长时间运行的 AI 智能体和编程智能体而言，context rot 往往是首要的失败原因。

3. 上下文里到底装了什么

人们容易以为「上下文＝提示词」，但实际上有多得多的元素共用着同一个窗口——而且它们全都在消耗这笔预算。

系统提示词

角色、规则、语气等作为基础的指令。

工具定义与结果

工具说明（例如 MCP）及其输出结果。

对话与工作历史

至今为止的往来交流，以及模型自身累积的推理。

外部数据

检索到的文档与代码、RAG 搜索结果等等。

工作越长，堆积的历史和工具结果就越多。放任不管，窗口很快就会塞满「被埋在中间的重要信息」。这正是需要下面这些整理技巧的原因。

4. 六大核心技巧

结合 Anthropic 的指引与实战经验，这里列出六个收效显著的技巧。它们共同的原则是「找出信号最强的最小 tokens 集合」。

① 拿捏合适「高度」的指令

过于细碎的 if-else 逻辑很脆弱；太笼统又不起作用。目标是取其中间：「既具体又灵活」。

② 精选你的工具

去掉职能重叠、或难以判断该用哪个的工具。收敛到少数几个职责清晰的工具。

③ 即时检索（just-in-time）

不在一开始就全部加载，而是只持有文件路径和链接，需要的那一刻再去取。与 Claude Skills 的渐进式披露是同一个思路。

④ 压缩（compaction，摘要压缩）

当窗口被填满时，把历史做成摘要，再带入一个全新的窗口。保留决策与未决问题，丢弃冗余的工具输出。

⑤ 笔记（外部记忆）

把进度和要点写到窗口之外的文件里，只在需要时再读回来。让长任务保持连贯。

⑥ 用子智能体隔离

把调研这类繁重的工作交给子智能体，只把摘要返回给主智能体。让细节上下文不进入主线程。

⚠️ 别过度设计：在搬出复杂机制之前，先做能跑通的最简单方案。仅仅是不加入多余信息、并经常开启新会话，往往就已经很有效了。

5. 与提示词、RAG、Skills 的关系

这些相邻概念很容易混在一起，我们来给它们定个位。上下文工程是把它们全部串起来的「统领性思路」。

  • 提示词工程：打磨指令的功夫。它是上下文工程的一部分。
  • RAG：检索外部知识并加入上下文的一种方法。是处理「检索什么、加入什么」的一种手段。
  • Skills：一种仅在需要时才展开某段流程的机制。是即时检索的一个具体例子。

因此，「打磨指令」（提示词）、「补充知识」（RAG）、「按需载入与卸载流程」（Skills）——上下文工程把这些都当作同一个设计问题：往窗口里放什么、又清掉什么。

6. 今天就能上手的做法

在动手做任何复杂实现之前，有一些谁都能立刻用上的习惯。

  • 话题变了就开一个新会话：仅仅是不把旧上下文拖着走，准确率就能恢复。这是最简单也最有效的一招。
  • 别整篇粘贴长文档：只抽出相关的部分交给模型。附上全文往往会适得其反。
  • 长任务做到一半让它做摘要：请它「把到目前为止的决策和剩余任务列出来」，然后以此为起点继续（手动压缩）。
  • 别堆砌工具和扩展：把用不上的 MCP 服务器和 skills 去掉。选项越多，模型越会犹豫。

💡 成本上也更划算：不加载多余的 tokens，直接就意味着节省 token 成本。准确率与成本可以同时改善。

总结

关于上下文工程的三点收获。

  • 它是什么：设计并管理「模型所看到的整体信息」（含提示词）的学问。是提示词工程之后的下一个阶段。
  • 为什么：因为存在「context rot」——你加入的 tokens 越多，准确率越下降。上下文是一笔有限的预算。
  • 诀窍：只保留最精简、信号最强的 tokens。你的武器是精选、整理（摘要）、按需检索，以及子智能体隔离。

先从「话题变了就开新会话」和「只粘贴要点」开始。想深入了解的话，不妨同时看看 Claude Skills 和harness 工程。

FAQ

Q. 提示词工程现在过时了吗？

A. 没有。提示词工程作为上下文工程的一部分，依然重要。两者的关系是：在打磨指令这项功夫之上，再叠加「设计整体信息」的视角。

Q. 用一个上下文窗口更大的模型就能解决吗？

A. 即使窗口很大，context rot 照样会发生。研究表明，仅仅因为有空间就把一切都塞进去，反而会降低准确率。大窗口是「余量」，而不是「可以什么都放」的许可。

Q. 普通的聊天使用也和它有关吗？

A. 有关。仅仅是「每个话题开一个新会话」和「只粘贴要点」，就能提升回答质量。即便你不是工程师，这些也是今天就能用上的小窍门。

Q. RAG 和上下文工程有什么区别？

A. RAG 是一种具体方法——「检索外部知识并加入上下文」。上下文工程则是更宽广的概念，整体地处理「往窗口里放什么、又清掉什么」，而 RAG 是其中的一个组成部分。