提示词工程已死？未来属于“上下文工程 (Context Engineering)”

当大语言模型应用从实验性的脚本走向复杂的生产级代理工作流（Agentic Workflow），行业内关于“提示词工程已死”的论断实际上揭示了一种更深层次的工程范式演进。长期以来，开发者习惯于通过反复修改措辞来“诱导”模型输出，这种被称为提示词工程（Prompt Engineering）的方法本质上充满了随机性与脆弱性，类似于试图通过炼金术般的咒语来掩盖系统信息的缺失。然而，对于追求高可用性和确定性的现代 AI 架构而言，单纯依赖静态文本优化的边际效应正在急剧递减，且极易因模型版本的微小更新而失效。取而代之的是上下文工程（Context Engineering）的崛起，它标志着 LLM 开发正式进入了软件工程化的新阶段。

上下文工程的核心逻辑不再局限于“如何提问”，而是通过架构设计彻底重构“模型知道什么”。在这种视角下，Prompt 不再是一段需要精雕细琢的静态文本，而是一个由代码实时组装的动态软件工件（Software Artifact）。开发者必须转变为上下文架构师，专注于设计高效的信息流管道，策略性地管理稀缺的上下文窗口（Context Window）资源。通过精准编排系统指令、动态检索增强（RAG）、自适应的少样本示例（Dynamic Few-Shot）以及高度压缩的会话状态，上下文工程能够消除模型推理过程中的不确定性。这不仅解决了模型幻觉与遗忘的问题，更重要的是，它将大模型的应用构建从一种依赖运气的艺术形式，转化为了一门可追踪、可调试且具备高度可重复性的严谨工程学科。

从“咒语”到架构：为什么提示词工程 (PE) 正在让位于上下文工程 (CE)

随着 Agentic Workflow（代理工作流）和复杂大模型应用的兴起，行业内关于“提示词工程已死”的讨论并非危言耸听，而是标志着一种工程范式的成熟。正如 Andrej Karpathy 等行业领袖所指出的趋势，单纯依赖“话术”优化的时代正在过去。对于追求生产级稳定性的工程师而言，继续沉迷于寻找完美的“咒语”（Incantations）不仅效率低下，更是一种不可扩展的技术负债。

传统的提示词工程（Prompt Engineering, PE）本质上是脆弱的。它往往依赖于试错和黑盒猜测——“如果我把这句话改成那样，模型也许会表现得更好”。这种方法在单次对话或简单脚本中尚可奏效，但在构建复杂的生产系统时，它很快就会触及天花板。依赖措辞微调的系统缺乏确定性，难以调试，且极易因模型版本更新而失效。正如 Addyo 在其分析中指出，这种做法更像是炼金术而非工程学。

为了突破这一瓶颈，上下文工程（Context Engineering, CE） 应运而生。它不再局限于打磨静态的文本字符串，而是转向设计 LLM 运行时所处的整个信息环境。上下文工程将重点从“如何提问”转移到了“模型知道什么”。这包括系统地管理系统指令（System Prompts）、动态检索的知识（RAG）、对话历史（History）以及工具输出的状态。

在上下文工程的视角下，Prompt 不再是一段静态的文本，而是一个动态构建的软件工件（Software Artifact）。它是由代码根据当前请求的上下文逻辑实时组装而成的。Inngest 的工程实践将其描述为“LLM 的软件工程”，强调这是一种架构原则：工程师需要像设计函数接口一样设计上下文的输入管道，确保模型在推理的瞬间拥有解决问题所需的最优信息集，而非仅仅依赖模型自身的训练记忆或用户的只言片语。

核心差异对比：提示词工程 vs. 上下文工程

在构建 LLM 应用时，混淆“提示词工程”与“上下文工程”是导致系统不稳定的常见原因。虽然两者都旨在优化模型输出，但它们的出发点和工程复杂度存在本质区别。提示词工程试图通过自然语言的技巧来引导模型，而上下文工程则是通过架构设计来控制模型的输入环境。

为了清晰界定两者的边界，我们可以从以下维度进行对比：

