告別提示詞工程，「上下文工程」才是 AI Agent 的核心競爭力原創

發布于 2025-7-18 09:39

瀏覽

0收藏

編者按： 什么樣的技能才能真正決定 AI 智能體的成敗？是更復雜的算法，還是更精妙的提示詞？我們今天為大家帶來的文章，作者的觀點是：構建強大 AI 智能體的關鍵已從“提示詞工程”轉向“上下文工程”。
文章從“上下文”的廣義定義出發，詳細拆解了影響 AI 決策的七大關鍵要素，包括系統指令、用戶輸入、歷史對話、長期記憶、外部檢索信息、可用工具及輸出結構。通過對比“廉價演示項目”與“神奇智能體”的案例，作者生動展現了上下文質量如何決定 AI 的表現 —— 真正的差距不在于模型本身，而在于是否提供了恰當的上下文支持。作者進一步提出，上下文工程是一套動態流程，需跨領域協作，以結構化的方式整合業務需求與技術實現，確保 LLM 在正確的時間獲得正確的信息與工具。

作者 | Philipp Schmid

編譯 | 岳揚

上下文工程（Context Engineering）是一個在人工智能領域逐漸走紅的新術語。行業內討論的焦點正從“提示詞工程”（prompt engineering）轉向一個更廣泛、更強大的概念：上下文工程（Context Engineering）。托比·盧克（Tobi Lutke）[1]將其描述為“為任務提供完整的上下文背景，使大語言模型能夠合理解決問題的一門藝術”，他說得很到位。

隨著 Agents 的興起，將哪些信息輸入“有限的工作記憶（limited working memory）”中變得越來越重要。我們觀察到，決定一個 Agent 成敗的關鍵因素，通常就在于你提供給它的上下文質量。大多數 Agent 的失敗早已不是模型本身的問題，而恰恰是上下文供給的失敗。

01 什么是上下文（Context）？

要理解上下文工程（Context Engineering），我們首先必須擴展對“上下文”的定義。它不僅指你發送給 LLM 的單一提示詞（prompt）。應該將其視為模型在生成響應前所看到的一切信息。

告別提示詞工程，「上下文工程」才是 AI Agent 的核心競爭力-AI.x社區

指令 / 系統提示詞（Instructions / System Prompt）：用于定義模型在對話期間行為的初始指令集，可以/應該包含示例、規則等。
用戶提示詞（User Prompt）：來自用戶的即時任務或問題。
狀態 / 歷史（短期記憶）[State / History (short-term Memory]：當前的對話內容，包括導致此刻結果的“用戶與模型的歷史回復“。
長期記憶（Long-Term Memory）：在之前的多次對話中收集的持久性知識庫，包含學習到的用戶偏好、過往對話摘要、或被明確告知需要記憶以備后續使用的信息。
檢索信息（RAG）[Retrieved Information (RAG)]：外部的、最新的知識，來自文檔、數據庫或 API 的相關信息，用于回答特定問題。
可用工具（Available Tools）：所有可調用函數或內置工具的標準化描述（如輸入參數、輸出格式、功能說明）（例如 check_inventory, send_email）。
結構化輸出（Structured Output）：對模型響應格式的定義，例如一個 JSON 對象。

02 為什么重要？從「廉價的演示項目」到「神奇的智能體產品」

構建真正高效的 AI 智能體的秘訣，與你編寫代碼的復雜程度關系不大，而與你提供上下文的質量息息相關。

構建智能體，與你編寫的代碼或使用的框架關系不大。 一個廉價的演示項目和“神奇的智能體”之間的區別，就在于你所提供上下文的質量。假設讓一個 AI 助手根據一封簡單的郵件來安排會議：

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 之前，你可以擴展上下文，使其包含：

你的日歷信息（顯示你日程已滿）。
你與此人的過往郵件（用于確定合適的非正式語氣）。
你的聯系人列表（用于識別 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！明天我這邊日程全排滿了，從早到晚連軸轉。周四上午有空，你看行不？邀請已發，確認下是否合適~

這種神奇的效果并非源于更聰明的模型或更精巧的算法，而在于為正確的任務提供了恰當的上下文。這就是為什么上下文工程（Context Engineering）非常重要。智能體的失敗并非僅僅是模型的失敗，本質上是上下文的缺失。

03 從提示詞工程到上下文工程

什么是上下文工程？如果說“提示詞工程（prompt engineering）”側重于在單個文本字符串中精心設計一套完美的指令，那么上下文工程（context engineering）的范疇則寬廣得多。簡而言之：

上下文工程是一門設計和構建動態系統的學科，它能以正確的格式、在正確的時間提供正確的信息與工具，賦予 LLM 完成任務所需的一切資源。

上下文工程是

一套流程，而非某些字符串：上下文不僅是一個靜態的提示詞模板。它是主 LLM 調用前系統運行所產生的輸出。
動態構建的：隨任務即時生成，適配用戶當下的需求。對某個請求，其上下文可能是日歷數據，對另一請求，上下文則可能是郵件記錄或網頁搜索結果。
在正確的時間提供正確的信息和工具：其核心職責是確保模型不遺漏關鍵細節（Garbage In, Garbage Out）。這意味著只有在必需且有幫助時才提供知識（信息）與能力（工具）。
注重呈現格式：如何呈現信息很重要。簡明扼要的摘要勝過原始數據的堆砌，清晰的工具架構勝過模糊的指令。