n8n AI Agent 最容易讓人誤會的地方，是看 demo 時很像什麼都能自動做，真的要放進公司流程時卻開始害怕：它會不會寄錯信？會不會改錯 CRM？會不會把客戶資料送進不該去的地方？出錯時誰負責？
你可能遇到的是這些場景：
- 客服信箱每天進來很多信，你想讓 AI 先分類、摘要、建議回覆，但不想讓它直接代表公司承諾退款。
- 業務表單進來後，你想讓 AI 判斷高意圖客戶、產生跟進草稿，再交給真人確認。
- 團隊文件散在 Notion、Google Drive、內部知識庫，你想做一個能查資料的問答 Agent。
- 你已經把 Agent 接上 Gmail、Slack、CRM，卻開始擔心工具太多、權限太大、行為不可控。
- 你想用 Memory 做連續對話，但不知道哪些資料不該被記住。
所以這篇的重點不是「怎麼讓 AI 自己做更多」，而是：怎麼把 AI Agent 放進受控的 n8n workflow，讓它能幫忙判斷、查資料、產生草稿，同時避免高風險動作失控。
如果你還在學 n8n 基本節點，先看 n8n 節點大全；如果你要從外部系統觸發 Agent，先看 n8n Webhook 教學。
先判斷你的任務適不適合 AI Agent
不是所有自動化都需要 Agent。很多流程用 If、Switch、HTTP Request 就能更穩、更便宜。AI Agent 適合的是「規則不好寫死，但可以被審核」的任務。
| 任務 | 適不適合 Agent | 建議做法 |
|---|---|---|
| 表單高意圖分級 | 適合 | Agent 判斷意圖與理由，CRM 更新前可先人工確認 |
| 客服 ticket 分類與草稿 | 適合 | Agent 分類、摘要、寫草稿，正式回覆前人審 |
| 查內部文件並回答 | 適合 | 限制資料源，要求附來源或引用段落 |
| 固定欄位格式轉換 | 不一定 | 優先用 Edit Fields 或 Code，不用為了 AI 而 AI |
| 付款、退款、刪資料 | 高風險 | 只能產生建議或申請單，不要直接執行 |
| 大量批次寄信 | 高風險 | 先抽樣審核，設定發送上限與錯誤停止條件 |
最小可上線架構：先不要做全自動
第一次做 n8n AI Agent，不要從「AI 自己判斷、自己寄信、自己更新 CRM」開始。比較穩的架構是：
Webhook或Chat Trigger收到任務。Edit Fields把輸入整理成固定欄位，例如customer_message、customer_id、source。AI Agent只負責分類、摘要、查資料、產生草稿。Structured Output Parser要求固定 JSON，例如category、priority、draft_reply、needs_human_review。If判斷是否需要人審。- 低風險結果寫入 Google Sheets、Slack 或 CRM note；高風險結果送給真人確認。
Error Trigger或通知節點負責失敗告警。
這樣做的好處是：AI 有發揮空間，但真正會影響客戶、金錢、資料庫的動作，都還在你設計好的邊界裡。
n8n AI Agent 是什麼？
n8n 的 AI Agent node 是讓模型根據任務選擇工具、取得資訊、產生回答或決定下一步的節點。官方目前的 AI Agent 以 Tools Agent 方式運作，也就是：Agent 會看到可用工具與工具 schema，然後決定要不要呼叫某個工具。
一個實用的 AI Agent workflow 通常包含：
| 元件 | 做什麼 | 實務提醒 |
|---|---|---|
| Trigger | 收到任務或訊息 | Chat Trigger、Webhook、表單、Slack |
| Preprocess | 整理輸入資料 | 清掉雜訊、補 metadata、限制欄位 |
| Chat Model | 讓模型推理 | 看 tool calling、成本、中文能力、穩定性 |
| Tools | Agent 能做的動作 | 查資料、呼叫 workflow、產生草稿 |
| Memory | 保存對話上下文 | 只在需要連續對話時使用 |
| Output Parser | 限制輸出格式 | 正式流程盡量輸出 JSON |
| Human Review | 人工批准高風險工具 | 寄信、改資料、刪資料前要審核 |
| Logging | 留下執行紀錄 | 方便追查 Agent 為什麼做這件事 |
Tools：不要把所有權限都給 Agent
Agent 的能力取決於你給它哪些工具。工具可以是 HTTP Request、Gmail、Google Sheets、Slack、Postgres、HubSpot、Call n8n Workflow 等等。工具越多，Agent 越像真的會做事；但風險也越高。
我的建議是從三層工具開始：
| 工具層級 | 允許做什麼 | 範例 |
|---|---|---|
| Read-only | 只能查資料 | 查 FAQ、查訂單狀態、查 CRM 摘要 |
| Draft-only | 只能產生草稿 | Email 草稿、客服回覆草稿、CRM note 草稿 |
| Human-approved | 要人工批准才執行 | 寄正式信、更新 CRM、建立退款、刪資料 |
最穩的做法是把高風險操作包成子 workflow，再讓 Agent 用 Call n8n Workflow 呼叫，而不是直接給 Agent 資料庫或 CRM 的完整權限。
例如你可以建立三個小工具：
| 工具名稱 | 輸入 | 輸出 | 風險 |
|---|---|---|---|
get_customer_order_status | order_id | 訂單狀態 JSON | 低 |
draft_refund_reply | ticket_id、reason | 回覆草稿 | 中 |
submit_refund_request | order_id、amount | 退款申請結果 | 高，需要人審 |
這樣 Agent 只能在你設計好的邊界裡工作。
Memory：什麼時候該開？
Memory 適合「連續對話」任務，例如：
- 內部文件問答助理。
- 客服對話需要記住上一輪問題。
- 個人助理需要在同一 session 追問細節。
但 Memory 不是越多越好。不要把它當成永久資料庫，也不要把敏感資料、密碼、完整合約、病歷、付款資訊丟進去。
| 場景 | 建議 |
|---|---|
| 單次表單分類 | 不需要 Memory |
| 客服 ticket 摘要 | 通常不需要 Memory，只要傳入 ticket 內容 |
| 文件問答聊天 | 可以開 Memory，但要限制 session 與資料範圍 |
| 內部助理跨天記住偏好 | 要先確認資料保存政策 |
如果只是「把這封信分類」或「把這張表單分級」，不要開 Memory。把當次輸入整理好，讓 Agent 做完一次就結束，反而更穩。
Structured Output：不要讓後續流程吃自由文字
AI Agent 產出的自然語言很好讀，但很難接流程。正式 workflow 應該要求固定 JSON。
例如名單分級可以要求：
{
"intent": "high|medium|low",
"category": "sales|support|partnership|other",
"confidence": 0.82,
"summary": "一句話摘要",
"next_action": "human_review|send_to_sales|nurture"
}後面再用 If 或 Switch 判斷 next_action。這比讓 Agent 回一段「我覺得這個客戶應該…」穩很多。
n8n 的 Tools Agent 支援要求特定輸出格式，並可搭配 output parser。實務上，凡是後續節點要讀取結果，就盡量用固定欄位。
Human Review：哪些工具一定要人審？
官方文件提到，Tools Agent 可以對特定工具加 human review；當 Agent 想使用 gated tool 時，workflow 會暫停並送出批准請求，批准才執行，拒絕就取消。
我會把工具分成三種：
| 動作 | 是否需要人審 | 原因 |
|---|---|---|
| 查 FAQ、查公開文件 | 通常不用 | 只讀、低風險 |
| 產生 Email 草稿 | 建議人工確認 | 語氣、錯誤資訊、客戶關係 |
| 寄正式 Email | 需要 | 對外發送不可輕忽 |
| 更新 CRM 欄位 | 視欄位而定 | lead stage、deal amount 會影響業務流程 |
| 建立退款或付款 | 必須 | 金錢風險 |
| 刪除資料 | 必須 | 不可逆 |
| 呼叫內部系統 API | 視權限而定 | 可能改動正式資料 |
人審不是要拖慢流程，而是把 AI 放在「提出建議」的位置，人負責批准不可逆動作。
實戰案例：客服 ticket AI 分流
流程設計：
Webhook或客服系統節點接收 ticket。Edit Fields (Set)整理ticket_id、subject、message、customer_email。AI Agent分類 ticket，輸出固定 JSON。Switch根據category分流：付款、帳號、Bug、功能建議。- 低風險 ticket 產生回覆草稿。
- 高風險 ticket 送 human review。
- 人審通過後才建立正式 ticket update 或寄信。
Agent prompt 可以這樣設計：
你是客服分流助理。請只根據輸入 ticket 分類，不要編造不存在的資訊。
輸出必須是 JSON，包含 category、priority、confidence、summary、next_action。
如果信心低於 0.75，next_action 必須是 human_review。
你不能直接承諾退款、刪除資料或修改帳號權限。實戰案例：文件問答 Agent
流程設計：
Chat Trigger或Webhook接收問題。- 先用 retriever 或向量資料庫查相關文件。
- 把檢索結果交給 AI Agent 或 LLM chain。
- 要求回答附
sources、confidence。 - 找不到資料時，回覆「目前資料不足」，不要硬答。
- 問題涉及合約、價格、醫療、法律時，轉人工。
這種 Agent 的重點不是回答得很像人，而是回答能追來源、能承認不知道、能把高風險問題交給人。
上線前檢查清單
- 是否只給 Agent 必要工具？
- 是否把高風險工具加 human review？
- 是否要求固定 JSON 輸出？
- 是否限制 max iterations，避免 Agent 反覆嘗試？
- 是否保留 intermediate steps 或足夠 log 方便 debug？
- 是否避免把 API key、密碼、完整個資放進 prompt？
- 是否有 Error Trigger 和失敗通知？
- 是否設計 fallback：低信心時交給人？
常見問題
n8n AI Agent 可以完全自動處理客服嗎？
可以處理分類、摘要、草稿、低風險 FAQ，但不建議一開始就讓它完全自動關單、退款或改帳號。正式流程要分階段開權限。
Memory 一定要開嗎？
不用。單次分類、摘要、表單分級通常不需要 Memory。只有連續對話、追問上下文時才考慮。
可以直接給 Agent HTTP Request 工具嗎？
可以，但要非常小心。比較穩的做法是先把可控 API 操作包成子 workflow，再讓 Agent 呼叫。
Human Review 會不會讓自動化失去意義？
不會。AI 先完成分類、摘要、草稿和資料整理，人只審核關鍵動作，仍然能省掉大量重複時間。
下一步
如果你的 Agent 要被外部系統觸發，先把 n8n Webhook 教學 補起來。如果你要把 Agent 放到正式內部系統，接著看 n8n 自架教學：Cloud、Docker、VPS、Queue mode 怎麼選。