編者按： 您是否曾感覺到，盡管精心設(shè)計了提示詞，AI 的表現(xiàn)卻依然不盡如人意？甚至隨著上下文越來越長，模型反而更容易“胡言亂語”？

我們今天為大家?guī)淼倪@篇文章，作者的核心觀點是：“提示詞工程”已經(jīng)不夠用了，下一代 AI 應(yīng)用的核心競爭力在于“上下文工程”（Context Engineering）。

文章系統(tǒng)地闡述了為何在智能體（Agent）時代，單純堆砌信息的“提示詞工程”思維會導(dǎo)致性能下降、成本飆升。作者提出，上下文工程是一套系統(tǒng)級的架構(gòu)方法，它強調(diào)動態(tài)地、有策略地為模型組合信息，包括系統(tǒng)指令、對話歷史、用戶記憶、檢索結(jié)果和工具定義等，從而在有限的上下文窗口中實現(xiàn)最優(yōu)性能。文章還深入分析了生產(chǎn)環(huán)境中實施上下文工程面臨的四大挑戰(zhàn)，并提供了五項關(guān)鍵優(yōu)化策略，最后通過一個醫(yī)療健康領(lǐng)域的實例展示了如何構(gòu)建一個真正的上下文驅(qū)動型 AI 系統(tǒng)。

作者 | Paul Iusztin

編譯 | 岳揚

開門見山地說：如果你現(xiàn)在還在只談?wù)摗疤崾驹~工程”，那你就已經(jīng)落后了。 在大語言模型（LLM）的發(fā)展初期，精心設(shè)計提示詞確實是核心任務(wù)。

對于 2022 年的簡單聊天機器人（chatbots）來說，這已經(jīng)綽綽有余了。到了 2023 年，檢索增強生成（RAG）技術(shù)興起，我們開始為模型注入領(lǐng)域知識。而現(xiàn)在，我們擁有了能使用工具、具備記憶能力的智能體，它們需要建立長期關(guān)系并維持狀態(tài)。提示詞工程那種只關(guān)注單次交互的思路已經(jīng)完全不夠用了。

隨著 AI 應(yīng)用變得越來越復(fù)雜，單純往提示詞里塞更多信息會引發(fā)一些嚴(yán)重的問題。首先是上下文衰減（context decay）現(xiàn)象。模型會被冗長雜亂的上下文搞糊涂，導(dǎo)致產(chǎn)生幻覺和錯誤答案。最近一項研究發(fā)現(xiàn)，一旦上下文超過 32,000 個 tokens，模型回答的正確率就會開始明顯下降 —— 這遠(yuǎn)低于宣傳的 200 萬 token 極限[1]。

其次，上下文窗口（模型的工作記憶）是有限的。即使上下文窗口再大，每個 token 都會增加成本和延遲。我曾經(jīng)構(gòu)建過一個工作流，把研究資料、指南、案例和評審意見全都塞進上下文。結(jié)果呢？運行一次需要 30 分鐘。根本沒法用。這種“上下文增強生成（context-augmented generation）”的天真做法（或者說簡單粗暴的信息堆砌），在生產(chǎn)環(huán)境中注定會失敗。

Context Engineering Guide 101

這正是上下文工程的意義所在。它標(biāo)志著思維模式的轉(zhuǎn)變：從精心設(shè)計單個提示詞，轉(zhuǎn)變?yōu)榧軜?gòu)整個 AI 的信息生態(tài)系統(tǒng)。我們動態(tài)地從記憶庫、數(shù)據(jù)庫和相關(guān)工具中收集并篩選信息，只為 LLM 提供當(dāng)前任務(wù)最必需的內(nèi)容。這讓我們的系統(tǒng)更精準(zhǔn)、更快速，也更經(jīng)濟。

01 理解什么是上下文工程

那么，上下文工程究竟是什么呢？標(biāo)準(zhǔn)的解釋是：這是一個最優(yōu)化問題 —— 通過尋找最佳的功能組合來構(gòu)建上下文，從而在特定任務(wù)中最大化 LLM 的輸出質(zhì)量[2]。

簡而言之，上下文工程的核心在于策略性地將正確的信息，在正確的時機，以正確的格式填入模型有限的上下文窗口。我們從短期記憶和長期記憶中檢索必要的片段來完成任務(wù)，同時避免讓模型過載。

