堆进窗口的 token 越多，context rot 越真实——不是某一家模型不行，而是长上下文里「大海捞针」普遍变难。Anthropic 把 context engineering 说成 prompt engineering 的自然延伸：前者管每一轮推理前整盘状态怎么策展，后者只管 instructions 怎么写；手段包括 JIT 检索、压缩、结构化笔记、子 Agent 分工——像剪辑师剪掉废镜头。[1]
Context 在采样时就是送进模型的那坨 token：system、工具、MCP、外部材料、历史消息……它不是无限硬盘，而是会贬值的注意力预算。[1]
先扫一眼
- 主线：为何 context 会「腐烂」→ context engineering 是什么 → 运行时与长程手段 → 对 Agent 落地 意味着什么。
- 深度：文内
### 深度解析与 官方叙事与可核对事实；文末 结论与讨论 与 延伸阅读。
一、一句话心智模型
工程目标：找到尽可能小的一组高信号 token，让模型稳定产出你要的行为。[1]
人话：别用「字数多」感动自己；要像剪辑师——剪掉废镜头，留下的每一帧都要推动剧情。
二、context engineering vs. prompt engineering
| 维度 | Prompt engineering | Context engineering |
|---|---|---|
| 焦点 | 主要写 system / 指令怎么组织 | 整盘状态：本轮到底喂啥给模型 [1] |
| 时间感 | 偏一次性把指令写好 | 多轮循环里每次都要策展 [1] |
| 典型组成 | 系统提示 | 系统提示 + 工具 + MCP + 外部数据 + 消息历史 …… [1] |
Agent 在循环里会不断制造「可能有用」的信息；上下文工程就是每次决定带什么上路的艺术与科学（Anthropic 引用社区表述称之为 art and science）。[1]
深度解析：(n^2) 直觉与「窗口变大」的误区
事实：文内给出 Transformer 注意力随长度增长的直觉。原文观点：窗口再大仍要策展。本文解读：工程上应区分 「模型窗口上限」 与 「任务有效上下文」——后者常由工具返回长度、日志噪声决定；优化工具比盲目扩窗口更划算（与同系列 Writing tools 一致）。[1][3]
三、为什么「上下文工程」正在成为主线
3.1 context rot（上下文腐烂）
needle-in-a-haystack 类评测揭示：上下文越长，从其中精确回忆信息的能力往往越差——文献与业界讨论中常称 context rot。[1][5]
这不是「某一家模型不行」，而是普遍现象；不同模型只是衰减陡缓不同。[1]
3.2 attention budget（注意力预算）
类比人类工作记忆有限，模型在长上下文里也有注意力预算：每多一个 token，都在消耗这份预算。[1]
3.3 架构直觉（非恐吓，是算账）
Transformer 里 token 之间存在两两关联，长度 (n) 时关系规模大致按 (n^2) 的量级去思考「为啥越长越吃力」；上下文拉长还会与位置编码外推等带来的精细度折损并存——因此往往是性能渐变而不是「一到某长度立刻全废」。[1]
对团队的意义：窗口再大，污染与相关性问题仍在；追求「最强 Agent 表现」时，**策展比「全塞进去」**更关键。[1]
四、有效上下文的「解剖课」
4.1 System prompt：海拔要刚好（Goldilocks）
两个常见翻车：[1]
- 太矮：堆砌 if-else、 brittle 规则，维护地狱。
- 太高：空泛大词，假设模型和你共享未言明的背景。
正解：够具体能约束行为，又够弹性留下稳健启发式——像飞机自动驾驶：航道要清，但别手写每一个气流扰动的应对。[1]
实操：可用分区（如背景、指令、## Tool guidance、## Output description），XML 标签或 Markdown 标题分块；但模型变强后，格式本身可能次要，关键仍是信息是否最小且充分。[1]
起步法：用最小的 prompt + 当前最好模型试跑，再按失败模式增量补指令与示例。[1]
4.2 Tools：合同要写「省 token、促进行为」
工具是 Agent 与行动/信息空间的契约；返回要 token-efficient，并引导 Agent 少做无效扩展。[1]
原则（与专文一致）：自包含、鲁棒、意图极清晰；参数名描述性、不歧义、发挥模型长处。[1][3]
常见失败：工具集浮肿、功能重叠 → 该用哪个工具人类都说不清，别指望模型更好。[1]
中文例：search_orders 描述写清「按日期/状态/金额搜订单，返回字段含运费与支付」优于 query_db 一句话糊弄。
4.3 Examples：要「典范画」，不要「条款汇编」
few-shot 仍是强建议；但不建议把无穷边界条件洗衣清单塞进 prompt。[1]
改法：少量多样、典型、直接演示期望行为的例子——对 LLM，例子是一图胜千言。[1]
五、运行时检索与 Agentic search：「即时加载」
5.1 从「推理前一把检索」到「边干边取」
很多应用先做 embedding 检索，把材料一次堆进 prompt。Agent 思潮下，越来越多团队叠加 just-in-time（即时） 策略：只带轻量句柄（路径、已存查询、链接），用时再工具拉取。[1]
Claude Code 叙事：针对大库可写定向查询、落盘结果，用 head/tail 等只看局部，而不把整坨原始对象塞进上下文。[1]
比喻：人类不会背下整本法规，而是靠目录、书签、检索；Agent 也一样。
5.2 元数据也是信号
同名的 test_utils.py 在 tests/ 与 src/core_logic/语义不同；目录层级、命名、时间戳都在帮人和模型判断「何时用、怎么用」。[1]
5.3 Progressive disclosure（渐进披露）
允许 Agent 探索式一层层揭示上下文：文件大小暗示复杂度，命名暗示用途，时间暗示新鲜度；工作记忆里只留当前必要子集，其它靠「记笔记」外置。[1]
5.4 Trade-off
运行时探索慢于预计算好的检索；还要给模型对的工具+启发式，否则会浪费上下文追死胡同。[1]
5.5 Hybrid（混合）
先预取一部分换速度，再按需深挖；边界因任务而异。Claude Code 被点名：例如 CLAUDE.md 可先塞进上下文，glob/grep 再即时捞文件——兼避陈旧索引与复杂语法树硬啃。[1]
个人延伸（非原文结论） ：合规/金融材料「变更少」的场景，预取+版本戳往往更划算；研发代码库则偏 JIT。
六、长程任务：窗口不够用时三板斧
长程＝动作序列跨越远长于窗口仍要保持目标一致（大规模迁移、长研究项目等）。原文认为：等窗口无限大不是银弹——污染与相关性仍会拖累「最强表现」。[1]
6.1 Compaction（压缩/折叠）
窗口快满时，把对话摘要后新开一轮上下文，以摘要接续。[1]
Claude Code 做法叙事：把历史交给模型压缩，保留架构决策、未解 bug、关键实现细节，扔掉冗余工具输出；再继续时附最近访问的少量文件（原文举「五个最近文件」类叙述）。[1]
艺术在取舍：压太狠会丢了「当时不起眼、后来要命」的细节；建议在复杂 trace 上调压缩 prompt：先召回拉满，再迭代精度删冗余。[1]
低风险小动作：深层历史里的工具调用/raw 结果，常可清掉——已经执行过，未必还要原文重看；Claude 开发者平台上也有 tool result clearing / context management 一类能力自述，可对照文档使用。[1][6]
6.2 Structured note-taking（结构化笔记 / Agent 记忆）
让 Agent 定期写笔记到上下文外，后续再读回。[1]
例子：Claude Code 的 to-do；你自己的 NOTES.md。Pokémon 长程玩法叙事：跨成千上万步仍记里程式目标、地图、战术笔记；上下文重置后读自己的笔记续跑。[1]
产品侧：Sonnet 4.5 周期曾强调 memory / context 管理能力，开发者平台有 file-based memory tool beta 叙述，适合跨会话堆知识库与项目状态（以当前文档为准）。[1]
6.3 Sub-agent architectures（子 Agent）
主 Agent 规划，子 Agent 用干净窗口深搜；子 Agent 可能烧几万 token，但只回报 1k–2k 级浓缩结论。[1]
原文指向多 Agent 研究系统实践，称复杂研究任务上相对单 Agent 显著提升。[1][4]
6.4 怎么选（原文归纳）
- 对话来回多 → compaction
- 迭代开发、里程碑清晰 → note-taking
- 复杂研究、并行探索划算 → multi-agent [1]
七、Agent 定义（文中更新）
在 Building effective AI agents 一文之后，Anthropic 更倾向一句定义：Agent = 在循环里自主使用工具的 LLM（并引用社区讨论）。[1][2]
模型越强，自主等级可越高。[1]
八、重要「指标」与工程考量（原文多为定性，整理成检查表）
| 考量 | 你要问自己的 |
|---|---|
| 信号密度 | 本轮上下文是否还能删而不伤目标？[1] |
| context rot 风险 | 暴长历史是否让「大海捞针」变难？[1][5] |
| 工具税 | 工具返回是否啰嗦、是否诱发无用扩展？[1][3] |
| JIT 成本 | 探索延迟 vs 预取 staleness（陈旧）之间的平衡？[1] |
| 长程连续性 | compaction 是否丢关键细节？笔记是否可检索？子 Agent 摘要是否失真？[1] |
| 人能否判决 | 若工程师都说不清该用哪个工具，模型也不会 magically 更好 [1] |
九、思辨延伸（非 Anthropic 结论）
- 上下文工程 = 组织知识治理：谁有权写 CLAUDE.md、谁维护 NOTE、何时 compaction——是流程问题。
- 「最小高信号」与合规：金融场景的最小集合可能必须含固定Disclaimer——「小」不等于「短」，但要去噪音。
- 评测：除端到端任务外，可加 context Budget 指标（每步有效 token、工具返回平均长度）。
- 和 RAG 的关系：RAG 是解决「材料从哪来」；context engineering 还多解决「本轮带多少旧历史」「哪些工具痕迹可删」。
官方叙事与可核对事实：Claude Code 叙事与通用 Agent
事实：文中大量举例来自 Claude Code 实践。原文观点：JIT、笔记、子 Agent、compaction。本文解读（推断） ：其他载体（浏览器 Agent、纯 API 无本地文件）需 替换等效 primitive（例如以检索/对象存储代替 grep）；照搬名词不照搬环境会失灵。
十、上手与延伸阅读（官方入口）
文末指向 Claude Developer Platform 上的 memory and context management cookbook（链接以官网为准）。[1]
设计与工具书写：Writing tools for AI agents。[3]
多 Agent 模式：How we built our multi-agent research system。[4]
结论与讨论
技术坐标
context engineering 把 prompt engineering 从「写好说明书」扩展到 「每轮推理前的状态策展」——与 工具设计、记忆产品、多 Agent 同一流水线；context rot 论述把「长窗口」从卖点拉回 信号密度 问题。
批判性问题
- Compaction 是否删掉 事后才重要 的 trace——如何留「可检索的外置笔记」？
- 子 Agent 摘要 失真 时谁负责——有无交叉检验？
- 「最小高信号」与 审计留痕 是否冲突？
独立判断（事实 / 原文观点 / 本文解读）
| 类型 | 内容 |
|---|---|
| 事实 | 原文 URL；引用 context rot 讨论与 Chroma 等链接。[1][5] |
| 原文观点 | 每轮策展；JIT、渐进披露；长程三板斧。 |
| 本文解读 | 最值得建立的是 上下文预算指标（工具返回均长、有效 token 比例），否则优化无的放矢。 |
模型再强，上下文仍是珍贵且有限的注意力预算。Anthropic 这篇的核心就一句：每一轮都问——「为了达成目标，最少要给对方看哪几样高信号？」 [1]
能力、API 与特性发布节奏以 Anthropic / Claude 平台最新文档为准。
参考文献与延伸阅读
- [1] Effective context engineering for AI agents — 原文
- [2] Building effective agents
- [3] Writing tools for AI agents
- [4] Multi-agent research system
- [5] Chroma — context rot
- [6] Anthropic — context management 新闻稿/产品页（以页面更新为准）
- 可先读 Building effective agents 建立 Agent 与工具循环概念，再读本篇「每轮策展」。
