# 02 Effective context engineering for AI agents - 上下文工程的系统性方法论

> **发布时间**：2025年9月29日\
> **原文链接**：<https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents\\>
> **核心定位**：从Prompt Engineering到Context Engineering的学科演进，定义Agent时代的新工程范式

***

## 📖 文章概览

这篇文章标志着AI工程领域的一次重要**术语转变**：从"Prompt Engineering"（提示词工程）到"Context Engineering"（上下文工程）。这不仅是名称的改变，更代表了随着AI能力

的提升，工程重点的战略性转移。

### 核心命题

> **关键问题**：什么样的上下文配置最有可能产生模型的期望行为？

```
Prompt Engineering (过去)
  ↓ 演进
Context Engineering (现在)
  = Retrieval + Memory + Tools + Meta-cognition
```

***

## 🎯 Context Engineering vs Prompt Engineering

### 定义对比

| 维度     | Prompt Engineering | Context Engineering                |
| ------ | ------------------ | ---------------------------------- |
| **焦点** | 如何编写有效的提示词         | 如何策划和维护最优的Token集合                  |
| **场景** | 单轮分类或文本生成          | 多轮推理，长时间范围的Agent                   |
| **组成** | 主要是System Prompt   | System + Tools + MCP + 外部数据 + 消息历史 |
| **管理** | 静态优化               | 动态循环管理                             |

### 核心区别图解

```
┌─────────────────────────────────────────────────────────────┐
│  Prompt Engineering: 离散任务                                 │
│                                                              │
│  [编写Prompt] → [单次推理] → [输出]                          │
│                                                              │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  Context Engineering: 迭代和循环管理                          │
│                                                              │
│  ┌──────────────┐                                           │
│  │ 策划上下文    │ ← ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐                 │
│  └──────┬───────┘                         │                 │
│         ↓                                  │                 │
│  ┌──────────────┐                         │                 │
│  │ Agent推理    │                         │                 │
│  └──────┬───────┘                         │                 │
│         ↓                                  │                 │
│  ┌──────────────┐                         │                 │
│  │ 产生新数据    │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┘                 │
│  └──────────────┘                                           │
│         │                                                    │
│         └──→ 循环：不断更新和优化上下文                       │
└─────────────────────────────────────────────────────────────┘
```

***

## 🧠 为什么Context Engineering如此重要

### 核心挑战：上下文腐烂（Context Rot）

**研究发现**：

```
Needle-in-a-haystack 基准测试揭示：

随着上下文窗口中的Token数量增加
     ↓
模型准确召回信息的能力下降
     ↓
上下文必须被视为有限资源
```

**类比**：

```
人类：有限的工作记忆容量
  ↓
LLM：有限的"注意力预算"

每个新Token都会消耗这个预算
```

### 架构约束：Transformer的n²问题

**技术原因**：

1. **Transformer架构**

   ```
   每个Token可以关注到所有其他Token
        ↓
   n个Token = n²对成对关系
        ↓
   关系捕获能力被拉伸
   ```
2. **训练数据分布**

   ```
   模型在训练数据中：
   - 短序列更常见
   - 长序列较少见
        ↓
   对长上下文的注意力模式经验较少
   ```
3. **位置编码插值**

   ```
   允许处理更长序列，但会：
   - 适应性地调整到原始训练的较小上下文
   - Token位置理解有所降低
   ```

**结论**：

```
性能梯度 > 硬边界
     ↓
模型在长上下文下仍然有能力
但在检索和长距离推理方面精度降低
```

***

## 🏗️ 有效上下文的解剖学

### 核心原则

> **指导原则**：找到能最大化期望结果可能性的**最小可能**的高信号Token集合。

### 各组件的优化策略

#### 1️⃣ System Prompts（系统提示词）

**目标**：在**正确的高度**呈现想法