安德烈·卡帕西（Andrej Karpathy）對此有一個精妙的類比：上下文工程就像一種新型的操作系統(tǒng)，模型充當(dāng) CPU，而其上下文窗口則相當(dāng)于 RAM[3]。正如操作系統(tǒng)需要管理哪些數(shù)據(jù)可以放入 RAM，上下文工程則精心策劃哪些內(nèi)容占據(jù)模型的工作內(nèi)存。需特別注意，上下文僅是系統(tǒng)總工作內(nèi)存的子集；有些信息可以保留在系統(tǒng)中，而無需在每次交互時都傳遞給 LLM。

這門新學(xué)科與單純編寫優(yōu)質(zhì)提示詞有著本質(zhì)的區(qū)別。要有效地設(shè)計上下文，你首先需要弄清楚哪些組成部分是你可以實際操作的。

上下文工程并非要取代提示詞工程。相反，你可以直觀地將提示詞工程視為上下文工程的一部分。在收集合適上下文的同時，你仍然需要學(xué)習(xí)如何撰寫優(yōu)質(zhì)提示詞，并確保將上下文填入提示詞中而不導(dǎo)致 LLM 出錯 —— 這正是上下文工程的意義所在！更多細(xì)節(jié)請參見下表。

02 上下文的構(gòu)成要素

我們傳遞給大語言模型的上下文并非固定不變的字符串，而是為每次交互動態(tài)組裝的信息載體。多種記憶系統(tǒng)協(xié)同構(gòu)建這個載體 —— 每種系統(tǒng)都受認(rèn)知科學(xué)啟發(fā)而承擔(dān)著獨特的功能[4]。

以下是構(gòu)成 LLM 上下文的核心組件：

• System Prompt：包含智能體的核心指令、規(guī)則和角色設(shè)定。可視其為程序性記憶，定義了行為模式。
• Message History：記錄了最近的對話往來，包括用戶輸入和智能體的內(nèi)部思考（調(diào)用工具時的思考、行動與觀察）。相當(dāng)于短期工作記憶。
• User Preferences and Past Experiences：這部分屬于智能體的情景記憶，負(fù)責(zé)存儲特定事件和與用戶相關(guān)的事實信息（通常保存在向量數(shù)據(jù)庫或圖數(shù)據(jù)庫中）。它能實現(xiàn)個性化功能，例如記憶用戶的身份特征或歷史請求[5]。
• Retrieved Information：屬于語義記憶—— 從內(nèi)部知識庫（如公司文檔/內(nèi)部記錄）或通過實時 API 調(diào)用的外部數(shù)據(jù)源中獲取的事實知識。這是 RAG 的核心。
• Tool and Structured Output Schemas：同樣屬于程序性記憶，定義智能體可使用的工具及其響應(yīng)格式。

上下文的構(gòu)成要素

這是一個循環(huán)且動態(tài)的流程。用戶查詢或任務(wù)會觸發(fā)從長期記憶源（情景記憶、語義記憶、程序記憶）中檢索信息，它不再是被動的傳統(tǒng) RAG，而是由一個“智能體”主動驅(qū)動的、更復(fù)雜的 Agentic RAG 組件。

隨后，我們將這些信息與短期工作記憶、工具模式及結(jié)構(gòu)化輸出模式相結(jié)合，為本次 LLM 調(diào)用創(chuàng)建出最終的上下文。LLM 的響應(yīng)會更新工作記憶，并可能將關(guān)鍵信息寫回長期記憶，從而優(yōu)化系統(tǒng)以適應(yīng)未來的交互。

03 在生產(chǎn)環(huán)境實施上下文工程可能會遇到的一些挑戰(zhàn)

構(gòu)建健壯的上下文工程流程并非易事。在生產(chǎn)環(huán)境中，若未能妥善處理以下幾個核心難題，將會導(dǎo)致智能體性能下降。

首先是上下文窗口的限制。 即便擁有超大容量的上下文窗口，其空間仍是昂貴且有限的資源。LLM 核心的自注意力機制會帶來二次方的計算開銷和內(nèi)存開銷[2]。每個 token 都會增加成本與延遲，聊天記錄、工具輸出和檢索到的文檔會迅速填滿上下文窗口，從而嚴(yán)格限制智能體的“可見范圍”。

