這兩年只要聊到 AI Product，很容易一路聊到最後一個詞：
Agent。
FAQ 很多？
先做 AI Assistant。
可以理解 User 之後呢？
接公司的 Data。
再下一步呢？
「不然讓它直接幫 User 做？」
例如：
「幫我申請下週五休假。」
「幫我把這筆訂單退款。」
「幫我整理上個月數據，寄給 Team。」
「幫我找三間飯店，選好後訂下來。」
聽起來很自然。
但我最近越來越覺得：
從「回答問題」跨到「幫 User 做事」，不是多接一個 LLM 就完成了。
因為真正的 Agent，不只需要理解 User。
它還需要：
有資料可以看、有 Tool 可以用、有權限可以做，而且做錯時知道怎麼回來。
所以如果今天有人跟我說：
「這個我們可以做 Agent。」
我現在會先問：
我們真的 Agent Ready 了嗎？
第一步不是決定 Model。
而是先把 Task 說清楚。
例如：
「做一個 HR Agent。」
這其實不是一個可以設計的 Task。
因為它可能代表：
回答 Policy
查剩餘假期
建立休假申請
修改申請
取消申請
通知主管
每一件事需要的 Data、Tool、Permission、Risk 都不同。
所以我會先問：
User 到底想把哪一件工作 Delegate 給 Agent？
好的 Agent Task 應該可以被清楚描述：
Input
→ Goal
→ Expected Outcome
例如：
Input：
「幫我請下週五休假」
Goal：
建立一天年假申請
Outcome：
Leave Request 成功建立
先把 Task 定義清楚，後面才有辦法談 Agent。
Agent 跟一般 Automation 最大的差異之一，是它中間可能需要做 Decision。
例如：
「幫我安排下週去東京出差。」
背後可能包含：
哪一天？
搭哪班飛機？
預算多少？
住哪裡？
哪些資訊可以自己推斷？
什麼時候要問 User？
這時候 PM 不能只畫：
User
↓
Agent
↓
Done
而要把 Decision Point 找出來。
再判斷：
Rule 可以決定？
Context 可以推斷？
需要 User Clarify？
需要 User Confirm？
Day 8 寫過：
Ignore / Infer / Clarify / Confirm。
到了 Agent，這些不再只是 Conversation Design。
而是 Agent 能不能安全完成 Task 的核心。
Day 10 提過 Data Readiness。
到了 Agent，這件事更重要。
因為 Agent 不只是「回答錯」。
它可能真的會：
做錯。
例如想做一個退款 Agent。
它可能需要知道：
Order Data
Payment Status
Refund Policy
User Identity
Refund History
如果資料散落在五個 System、Definition 不一致，甚至根本沒有被記錄，
Agent 就沒有足夠 Context 做正確 Decision。
所以我會問：
Agent 做每一個 Decision，需要哪些 Data？
以及：
Data 存在嗎？
可信嗎？
拿得到嗎？
夠即時嗎？
很多 Agent Project 最後卡住的，不是 Model。
而是 Data Foundation。
這是我覺得從 Chatbot 到 Agent 最關鍵的一步。
LLM 很會說：
「好的，我幫你取消訂單。」
但如果背後沒有 Cancel Order API，
它其實什麼都沒做。
真正能執行 Task，需要的是 Tool。
例如退款：
get_order()
get_payment()
check_refund_policy()
create_refund()
send_notification()
所以我現在會把 Agent 想成：
LLM
負責理解 / 判斷
+
Tools
負責執行
Agent Capability 的上限，很多時候不是 Model 有多聰明。
而是：
System 到底提供了哪些可靠的 Action 給它呼叫。
如果公司內部流程只能人工操作、沒有 API、沒有可控的 Tool，
那可能還沒準備好直接做 Agent。
假設 API 都有了。
下一題反而更重要：
Agent 有權限執行嗎？
例如：
查訂單
→ 可以
產生退款 Draft
→ 可以
真的退款
→ 需要 Confirm
修改收款帳號
→ 更高權限
刪除資料
→ 可能禁止
這其實延續了 Day 4 的 Human-in-the-loop，也接到 Day 12 的 Boundary。
Agent 不應該只有：
Can / Cannot
還需要：
Read
Prepare
Recommend
Execute with Confirmation
Execute Automatically
Forbidden
PM 要定義的，不只是 Agent 有哪些 Tool。
還包括：
什麼狀態下，它有資格使用這個 Tool？
這是我覺得 Agent Design 最容易被 Demo 忽略的一塊。
Demo 永遠走 Happy Path：
理解需求
↓
Call Tool
↓
成功
但真實世界一定會有：
API Timeout
資料不完整
Permission Denied
Tool 執行一半失敗
User 中途改需求
Agent 選錯 Action
假設 Agent 要完成三步：
建立訂單
↓
扣款
↓
寄通知
結果：
第一步成功。
第二步失敗。
現在怎麼辦？
重試？
Rollback？
停下來？
通知 User？
轉人工？
所以 Agent PRD 一定要多問：
如果做到一半失敗，System State 怎麼恢復？
真正成熟的 Agent，不是永遠不失敗。
而是：
失敗之後，產品知道怎麼收拾。
如果整理成一個 PM Checklist：
1. Task
User 要 Delegate 什麼工作？
↓
2. Decision
Agent 中間需要做哪些判斷？
↓
3. Data
做判斷需要哪些 Context？
↓
4. Tool
System 有哪些 Action 可以呼叫？
↓
5. Permission
哪些 Action 可以自動執行？
↓
6. Recovery
失敗之後怎麼恢復？
我會把它簡化成：
Task → Decision → Data → Tool → Permission → Recovery
這六個裡面，如果後面幾個還沒有 Ready，
也不代表這個 Use Case 完全不能做。
而是可能要先降低 Agent 的 Autonomy。
假設最終目標是：
「幫我完成退款。」
產品不一定第一天就做到 Fully Autonomous Agent。
可以分階段：
Phase 1｜Answer
告訴 User 怎麼退款
↓
Phase 2｜Guide
帶 User 完成退款
↓
Phase 3｜Prepare
Agent 準備好退款資料
↓
Phase 4｜Execute with Confirmation
User Confirm 後執行
↓
Phase 5｜Autonomous Execution
符合條件時自動完成
這對我來說反而是一種比較實際的 Agent Roadmap。
不是先決定「我要做 Agent」，再一次把所有權限交出去。
而是隨著：
Data Readiness
Tool Readiness
Eval Reliability
Guardrail
Recovery
逐步提高 Autonomy。
前幾天一路寫下來：
Day 10 問：
這個 Problem 值不值得用 AI？
Day 11 問：
什麼叫 AI 做得好？
Day 12 問：
AI 的能力 Boundary 在哪？
到了今天，我覺得才真的可以問：
我們 Ready 讓 AI 幫 User 做事了嗎？
因為一個真正能落地的 Agent，背後需要的其實是：
清楚的 Task
可控的 Decision
可靠的 Data
可呼叫的 Tool
明確的 Permission
完整的 Recovery
缺一個，都可能讓 Demo 很漂亮，但 Product 很難真正上線。
不要先問「能不能做 Agent」，先問「這個 Task 值不值得交給 Agent，以及我們 Ready 到哪一步」。
Agent 最迷人的地方，是它開始替 User 做事。
但真正決定它能不能從 Demo 走到 Product 的，
往往不只是 Model。
而是：
整個 System，有沒有準備好讓它做事。
iThome鐵人賽
看影片追技術