上下文工程

从 Prompt Engineering 到 Context Engineering

Prompt Engineering 是写好单条指令的技艺：选对词、搭好结构、挑准示例，让一次模型调用产出期望结果。这门手艺仍然有用 — 但已经不够了。

Context Engineering 是更宏观的学科。它问的是另一个问题：

“什么样的上下文配置，最可能让模型产生期望的行为？” — Anthropic, Effective Context Engineering for AI Agents

Agent 不是一次调用。它是一个循环：模型读上下文、调工具、拿结果、推理、继续 — 往往几十上百轮。每一轮，上下文窗口都会被完整重读一次。窗口里留了什么、怎么进来的、何时退出、被什么取代 — 这些选择在整个运行中累积。Prompt Engineering 优化一次调用；Context Engineering 优化整个信息生命周期。

这种转变之所以重要，是因为失败方式不同。糟糕的 prompt 产出糟糕的回答。糟糕的上下文策略则产出一个开始连贯但逐渐腐坏的 Agent — 忘记早期决策、前后矛盾、十轮前的用户目标已经丢了。第二种失败在越过某个阈值之前是不可见的；等你察觉，对话已经无法挽救。

注意力预算 (Attention Budget)

语言模型的工作记忆是有限的。长上下文基准的研究 — “大海捞针”检索、多文档问答、Agent 编码评测 — 揭示了 Anthropic 称为上下文衰退 (context rot) 的现象：

随着上下文窗口中的 token 数增加，模型准确召回特定信息的能力下降。

这不是在某个特定 token 数上出现的硬断崖，而是一个梯度：模型的有效精度在上下文远未”填满”之前就已经开始缓慢下降。因此结论不是”用更小的上下文”，而是：

找到最小的高信号 token 集合，最大化产生期望结果的可能性。

窗口中的每个 token 都在和其他所有 token 竞争注意力。低价值 token — 过时的工具输出、重复的样板、走不通的猜测 — 不仅仅是占位，它们会主动稀释模型对高价值 token 的关注。Context Engineering 就是最大化信号密度的学科。

两个推论：

上下文不是越多越好。 把所有”可能有用的”文档都预加载进去，往往会可衡量地伤害性能。一个塞满弱信号的 100k token 上下文，常常输给一个精心挑选的 10k token 上下文。
上下文有成本。 Token 是计费的。缓存能摊薄成本，但只对稳定前缀有效（参见提示词设计，这点直接决定了 prompt 布局）。

三支柱

Context Engineering 是个大的设计空间。更方便的思考方式，是把它拆成三个各自回答不同问题的支柱：

支柱	回答的问题	关注点
提示词设计	Agent 始终看到的静态骨架是什么？	高度、结构、示例、工具定义、缓存
记忆设计	什么信息存在窗口之外、按需召回？	记忆分类学、读写策略、结构化笔记
上下文管理	循环过程中如何修剪、替换、重载信息？	预算、即时加载、子 Agent 隔离、checkpoint

第三支柱里有一个操作足够厚重、值得独立成章：上下文压缩 —— 运行时已无法把窗口控制在预算内时启动的操作。触发、谱系、保留、调优、多 Agent 协调、跨框架对比都住在那里。它在阅读顺序里放在记忆和上下文管理之间 —— 因为它描述的是内容层溢出时会发生什么，先于把它编排进循环的运行时层。

三个支柱并非彼此独立：

记忆写入的信息，要由上下文管理在循环中载入；好的记忆如果从不被召回，等于没有。
工具定义属于提示词，但工具返回结果的形态由上下文管理治理（保留多少、如何截断）。
子 Agent 继承一个新鲜 prompt、用自己的记忆通道、回归时和压缩组合 — 一次委托同时涉及三个支柱。

把三支柱当成推理权衡时的词汇，不是正交的模块。

指导原则

后续页面讲的每一个技法 — XML 标签、示例挑选、记忆类型、即时加载、压缩级联、子 Agent 架构 — 都是同一个原则的局部实例：

在循环的每一步，识别出最小的高信号 token 集合，最大化产生期望结果的可能性。

模型进步后，上下文窗口会增大、注意力质量会提升。为弱模型搭的某些脚手架会变得多余。但底层约束不会消失：上下文仍然是稀缺资源，仍然有真实的机会成本。更强的模型让人去做更雄心的任务，那些任务又会用新类型的信息填满窗口。张力不会消失，它只是换一种形态出现。

阅读三支柱时如果感到某个技法令人困惑、或权衡看起来武断，回到这条原则重新看。

关于度量

三支柱各有值得测的东西 —— prompt 回归、记忆命中率、上下文占用。把它们当工程件对待，不是手艺。每个支柱页末尾都有一段简短的”如何度量”小节，点明那根支柱专属的信号。

三支柱共有的元原则：没有回归装置，每次改动都是观点。 最小的有用装置通常是一组固定的真实输入 + 期望行为 —— 20-50 条起步就够，也足以抓住生产里大多数会出的问题。

阅读指南

如果你对这个话题不熟，按顺序读；后面的支柱会把前面的作为词汇使用。

提示词设计 — 静态骨架。如何找对高度、把指令结构化以便模型解析、用示例作为主要的引导手段、排布 prompt 块让缓存真正生效。
记忆设计 — 窗口之外持久的东西。记忆类型分类（情景、语义、程序、工作），何时该写、何时该召回，结构化笔记作为持久的规划状态，以及记忆如何失效。
上下文压缩 —— 窗口装不下需要的内容时启动的操作：压缩谱系、触发策略、保留政策、自定义指令、设计扩展（多 Agent / 缓存 / 恢复）、跨框架参考。
上下文管理 —— 把上述各项整合起来的运行时纪律。注意力预算、即时加载、渐进式披露、把子 Agent 本身作为一种上下文工程手段、checkpoint、失败模式。

还有两个压轴，把理论转成实践：

案例：Claude 设计 Agent 提示词 —— 对一份 ~340 行真实生产级系统提示词的精读，点名每一个值得学的设计动作。理论在真实提示词里的样子。
从案例到范式 —— 从那次精读蒸馏出的方法：10 步设计流程，以及同一套不变量如何从单体 prompt 延伸到运行时装配的组合式架构。

如果你想了解 Zapvol 的具体实现（压缩层级、记忆服务、prompt registry），请看架构 — 本章讲的是设计理论，不是代码走读。

来源

Effective Context Engineering for AI Agents — Anthropic, 2026
Prompting best practices — Anthropic, Claude API 文档
Building Effective Agents — Anthropic, 2024
Building LLM Applications for Production — Chip Huyen, 2023，对”prompt + 上下文”问题的早期且仍具影响力的论述