如果你在 2023 年還活在「提示詞工程（Prompt Engineering）」的世界裡，那時候大家相信，只要把話說得更準、更細、更像咒語，大模型就會更聰明。

模型不再只被拿來做一次性的問答、摘要或文案生成。它開始要連接文件系統、讀 Slack、查資料庫、呼叫工具、跨多輪任務維持狀態，甚至在一個長流程裡自己拆解問題、回收資訊、做出下一步決策。

這時候，真正的瓶頸就不再只是「你怎麼寫那一句 prompt」，而是： 模型在這一刻到底看到了什麼，以及沒看到什麼。

Context Engineering，就是在這個壓力下長出來的。

它看起來像是個新詞，但它不是憑空誕生的流行語；更像是一個行業在踩過大量坑之後，終於為同一種痛苦找到的共通名字。這篇文章想做的，不是把它當成一句新口號介紹，而是把它放回時間軸裡，看看它怎麼從 prompt engineering 的邊界處長出來，又怎麼在今天變成 AI Agent 時代最關鍵、也最容易被低估的工程能力。

一、縱向分析：Context Engineering 不是突然出現的，它是被「做出來」的

1. 真正的前史，不在 2025，而在更早以前

如果把「Context Engineering」當成一個寬泛概念，它其實比大模型熱潮早得多。人機互動、情境感知系統、資訊檢索、個人化推薦，甚至早年的對話系統，都在處理同一個老問題：

系統在某個時刻，應該基於哪些上下文理解你、回應你、幫你做事。

只是那個年代，大家不會用今天這套詞彙說話。當時沒有幾百萬 token 的上下文窗口，也沒有「把工具、記憶、檢索與外部狀態一起塞進模型工作記憶」這件事。於是，「context」是一個重要概念，但還不是一門獨立工程學。

真正讓它開始成形的，是大模型把一個舊問題徹底放大了： 模型很強，但它每一次推理只看得到當下那個窗口。

它像一個聰明但短期記憶極端有限的同事。你每次找它，它都很能講；可你一旦任務拉長，它就忘、就亂、就被雜訊帶偏。

這是 Context Engineering 的根部：不是某位名人一拍腦袋創造了一個詞，而是產業先遇到了一個系統性痛點，才反過來為它命名。

2. 2020：RAG 把「上下文」第一次從 prompt 外面搬進來

很多人談 Context Engineering，會直接從 2025 年的名詞爆紅講起。但如果沒有 2020 年的 RAG，這條路大概根本不會長成今天這樣。

2020 年，Lewis 等人在 NeurIPS 發表 Retrieval-Augmented Generation。那篇論文要解決的核心問題很務實：模型參數裡存的知識有限，更新不方便，還容易幻覺；如果能在生成前先從外部知識庫檢索相關內容，再把它帶進來，答案就能更準，也更可追溯。

這件事在當時看起來像知識增強；回頭看，其實它做了一個關鍵的思想轉向： 模型的能力，不只由模型本身決定，也由你如何為它準備輸入上下文決定。

也就是說，從這一刻開始，「讓模型看見什麼」開始成為與「模型有多強」同等重要的問題。這其實就是 Context Engineering 的雛形，只是那時它還被叫做 RAG、檢索、外部記憶，而不是今天這個名字。

3. 2022 到 2023：Prompt Engineering 爆紅，也在同時暴露天花板

ChatGPT 把大模型推進主流之後，prompt engineering 幾乎成了第一代 AI 使用者的共同語言。每個人都在試：角色扮演、few-shot、chain-of-thought、格式約束、分隔符、系統提示。

那是一個很有魅力的時代，因為它讓人產生強烈錯覺：只要你夠會說，模型就會更會做。

這句話在單輪任務上沒有錯。OpenAI 官方提示工程文件也把「清楚指令、提供參考文本、拆子任務、用外部工具、系統化測試」講得很完整。問題是，一旦應用開始從 demo 走向 production，prompt engineering 的局限就暴露得很快。

第一，它很脆弱。語意相近但寫法不同的提示，品質可能差很多。 第二，它過度依賴單次輸入。當應用變成長流程、多輪互動、工具往返時，你根本不只是在設計一句 prompt，而是在管理一整個不斷膨脹的上下文狀態。 第三，它讓很多團隊誤以為問題出在措辭，於是拼命改 prompt，卻沒發現真正的故障點其實是：模型沒有拿到正確資訊、拿到太多雜訊，或資訊順序與格式不對。

也就是在這個階段，行業開始慢慢意識到：prompt engineering 並沒有錯，只是它描述的範圍太小了。

4. 2023 到 2024：工具調用、長上下文與 Agent 讓問題徹底失控

如果說 RAG 是第一次把外部知識搬進模型上下文，那麼 2023 到 2024 年的工具調用、函式調用、長上下文模型與 Agent 框架，則是把整個上下文問題從「重要」直接推到「失控」。

