代理迴圈：你在等回應時，Claude Code 在做什麼

你寫了一句話，按下 Enter，接著終端機裡就開始一行一行往上跑。開啟檔案。執行指令。又開啟同一個檔案。從旁邊看像是在瞎忙：明明只是要它做一件簡單的事，卻冒出一連串又久又看不懂的事。

其實它沒有在瞎忙。代理在跑一個由三個部分組成、不斷重複的迴圈，你在畫面上看到的幾乎所有東西，都是同一個迴圈跑到不同圈數而已。

為什麼代理做的事比聊天機器人多

聊天機器人印出答案之後，剩下的全靠你動手：複製、貼上、存檔、執行。代理則是自己在你的專案裡工作，開啟檔案、修改檔案、執行指令、查看結果，而這些修改是實實在在留在你的磁碟上。

這就帶出了這篇文章真正想講的事。既然代理是動手做，而不是給建議，就不可能一步到位。從你那句話到最後的成果之間有好幾個步驟，而且每一步都會顯示在畫面上。

一個步驟由什麼組成

收到你的請求後，代理就進入這個迴圈，需要跑幾圈就跑幾圈。每一圈都由三個部分組成。

收集上下文。代理會去補讀它還不知道的東西：開啟需要的檔案、看看專案結構、讀上一個指令的輸出。最常讓人意外的是這一點：它不是把你的專案背下來，而是去讀它。每次需要某個細節，它就會自己去看。

執行動作。一個具體的動作：修改一個檔案，或執行一個指令。不是一口氣做完整個構想，而是只做下一步。

檢查結果。看看實際做出了什麼，再跟你要求的內容比對。

接著是分岔點。目標達成，代理就停下來，等你的下一個請求。沒達成，就回到收集上下文，再繞一圈。

而且這個迴圈會配合請求調整，不是照著固定流程走完。一個關於程式碼的簡單問題，可能在收集上下文就結束了：代理讀完、回答，什麼都沒改。修一個 bug 則正好相反，三個部分會來回跑好幾次。各部分之間的界線也不一定分明，代理在整個迴圈裡都會用到工具。

那些看起來很奇怪的事，都是從這裡來的。代理把同一個檔案開了兩次，是因為改完之後需要重新看一遍。從請求到回應過了好幾分鐘，是因為跑了四圈而不是一圈。回到起點不是出錯，是正常運作。

推理與工具呼叫

代理做的事，並不是每一件都會改動專案裡的檔案。這條界線正好從它工作的中間劃過，能把它看清楚會很有幫助。

推理 - 代理在盤算下一步要做什麼、該去看哪個檔案、錯誤的原因可能在哪裡。這時磁碟上的改動是零。不管它推理得多有說服力，這些都還只是打算。

工具呼叫 - 到這裡才是真的在動手。讀取或寫入檔案、在專案裡搜尋、執行指令、上網查文件。每一個這樣的動作都會在終端機裡單獨顯示成一行，專案實際發生的事，就是由這些動作一步步累積起來的。

呼叫的結果會回傳給代理，變成它下一圈已知資訊的一部分。讀了檔案，現在就知道裡面寫什麼。跑了測試，現在就知道有沒有通過。

實務上的結論很簡單。關於工具呼叫的那幾行，不是可以看都不看就捲過去的雜訊。你的檔案此刻發生了什麼事，就是在那裡看到的。

為什麼代理會問問題

工作到一半，代理可能會停下來問你。這是迴圈裡的正常環節，不代表它搞不定。

問題分成兩種，分清楚會很有幫助：

• 缺少關於任務的資訊 - 到底要改什麼、兩個很像的檔案你指的是哪一個、怎樣才算完成。代理碰到了模稜兩可的地方，不想用猜的；
• 需要執行動作的許可 - 代理準備做一件影響比較大的事，所以先停下來問你可不可以。它能自己做主到什麼程度，取決於設定。

第一種問題是好兆頭。現在先問清楚，總比往錯的方向跑了三圈再重做好。

說說你怎麼理解這個任務，以及打算怎麼解決。
如果提問能幫助你更了解任務和目標，就儘管問。

由誰決定是否完成

代理說"完成"，意思只有一個：它的迴圈結束了。它執行了動作，用自己的標準檢查了結果，判斷目標已經達成。但工作本身還沒結束。

一個改動算不算被接受，不是看代理做完了沒有，而是看人有沒有查看實際改了什麼，並為這個結果負起責任。接下來有兩種可能：接受，工作就此結束；退回修改，由你說清楚哪裡不對，迴圈再從你的新請求重新開始。

這時要看的不是報告，而是改動本身：代理會顯示它刪掉了哪幾行、加了哪幾行。這才是"改了什麼"的準確答案，而答案並不在代理寫的文字裡。

實際搭配 Claude Code 使用時

理解這個迴圈，在實務上能幫你什麼：

• 請求寫得越精確，圈數就越少。代理會一直繞圈，直到結果符合你的要求，描述得含糊，就得多繞幾圈；
• 你自己在檔案裡做的修改，代理下次開啟那些檔案時就會讀到：畢竟它不是記住專案，而是去讀。如果你手動改過什麼，記得跟它說一聲；
• 代理的迴圈以"完成"這兩個字結束。工作則是以你的檢查結束，這是兩個不同的時間點。

整體來看是這樣：代理的迴圈在內側，你的檢查在外側。