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

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

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

作者 | Paul Iusztin

編譯 | 岳揚(yáng)

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

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

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

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

Context Engineering Guide 101

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

01 理解什么是上下文工程

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

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

安德烈·卡帕西（Andrej Karpathy）對(duì)此有一個(gè)精妙的類比：上下文工程就像一種新型的操作系統(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)中，而無需在每次交互時(shí)都傳遞給 LLM。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Context Engineering Guide 101

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

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

4.1 選擇合適的上下文

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

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

4.2 上下文壓縮

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

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

4.3 上下文排序

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

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

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

4.4 上下文隔離

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

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

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

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

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

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

05 示例

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，整個(gè)系統(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ù)庫(kù)作為長(zhǎng)期記憶存儲(chǔ)庫(kù)，Mem0 等專用工具管理記憶狀態(tài)，而可觀測(cè)性平臺(tái)對(duì)調(diào)試復(fù)雜交互至關(guān)重要。

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

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

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

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

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

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

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

END

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

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

文中鏈接

[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)載譯文，請(qǐng)聯(lián)系獲取授權(quán)。

原文鏈接：

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