```
┌─────────────────────────────────────────────────────────────┐
│  Goldilocks Zone（适中区域）                                  │
│                                                              │
│  太低 ←──────────────── 正确高度 ────────────────→ 太高      │
│                                                              │
│  硬编码           给出强大的启发式           过于模糊         │
│  复杂逻辑         引导行为                   缺乏具体信号     │
│  脆弱             灵活                       假设共享上下文    │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

**❌ 太低的示例**：

```markdown
如果用户说"取消"并且订单ID以"ORD"开头
并且订单在过去24小时内创建
并且用户不是VIP
那么...
```

**✅ 正确高度的示例**：

```markdown
## 任务
你是客户服务Agent，帮助用户管理订单。

## 取消政策
- 24小时内的订单可以免费取消
- 24小时后根据会员等级可能产生费用
- VIP会员始终免费取消

## 行为指导
在执行任何操作前：
1. 收集所有必要信息
2. 检查政策是否允许
3. 向用户确认
```

**❌ 太高的示例**：

```markdown
帮助用户处理他们的订单问题。
```

**最佳实践**：

```markdown
推荐结构：

<background_information>
[背景信息]
</background_information>

## 核心职责
[明确的职责定义]

## Tool guidance
[工具使用指导]

## Output description
[输出格式说明]
```

#### 2️⃣ Tools（工具）

**核心原则**：工具应该促进效率

**两个维度的效率**：

1. 返回**Token高效**的信息
2. 鼓励**高效的Agent行为**

**常见失败模式**：

```
❌ 臃肿的工具集
❌ 功能覆盖过多
❌ 工具选择不明确

示例：
如果人类工程师无法明确说出在特定情况下应该使用哪个工具，
Agent也不能指望做得更好。
```

**最佳实践**：

```python
# 自包含
def search_customer_context(
    customer_id: str,
    include_orders: bool = True,
    include_support_history: bool = True
) -> CustomerContext:
    """
    一站式获取客户的完整上下文
    而不是分别调用：
    - get_customer()
    - get_orders()
    - get_support_history()
    """
    pass

# 错误健壮
def send_email(to: str, subject: str, body: str):
    try:
        validate_email(to)
        validate_subject(subject)
        send(to, subject, body)
    except ValidationError as e:
        return f"Error: {e.message}. Please fix and retry."

# 清晰的预期用途
```

#### 3️⃣ Examples（示例）

**Few-shot Prompting的最佳实践**：

```
❌ 不推荐：穷举所有边缘情况

## 示例
1. 如果用户说X，做Y
2. 如果用户说A，做B
3. 如果用户说P，做Q
... (列举50个边缘情况)

✅ 推荐：策划多样化的规范示例

## 示例
<example>
场景：客户要求退款
情况：订单在30天内
行动：
1. 验证订单信息
2. 检查退款资格
3. 处理退款
4. 确认给客户
</example>

<example>
场景：客户报告产品缺陷
情况：保修期内
行动：
1. 收集缺陷详情（照片、描述）
2. 验证保修状态
3. 创建退换货工单
4. 提供时间线
</example>
```

**原则**：

```
对于LLM，示例是价值千言的"图片"

- 不是规则的清单
- 而是行为的演示
- 展示预期的模式
```

### 总体指导

**所有组件的共同原则**：

```
信息性 yet 紧凑

- System Prompts: 清晰 but 简洁
- Tools: 强大 but 最小化
- Examples: 多样 but 规范
- Message History: 相关 but 精简
```

***

## 🔍 上下文检索与Agentic Search

### 从静态检索到动态探索

#### 传统RAG方法

```
静态检索（传统RAG）：
1. 接收查询
2. 检索最相似的Chunks
3. 使用这些Chunks生成响应

问题：
- 检索是一次性的
- 无法适应新发现
- 无法动态调整
```

#### Agentic Search方法

```
动态探索（Agentic Search）：
1. Agent自己生成搜索查询
2. 评估检索结果
3. 根据发现调整搜索策略
4. 迭代直到找到足够信息

