第6章：Context Engineering —— Agent 工程的核心能力

上一章讲了对齐技术怎么把一个"只会续写"的模型变成"听话的助手"。但即使模型对齐得再好，如果你喂给它的信息是垃圾，它也只能输出垃圾。

这一章讲的是一个很多人忽视但极其关键的能力：怎么管理送进模型的那些 token。

一个直觉：你可以把 LLM 想象成一个极度聪明但只有短期记忆的员工。每次你找他干活，他只能看到你当场递给他的那叠资料。资料太少，他没有足够信息做决策；资料太多，关键信息被淹没在噪音里；资料放的顺序不对，他可能读完前半部分就忘了。Context Engineering 就是"怎么准备这叠资料"的学问。

6.1 从 Prompt Engineering 到 Context Engineering

核心直觉

Prompt Engineering 是写好一条指令；Context Engineering 是管好模型推理时能看到的所有信息——system prompt、对话历史、工具描述、工具返回结果、检索到的文档、结构化笔记，全部加起来。

定义

Anthropic 在 2025 年的工程博客中给出了明确定义 [1]：

Context Engineering 是一套策略，用于在 LLM 推理时策划和维护最优的 token 集合。

注意"策划和维护"这两个动词。策划（curating）意味着选择——不是所有信息都该塞进去；维护（maintaining）意味着持续管理——Agent 跑了 30 分钟之后的上下文和第 1 分钟的上下文不该是同一堆东西。

为什么需要一个新名词

Prompt Engineering 这个词在 2023-2024 年被用烂了。Simon Willison 说得好：这个词已经被重新定义成"往聊天框里输入一堆奇怪的 hack" [2]。但 Agent 开发者面对的问题远不止"怎么写 prompt"：

一个运行 4 小时的 Coding Agent，上下文从 5000 token 膨胀到 15 万 token，中间经历了几十次工具调用——怎么保证它到第 4 小时还记得第 1 小时做的架构决策？
一个 Multi-Agent 系统，主 Agent 拿到 5 个子 Agent 的返回结果，每个几千 token——怎么在不爆上下文的前提下综合所有信息？
一个 RAG Agent 检索到 20 个文档片段，但只有 3 个真正相关——怎么过滤噪音？

这些问题的共同点：不是在优化一条 prompt，而是在管理一整个信息流。

Andrej Karpathy 在 2025 年 6 月用了一个好类比 [3]：LLM 是 CPU，上下文窗口是 RAM。工程师的工作像操作系统——把正确的代码和数据加载到工作内存里。Prompt Engineering 关注的是"代码写得好不好"，Context Engineering 关注的是"整个内存里放了什么"。

不过，"Context Engineering"这个术语也不是没有争议。有开发者认为它不过是 Prompt Engineering 的改名 [4]；也有人指出，目前大部分所谓的"Context Engineering 最佳实践"缺乏量化标准，更像是"有技术外衣的写作建议" [5]。这些批评有道理——这个领域确实还很年轻，远没有形成软件工程那样成熟的方法论。但不管你怎么称呼它，管理上下文的问题是真实存在的，后面的内容会讲具体怎么做。

6.2 有限注意力预算：Context Rot

核心直觉

上下文窗口写着能装 100 万 token，不意味着装满 100 万 token 还能好好干活。Token 越多，模型的回忆准确率越低——这叫 Context Rot。

研究证据

Lost in the Middle（2024）

Stanford 的 Liu et al. 发现了一个 U 形曲线 [6]：模型对上下文开头和结尾的信息回忆准确率最高，中间的信息准确率下降超过 30%。即使是专门为长上下文训练的模型也存在这个问题。

为什么会这样？论文本身主要报告的是现象，而不是把原因锁定在单一机制上。一个更稳妥的理解是：随着序列变长，位置偏差、注意力分配被稀释、训练时更偏向短序列等因素会叠加，让中间区域的信息更容易被忽略 [1][6]。

Anthropic 在 2023 年关于 Claude 2.1 长上下文提示的文章里也给出过一个工程例子 [7]：在其 200K 检索评测中，给回答加上一句 "Here is the most relevant sentence in the context:"，得分可以从 27% 提升到 98%。这不是 Lost in the Middle 的直接复现，但它说明了另一件事：在长上下文里，提示语如果能把模型的注意力拉向正确片段，效果会发生很大变化。

