上下文工程指南 | Context Engineering Guide

DAIR.AI Academy 出品

上下文工程指南

从提示工程到架构完整上下文的演进 — 探索构建可靠AI代理的核心技能

什么是上下文工程？

✦ 从提示工程到上下文工程

几年前，许多顶尖的AI研究人员都声称提示工程（prompt engineering）将不复存在。显然，他们大错特错了。事实上，提示工程现在比以往任何时候都更加重要，以至于它正在被重新命名为上下文工程（context engineering）。

这不仅仅是一个新的花哨术语，它描述的是一个**至关重要的过程**：调整指令和高度相关的上下文，以使大型语言模型（LLM）能够更有效、更精确地执行其复杂任务。

✦ 上下文工程的广义定义

文章指出，上下文工程是：为大型语言模型（LLM）和高级AI模型设计并优化指令及相关上下文，以使其高效执行任务的过程。

图示释义： 上下文工程超越了简单的Prompt，它是一个多层面的过程，涵盖了对LLM整个上下文窗口的精细化架构与优化。

✦ 上下文工程核心任务一览

它不是单一的技能，而是涵盖了对LLM上下文窗口内所有信息的系统性优化，包括：

设计和管理**提示链 (Prompt Chains)**：当任务需要多个LLM调用协同完成时。
调整**指令/系统提示 (System Prompts)**：赋予LLM角色、明确任务目标。
管理提示的**动态元素 (Dynamic Elements)**：如用户输入、实时日期/时间等。
搜索和准备**相关知识 (RAG)**：通过外部知识库增强模型能力。
**工具定义和说明 (Tool Definitions)**：在代理系统中赋予模型使用外部工具的能力。
准备和优化**少样本示例 (Few-shot Demonstrations)**：通过案例指导模型行为。
**结构化输入和输出 (Structuring Inputs/Outputs)**：使用分隔符、JSON Schema等规范格式。
**记忆管理 (Memory Management)**：包括短期记忆（对话状态）和长期记忆（向量存储检索）。

简而言之，上下文工程旨在优化LLM上下文窗口中提供的信息，甚至包括过滤掉噪声信息，这本身就是一门需要系统测量LLM性能的科学。

上下文工程实战：AI研究代理构建

✦ 案例背景：多代理深度研究应用

文章通过一个具体的真实案例，展示了如何将上下文工程应用于多代理（multi-agent）深度研究应用的构建。虽然工具不重要（作者使用n8n），但其核心思想和架构是通用的。

该应用的核心是一个代理工作流，其架构图如下所示。本文将重点聚焦于其中的“搜索规划器”（Search Planner）代理，它负责根据用户的复杂查询，生成一个详细而具体的搜索计划。

图示释义： 这是一个多代理协作的工作流。用户查询首先进入“Search Planner”（搜索规划器）代理，该代理将生成详细的搜索计划，然后可能通过其他代理执行搜索、分析并生成报告。

✦ 系统提示 (System Prompt) 深入剖析

以下是为“搜索规划器”代理精心设计的系统提示。它不仅是简单的指令，更是一个经过反复实验和优化的上下文集合。

You are an expert research planner. Your task is to break down a complex research query (delimited by <user_query></user_query>) into specific search subtasks, each focusing on a different aspect or source type.

The current date and time is: {{$now.toISO()}}

For each subtask, provide:
1. A unique string ID for the subtask (e.g., 'subtask_1','news_update')
2. A specific search query that focuses on one aspect of the main query
3. The source type to search (web, news, academic, specialized)
4. Time period relevance (today, last week, recent, past_year, all_time)
5. Domain focus if applicable (technology, science, health, etc.)
6. Priority level (1-highest to 5-lowest)

All fields (id, query, source_type, time_period, domain_focus, priority) are required for each subtask, except time_period and domain_focus which can be null if not applicable.

Create 2 subtasks that together will provide comprehensive coverage of the topic. Focus on different aspects, perspectives, or sources of information.

Each substask will include the following information:
id: str
query: str
source_type: str #e.g.,"web","news","academic","specialized"
time_period: Optional[str] = None #e.g.,"today","lastweek","recent","past_year","all_time"
domain_focus: Optional[str] = None #e.g.,"technology","science","health"
priority: int #1(highest)to5(lowest)

After obtaining the above subtask information, you will add two extra fields. Those correspond to start_date and end_date. Infer this information given the current date and the time_period selected. start_date and end_date should use the format as in the example below:

"start_date":"2024-06-03T06:00:00.000Z",
"end_date":"2024-06-11T05:59:59.999Z",

核心启示： 这不仅仅是简单的指令，而是一个需要通过实验和迭代来提供关键上下文的过程，以使模型能以最佳状态执行任务。

核心组件与策略详解

01. 高层指令 (Instructions)

