在 AI 領域，2025 年你最需要掌握的技能：上下文工程 原創 精華
編者按： 您是否曾感覺到，盡管精心設計了提示詞，AI 的表現卻依然不盡如人意？甚至隨著上下文越來越長，模型反而更容易“胡言亂語”？
我們今天為大家帶來的這篇文章，作者的核心觀點是：“提示詞工程”已經不夠用了，下一代 AI 應用的核心競爭力在于“上下文工程”（Context Engineering）。
文章系統地闡述了為何在智能體（Agent）時代，單純堆砌信息的“提示詞工程”思維會導致性能下降、成本飆升。作者提出，上下文工程是一套系統級的架構方法，它強調動態地、有策略地為模型組合信息，包括系統指令、對話歷史、用戶記憶、檢索結果和工具定義等，從而在有限的上下文窗口中實現最優性能。文章還深入分析了生產環境中實施上下文工程面臨的四大挑戰，并提供了五項關鍵優化策略，最后通過一個醫療健康領域的實例展示了如何構建一個真正的上下文驅動型 AI 系統。
作者 | Paul Iusztin
編譯 | 岳揚
開門見山地說：如果你現在還在只談論“提示詞工程”，那你就已經落后了。 在大語言模型（LLM）的發展初期，精心設計提示詞確實是核心任務。
對于 2022 年的簡單聊天機器人（chatbots）來說，這已經綽綽有余了。到了 2023 年，檢索增強生成（RAG）技術興起，我們開始為模型注入領域知識。而現在，我們擁有了能使用工具、具備記憶能力的智能體，它們需要建立長期關系并維持狀態。提示詞工程那種只關注單次交互的思路已經完全不夠用了。
隨著 AI 應用變得越來越復雜，單純往提示詞里塞更多信息會引發一些嚴重的問題。首先是上下文衰減（context decay）現象。模型會被冗長雜亂的上下文搞糊涂，導致產生幻覺和錯誤答案。最近一項研究發現，一旦上下文超過 32,000 個 tokens，模型回答的正確率就會開始明顯下降 —— 這遠低于宣傳的 200 萬 token 極限[1]。
其次，上下文窗口（模型的工作記憶）是有限的。即使上下文窗口再大，每個 token 都會增加成本和延遲。我曾經構建過一個工作流，把研究資料、指南、案例和評審意見全都塞進上下文。結果呢？運行一次需要 30 分鐘。根本沒法用。這種“上下文增強生成（context-augmented generation）”的天真做法（或者說簡單粗暴的信息堆砌），在生產環境中注定會失敗。
Context Engineering Guide 101
這正是上下文工程的意義所在。它標志著思維模式的轉變：從精心設計單個提示詞，轉變為架構整個 AI 的信息生態系統。我們動態地從記憶庫、數據庫和相關工具中收集并篩選信息，只為 LLM 提供當前任務最必需的內容。這讓我們的系統更精準、更快速，也更經濟。
01 理解什么是上下文工程
那么，上下文工程究竟是什么呢？標準的解釋是：這是一個最優化問題 —— 通過尋找最佳的功能組合來構建上下文，從而在特定任務中最大化 LLM 的輸出質量[2]。
簡而言之，上下文工程的核心在于策略性地將正確的信息，在正確的時機，以正確的格式填入模型有限的上下文窗口。我們從短期記憶和長期記憶中檢索必要的片段來完成任務，同時避免讓模型過載。
安德烈·卡帕西（Andrej Karpathy）對此有一個精妙的類比：上下文工程就像一種新型的操作系統，模型充當 CPU，而其上下文窗口則相當于 RAM[3]。正如操作系統需要管理哪些數據可以放入 RAM，上下文工程則精心策劃哪些內容占據模型的工作內存。需特別注意，上下文僅是系統總工作內存的子集；有些信息可以保留在系統中，而無需在每次交互時都傳遞給 LLM。
這門新學科與單純編寫優質提示詞有著本質的區別。要有效地設計上下文，你首先需要弄清楚哪些組成部分是你可以實際操作的。
上下文工程并非要取代提示詞工程。相反，你可以直觀地將提示詞工程視為上下文工程的一部分。在收集合適上下文的同時，你仍然需要學習如何撰寫優質提示詞，并確保將上下文填入提示詞中而不導致 LLM 出錯 —— 這正是上下文工程的意義所在！更多細節請參見下表。
提示詞工程 vs. 上下文工程 | ||
維度 | 提示詞工程 | 上下文工程 |
復雜度 | 手動進行字符串操作 | 系統級的、多組件的優化 |
主要關注 | 如何表述任務 | 提供哪些信息 |
影響范圍 | 單次交互優化 | 整個信息生態系統 |
狀態管理 | 主要為“無狀態” | 本質為“有狀態”，具有顯式的內存管理 |
02 上下文的構成要素
我們傳遞給大語言模型的上下文并非固定不變的字符串，而是為每次交互動態組裝的信息載體。多種記憶系統協同構建這個載體 —— 每種系統都受認知科學啟發而承擔著獨特的功能[4]。
以下是構成 LLM 上下文的核心組件：
- System Prompt：包含智能體的核心指令、規則和角色設定。可視其為程序性記憶，定義了行為模式。
- Message History：記錄了最近的對話往來，包括用戶輸入和智能體的內部思考（調用工具時的思考、行動與觀察）。相當于短期工作記憶。
- User Preferences and Past Experiences：這部分屬于智能體的情景記憶，負責存儲特定事件和與用戶相關的事實信息（通常保存在向量數據庫或圖數據庫中）。它能實現個性化功能，例如記憶用戶的身份特征或歷史請求[5]。
- Retrieved Information：屬于語義記憶—— 從內部知識庫（如公司文檔/內部記錄）或通過實時 API 調用的外部數據源中獲取的事實知識。這是 RAG 的核心。
- Tool and Structured Output Schemas：同樣屬于程序性記憶，定義智能體可使用的工具及其響應格式。
上下文的構成要素
這是一個循環且動態的流程。用戶查詢或任務會觸發從長期記憶源（情景記憶、語義記憶、程序記憶）中檢索信息，它不再是被動的傳統 RAG，而是由一個“智能體”主動驅動的、更復雜的 Agentic RAG 組件。
隨后，我們將這些信息與短期工作記憶、工具模式及結構化輸出模式相結合，為本次 LLM 調用創建出最終的上下文。LLM 的響應會更新工作記憶，并可能將關鍵信息寫回長期記憶，從而優化系統以適應未來的交互。
03 在生產環境實施上下文工程可能會遇到的一些挑戰
構建健壯的上下文工程流程并非易事。在生產環境中，若未能妥善處理以下幾個核心難題，將會導致智能體性能下降。
首先是上下文窗口的限制。 即便擁有超大容量的上下文窗口，其空間仍是昂貴且有限的資源。LLM 核心的自注意力機制會帶來二次方的計算開銷和內存開銷[2]。每個 token 都會增加成本與延遲，聊天記錄、工具輸出和檢索到的文檔會迅速填滿上下文窗口，從而嚴格限制智能體的“可見范圍”。
這將引發信息過載問題（亦稱上下文衰減或“中間信息丟失”現象）。 研究表明，當向上下文塞入過多信息時，模型會喪失關注關鍵細節的能力[1]。性能往往會斷崖式下跌，導致生成混亂或無關的響應。這種信息丟失還可能觸發幻覺，因為模型會試圖填補感知到的信息缺口[6]。
另一個不易察覺的問題是上下文漂移（context drift），即關于同一件事存在的多個不一致甚至矛盾的記錄會隨著時間的推移而不斷累積。 例如，若記憶中同時存在“用戶預算為 500 美元”和后續的“用戶預算為1000美元”，智能體可能會產生困惑。若沒有機制來解析或清除過時的事實性信息，智能體的知識庫將變得不可靠。
最后是工具混淆問題（tool confusion）。 當為智能體提供過多工具時（尤其存在描述不清或功能重疊時），故障頻發。Gorilla 基準測試表明，當提供超過一個工具時，幾乎所有模型性能都會下降[7]。智能體會因選擇過多而陷入癱瘓或選錯工具，最終導致任務失敗。
Context Engineering Guide 101
04 上下文優化的關鍵策略
早期，大多數 AI 應用只是簡單的 RAG 系統。如今，智能體需要同時處理多個數據源、工具及記憶類型，這就要求采用更復雜的上下文工程方法。以下為有效管理 LLM 上下文窗口的關鍵策略。
4.1 選擇合適的上下文
選擇正確的上下文是你的第一道防線。應避免提供所有的可用上下文，應使用帶重排序機制的 RAG 來僅檢索最相關的上下文。
結構化輸出同樣也能確保 LLM 將響應拆分為多個邏輯片段，并僅將必要的片段傳遞至下游。這種動態的上下文優化會過濾內容并篩選出關鍵信息，從而在有限的上下文窗口內實現信息密度的最大化[2]。
4.2 上下文壓縮
上下文壓縮對于管理長對話非常重要。隨著消息歷史的增長，需要對其進行摘要或壓縮以避免超出上下文窗口的容量，其原理類似于管理計算機的 RAM。
可使用 LLM 生成舊對話的摘要，通過 mem0 等工具將關鍵信息轉移至長期情景記憶，或使用 MinHash 算法進行去重[8]。
4.3 上下文排序
LLM 會更關注提示詞的開頭和結尾部分，而常常忽略中間的信息 —— 這就是“中間信息丟失”（lost-in-the-middle）現象 [1]。
請將關鍵指令置于開頭，將最新或最相關的數據放在末尾。
重排序機制與時效相關性確保 LLM 不會埋沒關鍵信息[2]。動態上下文優先級還能通過適配變化的用戶偏好來解決歧義和維持個性化的響應[9]。
4.4 上下文隔離
上下文隔離（Isolating context）是指將復雜問題拆分給多個專用智能體處理。每個智能體專注維護自身的上下文窗口，避免干擾并且可以提升性能。
這是多智能體系統背后的核心原則，利用了軟件工程中經典的關注點分離原則（separation of concerns principle）。
4.5 上下文格式優化
最后，使用 XML 或 YAML 等結構進行上下文格式優化可使上下文更易被模型“消化”。這樣可以清晰地劃分不同信息類型，并提升推理的可靠性。
?? 小提示：始終用 YAML 替代 JSON，因其可節省 66% 的 token 消耗。
Context Engineering Cheat Sheet - Source thread on X by @lenadroid
05 示例
上下文工程并非僅是理論概念，我們已將其應用于構建多個領域的強大 AI 系統。
在醫療健康領域，AI 助手可調用患者病史、當前癥狀及相關醫學文獻，以提供個性化的診斷建議。
在金融領域，智能體可集成公司的客戶關系管理（CRM）系統、日歷和財務數據，從而基于用戶偏好做出決策。
對于項目管理，AI 系統可接入 CRM、Slack、Zoom、日歷及任務管理器等企業級工具，自動理解項目需求并更新任務。
讓我們看一個具體案例。假設用戶向醫療助手提問：我頭痛。有什么不吃藥的方法能緩解嗎？
在 LLM 接收到用戶查詢之前，上下文工程系統已開始工作：
1）它從情景記憶存儲庫（通常是向量數據庫或圖數據庫[5]）中檢索用戶的病史、已知過敏原和生活習慣。
2）它查詢存儲最新醫學文獻的語義記憶庫，獲取非藥物性頭痛療法[4]。
3）它將上述信息與用戶查詢及對話歷史一起，組裝成一個結構化的提示詞。
4）我們將此提示詞發送給 LLM，由其生成個性化的、安全且相關的建議。
5）記錄此次交互，并將任何新的偏好保存回用戶的情景記憶中。
以下是一個簡化的 Python 示例，展示了如何將這些組件組裝成一個完整的系統提示詞。請注意其清晰的結構與編排順序。
醫療 AI 助手的系統提示詞：
當然，整個系統的關鍵仍在于其周邊的支撐系統，該系統能引入恰當的上下文來填充系統提示詞。
要構建此類系統，需要組合使用多種工具。比如，Gemini 等 LLM 提供推理引擎，LangChain 等框架編排工作流，PostgreSQL/Qdrant/Neo4j 等數據庫作為長期記憶存儲庫，Mem0 等專用工具管理記憶狀態，而可觀測性平臺對調試復雜交互至關重要。
06 將上下文工程與 AI 工程相融合
掌握上下文工程的關鍵不在于學習特定算法，而在于培養一種直覺。這是一門懂得如何構建提示詞結構、選擇納入哪些信息以及如何排序以實現最大效用的藝術。
這項技能并非孤立存在。它是一種跨學科的實踐，位于多個關鍵工程領域的交匯處：
- AI Engineering：理解 LLM、RAG 和 AI 智能體是基礎。
- Software Engineering：需要構建可擴展且可維護的系統來聚合上下文，并將智能體封裝在健壯的 API 中。
- Data Engineering：為 RAG 及其他記憶系統構建可靠的數據管道非常重要。
- MLOps：在合適的基礎設施上部署智能體，并實現持續集成/持續部署（CI/CD）自動化，使其具備可復現性、可觀測性與可擴展性。
培養上下文工程技能的最佳方式是親自動手實踐。
開始構建集成以下功能的 AI 智能體：使用 RAG 實現語義記憶，使用工具實現程序性記憶，以及利用用戶配置文件實現情景記憶。通過在實際項目中努力權衡上下文管理的各種利弊，你將培養出那種能將簡單 Chatbot 與真正智能體區分開來的直覺。
現在，停止閱讀，運用這些上下文工程技能去構建你的下一個 AI 應用吧！
END
本期互動內容 ??
?如果讓你向一個新手解釋“上下文工程”和“提示詞工程”的區別，你會怎么比喻？
文中鏈接
[1]??https://www.databricks.com/blog/long-context-rag-performance-llms??
[2]??https://arxiv.org/pdf/2507.13334??
[3]??https://x.com/karpathy/status/1937902205765607626??
[4]??https://www.nature.com/articles/s41593-023-01496-2??
[5]??https://www.ibm.com/think/topics/ai-agent-memory??
[6]??https://arxiv.org/pdf/2505.00019??
[7]??https://gorilla.cs.berkeley.edu/leaderboard.html??
[8]??https://www.datacamp.com/tutorial/prompt-compression??
[9]??https://aclanthology.org/2025.naacl-srw.42.pdf??
[10]??https://www.anthropic.com/engineering/built-multi-agent-research-system??
[11]??https://www.speakeasy.com/mcp/ai-agents/architecture-patterns??
本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。
原文鏈接：
??https://decodingml.substack.com/p/context-engineering-2025s-1-skill??
