六種工程,何時用哪一種

我們先誠實一點。這六個詞為什麼讓人混?因為每篇文章都想把它們排成一條直線,從 prompt 一路排到 graph,好像後面的比前面的高級。結果各家排的順序還不一樣,有人說 harness 最外層,有人說 loop 最新,你看了三篇,更亂。我今天要先把這個錯誤觀念拆掉:它們根本不在同一條線上。看懂這件事,這六個詞就再也不會混。

先給你今天的結論,後面全部圍著它轉。這六個詞分屬三件事。第一把尺量「範圍多大」:從一句話,到一整個 Agent 團隊。第二把尺量「步驟是誰決定的」:是人事先排死,還是 AI 臨場自己決定。這兩把尺互相獨立。最後,下面永遠有一塊地板,叫 harness,就是「跑這一切的工具跟環境」。記住這兩把尺加一塊地板,剩下的都是細節。

從最小的開始。我們的任務是:整理一批雜亂的客戶名單。prompt engineering,就是你怎麼「開口交辦」這一句話。你如果只說「幫我整理一下這份名單」,它會給你一個它猜的整理法,八成不是你要的。但你如果說「把重複的合併、公司欄位空的補上、最後照公司名 A 到 Z 排序」,同一個模型,產出就完全不同。這是最基本、CP 值也最高的一段:大部分「AI 做不好」,其實是你話沒講清楚。

接著是 context engineering。它管的不是那句話,而是「AI 手邊看得到的所有資訊」。同樣整理名單,你可以多給它三樣東西:一,欄位規格,告訴它每一欄該長什麼樣;二,兩三筆已經整理好的範例,讓它照著做;三,一份忌口清單,比如「台積電跟 TSMC 要當成同一家公司」。你給的脈絡越齊,它越不用猜。很多人以為問題出在模型笨,其實是你沒把它該看的資訊擺到它面前。

再往上一層,loop engineering。這裡你不再一步步盯著它,而是讓它自己跑一個循環:做一版、檢查、發現問題、修、再檢查。但這裡有一個最容易被忽略的重點:你必須給它一個「可驗證的完成標準」。不是「整理到好」,而是「每一筆都要有公司名、而且完全沒有重複,做到這樣才算完成」。有了這把能跑出對或錯的尺,它才知道什麼時候該停。這件事我自己吃過虧:早期我沒給明確的完成標準,它就一直改、一直改,改到我受不了喊停。你的職責,其實不是描述『感覺對不對』,是給它一個能跑出『對或錯』的目標。等一下我直接讓一個 Agent 真的跑一次給你看。

但如果這個整理名單的流程,你「每個月都要做一次」,而且步驟固定不變呢?那你就不該每次都讓 AI 臨場發揮。這時候用 workflow engineering:把步驟事先排死——第一步去重、第二步補公司欄、第三步套用信件範本寄出去。誰來跑、跑幾次,結果都一樣。它的好處是穩定、可重複、又便宜,壞處是不會隨機應變。這就帶到今天最重要的一個判斷。

loop 跟 workflow,是今天第二把尺的兩端,很多人在這裡選錯。判斷方法只有一句話:這件事的步驟,我事先列得出來嗎?如果列得出來、每次都一樣,就用 workflow 排死,穩又省。如果列不出來——因為每次狀況不同、要邊做邊看——那才交給 loop,讓 AI 臨場決定下一步。這裡也順帶破解一個迷思:固定步驟的流程,其實是「狀態機」,不是真正的 Agent。Agent 的靈魂,是它自己決定步驟、自己知道何時停。

第三把——不對,harness 不是尺,它是那塊地板。harness engineering 管的是「跑這一切的環境」:AI 有沒有工具可以真的打開你的檔案、有沒有權限寄信、出錯的時候怎麼接住、明天能不能自動再跑一次。你上面用 prompt 還是用 loop,都得先站在這塊地板上。你其實天天在用的 Claude Code 這種工具,本身就是別人幫你蓋好的一間 harness。當你開始在意「這個流程能不能可靠地、重複地自動跑」,你就已經在做 harness 工程了。

最後,graph engineering,也是最新的一個。當任務大到一個 Agent 扛不動——比如你要一次處理十萬筆、還要有人審核、有人寄信——你就把很多個 loop 接成一張分工圖:一個負責接單、一個去重、一個寫信、一個把關。這就是 graph:多個 Agent 的分工與動線。但我要給你一個很實在、我自己踩過的警告。我最早做多 Agent 的時候,先定義了一組固定角色的團隊,想說分工很漂亮,結果它們互相回報錯誤、我跟著改,改了整整一天都沒收斂。事後才想通:我從頭到尾沒給它們一條「做到哪裡算完成」的停止線,它們就只能互相製造工作。所以記住——graph 不是取代 loop,一個 loop 只是圖裡的一個節點。能一個人做完,就別急著開整間餐廳。

而且別以為多 Agent 一定比較強,有幾個很殘酷的數據你該知道。第一,錯誤會沿著鏈路放大:三個各自九成準的 Agent 串在一起,整體只剩七成三,亂接的話甚至放大十幾倍。第二,史丹佛二零二六年的研究發現,在一樣的思考預算下,單一 Agent 在多步推理上常常贏過多 Agent——很多「多 Agent 比較強」的說法,其實只是花了更多錢在算,不是架構真的比較好。第三,業界掃過一千六百個失敗案例,多 Agent 系統的失敗率高達四成到八成七,而且多數是結構設計的問題,不是模型不夠聰明。所以 graph 不是你的預設選項,是你確定單一 loop 真的撐不住了,才動用的最後手段。

我們把六個詞收進一張表。範圍這把尺,從小到大是:prompt、context、loop、graph——一句話、一份備料、一個 Agent 自己跑、一整個團隊。決定步驟這把尺,兩端是 workflow 跟 loop:人排死,還是 AI 臨場。而 harness,不在任何一把尺上,它是一路都在的地板。你看,六個詞其實只對應三個問題,一點都不玄。

那給正在往工程走的你,一個實際的下手順序。第一,先把 prompt 跟 context 練到熟,這是投報率最高的一段,九成問題在這裡就解決。第二,遇到要自動化的流程,先問步驟列不列得出來:列得出來用 workflow,列不出來才用 loop。第三,確定一個 Agent 真的撐不住了,才上 graph,別為了多 Agent 而多 Agent。而 harness,是你一開始在意「可靠、可重複」時就一路都在的底層。

這集帶走一句話:別去背這六個詞的順序,名詞每隔幾個月就會換一批,你背不完。你只要記住兩把尺——一把量「範圍多大」,從一句話到一整個團隊;一把量「步驟是誰決定的」,人排死還是 AI 臨場。再記得下面永遠有一塊叫 harness 的地板。有了這兩把尺,不管明年又冒出什麼新的 X engineering,你都放得進去、分得清楚。我們下次見。