Context Rot（Chroma Research，2025）

Chroma 在 2025 年 7 月发布了一项更系统的研究 [8]，覆盖多个前沿模型家族（包括 Claude、GPT、Gemini、Qwen 等），核心发现：

所有模型的性能都随输入长度增加而下降，无一例外
即使模型在短而聚焦的输入上表现很好，换成长而嘈杂的输入后，效果也会明显变差
问题不只是"窗口装不下"，而是噪音、干扰项和注意力分散一起累积
模型在打乱顺序的文本上表现反而好于有逻辑结构的文档——结构化的文本中语义连贯的干扰项更容易误导注意力机制

Chroma 归纳了三个叠加机制：

上下文退化 = Lost-in-the-Middle（位置偏差）
           + 注意力稀释（二次方复杂度下的关系爆炸）
           + 干扰项干涉（语义相似但无关的内容主动误导模型）

一个需要注意的背景：Chroma 本身是做向量数据库的，如果长上下文不好使，对它的 RAG 生态有利。但研究结论已被多个独立团队复现，数据本身是可靠的。

对 Agent 开发的直接影响

METR 的公开评测从另一个角度说明了这个问题 [12]：当前前沿 Agent 更容易完成短任务，对人类需要数小时的任务成功率会明显下降；在 2024 年那版简单 scaffold 评测里，Agent 表现还会在大约 20 万 token 左右趋于平台。这里不全是上下文问题，但它提醒我们：任务一旦拉长，工具使用、状态管理和上下文管理会一起成为瓶颈。

这不是理论问题。如果你在做一个需要运行几十分钟的 Agent，Context Rot 几乎一定会影响你。

工程启示

更大的上下文窗口是必要的，但不是充分的。100 万 token 的窗口给了你更大的操作空间，但"用满它"几乎一定是错误策略。真正的目标是：在任意时刻，上下文里都只有当前任务需要的最小高信号 token 集合。

6.3 信噪比优化：找到最小高信号 token 集

核心直觉

关键不是往上下文里塞更多信息，而是只保留会影响下一步决策的信息。

核心原则

Anthropic 在 Context Engineering 文章里把目标概括得很直接 [1]：找到最小可能的高信号 token 集合。这个表述很朴素，但它几乎可以当成整章的总原则。

什么叫高信号？就是它会明显影响模型接下来的判断、工具选择或输出格式。比如：

当前任务目标和成功标准
最近做出的架构决策
下一步必须用到的工具约束
当前问题直接相关的文档片段

什么叫低信号？通常是这些东西：

已经过期的工具返回结果
和当前子任务无关的历史讨论
重复出现的规则和说明
"也许以后有用"但这一步并不需要的背景资料

一个实用判断标准：删掉这段信息后，模型下一步表现会不会明显变差？ 如果不会，它大概率就是噪音。

这也是为什么 Context Engineering 的核心不是"尽量多给"，而是"尽量少给，但别少到影响决策"。后面的 System Prompt、工具设计、检索策略和长任务管理，本质上都在服务同一个目标：提高信噪比。

6.4 System Prompt 设计

核心直觉

System Prompt 是 Agent 的"岗位说明书"。写清楚它是谁、能做什么、不能做什么、遇到模糊情况怎么处理。

核心原则

Anthropic 的建议可以归纳为四条 [1]：

1. 用清晰直接的语言，找到"正确的抽象高度"

不要事无巨细地列出每种可能的情况，也不要笼统到毫无约束力。好的 system prompt 像一份优秀的岗位描述——讲清楚职责边界和决策原则，而不是把每天的工作流程都写成操作手册。

# 不好的例子——太细，且无法穷举
如果用户问天气，调用 get_weather 工具。
如果用户问股票，调用 get_stock_price 工具。
如果用户问新闻，调用 search_news 工具。
...（还有 50 种情况）

