使用 AI 時，我們已經熟悉一些提示原則：說清楚任務、提供必要背景、指定輸出格式，需要時再附上範例。
但當 AI 開始處理真實工作，光是把要求寫清楚，還有一些問題沒有解決。
請它回答產品問題，它需要找到適用的文件；請它修改程式，它需要讀取相關檔案與專案規則；請它接續一項長任務，它需要知道哪些步驟已經完成、哪些問題仍未解決。
這些資訊從哪裡取得？哪些應該現在提供，哪些等需要時再查？當文件更新、工具回傳結果、工作進度改變，下一輪又該帶入什麼？
上下文工程（Context Engineering）處理的，就是模型執行任務時，這些資訊如何被準備、組織與持續更新。
提示工程（Prompt Engineering）仍然是其中的重要部分。當任務從一次回答延伸到多個步驟，需要設計的範圍也隨之包含資料取得、工具介面、記憶與工作狀態。
模型每一輪收到的，不只有你的問題
一次模型呼叫，可能同時包含任務指令、對話紀錄、取回的文件、工具說明，以及前一步的執行結果。這些內容共同構成本輪上下文（Context）。
例如，客服 AI 收到「這筆訂單可以退貨嗎？」時，光有「請根據公司政策回答」這項指令仍然不足。它可能還需要：
- 訂單日期
- 商品類型
- 適用地區
- 對應版本的退貨政策
這裡有個重要區別：系統擁有的資料，與模型這一輪收到的資料，往往不是同一批。
訂單存在資料庫裡，仍需要查詢；政策放在知識庫裡，仍需要檢索；過去對話即使已經保存，也未必會完整帶入下一次呼叫。
因此，上下文工程要管理兩件事：
- 資訊如何保存。
- 每一步如何選出需要的內容。
它既適用於單次問答，也適用於多步驟的 AI 代理（AI Agent）。前者可能只需要妥善組合指令與資料；後者還需要隨著工作進展，反覆更新上下文。
本文討論的是模型執行任務時的資訊設計。模型訓練與微調（Fine-tuning），則屬於改變模型參數的另一種途徑。
上下文工程包含哪些技術？
上下文工程涵蓋多種技術。它們分別處理資訊的取得、組織、保存與使用，不需要每個系統全部採用。
| 設計工作 | 對應技術與方法 | 具體作用 |
|---|---|---|
| 設計指令與示例 | 提示模板、動態指令、少樣本提示、示例檢索 | 依任務提供規則，挑選適合的參考範例 |
| 取得外部知識 | RAG、混合檢索、重排序、中繼資料過濾 | 找出相關內容，再依版本、日期或適用範圍篩選 |
| 管理對話與工作狀態 | 對話歷史選取、結構化狀態、檢查點 | 保存進度與已確認事項，決定哪些狀態要提供給下一輪模型 |
| 建立跨任務記憶 | 記憶擷取、持久化儲存、記憶檢索、更新與失效處理 | 保存值得延續的資訊，需要時取回，並處理過期或衝突內容 |
| 設計工具使用介面 | 工具呼叫、工具結構定義、動態工具選取、結果過濾與分頁 | 讓模型知道工具怎麼用，並取得足以支持下一步的結果 |
| 控制上下文容量 | Token 預算、歷史裁剪、上下文壓縮、外部保存、按需讀取 | 控制每輪輸入量，保留必要資訊及回查途徑 |
| 隔離不同工作的上下文 | 子代理、獨立工作階段、狀態分區、執行環境隔離 | 讓不同工作分別處理細節，只交換需要的結果 |
其中有些是通用工程方法，名稱也可能因框架而異。這張表是理解範疇的地圖，不是一套統一標準。
這些方法經常一起使用。例如，檢索先找出候選文件，重排序挑選較相關的段落，Token 預算再限制本輪帶入的內容量。Token 是模型處理內容的計量單位，不直接等同於字數。
技術之間如何配合，取決於這一步要完成什麼判斷。
資料存在，為什麼還是答錯？
回到退貨問題。客服 AI 答錯，可能有幾種不同原因：
- 必要的政策文件沒有被收錄。
- 文件存在，但這次搜尋沒有找到。
- 找到了相關文件，卻選到不適用的版本。
- 取回內容正確，但整理時刪掉重要條件。
- 條件已經完整提供，模型仍然理解錯誤。
這些問題需要不同的修正。補資料無法解決所有搜尋問題，改善搜尋也無法保證模型正確解讀。
例如，文件片段寫著「購買後三十天內可退貨」，但完整政策還包含商品類別與地區限制。若只保留這句話，模型就缺少判斷例外所需的資訊。
這時，中繼資料可以協助保留文件日期、版本與適用範圍；檢索時也能利用這些欄位過濾。若問題包含精確的商品代碼，混合檢索可以同時利用關鍵字比對與語意相似度；候選內容太多，再透過重排序縮小範圍。
排查時，可以沿著以下路徑逐段檢查：
系統擁有的資料 → 取回的資料 → 實際提供給模型的內容 → 最後回答
最先要確認的是：足以支持正確答案的證據，有沒有真正進入本輪輸入。
工具怎麼設計，也會改變模型看到的資訊
工具不只是讓 AI 多一項能力，也決定它如何取得新資訊。
模型通常透過工具的名稱、用途說明與參數定義，判斷何時呼叫。周邊系統執行工具後，再將結果提供給模型，成為下一步判斷的依據。
例如，找一位聯絡人時，工具若回傳整本通訊錄，模型就必須處理大量無關內容。若工具能依姓名搜尋，再回傳必要欄位，資訊就更貼近任務。
不過，精簡也不能只看字數。如果後續查詢需要聯絡人編號，就不能因為編號難讀而刪除。若工具只回傳部分結果，也應讓模型知道還有後續頁面。
工具介面需要說清楚三件事：
1. 什麼時候用
說明用途與適用情況。
2. 怎麼呼叫
定義必要參數、格式與限制。
3. 如何解讀結果
解釋內容代表什麼、是否完整，以及能否繼續查詢。
工具很多時，還可以依任務階段選擇提供哪些工具。查詢進度與提交修改是不同工作，模型不一定需要在每一輪都看到所有操作選項。
哪些先提供，哪些需要時再讀？
如果資料很少，而且確定會用到，直接提供通常最簡單。當資料量大，或需求會隨任務進展改變，就可以考慮按需讀取。
程式代理的工作很適合說明這個差別：專案規則可以預先提供；至於哪個檔案、哪段程式需要閱讀，再根據當下問題搜尋。
大型搜尋結果也可以保存在外部檔案，之後再讀取相關部分。原始資料仍然存在，但不必每一輪都完整帶入。
| 安排方式 | 適合的情況 | 主要代價 |
|---|---|---|
| 預先提供 | 資料少，而且確定會用到 | 不相關內容也可能持續占用上下文 |
| 按需讀取 | 資料多，下一步需求尚未確定 | 增加查詢時間，也可能漏查 |
| 混合使用 | 固定規則與動態資料並存 | 需要決定預載與查詢的界線 |
按需讀取的關鍵，是保留可找到資料的線索，例如檔案位置、文件名稱或查詢條件。只把內容移出去，卻沒有留下取回方法，後續工作就難以使用它。
長任務需要整理，也需要交接
隨著對話與工具呼叫增加，上下文會累積。較大的上下文視窗（Context Window）能容納更多內容，但不會自動消除版本衝突、重複資訊與過期決策。
這時，可以根據問題採取不同做法。
壓縮歷史，保留後續需要的判斷依據
假設程式代理嘗試過多個修正方案，下一輪可能需要的是目前採用的方案、選擇理由、未解問題與測試結果，而不是所有重複輸出。
若摘要只留下「採用方案 B」，卻刪掉方案 A 失敗的原因，後續仍可能重走同一條路。壓縮品質要看必要資訊是否保留，而不是只看縮短多少。
保存工作狀態，讓任務能夠接續
進度、完成項目與待辦事項，可以保存成結構化狀態；需要恢復工作時，再由檢查點載入。值得跨任務延續的偏好或知識，則可以另存為記憶，依需要取回。
這也說明了狀態與記憶的差異：前者常描述「這項工作現在進行到哪裡」，後者則可能在未來不同工作中仍然有用。
兩者都需要更新。過期目標或錯誤筆記一旦反覆被讀取，也可能持續影響後續判斷。
分開處理可以獨立完成的工作
研究任務可以由不同子代理各自探索，再交回必要結果。這能減少單一代理需要處理的細節，但也增加成本與交接風險。
若子任務高度相依，需要頻繁交換大量資訊，分開處理就未必划算。執行環境隔離也不會自動帶來上下文隔離；還要決定哪些結果應該回傳給模型。
怎麼知道上下文設計有沒有改善？
先選一組有明確判定依據的任務，保留問題、取回資料、模型輸入、工具結果與最後回答，再比較修改前後的差異。
以退貨問答為例，可以檢查：
- 是否使用適用的政策版本？
- 是否保留商品與地區限制？
- 資料不足時，是否詢問或明確說明？
- 是否能指出回答的依據？
- 是否增加不必要的查詢、等待時間與用量？
比較時，盡量固定模型與其他設定，先改一項策略，才能更清楚地判斷效果。
例如，工具結果縮短後用量降低了，但模型無法再取得查證所需的編號，就不能只看成本下降便認定成功。上下文設計要同時評估任務成果與使用代價。
提示寫清楚之後，下一步要問什麼？
提示寫清楚之後，下一個值得檢查的問題就是：
模型這一步需要知道什麼，而系統實際提供了什麼？
沿著兩者之間的差異，才能決定應該補資料、改搜尋、調整工具，還是重新整理工作狀態。
參考資料
本文依公開文章與官方文件整理。通用情境經改寫，產品案例依來源描述，未自行進行成效實測。