Context Engineering 實戰指南：一種全面的 AI 開發方法

什麼是 Context Engineering？

幾年前，許多人，甚至頂尖的 AI 研究人員，都聲稱提示工程（prompt engineering）現在應該已經過時了。

顯然，他們大錯特錯了。事實上，提示工程現在比以往任何時候都更重要。它是如此重要，以至於現在被重新命名爲 "語境工程"（context engineering）。

是的，這又是一個時髦的術語，用來描述優化指令和相關語境的重要過程，這些對於 LLM 有效執行任務至關重要。

關於語境工程已經有很多文章（如 Ankur Goyal(https://x.com/ankrgyl/status/1913766591910842619)、Walden Yan(https://cognition.ai/blog/dont-build-multi-agents)、Tobi Lutte(https://x.com/tobi/status/1935533422589399127) 和 Andrej Karpathy(https://x.com/karpathy/status/1937902205765607626) 等專家的觀點），但我想寫一寫自己對這個話題的想法，並向大家展示一個具體的分步指南，將語境工程應用於開發 AI 智能體工作流程。

我不太確定是誰最先提出了 "語境工程" 這個術語，但我們將基於 Dex Horthy 的這個圖表來構建理解，該圖表簡要解釋了語境工程的含義。

我喜歡 "語境工程" 這個術語，因爲它感覺像是一個更廣泛的詞彙，能夠更好地解釋提示工程中涉及的大部分工作，包括其他相關任務。

人們懷疑提示工程是否是一項嚴肅技能的原因是，許多人將其與 "盲式提示"（blind prompting）混淆，即在像 ChatGPT 這樣的 LLM 中使用簡短的任務描述。在盲式提示中，你只是向系統提出問題。而在提示工程中，你需要更仔細地思考提示的語境和結構。也許從一開始就應該稱之爲語境工程。

語境工程是下一個階段，在這個階段，你需要設計完整的語境，這在許多情況下需要超越簡單的提示，採用更嚴格的方法來獲取、增強和優化系統的知識。

從開發者的角度來看，語境工程涉及一個迭代過程，用於優化指令和提供給 LLM 的語境，以達到預期的結果。這包括建立正式的流程（如評估管道）來衡量你的策略是否有效。

鑑於 AI 領域的快速發展，我建議對語境工程進行更廣泛的定義：爲 LLM 和高級 AI 模型設計和優化指令及相關語境，以有效執行任務的過程。這不僅涵蓋基於文本的 LLM，還包括爲多模態模型優化語境，這些模型正變得越來越普遍。這可以包括所有提示工程工作和相關流程，如：

換句話說，在語境工程中，你試圖實現的是優化在 LLM 語境窗口中提供的信息。這也意味着過濾掉噪聲信息，這本身就是一門科學，因爲它需要系統地測量 LLM 的性能。

每個人都在談論語境工程，但在這裏我們將通過一個具體的例子來向你展示在構建 AI 智能體時語境工程的實際應用。

語境工程實戰

讓我們看一個具體的例子，這是我最近爲個人使用構建的多智能體深度研究應用程序所做的語境工程工作。

我在 n8n 中構建了智能體工作流程，但工具本身並不重要。我構建的完整智能體架構如下所示：

在我的工作流程中，搜索規劃智能體負責根據用戶查詢生成搜索計劃。

以下是我爲這個子智能體整理的系統提示：



你是一個專業的研究規劃師。你的任務是將複雜的研究查詢（用 <user_query></user_query> 分隔）分解爲具體的搜索子任務，每個子任務關注不同的方面或源類型。  
當前日期和時間是：{{ $now.toISO() }}  
對於每個子任務，請提供：

1. 子任務的唯一字符串 ID（如 'subtask_1'、'news_update'）

2. 專注於主查詢某一方面的具體搜索查詢

3. 要搜索的源類型（網絡、新聞、學術、專門）

4. 時間週期相關性（今天、上週、最近、過去一年、所有時間）

5. 如果適用，領域焦點（技術、科學、健康等）

6. 優先級（1-最高到5-最低）  


所有字段（id、query、source_type、time_period、domain_focus、priority）對於每個子任務都是必需的，除了 time_period 和 domain_focus 如果不適用可以爲 null。  


創建 2 個子任務，這些子任務將一起提供對該主題的全面覆蓋。關注不同的方面、觀點或信息來源。  


每個子任務將包含以下信息： 
id: str 
query: str 
source_type: str # 例如，"web"、"news"、"academic"、"specialized"

time_period: Optional[str] = None # 例如，"today"、"last week"、"recent"、"past_year"、"all_time"

domain_focus:Optional[str]=None # 例如，"technology"、"science"、"health"

priority: int # 1（最高）到 5（最低）  


獲取上述子任務信息後，你將添加兩個額外字段。這些對應於 start_date 和 end_date。根據當前日期和選擇的 time_period 推斷此信息。start_date 和 end_date 應使用如下示例格式：

"start_date": "2024-06-03T06:00:00.000Z","
end_date": "2024-06-11T05:59:59.999Z",

這個提示有許多部分需要仔細考慮，關於我們爲規劃智能體提供什麼確切的語境來有效地執行任務。如你所見，這不僅僅是設計一個簡單的提示或指令；這個過程需要實驗，併爲模型提供重要的語境，以便最優地執行任務。

讓我們將問題分解爲有效語境工程的核心組成部分。

指令（Instructions）

指令是提供給系統的高級指令，準確地指示它要做什麼。



你是一個專業的研究規劃師。你的任務是將複雜的研究查詢（用 <user_query></user_query> 分隔）分解爲具體的搜索子任務，每個子任務關注不同的方面或源類型。

許多初學者甚至有經驗的 AI 開發者都會在這裏停止。考慮到我上面分享了完整的提示，你可以理解我們需要給系統提供多少更多的語境才能讓它按照我們的期望工作。這就是語境工程的全部意義；它向系統提供更多關於問題範圍和我們確切想要從中得到什麼的信息。

用戶輸入（User Input）

用戶輸入在系統提示中沒有顯示，但下面是一個示例：



<user_query>OpenAI的最新開發新聞是什麼？</user_query>

注意分隔符的使用，這是爲了更好地構建提示。這對於避免混淆和增加用戶輸入是什麼以及我們希望系統生成什麼的清晰度非常重要。有時，我們輸入的信息類型與我們希望模型輸出的內容相關（例如，查詢是輸入，子查詢是輸出）。

結構化輸入和輸出（Structured Inputs and Outputs）

除了高級指令和用戶輸入，你可能已經注意到我在規劃智能體需要生成的子任務相關細節上花費了相當多的精力。以下是我爲規劃智能體提供的詳細指令，用於根據用戶查詢創建子任務：



對於每個子任務，請提供：

1. 子任務的唯一字符串 ID（如 'subtask_1'、'news_update'）

2. 專注於主查詢某一方面的具體搜索查詢

3. 要搜索的源類型（網絡、新聞、學術、專門）

4. 時間週期相關性（今天、上週、最近、過去一年、所有時間）

5. 如果適用，領域焦點（技術、科學、健康等）

6. 優先級（1-最高到5-最低）  


所有字段（id、query、source_type、time_period、domain_focus、priority）對於每個子任務都是必需的，除了 time_period 和 domain_focus 如果不適用可以爲 null。  


創建 2 個子任務，這些子任務將一起提供對該主題的全面覆蓋。關注不同的方面、觀點或信息來源。

如果你仔細看上面的指令，我決定構建一個我希望規劃智能體生成的必需信息列表，以及一些提示 / 示例來更好地幫助引導數據生成過程。這對於爲智能體提供預期內容的額外語境至關重要。例如，如果你不告訴它你希望優先級是 1-5 的等級，那麼系統可能更傾向於使用 1-10 的等級。再次強調，這種語境非常重要！

接下來，讓我們談談結構化輸出。爲了從規劃智能體獲得一致的輸出，我們還提供了一些關於我們期望的子任務格式和字段類型的語境。以下是我們作爲額外語境傳遞給智能體的示例。這將爲智能體提供關於我們期望輸出的提示和線索：



每個子任務將包含以下信息：

id: str

query: str

source_type: str # 例如，"web"、"news"、"academic"、"specialized"

time_period:Optional[str] = None # 例如，"today"、"last week"、"recent"、"past_year"、"all_time"

domain_focus:Optional[str] = None # 例如，"technology"、"science"、"health"

priority: int # 1（最高）到 5（最低）

除此之外，在 n8n 中，你還可以使用工具輸出解析器，它本質上將用於構建最終輸出。我使用的選項是提供一個 JSON 示例，如下所示：



{

"subtasks":[

 {

 "id":"openai_latest_news",

 "query":"最新 OpenAI 公告和新聞",

 "source_type":"news",

 "time_period":"recent",

 "domain_focus":"technology",

 "priority":1,

 "start_date":"2025-06-03T06:00:00.000Z",

 "end_date":"2025-06-11T05:59:59.000Z"

},

{

 "id":"openai_official_blog",

 "query":"OpenAI 官方博客最新文章",

 "source_type":"web",

 "time_period":"recent",

 "domain_focus":"technology",

 "priority":2,

 "start_date":"2025-06-03T06:00:00.000Z",

 "end_date":"2025-06-11T05:59:59.000Z"

}

]

}

這些內容看起來複雜，但今天的許多工具都提供了開箱即用的結構化輸出功能，所以你可能不需要自己實現它。n8n 使語境工程的這一部分變得輕而易舉。這是我看到許多 AI 開發者出於某種原因忽視的語境工程的一個被低估的方面。希望語境工程能更加突出這些重要技術。這是一種非常強大的方法，特別是當你的智能體獲得需要以特殊格式傳遞給工作流中下一個組件的不一致輸出時。

工具（Tools）

我們使用 n8n 構建智能體，因此很容易在語境中放入當前日期和時間。你可以這樣做：



當前日期和時間是：{{ $now.toISO() }}

這是在 n8n 中調用的一個簡單、方便的函數，但通常將其構建爲專用工具，可以幫助使事情更加動態（即，只有當查詢需要時才獲取日期和時間）。這就是語境工程的意義所在。它強制你，作爲構建者，對傳遞什麼語境以及何時傳遞給 LLM 做出具體決定。這很棒，因爲它消除了應用程序中的假設和不準確性。

日期和時間是系統的重要語境；否則，對於需要當前日期和時間知識的查詢，系統往往表現不佳。例如，如果我要求系統搜索上週發生的 OpenAI 最新開發新聞，它只會猜測日期和時間，這將導致次優查詢，從而導致不準確的網絡搜索。當系統有正確的日期和時間時，它可以更好地推斷日期範圍，這對搜索智能體和工具很重要。我將此作爲語境的一部分添加，以允許 LLM 生成日期範圍：



獲取上述子任務信息後，你將添加兩個額外字段。這些對應於 start_date 和 end_date。根據當前日期和選擇的 time_period 推斷此信息。start_date 和 end_date 應使用如下示例格式：

"start_date": "2024-06-03T06:00:00.000Z",

"end_date": "2024-06-11T05:59:59.999Z",

我們專注於架構的規劃智能體，所以這裏不需要添加太多工具。唯一有意義的其他工具是檢索工具，它根據查詢檢索相關的子任務。讓我們在下面討論這個想法。

RAG 和記憶（RAG & Memory）

我構建的深度研究應用程序的第一個版本不需要使用短期記憶，但我們構建了一個版本，可以爲不同的用戶查詢緩存子查詢。這有助於實現工作流程中的一些加速 / 優化。如果用戶之前已經使用過類似的查詢，可以將這些結果存儲在向量存儲中並對其進行搜索，以避免需要爲我們已經生成並存在於向量存儲中的計劃創建新的子查詢集。請記住，每次調用 LLM API 時，你都會增加延遲和成本。

這是聰明的語境工程，因爲它使你的應用程序更加動態、更便宜、更高效。你看，語境工程不僅僅是優化你的提示；它是爲你的目標選擇正確的語境。你還可以更加創造性地維護該向量存儲以及如何將那些現有的子任務引入語境。創造性和新穎的語境工程是護城河！

狀態和歷史語境（States & Historical Context）

我們在深度研究智能體的 v1 中沒有顯示它，但這個項目的一個重要部分是優化結果以生成最終報告。在許多情況下，智能體系統可能需要修改所有或部分查詢、子任務，以及可能從網絡搜索 API 中提取的數據。這意味着系統將多次嘗試解決問題，並需要訪問先前的狀態和系統的潛在所有歷史語境。

在我們的用例語境中，這意味着什麼？在我們的示例中，這可能是讓智能體訪問子任務的狀態、修訂（如果有的話）、工作流中每個智能體的過去結果，以及在修訂階段幫助所需的任何其他語境。對於這種類型的語境，我們傳遞的內容將取決於你正在優化的內容。這裏會發生很多決策制定。語境工程並不總是直接的，我想你可以開始想象這個組件需要多少次迭代。這就是爲什麼我繼續強調其他領域的重要性，如評估。如果你沒有測量所有這些東西，你怎麼知道你的語境工程努力是否有效？

結語

在這篇文章中，我們沒有涵蓋語境工程的許多其他方面，如語境壓縮、語境管理技術、語境安全性，以及評估語境有效性（即，衡量該語境隨時間的有效性）。我們將在未來的文章中分享更多關於這些主題的想法。

語境可能會稀釋或變得低效（即，充滿過時和不相關的信息），這需要特殊的評估工作流程來捕捉這些問題。

我期待語境工程作爲 AI 開發者 / 工程師的重要技能組合繼續發展。除了手動語境工程，還有機會構建自動化有效語境工程處理的方法。我見過一些嘗試這樣做的工具，但這個領域需要更多的進展。請繼續關注我即將發佈的文章中關於這方面的更多想法。

原文鏈接：Context Engineering Guide[3]

參考資料

[1]

Context Engineering in Practice: https://rlancemartin.github.io/2025/06/23/context_engineering/

[2]

The Skill That's Replacing Prompt Engineering: https://simple.ai/p/the-skill-thats-replacing-prompt-engineering

[3]

Context Engineering Guide: https://nlp.elvissaravia.com/p/context-engineering-guide

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/z19FJgUqSkUKcHgpTEigQQ

猜你喜歡