优势：
- 自适应
- 更全面
- 更相关
```

### Just-in-Time Context策略

**核心思想**：不是预先处理所有数据，而是维护轻量级标识符，在运行时动态加载。

#### 工作方式

```
┌─────────────────────────────────────────────────────────────┐
│  传统方法：预加载所有相关数据                                 │
│                                                              │
│  [大量文档] → [Embedding] → [全部加载到上下文]               │
│                                                              │
│  问题：                                                       │
│  - 上下文窗口浪费                                            │
│  - 大量无关信息                                              │
│  - 无法处理大规模数据                                         │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  Just-in-Time方法：按需加载                                   │
│                                                              │
│  [维护索引] → [Agent决定] → [动态加载]                       │
│  (文件路径)   (需要什么)   (仅需要的)                        │
│                                                              │
│  优势：                                                       │
│  - 上下文高效                                                │
│  - 相关性高                                                  │
│  - 可扩展                                                    │
└─────────────────────────────────────────────────────────────┘
```

#### Claude Code的实现

```python
# Claude Code使用此方法处理大型数据库

# 1. 维护轻量级引用
database_index = {
    "customers": "path/to/customers.db",
    "orders": "path/to/orders.db",
    "logs": "path/to/logs/"
}

# 2. Agent编写目标查询
query = "SELECT * FROM customers WHERE id = 12345"

# 3. 使用Bash命令分析结果
# head: 查看前几行
# tail: 查看后几行
# grep: 搜索特定模式

# 4. 从不将完整数据对象加载到上下文中
```

### 元数据的力量

**观察**：

```
文件/资源的元数据提供了高效的信号

示例：
- test_utils.py 在 tests/ 文件夹
  vs
- test_utils.py 在 src/core_logic/

相同的文件名，不同的上下文含义

元数据信号：
- 文件夹层次结构
- 命名约定
- 时间戳
- 文件大小
```

### 渐进式披露（Progressive Disclosure）

**类比人类研究**：

```
人类研究过程：
1. 先浏览目录了解全局
2. 识别相关章节
3. 深入阅读特定段落
4. 必要时扩展到相关资料

Agent研究过程：
1. 浏览文件结构
2. 识别相关文件（基于命名、大小、时间戳）
3. 选择性加载内容
4. 使用笔记策略保留关键信息
```

### 混合策略

**权衡**：

| 特性    | 运行时探索 | 预计算检索 |
| ----- | ----- | ----- |
| 速度    | 较慢    | 更快    |
| 准确性   | 更高    | 较低    |
| 灵活性   | 高     | 低     |
| 工程复杂度 | 高     | 低     |

**最佳实践**：

```
混合策略：

1. 预先检索一些关键数据（速度）
2. 允许Agent自主探索（准确性）

决策边界取决于：
- 任务复杂度
- 延迟要求
- 内容动态性
```

**Claude Code示例**：

```python
# 混合策略实现

# 1. CLAUDE.md文件预先加载
claude_md_content = load_upfront("CLAUDE.md")

# 2. Agent使用工具进行Just-in-Time检索
agent.use_tools([
    "glob",  # 文件模式匹配
    "grep",  # 内容搜索
    "head",  # 查看文件开头
    "tail"   # 查看文件结尾
])

# 这避免了：
# - 过时的索引
# - 复杂的语法树
# - 昂贵的预计算
```

***

## ⏳ 长时间任务的上下文工程

### 挑战

```
长时间任务：
- 跨越数十分钟到数小时
- Token计数超过LLM的上下文窗口
- 需要保持连贯性和目标导向

挑战：
- 上下文窗口大小限制
- 上下文污染
- 信息相关性

注意：
等待更大的上下文窗口可能不是解决方案！
即使有更大的窗口，仍然会面临：
- 上下文污染
- 信息相关性问题
```

### 三种解决技术

#### 1️⃣ Compaction（压缩）

**定义**：将接近上下文窗口限制的对话进行总结，并用总结重新启动新的上下文窗口。

**工作流程**：

```
┌─────────────────────────────────────────────────────────────┐
│  步骤1：检测接近限制                                          │
│  ┌─────────────────────────────────┐                        │
│  │ Context Usage: ████████████░ 95%│                        │
│  └─────────────────────────────────┘                        │
└─────────────────────────────────────────────────────────────┘
        ↓
┌─────────────────────────────────────────────────────────────┐
│  步骤2：总结关键内容                                          │
│  ┌──────────────────────────────────────────┐               │
│  │ • 架构决策：使用微服务架构                  │               │
│  │ • 未解决的Bug：用户登录超时                │               │
│  │ • 实现细节：使用Redis作为缓存              │               │
│  └──────────────────────────────────────────┘               │
└─────────────────────────────────────────────────────────────┘
        ↓
