*圖 1｜Tool、Workflow 與 Agent 的差異，在於系統需要多少動態決策*
## 工具（Tool）提供能力，代理（Agent）負責決策循環 Tool 很像一組員工可以使用的軟體：查資料、算數字、搜尋文件或讀取專案狀態。它本身不會決定何時使用，也不會理解任務是否已經完成。 Agent 則多了一層判斷。它收到問題後，會先分析需要哪些資訊，選擇工具，觀察工具回傳結果，再決定是否需要繼續查詢。如果結果不足，它可能換一個工具、調整查詢條件，甚至向使用者確認。 ```text theme={null} 理解任務 → 選擇工具 → 執行 → 觀察結果 → 再判斷 ``` 這個循環才是從自動化腳本走向 Agent 的核心。 ## 固定工作流程（Workflow）與代理（Agent）各有價值 這裡很容易陷入「Agent 一定比較進階，所以什麼都應該交給 Agent」的誤區。其實如果任務步驟固定、規則明確，直接用 Workflow 往往更可靠，也更容易測試。只有當問題類型多、工具選擇需要語意理解，或中間結果會影響後續動作時，Agent 的自主判斷才真正有價值。 例如「每天 9 點產生同一份報表」幾乎不需要 Agent；但「找出問題最大的市場，確認其定義，再查看相關專案是否有改善計畫」就比較適合讓系統根據資料逐步決定。 ## Data Machi 為什麼需要 Agent 層？ Data Machi 最初可以靠固定條件判斷數據問題與文件問題，但當使用者開始提出複合查詢，if/else 很快會膨脹。更合理的做法，是讓 Coordinator 先理解任務，決定呼叫哪些 tools，再把工具結果整合起來。 不過自主性愈高，也代表系統愈可能走錯路。因此接下來幾天不會只談「怎麼讓 Agent 更自由」，反而會同時討論如何觀察、驗證與控制它。 ## 進階理解｜新增能力時，先問它應該是 Tool、Workflow，還是 Agent？ 判斷一項能力應該做成工具、工作流程還是代理時，可以先用一個簡單的方法思考。對非工程背景讀者，可以用三個問題判斷： 1. **只要做一件明確的事嗎？** 例如查一張表、搜尋一份文件，通常就是 Tool。 2. **步驟可以事先列清楚嗎？** 例如查資料 → 驗證 → 產出報告，通常用 Workflow 更穩定。 3. **下一步必須看中間結果才知道嗎？** 如果系統需要理解語意、觀察結果、動態改變策略，才真正需要 Agent。 這個順序可以避免把簡單功能過度工程化。Agent 帶來彈性，也帶來成本、延遲與較難預測的行為，因此應該只在「決策真的無法事先寫死」的地方使用。