模型開始不只讀文本，還要讀工具定義、看 API 回傳、記住對話歷史、維持任務狀態、利用 scratchpad、讀寫檔案，甚至在多代理之間轉交任務。

這時候，context 不再只是「幾段文件＋一條 prompt」，而是一個混合體：

• 系統指令
• 使用者訊息
• 對話歷史
• 長短期記憶
• 檢索結果
• 工具列表與輸出
• 狀態變數與外部檔案引用

很多應用在這裡第一次碰到相同的現象：模型不是笨，而是被餵壞了。

你給它太少，它不會。 你給它太多，它分心。 你給它錯的順序，它誤判。 你把工具回傳原封不動塞回去，它被巨量 JSON 淹死。 你讓歷史訊息無限追加，它開始忘早期約束。

也就是在這個階段，Agent 開發者開始說出一句很關鍵的話：很多 agent 的失敗，不是 model failure，而是 context failure。

5. 2024：MCP 的出現，讓上下文從內容問題變成連接問題

2024 年 11 月，Anthropic 公開 Model Context Protocol（MCP）。這看似是一個工具連接標準，實際上它把「context」往前又推了一步。

因為一旦模型需要與檔案、資料庫、企業系統、程式碼庫互動，上下文就不只是「塞進窗口裡的文字」，還包括：模型怎麼安全、標準化、可擴展地接到外部世界。

MCP 想解決的是一個很現實的工程問題：每接一個新資料源就要重做一套整合，成本太高，也難維護。它讓開發者開始以更系統化的方式思考上下文： 不是把所有東西都拷進 prompt，而是讓模型知道去哪裡拿、何時拿、拿多少、以什麼格式拿。

這一點非常關鍵。它意味著 Context Engineering 不只是「編排 token」，也是「設計資訊物流」。

6. 2025 年春夏：這個詞終於被喊出來

到了 2025 年，很多人其實都已經在做 Context Engineering，只是沒有統一名字。然後命名時刻來了。

2025 年 6 月中旬，Shopify 執行長 Tobi Lütke 在社群上表示，他更喜歡「Context Engineering」這個說法，因為它比 prompt engineering 更準確地描述核心技能：提供任務能被 LLM 合理解決所需的全部上下文。

一週後，Andrej Karpathy 進一步放大這件事。他說，在任何工業級 LLM 應用中，真正重要的是把「恰到好處的資訊」放進 context window，這是一門藝術，也是一門科學。

這兩句話之所以影響大，不是因為它們第一次發明了概念，而是因為它們替整個產業把那個模糊但共同的經驗說清楚了。大家突然意識到：對，原來我們一直在處理的就是這個。

同一時間，LangChain 把它定義成一套動態系統；HumanLayer 的「12-Factor Agents」則進一步把它放進工程原則裡。這裡有一個很有意思的現象： 到了 2025 年中，行業已經不再把 prompt engineering 視為錯誤，而是把它重新歸類成 Context Engineering 的一個子集。

7. 2025 年夏天：長上下文神話開始破功

如果沒有 2025 年的另一股力量，Context Engineering 可能還只是個新名詞。那股力量是：大家發現長上下文不是萬靈丹。

2025 年 7 月，Chroma 發表 Context Rot 研究，測試多個主流模型在更長輸入下的表現，指出一件很多開發者體感早就知道的事：上下文窗口變大，不代表模型會穩定地利用它。

輸入越長，模型表現常常越不均勻、越不可靠；而且真正讓性能掉下去的，不只是長度本身，還包括干擾項、語意相似雜訊、上下文結構。

這對行業是一記重錘。因為在那之前，很多人相信「模型上下文越大，管理上下文的重要性就會下降」。Context Rot 幾乎是反著講：窗口越大，你越需要工程化管理，不然只是把更多垃圾更昂貴地塞進去。

這也是為什麼 Context Engineering 在 2025 年下半年迅速從「流行語」變成「基礎能力」。因為長上下文沒有消滅這門技術，反而證明它不可避免。

8. 2025 年秋冬：Anthropic 與 Google 把它正式制度化

2025 年 9 月，Anthropic 發表〈Effective context engineering for AI agents〉，這幾乎可視為 Context Engineering 第一次被一線模型公司正式寫成一套明確方法論。

他們強調的不是一次性構造，而是反覆策展。因為 Agent 每跑一輪，就會產生更多可能相關的資訊；而這些資訊不能無腦累積，必須被壓縮、篩選、引用或隔離。

到了 2025 年 12 月，Google 在 Agent Development Kit 的架構說明中又把這個想法往前推了一步：context 不是一串可變字串，而是某個更大狀態系統的「編譯視圖」。