# 好的例子——讲原则
你是一个信息查询助手。当用户提出需要实时数据的问题时，
使用合适的工具获取最新信息。优先使用最专用的工具；
如果没有专用工具，退回到通用搜索。
如果不确定用哪个工具，向用户确认。

2. 用结构化格式组织

用 XML 标签或 Markdown 标题把 system prompt 切分成独立段落。模型对结构化输入的理解显著好于一大段自然语言。

xml

<role>你是一个代码审查 Agent。</role>

<capabilities>
- 读取代码文件
- 运行静态分析工具
- 提交审查评论
</capabilities>

<constraints>
- 不要修改代码，只提供审查意见
- 每个文件的评论不超过 5 条，聚焦最重要的问题
- 如果发现安全漏洞，标记为 CRITICAL
</constraints>

<output_format>
每条评论包含：文件路径、行号、严重级别、问题描述、建议修复
</output_format>

3. 从最小化开始，基于失败逐步迭代

不要一上来就写一个 2000 token 的 system prompt。从最核心的指令开始，跑测试，看 Agent 在哪里犯错，针对那个错误加一条规则或一个 few-shot 示例。每一条规则都应该对应一个观察到的失败模式。

4. 少量示例（Few-shot）比长篇描述更有效

与其用 200 个字描述你想要的输出格式，不如直接给两个例子。模型从示例中提取模式的能力远强于从自然语言描述中推断。

System Prompt 的大小

一个经常被忽视的问题：system prompt 占据的是你的上下文预算。一个 5000 token 的 system prompt 在每一轮对话中都会被完整发送——如果 Agent 跑了 100 轮，这就是 50 万个输入 token 的成本（虽然 Prompt Caching 可以大幅降低重复前缀的费用）。

经验法则：system prompt 控制在 1000 token 以内能覆盖绝大多数场景。如果超过 2000 token，认真考虑是否有内容可以移到工具描述或外部文档中。

6.5 工具描述作为上下文的一部分

核心直觉

工具描述不只是"技术文档"——它们是 system prompt 的延伸，直接影响模型选择哪个工具、怎么调用。

为什么工具描述这么重要

每个工具的名称、描述、参数定义都会被注入到上下文中。模型看到这些描述后决定调用哪个工具——这和人类看菜单点菜是一样的道理。菜单上写"红烧肉"和写"精选五花肉经传统工艺炖制 4 小时"，点菜的决策过程是不同的。

Anthropic 提出的工具设计原则（ACI，Agent-Computer Interface）[9]：

自包含：每个工具的描述要完整到模型不需要额外信息就能正确调用。包括：什么时候用、什么时候不用、参数的含义和约束、返回值的格式。

功能不重叠：两个工具如果做差不多的事情，模型就会犹豫选哪个。这种犹豫浪费推理 token，还增加出错概率。如果必须保留功能相近的工具，描述中要明确区分使用场景。

意图清晰：工具名称应该直接表达意图。search_database 比 query 好，get_user_by_email 比 get_user 好。

一个反例：

python

# 不好——模型不知道什么时候该用哪个
tools = [
    {"name": "search", "description": "搜索信息"},
    {"name": "lookup", "description": "查找信息"},
    {"name": "find", "description": "找到信息"},
]

# 好——每个工具职责清晰
tools = [
    {"name": "web_search", "description": "在互联网上搜索实时信息。用于需要最新数据的问题（新闻、天气、股价）。返回前 5 条结果的标题和摘要。"},
    {"name": "db_lookup", "description": "在内部数据库中按 ID 查询记录。用于已知记录 ID 时的精确查询。返回完整记录。"},
    {"name": "vector_search", "description": "在知识库中做语义搜索。用于需要理解问题含义才能找到答案的开放式问题。返回最相关的 3 个文档片段。"},
]

工具数量与上下文预算

每个工具描述通常会消耗数十到数百 token。工具一多，这就是一笔不小的上下文开销，尤其在每轮对话都会重复发送的情况下。

当工具集合持续膨胀时，模型的选择准确率往往会下降。不是因为模型"笨"，而是上下文中的工具描述太多，注意力被稀释了——这本质上就是 Context Rot 在工具层面的表现。

