上下文工程指南
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：提示工程正在进阶为上下文工程！本文用一个n8n智能体案例揭示：结构化输出、动态时间注入、RAG缓存优化已成LLM提升效能的核心三板斧。文章来自编译。
什么是上下文工程？
几年前，很多顶尖AI研究者甚至宣称提示工程到现在就该消亡了。
显然这个结论是大错特错的，事实上，提示工程如今比以往任何时候都更重要。
重要到以至于这个东西现在正被重新包装为"上下文工程"。
没错，这又是一个花哨术语，用来描述调整大语言模型（LLM）任务执行所需的指令和相关背景的关键过程。
关于上下文工程已有诸多讨论（Ankur Goyal, Walden Yan, Tobi Lutke, Andrej Karpathy等），但我想分享自己的观点，并通过开发AI智能体工作流的具体步骤，展示上下文工程的实践应用。
虽然不确定谁最先提出"上下文工程"一词，但我们会基于Dex Horthy的这张示意图简要说明其内涵。
我个人比较青睐"上下文工程"这个说法，因为它更全面地涵盖了提示工程的核心工作及相关任务。
人们常质疑提示工程的专业性，因为许多人将其与"盲提示"（如在ChatGPT这样的大模型中输入的简短任务描述）混为一谈。
盲提示只是向系统提问，而提示工程则需要精心设计提示的上下文和结构——或许它早就该叫做上下文工程。
上下文工程是更高级的阶段：你需要设计完整的上下文架构，这往往需要通过严谨方法获取、增强和优化系统知识，不是简单提示就能搞定的。
从开发者视角看，上下文工程是通过迭代过程优化指令与上下文，令LLM达成预期目标。
这包括了建立评估流程来衡量策略有效性。
鉴于AI领域发展很快，我建议扩展上下文工程定义：为LLM和先进AI模型设计优化指令与相关上下文，令其能高效执行任务的过程。
这个定义不仅涵盖了文本型LLM，还包括日益普及的多模态模型上下文优化。
上下文工程涉及到提示工程以及以下相关过程：
设计管理提示链（如适用）
调试指令/系统提示
管理提示的动态元素（如用户输入、日期时间等）
搜索准备相关知识（即RAG）
查询增强
工具定义与说明（智能体系统场景）
准备优化小样本演示
结构化输入输出（如分隔符/JSON格式）
短期记忆（状态/历史上下文管理）与长期记忆（向量库检索相关知识）
以及其他优化LLM系统提示的技巧
简言之，上下文工程旨在优化提供给LLM上下文窗口的信息。
这也意味着需过滤噪声信息——这本身就是门学问，需要系统性地衡量LLM表现。
虽然大家都在讨论上下文工程，但下文会通过构建AI智能体的实际案例来带你亲历实践。
上下文工程实战
让我们看看我最近为自建多智能体深度研究应用实施上下文工程的具体案例
这个智能体工作流是用n8n开发的（但工具选择不重要），完整架构如下：
工作流中的"搜索规划智能体"负责根据用户查询生成搜索计划
以下是为该子智能体编写的系统提示：
你是一名专业研究规划师，任务是将复杂研究查询（由<user_query></user_query>分隔）拆分为具体搜索子任务，每个子任务聚焦不同方面或来源类型
当前日期时间：{{ $now.toISO() }}
每个子任务需包含：
1. 子任务唯一字符串ID（如'subtask_1', 'news_update')
2. 聚焦主查询某方面的具体搜索语句
3. 搜索来源类型（网络/新闻/学术/专业库）
4. 时间范围（今日/上周/近期/去年/不限时）
5. 适用领域（技术/科学/健康等）
6. 优先级（1最高-5最低）
除time_period和domain_focus可不填外，其余字段(id/query/source_type/time_period/domain_focus/priority)均为必填
创建2个能全面覆盖主题的子任务，侧重不同信息维度或来源
获取子任务信息后需添加两个字段：start_date和end_date。请根据当前日期与所选time_period推导日期范围，格式示比方说下：
"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z",
这个提示的多个环节都需要仔细考量：我们究竟该提供哪些具体上下文，才能让规划智能体高效执行任务？如你所见，这不仅要设计简单提示或指令，更需要实验精神，并为模型提供关键上下文，从而优化任务的执行。
下面我们就来分解构成有效上下文工程的核心要素
指令
指令是为系统提供的高层操作指南
"你是一名专业研究规划师，任务是将复杂研究查询（由<user_query></user_query>分隔）拆分为具体搜索子任务，每个子任务聚焦不同方面或来源类型"
许多初学者甚至资深AI开发者可能就此止步。看过完整提示后，你会理解我们还需提供多少额外上下文才能让系统按预期工作——这正是上下文工程的核心：让系统更清晰理解问题范围及具体需求
用户输入
系统提示中未展示用户输入，不过下面是一个示例：
<user_query>OpenAI最新开发动态有哪些？</user_query>
注意分隔符的使用能让提示结构更清晰。这一点很重要：既可以避免混淆，又能明确划分用户输入和系统生成内容。有时输入信息类型与我们希望模型输出的内容是直接关联的（比方说查询是输入，子查询是输出）
结构化输入输出
除高层指令和用户输入外，你可能注意到我花费路大量精力来定义规划智能体生成子任务的细节要求：
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.
仔细看看这些指令，你会发现我专门规划了要求规划智能体生成的字段结构，并通过提示示例引导数据生成过程。这种补充上下文对明确预期至关重要——若不声明优先级用1-5级，系统可能默认采用1-10级尺度。上下文细节决定成败！
接着谈谈结构化输出。为获取规划智能体的稳定输出，我们还提供了子任务格式和字段类型的上下文说明。以下是传递给智能体的额外上下文示例，用于明确输出预期：
每个子任务需包含以下信息：
id: str
query: str
source_type: str# 如："网络"、"新闻"、"学术"、"专业库"
time_period: Optional[str] = None# 如："今日"、"上周"、"近期"、"去年"、"不限时"
domain_focus: Optional[str] = None# 如："技术"、"科学"、"健康"
priority: int# 1（最高）至5（最低）
此外，在n8n中可使用工具输出解析器结构化最终输出。我采用的方案是提供如下JSON示例：
{
"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"
},
{
"id": "openai_official_blog",
"query": "OpenAI official blog recent posts",
"source_type": "web",
"time_period": "recent",
"domain_focus": "technology",
"priority": 2,
"start_date": "2025-06-03T06:00:00.000Z",
"end_date": "2025-06-11T05:59:59.999Z"
},
...
}
工具将自动生成数据模式，让系统能解析并生成规范的结构化输出，像下面这样：
[
{
"action": "parse",
"response": {
"output": {
"subtasks": [
{
"id": "subtask_1",
"query": "OpenAI recent announcements OR news OR updates",
"source_type": "news",
"time_period": "recent",
"domain_focus": "technology",
"priority": 1,
"start_date": "2025-06-24T16:35:26.901Z",
"end_date": "2025-07-01T16:35:26.901Z"
},
{
"id": "subtask_2",
"query": "OpenAI official blog OR press releases",
"source_type": "web",
"time_period": "recent",
"domain_focus": "technology",
"priority": 1.2,
"start_date": "2025-06-24T16:35:26.901Z",
"end_date": "2025-07-01T16:35:26.901Z"
}
]
}
}
}
]
虽然看似复杂，但现代工具通常自带结构化输出功能，无需自行实现。n8n让这部分上下文工程变得轻松——令人惊讶的是许多AI开发者常忽略这一要点。上下文工程应让这些关键技术更受关注，尤其在智能体输出不稳定且需特殊格式传递时，这种做法尤为强大。
工具
使用n8n构建智能体时，可便捷地植入当前日期时间上下文：
当前日期时间：{{ $now.toISO() }}
n8n这类简单函数调用很便利，但通常需构建专用工具实现动态上下文（比方说仅当查询需要时才获取日期时间）。这正是上下文工程的意义：它迫使构建者明确决策什么时候传递什么样的上下文，从而消除应用中的假设和误差。
日期时间对系统至关重要，否则在涉及到时效性的查询时将表现不佳。比方说如果要求查询"OpenAI上周开发动态"，系统可能会推测日期错误，导致搜索效果不佳。提供准确时间后，系统就能正确推导出时间范围（这对搜索智能体和工具很关键）。为此我特别添加了推导指令：
"获取子任务信息后需添加两个字段：start_date和end_date。请根据当前日期与所选time_period推导日期范围，格式示例如下：
"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z"
当前聚焦的是架构中的规划智能体，无需添加过多工具。唯一值得补充的是根据查询检索相关子任务的工具，我们后续会讨论这一设计。
RAG与记忆机制
当前自建深度研究应用邪恶第一版不需要短期记忆，但已实现用户查询子任务的缓存功能。
这对实现工作流加速优化很有帮助：如果用户曾发起过类似的查询，可将结果存入向量数据库复用，避免重复生成子任务计划。
记住：每次调用LLM API都会增加延迟和成本
这就是上下文工程实践的聪明之处——让应用更动态、更经济、更高效。
请注意：上下文工程不仅是优化提示，更是为目标精准选择上下文。
你还可以创新设计向量库维护机制与子任务调用方式。
创新性的上下文工程才是核心竞争力！
状态与历史上下文
深度研究智能体的第一版必备那个没有展示这一功能，但项目核心是优化最终报告的生成。
智能体系统往往要修正查询、子任务及网络API数据，这意味着系统需多次尝试并访问系统的历史上下文。
对于实践来说意味着什么呢？以本案为例：需要让智能体访问子任务状态、修订记录、各环节历史结果等修正阶段所需的上下文。
此时传递的上下文取决于优化目标，决策过程将极其复杂。
上下文工程绝非易事，你可想象该组件需多少轮迭代。
所以我会不断强调评估等环节的重要性：如果没有量化指标，如何验证上下文工程成效？
结语
本文未涵盖上下文工程的诸多方面（如上下文压缩/管理技术/安全性/有效性评估），未来将深入探讨。
上下文可能会被稀释，变得低效（充斥陈旧无关信息），需专门评估流程监测此类问题。
我的预计是，上下文工程会不断演进，发展成为AI开发者的核心技能。
除人工工程外，自动化上下文处理也有广阔前景。
当前工具仍处在早期阶段，这一领域需更多突破。
推荐阅读近期上下文工程相关文献：
译者：boxi。