它把 Context Engineering 從一種「手工拼 prompt 的技巧」提升成一種架構觀。說得直接一點，這代表產業終於承認一件事：在 Agent 時代，context 本身就是基礎設施。

9. 到了今天：它還不是成熟學科，但已經是實務分水嶺

截至 2026 年，Context Engineering 仍然是一個邊界流動、定義尚未完全收斂的領域。但它已經足夠成熟到成為一條分水嶺：

• 還停留在 prompt 思維的團隊，會不斷微調句子，卻很難把 Agent 做穩。
• 理解 Context Engineering 的團隊，會把問題拆成資訊選擇、狀態管理、工具暴露、輸出壓縮等一連串可工程化子問題。

這不是語言上的升級，而是心智模型的升級：從「怎麼問模型」走向「怎麼建一個讓模型更容易成功的系統」。

二、橫向分析：今天的 Context Engineering，到底在和誰競爭？

先做場景判斷：它沒有單一直接競品，但有多條強力替代路線。如果把問題改成：今天市場上有哪些主流路線，正在解決「如何讓模型在真實任務裡更穩、更準、更能持續工作」這件事？那競爭者就非常清楚了。

我會把它歸為場景 C：競品充分。只是這些競品不是一個個 App，而是五種彼此競逐的路線：

1. Prompt Engineering
2. RAG-first 路線
3. Long-context brute force 路線
4. Fine-tuning／模型客製化路線
5. Framework-native Agent 路線

Context Engineering 與它們的關係，不是單純取代，而是逐步吸收、整合、重新排序。

1. Prompt Engineering：最容易上手，也最容易讓人誤判問題

如果說 Context Engineering 是現在最被看重的能力，那 Prompt Engineering 仍然是所有人最熟悉的起點。它最大的優勢很明顯：便宜、快速、低門檻。

但它的短板也正是它的迷人之處：它讓人太容易把所有問題都理解成「我還沒把 prompt 寫對」。

社群對 prompt engineering 最常見的抱怨其實有三種：

• 脆弱：換個模型版本、改個順序，效果就跑掉。
• 不可擴展：當任務從單輪變成長流程時，很難靠一個越寫越長的 system prompt 管住整個系統。
• 難診斷：因為所有問題最後都被折疊進一句 prompt，出了錯你很難知道故障點在哪裡。

從生態位來看，Prompt Engineering 現在更像是 Context Engineering 的局部手藝。你可以把它想成寫作能力：很重要，但如果整個報導的採訪、編輯系統都壞了，光會寫一句漂亮標題救不了全局。

2. RAG-first：最務實、最可追溯，也最容易陷入「檢索地獄」

RAG 是今天最常被拿來和 Context Engineering 相提並論的一條路。很多團隊第一次意識到「上下文很重要」，其實就是在做 RAG 的時候。

RAG 的優勢幾乎是企業級落地的理想清單：能接內部知識、能做資料更新、能提供一定程度可追溯性。這也是為什麼 2023 到 2024 年間，幾乎所有企業 AI 專案最後都會走到某種程度的 RAG。

但使用者對 RAG 的感受也很兩極。討厭它的人討厭的是「切 chunk、做 embedding、調 top-k... 最後還是不穩」。這正是 RAG 的困境：它把問題從「模型不知道」轉成「我怎麼把對的東西檢回來」。

也就是說，RAG 解決的是 Context Engineering 裡「select context」的一大塊，但不是全部。如果你把所有 context 問題都丟給檢索，那最後很容易掉進另一個坑：模型不是沒資料，而是你讓它在錯的時間、用錯的格式，看到了太多不該看的東西。

3. Long Context Brute Force：最省腦、最像魔法，也最容易被現實打臉

這條路的誘惑非常大：既然模型能吃 200K、1M 甚至更大的上下文，為什麼還要這麼麻煩地做檢索？直接把東西塞進去不就好了？

這種思路在 demo 階段非常有殺傷力。對很多開發者來說，這是最自然也最符合直覺的路線：上下文窗口既然是 RAM，那就多給 RAM。使用者喜歡 brute force 的原因很單純：少設計、少建管線、看起來也少出錯。

但真實口碑裡，這條路最大的槽點也最一致：貴、慢，而且一長就開始不穩。

Chroma 的 Context Rot 幾乎就是對這條路的公開審判。它提醒所有人：大上下文不等於均勻注意力，不等於穩定推理。所以 Long Context Brute Force 最適合的生態位，其實是原型驗證或低頻高價值任務。在你還沒時間做精細 Context Engineering 時的過渡方案。

4. Fine-tuning：把能力寫進模型裡，穩定但不靈活

另一條經常被拿來替代 context 管理的路線，是 fine-tuning。背後邏輯也很好懂：如果某些知識、風格會反覆出現，那我乾脆不要每次都塞進 context，而是直接把它寫進模型參數裡。

