Harness Engineering｜AI Agent 從提示詞工程、上下文工程演進的新顯學
kyle

同樣是「請 LLM 幫我寫一段程式」，2023 年的開發者在糾結提示詞要怎麼下、要不要加 few-shot；2024 年改成糾結要塞哪些檔案進 context、怎麼寫 RAG；到了 2026 年，焦點變成 agent 的工具要怎麼設計、loop 該怎麼停、要不要先問人。三個時期看似都在解同一個問題，背後的工程語彙卻換了三次：

  • 提示詞工程（Prompt Engineering）
  • 上下文工程（Context Engineering）
  • 駕馭工程（Harness Engineering）

名詞推陳出新的速度，常讓人焦慮「昨天學的今天就過時」。但仔細看會發現，舊名詞並沒有被丟掉，只是從「需要特別研究」變成「產品內建的能力」。這篇文章想做兩件事：把三個工程的脈絡講清楚，再說明為什麼過去學的每一層知識都沒有浪費。

註：Harness Engineering 目前沒有很一致的翻譯，原意為駕馭馬匹用的「馬具」，本文翻譯為駕馭工程。

提示詞工程：把單次對話榨到極限

提示詞工程（Prompt Engineering）大約在 2022 到 2023 年間爆發，那是 ChatGPT 跟 GPT-3.5 剛震撼世界的時期。當時的模型已經很聰明，但介面非常單純——一個輸入框、一段回應，沒有工具、沒有記憶、沒有檔案。模型表現好不好，幾乎完全取決於我們怎麼把問題講清楚。

於是社群開始累積一整套「對 LLM 說話的技藝」：

  • Few-shot：在 prompt 裡丟幾個範例，讓模型照樣造句
  • Chain-of-Thought（CoT）：請模型「一步一步想」，數學跟邏輯題正確率大幅提升
  • Role-play：「你是一位資深 Linux 工程師」這類角色設定，讓回答更專業
  • 結構化輸出：要求 JSON、Markdown、表格，讓下游程式可以解析
  • ReAct：把「思考」與「行動」交錯，是後來 agent loop 的雛形

這個階段最大的貢獻，是把「跟 AI 對話」從玄學變成可複製的技藝。同樣一個問題，會寫提示詞跟不會寫的人，產出品質差距可以是十倍。

但隨著 Claude 3.5、GPT-4o、Claude 4 等新一代模型出現，指令跟隨能力越來越強，過去要靠技巧才能擠出來的輸出，現在用白話講就可以。提示詞工程開始淡出主流話題——不是因為它沒用了，而是因為大部分人不需要再特別研究。

上下文工程：把對的資料送到模型眼前

2023 到 2025 年，問題從「怎麼問」變成「給模型看什麼」。再會寫提示詞，模型沒看過我們公司的內部文件、沒讀過今天剛上的程式碼，就是答不出來。上下文工程（Context Engineering）就是在處理這件事。

它要解決的問題大致有三層：

  • 找到對的資料：從幾萬份文件裡，挑出這一輪對話真正需要的那幾段
  • 安排資訊密度：context window 有限，重要的放前面、不重要的壓縮或丟掉
  • 跨回合記憶：讓 agent 記得上一輪聊過什麼、上週做過什麼決定

對應的技術也百花齊放：RAG（Retrieval-Augmented Generation）、embedding + vector search、reranker、prompt cache、sliding window、summarization memory，到後來的 MCP（Model Context Protocol） 把外部工具的輸出統一成 context 來源。這個階段把 LLM 應用從「聊天機器人」推進到「能查資料、能串系統」的助手。

而現在，上下文工程也開始往「基礎設施」的方向移動。Gemini、Claude 都端出 1M token 的 context window，prompt cache 變成 SDK 預設功能，MCP 成為跨家共用的協議，市面上 RAG 框架多到挑不完。對大部分應用開發者來說，已經不需要從零造輪子，會用就夠了。

駕馭工程：讓 agent 自己幹活又不失控

當模型夠聰明、context 夠大之後，新的瓶頸出現了：怎麼讓 agent 在一個迴圈裡自己決定下一步、自己呼叫工具、自己處理錯誤，而且不會把使用者的檔案或資料庫弄壞。這就是駕馭工程（Harness Engineering）登場的舞台。