应对策略：动态工具加载。不要把所有工具一次性注入上下文，根据当前任务阶段只加载相关的工具子集。MCP（Model Context Protocol）的一个核心价值就是支持这种动态发现和加载——Agent 不需要预先知道所有可用工具，可以在运行时按需发现和注册。

6.6 上下文检索策略

核心直觉

不要把所有可能有用的信息一股脑塞进上下文。按需加载，能省则省。

两种策略

Just-in-Time（即时加载）

在上下文中只保留轻量的标识符（文件名、记录 ID、URL），需要时才通过工具调用加载完整内容。

好处：上下文保持精简，不会被大量预加载的内容污染。代价：每次需要信息时都要做一次工具调用，增加延迟和 token 消耗（调用本身也有开销）。

适合场景：工具调用延迟低、信息量大且只有少部分会被用到。

预加载 + Agent 自主探索（混合策略）

把确定会用到的核心信息预加载到上下文中（比如用户的基本信息、项目配置），让 Agent 自主决定是否需要加载更多。

好处：减少工具调用次数，核心信息随时可用。代价：预加载的信息如果没被用到，就是噪音。

适合场景：有一组几乎每次都会用到的核心数据，加上偶尔需要深入查询的长尾数据。

实战中的选择

大部分生产系统用混合策略。一个具体的例子——客服 Agent：

预加载（每次会话都注入）：
- 用户姓名、等级、最近 3 笔订单摘要（~200 token）
- 当前活跃的促销政策摘要（~100 token）

即时加载（Agent 判断需要时调用）：
- 具体订单详情（通过 get_order_detail 工具）
- 退款政策全文（通过 get_policy 工具）
- 物流追踪信息（通过 track_shipment 工具）

这样上下文始终保持在可控范围内，同时 Agent 在大多数对话中不需要额外的工具调用就能回答基本问题。

6.7 长任务上下文管理

这是 Agent 工程中最难的部分。一个运行 5 分钟的 Agent 和一个运行 5 小时的 Agent 面临的上下文挑战完全不同。短任务可以靠"把什么都塞进去"撑过去，长任务必须有系统性的管理策略。

Anthropic 在博客中介绍了四种核心手段 [1]，下面逐一展开。

6.7.1 Compaction（压缩）

核心直觉：上下文快满了，让模型自己总结一下"到目前为止发生了什么"，然后用总结替换掉原始对话历史。

机制：

当对话接近上下文窗口上限时，把完整的消息历史发送给模型，要求它压缩成一份摘要。摘要应保留：

关键的架构决策和设计选择
未解决的问题和待办事项
重要的中间结果
当前的执行状态

然后丢弃原始消息，用摘要作为新上下文的起点继续执行。

一个可公开核验的实现例子：

Anthropic 在 Context Engineering 文章和 Claude Code 文档里给过一个公开版本的实现描述 [1][11]：长会话发生 compaction 时，系统会把消息历史总结成结构化摘要，再继续往下执行。System Prompt 和输出风格不会因为压缩而消失；项目根目录的 CLAUDE.md、自动记忆等会从磁盘重新注入；而路径作用域规则、子目录里的 CLAUDE.md 则要等到再次读到匹配文件时才会重新进入上下文。

这说明 compaction 不是简单地"删聊天记录"，而是把上下文分成两层：

持久指导信息：该保留、该重载的继续保留
易膨胀的消息历史：压缩成摘要，只留下高信号部分

核心权衡：每次压缩都会丢失信息。如果压缩得太激进，Agent 可能忘记关键的早期决策；如果压缩得太保守，上下文又会迅速重新膨胀。没有通用最优解——需要根据任务特点调整压缩策略。

6.7.2 Structured Note-Taking（结构化笔记）

核心直觉：让 Agent 主动把重要信息写到上下文窗口之外的持久存储中，需要时再读回来。

机制：

给 Agent 一个"写笔记"的工具，Agent 在执行过程中主动记录关键发现。笔记存储在文件系统、数据库或 KV 存储中——不在上下文窗口内，不会随对话压缩被丢弃。

python

