推荐语
从提示词工程到上下文工程，AI开发正迎来系统化思维的新时代。Shopify CEO和OpenAI专家揭示如何通过精心设计信息环境提升Agent性能。
核心内容：
1. 上下文工程的定义与核心价值
2. 对比传统提示词工程的突破性优势
3. 在Agent开发中的具体应用指南
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
2025 年的 AI 开发领域，一个新的术语正在迅速取代 "提示词工程（Prompt Engineering）" 成为行业焦点 ——上下文工程(Context Engineering)。这一概念由 Shopify CEO Tobi Lutke 率先提出，并迅速获得前 OpenAI 研究员 Andrej Karpathy 等技术领袖的力挺。Karpathy 在社交媒体上明确表示："我支持 ' 上下文工程 ' 而非 ' 提示词工程 '"，这一表态标志着LLM大模型应用开发从单点思维向系统思维的根本转变。
与提示词工程相比，上下文工程提供了更为全面和系统的方法论。Lutke 对上下文工程的定义是："它更好地描述了核心技能 —— 为任务提供所有必要的上下文，使LLM能够合理地解决问题的艺术"。这一定义揭示了上下文工程的本质：它不是简单地构造几个提示词，而是精心设计和管理整个信息环境，使 LLM 能够在其中高效、可靠地运行。
在Agent开发中，上下文工程的核心价值在于解决了传统提示词工程的局限性。Karpathy 特别强调："在工业级 LLM 应用中，上下文工程才是关键所在 —— 一门既讲科学又讲直觉的技术活，要把上下文窗口精确地填入下一步所需的信息"。这一观点得到了 DeepMind 高级 AI 工程师 Philipp Schmid 的认同，他指出："如今很多 Agent 的失败，不是模型能力不足，而是上下文没设计好"。
「Context Engineering Guide」是 ELVIS 在 DAIR AI 最新推出的上下文工程详细解读，推荐Agent开发者学习。
什么是上下文工程？
上下文工程是提示词工程的升级版，本质上是优化你给 AI 模型提供的指令和背景信息，让它能更高效、准确地完成任务。几年前，有些 AI 专家觉得提示工程会过时，但事实恰恰相反，它不仅没消失，反而变得更重要，进化成了上下文工程。
很多人写过上下文工程的定义（比如Ankur Goyal、Walden Yan），但我想分享我的看法，并给一个具体指南，讲讲怎么在开发AI Agent时用上下文工程。
我不确定谁先提出"上下文工程"，但我们可以参考Dex Horthy的图，里面简要解释了这个概念。
图中，上下文工程涵盖了RAG、提示词工程、状态/历史、标准化输出、记忆等部分。
上下文工程不只是随便给 AI 扔一句问题（这叫“盲目提示”），而是像个建筑师一样，精心设计指令、用户输入、输出格式，甚至是外部工具和历史数据的使用，确保 AI 明白你的意图，产出你想要的结果。
从开发者角度看，上下文工程是个迭代过程，优化给AI模型的指令和上下文，达到预期结果。这包括用正式流程（比如评估管道）来衡量策略是否有效。
我给上下文工程下了个更广泛的定义：为LLM和高级AI模型设计和优化指令及相关上下文，让它们有效完成任务的过程。这不仅包括文本大模型，还包括优化多模态模型的上下文，这些模型越来越常见。这涵盖所有提示词工程工作和相关流程，它包括以下关键部分：
设计指令：调整指令/系统提示词，设计和管理提示链，告诉 AI 具体要做什么，比如“把复杂问题拆成小任务”。
用户输入：管理提示词的动态元素，提供清晰的问题或数据，比如“查询 OpenAI 的最新开发动态”，准备和优化少样本演示。
结构化输入输出：规定 AI 的输入和输出格式，比如用 JSON 格式返回结果。
工具调用：让 AI 用外部工具，比如获取当前时间或搜索网页。
RAG 与记忆：通过 RAG 或记忆机制，从向量存储检索知识（长期记忆），提供相关背景或缓存历史查询。
管理状态与历史上下文：让 AI 记住之前的操作或状态（短期记忆），方便优化或修改。
上下文工程的目标是让 AI 的“上下文窗口”（Context Window）里的内容尽可能精准、有效，同时过滤掉无关或噪声信息。
这里我会带大家看一个具体例子，讲讲构建AI 智能体时上下文工程是什么样的。
上下文工程的实际应用
看看我最近做的一个例子：为个人用的多智能体深度研究应用做上下文工程。
我在n8n里构建了Agent工作流，工具不重要。完整的Agent架构像这样：
工作流中的“搜索规划智能体”负责根据用户查询生成搜索计划。
系统提示
这是我为这个子Agent写的系统提示：
你是专业的研究规划师。任务是把复杂的研究查询（用<user_query></user_query>界定）分解成具体的搜索子任务，每个子任务专注不同方面或来源类型。
当前日期和时间：{{ $now.toISO() }}
每个子任务需要：1. 唯一字符串ID（比如'subtask_1'、'news_update'）2. 专注主查询某方面的具体搜索查询3. 搜索来源类型（网页、新闻、学术、专业）4. 时间相关性（今天、上周、最近、过去一年、所有时间）5. 领域重点（如果适用，比如技术、科学、健康等）6. 优先级（1最高到5最低）
每个子任务必须有所有字段（id、query、source_type、time_period、domain_focus、priority），除非时间周期和领域重点不适用，可以为null。
创建2个子任务，共同覆盖主题的全部内容。专注不同方面、视角或信息来源。
每个子任务包括：id: strquery: strsource_type: str # 比如"web"、"news"、"academic"、"specialized"time_period: Optional[str] = None # 比如"today"、"last week"、"recent"、"past_year"、"all_time"domain_focus: Optional[str] = None # 比如"technology"、"science"、"health"priority: int # 1最高到5最低
获取子任务信息后，添加start_date和end_date两个字段。根据当前日期和所选时间周期推断这些信息。格式如下："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>
注意用了分隔符，这是为了更好地构建提示词结构，避免混淆，明确用户输入和我们希望系统生成的内容。有时输入的信息类型和希望模型输出的内容相关（比如查询是输入，子查询是输出）。
结构化输入和输出
除了高级指令和用户输入，我还花了很多精力在规划智能体需要生成的子任务细节上。这是给规划智能体的详细指令，让它根据用户查询创建子任务：
每个子任务需要：
1. 唯一字符串ID（比如'subtask_1'、'news_update'）2. 专注主查询某方面的具体搜索查询3. 搜索来源类型（网页、新闻、学术、专业）4. 时间相关性（今天、上周、最近、过去一年、所有时间）5. 领域重点（如果适用，比如技术、科学、健康等）6. 优先级（1最高到5最低）
每个子任务必须有所有字段，除非时间周期和领域重点不适用，可以为null。
创建2个子任务，共同覆盖主题的全部内容。专注不同方面、视角或信息来源。
仔细看指令，我列出了希望规划智能体生成的必要信息，还有提示词和例子，帮助指导数据生成过程。这很重要，能给Agent提供关于预期输出的额外上下文。比如，如果不告诉它优先级是1-5，系统可能会用1-10的范围。这些上下文很重要！
接下来是结构化输出。为了从规划智能体得到一致的输出，我们还提供了子任务格式和字段类型的上下文。这是作为额外上下文传给智能体的示例：
每个子任务包括：id: strquery: strsource_type: str # 比如"web"、"news"、"academic"、"specialized"time_period: Optional[str] = None # 比如"today"、"last week"、"recent"、"past_year"、"all_time"domain_focus: Optional[str] = None # 比如"technology"、"science"、"health"priority: int # 1最高到5最低
另外，在n8n里可以用工具输出解析器，本质上是用来构建最终输出结构的。我用的选项是提供JSON示例：
每个子任务包括：id: strquery: strsource_type: str time_period: Optional[str] = None domain_focus: Optional[str] = None priority: int
然后工具会从这些示例自动生成模式，让系统解析和生成合适的结构化输出，比如：
[ { "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开发者忽略的点，希望上下文工程能让这些技术更清晰。当Agent输出不一致，需要用特殊格式传给工作流下一个组件时，这是很强大的方法。
工具
我们用n8n构建智能体，很容易在上下文里加入当前日期和时间，像这样：
当前日期和时间：{{ $now.toISO() }}这是n8n里的简单函数，通常会做成专用工具，让内容更动态（比如只在查询需要时获取日期时间）。这就是上下文工程：迫使开发者决定是否传递上下文，以及何时传给LLM，消除应用中的假设和不准确。
日期和时间是系统的重要上下文，否则处理需要当前日期时间的查询时表现不好。比如，让系统搜索上周OpenAI的最新新闻，它会猜测日期，导致查询不好，搜索结果不准确。有了正确的日期时间，系统能更好推断日期范围，这对搜索Agent和工具很重要。我把这作为上下文的一部分，让LLM生成日期范围：
获取子任务信息后，添加start_date和end_date字段。根据当前日期和所选时间周期推断这些信息，格式如下："start_date": "2024-06-03T06:00:00.000Z","end_date": "2024-06-11T05:59:59.999Z",
我们关注架构中的规划智能体，不需要加太多工具。另一个有用的工具是检索工具，根据查询检索相关子任务，下面讨论这个想法。
RAG & 记忆
我建的深度研究应用第一个版本不需要短期记忆，但有个版本会为不同用户查询缓存子查询，这能优化工作流速度。如果用户之前用过类似查询，可以把结果存在向量存储里，搜索时就不用重新生成子查询，节省LLM API的延迟和成本。
这是聪明的上下文工程，让应用更动态、便宜、高效。上下文工程不只是优化提示，还是为目标选择正确的上下文。还可以更有创意地维护向量存储，把现有子任务加入上下文。有创意的上下文工程是优势！
状态与历史上下文
深度研究Agent v1没展示，但项目的重要部分是优化结果生成最终报告。很多时候，Agent系统需要修改部分或全部查询、子任务，以及从网络搜索API获取的数据。这意味着系统会多次尝试解决问题，需要访问之前的状态和历史上下文。
在我们的用例中，这可能是让Agent访问子任务状态、修订（如果有）、工作流中每个Agent的过去结果，以及修订阶段需要的其他上下文。传递什么内容取决于优化目标，这里需要做很多决策。上下文工程不简单，需要多次迭代。这就是为什么评估很重要：不衡量怎么知道上下文工程有没有用？
高级上下文工程[展望]
本文没涵盖上下文工程的其他方面，比如上下文压缩、管理技术、安全性，以及评估上下文有效性。未来文章会分享这些主题的想法。
上下文可能变低效（充满陈旧不相关的信息），需要特殊评估流程发现这些问题。
我认为上下文工程会成为AI开发者的重要技能。除了手动上下文工程，还可以构建自动化方法。我见过一些工具尝试这样做，但这个领域需要更多进展。
粤ICP备14082021号
免费POC，
零成本试错
