agent 迴圈怎麼搭：目標、工具與觀察環境

上一篇我們定了調：能用 workflow 就用 workflow，真的開放的任務才交給 agent。這一篇就來拆 agent 本體：把外殼剝掉，agent 其實只是一個迴圈：模型看目標、挑工具、你執行、把結果餵回去，再問一次，直到做完。

迴圈本身不難寫，難的是搭得好。這篇聚焦三件事：迴圈的結構、工具該怎麼設計、以及最常被忽略的一塊：讓 agent 能觀察自己動作的結果。

迴圈的骨架

agent 的定義可以濃縮成一句：給 Claude 一個目標與一組工具，讓它自己想辦法。落到程式層面，就是圍繞 API 的一個迴圈：每一輪把目前的對話與工具定義送給 Claude，看它是要呼叫工具還是要收工。用偽程式碼表達：

messages = [user_goal]

while True:
    response = claude(messages, tools=tools)
    if response.wants_tool_call:
        result = run_tool(response.tool_name, response.tool_input)
        messages.append(tool_result(result))   # feed result back
    else:
        break   # final answer reached

注意分工：決定用哪個工具的是模型，真正執行工具的是你的程式。執行結果一定要加回對話再送下一輪，這樣 Claude 才知道剛才那步發生了什麼，據此決定下一步。迴圈一直轉，直到它認為目標達成，不再呼叫工具為止。

工具成就 agent：組合的威力

agent 的能力上限不在迴圈，在工具。而且有趣的是，簡單工具的組合會長出你沒設想過的能力。舉一組時間工具當例子：取得目前時間、對時間做加減、設定提醒。

三個都很平凡，但 Claude 能把它們串出各種行為：問「11 天後是星期幾」，它先取得今天再做加法；要「下週三提醒我上健身房」，它三個都用上；問「我的 90 天保固什麼時候到期」，它甚至知道要先反問你購買日期。

工具要抽象，不要特化

設計工具時最重要的原則：提供合理抽象的工具，而不是超特化的工具。最好的示範就是 Claude Code 本身：它的工具是 bash、讀檔、寫檔、編輯、找檔案、搜尋內容這種基本款，沒有「重構程式」工具、也沒有「安裝相依套件」工具。

這些複雜任務，它自己用基本工具組合出來，所以能應付開發者沒預想過的無數情境。

換到你自己的應用也一樣。假設要做社群影片 agent，合理的工具組是：bash（操作 FFmpeg 處理影片）、產生圖片、文字轉語音、上傳發佈。這組工具既能走完「做影片然後發佈」的固定路，也能支援互動玩法：先生成一張示意圖給使用者過目，同意了再往下做。

反過來說，如果你發現自己在幫 agent 加「產生開箱影片」「產生教學影片」這種一個比一個窄的工具，就該警覺了：特化工具每加一個，agent 的自由度就少一分，最後你維護的是一大把只能各做一件事的按鈕，而不是一個會解題的系統。

環境觀察：別讓 agent 盲目做事

這是搭 agent 最常被忽略的一塊。Claude 看不到你的系統，它對世界的全部認知，來自你餵回去的工具結果。所以每個動作都要能觀察後果：computer use 每點一下就拿一張截圖，因為點下去可能開新頁、可能彈選單，不看就不知道；改檔案前一定先讀檔，理解現況才能安全地改。

更進一步，可以在 system prompt 裡把「驗證」寫成任務的一部分。例如影片生成 agent 可以被指示：用語音辨識工具產生帶時間戳的字幕檔，核對對白位置對不對；用 FFmpeg 定期擷取畫面截圖，檢查視覺元素有沒有出現；最後拿成品跟原始需求比對。

• 進度追蹤：agent 能判斷自己離完成還有多遠。
• 錯誤處理：非預期的結果被看見，才有機會被修正。
• 品質保證：產出先驗證再交付，而不是做完就算。
• 行為調適：依觀察到的狀況調整做法，而不是一路照原計畫衝。

收尾：一個問題檢驗你的設計

設計 agent 的每個工具與每段流程時，反覆問同一個問題：「Claude 怎麼知道這個動作成功了沒？」答不出來，就補上對應的觀察手段：讀回檔案內容、擷取畫面、檢查 API 回應、驗證產出格式。迴圈給了 agent 手腳，工具給了它能力，而環境觀察給了它眼睛：三者到齊，agent 才真的能自己把事情做完。