Harness 直譯是「馬具」，在 AI 領域指的是把 LLM 包起來那一層骨架——它定義了模型可以呼叫哪些工具、loop 怎麼跑、什麼時候要停下來問人、出錯了怎麼回滾。Claude Code 、Cursor agent、SWE-agent、OpenAI Agents SDK 等產品，本質上都是不同風格的 harness。

駕馭工程要解決的問題，比前兩個階段更貼近「真實世界的副作用」：

  • 工具設計：粒度要粗還是細？一個 edit_file 大工具，還是拆成 read、insert、replace？哪些工具會改變狀態（side-effect）？
  • Loop 控制：模型卡住時要不要強制停？要不要設預算上限？什麼情況自動往下走、什麼情況要回頭問人
  • 安全與權限：哪些指令可以直接跑、哪些一定要使用者按 yes，這背後是一整套判斷規則，可參考 Claude Code 終端機指令安全判斷教學
  • 多 agent 協作：把大任務拆給多個子 agent 並行處理，再收回成果，可參考 Claude Code Agent Teams 教學

在這個階段，我們做 AI 應用，重心不再是「寫一個更厲害的 prompt」，而是「設計一個更穩的 harness」。Prompt 跟 context 都還在，但它們現在是 harness 的內建零件，而不是工程師日常糾結的主戰場。想看真實 harness 長什麼樣，可以參考 Claude Code 原始碼意外洩漏 那篇的拆解。

舊名詞淡出 ≠ 退流行，是成熟地融入了產品

講到這裡，可能會有開發者開始焦慮：是不是要趕快丟掉提示詞工程的書、把 RAG 框架全部砍掉、All-in 駕馭工程？

不用。這三個名詞不是接力賽，而是疊樓房。每一層都還在，只是位置變了：

  • 提示詞工程沒消失——好的 prompt 結構被吃進 SDK 預設、system prompt 模板、RLHF 訓練資料裡。我們今天對模型下指令，仍然在用 CoT 跟 few-shot 的精神，只是不再需要喊出名字
  • 上下文工程沒消失——它變成 MCP、prompt cache、長 context window、RAG 框架的內建行為。會 context 設計的人，在規劃 agent 系統時仍然有壓倒性優勢
  • 駕馭工程目前在最前沿——但兩三年後也會「淡出」，被 SDK、平台、標準協議吸收進去，下一個新名詞會在它上面繼續長

這個現象在軟體圈一點都不陌生。HTTPS 從研究主題變成瀏覽器預設、容器化從熱門話題變成 CI 基礎建設、React Hooks 從新概念變成寫法標配。成熟的技術不會喧嘩，它只是慢慢變成空氣——大家每天用，但不會特別討論。

所以給開發者的定心丸是這樣的：

  • 昨天學的提示詞技巧，今天還在用，只是不再掛牌
  • 今天學的 context engineering，明年會讓我們在設計 harness 時更有直覺
  • 現在學的 harness 設計，未來會變成下一代 agent 平台的選型直覺

知識不會貶值，只是會換位置繼續發揮作用。反過來說，如果想跳過基礎、直接做最新的，往往很快會踩坑——harness 跑不順，多半不是 harness 本身的問題，而是底下的 context 或 prompt 沒處理好。

小結：名詞在變，工程精神沒變

回到開頭那個場景：2023、2024、2026 年的開發者，看似在解不同的問題，本質上都在做同一件事——把不確定的東西變成可複製的工程。提示詞工程在馴服「自然語言的歧義」、上下文工程在馴服「資料的雜亂」、駕馭工程在馴服「自主決策的失控風險」。每個時代的名詞不同，但精神一以貫之。

對開發者來說，與其追新名詞，不如先誠實面對自己的系統卡在哪一層。如果模型輸出格式跑掉，那是 prompt 的問題；如果模型答不出公司內部知識，那是 context 的問題；如果 agent 跑兩步就卡住或闖禍，那是 harness 的問題。對症下藥，比追潮流更重要。

延伸閱讀

Post Views: 22
Tags:

發佈留言