AI Agent
AI Agent 該不該用？IBM 的四個判斷準則與上線守則
AI Agent 該不該用？IBM 的四個判斷準則與上線守則
上一篇整理了 IBM《Fundamentals of Building AI Agents》的觀念：複合 AI 系統、控制邏輯與 ReAct。這一篇進入實作面。課程裡我最想劃重點的不是程式碼，而是一份判斷框架：什麼時候該用 Agent，什麼時候用了反而更糟。
Agent 很迷人，但它昂貴、難預測、需要防護。這篇把課程教的判斷準則、風險管理與部署節奏一次整理清楚。
你將學到什麼
四個判斷準則
模糊度、成本、能力、出錯後果，一題一題問。
不適用場景
哪些任務交給 Agent 反而更糟。
架構三要素
環境、工具、系統提示，保持簡單。
分階段部署
概念驗證、試點、正式上線的節奏。
先問四個問題再動手
課程給了一個四準則框架，決定一個任務要交給 Agent，還是交給普通的工作流程：
- 任務是模糊的還是可預測的？決策路徑無法事先畫出來、需要探索、排錯或創意的任務，適合 Agent；規則與結果都能定義清楚、流程可重複的，用工作流程。
- 價值撐得起成本嗎？Agent 因為要探索，token 消耗可能是工作流程的 10 到 100 倍。高報酬的策略規劃值得，基本客服任務就不值得。
- Agent 通過最低能力測試了嗎？上線前挑三到五個關鍵技能實測，例如客服 Agent 要能分類問題、解決常見詢問、正確升級複雜案件。測不過，就縮小範圍或重新設計。
- 出錯了會怎樣？錯誤能不能快速發現並修正？後果會不會影響客戶或組織的安全？風險可控、可回復，才考慮 Agent。
這四題的順序是刻意的：先看任務性質，再看經濟性，接著驗能力，最後評風險。任何一題答不過去，就退回工作流程；四題都過，才值得把控制權交給模型。
哪些場景不要用 Agent
課程很少見地直接列出「不要用」的清單，我原封不動抄給你：
- 高頻、低毛利的任務，例如基本的聊天客服。
- 需要即時回應的應用，例如即時詐欺偵測。
- 零容錯系統，例如醫療或安全決策。
- 需要確定性結果的高度監管產業。
背後的原因是現階段 Agent 的三個罩門：推理不穩定（這次成功，類似任務下次可能失敗）、成本難預測（複雜度一高，資源消耗就飆升）、工具整合（需要整合良好的工具與穩定的 API）。
Agent 架構的三個要素
有效的 Agent 架構其實很簡單，只有三個元件：環境（Agent 運作的數位空間）、工具（它用來行動與觀察的介面）、系統提示（規範它目標與行為的規則）。課程反覆強調同一句話：從簡單的行動開始，等 Agent 表現穩定了，再增加任務的複雜度。
三個要素裡最容易被輕忽的是系統提示：目標寫得含糊，Agent 就會用你想不到的方式自由發揮。
風險分級與分階段部署
部署前先幫任務做風險分級，不同等級配不同的防護：
| 風險等級 | 應對策略 |
|---|---|
| 高風險且不易察覺 | 人工審查，加上多層驗證 |
| 高風險但看得見 | 自動化檢查與監督機制 |
| 低風險 | 監控行為、蒐集使用者回饋、輕量驗證 |
部署節奏則分三個階段：
- 概念驗證：用低風險、可回復的任務試水溫。
- 試點計畫：在監督下處理中等風險的任務。
- 正式擴大：確認安全與表現後，才放大使用範圍。
搭配四個起手式：工具與系統先給唯讀權限、關鍵步驟加人工核可、分階段部署並持續監控、開啟完整日誌。這幾條看起來保守，但 Agent 的行為本來就難預測，防線要先架好，而不是出事後補。
課程裡實際動手做什麼
這門課的實作全部圍繞 LangChain 生態：模組一打基礎，講工具呼叫（tool calling）與 AI Agent 的概念；模組二進入 LangChain 表達式語言（LCEL）與手動工具呼叫，學怎麼解析、驗證模型輸出的工具呼叫；模組三用內建的 DataFrame Agent 與 SQL Agent，讓你用自然語言分析資料、產生視覺化、查資料庫。課程明說要會 Python，最好也摸過 LangChain，再來修比較不吃力。
