摘要

在AI時代，“提示工程”正在讓位于更強大的“上下文工程”。上下文工程不僅是寫一個提示詞，而是為模型設計、收集、組織所有必要的信息與工具，使其能在恰當的時間以最優的方式完成任務。這一理念正成為打造高效AI智能體的關鍵。

1. 從提示工程到上下文工程

在過去，AI應用的核心技能是編寫精確的提示詞（Prompt Engineering）。然而，隨著大型語言模型（LLM）和自主智能體（Agents）的普及，我們發現，影響智能體成敗的最大因素不再是模型的性能，而是提供給它的“上下文”質量。

Tobi Lutke 將上下文工程（Context Engineering）定義為：

“為任務提供所有使其在LLM中可被合理解決的上下文藝術。”

2. 什么是上下文？

上下文不僅僅是你輸入給LLM的一段問題，而是模型在生成回答前看到的所有信息合集，包括但不限于：

• 指令 / 系統提示：設定模型行為的初始規則和示例。
• 用戶提示：用戶的即時提問或任務。
• 對話狀態 / 歷史記錄（短期記憶）：當前對話的來龍去脈。
• 長期記憶：跨會話保存的知識庫、用戶偏好、過往項目摘要。
• 檢索信息（RAG）：來自外部數據庫、文檔、API的最新資料。
• 可用工具：模型能調用的功能列表（如發送郵件、查庫存）。
• 結構化輸出定義：輸出內容的格式要求（如JSON對象）。

3. 為什么上下文工程是關鍵？

“便宜的演示”與“神奇的產品”差別，并不在于代碼的復雜度，而在于提供給模型的上下文是否充足。

示例對比：

廉價Demo

• 上下文：僅包含用戶問“明天能不能開個短會？”
• 輸出：

明天可以，請問您方便的時間是？

神奇Agent

• 上下文額外包含：你的日程（顯示明天已滿）、與對方的歷史郵件（確定使用輕松語氣）、聯系人信息（識別對方為重要合作伙伴）、可用工具（發送邀請、發郵件）。
• 輸出：

嘿 Jim！明天我全天排滿，周四上午有空，方便嗎？我已發了邀請，等你確認。

這里的差異不來自“更智能的模型”，而是上下文質量的差異。

4. 上下文工程的本質

上下文工程不僅是提示詞的擴展，而是一套系統化的工作流：

核心原則

1. 系統，而非字符串：上下文是調用LLM前運行的系統產出，而非靜態模板。
2. 動態生成：根據任務需求實時構建上下文，比如調取日程、搜索網絡等。
3. 信息與工具匹配：在合適的時間提供合適的知識與可用工具，避免遺漏關鍵信息。
4. 格式優化：信息呈現方式影響效果——簡要摘要比冗長原文更有效，工具Schema需清晰明確。

5. 落地實施建議

• 明確業務場景：要解決的任務類型與目標。
• 定義輸出格式：確定模型回答的結構與風格。
• 將必要信息結構化：避免無序數據輸入模型。
• 建立自動化上下文構建流程：整合記憶、檢索、外部API調用。

6. 結論

未來構建強大智能體的關鍵，不是“湊一個提示詞”或等待模型升級，而是在合適的時間，以合適的格式，為模型提供合適的上下文。這是一項跨業務、技術、產品的協作挑戰，需要精確理解任務、明確目標輸出，并高效組織信息。

本文轉載自????知識圖譜科技????，作者：Wolfgang