告別提示詞工程，「上下文工程」才是 AI Agent 的核心競爭力 原創(chuàng)
編者按： 什么樣的技能才能真正決定 AI 智能體的成敗？是更復雜的算法，還是更精妙的提示詞？我們今天為大家?guī)淼奈恼?，作者的觀點是：構建強大 AI 智能體的關鍵已從“提示詞工程”轉向“上下文工程”。
文章從“上下文”的廣義定義出發(fā)，詳細拆解了影響 AI 決策的七大關鍵要素，包括系統(tǒng)指令、用戶輸入、歷史對話、長期記憶、外部檢索信息、可用工具及輸出結構。通過對比“廉價演示項目”與“神奇智能體”的案例，作者生動展現(xiàn)了上下文質量如何決定 AI 的表現(xiàn) —— 真正的差距不在于模型本身，而在于是否提供了恰當?shù)纳舷挛闹С?。作者進一步提出，上下文工程是一套動態(tài)流程，需跨領域協(xié)作，以結構化的方式整合業(yè)務需求與技術實現(xiàn)，確保 LLM 在正確的時間獲得正確的信息與工具。
作者 | Philipp Schmid
編譯 | 岳揚
上下文工程（Context Engineering）是一個在人工智能領域逐漸走紅的新術語。行業(yè)內討論的焦點正從“提示詞工程”（prompt engineering）轉向一個更廣泛、更強大的概念：上下文工程（Context Engineering）。托比·盧克（Tobi Lutke）[1]將其描述為“為任務提供完整的上下文背景，使大語言模型能夠合理解決問題的一門藝術”，他說得很到位。
隨著 Agents 的興起，將哪些信息輸入“有限的工作記憶（limited working memory）”中變得越來越重要。我們觀察到，決定一個 Agent 成敗的關鍵因素，通常就在于你提供給它的上下文質量。大多數(shù) Agent 的失敗早已不是模型本身的問題，而恰恰是上下文供給的失敗。
01 什么是上下文（Context）？
要理解上下文工程（Context Engineering），我們首先必須擴展對“上下文”的定義。它不僅指你發(fā)送給 LLM 的單一提示詞（prompt）。應該將其視為模型在生成響應前所看到的一切信息。
- 指令 / 系統(tǒng)提示詞（Instructions / System Prompt）： 用于定義模型在對話期間行為的初始指令集，可以/應該包含示例、規(guī)則等。
- 用戶提示詞（User Prompt）： 來自用戶的即時任務或問題。
- 狀態(tài) / 歷史（短期記憶）[State / History (short-term Memory]： 當前的對話內容，包括導致此刻結果的“用戶與模型的歷史回復“。
- 長期記憶（Long-Term Memory）： 在之前的多次對話中收集的持久性知識庫，包含學習到的用戶偏好、過往對話摘要、或被明確告知需要記憶以備后續(xù)使用的信息。
- 檢索信息（RAG）[Retrieved Information (RAG)]： 外部的、最新的知識，來自文檔、數(shù)據(jù)庫或 API 的相關信息，用于回答特定問題。
- 可用工具（Available Tools）： 所有可調用函數(shù)或內置工具的標準化描述（如輸入?yún)?shù)、輸出格式、功能說明）（例如 check_inventory, send_email）。
- 結構化輸出（Structured Output）： 對模型響應格式的定義，例如一個 JSON 對象。
02 為什么重要？從「廉價的演示項目」到「神奇的智能體產品」
構建真正高效的 AI 智能體的秘訣，與你編寫代碼的復雜程度關系不大，而與你提供上下文的質量息息相關。
構建智能體，與你編寫的代碼或使用的框架關系不大。 一個廉價的演示項目和“神奇的智能體”之間的區(qū)別，就在于你所提供上下文的質量。假設讓一個 AI 助手根據(jù)一封簡單的郵件來安排會議：
Hey, just checking if you’re around for a quick sync tomorrow.
嘿，想問一問明天方不方便，我們快速碰個頭？
“廉價的智能體演示項目”的上下文質量很差。它只看到用戶的請求，其他什么都看不到。它的代碼可能功能完善，它會調用 LLM 并獲得響應，但輸出的內容卻毫無幫助，且充滿機械感：
Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?
感謝來信！明天我有空。你想約在幾點？
“神奇的智能體”則由豐富的上下文驅動。其代碼的主要任務并非琢磨如何回應，而是收集 LLM 所需的信息，以便更好地響應用戶需求。在調用 LLM 之前，你可以擴展上下文，使其包含：
- 你的日歷信息（顯示你日程已滿）。
- 你與此人的過往郵件（用于確定合適的非正式語氣）。
- 你的聯(lián)系人列表（用于識別 ta 為關鍵的合作伙伴）。
- send_invite 或 send_email 工具。
然后便能生成回應：
Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works.
嗨 Jim！明天我這邊日程全排滿了，從早到晚連軸轉。周四上午有空，你看行不？邀請已發(fā)，確認下是否合適~
這種神奇的效果并非源于更聰明的模型或更精巧的算法，而在于為正確的任務提供了恰當?shù)纳舷挛?。這就是為什么上下文工程（Context Engineering）非常重要。智能體的失敗并非僅僅是模型的失敗，本質上是上下文的缺失。
03 從提示詞工程到上下文工程
什么是上下文工程？如果說“提示詞工程（prompt engineering）”側重于在單個文本字符串中精心設計一套完美的指令，那么上下文工程（context engineering）的范疇則寬廣得多。簡而言之：
上下文工程是一門設計和構建動態(tài)系統(tǒng)的學科，它能以正確的格式、在正確的時間提供正確的信息與工具，賦予 LLM 完成任務所需的一切資源。
上下文工程是
- 一套流程，而非某些字符串：上下文不僅是一個靜態(tài)的提示詞模板。它是主 LLM 調用前系統(tǒng)運行所產生的輸出。
- 動態(tài)構建的：隨任務即時生成，適配用戶當下的需求。對某個請求，其上下文可能是日歷數(shù)據(jù)，對另一請求，上下文則可能是郵件記錄或網(wǎng)頁搜索結果。
- 在正確的時間提供正確的信息和工具：其核心職責是確保模型不遺漏關鍵細節(jié)（Garbage In, Garbage Out）。這意味著只有在必需且有幫助時才提供知識（信息）與能力（工具）。
- 注重呈現(xiàn)格式：如何呈現(xiàn)信息很重要。簡明扼要的摘要勝過原始數(shù)據(jù)的堆砌，清晰的工具架構勝過模糊的指令。
04 Summary
構建強大且可靠的 AI 智能體，已經(jīng)不再需要尋找神奇的提示詞或更新模型版本。其核心在于上下文工程，即以正確的格式、在正確的時間提供正確的信息與工具。這是一項跨領域協(xié)作的挑戰(zhàn)，需要理解業(yè)務場景、定義預期輸出，并結構化組織所有必要的信息，使 LLM 能夠真正“完成任務”。
05 致謝
本綜述的完成得益于深度研究（deep research）與人工校驗（manual research），并從以下優(yōu)質資源中汲取了靈感與信息：
- Tobi Lutke tweet[1]
- Karpathy tweet[2]
- The rise of "context engineering"[3]
- Own your context window[4]
- Context Engineering by Simon Willison[5]
- Context Engineering for Agents[6]
END
本期互動內容 ??
?你是否有過動態(tài)構建上下文的經(jīng)驗？能否分享一個你認為特別成功的案例？
文中鏈接
[1]??https://x.com/tobi/status/1935533422589399127??
[2]??https://x.com/karpathy/status/1937902205765607626??
[3]??https://blog.langchain.com/the-rise-of-context-engineering/??
[5]??https://simonwillison.net/2025/Jun/27/context-engineering/??
[6]??https://rlancemartin.github.io/2025/06/23/context_engineering/??
本文經(jīng)原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯(lián)系獲取授權。
原文鏈接：