這將引發(fā)信息過載問題（亦稱上下文衰減或“中間信息丟失”現(xiàn)象）。 研究表明，當(dāng)向上下文塞入過多信息時，模型會喪失關(guān)注關(guān)鍵細(xì)節(jié)的能力[1]。性能往往會斷崖式下跌，導(dǎo)致生成混亂或無關(guān)的響應(yīng)。這種信息丟失還可能觸發(fā)幻覺，因為模型會試圖填補感知到的信息缺口[6]。

另一個不易察覺的問題是上下文漂移（context drift），即關(guān)于同一件事存在的多個不一致甚至矛盾的記錄會隨著時間的推移而不斷累積。 例如，若記憶中同時存在“用戶預(yù)算為 500 美元”和后續(xù)的“用戶預(yù)算為1000美元”，智能體可能會產(chǎn)生困惑。若沒有機制來解析或清除過時的事實性信息，智能體的知識庫將變得不可靠。

最后是工具混淆問題（tool confusion）。 當(dāng)為智能體提供過多工具時（尤其存在描述不清或功能重疊時），故障頻發(fā)。Gorilla 基準(zhǔn)測試表明，當(dāng)提供超過一個工具時，幾乎所有模型性能都會下降[7]。智能體會因選擇過多而陷入癱瘓或選錯工具，最終導(dǎo)致任務(wù)失敗。

Context Engineering Guide 101

04 上下文優(yōu)化的關(guān)鍵策略

早期，大多數(shù) AI 應(yīng)用只是簡單的 RAG 系統(tǒng)。如今，智能體需要同時處理多個數(shù)據(jù)源、工具及記憶類型，這就要求采用更復(fù)雜的上下文工程方法。以下為有效管理 LLM 上下文窗口的關(guān)鍵策略。

4.1 選擇合適的上下文

選擇正確的上下文是你的第一道防線。應(yīng)避免提供所有的可用上下文，應(yīng)使用帶重排序機制的 RAG 來僅檢索最相關(guān)的上下文。

結(jié)構(gòu)化輸出同樣也能確保 LLM 將響應(yīng)拆分為多個邏輯片段，并僅將必要的片段傳遞至下游。這種動態(tài)的上下文優(yōu)化會過濾內(nèi)容并篩選出關(guān)鍵信息，從而在有限的上下文窗口內(nèi)實現(xiàn)信息密度的最大化[2]。

4.2 上下文壓縮

上下文壓縮對于管理長對話非常重要。隨著消息歷史的增長，需要對其進行摘要或壓縮以避免超出上下文窗口的容量，其原理類似于管理計算機的 RAM。

可使用 LLM 生成舊對話的摘要，通過 mem0 等工具將關(guān)鍵信息轉(zhuǎn)移至長期情景記憶，或使用 MinHash 算法進行去重[8]。

4.3 上下文排序

LLM 會更關(guān)注提示詞的開頭和結(jié)尾部分，而常常忽略中間的信息 —— 這就是“中間信息丟失”（lost-in-the-middle）現(xiàn)象 [1]。

請將關(guān)鍵指令置于開頭，將最新或最相關(guān)的數(shù)據(jù)放在末尾。

重排序機制與時效相關(guān)性確保 LLM 不會埋沒關(guān)鍵信息[2]。動態(tài)上下文優(yōu)先級還能通過適配變化的用戶偏好來解決歧義和維持個性化的響應(yīng)[9]。

4.4 上下文隔離

上下文隔離（Isolating context）是指將復(fù)雜問題拆分給多個專用智能體處理。每個智能體專注維護自身的上下文窗口，避免干擾并且可以提升性能。

這是多智能體系統(tǒng)背后的核心原則，利用了軟件工程中經(jīng)典的關(guān)注點分離原則（separation of concerns principle）。

4.5 上下文格式優(yōu)化

最后，使用 XML 或 YAML 等結(jié)構(gòu)進行上下文格式優(yōu)化可使上下文更易被模型“消化”。這樣可以清晰地劃分不同信息類型，并提升推理的可靠性。

?? 小提示：始終用 YAML 替代 JSON，因其可節(jié)省 66% 的 token 消耗。

Context Engineering Cheat Sheet - Source thread on X by @lenadroid

05 示例

上下文工程并非僅是理論概念，我們已將其應(yīng)用于構(gòu)建多個領(lǐng)域的強大 AI 系統(tǒng)。

在醫(yī)療健康領(lǐng)域，AI 助手可調(diào)用患者病史、當(dāng)前癥狀及相關(guān)醫(yī)學(xué)文獻(xiàn)，以提供個性化的診斷建議。

