AI Agent 與聊天機器人的核心差異，不是回答比較像人，而是 Agent 能依工作狀態選擇工具、讀取執行結果、修正下一步，最後留下可驗收的成果。若系統只產生一段文字，再長、再聰明，仍比較接近聊天助手。
用四個問題判斷它是不是 Agent
OpenAI 將 Agent 描述為能代表使用者完成任務的系統：模型管理工作流程、判斷何時完成，並使用工具取得資料或採取行動。單輪 LLM 或未讓模型控制工作流程的聊天機器人，則不在這個定義內。OpenAI 的 Agent 建置指南也強調，工具與 guardrails 是核心組成，而非附加功能。
評估企業 AI 工具時，可以問四個問題：
| 問題 | 聊天機器人常見結果 | Agent 應有的結果 |
|---|---|---|
| 它知道工作到哪裡嗎？ | 依賴整串對話猜測 | 讀取明確狀態與待辦 |
| 它能使用真實工具嗎？ | 建議你怎麼做 | 查資料、執行受允許的動作 |
| 工具失敗後會怎樣？ | 解釋可能原因 | 讀錯誤、修正或交回人類 |
| 完成後留下什麼？ | 一段回答 | 文件、程式、查詢或可驗收紀錄 |
因此，「能呼叫 API」還不夠。若沒有完成條件、狀態、權限和錯誤處理，工具呼叫只是較花俏的聊天。Anthropic 也把 Agent 定義為會自行決定流程與工具使用的模型，同時指出有些偏好或意圖只能由人決定；可信任性並不等於完全放手。Anthropic：Trustworthy agents in practice
數據分析最能看出差別
假設使用者問：「上季新客轉化率為什麼下降？」
聊天型回答可能讀入一份 CSV，直接給出「轉化率下降 8%，主因是行動版流失」。但真正可驗收的分析還有一串問題：新客以註冊日還是首購日定義？分母是造訪、註冊或進入結帳的人？退款是否排除？跨季完成付款算在哪一季？行動版與桌機是否重複計人？
Agent 工作流應把任務拆成可觀察的狀態：
- 先確認決策問題、時間範圍、分母、粒度與排除條件。
- 探索 schema，找出事件表、訂單表與 join key。
- 起草可審閱的 Plan，讓業務 owner 修正口徑。
- 獲得授權後執行 SQL，保留查詢與驗證 checkpoint。
- 交付 Report，列出發現、證據與限制。
「回答」的驗收點是文字看起來是否合理；「工作」的驗收點則是需求、過程和成果能否被追問。後者需要的不只是模型，還需要一個容納狀態、工具和 artifacts 的工作環境，也就是常說的 Agent harness。
Lantide Data 把 Agent 放進分析工作面
Lantide Data 是 Local-first 桌面 SQL 分析 IDE，內建與工作區整合的 Agent runtime。正式的 Project Analysis 不是讓 Agent 在聊天裡直接宣布答案，而是形成 Plan → 審閱／批註 → 使用者按 Execute → Report 的流程；取數邏輯以 SQL 分頁為主要證據。產品設計可參考系列導讀與定位及Agent 分析工作流。
這套設計的優點不是保證 Agent 不犯錯，而是讓人能在正式執行前檢查口徑，並在完成後回到 SQL 與 Report 查證。Agent 可以探索 schema、草擬 Plan、建立與執行查詢；但正式 Execute 仍是使用者的可觀察動作，Report 的業務解讀也仍需負責決策的人判斷。
它也不是所有任務的最佳答案。只問 SQL 語法、做一次性欄位預覽，用聊天或 Lantide 的 Quick Analysis 會更省事；固定 KPI 的長期監控，成熟 BI dashboard 通常更合適。Lantide 的主場是「問題還要釐清，但成果最後會被追問」的分析工作。
結語
判斷一個產品是否真是 AI Agent，不要只看它能不能聊天或按按鈕；看它是否理解狀態、在權限內使用工具、遇錯能停下或修正，並留下可驗收成果。評估下一個 AI 分析情境時，可先把「最後要驗收的 artifact 是什麼」寫下來，再決定需要聊天助手還是完整 Agent 工作流。