你以為它答一次，其實它跑了好幾輪

平常我們問 AI 一個問題，它答一次，事情就結束了。但如果你仔細盯著一個 coding agent 做事，會發現完全不是這麼回事，它會自己跑好幾輪，中間看檔案、跑指令、改程式碼，一直到它自己覺得任務做完了才停下來。

這件事聽起來理所當然，但如果沒有把它想清楚，後面每一天要拆解的東西都會變成沒有地基的空中樓閣。所以 Day2 先不談任何具體元件，只做一件事：把「一個 coding agent 收到任務之後，到底在做什麼」講成一個大家都能有畫面的心智模型。

迴圈，不是一次性問答

業界對這個「自己跑好幾輪」的機制有個統一的說法，叫 agent loop，中文可以叫它代理迴圈。拆開來看，其實就是四個動作不斷重複：

1. 看現況：每一輪開始前，模型會看到目前為止的所有東西，原本的任務是什麼、到目前為止做過哪些事、剛剛做的事得到什麼結果。
2. 想下一步：模型判斷，現在是該直接給答案了，還是該先動手查點什麼、改點什麼。
3. 動手做：如果模型決定要採取行動，真正去執行的不是模型本身，而是包在外面的那層程式，去讀一個檔案、跑一個指令、改一段程式碼。
4. 看結果：動作做完的結果，會被送回去給模型看，模型才能根據「實際發生的事」決定下一步，而不是憑空亂猜。

然後回到第一步，一直重複，直到任務做完、或撞到某個上限，才停下來。

這裡有一個小細節值得放大看：每一次「動手做」後面，一定會跟著「看結果」。這是 agent 迴圈跟一次性問答最大的不同，模型不是把整件事一口氣想完再輸出，而是每做一步就先看看現實世界發生了什麼，再決定下一步怎麼走。這也是為什麼它能處理「一開始想的方法行不通」這種狀況：因為它每一步都有機會根據新的資訊修正自己。

一個修 bug 的例子

抽象的四步驟不好想像，換成一個修 bug 的情境會清楚很多：

想：測試會失敗，是因為 parse_date 遇到空輸入會回傳 None
做：打開 utils.py，在第 42–47 行加一個空值檢查
看結果：檔案改好了
想：應該重新跑一次測試，確認真的修好了
做：執行 pytest tests/test_utils.py
看結果：14 個測試通過、0 個失敗 → 可以結束了

你會發現這跟你自己手動修 bug 的流程其實一模一樣：看錯誤、猜原因、動手改、跑測試驗證、確認沒問題。差別只在於，agent 是把這整個循環自動跑完，不需要你每一步都盯著螢幕。

這只是我用文字描述出來的樣子。實際上 Pi 每跑一輪，都會留下一份完整的逐字記錄，之後 Day6〈打開黑箱〉會帶大家實際打開這份記錄，親眼看看一個真實任務跑起來到底長什麼樣。

為什麼「模型自己不會記得」

這裡有一個容易誤會的地方：迴圈跑到第五輪的時候，模型並不是「記得」前面四輪發生了什麼事，而是每一輪都被重新整包提醒一次，任務是什麼、之前做過什麼、每次工具回傳了什麼，全部重新送一遍給模型看。

聽起來有點笨拙，但這正是這整個系列後面要花很多篇幅討論的地方：這包「重新提醒」的內容要放什麼、放多少、怎麼放，會直接決定 agent 做得好不好、又要花多少成本。這件事我們留到後面幾天（尤其是迴圈跑得很長、這包內容要精簡的時候）再展開，這裡先埋個伏筆就好。

一個值得記住的數字：迴圈越長，越容易出錯

有個算法可以說明為什麼這件事重要：假設迴圈裡每一步的成功率是 95%，聽起來已經很高了。但如果一個任務需要跑 20 步才能完成，整體成功的機率會掉到 0.95 的 20 次方，大約只剩 36%。

換句話說，迴圈跑得越長，任何一步的小失誤都會被一路放大。這也是為什麼「怎麼設計這個迴圈」，它看得到什麼、能做什麼、犯錯之後有沒有機會被抓到——比「模型本身聰不聰明」更值得認真研究。這句話跟 Day1 的結論其實是同一件事的兩種說法：模型固定的前提下，真正決定結果穩不穩的，是這個迴圈怎麼被設計出來的。

迴圈不是萬靈丹

順帶一提，迴圈也不是每個場景都該用。任務很簡單、一步就能做完的，硬套一個會自己跑好幾輪的迴圈，只是浪費時間和成本；高風險的操作（例如直接部署到正式環境），也不適合讓 agent 自己一路跑完，中間該有人卡進來看一眼。什麼時候該放手讓 agent 自己跑、什麼時候該讓人卡在中間，這個判斷本身，也是設計這個迴圈時要回答的問題之一，後面講到工具的使用限制時還會再碰到。

明天

把這四站的迴圈記住：看現況、想下一步、動手做、看結果。之後每一天要拆解的東西，幾乎都是掛在這四站的某一個上面，模型看到什麼、模型怎麼想、模型能動用什麼工具、犯錯之後怎麼被看見。Day3 會把這些之後要拆的元件，畫成一張完整的地圖，讓你先看到全系列的骨架長什麼樣子。