# Agent 可用的笔记工具
tools = [
    {
        "name": "write_note",
        "description": "将重要发现写入持久化笔记。用于：架构决策、关键发现、待办事项、需要跨多步保留的信息。笔记不会随上下文压缩丢失。",
        "parameters": {
            "category": "决策 | 发现 | 待办 | 状态",
            "content": "笔记内容"
        }
    },
    {
        "name": "read_notes",
        "description": "读取之前保存的笔记。在压缩后或需要回顾早期决策时使用。",
        "parameters": {
            "category": "可选，按类别过滤"
        }
    }
]

Anthropic 的多 Agent 研究系统中，LeadResearcher 会把研究计划写入 Memory，因为如果上下文窗口超过 20 万 token 就会被截断——外置的笔记是少数不会随上下文截断直接丢失的信息 [10]。

关键洞察：好的 Agent 不只是被动地积累上下文，而是主动管理信息——把值得记住的东西外置，把不再需要的东西清理掉。这和人类做笔记的逻辑完全一样：你不会把每句话都记在脑子里，而是选择性地写到笔记本上。

6.7.3 Sub-agent Context Isolation（子 Agent 上下文隔离）

核心直觉：把大任务拆给多个子 Agent，每个子 Agent 有自己独立的上下文窗口，干完活只返回一份精简摘要。

机制：

主 Agent 负责规划和综合；子 Agent 负责具体执行。每个子 Agent 的上下文窗口只包含它自己的任务——搜索结果、中间推理、工具调用历史都不会污染主 Agent 的上下文。子 Agent 完成后返回一份压缩摘要，主 Agent 只需要整合这些摘要。

Anthropic 的实际效果：

在 Anthropic 的内部 research eval 上，多 Agent 架构（Opus 4 主 Agent + Sonnet 4 子 Agent）相对单个 Opus 4 Agent 提升了 90.2% [10]。这个差距不该被机械外推到所有任务，但它至少说明了一件事：当任务天然适合并行探索时，把细节搜索隔离在子 Agent 的上下文里，确实可能显著提高信噪比。

代价：Anthropic 同一篇文章也提到，普通 Agent 交互大约会消耗聊天交互 4 倍的 token，而多 Agent 系统大约会消耗聊天交互 15 倍的 token [10]。你是在用更多 token 换更高质量，这是一笔明确的成本-质量权衡。

6.7.4 Tool-result Clearing（工具结果清理）

核心直觉：工具返回了大量数据，Agent 用完之后及时清理，不要让过期结果一直占着上下文。

机制：

一次 search 工具调用可能返回几千 token 的搜索结果。Agent 从中提取了需要的信息后，这些原始结果就不再有用了。但如果不清理，它们会一直留在对话历史中，成为 Context Rot 的帮凶。

清理策略：

立即清理：Agent 提取完信息后，用摘要替换原始工具返回
延迟清理：保留最近 N 次工具调用的完整结果，更早的自动压缩
选择性保留：对不同类型的工具结果应用不同策略——代码文件内容可能需要保留更久，搜索结果通常可以快速清理

Anthropic 把 tool result clearing 视为一种最轻量的压缩形式 [1]：优先清掉已经消费完的大块工具结果，同时保留摘要、推理痕迹和决策记录。因为后续步骤真正依赖的通常不是原始输出本身，而是"从里面得出了什么结论"。

四种手段的协同

这四种策略不是互斥的——生产系统通常同时使用：

策略	解决的问题	触发时机	信息损失
Compaction	对话历史膨胀	接近上下文上限	中等——取决于压缩质量
Structured Note-Taking	关键信息跨压缩保留	Agent 发现重要信息时主动触发	低——信息被持久化
Sub-agent Isolation	单个上下文被多任务污染	任务可并行拆分时	低——但总 token 成本高
Tool-result Clearing	工具输出占据过多空间	工具信息被使用后	低——原始数据通常可重新获取

一个长时间运行的 Agent 的典型信息流：

开始执行
  ├── 工具调用 → 获取结果 → 提取关键信息 → 清理原始结果（Clearing）
  ├── 发现重要信息 → 写入外部笔记（Note-Taking）
  ├── 拆分子任务 → 分派子 Agent → 接收摘要（Isolation）
  ├── 上下文接近上限 → 压缩对话历史（Compaction）
  └── 读取笔记 → 继续执行 → 循环

