AI Agent 是甚麼？用 n8n 建立可靠工作流：工具、記憶、Guardrails 與平台選型

「Agent 可以理解目標、自主規劃和執行」是一個有用的入門圖像，但若要把它變成可靠系統，還要回答更具體的問題：模型可看見甚麼？可調用哪些工具？每個工具有甚麼權限？狀態保存在哪裏？何時停止？失敗怎樣重試？哪一步必須由人批准？本文把概念落到一個可實作的架構，並以 n8n 作視覺化編排例子。

一句話定義：Agent 是一個受目標、指示和政策約束的執行迴圈；它讀取目前狀態，選擇有限工具，觀察結果，再繼續、求助或停止。它不是擁有無限權限的「全自動員工」。

一、先分清四個層次：模型、工具、工作流與 Agent

OpenAI 現行 Agents SDK 文件把 agent 定義為一個包含模型、instructions，並可選配 tools、guardrails、MCP、handoffs 和 structured outputs 的工作單元。這個定義很重要：工具和限制是設計的一部分，不是模型生成答案後才補上的附加項。

二、Agent 與 deterministic workflow：不要二選一

可靠自動化通常採用「規則外殼＋Agent 判斷核心」。能以程式清楚表達的規則，交給程式；只有需要理解語意、處理例外或選擇工具的部分，才交給模型。

判斷準則很簡單：若同一輸入必須永遠得到同一結果，或錯誤一次便會造成實際損失，優先使用 deterministic code。若輸入語意多變，而且錯誤可被 schema、政策或人工覆核攔截，才考慮 Agent。

三、先定成熟度路線：由單步輔助到受控自治

1. 第 0 級—人工工具：模型只產生草稿，人手複製和執行。
2. 第 1 級—單步增強：workflow 固定調用一次模型，輸出結構化分類或摘要。
3. 第 2 級—工具選擇：Agent 可在少量唯讀工具之間選擇，但不能造成外部副作用。
4. 第 3 級—受控動作：可提出寫入操作；schema、政策和人工批准通過才執行。
5. 第 4 級—有限自治：只在明確範圍、預算、時限和評測門檻內自動運行，並有完整 trace 和停止機制。

每一級都要先取得基線數據，再決定是否升級。若第 1 級的分類仍不穩定，增加工具和循環只會把小錯誤放大。

四、一個可靠 Agent 需要九個部件

五、指示要規範決策，不要假裝提供無限智慧

一份可執行的 instruction 應回答：你負責甚麼；可使用哪些來源；哪種資料較可信；甚麼情況不可猜；何時調用哪個工具；何時要求更多資料；何時交給人；最後輸出哪個 schema。政策要短、具體，而且用正反例說明邊界。

角色：你是客戶查詢分流 Agent，只處理產品使用和訂單狀態。
目標：輸出 category、urgency、language、missing_fields、draft_summary。
可用工具：lookup_order（唯讀）、search_help_center（唯讀）。
規則：
1. 未有 order_id 時不要猜訂單；把 order_id 加入 missing_fields。
2. 不可承諾退款、折扣或送貨日期。
3. 任何付款、健康、安全或法律內容一律標記 human_review。
4. 工具無結果時，保留 unknown；不要把不存在寫成已確認。
5. 最多調用三次工具，之後必須成功、求助或停止。
輸出：嚴格符合指定 JSON schema，不要加入額外文字。

六、工具設計比提示詞更接近真正的權限系統

模型只能「建議」調用工具；真正執行工具的是你的 runtime。工具層要把危險能力切細，例如把 manage_customer 拆成 get_customer、draft_customer_note 和需要批准的 commit_customer_note。不要讓一個通用 HTTP、SQL 或 shell 工具接觸整個環境。

每個工具最少要有

• 精準名稱和描述：何時用、何時不要用。
• 嚴格 schema：enum、長度、格式、必填欄和未知值。
• 最小權限：唯讀與寫入分開；服務帳戶只可接觸必要資料。
• 冪等鍵：重試不會重複發信、扣款或建立記錄。
• 逾時與錯誤碼：讓 workflow 分辨可重試、不可重試和要人工處理。
• 輸出最小化：只把下一步所需欄位送回模型，避免整份客戶記錄進入 context。
• 審計資料：run ID、工具版本、參數摘要、結果和批准人。

七、狀態不等於記憶：分開四個資料層

OpenAI Agents SDK 文件特別區分 conversation history 與 run context：前者是模型看見的內容，後者是程式看見的依賴和狀態。n8n 的入門教學亦把 memory 作為額外連接加入 Agent node；這不代表應把所有資料都保存為聊天記憶。

八、Agent loop 要有狀態機和可證明的完成條件