从“你怎么问”到“模型知道什么”

最根本的思维转变在于：提示词工程决定了你如何提问 (What you ask)，而上下文工程决定了推理时刻模型知道什么 (What the model knows)。

在传统的提示词工程中，开发者往往陷入“魔法词汇”的陷阱，试图通过添加 "Think step-by-step" 或模拟特定角色来掩盖上下文信息的缺失。这种方法极其脆弱，模型版本的微小更新都可能导致 Prompt 失效。

相比之下，上下文工程 将重点转移到了环境构建上。它不依赖模型去“猜”你的意图，而是通过代码逻辑，在请求发送给 LLM 之前，动态地从数据库、API 或对话历史中提取最相关的信息片段，并将其结构化地填入上下文窗口。

这种转变意味着开发者不再仅仅是“提示词编写者”，而是成为了上下文架构师。你需要设计一套逻辑，决定在有限的 Token 预算内，哪些信息是必须保留的（如系统指令），哪些是可以动态替换的（如 RAG 检索结果），以及哪些是需要压缩的（如过往对话历史）。只有当上下文环境被确定性地构建好，Prompt 的措辞优化才能真正发挥作用。

解构上下文工程：填充 Context Window 的四大核心组件

在传统的提示词工程（Prompt Engineering）中，开发者往往聚焦于如何打磨一句完美的指令。然而，在上下文工程（Context Engineering）的视角下，核心挑战在于如何管理和填充 Context Window（上下文窗口）。

Context Window 不仅仅是字符数的限制，它是大语言模型（LLM）的“工作记忆”或“注意力预算”。正如 Department of Product 所述，能否有效管理这一窗口，直接决定了 AI Agent 的可靠性与能力上限。一个未经设计的上下文窗口往往充斥着冗余信息，导致模型忽略关键指令；而优秀的上下文工程则是将窗口视为稀缺资源，通过算法逻辑动态组装以下四大核心组件，以确保每一个 Token 都具有高信噪比。

1. 系统指令 (System Instructions)

这是上下文的“宪法”层。它定义了模型的角色、核心目标以及不可逾越的边界（Guardrails）。
与简单的“你是一个助手”不同，工程化的系统指令通常包含结构化的输出格式定义（如 JSON Schema）和错误处理逻辑。在上下文工程中，这部分内容虽然相对静态，但往往需要根据任务类型进行模块化切换。

2. 动态少样本 (Dynamic Few-Shot Examples)

“Few-Shot”是提升模型表现最有效的手段之一，但上下文窗口限制了我们无法塞入所有示例。
上下文工程不再硬编码固定的示例，而是建立一个示例库（Example Store）。在推理时，系统会根据用户当前的 Query，通过语义相似度检索出最相关的 3-5 个示例动态注入窗口。这种方法让模型在不增加 Token 消耗的前提下，获得了针对当前具体场景的“即时训练”。

3. 检索增强内容 (Retrieval Content / RAG)

这是连接模型与私有数据的桥梁。Weaviate 的研究指出，上下文工程的关键在于“在正确的时间提供正确的信息”。
这一组件不仅包含从向量数据库检索的文档片段，还包括实时 API 调用的结果（如库存数据、天气信息）。工程师必须设计精密的排序（Rerank）和过滤机制，防止低相关性的检索结果“污染”上下文窗口，导致模型产生幻觉。

4. 会话历史与状态 (Conversation History/State)

这是模型的“短期记忆”。随着对话轮数增加，原始历史记录会迅速吞噬窗口空间。
Comet 的分析强调，一旦窗口被填满，早期的关键信息会被静默丢弃，导致“上下文故障”（Context Failures）。因此，上下文工程必须包含历史记录的压缩策略——是采用滑动窗口（Sliding Window）、摘要压缩（Summarization），还是选择性保留关键状态（State Preservation）。

总结：从“文本”到“架构”

上下文工程的本质，就是编写一套编排逻辑（Orchestration Logic）。它不再是单纯地写一段话，而是构建一个运行时流水线：在用户发送请求的毫秒级时间内，系统需要分析意图，从数据库拉取相关知识，检索最佳示例，修剪历史记录，最后将这四大组件无缝拼接成一个高密度的 Prompt 发送给模型。

