在前面兩天，我們探討了Prompt Engineering如何幫模型建立規則邊界，以及如何在程式碼中管理模板

但隨著Agent開發走向深水區，你很快會發現光把Prompt寫好遠遠不夠
當Agent進入多輪對話、呼叫外部工具（Tool Calling）、反覆執行推理迴圈時，它所面對的Context（上下文）會以驚人的速度膨脹
想像一下你的LLM是一隻神隱少女中的無臉男，在不斷餵食下(CONTEXT)，變得越來越肥大，導致無法快速行走(思考)

那要如何解決Context越來越肥大的問題?
今天我們就從這個前沿視角出發，徹底拆解：甚麼是Context Engineering？為什麼它是現代 Agent 系統的核心骨幹？

一、Context Engineering 的本質：為Agent打造高效的「工作桌面」

LangChain將Agent的運作視為一個持續的「感知 ➔ 思考 ➔ 行動」循環
在這個循環中，LLM本身不具備持久狀態，每一次向LLM發出請求，都必須將它當下決策所需的一切資訊完整打包送入

這份被打包的資訊集合，就是 Context（上下文）。

Context Engineering 的核心定義：
不是被動地將歷史紀錄堆疊給模型，而是主動設計一套**「資訊獲取、篩選、轉換與裁剪」**的動態管線，在有限的注意力與Token預算下，確保模型每一輪迭代時的工作桌面（Working Memory）都保持最高資訊密度與零噪音

二、為什麼Context膨脹是Agent的頭號殺手？

在單純的Chatbot中，Context通常只是簡單的「問答對話歷史」
但在自主Agent中，Context包含了：

1. 系統角色與約束（System Prompts）
2. 工具定義清單（Tool Definitions / Schemas）
3. 多輪工具呼叫與環境回傳結果（Tool Invocations & Execution Outputs）
4. 檢索增強的外部文件片段（RAG Documents）
5. 短期推理軌跡（Scratchpad / CoT Steps）

如果缺乏工程化管理，這種Context會引發三大致命問題：

• Token成本與延遲雪崩：每一輪迴圈都需要重複傳輸前面的所有歷史，API費用呈指數級暴增，First Token 延遲（TTFT）大幅拉長
• Lost in the Middle（注意力迷失）：即便模型宣稱具備數百萬Token的Context Window，大量實證研究顯示，模型對長文本中間區段的檢索與推理能力會顯著退化
• Context Poisoning（上下文污染）：過多冗長、錯誤或無關的工具回傳內容（例如一次回傳了5000行 raw JSON），會直接干擾模型的下一步決策，導致Agent陷入死循環

三、Context管理四面相

在現代Agent工程架構中，Context Engineering主要由以下四個核心維度構成：
圖片來自(LangChain Team https://www.langchain.com/blog/context-engineering-for-agents)

1. 寫入與持久化（Write / Store）

這裡的Write千萬別誤會成Write in Context Window，而是指將Agent的執行狀態以結構化方式儲存，明確區分什麼是暫時性的中間步驟（Scratchpad），什麼是需要跨輪次保留的事實
簡言之~這個行為的目的是為了將大量的資訊儲存起來，以備之後需要時再使用，而不直接存於context window中

2. 精準篩選（Select / Retrieve）

不要在每一輪把所有50個工具的定義都塞進Prompt
而是根據當前用戶意圖，動態選取最相關的 3~5 個工具定義注入Context，大幅降低模型的決策負擔
或是銜接前面步驟，當你把資訊放在外部儲存後，需要讀進來時肯定也不會是全部的資訊，因此可以用到Select概念，將你真正所需、符合當前任務的資訊選擇出

3. 壓縮與轉換（Compress / Transform）

工具回傳的 Raw Data（如資料庫查詢結果、網頁 HTML）往往包含大量雜訊。在塞入 Context 前，必須透過解析器進行剪裁，僅提取關鍵欄位，或利用小型模型先進行局部總結。

4. 淘汰與驅逐（Evict / Window）

當對話輪次過長時，必須建立明確的淘汰策略——是保留最近 N 輪？還是保留最初的任務目標加上最近的對話？這需要透過確定性的邏輯加以裁決。

四、Prompt Engineering 與 Context Engineering 的層次對比

小小自問自答

Q. 是不是必須用到這四個概念才能稱為Context Engineering呢?
A. 我覺得未必，有時候不是每個任務都需要經過Compress步驟，若Compress導致原本應該呈現的資訊被裁減，我們可以跳過這個步驟，因此去選擇自己所需的概念實行就好

Q. 從Write到Select到Compress的流程，是一定要照這個順序嗎?
A. 不用喔!!如同前面所述，你可以選擇自己所需要的概念就好，因此你想在Write前Compress資訊，只要不會因此裁減到重要訊息，也是沒問題的!!!

小結與下集預告

Context Engineering是現代Agent架構從「雛形展示（PoC）」邁向「生產級可用（Production-ready）」的分水嶺。只有當系統學會主動管理自己的工作記憶，Agent 才能在長程任務中保持清醒與穩定

理解了Context Engineering的理論架構後，在真實的程式碼中，我們該如何實作？

明天 【Day 5】怎麼應用 Context Engineering，我們將進入實戰篇，透過程式碼實作完整Context管線！