不要用一句「直到完成為止」作 loop。建立有限狀態，例如 RECEIVED → VALIDATED → NEEDS_CONTEXT → PROPOSED → AWAITING_APPROVAL → EXECUTED → VERIFIED，並為每個轉移寫明前置條件。

必要退出條件

• 成功：有外部證據確認結果，而不是 Agent 自稱完成。
• 需要資料：列出缺少欄位，停止工具調用並詢問使用者。
• 需要批准：保存可恢復狀態，展示具體動作和參數。
• 安全拒絕：輸入違反政策或要求超出授權。
• 工具失敗：達到重試上限後進入人工 queue。
• 逾時／預算：達到最大步數、token、API 成本或 wall time。
• 低信心：分類或抽取未達門檻，不以猜測補齊。

成功也要可驗證。例如「已寄出」應由電郵服務回傳 message ID；「CRM 已更新」應再讀取目標記錄或檢查版本；「沒有重複」應由 idempotency key 和唯一約束保證。

九、Guardrails 與人工批准要放在正確邊界

OpenAI 文件把控制分成 input、output、tool guardrails，以及 human-in-the-loop approvals。它們不是同一件事：guardrail 是自動檢查；批准是把 run 暫停，等待人或政策批准／拒絕，再從同一狀態恢復。

批准不是橡皮圖章：畫面要顯示將要做甚麼、影響誰、使用哪個帳戶、關鍵參數、預期成本及能否回復。批准要綁定該次 payload；payload 改變便要重新批准。

十、n8n 在這個架構扮演甚麼角色？

n8n 是 workflow orchestration 平台，也提供 AI Agent node。官方文件指出，目前 AI Agent node 以 Tools Agent 運作，而且至少要連接一個 tool sub-node。這正好說明 Agent 和普通模型節點的差別：Agent 能在受限工具之間選擇動作，而整條 workflow 仍可用普通節點控制觸發、驗證、分支、批准、重試和輸出。

授權名稱要說準確

n8n 的主要原始碼可見，但官方明確不把自己稱為 OSI 意義的 open source；它採用 Sustainable Use License 和 Enterprise License，並以 fair-code／source-available 描述。該授權一般容許內部商業、個人和非商業使用，但對白標轉售、收費提供平台存取等用途有限制。若產品價值主要來自把 n8n 功能提供給客戶，應先讀現行授權並向法律或 n8n 查詢。

自託管代表控制，也代表責任

官方 hosting 文件指出，自託管在沒有 license key 時運行 Community edition；加入其他 license 才啟用相應版本。自託管可讓你選擇網絡和資料邊界，但你亦要負責 TLS、database、encryption key、憑證、備份、升級、worker、queue、監察、容量、事故和復原。若團隊未準備好做這些工作，managed cloud 可能有較低總風險。

十一、比較 n8n、Coze 或其他平台：用同一張需求表

Coze 官方條款和開發者文件顯示平台可用來建立 bot／software，並提供 API、插件和 token 相關服務；但功能、方案、地區、配額和價格會改變。本文不把舊影片中的數字當作現行事實，也不宣稱任何平台一定勝出。

簡單加權方法

先按場景給每個維度 1–5 權重，再用同一個 prototype 為候選平台評 1–5 分。總分只作討論起點；任何硬性要求，例如指定資料地域、必須自託管或必須有人工批准，應先作 pass／fail gate，不能由其他高分抵銷。

十二、觸發與生態：先驗證必要連接，不要比較總數

n8n 官方文件確認 Webhook node 可接收事件並啟動 workflow，也可在完成後返回結果；Schedule Trigger 可按固定時間、間隔或 cron 執行。這些是可直接引用的現行能力。至於「有多少整合」並不能直接代表適用：一個沒有你所需權限、缺少必要 operation 或無法在你的地域使用的 connector，數量再多也沒有價值。

每個外部連接都要測六件事

1. 認證方式和最小 scope。
2. 讀、寫、更新、刪除是否分開授權。
3. rate limit、timeout、pagination 和 payload 上限。
4. 重試會否產生重複副作用。
5. 錯誤是否有穩定 code，可否進入人工 queue。
6. 日誌會否記錄 token、個人資料或完整 payload。

十三、第一個專案藍圖：客戶查詢分流與回覆草稿

這個專案有真實價值，但不會讓 Agent 自動退款或直接發信，適合作為第一個受控 prototype。

十四、在 n8n 實作：由外向內逐層收窄