不仅仅是 RAG：动态上下文的构建策略

许多开发者误以为上下文工程（Context Engineering）等同于简单的 RAG（检索增强生成），即“从向量数据库中检索 Top-K 文档，直接拼接到提示词中”。然而，这种简单的“文档堆砌”往往会导致模型出现“迷失中间（Lost in the Middle）”现象或由于噪声过大而产生幻觉。真正的上下文工程不仅仅是检索，更是对输入数据进行清洗、格式化与动态编排的系统性工程。

1. 结构化数据的格式优选：JSON vs. Markdown

将非结构化文档直接丢入上下文窗口是效率最低的做法。为了提高机器的可读性（Machine Readability），我们需要对检索到的内容进行预处理。

• JSON 格式：适用于需要模型进行逻辑推理、数据提取或工具调用的场景。JSON 的键值对结构能明确字段含义，减少歧义。例如，在处理用户画像或库存数据时，JSON 能比自然语言描述节省 Token 并提高准确率。
• Markdown 格式：适用于生成文章、摘要或需要保留层级关系的知识库内容。Markdown 的标题（#）和列表符号能帮助模型理解文本的语义结构。

通过提高信息密度，移除无关的 HTML 标签或冗余字符，可以让模型将有限的注意力集中在关键逻辑上。

2. 动态优先级与混合检索

静态的上下文填充无法应对复杂的真实对话。构建策略必须在“近期历史（Recency）”与“相关知识（Relevance）”之间通过算法进行权衡：

• 分层检索（Tiered Retrieval）：首先检索与用户意图强相关的知识库片段，其次检索最近 3-5 轮的对话历史以保持连贯性。
• 重排序（Re-ranking）：向量检索的相似度并不等同于从逻辑上的相关性。在检索后引入 Cross-Encoder 模型对片段进行重排序，确保最核心的信息出现在 Prompt 的开头或结尾（利用首尾效应）。

3. 系统提示词的动态触发 (Dynamic System Prompts)

上下文工程要求 System Prompt 不再是一成不变的字符串，而是根据检索内容动态生成的指令集。

• 思维链触发（Chain-of-Thought Triggers）：当检测到检索回来的上下文包含复杂的数学计算或逻辑推演时，中间件应自动在 System Prompt 中注入“请一步步思考（Let's think step by step）”的指令。
• 上下文感知门控（Context Awareness Gate）：根据查询的上下文需求，动态调整 LLM 的输入提示，例如在上下文缺失时，自动切换为“请如实告知不知道”，而非强行生成。

4. 编排层：代码即上下文

由于上述逻辑过于复杂，无法仅靠 Prompt 实现，因此上下文工程的核心逻辑通常下沉到了编排层（Orchestration Layer）。

这正是上下文工程与软件工程融合的体现：开发者需要使用 Python 中间件或像 LangGraph 这样的框架来管理状态。在这个层面上，我们编写代码来决定何时读取长期记忆、何时截断历史、以及如何将多源数据组装成最终发送给 API 的 payload。简而言之，Prompt 是结果，而编排层的代码才是上下文工程的本体。

实战落地：构建高效上下文管道 (Context Pipeline) 的关键技术

构建生产级的 AI 应用，核心不在于反复调试提示词（Prompt Engineering），而在于设计一套健壮的数据流转架构。正如 Inngest 所指出的，上下文工程本质上是针对 LLM 的软件工程，它关注的是如何通过标准化的工作流（Workflow）和编排（Orchestration），将正确的信息在正确的时间传递给模型。

一个高效的上下文管道（Context Pipeline）通常包含四个关键环节，开发者需要在架构层面进行精细的决策与权衡。

1. 意图分类与路由 (Intent Classification)

上下文构建的第一步并非盲目检索，而是“决策”。并非所有用户请求都需要加载庞大的知识库或调用外部工具。

