Agent 的重點不是「更像人」

Chatbot 的基本單位是一次問答：使用者提出問題，模型產生文字。Agent 的基本單位則是一個需要完成的目標。它可能先讀取專案檔案，再呼叫 API、修改程式、執行測試，最後回報哪些事情已經完成、哪些地方仍需要人判斷。

這個差異看起來只是產品命名，實際上卻會改變開發者設計工作的方式。當模型開始使用工具，錯誤就不再只是一句答錯的文字，而可能是一個被寫進 repository 的決定。因此，Agent workflow 的核心不是讓模型擁有更多權限，而是把每一個權限放在可以觀察、可以撤回、可以驗證的位置。

一個可靠的 Agent loop

可以先把 Agent 想成一個很樸素的循環：理解目標、選擇行動、執行工具、檢查結果，然後決定是否繼續。這個循環不需要一開始就很複雜，但每一段都要有清楚的輸入與輸出。

1. 把模糊目標變成可驗收的結果

「幫我改善登入流程」對人類團隊來說可以作為討論起點，對 Agent 來說卻太寬。較好的任務描述會包含影響範圍、不可改動的部分，以及完成條件，例如：

  • 只修改登入頁與相關測試，不更動資料庫 schema
  • 保留現有的 error message 與 redirect 行為
  • 新增一個失敗案例，並讓 npm test 通過

這些條件不是繁瑣的文件工作，而是 Agent 能否自我修正的依據。

2. 工具要小，回傳要可讀

把整個 shell 交給模型很方便，卻很難控制風險。較穩定的做法是提供窄介面的工具：讀檔、搜尋、套用 patch、執行指定測試。每個工具的回傳也應該盡量短而有結構，讓模型知道自己拿到的是檔案差異、測試結果，還是需要人工確認的警告。

工具越小，Agent 的行為越容易被記錄。當一次任務失敗時，我們才有機會回答「它在哪一步做了錯誤假設」，而不只是重新執行一次看看。

Human-in-the-loop 不是退步

完全自動化很適合拿來當宣傳句，但在真實的 codebase 裡，最有效率的模式往往是把人放在高價值的決策點。Agent 可以先整理影響檔案、提出 patch、跑測試；人則在合併之前確認產品語意、資料邊界與不可逆的操作。

這種分工也讓團隊比較容易建立信任。你不必相信模型「永遠正確」，只要能看懂它做了什麼、知道它如何被驗證，並且能在需要時撤回。

從哪裡開始比較實際？

第一個 Agent 任務不應該是「接管整個專案」。可以從有明確輸入與輸出的工作開始：替既有 API 補測試、整理錯誤 log、將重複的設定轉成共享 helper，或為一個小元件產生文件。這些任務足以測量節省的時間，也能暴露上下文不足、權限過大與驗證不完整等問題。

真正值得追蹤的指標也不只是生成了多少行程式碼，而是：一次任務需要多少次人工修正、測試是否真的捕捉到回歸、以及團隊是否更快理解變更。Agent 的價值，最後會落在更短的 feedback loop，而不是更長的 prompt。