從「指令」到「情境」：Context Engineering 如何引爆 AI Agent 的真正革命？

你是否曾對 ChatGPT 下過一個看似清晰的指令，卻得到一個完全偏離軌道的回答？你是否覺得，要讓 AI 真正理解你的意圖，就像在跟一個極度聰明、卻又缺乏常識的外星人溝通？我們正站在一個關鍵的轉捩點：傳統的「提示工程」（Prompt Engineering）已觸及瓶頸，而一場由 Context Engineering（上下文工程，或稱情境工程） 驅動的 AI Agent 革命，正悄然重塑我們與機器互動的未來。

這不是關於如何把問題問得更漂亮，而是關於如何為 AI 構建一個完整的「認知世界」。李宏毅教授在 2026 年的前瞻性講座中，清晰地勾勒出這條技術演進路徑。本文將深入拆解這場革命的核心，揭示為何 Context Engineering 將是未來五年內，區分「玩具級 AI」與「生產力級 AI Agent」的關鍵分水嶺。準備好，我們將進入一個 AI 真正開始理解「言外之意」的時代。

要點一：Prompt Engineering 的黃昏——當「精準提問」不再夠用

傳統的提示工程，本質上是一場「猜謎遊戲」。使用者必須絞盡腦汁，將自己的意圖轉譯成模型能理解的「魔法咒語」。我們學會了使用「一步步思考」（Chain-of-Thought）、「扮演專家角色」等技巧，但這暴露了一個根本性缺陷：人類的溝通，極少依賴於單一、精確的指令。

想像一下，你對人類助理說：「幫我安排下週的會議。」助理不會只根據這七個字行動。他會調用腦海中的「上下文」：他知道你是誰、你的職位、你通常與誰開會、你偏好上午還是下午、公司常用的會議室有哪些、甚至你上週抱怨過某個時段太忙。這海量的背景資訊，從未被明確「提示」，卻是任務成功的關鍵。

大型語言模型（LLM）的困境與此類似。沒有上下文，它就像一個失憶的天才，每次對話都是從零開始。李宏毅教授在影片中一針見血地指出：

「我們過去花太多時間在雕琢單次的 prompt，但真正強大的 AI 應用，應該像一個持續學習、累積情境的夥伴。Context Engineering 就是要解決這個『失憶』問題。」

Prompt Engineering 是戰術，而 Context Engineering 是戰略。 前者關注單次交鋒的勝負，後者著眼於構建整個戰場的優勢。當 AI 應用從「問答機」邁向能獨立執行複雜任務的「Agent」（智能體）時，為其提供持續、連貫、多模態的上下文，就從「加分項」變成了「生存必需品」。這標誌著一個舊時代的結束，和一個更複雜、也更強大的新範式的開始。

要點二：Context Engineering 的核心三支柱——記憶、工具與規劃

那麼，Context Engineering 究竟在「工程」什麼？它不是一個單一技術，而是一個系統性的框架，主要由三大支柱構成，將原始的 LLM 武裝成真正的 AI Agent。

1. 記憶（Memory）：從失憶到擁有「連續性人格」

這是 Context Engineering 的基石。記憶讓 AI 能夠跨對話、跨任務、跨時間累積資訊。這不僅僅是記住「用戶叫小明」那麼簡單，而是包括：

• 對話歷史： 完整的互動紀錄，避免重複或矛盾。
• 實體記憶： 儲存關於用戶、地點、事件等關鍵實體的屬性與關係。
• 向量記憶： 將過往對話的語義嵌入向量資料庫，實現基於「意義相似度」的快速檢索。例如，當用戶提到「上次那個很貴的提案」，AI 能從記憶中搜尋出三個月前討論過的「年度預算計畫書.pdf」。
• 摘要記憶： 將冗長的互動濃縮成關鍵要點，解決上下文視窗長度的限制。這就像為 AI 配備了一個不斷更新的「工作筆記本」。

李宏毅教授以「旅遊規劃 Agent」為例：一個擁有記憶的 Agent，會記得你討厭早起、對海鮮過敏、上次稱讚了某類型的博物館。它規劃的第二天行程，會與第一天連貫，而非每次都從零開始推薦「十大必去景點」。

2. 工具使用（Tool Use）：從空談到動手執行

LLM 本質是「思想家」，擅長推理與生成文字，但無法直接操作現實世界。Context Engineering 通過定義和接入「工具」（Tools/APIs），賦予 AI 行動的「手腳」。關鍵在於，工具的描述與使用方式，本身就是餵給模型的核心上下文。