• 架构决策：在管道入口处部署一个轻量级分类器（如微调过的 BERT 模型或低延迟的小型 LLM），用于判断用户意图。
• 执行逻辑：根据分类结果（例如：“技术咨询”、“闲聊”、“数据查询”），将请求路由到不同的上下文构建分支。这不仅能显著降低 Token 成本，还能避免无关信息干扰模型的推理能力。

2. 检索与高精度过滤 (Retrieval & Filtering)

当确定需要外部信息时，管道进入检索阶段。这里的挑战在于从海量数据中提取高密度的有效信息，而非简单的关键词匹配。

• 分块策略 (Chunking)：根据数据类型选择策略，例如对结构化数据使用固定长度分块，而对语义连贯的文档使用基于内容的分割。
• 重排序 (Re-ranking)：单纯的向量检索（Vector Search）往往不够精准。在检索后引入 Cross-Encoder 进行重排序是提升上下文质量的关键步骤。LinkedIn 上的技术讨论指出，即使检索能力很强，重排序也能确保最相关的信息被优先处理，从而减少模型幻觉。

3. 组装与剪枝 (Assembly & Pruning)

获取数据后，需要将其填充进有限的上下文窗口中。这一步不仅是简单的字符串拼接，而是对“信息预算”的管理。

• 动态组装：将系统提示词（System Prompt）、对话历史（Conversation History）和检索到的上下文块（Retrieved Chunks）按优先级合并。
• 工程权衡：开发者必须在此阶段处理“延迟 vs. 深度”的权衡。过多的上下文会增加 Time-to-First-Token (TTFT) 延迟并稀释注意力；过少则会导致信息缺失。Monte Carlo 的分析强调，当相关信息跨越多个文档时，必须通过算法过滤掉非关键片段，以保持上下文的连贯性。

4. 结构化格式 (Formatting)

最后一步是将组装好的数据转化为模型最易理解的格式。

• 机器可读性：相比于自然语言段落，现代 LLM 对结构化数据（如 JSON、XML 或 Markdown 表格）的理解能力更强。
• 分隔符技术：使用清晰的 XML 标签（如 <context>...</context>）将外部知识与用户指令隔离，可以有效防止提示词注入攻击，并帮助模型明确区分“已知事实”与“用户问题”。

通过建立标准化的 Context Pipeline，我们将原本依赖“玄学”调优的提示词工程，转化为可监控、可调试、可迭代的工程系统。

上下文窗口管理与 Token 预算策略

尽管 GPT-4、Claude 3 等模型已经支持 128k 甚至更长的上下文窗口，但在工程实践中，简单粗暴地填充窗口（Context Stuffing）往往会导致成本失控、延迟增加以及模型推理能力的下降。成熟的上下文工程需要像管理内存一样管理 Token 预算，核心在于在有限的预算内最大化信息密度。

1. 预算分配与截断策略 (Truncation Strategies)

在构建上下文管道时，首先应建立严格的 Token 预算模型。一个典型的生产级 Prompt 结构通常被划分为三个预算区域：

• 系统指令区 (System Instructions)：这是上下文的“内核”，必须固定且受保护。无论对话多长，这部分都不应被截断，因为它定义了 Agent 的行为准则和输出格式。
• 短期记忆区 (Short-term History)：通常采用滑动窗口 (Sliding Window) 机制。与其基于“消息条数”截断（例如保留最后 10 条），不如基于 Token 数量截断（例如保留最后 2000 Tokens）。
• 动态上下文区 (RAG/Tools)：这是弹性最大的区域。需要根据剩余的 Token 预算动态填充检索到的文档块。

对于超出预算的历史记录，Letta 的研究指出，智能的“驱逐策略 (Eviction Methods)”至关重要。与其简单丢弃旧消息，不如引入摘要机制 (Summarization)，将早期的对话压缩为简洁的摘要并存储在系统提示或专门的记忆块中，从而在释放 Token 空间的同时保留关键的上下文连续性。

2. 避免“中间迷失” (Lost in the Middle)

