為什麼該『設計 loop』而非 prompt agent？stacking loops 是什麼

1/

6 月 10-11 日，Steipete、Boris、Andrej 在各自平台說了幾乎相同的話：停止手動 prompt agent，去設計驅動 agent 的 loop。三個獨立聲音在同一周收斂，不是趨勢預言，是工作型態轉型的信號點。但他們說的到底代表什麼改變？

2/

Boris 說得最直：他已不 prompt Claude，改寫 loop，讓 loop 去做事。這句話的含義是，agent 不是被你在用的工具，是在背景自己跑的系統。Andrej 從 Autoresearch 說得更結構：只要你還在迴圈裡等輸出、再下一個指令，你就是系統瓶頸，目標是把一切安排好、按下執行，把 token 吞吐量最大化。Steipete 的說法像月刊提醒，意思是多數人不是不知道，只是還沒真的改做法。三人指向同一結論：槓桿不來自更好的 prompt，來自讓 agent 自驅的架構。但架構的核心判斷是什麼？

3/

這裡有個值得拆開的框架：何時往下一層 loop 修可靠性，何時往上一層 loop 搶槓桿。

往下修是底層不穩的時候，agent 工具串接出錯、輸出品質飄，這是早期必要投入，不可跳過。往上走是底層夠穩之後，在上層再包一層 orchestration（編排）讓多個 loop 協調、目標能分解再聚合。AINews 的說法是：早期要能往下走，但更有價值的技能是知道何時往上，理論上模型每進步一代，這層架構自動跟著放大。這個框架背後有更深的類比。

4/

AINews 把這稱為 agent 端的「Salty Lesson」（鹹澀教訓），對應模型端 Rich 的「Bitter Lesson」（苦澀教訓）：別靠人工特徵，讓計算規模說話。Salty Lesson 說的是 agent 版：別自己去追 bug 和結果，改成搭能隨更多 agent 水平擴展的系統，核心工件是目標定義和 orchestration 架構。失敗模式就是用 agent 前時代的直覺，做 agent 時代的工作。那對工程師的日常，影響有多具體？

5/

影響很具體。過去一年磨 system prompt、試 few-shot example、調 instruction 格式，這些都讓你固定在 loop 裡。往上走一層，核心工作變成：設計 agent 的觸發條件、讓一個 agent 的輸出成為下一個 agent 的輸入、定義能讓系統自我校正的目標。這是 orchestration 工程，思維框架更接近分散式系統設計，比優化 prompt 更難複製，也更能積累成差異點。

6/

AINews 直接點出：搞不清楚怎麼堆疊 loop 的人，等那些搞清楚的人贏了，別酸。堆疊 loop 目前還沒標準路徑，每個 orchestration 架構都在摸索。但能辨認「現在該往下修可靠性，還是往上衝槓桿」，看起來是接下來拉開差距的關鍵判斷力。