┌─────────────────────────────────────────────────────────────┐
│  步骤3：重启新上下文                                          │
│  ┌─────────────────────────────────┐                        │
│  │ [总结] + [最近5个文件]           │                        │
│  │ Context Usage: ██░░░░░░░░░ 20%   │                        │
│  └─────────────────────────────────┘                        │
└─────────────────────────────────────────────────────────────┘
```

**Claude Code实现**：

```python
# Claude Code的Compaction实现

def compact_context():
    # 1. 将消息历史传递给模型进行总结
    summary = claude.summarize(message_history, 
        focus=[
            "architectural_decisions",
            "unresolved_bugs",
            "implementation_details"
        ]
    )
    
    # 2. 保留关键内容
    preserved_content = {
        "summary": summary,
        "recent_files": last_5_accessed_files,
        "current_task": current_task_state
    }
    
    # 3. 清除旧上下文，加载压缩内容
    reset_context(preserved_content)
```

**艺术在于选择**：

```
需要保留：
✅ 架构决策
✅ 未解决的问题
✅ 实现细节
✅ 依赖关系

可以丢弃：
❌ 冗余的工具输出
❌ 成功的中间步骤
❌ 详细的调试日志
```

**最佳实践**：

```markdown
Compaction Prompt优化：

1. 最大化召回（Recall）
   - 确保捕获所有相关信息
   - 在复杂Agent追踪上仔细调整

2. 提高精度（Precision）
   - 消除多余内容
   - 保持总结简洁

3. 清除工具调用结果
   - 一旦工具被调用很久，无需再看原始结果
   - Tool Result Clearing是最安全的压缩形式
```

**功能链接**：[Context Management on Claude Developer Platform](https://www.anthropic.com/news/context-management)

#### 2️⃣ Structured Note-Taking（结构化笔记）

**定义**：Agent定期将笔记写入上下文窗口外的持久内存，稍后再拉回。

**类比**：

```
像Claude Code创建待办事项列表
或
你的自定义Agent维护NOTES.md文件
```

**工作流程**：

```
┌─────────────────────────────────────────────────────────────┐
│  Agent工作流程                                                │
│                                                              │
│  执行任务 → 发现关键信息 → 写入NOTES.md                       │
│     ↑                                      ↓                 │
│     └──────────── 稍后读取 ←───────────────┘                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

**实战案例：Claude玩Pokémon**

```python
# Claude玩Pokémon的记忆系统

# 维护精确的计数
notes = {
    "steps_training": 1234,
    "pikachu_levels_gained": 8,
    "target_levels": 10,
    "current_location": "Route 1",
    "explored_regions": ["Pallet Town", "Route 1", "Viridian City"],
    "achievements": ["Defeated 5 trainers", "Caught Pidgey"],
    "combat_strategies": {
        "electric_attacks": "Effective against water types",
        "avoid": "Ground type Pokémon"
    }
}

# 跨上下文重置保持连贯性
after_reset = load_notes(notes)
# Agent继续多小时的训练序列或地下城探索
```

**核心价值**：

```
没有笔记：
❌ 上下文重置后丢失进度
❌ 无法跟踪长期目标
❌ 难以维护状态

有笔记：
✅ 跨会话连贯性
✅ 清晰的进度跟踪
✅ 战略性的长期规划
```

**Claude Developer Platform的记忆工具**：

```python
# Memory Tool in Public Beta

from claude_sdk import memory

# 存储信息
memory.store(
    key="project_architecture",
    value={"type": "microservices", "language": "Python"}
)

# 检索信息
arch = memory.retrieve("project_architecture")

# 跨会话持久化
memory.persist()
```