仅仅将信息塞入窗口是不够的，信息的位置对模型性能有显著影响。研究表明，LLM 往往对位于上下文开头（System Prompt）和结尾（最新 User Query）的信息关注度最高，而位于中间的长文档或历史记录容易被“忽略”。

在组装上下文时，应遵循以下工程原则：

• 关键指令置顶：核心任务定义必须位于 System Prompt 的最前端。
• 高相关性内容置底：在 RAG 检索中，经过 Re-ranking (重排序) 后得分最高的文档块，应尽可能靠近用户的当前问题（即 Prompt 的尾部），而不是被埋没在中间的历史记录里。

3. 优先级与压缩 (Prioritization & Compression)

当检索到的上下文远超窗口限制时，必须引入优先级排序机制。这不仅仅是简单的相似度搜索，而是需要引入后置重排序 (Post-Retrieval Re-ranking)。

• 分级过滤：首先通过向量检索获取宽泛的候选集（Recall），然后使用 Cross-Encoder 等模型对候选集进行精细打分，仅保留相关性得分超过阈值的片段。
• 语义压缩：对于必须保留但篇幅过长的参考资料，可以使用小模型预先提取关键实体或摘要，再注入到主模型的上下文中。正如 The Low End Disruptor 所述，上下文工程的核心动作可以归纳为“写入、选择、压缩和隔离”，其中压缩是平衡 Token 成本与任务表现的关键手段。

通过精细化的 Token 预算管理，开发者可以在不牺牲模型推理质量的前提下，显著降低 API 调用成本并提升系统的响应速度。

案例复盘：从提示词优化到上下文重构

为了直观地展示上下文工程（Context Engineering, CE）与传统提示词工程（Prompt Engineering, PE）在解决复杂业务问题时的本质区别，我们以一个典型的电商智能客服场景为例。

假设我们需要构建一个处理“退款政策咨询”的 AI Agent。该电商平台的退款规则极为复杂：不同品类（电子产品、生鲜、服饰）有不同的时效，VIP 用户享有特殊豁免权，且跨境订单适用另一套法律条款。

场景 A：提示词工程（PE）的困局——“超级提示词”

在传统的 PE 思路中，工程师倾向于将所有业务逻辑“塞”进 System Prompt 中。试图通过精细的文字打磨，让 LLM 理解整本员工手册。

构建方式：
开发者编写了一个长达 3000 tokens 的提示词，包含了所有类别的退款规则、例外条款和语气要求。

System: 你是一个专业的客服。请严格遵守以下规则：
1. 电子产品签收后 7 天内可退，除非是质量问题。
2. 生鲜产品不支持无理由退货。
3. VIP 用户（等级 > 3）对电子产品享有 15 天退货期。
4. 如果是跨境订单（SKU 以 HK 开头），需扣除关税。
...（此处省略 50 条规则）...
当用户询问时，请先判断用户身份，再计算日期，最后给出结论。

失败案例（Edge Case）：
用户提问： “我是 VIP4，上个月买的那个 HK 开头的耳机坏了，能全额退吗？”

结果分析：
模型极易发生幻觉（Hallucination）或逻辑冲突。

1. 注意力分散：在长上下文中，模型可能忽略了“跨境订单扣税”的条款，而过度关注“VIP 15天”的规则。
2. 推理负担过重：模型需要同时处理身份验证（VIP4 > 3?）、SKU 识别、日期计算（“上个月”是几天前？）以及规则优先级的排序。
3. 维护噩梦：一旦运营部门修改了“生鲜”的规则，开发者就需要重新测试整个超级提示词，因为修改一部分可能会破坏另一部分的逻辑稳定性。正如行业观察者所言，Prompt Engineering 的调试往往只能靠猜测和重写，缺乏确定性。

场景 B：上下文工程（CE）的解法——动态流水线

在 CE 思路中，我们不再强求模型“记住”规则，而是通过工程手段构建一个动态上下文。我们将任务拆解为：意图识别 -> 信息检索/状态注入 -> 最终生成。

构建方式：
系统后端在调用 LLM 生成回答之前，先执行了一系列确定性的代码逻辑：

