Context Engineering 實作原理與檢查清單：Agent 工作流程裡的上下文工程實戰

一分鐘判斷這份清單是否適合你

如果你正在開發一個需要與 LLM 互動的 Agent 系統，並且遇到的問題不只是“prompt 寫不好”而是“模型總是不記得上個步驟的關鍵信息”或“上下文都快撐爆 token 還漏了重要約束”，那麼這份 Context Engineering 檢查清單就是為你準備的。

反之，如果你的 Agent 只是簡單調用一次 API 返回結果，或者你對當前任務不需要管理多輪上下文狀態，那你當前可能並不需要完整的 Context Engineering 實踐——優先完成基礎 prompt 優化即可。

第一步：誰都不能跳過的上下文 Schema 定義

Context Engineering 的起點不是寫 prompt，而是定義「上下文結構（Context Schema）」。很多人一上來就往系統 prompt 裡塞大量信息，結果就是上下文臃腫、關鍵數據被淹沒。正確的做法是：先用 JSON Schema 或類似形式定義 Agent 必須感知到的資訊字段，包括：

• 任務目標（Task Goal）
• 目前工作區狀態（如檔案清單、環境變數）
• 歷史動作摘要（Action History）
• 外部約束（如權限、時間限制）

這一步驟決定了後續所有上下文注入的邊界。如果你跳過 Schema 定義直接寫程式碼，很容易出現「該有的沒有、不該有的一大堆」的局面。一個真實的失敗案例是：某團隊在建立程式碼審查 Agent 時，因為沒有明確定義「審查標準」字段，導致 Agent 在不同會話中反覆追問相同的問題，最終上下文膨脹到無法處理。

第二步：上下文注入的「黃金分段」與最小化原則

定義好 Schema 後，下一步是決定「什麼時候要注入什麼資訊」。普遍的錯誤是在每個請求中都把全部上下文塞進去，這樣做不僅浪費 token，還會降低 Agent 對關鍵訊息的注意力。

實際工程中，你應該把上下文分為三類：

• 靜態上下文：幾乎不變的背景資訊（如係統說明、全域限制），僅在首次注入或變更時更新。
• 動態上下文：每次互動都會變化的內容（如當前步驟結果、最新狀態），隨請求發送。
• 臨時上下文：僅在特定動作下所需的資訊（如 API 回應詳情、臨時快取），用完即棄。

這個分段的實操方法是：在程式碼中為每種上下文類型設定獨立的「上下文注入函數」（例如 inject_static_context()、inject_dynamic_context()），並在 Agent 的每個循環中按需呼叫。這樣既能減少 token 開銷，又能保證模型看到的上下文總是最新的。

第三步：最容易流於形式的步驟－上下文摘要（Context Summarization）

幾乎所有 Context Engineering 教程都會提到“對歷史對話做摘要”，但在實際工程中，這一步經常淪為形式主義。原因在於：很多人直接呼叫 LLM 對完整對話做總結，然後把總結文字丟回上下文──結果摘要本身又成了新的資訊噪音。

正確的做法是選擇性地摘要：只對「已完成的動作序列」做結構化摘要，而不是對模型輸出全文做自然語言總結。例如，如果 Agent 已經連續做了三次文件搜尋操作，你應該摘要為“已搜尋檔案：config.py, main.py, utils.py（範圍：專案根目錄）”，而不是“Agent 正在試圖找到設定檔...”。這一步驟的失敗往往導致 Agent 在後續步驟中重複執行已經完成的操作，或是遺失關鍵邊界資訊。

真實場景：一個調試 Agent 因為摘要裡包含了大量「正在嘗試...」的中間輸出，導致模型誤以為還在探索，從而陷入死循環。修復方式就是改用結構化摘要：只保留「已執行動作」和「結果狀態」兩項。

第四步：最小可執行的檢查路徑－你今天就能試的 4 步

如果你之前沒有做過 Context Engineering，現在可以從這個最小路徑開始：

1. 檢查上下文結構：打開你的 Agent 程式碼，找到所有拼接到 prompt 裡的變數。它們中有沒有你其實不需要的舊資訊？有沒有遺漏的關鍵約束？先列一個清單。
2. 隔離靜態上下文：把不會變的系統說明單獨拿出來，只在會話開始時注入一次。如果你現在每次要求都重複發送相同的系統 prompt，這一步驟可以立刻減少 30% 的 token 佔用。
3. 測試一個邊界場景：找一個容易讓 Agent 失去上下文的場景（例如連續 5 輪對話後），觀察它是否還記得最初的指令。如果它忘了，檢查你的動態上下文更新邏輯是否有覆蓋遺漏。
4. 實驗摘要格式：把一段歷史對話交給 LLM，分別用「自然語言總結」和「結構化欄位清單」兩種方式要求摘要，比較哪一個在後續測驗中表現得更好。

這個最小路徑可以幫助你在一個下午內找到至少一個情境工程中的實際問題，並驗證改善效果。

做完清單後：向系統化 Context Engineering 進階

當你完成了上述最小檢查路徑，並且嚐到了結構化上下文帶來的效果提升，你會發現 Context Engineering 遠不止一張清單。它涉及更深入的 Agent 架構設計，例如：上下文版本控制、多 Agent 共享上下文、上下文持久化與復原、基於上下文的偵錯和評估系統。

如果你希望從“臨時修補”升級到“系統設計”，接下來的方向應該是：

• 學習如何為複雜 Agent 工作流程設計上下文生命週期（Context Lifecycle）
• 探索情境評估指標（如資訊密度、注入時機準確性）
• 理解情境工程與 prompt engineering 的邊界與配合

這些內容在單篇文章裡無法全面覆蓋，但你可以透過高品質原創付費文章和 AI 程式設計進階課程獲得系統性的知識體系。