先從意義說起：這三個詞，其實代表 AI 工程重心的三次移動
生成式 AI 剛普及時，大家最熟悉的是「提示詞工程」。那時候的核心問題很直接：怎麼把一句話講得更清楚，讓模型比較聽話。接著，業界逐漸發現，真正影響品質的，往往不只是那一句 prompt，而是模型在每一輪推理時，到底拿到了哪些資訊、哪些工具、哪些記憶與哪些限制，於是「上下文工程」開始變成更關鍵的能力。到了代理式 AI 與 coding agent 進入真實工作流後，問題又再往外擴一層：不只是 prompt 與 context，還包含工具路由、重試、驗證、回饋迴路、架構約束、文件治理與自動化檢查，這時「Harness」才開始成為新焦點。
換句話說，三個詞並不是彼此取代，而是工程控制範圍一路往外擴張：從一句話，擴到一整包上下文，再擴到整個代理執行環境。
什麼是提示詞工程（Prompt Engineering）？
根據 OpenAI 文件，prompt engineering 指的是設計與優化輸入提示，讓模型更穩定地產出符合需求的內容。它的核心是「如何下指令」：任務要不要拆步驟、輸出格式要不要限定、角色設定要不要明確、範例要不要先給、限制條件要不要先講清楚。
提示詞工程最適合處理的，是單輪或短流程任務，例如摘要、改寫、分類、翻譯、表格整理、文案生成、基本推理等。它像是在教一位很聰明但不熟悉你工作背景的同事：你說得越明白、越具體、越有格式，回覆通常越穩。
但它的天花板也很明顯。當任務牽涉長對話、歷史記憶、多工具切換、外部資料查詢、工作流狀態管理時，只靠 prompt 本身，通常撐不住。
什麼是上下文工程（Context Engineering）？
LangChain 將 context engineering 定義為：建立動態系統，在正確時間，以正確格式，把正確資訊與工具提供給 AI 應用，使其能完成任務。這個定義很重要，因為它把焦點從「寫一句好 prompt」移到「怎麼組裝整個輸入現場」。
因此，上下文工程不只是聊天紀錄長不長，也不只是 context window 大不大。它真正關心的是：這一輪該送哪些文件？該暴露哪些工具？哪些歷史訊息該保留、哪些該摘要？哪些是使用者偏好、哪些是系統狀態、哪些是工具觀測值、哪些是長期記憶？
在 agent 場景裡，上下文工程通常包含幾件事：檢索外部知識、裁剪或摘要對話、注入結構化狀態、選擇可用工具、限制輸出 schema、把錯誤訊息重新整理後再餵回模型。它處理的是「模型在這一刻到底看到了什麼」。
什麼是 Harness？
「Harness」其實有兩層語境。較早期的用法，是評測領域裡的 evaluation harness。像 EleutherAI 的 Language Model Evaluation Harness，指的是一套統一框架，用來在多種 benchmark 上測試不同語言模型。這個意思偏向「評測夾具」或「測試框架」。
但在 2026 年代理式 AI 的討論裡，Harness 的意思明顯變寬了。OpenAI 在介紹 Codex App Server 時，直接把 Codex harness 描述為支撐各種 Codex 體驗背後的 agent loop 與 logic；而在談 harness engineering 時，重點更放在設計環境、建立回饋迴路、加入工具、文件、守欄、驗證與控制系統，讓 agent 能更可靠地工作。
所以放到今天的實務語境裡，Harness 可以理解成：包在模型外面的整個執行與治理層。它不只決定模型能做什麼，還決定模型出錯時會怎麼被攔下、被修正、被重試、被檢查，甚至被重新教育。
三種工程的差異，到底差在哪？
面向提示詞工程上下文工程Harness核心問題怎麼把指令講清楚這一輪該給模型哪些資訊與工具整個代理系統怎麼穩定運作控制範圍單次輸入單輪到多輪的動態輸入組裝模型外圍的執行、驗證、回饋與治理主要手段角色、格式、範例、步驟、限制檢索、摘要、記憶、工具暴露、狀態注入工作流、工具路由、重試、lint、tests、guardrails、監控最常見失敗點指令模糊、格式漂移、漏條件上下文選錯、太多、太少、太亂流程失控、重複執行、錯誤未攔截、品質不可驗證適用場景單點任務、短鏈任務RAG、agent、多工具任務生產級代理系統、長流程、自動化開發與運維
一句話總結：提示詞工程在調「說法」，上下文工程在調「餵法」，Harness 在調「整個跑法」。
為什麼業界重心正在往 Context 與 Harness 移動？
因為模型失敗時，原因常常不是它不夠聰明，而是它拿到的東西不對，或所處的環境不受控。LangChain 在 agent 文件裡就直接點出，代理失敗常見原因只有兩個：一是模型本身能力不足，二是沒有把「正確上下文」傳進去，而更多時候真正的問題其實是第二個。
OpenAI 談 harness engineering 時，也不是把重點放在「再寫一個更神的 prompt」，而是放在知識如何組織在 repo 裡、AGENTS.md 如何變成入口索引、規則如何用 linter 與 CI 機械化執行、回饋如何回寫成文件、工具與守欄如何讓 agent 在高吞吐情境下仍可控。這代表工程重心已經從「文字技巧」轉到「系統設計」。
那提示詞工程會消失嗎？
不會，但它的地位會下降。未來 prompt 仍然重要，只是它更像基本功，而不是勝負手。真正拉開差距的，會是誰更會整理知識、設計記憶、配置工具、建立檢查點、安排重試、壓縮上下文、定義結構化輸出，並把這些能力做成可持續運行的系統。
也可以這樣理解：prompt engineering 像寫一段好開場白；context engineering 像替模型準備好完整會議資料；Harness 則像替整個團隊建立 SOP、監控、品管與回報機制。
結尾：當上下文長度持續暴漲，這些工程會不會只是過渡期技巧？
這個問題值得誠實回答：從某個角度看，確實是。Google 官方長上下文文件提到，100 萬 token 在實務上大約相當於 8 本平均長度的英文小說；Gemini 2.5 Pro 官方規格頁列出的最大輸入 token 為 1,048,576；Anthropic 文件則寫明 Claude Sonnet 4 支援 100 萬 token context window，目前屬 beta；OpenAI 的 GPT-5.1 官方模型頁也已提供 400,000 token context window。這表示模型的工作記憶上限，確實正在快速突破。
因此，如果只是從「把更多資訊硬塞進模型，讓它暫時更像懂你」這個角度來看，提示詞工程、上下文工程，甚至部分 Harness 技巧，確實帶有過渡時期取巧的味道。當模型能直接吞下近似小說規模、整份 codebase 規模、長期對話規模的內容後，很多今天用來裁剪、拼裝、壓縮、分段的技巧，未來都可能被更大上下文直接吃掉。
但另一半事實也同樣重要：就算上下文再大，成本、延遲、可靠性、驗證、責任邊界、權限控制與系統治理都不會自動消失。所以更精準的說法是，這些工程裡有一部分會被大 context 吃掉，另一部分則會演化成 AI 時代的新型軟體工程。
我的判斷是：提示詞工程、上下文工程、Harness 工程，今天看起來像三門新學問；再過幾年回頭看，其中相當一部分，會被證明只是大模型能力尚未完全展開前的臨時補丁與聰明繞路。它們不是沒有價值，但很可能都只是過渡時期的取巧辦法。