1. 获取状态：API 查询数据库，确认用户等级为 VIP4，订单 SKU 为 HK-Headphone，购买日期距今 28天。
2. 检索规则：基于 SKU 和用户等级，RAG 系统仅检索出两条相关条款：“跨境商品质量问题全额退款”和“VIP 电子产品延保政策”。
3. 上下文组装：构建一个轻量级、高密度的 Prompt。

System: 你是退款专员。请根据以下【当前事实】回答用户。不要引用无关规则。

【当前事实】
- 用户等级：VIP4
- 商品类型：跨境电子产品
- 购买时长：28天
- 适用条款 A：跨境商品若存在质量问题，免除关税扣除，支持全额退款。
- 适用条款 B：VIP 用户对电子产品享有 30 天质保期（覆盖当前 28 天）。

User: 我是 VIP4，上个月买的那个 HK 开头的耳机坏了，能全额退吗？

成功结果：
模型只需做最简单的语义转换：“根据条款 A 和 B，您可以全额退款。”

核心收益对比

通过从 Prompt 优化转向上下文重构，我们获得了工程层面的显著提升：

这种转变体现了 AI 应用开发的成熟路径：从试图用自然语言“催眠”模型，转变为用系统架构“武装”模型。正如 Anthropic 的研究指出，随着知识库的增长，单纯依赖长上下文提示词不再可行，通过 RAG 或上下文检索（Contextual Retrieval）构建动态知识库 才是可扩展的解决方案。

结论：上下文工程是迈向 AI Agent 的必经之路

提示词工程（Prompt Engineering）教会了我们如何与聊天机器人“对话”，而上下文工程（Context Engineering）则赋予了我们构建可靠 AI 应用的能力。随着大模型能力的提升和上下文窗口（Context Window）的不断扩展，AI 开发的瓶颈正在发生本质性的转移：问题不再是“如何通过精妙的措辞来诱导模型”，而是“如何构建一个系统，在正确的时间为模型提供正确的信息”。

正如 WTF In Tech 的分析所指出的，提示词工程关注的是用户的单次输入，而上下文工程关注的是整个信息空间的动态管理。在迈向 AI Agent（智能体）的进程中，这种系统化的思维尤为关键。

从“对话者”到“架构师”的思维跃迁

许多开发者误以为，随着 Gemini 1.5 Pro 或 Claude 3 等模型支持百万级 Token 的上下文，工程复杂度会随之降低。事实恰恰相反。虽然窗口变大了，但模型的“注意力预算”依然是稀缺资源。无差别地将所有数据塞入上下文，不仅会增加延迟和成本，还会引入噪音，导致模型在关键指令上产生幻觉（Hallucination）。

Weaviate 的工程实践强调，上下文工程的核心在于将有限的窗口视为一种稀缺资源，围绕它设计检索（RAG）、记忆系统和工具集成。一个成熟的 AI 架构师不再纠结于某个 Prompt 是用“请”还是“必须”，而是专注于设计数据管道，确保模型只处理高信噪比（High-Signal）的 Token。

它是构建自主智能体的基石

如果说提示词是 AI 的短期指令，那么上下文工程就是 AI 的长期记忆与感知系统。对于需要长期运行、处理复杂任务的 AI Agent 而言，仅仅依赖单次对话的上下文是远远不够的。

Anthropic 在其工程博客中提到，高效的上下文工程包括“结构化笔记”和“代理记忆”（Agentic Memory）。通过将关键信息持久化存储在上下文窗口之外，并在需要时精准回传，Agent 才能在跨会话的任务中保持状态一致性，实现真正的自主决策。

展望

未来的 AI 开发将不再是自然语言的文字游戏，而是对信息流的精密编排。掌握上下文工程，意味着你能超越普通用户的“聊天”层面，深入到系统架构的核心。这是区分一名普通 AI 爱好者与一位资深 AI 应用架构师的关键技能鸿沟。

当提示词工程逐渐隐入幕后，成为一种基础的交互原语时，上下文工程将站在舞台中央，定义下一代智能应用的高度与边界。