1. 建立測試 Webhook：先用 test URL；正式發布 workflow 後才改用 production URL。加入 header 或 JWT auth，並限制來源。
2. 固定驗證：用普通節點檢查 request_id、message、locale 和大小；非法輸入立即結束。
3. 建立 structured output：只容許預先定義 category；未知便輸出 other，不要自由創造標籤。
4. 加入 AI Agent node：連接 chat model 和最少量唯讀工具；system message 寫清楚目標、禁止事項和 tool budget。
5. 把寫入拆開：Agent 只產生 proposed_action；普通 workflow 驗證後進入人工批准。
6. 保存狀態：以 request ID 和 idempotency key 關聯輸入、工具調用、批准與最終結果。
7. 錯誤分流：429／timeout 可指數退避；驗證錯誤不可重試；未知故障進人工 queue。
8. 加入觀察資料：記錄節點時間、模型用量、工具次數、分類、批准和錯誤，但遮蔽 secret 和敏感內容。
9. 先以 draft 模式上線：至少收集一段時間的人工改寫和錯誤資料，才考慮自動提交低風險類別。

n8n 安全提醒：Webhook 官方文件支援 Basic、Header、JWT 或無認證，也提供 IP whitelist 等選項。正式 endpoint 不應沿用無認證預設；同時要檢查 CORS、payload 上限、回應內容和日誌。

十五、評測：不是問「看起來聰明嗎」

OpenAI 的 agent evals 文件建議先看 trace，再把已知良好行為整理成可重複 dataset 和 eval runs。Trace 應包含模型調用、工具調用、guardrails、handoffs 和最終結果，讓你知道錯在分類、工具、資料、政策還是 orchestration。

測試集至少包括

• 常見正常案例和不同寫法。
• 缺欄、矛盾、拼錯、混合語言和極長輸入。
• 工具沒有結果、回傳部分資料、429、timeout 和 500。
• 外部內容內含惡意指令或要求洩露資料。
• 要求付款、退款、刪除、改權限或跨 tenant 存取。
• 重複 webhook、重播舊 request、批准後 payload 被更改。

十六、成本、託管與營運：計算完整單位經濟

用實際 prototype 跑 100 次，再按正常、長輸入、工具失敗和人工批准分組。平均成本會掩蓋最貴的 p95；亦要量度每個成功任務，而不是每次模型調用。若 Agent 經常重試或需要大量人工改寫，看似便宜的單次 API 價格可能沒有意義。

十七、上線前檢查表

• 目標、範圍和禁止事項有文件，且可以用測試驗證。
• 規則步驟沒有不必要地交給模型。
• 每個工具有 schema、最小權限、逾時、錯誤碼和 idempotency。
• 模型看不到不需要的密鑰、整份資料庫或跨 tenant 資料。
• 成功由外部結果驗證；失敗、求助、批准、逾時和預算都有退出路徑。
• 副作用工具在 payload 層做人工批准；批准後 payload 不可被靜默修改。
• 有去識別 logs／traces、告警、保存期和刪除政策。
• 正常、邊界、惡意、工具故障和重播測試均通過。
• 模型、prompt、workflow 和 tool 版本可追蹤及回復。
• 託管、license、資料地域、DPA 和第三方條款已由負責人確認。

十八、可直接複製的 Agent Workflow 規格模板

# 1. 業務目標
使用者：
成功結果：
不包含範圍：
風險等級：

# 2. 輸入與資料
觸發方式：
必要欄位與 schema：
敏感資料：
可信來源優先次序：
保存期與刪除：

# 3. Deterministic workflow
固定驗證：
固定計算：
固定路由：
錯誤與重試：

# 4. Agent
目標：
Instructions：
Structured output：
可用工具：
最大步數／時間／成本：
不可猜測事項：

# 5. Tools
每個工具的 schema、權限、timeout、錯誤碼、冪等鍵和審計資料。

# 6. State 與 memory
Run state：
Conversation context：
Business memory：
只屬 runtime 的依賴／密鑰：

# 7. Controls
Input／output／tool guardrails：
需要人工批准的工具和參數：
Approval payload 與恢復方式：

# 8. Exit conditions
成功：
需要更多資料：
需要人工：
拒絕：
工具失敗：
逾時／預算超限：

# 9. Observability 與 evals
Trace 欄位：
測試資料集：
指標與門檻：
告警：
版本與 rollback：

# 10. 上線策略
Shadow → Draft → Approved action → Limited automation
每一階段的升級條件和停機條件：

Agent 的價值，不是把每一步變得不可預測；而是把確實需要語意判斷的部分，放進一個有工具邊界、狀態、退出條件、人工批准和評測的系統。n8n、Coze 或任何其他平台都只是實作載體。先把控制面和驗收寫清楚，再選最符合資料、營運和團隊條件的平台，才是可持續的自動化方法。