搞懂上下文工程（Context Engineering)，讓你的LLM更聰明原創

Halo咯咯

發布于 2025-8-7 08:09

瀏覽

0收藏

我們可能早已習慣了“提示詞工程”（Prompt Engineering）。不論是寫摘要、代碼生成，還是會議復盤，大家都想著如何寫出一個高效的提示詞，讓LLM做出回答。但有時候大模型回答的結果并不是盡人意。

所以，最近有個新詞開始頻繁出現在圈內討論中——“上下文工程”（Context Engineering）。

這個詞乍一看和“提示詞工程”貌似差不多，但如果你是在構建一個智能體（AI Agent）系統，特別是基于像 LlamaIndex、LlamaCloud 這樣的工具時，你會發現：你寫得再好的提示詞，也比不上一次精心設計的上下文填充。

什么是上下文工程？它和提示詞工程到底有什么不同？

我們都知道，大模型的“工作記憶”——也就是所謂的“上下文窗口”——是有限的。你想讓它準確理解、判斷和執行任務，必須把最相關、最有價值的信息放進這段上下文里。

這就是“上下文工程”的核心：不僅要喂信息，還要喂對的信息、喂得巧、喂得精。

而“提示詞工程”更多是在設計指令的語言方式——比如你是說“請寫一篇總結”，還是“像公眾號一樣寫一篇總結”。它關注的是“怎么說”，而上下文工程則關注“說什么”和“說多少”。

來自 Andrey Karpathy 的一句話總結得很好：

“提示詞只是你日常用來對大模型發出請求的文字描述，但在真正的工業級 LLM 應用中，上下文工程才是真正的藝術與科學。”

一個 Agent 的「上下文」到底包括什么？

這部分是重頭戲。參考 Philipp Schmid 的觀點，再結合 LlamaIndex 團隊的實戰經驗，我們可以將一個 AI Agent 的上下文來源劃分為以下幾類：

系統指令：為 Agent 定義角色和任務范疇；
用戶輸入：用戶的提問、請求、任務說明；
短期記憶（對話歷史）：讓模型記住前面發生了什么；
長期記憶：保存過去交互、知識點或關鍵信息，可隨時檢索；
知識庫檢索信息：基于向量數據庫、API 或其他來源抓取補充內容；
工具及其定義：告訴大模型可以用哪些外部能力；
工具調用結果：上一輪工具執行返回的具體內容；
結構化輸出：標準格式的數據結構，可作為輸入或輸出；
全局狀態/上下文：Agent 跨步驟共享的“草稿板”信息。

看到這里你可能會問：這不就是 Retrieval-Augmented Generation（RAG）嗎？確實，RAG 是上下文工程的重要一環。但上下文工程不僅僅是“檢索”，它關心的是：怎么選、怎么排、怎么裁剪這些上下文。

做好上下文工程，你得解決這3個關鍵問題

搞懂上下文工程（Context Engineering)，讓你的LLM更聰明-AI.x社區

1?? 如何選出“對”的上下文？

構建智能 Agent 時，很多人習慣一股腦把所有內容丟進去：知識庫、文檔、歷史對話……然后讓模型自己“看著辦”。

但上下文窗口不是無底洞！你必須問自己兩個問題：

現在這個任務，需要哪些信息？
哪些是“可選但冗余”的背景，能不放就不放？

比如，在多知識源場景下，我們不僅要考慮是否使用知識庫，還要想清楚該用哪個庫，是需要法律知識、用戶FAQ，還是實時數據查詢？甚至告訴模型“有哪些工具可用”本身也是一種上下文補充。

2?? 如何壓縮有限的上下文窗口？

LlamaIndex 中已經廣泛采用了上下文壓縮（Compression）策略，尤其體現在兩點：

摘要化（Summarization）：檢索結果太多？先用摘要技術壓縮內容，再填入模型。
排序機制（Ordering）：信息太多？那就按時間、重要性、相關度排序，放前面的優先處理。

例如以下 Python 函數中，檢索返回結果后會根據時間戳篩選和排序，確保先提供最新、最相關的內容：

def search_knowledge(query: str) -> str:
    nodes = retriever.retrieve(query)
    sorted_and_filtered_nodes = sorted(
        [item for item in data if datetime.strptime(item['date'], '%Y-%m-%d') > cutoff_date],
        key=lambda x: datetime.strptime(x['date'], '%Y-%m-%d')
    )
    return "\n----\n".join([n.text for n in sorted_and_filtered_nodes])