例如，提供給模型的上下文可能包括：

• 工具名稱：search_flight
• 功能：查詢航班資訊
• 參數：出發地、目的地、日期
• 回傳格式：JSON，包含航班號、時間、價格 當用戶說「我想下週二去東京」，模型在自身「規劃」能力的驅動下，會識別出需要調用 search_flight 工具，並自動從對話中提取「下週二」和「東京」作為參數。這個「工具庫上下文」讓 AI 從被動回答，轉變為主動執行的代理。

3. 規劃（Planning）：從被動反應到主動拆解

這是 AI Agent 的「大腦前額葉」。面對「幫我籌辦一個30人的產品發布會」這樣的複雜目標，模型需要自主將其分解為可執行的子任務序列：

1. 確定預算和日期（可能需要詢問用戶）。
2. 預訂場地（調用 search_venue 工具）。
3. 安排餐飲（調用 catering_service 工具）。
4. 製作邀請函（使用模型本身的文本生成能力）。
5. 發送邀請（調用 send_email 工具）。

規劃能力依賴於模型對目標的理解、對可用工具（上下文）的掌握，以及對任務邏輯順序的推理。優秀的 Context Engineering，就是為模型的規劃模組提供最清晰、最相關的「地圖和工具箱」。

要點三：RAG 的進化——從靜態檢索到動態情境構建

檢索增強生成（RAG）是當下最熱門的讓 LLM 獲取外部知識的技術。但在 Context Engineering 的框架下，RAG 的角色發生了根本性轉變。

傳統 RAG 像是「即時查百科全書」：用戶提問 -> 從向量資料庫搜尋相關段落 -> 連同問題一起送給模型生成答案。這仍是「一次性」的上下文注入。

進階的、為 Agent 服務的 RAG，是「動態構建任務專屬知識庫」的過程。 在李宏毅教授描繪的藍圖中，一個研究助理 Agent 的工作流程可能是：

1. 接收宏觀指令： 「為量子計算對加密貨幣的潛在影響撰寫一份報告。」
2. 自主規劃與檢索： Agent 自行將任務分解為「理解量子計算」、「理解當前加密貨幣加密技術」、「分析衝擊時間線」、「尋找案例」等子目標。
3. 多輪、多源檢索： 針對每個子目標，從學術論文庫、新聞網站、技術白皮書等不同來源進行檢索。每一次檢索的結果，都會成為下一輪檢索和思考的新上下文。
4. 綜合與生成： 最終，模型擁有的上下文不是幾段相關文字，而是一個為此任務動態構建、結構化、經過多輪篩選的完整知識體系，並據此生成高品質報告。

這個過程中的「檢索-評估-再檢索」循環，本身就是一個高級的上下文工程。它確保 AI Agent 是在一個不斷豐富、不斷聚焦的資訊環境中工作，而非對著一堆雜亂的初始資料硬幹。

要點四：新興架構與挑戰——Graph of Thoughts 與「幻覺」對抗

隨著 Context Engineering 的複雜度提升，新的技術架構應運而生，其中最值得關注的是 Graph of Thoughts (GoT) 範式。

傳統的思維鏈（Chain-of-Thought）是線性的：A -> B -> C。但在真實世界的複雜任務中，思考路徑往往是樹狀甚至網狀的。例如，規劃旅行時，「選擇目的地」和「確定預算」可能相互影響，需要來回對比。GoT 允許模型以更靈活、非線性的方式組織其推理過程，並將不同的「思考節點」（Thought）連接起來。這使得模型能：

• 探索多種解決方案分支。
• 合併不同分支的發現。
• 在遇到死胡同時回溯到先前的節點。

GoT 本質上是對模型「內部上下文」的一種高階管理方式。 它讓 AI Agent 的思考過程更接近人類，更能處理需要權衡、迭代和創造性解決的問題。

然而，賦予 AI 越多的上下文和自主權，就伴隨著越大的風險，首當其衝的就是 「幻覺」（Hallucination）的加劇。當 Agent 自主檢索網路資訊、調用多個工具、進行多輪規劃時，任何一個環節出錯（如檢索到錯誤資訊、工具回傳異常、規劃邏輯謬誤），都可能導致災難性的錯誤輸出，且更難追蹤溯源。

因此，Context Engineering 的另一面，是必須建立強大的「監控與驗證」上下文層。 這包括：

• 來源追溯： 為生成的每一段陳述，標注其依據的來源上下文（哪份文件、哪次工具調用）。
• 信心校準： 讓模型對自己的輸出給出信心指數，對低信心部分標記需人工覆核。
• 安全圍欄： 在關鍵工具調用（如轉帳、發送郵件）前，設置強制性的確認步驟。

