從提示詞工程到上下文工程：這不只是延伸，而是系統設計的質變

我最初也將「上下文工程」（Context Engineering）視為「提示詞工程」（Prompt Engineering）的自然延伸，誤以為核心只是寫出更長的提示詞。然而，在實際的產品建構中，我意識到這是一個根本性的誤解。正如 Anthropic 也曾指出，上下文工程的本質更接近系統設計，它要求我們將提示詞視為眾多元件之一，並與檢索、記憶、工具、權限等要素進行結構化組合。唯有如此，我們才能將大型語言模型從一個有趣的對話夥伴，轉變為一個真正能執行複雜任務的工作系統。

為什麼我們需要超越「更長的提示詞」？

隨著大型語言模型（LLM）能力的演進，其上下文視窗（Context Window）的擴張確實令人驚訝。從 Google Gemini 1.5 Pro 的 100 萬 token 到 Anthropic Claude 3 的 20 萬 token，我們似乎能將整本書都塞進提示詞裡。這股趨勢催生了一種迷思：只要給予足夠多的資訊，模型就能神奇地解決所有問題。然而，這種看似「暴力堆砌」的作法，很快就會碰到實際的瓶頸。

首先是顯著的成本與延遲問題。更長的上下文意味著更高的運算成本與更長的等待時間，這對於需要即時回應的產品而言，將對使用者體驗造成巨大影響。其次，模型在處理極長上下文時，效能表現也非盡善盡美。有研究指出，模型會出現「Lost in the Middle」的現象——位於上下文中間的資訊很容易被忽略或誤解，導致輸出品質不穩定。

更重要的是，一個長達數萬 token 的單體提示詞，幾乎無法維護、除錯與迭代。當系統出錯時，我們很難判斷問題是源於提示詞的某個段落，還是輸入資料本身的品質。因此，我們需要一個更結構化、更具擴展性的框架來思考如何為模型提供「對的」資訊，而不僅僅是「多的」資訊。這正是上下文工程的核心價值所在。

上下文工程的系統設計觀：拆解七大核心元件

當我們不再將上下文視為一個巨大的文字團塊，而是將其解構成一個由多個獨立元件構成的系統時，整個問題的輪廓就清晰了。參照 kenimo49 在 Zenn.dev 上的討論以及業界實踐，我們可以將上下文工程框架拆解為以下七個關鍵元件。讓我們來一一檢視這些要素，理解它們如何共同運作，將 AI 的潛力發揮到極致：

• 提示詞 (Prompt)：這是使用者意圖的直接體現，也是整個系統的觸發點。它定義了任務目標、角色扮演與回應的基本框架，但請記住，它只是起點，而非全部。
• 檢索 (Retrieval)：這正是 RAG（Retrieval-Augmented Generation） 的核心。系統會根據使用者查詢，從知識庫、資料庫或文件中動態抓取最相關的資訊片段，精準地提供給模型。這比將整個文件庫塞入提示詞更有效率且更準確。
• 記憶 (Memory)：賦予系統連續對話與個人化能力。這可以分為短期記憶（如當前對話的歷史紀錄）與長期記憶（如使用者的偏好、過去的互動總結）。有效的記憶管理能確保 AI Agent 不會像金魚一樣，每輪對話都重新開始。
• 工具 (Tools)：也就是我們常說的 Function Calling。它允許模型調用外部 API、執行程式碼或查詢即時數據（如天氣、股價）。這極大地擴展了模型的行動能力，使其能與真實世界的系統互動。
• 權限 (Permissions)：在企業或複雜應用中至關重要的一環。它定義了 Agent 能存取哪些資料、能執行哪些工具。這層控管確保了系統的安全性與合規性，避免 AI 做出越權行為。
• 格式 (Format)：對模型的輸出進行結構化約束。透過要求模型回傳 JSON、XML 或其他預定格式，我們可以確保其輸出能被下游的應用程式穩定地解析與使用，這對於建構可靠的自動化流程至關重要。
• 狀態 (State)：管理多步驟任務的進程。對於需要來回數輪才能完成的複雜工作流（如訂票、專案規劃），狀態管理器會追蹤目前進行到哪一步、已收集到哪些資訊，以及下一步該做什麼。

在這個系統中，提示詞不再是完整的劇本，更像是指揮家的手勢。它引導著各個元件（樂手）在何時、以何種方式介入，共同譜出最終的樂章。

如何從系統視角實踐上下文工程？

將視角從「寫提示詞」轉變為「設計系統」，意味著我們的工作流程也需要隨之改變。過去，我們可能花 80% 的時間在微調提示詞的措辭上；現在，這些時間應該被重新分配到設計、實作與評估上述的各個元件上。

一個好的起點是，在面對新任務時，先不要急著寫提示詞，而是問自己一系列關鍵的系統設計問題：

1. 任務目標是什麼？ 這將定義提示詞的核心指令與預期行為。
2. 需要哪些外部知識？ 這決定了我們該建立什麼樣的檢索系統（RAG），以及如何有效率地獲取資訊。
3. 任務需要與外部世界互動嗎？ 這決定了我們需要提供哪些工具（API），讓模型能執行實際操作。
4. 輸出結果將如何被使用？ 這決定了我們需要強制什麼樣的輸出格式，確保下游應用能穩定解析。
5. 這是一個一次性任務還是連續性對話？ 這決定了我們需要設計何種記憶機制，以維持對話連貫性或使用者偏好。

舉例來說，建構一個能回答公司內部文件的問答機器人。舊思路可能是將所有文件轉為文字，想辦法塞進一個超長提示詞。新思路則是：建立一個基於向量搜尋的 RAG 系統，當使用者提問時，系統先檢索最相關的 3-5 個文件片段（每個約 512 token），然後將這些片段連同原始問題一起交給一個簡潔的提示詞，指示模型根據提供的資料進行回答。這個系統不僅成本更低、反應更快，而且當回答出錯時，我們可以清楚地追溯是檢索環節出了問題，還是模型理解有誤，從而進行針對性優化。

上下文工程如何改變我們與 AI 協作的未來？

總結來說，上下文工程的成熟，標誌著我們與大型語言模型協作方式的典範轉移。我們不再是單純的「詠唱者」，而是成為了「架構師」。這種轉變不僅提升了 AI 應用的穩定性與天花板，更重要的是，它讓我們能以一種更工程化、更可預期的方式，去建構真正能解決複雜問題的智慧系統。

延伸閱讀

• Anthropic: Context Engineering for Better LLM-Powered Applications
• Liu, et al. "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172)
• OpenAI: Function calling
• Lewis, et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (arXiv:2005.11401)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。