如果你已經試過把 Prompt 改得越來越長，AI 還是會引用舊版本、忘掉限制，甚至拿錯工具，那問題可能不只在句子寫得不好。Context Engineering 談的是更大的範圍：在模型每一輪回答之前，哪些任務、資料、工具、對話歷史與記憶應該被放進它能參考的 context，哪些應該先整理、壓縮或不要放進去。
先講本文的判斷：Prompt Engineering 是設計指令的一部分；Context Engineering 則是設計整個工作環境。 你不需要因為看到這個新名詞就立刻部署一套 Agent。先把輸入資料、成功條件、工具範圍與驗收方式整理好，通常比再加十條「請務必」更值得。
本文以 2026 年 9 月 8 日查到的 Anthropic、OpenAI 與 Model Context Protocol 官方文件為界。Context Engineering 目前仍是正在成形的說法，我沒有把它當成跨供應商唯一標準；文中會分開標記已查證的事實、本文推論、實務建議與尚未確認的部分。
文章目錄
先講結論：你不是只需要更長的 Prompt
已查證的定義
Anthropic 在 2025 年 9 月發布的Context Engineering 工程文章把 context 描述成模型在生成時可以參考的 token 集合，並把 Context Engineering 說成整理與維護這組資訊的策略。文章列出的範圍不只包含使用者最後輸入的句子，也包括系統指令、工具、MCP、外部資料與訊息歷史。
換成工作語言，就是你不只是在想「我要怎麼問」，還要問以下幾件事：
- 這一輪真正要完成的任務是什麼？
- 哪些資料是這個任務必要的，哪些只是順手丟進來？
- 工具的輸入與輸出是否清楚，還是每個工具都在做差不多的事？
- 先前對話、記憶或筆記有沒有過期、互相矛盾，或已經長到找不到重點？
- 什麼叫做完成？要用什麼案例確認結果，而不是只看回答讀起來順不順？
這些問題合起來，才是「脈絡」的工程。名稱可以是 Context Engineering，也可以先不取名字；重要的是你開始管理模型做判斷時手上的材料。
本文的推論：模型能力不是唯一變數
當一個回答失敗時，我們很容易直接說「模型不夠聰明」。但如果它拿到三個互相矛盾的版本、六個沒有用途說明的工具，以及一串沒有整理的聊天紀錄，就算換一個模型，也不代表問題會自動消失。
這不是說模型不重要，而是把問題拆開後，才知道下一步要修哪裡。輸出錯在事實，可能要改善來源或檢索；輸出錯在格式，可能要補成功條件；工具選錯，可能要整理工具名稱與參數；長對話失焦，可能要壓縮歷史。全部歸咎於 Prompt，通常只會讓 Prompt 越來越像一份沒人敢刪的公司規章。
Prompt Engineering 與 Context Engineering 差在哪裡
Prompt Engineering 處理指令與輸出要求
Prompt Engineering 比較靠近「這一次要怎麼告訴模型要做什麼」。例如你交代角色、背景、限制、輸出格式、範例和評分條件。OpenAI 的Prompt Engineering 文件把提供相關 context、規劃 context window、使用 examples 等做法列在提示設計範圍內；Anthropic 的Prompt Engineering Overview則先要求使用者定義成功條件、建立可實證測試的方法，再開始改善 Prompt。
這個順序很重要。沒有成功條件時，你其實不知道 Prompt 改好沒有，只能用「這次讀起來比較像人」這種不穩定的感覺投票。
Context Engineering 管理整個輸入環境
Context Engineering 的範圍更廣，關心模型在推理當下看得到的所有重要資訊，以及這些資訊是怎麼被選出來、組織、更新和移除。Prompt 當然在裡面，但它只是其中一層。
可以先用這張表區分。表格中的「先做什麼」是本文建議，不是某個供應商宣布的唯一流程。
| 面向 | Prompt Engineering | Context Engineering |
|---|---|---|
| 主要問題 | 這次指令怎麼寫得清楚 | 這次推理應該讓模型看到什麼 |
| 管理對象 | 指令、範例、輸出格式 | 指令、資料、工具、歷史、記憶與環境 |
| 常見失敗 | 沒說清楚、格式不一致、範例不對 | 來源過期、資料太雜、工具重疊、歷史污染 |
| 適合的第一步 | 改寫任務與成功條件 | 盤點輸入來源並刪掉無關材料 |
| 驗收方式 | 同一題的輸出是否符合規格 | 不同回合、不同資料與失敗案例是否仍可重現 |
所以「Context Engineering 是 Prompt Engineering 的下一代」可以當成易懂的比喻，但不要把它寫成已經通用的正式分層標準。比較精準的說法是：它把原本只盯著提示文字的注意力，拉回到整個推理輸入環境。
不是每個聊天都需要工程化
如果你只是問一次旅遊交通、請 AI 改一段訊息，完整管理工具、記憶和檢索可能比任務本身還麻煩。Context Engineering 真正有價值的地方，通常是任務會重複、會跨多輪、會接資料或工具，而且錯誤需要被發現。
這也是為什麼 Anthropic 在Prompt Engineering Overview先要求釐清成功標準，並提醒不是每個失敗都應該靠 Prompt 解決。有時候換模型、縮小任務或重做資料流程才是比較直接的修正。
一個 AI 工作流程的 context 由什麼組成
以下六層不是每個產品都會以同樣名稱呈現，也不代表每一層都會被完整暴露給使用者。它們是用來盤點工作流程的實務框架。
1. 任務與成功條件
先說明要完成什麼，還要說明怎麼算完成。例如「整理十篇文章」太模糊；「列出每篇 URL、主題、已確認來源、未知欄位與下一步，找不到資料就保留未知」就比較能驗收。
成功條件要能被人或程式檢查。字數、欄位、來源、格式、禁止猜測的規則，都比「寫得專業一點」更容易變成可用的測試。
2. 指令與輸出規格
這就是大家最熟悉的 Prompt 層：角色、背景、步驟、格式、語氣、限制和範例。指令最好各自負責一件事，不要把背景資料、流程規則和這一次的臨時要求混在一大段文字中。
Anthropic 的工程文章建議讓 system prompt 清楚、直接，維持在既不過度硬編排、也不含糊的適當程度；同時也提醒「最小」不一定等於「最短」，而是剛好足以引導行為。這個提醒很實用：刪掉重複規則，不代表刪掉必要的條件。
3. 參考資料與檢索結果
如果任務需要公司規範、最新文件、資料庫內容或網站頁面，這些外部資料怎麼進入 context 會直接影響輸出。你可以一次把所有東西塞進去，也可以先保留索引，再在需要時取得相關片段。
後者常被稱為 just-in-time context：讓系統先帶著檔案路徑、查詢、網址或其他輕量識別資訊，在工作過程中再載入需要的內容。Anthropic 的工程文章用這個方向說明，代理不必一開始把整個資料庫塞進 context，而是透過工具逐步探索。
這不代表即時檢索一定比較好。即時載入通常會增加延遲，也要求工具和索引設計得夠清楚。固定不變的小型規範可以預先載入；變動很快、數量很大的資料，才有理由讓系統按需取用。
4. 工具與工具描述
工具不只是「多一個按鈕」。工具名稱、用途、參數、回傳格式和錯誤訊息，都是模型用來選擇行動的 context。如果兩個工具名稱很像，或一個工具一次做太多事，模型就比較難判斷該用哪一個。
Anthropic 在Building effective agents中把工具、檢索和記憶視為增強 LLM 的 building blocks，也提醒工具介面要清楚、容易理解，過度肥大的工具集合會增加模糊的決策點。這是官方文章的設計建議，不是所有框架都必須照抄的 API 規格。
5. 對話歷史與外部記憶
多輪對話會把前面的訊息、回答、工具結果和錯誤一起帶到後面。對讀者來說，它像一個越堆越高的工作桌：剛開始方便，久了之後想找一張重要便條，得先搬開一堆已經沒用的紙。
外部記憶可以是摘要、決策紀錄、待辦清單、資料庫或檔案。它的用途不是把所有歷史永久保存，而是讓下一次工作能快速恢復必要狀態。過期的記憶沒有比沒有記憶安全，因為它會用很有信心的口吻把舊規則帶回來。
6. 執行環境與權限邊界
同一段指令，在只有文字輸出的聊天裡，和在能讀檔、查資料、呼叫 API 或執行程式的 Agent 裡，風險完全不同。模型看得到的工具、可讀資料夾、可執行動作和人工審核點，都屬於工作流程的 context 與約束。
這裡要把「模型知道怎麼做」和「模型被允許做什麼」分開。後者是權限與治理問題，不是靠 Prompt 加一句「請小心」就能取代的安全控制。
為什麼 context 越多不一定越好
官方資料能確認什麼
Anthropic 的Context Windows 文件明確提醒，context window 是模型生成時可參考的工作記憶；隨著 token 增加，準確度與回憶能力可能下降，文件把這種現象稱為 context rot。文件也指出，系統提示、訊息、工具結果、圖片、文件和輸出都可能計入 context window，具體規則仍依模型與 API 而定。
這裡有兩個不能混在一起的結論：
- context window 變大，代表一次能處理的輸入上限可能變大。
- 輸入越多，不代表每個細節都會被同樣準確地取用。
所以不要把「可以放一百頁」直接翻譯成「一百頁都該放進去」。容量是上限，不是內容策略。
本文整理的四種雜訊
以下是依官方文件與工作流程推導出的常見設計風險，不是我對所有模型做完同條件基準測試後的排名：
- 過期雜訊：舊方案、舊欄位或已失效的規則仍留在專案資料中。
- 重複雜訊：同一條規則在 system prompt、專案說明、聊天歷史和工具說明重複出現。
- 衝突雜訊：兩份文件都像是最新版本，但對同一欄位有不同定義。
- 工具雜訊：可選工具很多，名稱和用途又沒有清楚邊界。
遇到這些問題時，我會先做 context inventory（輸入盤點），而不是立刻要求模型「更仔細」。先問它讀到了哪些來源、採用了哪個版本、哪些欄位缺資料，再決定要補資料還是刪資料。這樣才能分辨是模型失誤，還是我們把工作桌弄得太亂。
可維護的 Context Engineering，先做這 6 件事
1. 先寫成功條件，再改 Prompt
把「好的答案」改寫成驗收表。例如：
- 必須引用哪些來源？
- 哪些欄位找不到時要顯示未知？
- 輸出要給誰繼續使用？
- 哪些動作一定要人工核准？
- 哪一個錯誤案例最容易讓整個流程失真？
Anthropic 的 Prompt 文件要求先定義 success criteria 與可實證的測試；這比先蒐集一堆神奇 Prompt 範本更穩。若你還沒有驗收條件，先不要急著把 Prompt 寫成一頁長。
2. 把固定規則、任務資料和臨時輸入分層
一個簡單的分法是：
- 固定規則：品牌用語、輸出格式、安全與權限限制。
- 任務資料：這次要讀的文件、表格、網址或資料列。
- 臨時輸入：這一輪的問題、優先順序與截止條件。
- 驗收狀態：已確認、推論、未知、失敗與待人工決定。
分層後，更新資料不必重寫整份規則；換任務也不會把上一題的臨時背景當成永久記憶。這是本文建議的維護方式，不是產品介面一定會提供的資料夾結構。
3. 需要時才載入，不要一開始全部倒進去
對大型資料集，先提供索引、欄位說明、更新時間和取得方法，再按任務載入相關內容。這樣做的重點不只是省 token，也讓讀者知道輸出到底根據哪些材料。
不過 just-in-time 不是「讓 Agent 自己到處找」的同義詞。你仍然要限制搜尋範圍、記錄取得來源，並設計找不到資料時的停點。沒有邊界的自主探索，可能只是把不確定性從回答文字搬到工具呼叫。
4. 每個工具只處理清楚的責任
一個工具最好能用一句話說清楚：
- 它解決什麼問題？
- 什麼情況不該用它？
- 輸入必須有哪些欄位？
- 回傳結果的格式與錯誤狀態是什麼？
- 會不會修改外部資料？
若人類維護者也無法快速回答，模型更不可能穩定選對。先刪掉重複或很少使用的工具，通常比再增加一個「萬用工具」更容易讓系統變可靠。
5. 為長任務準備摘要與恢復點
長任務不可能把每一段原始歷史都永遠保留在工作記憶裡。Anthropic 的工程文章提出 compaction、structured note-taking 和 multi-agent architectures 等處理長時程任務的方向。對一般團隊來說，不一定要一次實作所有架構，可以先做一個可讀的進度檔：
- 目標與成功條件
- 已確認的決策
- 尚未解決的問題
- 已讀過的來源與版本
- 下一步與停止條件
摘要不是刪除歷史後假裝沒發生過，而是把後續真正需要的狀態留下來。壓縮太用力，也可能把例外和未解決風險一起刪掉，所以恢復後要跑一次驗收案例。
6. 把失敗案例納入測試
不要只準備「正常資料」。至少加一個空欄位、一個過期版本、一個互相矛盾的來源，或一個需要人工核准的動作，觀察系統會怎麼處理。
你要測的不是模型永遠不犯錯，而是錯誤能不能被看見、能不能停下來、能不能保留原始資料，以及下一輪能不能知道前一次發生了什麼。這種測試比拿一題漂亮的 demo 宣布成功更接近真實工作。
用內容稽核案例走一次實作流程
以下是假設情境，不是作者已經完成的客戶專案或性能測試。假設你每週要檢查十篇文章，輸出來源、更新狀態、缺口和下一步。
第一步：把任務變成可驗收的輸出
不要只寫「請找出文章問題」。先規定每篇輸出：
| 欄位 | 內容 |
|---|---|
| URL | 實際檢查的頁面 |
| 已確認 | 能回到來源或頁面驗證的事實 |
| 推論 | 依已確認資料提出的判斷 |
| 未知 | 沒有讀到、無法驗證或需要登入的部分 |
| 下一步 | 更新、補來源、保留或交給人工決定 |
這個格式本身就是 context 的一部分。它讓模型知道你不是要一段「看起來完整」的評論，而是一份能交接的檢查結果。
第二步：固定規則，分開放入本次資料
固定規則可以包括：不要把未觀察到寫成零、變動資料附查證日期、來源不足就保留未知、不要直接發布。這些內容不必每次和十篇文章全文混在一起。
本次資料則放要檢查的 URL、文章版本、抓取時間和需要回答的問題。如果是網站稽核，先帶 sitemap 或 URL 清單，再逐頁取得內容；不要在第一輪就把整個網站所有 HTML、圖片 metadata 和歷史 log 全部貼進對話。
第三步：按需取得資料並保留來源
模型可以先讀頁面標題、更新日期和主題，再決定是否需要載入完整正文。每次取得資料時，保留 URL、時間和回應狀態。某個頁面被擋、需要登入或回傳不完整，就標成未知，不要為了讓表格好看而猜。
這裡的 Context Engineering 不是把檢索系統包裝成智慧魔法，而是把「取得什麼」和「根據什麼做判斷」留下來。讀者才能知道哪一個結論需要再次查證。
第四步：用故意的錯誤資料驗收
放入一篇缺少更新日期的文章、一個失效連結和一個內容已改但 sitemap 尚未同步的假設案例，觀察輸出是否：
- 把失效連結列成問題，而不是默認頁面不存在。
- 把缺日期保留為未知，而不是自行補今天。
- 分開描述頁面內容與 sitemap 狀態。
- 在資料互相矛盾時停下來，提出需要人工決定的選項。
若模型每次都把未知填滿，先修成功條件與輸出格式；若它拿錯來源，先修索引、檢索或版本標記；若它不會停，先加人工核准點。不要所有問題都回到「Prompt 再寫清楚一點」。
第五步：留下下一輪真的需要的筆記
任務結束後，保留已確認的規則、尚未解決的 URL、來源日期、人工決定和下一次入口。把整段對話原封不動存下來，未必是好的記憶設計；下一輪真正需要的是狀態，不是所有聊天口水。
Context Engineering、RAG、MCP 與 Agent 的關係
這幾個詞很容易在文章裡排成一串，讀者卻不知道它們到底是不是同一件事。先把它們放回不同層次：
| 名詞 | 它主要處理什麼 | 和 context 的關係 |
|---|---|---|
| Prompt Engineering | 指令、範例與輸出要求 | 是 context 設計的一部分 |
| RAG | 從外部資料取得相關內容再提供給模型 | 是補充 context 的一種方法 |
| MCP | 讓 AI 應用程式連接外部資料、工具與工作流程的開放標準 | 是工具與資料連接的協定，不等於完整 context 策略 |
| Workflow | 以預先定義的程式路徑編排模型與工具 | 可以固定 context 如何流動 |
| Agent | 讓模型動態決定流程與工具使用 | 需要更嚴謹地管理工具、歷史、狀態與權限 |
| Context Engineering | 設計與維護模型在每一輪可用的資訊環境 | 是本文討論的整體方法問題 |
RAG 是其中一條資料路徑
OpenAI 的Prompt Engineering 文件把加入外部相關 context 說明為常見做法，並以 RAG 作為從向量資料庫或 file search 取得資料的例子。這表示 RAG 可以幫你把資料放進 context，但它不會自動替你決定哪個版本可信、來源是否過期、輸出要怎麼驗收。
如果檢索到的是錯的文件，RAG 只會更有效率地把錯誤材料送進模型。資料版本、權限、切片、排序和引用仍是整體流程的一部分。
MCP 是連接標準，不是品質保證
MCP 官方介紹將 MCP 定義為連接 AI 應用程式與外部系統的開放標準，讓應用程式可以連接資料來源、工具和工作流程。這能處理「怎麼接上」的問題，但不會單獨回答「什麼時候該接」「要回傳多少資料」「哪些動作需要核准」。
所以 MCP 讓 context 的來源更容易被接進來，卻沒有替你完成 context 的取捨。接得越多，越需要知道每個連線提供什麼、誰能使用，以及失敗時怎麼停止。
Agent 不一定比 Workflow 更進階
Anthropic 在Building effective agents中區分 workflow 與 agent：前者沿著預先定義的程式路徑執行，後者由模型動態決定流程與工具使用；同一篇也建議先用最簡單能解決問題的方法，只有在需要彈性時再增加 Agent 的自主性。
這個建議值得保留。若你的任務可以拆成固定的「讀取、整理、檢查、輸出」，先做 workflow 反而容易測試。Agent 的自由度增加後，工具、歷史、權限與停止條件都會一起變成新的 context 管理工作。
怎麼知道該重做 context，而不是繼續改句子
遇到以下現象時，我會先停下來做輸入盤點：
| 現象 | 先檢查什麼 | 可以驗收的修正 |
|---|---|---|
| 反覆提醒同一條規則仍會漏掉 | 規則是否分散、互相矛盾或埋在歷史中 | 把固定規則集中，加入一個違規測試案例 |
| 回答引用舊版本 | 來源日期、版本欄位與檢索排序 | 要求輸出來源版本與查證日期 |
| 工具常常選錯 | 工具名稱、描述、參數與責任是否重疊 | 刪除重複工具，測試一組相似任務 |
| 長對話前後標準不一致 | 歷史是否過長，摘要是否保留決策和未知 | 建立恢復筆記，從摘要重開一輪 |
| 回答越完整，錯誤越難看出來 | 輸出是否把事實、推論和未知混在一起 | 改成分欄輸出，保留來源與不確定狀態 |
| 每次改一點，結果都不可重現 | 是否有固定輸入、版本和評估案例 | 固定一組小型 eval set，再比較變更 |
這些並不是一個「Context Engineering 健康分數」。它們只是把模糊的不滿拆成可以檢查的假設。沒有同一份資料、同一個模型版本和同一組測試，就不要把結果寫成準確率或性能排名。
不同情境該先做哪一步
只是想讓日常對話少返工
先把任務、背景、輸出格式和「不知道時怎麼回答」寫在同一則訊息裡；資料超過需要時，就開新對話或先做短摘要。你不必先研究 Agent 架構。
如果你想回頭整理 Prompt，可以先看 NICROW 的ChatGPT Prompt 教學：寫出可驗收的工作指令。那篇文章提供的是歷史上的 Prompt 工作脈絡；本文補上的，是當任務開始跨資料、工具與長期狀態時，還要管理哪些東西。兩者不是同一篇文章的重複版本。
如果你還在比較不同工具的工作形狀，可以延伸讀Claude 與 ChatGPT 比較：研究、寫作、資料分析怎麼選？。那篇處理的是工具選擇；本文處理的是不論選哪個工具，都要怎麼整理它看到的資訊。
需要固定產出內容或報告
先建立來源清單、版本欄位、輸出範本和人工檢查點。每一次產出保留查證日期與未知，不要讓模型用順暢語氣遮住缺資料。
這時可以把工作流程拆成「取得資料、整理、草稿、驗收」幾段，每段只交付下一段需要的資訊。這個拆法和既有的工作自動化框架文章能互相參照：工具是否能串起來只是開始，目標、失敗處理和結果檢查才決定它值不值得維護。
正在建立 AI Agent 或工具流程
先盤點工具與權限，再決定是否需要讓模型自由規劃。為每個工具寫清楚用途、輸入、輸出、錯誤狀態與是否修改外部資料；為長任務準備摘要、恢復點和人工核准。
如果固定 workflow 已經能完成需求，不必為了「看起來更智慧」改成 Agent。多一點自主性也代表多一些可能的路徑、成本和失敗點，這些都要放進測試範圍。
FAQ：Context Engineering 常見問題
Context Engineering 是不是只是更進階的 Prompt Engineering？
不完全是。Prompt Engineering 主要處理指令、範例與輸出要求；Context Engineering 把範圍擴大到模型在推理時可以取得的資料、工具、對話歷史、記憶與環境。Prompt 是其中一層，不是全部。
沒有寫程式，也需要懂 Context Engineering 嗎？
需要懂它的基本判斷，但不代表你要立刻寫檢索系統。只要你會重複使用同一份背景資料、累積長對話或要求 AI 按格式交付，就可以先用來源清單、版本、成功條件與未知欄位改善流程。
Context window 越大，是不是就不用整理資料？
不是。官方文件把 context window 視為可參考的工作記憶，也提醒隨 token 增加，準確度與回憶能力可能下降。更大的上限解決的是容量問題，不會自動解決過期、重複、衝突或無關資料。
RAG 和 Context Engineering 是同一件事嗎？
不是。RAG 是從外部資料取得內容、補進模型 context 的一種方法；Context Engineering 還要處理資料選擇、版本、排序、工具、歷史、記憶和驗收。RAG 可以是其中一個元件，但不等於完整策略。
MCP 等於 Context Engineering 嗎？
不是。MCP 是連接 AI 應用程式與外部資料、工具、工作流程的開放標準。它能讓 context 有更多來源，但不會替你決定要不要使用某個來源、要載入多少資料，或哪個動作需要人工核准。
我應該先做 Workflow 還是 Agent？
如果任務可以用固定步驟完成，先做 Workflow 通常比較容易測試與除錯；只有當步驟數量或選擇會隨輸入變化，才有理由評估 Agent。這是依可驗收性與維護負擔提出的本文建議，不是所有團隊都適用的硬規則。
結語：先管理模型看到什麼，再追求模型做更多事
Context Engineering 最值得留下的不是一個新名詞，而是一個工作習慣：回答失敗時，先確認模型在那一輪真正看到了什麼。任務是否清楚、資料是否正確、工具是否過多、歷史是否過期、成功條件是否能驗收，通常比再加一段華麗 Prompt 更接近問題本身。
你可以先從一個小流程開始：選一份會重複處理的材料，列出成功條件與未知狀態，固定來源和輸出格式，再用一個過期或矛盾案例測試。結果若還不穩，再決定是要改 Prompt、做檢索、整理工具、加入摘要，或乾脆把 Agent 改回固定 Workflow。
工具可以晚一點增加，context 的邊界要先畫出來。否則最後得到的可能不是更聰明的工作流程，只是一張堆滿卡片、但沒人知道哪張有效的桌子。
參考來源
- Anthropic：Effective context engineering for AI agents，查閱日期：2026-09-08。
- Anthropic：Prompt engineering overview，查閱日期：2026-09-08。
- Anthropic：Building effective agents，查閱日期：2026-09-08。
- Anthropic Claude Platform Docs：Context windows，查閱日期：2026-09-08。
- OpenAI API Docs：Prompt engineering，查閱日期：2026-09-08。
- Model Context Protocol：What is MCP?，查閱日期：2026-09-08。