6.8 Prompt Caching 机制与最佳实践

核心直觉

Prompt Caching 的核心价值是：把每轮都重复出现的长前缀缓存起来，让后续请求更便宜、更快。对 Agent 来说，最典型的可缓存内容就是 system prompt、工具定义、固定示例和稳定的知识库前缀。

为什么它对 Agent 特别重要

普通聊天应用每轮上下文可能不长；Agent 不一样。一个生产 Agent 的请求里常常有：

很长的 system prompt：角色、边界、输出格式、错误处理规则。
大量工具定义：函数名、参数 schema、权限说明、返回格式。
固定 few-shot 示例：教模型如何选择工具、如何拒绝危险操作。
稳定业务上下文：产品文档、政策摘要、用户所在租户的规则。

这些内容每轮都发，但大部分并不会变。如果供应商支持 prompt caching，就应该把它们设计成稳定前缀，把每轮变化的用户输入、当前任务状态、工具返回结果放在后面。

text

可缓存前缀：
  system prompt
  工具定义
  固定示例
  稳定业务规则

每轮变化内容：
  用户最新消息
  当前步骤状态
  本轮工具返回
  临时错误信息

OpenAI 的 Prompt Caching 文档明确建议把静态内容放在 prompt 开头，因为缓存命中依赖前缀匹配 [13]。Anthropic 的缓存机制则通过 cache_control 标记可复用内容，并按 tools → system → messages 的层级创建缓存前缀 [14]。具体门槛、TTL、折扣和模型支持会随供应商变化，写作或实现时必须查官方文档。

缓存友好的上下文结构

一个缓存友好的 Agent 请求通常长这样：

python

messages = [
    # 稳定：适合缓存
    {"role": "system", "content": SYSTEM_PROMPT},

    # 稳定：工具定义或工具说明尽量保持顺序和文本不变
    {"role": "system", "content": TOOL_POLICY},

    # 半稳定：业务规则可以按版本缓存
    {"role": "system", "content": f"Policy version: {policy_version}\n{policy_text}"},

    # 动态：放在后面，避免破坏前缀命中
    {"role": "user", "content": user_message},
    {"role": "assistant", "content": current_task_state},
]

几个实用原则：

稳定内容前置：system prompt、工具定义、固定示例放前面，用户输入和工具结果放后面。
减少无意义动态字段：不要在可缓存前缀里放时间戳、随机 request id、每轮变化的调试标记。
工具定义顺序稳定：同一批工具每次排序不同，也可能让前缀匹配失败。
按版本管理业务规则：政策文档更新时显式变更版本，让缓存失效是可解释的。
观察缓存命中指标：不要只凭感觉优化。OpenAI 会在 usage 里返回 cached tokens，Anthropic 也有 cache creation / cache read 相关 usage 字段。

它不是免费的银弹

Prompt Caching 只降低重复前缀的成本和延迟，不会解决上下文本身的质量问题。一个冗长、矛盾、低信噪比的 system prompt，即使缓存命中率很高，也仍然会让模型表现变差。

更微妙的问题是：缓存会影响架构风格。为了提高命中率，你会倾向于把稳定内容固定在前缀里，把动态内容后置。这是好事，但不要为了缓存把本该动态检索的信息硬塞进 system prompt。缓存优化应该服从 Context Engineering 的总原则：最小高信号 token 集。

常见误区

误区一："上下文窗口越大越好，直接把所有东西塞进去"

Chroma 的研究已经证明，即使窗口有 100 万 token，5 万 token 处就可能开始退化。更大的窗口给了你更大的操作空间，但不意味着你应该填满它。正确的策略是：用大窗口给自己留出安全余量，同时积极管理上下文中的信息密度。

误区二："压缩就是丢信息，能不压缩就不压缩"

压缩确实会丢信息，但不压缩的后果可能更糟——Context Rot 导致模型连已有的信息都无法正确使用。一个 5 万 token 的精简上下文通常比一个 15 万 token 的臃肿上下文表现更好。

误区三："System Prompt 越详细越好"