**链接**：[Memory Tool Announcement](http://anthropic.com/news/context-management)

#### 3️⃣ Sub-agent Architectures（子Agent架构）

**定义**：中央LLM动态分解任务，委派给工作LLM，并综合结果。

**架构模式**：

```
┌─────────────────────────────────────────────────────────────┐
│  Lead Agent (协调者)                                          │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ • 制定高层计划                                           │  │
│  │ • 识别子任务                                             │  │
│  │ • 委派给Sub-agents                                      │  │
│  │ • 综合结果                                               │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
        │
        ├──────────────┬──────────────┬──────────────┐
        ↓              ↓              ↓              ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Sub-agent 1  │ │ Sub-agent 2  │ │ Sub-agent 3  │ │ Sub-agent 4  │
├──────────────┤ ├──────────────┤ ├──────────────┤ ├──────────────┤
│ 深度技术工作  │ │ 搜索特定信息  │ │ 分析数据      │ │ 生成报告      │
│              │ │              │ │              │ │              │
│ 使用数万Token │ │ 使用数万Token │ │ 使用数万Token │ │ 使用数万Token │
│      ↓       │ │      ↓       │ │      ↓       │ │      ↓       │
│ 返回1-2k     │ │ 返回1-2k     │ │ 返回1-2k     │ │ 返回1-2k     │
│ Token总结    │ │ Token总结    │ │ Token总结    │ │ Token总结    │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
```

**关键特性**：

```
1. 关注点分离
   - 详细搜索上下文在Sub-agent内隔离
   - Lead Agent专注于综合和分析

2. 上下文压缩
   - Sub-agent可能使用数万Token探索
   - 但仅返回1-2k Token的摘要

3. 并行处理
   - 多个Sub-agent同时工作
   - 显著提升效率
```

**实战案例**：[How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)

**性能提升**：

```
单Agent系统 vs Multi-Agent系统

在复杂研究任务上：
Multi-Agent显示出**实质性改进**

特别是在需要：
- 并行探索
- 大量信息处理
- 独立子任务
```

### 选择合适的方法

```
┌─────────────────────────────────────────────────────────────┐
│  决策树                                                       │
│                                                              │
│  需要广泛的来回对话？                                         │
│  ├─ 是 → Compaction                                         │
│  └─ 否 ↓                                                     │
│                                                              │
│  有明确的里程碑迭代开发？                                     │
│  ├─ 是 → Note-Taking                                        │
│  └─ 否 ↓                                                     │
│                                                              │
│  需要复杂研究和分析？                                         │
│  有并行探索价值？                                             │
│  └─ 是 → Multi-Agent Architectures                          │
└─────────────────────────────────────────────────────────────┘
```

***

## 💡 核心洞察总结

### 洞察1：上下文是稀缺资源

```
关键理解：

上下文 ≠ 免费资源
上下文 = 有限的注意力预算

每个Token都有成本：
- 降低其他Token的关注度
- 增加混淆的可能性
- 减少推理能力

因此：
→ 必须精心策划上下文
→ 就像策划博物馆展览一样
```

### 洞察2：从静态到动态

```
Prompt Engineering (静态)
     ↓
Context Engineering (动态)

不再是：
"编写一次完美的Prompt"

而是：
"在每个推理步骤动态优化上下文"

这是范式转变：
从手工艺 → 到系统工程
```

### 洞察3：Agent需要元认知

```
传统AI：
Input → Process → Output

现代Agent：
Input → Think → Gather → Process → Verify → Output

关键差异：
Agent需要知道：
- 我需要什么信息？
- 我在哪里可以找到它？
- 我现在知道的够吗？
- 我的输出对吗？

这是**元认知能力**
```

***

## 🔗 与其他文章的关联

### 前置文章

* **Building effective agents**（2024.12.19）：Agent的基础概念

### 同时发布的文章

* **Building agents with Claude Agent SDK**（2025.09.29）：SDK实现上下文工程

### 后续实践文章

* **Writing effective tools for agents**（2025.09.11）：工具设计与上下文效率
* **Multi-agent research system**（2025.06.13）：Sub-agent架构的实战

### 技术深入文章

* **The "think" tool**（2025.03.20）：元认知在上下文中的实现
* **Contextual Retrieval**（2024.09.19）：检索技术的创新

***

## 🎯 实践建议

### 对开发者

#### 立即可做

1. **审计现有的上下文使用**

   ```python
   # 检查你的Prompt
   - System Prompt有多长？
   - 是否包含过多细节？
   - 是否在正确的"高度"？

   # 检查你的工具
   - 工具是否返回过多信息？
   - 是否有重叠功能？
   - 工具描述清晰吗？
   ```
2. **实现Tool Result Clearing**

   ```python
   # 最安全的压缩形式
   # 清除深层历史中的工具调用结果

   def clear_old_tool_results(history, threshold=50):
       for i, message in enumerate(history):
           if i < threshold and message.type == "tool_result":
               message.content = "[Cleared]"
   ```
3. **使用Memory Cookbook**

   ```python
   # Claude Developer Platform提供的示例
   # https://github.com/anthropics/claude-cookbooks/blob/main/tool_use/memory_cookbook.ipynb
   ```

#### 中期目标

1. **实现Compaction**

   ```python
   # 为长期运行的Agent实现压缩

   def should_compact(context_usage):
       return context_usage > 0.8

   def compact(history):
       summary = summarize(history, 
           focus=["decisions", "unresolved_issues", "key_facts"])
       recent = history[-5:]
       return [summary] + recent
   ```
2. **构建Just-in-Time检索**

   ```python
   # 不要预加载所有数据
   # 维护索引，按需加载

   index = {
       "customers": "path/to/customers.db",
       "orders": "path/to/orders.db"
   }

   def load_on_demand(agent_query):
       # Agent决定需要什么
       if "customer" in agent_query:
           return load(index["customers"], limit=100)
   ```
3. **实验Sub-agent**

   ```python
   # 对于复杂任务，尝试Sub-agent

   def research_task(query):
       lead_agent = LeadAgent()
       
       # 分解任务
       subtasks = lead_agent.decompose(query)
       
       # 并行执行
       results = parallel_execute([
           SubAgent(task) for task in subtasks
       ])
       
       # 综合
       return lead_agent.synthesize(results)
   ```

### 对产品经理

1. **理解上下文成本**

   ```
   Agent运行成本 = 基础成本 + 上下文成本

   上下文成本可能是主要成本！

   需要在功能和成本之间权衡：
   - 是否需要完整历史记录？
   - 可以使用总结吗？
   - 可以分解为子任务吗？
   ```
2. **设计验证机制**

   ```
   长期运行的Agent需要检查点：
   - 中途人工审核
   - 关键决策确认
   - 进度可视化
   ```
3. **规划渐进式推出**

   ```
   不要一次构建复杂系统：

   Phase 1: 单Agent + 简单工具
   Phase 2: 添加Compaction
   Phase 3: 实现Just-in-Time检索
   Phase 4: 尝试Sub-agents
   ```

***

## 🚨 关键警告

### ⚠️ 上下文不是越多越好

**误区**：

```
❌ "我们有200k上下文窗口，让我们全部使用！"
```

**现实**：

```
✅ "更多上下文 = 更多噪音"
✅ "上下文质量 > 上下文数量"

研究显示：
- 上下文越长，准确性下降
- 关键信息可能被"埋没"
- 推理能力可能降低
```

### ⚠️ 等待更大的上下文窗口不是解决方案

**误区**：

```
❌ "等Claude有1M上下文窗口，问题就解决了"
```

**现实**：

```
✅ 即使有1M窗口，仍需要上下文工程

原因：
- 上下文腐烂不会消失
- 注意力稀释仍然存在
- 信息相关性仍然重要

更大的窗口 ≠ 更好的性能
更好的上下文策划 = 更好的性能
```

### ⚠️ 工具设计直接影响上下文效率

**问题**：

```
糟糕的工具设计：
- 返回过多信息
- 格式不友好
- 缺乏过滤选项
     ↓
上下文快速耗尽
     ↓
Agent性能下降
```

**解决**：

```python
# 好的工具设计

def search_documents(
    query: str,
    max_results: int = 10,
    return_format: str = "summary"  # "full" | "summary"
):
    """
    返回格式选项：
    - summary: 只返回标题和摘要（节省Token）
    - full: 返回完整内容（当需要时）
    """
    results = search(query)
    
    if return_format == "summary":
        return [{"title": r.title, "summary": r.summary} 
                for r in results[:max_results]]
    else:
        return results[:max_results]
```

***

## 📊 价值评估

| 维度       | 评分    | 说明                  |
| -------- | ----- | ------------------- |
| **理论深度** | ⭐⭐⭐⭐⭐ | 定义了新的工程学科           |
| **实践指导** | ⭐⭐⭐⭐⭐ | 提供了完整的实践方法论         |
| **技术创新** | ⭐⭐⭐⭐☆ | Just-in-Time检索是创新思路 |
| **长期价值** | ⭐⭐⭐⭐⭐ | 这是Agent时代的核心工程能力    |

***

## 🔮 未来展望

### 可能的演进方向

1. **自动化上下文优化**

   ```
   未来的Agent可能自动：
   - 识别无关信息
   - 决定何时压缩
   - 优化检索策略
   - 管理自己的记忆
   ```
2. **上下文工程IDE**

   ```
   专门的工具来：
   - 可视化上下文使用
   - 分析上下文效率
   - 优化建议
   - A/B测试上下文策略
   ```
3. **标准化的上下文协议**

   ```
   类似HTTP的标准：
   - 如何组织上下文
   - 如何传递上下文
   - 如何压缩上下文
   - 如何验证上下文
   ```
4. **跨Agent上下文共享**

   ```
   Multi-Agent系统中：
   - 如何安全共享上下文
   - 如何隔离上下文
   - 如何同步状态
   - 如何避免冲突
   ```

***

## 📚 延伸阅读

### 在本知识库中

1. **Agent开发系列**
   * `Building agents with Claude Agent SDK.md`
   * `Building effective agents.md`
   * `Multi-agent research system.md`
2. **工具设计系列**
   * `Writing effective tools for agents.md`
   * `The think tool.md`
3. **RAG系列**
   * `Contextual Retrieval.md`（待生成）
   * `# 🏗️ Build RAG/` 文件夹

### 外部资源

* **Memory Cookbook**: <https://github.com/anthropics/claude-cookbooks/blob/main/tool\\_use/memory\\_cookbook.ipynb>
* **Context Management**: <https://www.anthropic.com/news/context-management>
* **Claude Documentation**: <https://docs.anthropic.com/>

***

## 💭 个人思考与启发

### 思考1：学科的诞生

**观察**：

```
Prompt Engineering → Context Engineering

这不仅是术语变化，是学科升级：

就像：
Web设计 → UX/UI设计
写代码 → 软件工程

当一个领域成熟，它会：
1. 定义自己的术语
2. 建立方法论
3. 形成最佳实践
4. 培养专业人才

Context Engineering正在经历这个过程
```

**启发**：

```
对于从业者：
- 这是学习新技能的机会
- 早期采用者会有优势
- 建立专业知识的窗口期

对于公司：
- 这是战略投资的时机
- Context Engineer可能成为新职位
- 上下文工程能力=竞争优势
```

### 思考2：稀缺性的价值

**观察**：

```
AI时代的悖论：
- 计算能力越来越强
- 上下文窗口越来越大
- 但注意力仍然稀缺

这类似于：
互联网时代 - 信息爆炸，但注意力稀缺
```

**启发**：

```
在AI系统设计中：
不要追求"更多"
要追求"更相关"

就像：
不要给用户1000个搜索结果
要给用户最相关的10个结果
```

### 思考3：Just-in-Time的回归

**观察**：

```
Just-in-Time Context
    ↓
类似于Just-in-Time Compilation
    ↓
都是"延迟计算"的思想

核心理念：
- 不预先加载所有东西
- 在需要时才加载
- 基于运行时决策
```

**启发**：

```
在软件工程中：
很多经典思想在新场景下重现

学习经典思想的价值：
- 提供思维框架
- 可以类比应用
- 避免重新发明轮子
```

***

**最后的话**：

这篇文章定义了AI工程的新学科：**Context Engineering**。

就像软件工程从"写代码"演进到"工程化"，AI开发也正从"调Prompt"演进到"系统化的上下文管理"。

对于开发者，这是**技能升级的机会**。\
对于行业，这是**新职业的诞生**。\
对于AI发展，这是**工程化的关键一步**。

**上下文工程，未来已来！** 🚀