Make AI Agents 適合想把 AI 放進工作流、但又不想失去可視化控制的人。它不是單獨的聊天機器人，而是放在 Make 的 scenario builder 裡，和既有 modules、apps、資料轉換、條件分支一起運作。
這點很重要。許多 AI agent 工具看起來很聰明，但一旦流程出錯，很難知道它為什麼做出那個決定。Make 的方向是把 agent 放回可視化流程中，讓你看得到它用了哪些 tools、如何推理、哪一步需要調整。
Make AI Agents 是什麼？
Make 官方在 2026 年 2 月推出新版 Make AI Agents app。新版 agent 直接在 scenario builder 中設定，可以和 Make 的 apps、modules、MCP server tools、knowledge、input 一起使用。
在 Make 的語境裡，一個 AI agent 通常包含：
| 元件 | 說明 | 實務用途 |
|---|---|---|
| LLM | agent 的推理模型 | 理解請求、做判斷 |
| AI provider | 連接模型的供應商 | Make provider、OpenAI、Gemini、Claude 等 |
| Instructions | 行為規則 | 定義角色、任務、限制 |
| Knowledge | 參考資料 | FAQ、品牌規範、政策文件 |
| Input | 每次執行的變動資料 | Slack 訊息、表單內容、訂單資料 |
| Tools | agent 可使用的動作 | modules、scenarios、MCP tools |
| Reasoning | 決策過程 | 除錯與稽核 |
Make AI Agents 的重點不是「把所有流程交給 AI」，而是把 AI 放在需要判斷的節點，再用 Make 既有 automation 做穩定執行。
什麼時候該用 Make AI Agents？
Make 官方文件給出很清楚的判斷方向：需要彈性推理、判斷與變動輸入輸出的任務，適合用 scenario 加 agent；固定邏輯則用標準 scenario。
適合 agent 的流程
- 客服 ticket 分類
- 候選人初步篩選
- 市場資料摘要
- 銷售 lead 評估
- 供應商郵件分類
- 合約條款初步標記
這些任務共同點是：輸入內容很雜，同一種結果可能由不同文字表達，單靠 if/else 很難維護。
不適合 agent 的流程
- 訂單同步
- 固定格式報表產生
- 資料欄位轉換
- 每日定時備份
- 已有明確規則的通知流程
這些任務用標準 scenario 更穩。Agent 應該處理模糊與判斷，不應取代所有固定邏輯。
Make AI Agents 與標準 scenario 的差別
| 比較項目 | 標準 scenario | Make AI Agents |
|---|---|---|
| 流程邏輯 | 預先定義 | 可根據輸入調整 |
| 適合資料 | 格式穩定 | 文字、訊息、非結構化資料 |
| 可預測性 | 高 | 需要測試與限制 |
| 除錯方式 | 看每個 module | 看 module 與 reasoning |
| 風險控制 | 條件分支與錯誤處理 | tools 權限、instructions、人工審核 |
實務上，最好不要把整個 scenario 都改成 agent。比較穩的做法是：trigger、資料清理、寫入系統仍由標準 modules 處理；agent 只負責判斷與產出結構化建議。
第一個 Make AI Agent 該怎麼設計？
第一步：選低風險任務
不要從付款、退款、合約批准開始。第一個 agent 最好選「錯了也容易修正」的流程，例如：
- 客服 ticket 分類
- 文章摘要
- 郵件優先級判斷
- Slack 討論整理
- 表單內容標籤化
這些任務能快速看出 agent 是否有幫助，也不會因為一次錯誤造成重大損失。
第二步：定義輸入與輸出
AI agent 最怕輸出格式漂移。建議一開始就要求固定格式：
請根據輸入訊息輸出 JSON：
{
"category": "billing | technical | sales | partnership | other",
"priority": "low | medium | high",
"summary": "一句話摘要",
"recommended_owner": "support | sales | product | finance",
"needs_human_review": true
}如果後面要接其他 module，固定輸出比漂亮文字更重要。
第三步：只給必要 tools
Make AI Agents 可以使用 modules、scenarios 與 MCP server tools。這很強，但也意味著權限要收斂。
初期建議只開放：
- 讀取指定資料
- 查詢特定 app
- 呼叫小型內部 scenario
- 輸出分類結果
等流程穩定後，再讓 agent 進一步建立任務、通知團隊或更新系統。
第四步：加入 knowledge
Knowledge 適合放規則與背景資料，例如：
- 產品分類表
- 客服處理規則
- 品牌語氣規範
- 報價條件
- 內部升級 SOP
不要把整個公司雲端硬碟都塞進 knowledge。資料越多，不代表回答越準。真正重要的是資料乾淨、互相不衝突、和任務直接相關。
第五步：看 reasoning 與執行紀錄
Make 強調新版 AI Agents 的透明度。Reasoning 可以幫你理解 agent 做決策的過程。除錯時不要只看最後答案，還要看它是否用了錯的資料、選錯 tool，或在 instructions 中沒有收到足夠限制。
三個實用 Make AI Agents 範例
客服分流 agent
流程：
- 新 ticket 進來
- Agent 讀取 ticket 內容與 FAQ
- 判斷分類、優先級、負責團隊
- Scenario 更新 helpdesk 欄位
- 高風險 ticket 通知 Slack
注意事項：不要讓 agent 自動關閉 ticket。它可以建議回覆，但關閉與退款仍應保留人工確認。
候選人初篩 agent
流程：
- 收到履歷或表單
- Agent 對照職缺條件
- 輸出符合度、風險、需追問問題
- Scenario 寫入 ATS 或 Sheets
- 符合條件才通知招募負責人
注意事項：招募流程要避免偏見與不透明決策。Agent 可以整理資料，但不應作為唯一錄取依據。
市場情報摘要 agent
流程：
- 定期收集指定來源
- Agent 摘要更新與變化
- 對照內部產品或競爭清單
- 產出 Slack 摘要
- 有重大變化時建立任務
注意事項：Agent 摘要應附來源連結。沒有來源的判斷不要進入決策會議。
Make AI Agents 的限制
AI 結果仍然不可完全預測
即使有 instructions 與 knowledge，agent 仍可能誤判。因此 Make 官方也提醒，應選擇你能信任實習生處理的任務，避免敏感資料、高風險財務或嚴格法務要求。
Debug 成本會轉移到流程設計
可視化不代表不用設計。你仍要決定哪些資料能進來、哪些 tools 能使用、什麼情況要人工審核、失敗時如何 fallback。
成本與用量需要觀察
Agent 每次執行可能呼叫模型、讀資料、用 tools。若放在高頻 trigger 上，成本可能比預期高。上線前應先估算執行頻率與每次執行成本。
Make AI Agents 適合誰？
Make AI Agents 適合已經習慣 visual automation、但開始需要 AI 判斷的團隊。它特別適合營運、客服、業務、招募、行銷這些跨工具流程很多的部門。
如果你重視可視化除錯、團隊共享、透明流程，Make 會比單純聊天型 agent 更容易管理。若你需要高度自訂、能自己部署、能寫程式控制細節，n8n 可能更適合。