要點五：產業衝擊與未來職能——人人都需要成為「情境架構師」

Context Engineering 的成熟，將引發連鎖性的產業變革。它的影響遠不止於技術圈，而是會重新定義許多職業的工作內容。

1. 軟體開發範式遷移： 未來的應用程式開發，將從「編寫所有業務邏輯程式碼」，轉向 「定義上下文與組裝智能體」。開發者更像是指揮官，負責：

• 為 AI Agent 挑選和組合合適的工具（APIs）。
• 設計記憶結構與知識檢索流程。
• 設定任務規劃的邊界與規則。
• 構建人與 Agent 協同工作的流程介面。

2. 新職業的誕生：「情境架構師」與「Agent 訓練師」

• 情境架構師（Context Architect）： 專精於為特定領域（如法律、醫療、金融）設計最有效的上下文框架。他們需要深度理解領域知識和 AI 模型的行為特性，知道什麼樣的記憶格式、工具組合、規劃提示能讓 Agent 在該領域表現卓越。
• Agent 訓練師/調校師： 類似於傳統的產品經理或業務分析師，但專注於透過互動、反饋和評估來「教導」和優化 AI Agent 的行為，確保其輸出符合業務目標與安全規範。

3. 企業競爭力的核心： 企業的私有資料（客戶互動紀錄、內部流程文件、產品知識庫）將成為構建專屬 AI Agent 最具價值的「上下文燃料」。誰能更系統化、更安全、更有效地將自身資料與業務流程「上下文化」，誰就能打造出無法被通用模型複製的競爭壁壘。 這將使得資料治理與知識管理從後台支援功能，一躍成為戰略前線。

---

Context Engineering 核心架構與傳統模式對比

下表匯總了 Context Engineering 驅動的 AI Agent 範式與傳統 LLM 應用模式的關鍵差異：

維度	傳統 LLM / 提示工程	Context Engineering 驅動的 AI Agent	影響與意義
互動模式	問答式、單次性、被動反應	任務式、連續性、主動規劃與執行	從「工具」升級為「同事」
核心焦點	優化單次輸入提示（Prompt）	設計持續的上下文系統（記憶、工具、規劃）	從戰術技巧到戰略架構
知識來源	主要依賴模型靜態預訓練知識	動態結合長期記憶、即時檢索（RAG）、工具回饋	知識實時更新，具備個性化與專屬性
任務複雜度	適合定義明確的單一任務	適合開放式、多步驟的複雜目標	可處理真實世界的模糊需求
技術關鍵	提示詞撰寫、微調（Fine-tuning）	記憶管理、工具編排、規劃與推理架構（如GoT）	工程重心從模型本身轉向系統整合
主要風險	幻覺、偏見、資訊過時	複雜錯誤鏈、安全與權限控制、決策可解釋性	風險管理需求指數級上升
開發者角色	提示工程師、微調專家	情境架構師、Agent 流程設計師、工具整合者	需要更廣泛的系統思維與領域知識

---

結論：擁抱不確定性，成為情境的塑造者

我們正從一個「如何向 AI 提問」的時代，邁入一個「如何為 AI 構建世界」的時代。Context Engineering 不是提示工程的替代品，而是它的必然演進，是釋放大型語言模型全部潛能的關鍵鑰匙。

對於科技愛好者、創業者與企業決策者而言，當務之急不再是追逐參數量最大的模型，而是開始思考：

• 我的業務或領域中，最有價值的「上下文」是什麼？ 是客戶的歷史偏好？設備的即時感測數據？還是法規條文的變更歷程？
• 如何將這些鬆散的資料，結構化成 AI Agent 可理解、可利用的記憶與知識？
• 我的工作流程中，哪些環節可以分解為「規劃-工具調用-記憶」的組合，交由 Agent 執行？

這場革命的終點，或許是我們每個人都能擁有一個或多個深度理解我們個人上下文、忠實執行我們複雜意圖的數字化身。它們記得我們的所有過往，了解我們的所有工具，並能替我們規劃未來。

最後，留給你一個李宏毅教授在影片中隱含的深刻問題：當 AI Agent 透過 Context Engineering 變得越來越連貫、越來越個性化、越來越能幹時，我們該如何定義我們與它的關係？是主僕、是夥伴，還是某種意義上，它成了我們意識與能力在數位世界中的延伸？ 思考這個問題，或許就是我們為自己——這個最終的「人類智能體」——進行最重要的 Context Engineering 的開始。