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

發(fā)布于 2025-7-18 09:39

瀏覽

0收藏

編者按： 什么樣的技能才能真正決定 AI 智能體的成敗？是更復雜的算法，還是更精妙的提示詞？我們今天為大家?guī)淼奈恼拢髡叩挠^點是：構(gòu)建強大 AI 智能體的關(guān)鍵已從“提示詞工程”轉(zhuǎn)向“上下文工程”。
文章從“上下文”的廣義定義出發(fā)，詳細拆解了影響 AI 決策的七大關(guān)鍵要素，包括系統(tǒng)指令、用戶輸入、歷史對話、長期記憶、外部檢索信息、可用工具及輸出結(jié)構(gòu)。通過對比“廉價演示項目”與“神奇智能體”的案例，作者生動展現(xiàn)了上下文質(zhì)量如何決定 AI 的表現(xiàn) —— 真正的差距不在于模型本身，而在于是否提供了恰當?shù)纳舷挛闹С帧Ｗ髡哌M一步提出，上下文工程是一套動態(tài)流程，需跨領(lǐng)域協(xié)作，以結(jié)構(gòu)化的方式整合業(yè)務需求與技術(shù)實現(xiàn)，確保 LLM 在正確的時間獲得正確的信息與工具。

作者 | Philipp Schmid

編譯 | 岳揚

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

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

01 什么是上下文（Context）？

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

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

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

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

構(gòu)建真正高效的 AI 智能體的秘訣，與你編寫代碼的復雜程度關(guān)系不大，而與你提供上下文的質(zhì)量息息相關(guān)。

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

Hey, just checking if you’re around for a quick sync tomorrow.
嘿，想問一問明天方不方便，我們快速碰個頭？

“廉價的智能體演示項目”的上下文質(zhì)量很差。它只看到用戶的請求，其他什么都看不到。它的代碼可能功能完善，它會調(diào)用 LLM 并獲得響應，但輸出的內(nèi)容卻毫無幫助，且充滿機械感：

Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?
感謝來信！明天我有空。你想約在幾點？

“神奇的智能體”則由豐富的上下文驅(qū)動。其代碼的主要任務并非琢磨如何回應，而是收集 LLM 所需的信息，以便更好地響應用戶需求。在調(diào)用 LLM 之前，你可以擴展上下文，使其包含：

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

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

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

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

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

上下文工程是

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

04 Summary

構(gòu)建強大且可靠的 AI 智能體，已經(jīng)不再需要尋找神奇的提示詞或更新模型版本。其核心在于上下文工程，即以正確的格式、在正確的時間提供正確的信息與工具。這是一項跨領(lǐng)域協(xié)作的挑戰(zhàn)，需要理解業(yè)務場景、定義預期輸出，并結(jié)構(gòu)化組織所有必要的信息，使 LLM 能夠真正“完成任務”。