过长的 system prompt 有两个问题：占用上下文预算，以及增加模型需要同时关注的指令数量。指令之间如果存在微妙的矛盾，模型可能选择性忽略一部分。从 500 token 以内的 system prompt 开始，只在观察到具体失败后才添加规则。

误区四："一个 Agent 能做所有事"

当任务涉及多个不同领域（搜索、代码、数据分析），一个 Agent 的上下文会被多种不相关的信息污染。拆分成多个专用子 Agent，每个子 Agent 的上下文只包含它需要的信息，通常比一个"全能 Agent"效果更好。Anthropic 在适合并行探索的内部研究评测里报告过显著提升 [10]，但前提是任务本身确实适合拆分。

面试高频题

题目一：Context Engineering 和 Prompt Engineering 的区别？

好的回答思路：

Prompt Engineering 关注的是怎么写好一条指令——措辞、格式、few-shot 示例。Context Engineering 的范围更广：它关注 LLM 推理时能看到的所有 token——system prompt、对话历史、工具描述、工具返回结果、检索到的文档、外部笔记等等。
Andrej Karpathy 的类比很贴切：LLM 是 CPU，上下文窗口是 RAM。Prompt Engineering 像是优化单条指令，Context Engineering 像是操作系统的内存管理——决定什么时候加载什么数据、什么时候释放、怎么避免内存碎片。
在实践中，Context Engineering 包含了 Prompt Engineering，但还额外涵盖：上下文检索策略（预加载 vs 即时加载）、长任务的压缩和笔记策略、多 Agent 的上下文隔离、工具结果的生命周期管理。对 Agent 开发来说，单次 prompt 的质量只是基线，跨多轮的信息流管理才是决定 Agent 能否可靠运行的关键。

加分点：

提到 Context Rot 研究——即使有大窗口，信噪比才是关键
提到具体的管理手段：Compaction、Structured Note-Taking、Sub-agent Isolation、Tool-result Clearing
提到社区争议——有人认为只是改名，但解决的工程问题是真实存在的

题目二：如何处理一个需要运行 4 小时的长任务 Agent 的上下文管理？

好的回答思路：

4 小时的 Agent 面临的核心挑战是上下文膨胀和 Context Rot——token 越来越多，模型对早期信息的回忆越来越差。
我的策略是四层组合：
Compaction：设定一个阈值（比如上下文使用到 70%），触发压缩。让模型把对话历史总结成保留关键决策和当前状态的摘要，然后在压缩后的上下文上继续执行。
Structured Note-Taking：给 Agent 一个"写笔记"的工具。在发现重要信息、做出关键决策、遇到待解决问题时，主动把这些写入外部存储（文件或数据库）。这样即使经历多次压缩，关键信息也不会丢失。
Sub-agent Isolation：把大任务拆分成子任务，每个子任务分配给独立的子 Agent。子 Agent 有自己的上下文窗口，完成后返回精简摘要。主 Agent 的上下文只需要包含计划和各子 Agent 的摘要。
Tool-result Clearing：工具返回的大块数据（搜索结果、文件内容）在使用后及时清理或替换为摘要，避免过期数据在上下文中持续积累。
另外，我会在每次压缩后让 Agent 读取笔记确认当前状态，类似于人类午休后回来先看看自己的待办清单。

加分点：

提到 Claude Code 的 compaction、自动记忆和外部文件重载机制
提到 METR 的任务时间尺度评测——任务越长，成功率通常越低，解释为什么主动管理是必需的
提到 Checkpoint 和状态持久化（对接第 16 章 Runtime 的概念）——如果 Agent 中途崩溃，不仅需要恢复执行状态，还需要恢复上下文状态
提到 Prompt Caching：长任务里稳定前缀应尽量可缓存，但不能为了缓存牺牲上下文质量

参考资料

[1] Anthropic. Effective context engineering for AI agents. 2025-09. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[2] Simon Willison. Context Engineering. 2025-06. https://simonwillison.net/2025/jun/27/context-engineering/

[3] Andrej Karpathy. X post on context engineering. 2025-06-25. https://x.com/karpathy/status/1937902205765607626

[4] Prompting Guide. Prompt Engineering is Dead?. https://www.promptingguide.ai/