在金融領(lǐng)域，智能體可集成公司的客戶關(guān)系管理（CRM）系統(tǒng)、日歷和財務(wù)數(shù)據(jù)，從而基于用戶偏好做出決策。

對于項目管理，AI 系統(tǒng)可接入 CRM、Slack、Zoom、日歷及任務(wù)管理器等企業(yè)級工具，自動理解項目需求并更新任務(wù)。

讓我們看一個具體案例。假設(shè)用戶向醫(yī)療助手提問：我頭痛。有什么不吃藥的方法能緩解嗎？

在 LLM 接收到用戶查詢之前，上下文工程系統(tǒng)已開始工作：

1）它從情景記憶存儲庫（通常是向量數(shù)據(jù)庫或圖數(shù)據(jù)庫[5]）中檢索用戶的病史、已知過敏原和生活習(xí)慣。

2）它查詢存儲最新醫(yī)學(xué)文獻(xiàn)的語義記憶庫，獲取非藥物性頭痛療法[4]。

3）它將上述信息與用戶查詢及對話歷史一起，組裝成一個結(jié)構(gòu)化的提示詞。

4）我們將此提示詞發(fā)送給 LLM，由其生成個性化的、安全且相關(guān)的建議。

5）記錄此次交互，并將任何新的偏好保存回用戶的情景記憶中。

以下是一個簡化的 Python 示例，展示了如何將這些組件組裝成一個完整的系統(tǒng)提示詞。請注意其清晰的結(jié)構(gòu)與編排順序。

醫(yī)療 AI 助手的系統(tǒng)提示詞：

當(dāng)然，整個系統(tǒng)的關(guān)鍵仍在于其周邊的支撐系統(tǒng)，該系統(tǒng)能引入恰當(dāng)?shù)纳舷挛膩硖畛湎到y(tǒng)提示詞。

要構(gòu)建此類系統(tǒng)，需要組合使用多種工具。比如，Gemini 等 LLM 提供推理引擎，LangChain 等框架編排工作流，PostgreSQL/Qdrant/Neo4j 等數(shù)據(jù)庫作為長期記憶存儲庫，Mem0 等專用工具管理記憶狀態(tài)，而可觀測性平臺對調(diào)試復(fù)雜交互至關(guān)重要。

06 將上下文工程與 AI 工程相融合

掌握上下文工程的關(guān)鍵不在于學(xué)習(xí)特定算法，而在于培養(yǎng)一種直覺。這是一門懂得如何構(gòu)建提示詞結(jié)構(gòu)、選擇納入哪些信息以及如何排序以實現(xiàn)最大效用的藝術(shù)。

這項技能并非孤立存在。它是一種跨學(xué)科的實踐，位于多個關(guān)鍵工程領(lǐng)域的交匯處：

• AI Engineering：理解 LLM、RAG 和 AI 智能體是基礎(chǔ)。
• Software Engineering：需要構(gòu)建可擴展且可維護的系統(tǒng)來聚合上下文，并將智能體封裝在健壯的 API 中。
• Data Engineering：為 RAG 及其他記憶系統(tǒng)構(gòu)建可靠的數(shù)據(jù)管道非常重要。
• MLOps：在合適的基礎(chǔ)設(shè)施上部署智能體，并實現(xiàn)持續(xù)集成/持續(xù)部署（CI/CD）自動化，使其具備可復(fù)現(xiàn)性、可觀測性與可擴展性。

培養(yǎng)上下文工程技能的最佳方式是親自動手實踐。

開始構(gòu)建集成以下功能的 AI 智能體：使用 RAG 實現(xiàn)語義記憶，使用工具實現(xiàn)程序性記憶，以及利用用戶配置文件實現(xiàn)情景記憶。通過在實際項目中努力權(quán)衡上下文管理的各種利弊，你將培養(yǎng)出那種能將簡單 Chatbot 與真正智能體區(qū)分開來的直覺。

現(xiàn)在，停止閱讀，運用這些上下文工程技能去構(gòu)建你的下一個 AI 應(yīng)用吧！

END

本期互動內(nèi)容 ??

?如果讓你向一個新手解釋“上下文工程”和“提示詞工程”的區(qū)別，你會怎么比喻？

文中鏈接

[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??

[12]??https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md??

本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。

原文鏈接：

??https://decodingml.substack.com/p/context-engineering-2025s-1-skill??