Loop engineering:別再 prompt agent,設計會 prompt agent 的迴圈

Prompt 寫得再好,有一件事沒變:你還是那個反覆下 prompt 的人。AI 給你一版,你看完給回饋,它再給一版——這條迭代曲線是你親手在爬。

Loop engineering 的一句話定義:把「prompt agent 的那個人」從你自己換成一套系統。你不再一次次下指令,而是設計一個會替你下指令的迴圈。一個 loop 就三件事:觸發(trigger)、動作(action)、停止條件(stop condition)。這是抽象層級的上移——不是「我更會寫 prompt」,而是「我描述目標和完成標準,讓系統自己跑迭代」。

建 loop 前先答兩問

一個 loop 的上限,就是它的 done-check。動手前先答兩個問題:

一、done 是什麼? 盡量客觀。最好的停止條件是「迭代到某個指標等於某個值」這種可量測的;「跑到你滿意為止」是退而求其次的弱版——主觀打分會把本質不同的結果混為一談。做蛋糕的 done 是叉子插下去不沾麵糊;把你的 done 講到那麼具體可驗,loop 才不會空轉或提早收工。

二、它怎麼 check? 驗證手段要對得上做的東西:做遊戲要實際把關卡玩過,寫文案要查流程和語氣。你的工作是確保 agent 手上有做這些 check 的對的工具。這跟我一貫的 harness 判準同一件事——把限制寫進 code、做客觀可驗證的 gate,別讓做事的 agent 自己宣告做完。

答不出這兩問就先別建。loop 不會把爛驗證變好,只會把空轉自動化。

建 loop 的理由是驗證,不是 agent 艦隊

多數任務根本不需要 loop;會去包一個 loop,理由幾乎只有一個——驗證。而拿到驗證迴圈,不必先蓋一套多 agent 架構。形態由輕到重:一個 agent 自己跑到底(最常用)、一個做一個打分、一個管理者帶一群子 agent。選最輕能成事的那個。

看到別人擺一排 agent 全天候互相調度,不代表你不那樣就落後。真正搬動指針的是驗證與迭代,不是 agent 數量;不懂自己在做什麼就上艦隊,只是把 bug 一起放大。

值得外包的是那條迭代曲線本身:品質從六成爬到九成的來回,反正得有人走完——與其你親手給回饋,不如讓 agent 自己觀察、自己修,第一次交到你手上就離終點近得多。你省下的不是品質,是來回那幾輪。

時長對齊價值,別炫技

Loop 跑到 done 為止,所以硬目標加上驗不動的 done 可能永遠收不了口——空轉半天一夜也不稀奇,而那種 run 多半沒用。兩個對策:給迭代次數一個硬上限當保險;把 loop 的時長對齊它能換回的價值。甜蜜點不是連跑好幾天的炫技 run,而是睡前丟一個扎實的任務、過夜跑完,早上拿到一份成果,由人接手。

也不是所有事都該進 loop:對齊和規劃必須有人在場,實作可以放手;品味要靠人壓回去,全自動化只會產出沒人想要的量產品。我自己的用法是投遞 pipeline 那種帶人工核准閘的 loop——機器跑迭代,關鍵轉移等我點頭。

別照搬大神的 loop

最後一個提醒:那些說「我全寫 loop、全天候跑」的人,多半是硬核工程師,那套對他的角色成立。AI 會滲進每個職位,每個人的用法天差地別——知識工作更合理的是按節奏或事件觸發的 loop,不是養一群艦隊跑滿額度。判準永遠是「這真的搬動我的指針嗎」,不是「別人都這樣」。