[5] The Infrastructure Mindset. Prompt Engineering Is Not Engineering. https://the-infrastructure-mindset.ghost.io/prompt-engineering-is-not/

[6] Nelson F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12:157-173, 2024. https://arxiv.org/abs/2307.03172

[7] Anthropic. Long context prompting for Claude 2.1. 2023-12-06. https://www.anthropic.com/news/claude-2-1-prompting

[8] Kelly Hong, Anton Troynikov, Jeff Huber. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research, 2025-07. https://www.trychroma.com/research/context-rot

[9] Anthropic. Building effective agents. 2024-12. https://www.anthropic.com/engineering/building-effective-agents

[10] Anthropic. How we built our multi-agent research system. 2025-06-13. https://www.anthropic.com/engineering/multi-agent-research-system

[11] Claude Code. Explore the context window. https://code.claude.com/docs/en/context-window

[12] METR. An update on our general capability evaluations. 2024-08-06. https://metr.org/blog/2024-08-06-update-on-evaluations/

[13] OpenAI. Prompt caching. OpenAI API Documentation. https://platform.openai.com/docs/guides/prompt-caching

[14] Anthropic. Prompt caching. Claude API Documentation. https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

第6章：Context Engineering —— Agent 工程的核心能力 ​

6.1 从 Prompt Engineering 到 Context Engineering ​

核心直觉 ​

定义 ​

为什么需要一个新名词 ​

6.2 有限注意力预算：Context Rot ​

核心直觉 ​

研究证据 ​

对 Agent 开发的直接影响 ​

工程启示 ​

6.3 信噪比优化：找到最小高信号 token 集 ​

核心直觉 ​

核心原则 ​

6.4 System Prompt 设计 ​

核心直觉 ​

核心原则 ​

System Prompt 的大小 ​

6.5 工具描述作为上下文的一部分 ​

核心直觉 ​

为什么工具描述这么重要 ​

工具数量与上下文预算 ​

6.6 上下文检索策略 ​

核心直觉 ​

两种策略 ​

实战中的选择 ​

6.7 长任务上下文管理 ​

6.7.1 Compaction（压缩） ​

6.7.2 Structured Note-Taking（结构化笔记） ​

6.7.3 Sub-agent Context Isolation（子 Agent 上下文隔离） ​

6.7.4 Tool-result Clearing（工具结果清理） ​

四种手段的协同 ​

6.8 Prompt Caching 机制与最佳实践 ​

核心直觉 ​

为什么它对 Agent 特别重要 ​

缓存友好的上下文结构 ​

它不是免费的银弹 ​

常见误区 ​

面试高频题 ​

题目一：Context Engineering 和 Prompt Engineering 的区别？ ​

题目二：如何处理一个需要运行 4 小时的长任务 Agent 的上下文管理？ ​

参考资料 ​

第6章：Context Engineering —— Agent 工程的核心能力

6.1 从 Prompt Engineering 到 Context Engineering

核心直觉

定义

为什么需要一个新名词

6.2 有限注意力预算：Context Rot

核心直觉

研究证据

对 Agent 开发的直接影响

工程启示

6.3 信噪比优化：找到最小高信号 token 集

核心直觉

核心原则

6.4 System Prompt 设计

核心直觉

核心原则

System Prompt 的大小

6.5 工具描述作为上下文的一部分

核心直觉

为什么工具描述这么重要

工具数量与上下文预算

6.6 上下文检索策略

核心直觉

两种策略

实战中的选择

6.7 长任务上下文管理

6.7.1 Compaction（压缩）

6.7.2 Structured Note-Taking（结构化笔记）

6.7.3 Sub-agent Context Isolation（子 Agent 上下文隔离）

6.7.4 Tool-result Clearing（工具结果清理）

四种手段的协同

6.8 Prompt Caching 机制与最佳实践

核心直觉

为什么它对 Agent 特别重要

缓存友好的上下文结构

它不是免费的银弹

常见误区

面试高频题

题目一：Context Engineering 和 Prompt Engineering 的区别？

题目二：如何处理一个需要运行 4 小时的长任务 Agent 的上下文管理？

参考资料