这是提供给系统的**高层指导**，明确指示其具体任务。许多AI开发者可能会止步于此，但文章强调，这仅仅是上下文工程的起点。有效的上下文工程需要进一步的细化，以告知系统问题的范围和我们期望的精确输出。

You are an expert research planner. Your task is to break down a complex research query (...) into specific search subtasks...

02. 用户输入 (User Input)

用户输入通常需要通过**分隔符 (delimiters)** 进行明确标识，这有助于避免混淆，并清晰界定用户输入与系统期望生成的内容。例如：

<user_query>What's the latest dev news from OpenAI?</user_query>

这种结构化方式，即使在处理与输出内容类型相似的输入时（如查询输入与子查询输出），也能保持高度清晰性。

03. 结构化输入与输出 (Structured Inputs and Outputs) (关键!)

这是**上下文工程的重中之重**。通过详细规定期望的数据格式，能够显著提升LLM输出的**一致性、规范性和可解析性**。这包括：

字段定义与约束： 明确每个字段的含义、类型和可能的取值范围，例如，规定优先级是1到5的整数。
示例与提示： 提供具体的示例数据格式，作为LLM生成结构化输出的参考，例如像Python类型提示或JSON模式。

Each subtask will include the following information:
id: str
query: str
source_type: str # e.g., "web","news","academic","specialized"
time_period: Optional[str] = None # e.g., "today","lastweek","recent","past_year","all_time"
domain_focus: Optional[str] = None # e.g., "technology","science","health"
priority: int # 1 (highest) to 5 (lowest)

工具（如n8n）通常支持通过JSON示例自动生成Schema，从而实现对最终输出的严格控制：

{
  "subtasks": [
    {
      "id": "openai_latest_news",
      "query": "latest OpenAI announcements and news",
      "source_type": "news",
      "time_period": "recent",
      "domain_focus": "technology",
      "priority": 1,
      "start_date": "2025-06-03T06:00:00.000Z",
      "end_date": "2025-06-11T05:59:59.999Z"
    },
    ...
  ]
}

这种方法在代理输出不一致或需要特定格式传递给工作流中下一个组件时尤为强大。

04. 工具 (Tools)

通过工具向LLM**动态地注入上下文**。例如，在提示中嵌入当前日期和时间是一种常见且高效的做法：

The current date and time is: {{$now.toISO()}}

这种上下文在处理时间敏感的查询（例如，“上周发生了什么新闻？”）时至关重要。否则，LLM只能猜测日期，导致生成次优的查询和不准确的结果。上下文工程迫使开发者明确决定“传递什么上下文”以及“何时传递”，从而消除应用中的假设和不准确性。

作者还提到，其LLM通过此工具生成的日期信息，可以根据用户定义的`time_period`自动推断出`start_date`和`end_date`，这进一步提升了搜索的精确性。

05. RAG & 记忆 (RAG & Memory)

虽然文章的案例在v1中未完全实现，但作者提出了一个重要的优化策略：通过检索增强生成 (RAG) 和**记忆机制**来提升效率和降低成本。核心思想是缓存已生成的子查询：

用户查询

检索历史记录 (向量库)

相似查询存在?

是 ✔ (复用缓存)

否 ✖ (调用LLM生成新查询)

价值点： 这是一种“聪明的上下文工程”，因为它不仅优化了提示，还在宏观层面提升了整个应用的效率、成本和延迟。作者强调，创造性和新颖的上下文工程就是真正的“护城河”！

06. 状态 & 历史上下文 (States & Historical Context)

在需要“反思”和“修正”的复杂AI工作流中，代理需要访问其**先前状态和所有历史上下文**。例如，一个代理可能需要回顾之前生成的子任务、中间结果，甚至之前所有代理的执行历史，以便在后续阶段进行优化或修订。

决策复杂性： 至于具体传递哪些历史上下文，这完全取决于你的优化目标，涉及大量的决策。
评估关键性： 这个组件的成功需要反复的迭代和严格的评估。作者再次强调：“如果你不测量所有这些东西，你怎么知道你的上下文工程努力是否奏效？”

这部分工作充满了“大量的决策制定”，是上下文工程最富有挑战性也最具潜力的领域。

高级上下文工程 [WIP]

✦ 未被完全探索的领域

文章提到，上下文工程仍有许多**未被充分探索的领域**值得未来深入研究和开发，例如：

上下文压缩 (Context Compression)：如何在有限的上下文窗口中高效地编码更多相关信息。
上下文管理与安全 (Context Management & Safety)：确保信息流动的健全性和安全性，防止过期或不相关信息污染上下文。
上下文有效性评估 (Evaluating Context Effectiveness)：如何系统性地测量和优化所提供上下文的长期效果。

作者预计，上下文工程将继续成为AI开发者/工程师的关键技能。除了手动工程，未来的趋势还将包括构建自动化方法，以提升上下文处理的效率和效果。

目录导航

上下文工程指南 | Context Engineering Guide

预览结果：