Claude 的新互動範式，乍看之下像是「更會聊天了」。但如果你真的把它放進 agent 工程裡看，重點不只是在模擬人類對話，而是把原本只停留在單次回應的設計，往更完整的執行系統推了一步。很多人以為 AI 進步，都是模型本身更強；可是在實作層面，真正拉開差距的，常常是它怎麼被觸發、怎麼被檢查、怎麼被修正，以及做完之後狀態要送去哪裡。
這也是為什麼，Claude 的新互動範式值得放到 Outer Loop Engineering 來看。因為它不只是「一次 prompt 寫得更好」，而是開始處理更外層的問題：什麼時候啟動 agent、每次是不是要乾淨 context、進度寫在 context 外還是靠模型記憶、多個任務怎麼平行協調。換句話說，焦點已經從「模型會不會答」移到「整個任務怎麼跑完」。
從更像人，到更像一個可運作的系統
如果只看表面，互動變得自然、連續、像人在接話，會讓人直覺覺得這是語氣層的升級。但 agent 工程真正關心的，是這種自然感背後有沒有更好的控制流程。因為單次對話再流暢，也不代表任務會完成；而任務能完成，通常靠的是 harness，而不是純 prompt。
在 Harness Engineering 的語境裡，Agent = Model + Harness。模型負責生成，但 harness 要負責約束、檢查、動態修正。也就是說，Claude 這類新互動方式如果真的有進步，價值不只在「更像人」，而是在執行期間更容易被引導到正確路徑，讓 agent 不只是說得通，而是做得完。
真正的關鍵：回饋不只在最後，而是分層發生
把 agent 迴圈拆開來看，回饋其實有四個時機：工具執行內、request 之間注入、單輪結束、外層 loop。Claude 的新範式之所以重要，就是它更自然地接上了這條回饋鏈。
1. request 之間注入，讓方向能即時改
當 tool calls 的結果都回來、但下一次 model request 還沒送出前，框架可以插入新的訊息，立刻改變接下來的動作。這種 request injection 很適合中途 steering：人類看到 agent 走偏，直接補一句新方向；或是背景工具完成後，把結果送回去。這讓互動不再只是「問完等答」，而是任務進行中就能修正。
2. 單輪結束前驗收，避免太早說完成
另一層是 stop hook、Goal、Outcome。也就是 agent 雖然快要結束了，但 harness 可以先攔下來檢查。這比單純相信模型「自己會驗證」可靠得多。Claude 這種互動方式如果搭上這層機制，就不是只是回話順，而是能在結束前被驗收。
3. 外層 loop，把單次 session 變成任務流程
最外層才是 Outer Loop Engineering：cron、webhook、CI 失敗、看板 ticket、queue，任何事件都可能啟動 agent。這一層管的是「何時跑、跑哪個、跑完結果去哪」。進度則不能只放在 context 裡，而要寫到外部狀態，例如 git、文件、資料庫、看板。這也是從聊天 agent 走向工作系統的分界。
為什麼說它把 Outer Loop Engineering 往前推了一步
因為一個成熟的互動範式，不會只優化當下這輪回答，而會開始支援整體任務的調度與收斂。像 Ralph 那種做法，甚至可以用無窮迴圈一圈圈重新載入 prompt，每次都用乾淨 context，並靠 git history、progress.txt、prd.json 這些外部狀態維持進度。OpenAI Symphony 更進一步，把專案看板直接當狀態機，讓 ticket 決定 agent 何時跑、誰來跑、何時收掉。
Claude 的新互動範式之所以被認為有意義，正是因為它讓這些外層設計更容易接上：
- 不是只做一次回答，而是支援連續的任務推進
- 不是只看模型輸出，而是把驗證放進流程
- 不是只靠 context 記憶，而是讓外部狀態承接進度
這些都屬於 Outer Loop Engineering 的核心。
互動變自然只是表面，真正重要的是可控
如果把 agent 比喻成跑步的人，那 prompt 只是起跑口令，context 是手上帶的資料，harness 才是路線、補給站和終點檢查。Claude 的新互動範式之所以值得注意，不是因為它更會講話，而是因為它更接近一個可以被排程、被注入、被驗收、被重跑的工作單元。
這也是 agent 工程接下來的重心：不是讓模型看起來像人，而是讓它在整個任務生命週期裡，真的能像系統一樣穩定運作。