對使用者來說，fine-tuning 的最大優點是：穩。不需要每次再教一次，也不容易因 prompt 小改而大幅波動。

但它的問題，恰好與 Context Engineering 的優勢互補：更新慢、成本高、需要資料治理、對外部即時知識無力。你可以把它想成把知識刻進骨頭裡，而 Context Engineering 比較像替模型安排當下工作台。

社群對 fine-tuning 的真實評價通常很務實：**好用，但不能亂用。**因為很多團隊最後發現，自己以為是模型能力問題，實際上只是上下文設計問題。這時候一頭栽進 fine-tuning，不只花錢，也容易把本來應該外顯、可追蹤的資訊，藏進難以維護的參數裡。

5. Framework-native Agent 路線：最接近 Context Engineering 本體

最後一個同類，不是單一方法，而是一整條正在成形的生態（LangGraph、Google ADK、MCP 生態等）。這些路線的共同特徵是，它們不再問「prompt 怎麼寫比較好」，而是問：

• 什麼資訊應該保存在 session？
• 什麼要寫入長期 memory？
• 工具應該如何最小暴露？
• 如何做 eval 才知道問題出在 context pipeline 而不是模型本身？

這一派的使用者口碑也很典型：**做起來真的比較穩，但工程複雜度明顯更高。**它的好處是可觀測、可維護；壞處則是需要更成熟的工程團隊。這條路線目前佔據的生態位很清楚：它是給「已經知道 AI 值得做，現在要把它做穩」的人。

三、橫縱交匯：Context Engineering 真正改變的，不是技術名詞，而是 AI 開發的主語

如果把前面的時間線和競爭格局疊在一起，你會發現一件很有意思的事： Context Engineering 之所以在 2025 年之後迅速站穩，是因為它改寫了 AI 應用開發的主語。

• 舊主語是模型： 大家問的是哪個模型更強？哪個 prompt 更好？
• 新主語是系統： 大家開始問這個任務需要哪些資訊來源？這些資訊何時進場？如何避免上下文中毒、分心與遺忘？

這個轉向很重要，因為它把 AI 開發從一種「跟模型賭運氣」的手藝，慢慢推回到工程 discipline。也正因如此，Context Engineering 最終不太可能成為一個封閉品類。它更可能像 DevOps、資料工程一樣，慢慢被拆成一系列子能力：context assembly, memory architecture, retrieval strategy 等。

對企業與產品團隊來說，這裡面的機會非常大。因為模型能力越接近，真正把體驗拉開差距的，就越可能不是底模，而是上下文管理能力。同一顆模型，放在兩個產品裡，一個像失憶實習生，一個像真正懂你業務的同事，差別通常不在模型本體，而在 context pipeline。

但風險也同樣清楚。Context Engineering 現在很容易被講成萬能答案，彷彿只要把這個詞掛上去，系統就會穩。實際上，它恰恰相反： 它不是一句新 slogan，而是一串更麻煩、更細碎、更需要工程耐心的工作。

它沒有魔法，只有取捨。什麼該放進窗口，什麼該留在窗口外；什麼該摘要，什麼不能摘要。這些都沒有單一教條。

所以，對「Context Engineering 是不是下一個 buzzword」這個問題，我的判斷是： **它確實有 buzzword 的外表，但裡面包的是一個真問題。**而且這個問題，會隨著 Agent 更普及、工具更多、任務更長，而變得只會更重要，不會更不重要。

如果 prompt engineering 教會的是「如何對模型說話」，那 Context Engineering 真正教會的，是：**如何為模型搭一個比較不會失手的工作現場。**在 AI 的下一階段，這很可能才是最實在的護城河。

資料來源

• Lewis, Patrick et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（NeurIPS 2020 / arXiv 2020） https://arxiv.org/abs/2005.11401
• OpenAI Developers. Prompt engineering https://developers.openai.com/api/docs/guides/prompt-engineering
• Anthropic. Introducing the Model Context Protocol（2024-11-25） https://www.anthropic.com/news/model-context-protocol
• LangChain Blog. The rise of "context engineering"（2025-06-23） https://blog.langchain.com/the-rise-of-context-engineering/
• HumanLayer GitHub. 12-factor Agents - Principles for building reliable LLM applications https://github.com/humanlayer/12-factor-agents
• Chroma Research. Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025-07-14） https://www.trychroma.com/research/context-rot
• Anthropic Engineering. Effective context engineering for AI agents（2025-09-29） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Google Developers Blog. Architecting efficient context-aware multi-agent framework for production（2025-12-04） https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/
• GitHub. langchain-ai/context_engineering https://github.com/langchain-ai/context_engineering
• arXiv. Context Engineering 2.0: The Context of Context Engineering（2025-10-30） https://arxiv.org/abs/2510.26493