# 目錄
## 1. 課程介紹與 n8n 基礎
* Introduction and Course Overview
* Foundations of n8n: Nodes, Architecture, and Data Types

---

## 2. 第一個 AI Agent Workflow

* Building Your First AI Agent Workflow (Chatbot / Email Agent Demo)

---

## 3. 實驗環境與雲端設定

* Free Labs Access and CodeCloud Keyspace API Setup
* n8n Cloud vs. Lab Playground Differences (API / Google Auth Setup)

---

## 4. API 與驗證最佳實務

* Authentication Best Practices for HTTP Request Node
* Google Drive / Sheets / Docs Authentication Setup via Google Cloud Console
* Slack API Setup and Integration

---

## 5. HTTP Request Node 實戰應用

* HTTP Request Node and API Call Scenarios
* Cat Facts
* Weather
* Web Scraper

---

## 6. AI 影音生成 Workflow

* Text-to-Image Workflow with AI Prompt Generation
* Text-to-Video Workflow with AI Prompt Generation
* Image-to-Video Workflow with Google Drive and Telegram Integration
* Vertex AI (Google V3) Integration for Text-to-Video

---

## 7. n8n 架構進階與部署選擇

* n8n Cloud vs. Self-Hosted n8n (Docker / AWS EC2)
* Multi-Workflow Orchestration with Subworkflows

---

## 8. 課程總結

* Course Conclusion and Next Steps

---
# 1. 課程介紹與 n8n 基礎
## 課程定位與目標（n8n Zero to Hero）

* n8n 是開源自動化平台，可整合 API、編排智慧工作流程，降低大量自訂程式碼需求
* 課程宣稱從基礎到進階，涵蓋節點架構、部署、資料流處理與 AI 整合
* 目標受眾包含 DevOps、AI 相關角色與想做流程自動化的非技術背景使用者

## 課程大綱總覽


* 入門：認識 n8n、環境（playground）、專案結構與學習目標
* 基礎：節點（nodes）、輸入輸出、資料型別、工作流程在底層如何執行
* AI 整合前置：設定 OpenAI、Anthropic 等服務的 API keys
* 實作：Email AI agent、自動研究工作流（多工具）、HTTP Request、web scraping、資料抓取
* 多模態：文字轉圖、文字轉影片、圖轉影片等流程整合
* 協作工具：Slack 工作流讓 AI 代回覆訊息
* 選修部署：Docker 自架、Ollama 本機 LLM、AWS EC2 託管
* RAG：向量資料庫（如 Pinecone）、客服型 RAG agent、文件記憶與檢索
* MCP 與可重用性：比較 MCP 與傳統工作流，強調可擴展與可重用
* 進階編排：多工作流、多代理整合、subflows 管理複雜度
* 維運：重試、錯誤處理、最佳實務、模板市集加速開發

## n8n 的核心概念：節點與工作流程

* n8n 以節點串接的視覺化方式建立自動化流程

* 流程由 Trigger node 開始（如新郵件、Webhook 被呼叫）
* 後續接 Action nodes 執行工作（寄信、呼叫 LLM、呼叫 API）
* 節點之間會自動傳遞資料，形成完整資料流

## AI agent 在 n8n 的基本構成

* LLM：作為 agent 的「大腦」（OpenAI、Claude、Llama 等）
* Memory / Context window：提供對話或流程上下文，影響有無狀態的回應
* Tools：可供 agent 呼叫的外部能力（Gmail、web scraper、各種 API 工具）
* agent 接收輸入後判斷是否需要呼叫工具，再回傳輸出給後續節點或回覆端

## 工作流程的執行邏輯與分支

* 預設順序執行：從 trigger 依連線往下跑，任一節點失敗可能導致整體 error
* 工具型節點的使用是「由 agent 決定是否呼叫」，不一定每次都會用到


* 可做分支：同一個輸入可分流到多個路徑，例如同時發 Slack 與寄 Gmail
* 分支在示例中通常依序跑完各分支，達到一個觸發帶出多個動作

## 記憶體系：短期 Context 與長期 RAG

* Context memory：放在 prompt 內的短期記憶，用於對話歷史與保持上下文
* 長期記憶（RAG）：文件或資料存進向量資料庫，以 embedding 方式檢索相關片段
* Context 偏向連續性與狀態維持，RAG 偏向規模化與回答準確度

## 節點輸入輸出與資料呈現方式

* 每個節點都有 input 與 output，上一節點 output 就是下一節點 input
* 在面板可看到資料如何在流程中流動，方便除錯與理解


* 同一份資料可用不同視圖呈現：schema、table、JSON
* 有時也會看到 binary（檔案、圖片）等非純文字資料

## Expressions 與動態資料綁定

* 節點欄位可填固定值（static）或用 expression 引用前面節點的動態資料
* expression 讓流程能依即時輸入變化，不需硬編碼
* 介面支援拖拉變數到欄位，降低綁定資料的門檻

## 基礎資料型別（n8n 常見）

* String：文字資料
* Number：數值
* Boolean：true/false
* Array：列表
* Object：結構化資料（可巢狀），常用點路徑與 expression 取值

## 社群節點（Community nodes）

* 除官方節點外，社群也提供額外 connector 擴充整合範圍
* 若找不到內建整合，常可先在社群節點尋找是否已有可用的擴充

---

# 2. 第一個 AI Agent Workflow

## 建立工作流程的第一步：加入 Trigger

* 進入 workflow 後先新增 Trigger node 作為整個流程的啟動點
* 點右上角加號選擇 Trigger 類型
* 範例使用「On Chat Message」觸發器


* 在觸發器出現的終端輸入訊息（例如 hello）以產生測試資料
* 觸發器節點可用閃電圖示辨識

## Chat Message Trigger 的輸出資料內容

* Trigger 節點只有輸出資料沒有輸入資料
* 輸出底層格式是 JSON

* 常見欄位包含 session ID、action（例如 send message）、chat input content（例如 hello）
* 可切換檢視成 JSON、Table、Schema


* Schema 檢視方便拖拉欄位到下一個節點

## 加入 AI Agent 節點並接收 Trigger 輸出

* 新增 AI Agent node 並接到 chat trigger 後會自動把上一節點輸出帶入為輸入
* User Message 通常以 JSON chat input 作為來源並以 expression 表達式表示
* 每次執行會依 chat input 的內容變動

## AI Agent 的三個核心組成：LLM、Memory、Tool

* LLM 是 AI agent 的核心模型，用來生成回應與推理
* Memory 用於保留對話上下文，讓模型能記住前幾輪訊息
* Tool 讓 AI agent 能執行外部動作，例如透過 Gmail 寄信

## 連接 OpenAI Chat Model 與建立憑證

* 在 AI agent 加入 OpenAI chat model


* 透過下拉選單建立新 credential，填入 OpenAI API key
* 儲存後即可選擇模型清單中的 GPT 模型
* 範例選 GPT-4 mini 作為模型

## 沒有 Memory 與有 Memory 的差異示範

* 不加 Memory 時，模型可能無法記住前一輪剛提供的資訊
* 範例先輸入「hello, my name is Mark」後再問「What is my name?」會回覆無法得知


* 加上 Simple Memory 後再做同樣測試，模型可正確回答「你的名字是 Mark」


* Simple Memory 可設定 context window length（範例為 5）表示保留最近幾次互動

## 加入 Gmail Tool 讓 AI Agent 具備寄信能力

* 在 AI agent 加入 Gmail tool，設定成 message resource 與 send operation


* Gmail tool 需要建立/選擇 Google 帳號憑證


* Recipient、Subject、Message 可設為由模型決定，讓 AI 從自然語言指令抽取資訊
* Email type 範例使用 text，HTML 適合需要排版與圖片的郵件

## Fixed 與 Expression 的差異

* Fixed 代表固定文字，每次執行都會用同一段內容


* Expression 代表動態變數，會依輸入資料改變
* 若要讓 AI agent 接收每次不同的聊天輸入，應使用 Expression 並引用 chat input 欄位

## 設定 System Message 控制 AI 行為

* 在 AI agent 的 Options 新增 system message
* system message 用來定義模型角色與行為規則
* 範例內容是把 AI 定義成協助撰寫精簡有效郵件並在需要時使用 Gmail tool

## 寄信互動流程示範

* 使用者提出寄信需求，模型先補問缺少的 subject 與 body
* 使用者要求模型自行產生內容後，模型提供草稿
* 使用者再提供補充資訊（例如收件者稱呼）後，模型更新草稿
* 使用者確認後，模型才會真的呼叫 Gmail tool 發送郵件

## 移除 Gmail 自動附加的 Attribution

* 發送後郵件尾端可能出現「this email was sent automatically by n8n」類似字樣
* 在 Gmail node 的 Options 找到 append/edit attribution 並關閉
* 關閉後再次發送就不會自動附加該段文字

## 節點常用操作：Execute、Deactivate、Delete、Pin

* Execute step 可單獨執行某一節點，不必重跑整條 workflow
* Deactivate 可停用節點使流程不經過該節點
* Delete 可刪除節點


* Pin data 可固定該節點的輸入/輸出資料用於反覆測試，避免重複跑到會花費成本的步驟

## 啟用工作流程與 Production Chat URL

* 切換 Activate workflow 後 workflow 進入上線狀態
* 上線後不必按 execute workflow，收到訊息就會自動觸發
* 會提供 production chat URL 作為正式呼叫入口

## 讓聊天介面公開並提供 URL

* 在 chat trigger 節點開啟 make chat publicly available
* 系統會產生可公開存取的 URL，外部使用者可用該頁面對話
* 可設定是否需要認證與自訂初始訊息

## 執行紀錄與 Copy to Editor 的除錯方式

* Executions 頁面可查看每次執行的時間與類型
* 測試執行通常以特定圖示標記，正式上線後會以不同類型顯示
* 可用 copy to editor 把某次 production 執行的資料帶回編輯器畫面協助排查問題
* 編輯器中可看到當次 chat input 與 AI agent response 的實際資料內容

---

# 3. 實驗環境與雲端設定
## 瀏覽器內免費 Labs 的定位與形式

* 課程提供可直接在瀏覽器使用的免費 labs，不需要自行安裝環境
* 不要求填信用卡即可開始
* labs 以挑戰題為主：給任務、要求學員自行完成
* 後續 labs 會在 n8n 環境中動手打造 AI agents

## 為 Labs 取得 LLM API Key 的方式與問題背景

* 使用 AI agent 需要能呼叫 LLM，因此必須準備 API key
* 直接向 OpenAI 申請或用 OpenRouter 等平台可取得 key，但常需要先提供付款資訊
* CodeCloud 提供「Code Key」作為替代：在自家 AI playground 取得多家模型 API key


* 示範提到可用模型包含 GPT-4o、GPT-4.1、Gemini 2.5、Grok 3 等（以錄製當下為準）


* Code Key 依不同訂閱方案提供不同程度的可用權限

## Code Key Playground：取得 Base URL 與 API Key

* 進入指定頁面後啟動 playground，進入 dashboard
* 在 dashboard 可選模型與呼叫方式，並取得對應的 base URL 與 API key
* 這兩個值會被拿來設定 n8n 的模型憑證

## 在 n8n 透過 Code Key 呼叫 GPT-4.1：方式一（OpenAI 節點）

* 建立簡單流程：Chat trigger → OpenAI message/model 節點


* 建立新憑證時要替換 base URL 為 Code Key 提供的 base URL
* API key 使用 Code Key 提供的 key
* UI 可能出現紅色警示條，原因是介面原本不是設計來手動替換 base URL


* 模型必須用「By ID」手動填入，例如 openai/gpt-4.1，不能靠清單載入

## 在 n8n 透過 Code Key 呼叫 GPT-4.1：方式二（HTTP Request 節點）

* 使用 HTTP Request node 以 POST 呼叫 Code Key 的 API endpoint


* 從文件複製 cURL 指令並用「Import curl」匯入

* cURL 內已包含 endpoint 與驗證資訊（示範先用整段貼上）


* JSON body 內有預設的 user prompt，可替換成流程輸入變數（例如 chat trigger 的文字）

## Code Key 與 OpenAI 原生 API Key 的差異（模型選擇）

* 使用 Code Key 時，模型清單在 UI 可能無法正確載入或不對應，需要改用 By ID
* 使用 OpenAI 原生 API key 時，base URL 不用改，模型可直接從清單選擇並正常運作
* 示範對比流程：建立 OpenAI 原生 key 後，選 GPT-4.1 可直接跑通

## Lab Playground 與 n8n Cloud：登入與介面流程差異

* Lab 進入時仍要填 email、姓名、密碼，但示範強調不需記住、每次可用不同資料
* 會出現 onboarding 問題與付費功能介紹，可略過
* 進到介面後可「Start from scratch」開始建立第一個 email AI agent

## Lab 內使用 Google 工具的差異：需要自行做 OAuth 設定

* 在 n8n Cloud 有時可直接用「Sign in with Google」快速建立 Gmail 憑證（視瀏覽器與環境）
* 在 labs 中建立 Gmail/Google 工具憑證時，示範強調需要走 OAuth 流程自行設定


* 必須到 Google Cloud Console 建立 project，並啟用對應 API（示例為 Gmail API）
* 需要設定 OAuth consent screen（含 app name、支援信箱、external、聯絡信箱）
* 需加入 test user（用來實際發信的帳號）
* 建立 OAuth client（Web application）並填入 lab 提供的 redirect URL
* 把 client ID / client secret 回填到 n8n 憑證後，使用 Google 登入並授權
* 授權頁會顯示「未驗證 app」，示範做法是自行確認後繼續授權

## Gmail 實測：用 AI agent 透過工具寄信

* 流程可用聊天指令要求 agent 寄信（示例為寄出簡單問候信）
* 執行後可在 Gmail 收到對應信件，代表工具串接成功
* 示範提到未特別設 system prompt，因此行為較簡單，重點在驗證流程可跑通

## 環境差異的提醒範圍

* self-host、lab-host、n8n cloud 之間可能在功能支援上有差異
* 差異可能包含 community nodes 可用性、版本支援與部分功能開關
* 出現問題不一定是限制，可能只是環境差異導致需要不同作法

---

# 4. API 與驗證最佳實務


## HTTP Request 節點的驗證方式概覽

* HTTP Request node 可快速重現 API 呼叫，特別適合從 API 文件用「Import cURL」直接匯入
* 匯入 cURL 後通常會自動把驗證資訊填到 Headers（常見是 Authorization 與 API key 格式）
* 多數 API 呼叫屬於 Header-based authentication

## 直接寫 Header 與使用 Credential 的差異

* 直接在參數或 Headers 填 API key 可用，但容易變成把 key 硬寫在節點設定裡


* 用 Credential（例如 Header Auth credential）是把驗證資訊抽離成可重用的憑證設定

## 使用 Credential 的兩個主要理由

* 方便重用：建立一次憑證後，後續節點或其他 workflow 可以直接從清單選取，不用每個節點重設
* 安全性較好：避免把 API key 硬寫在 workflow 節點參數中，分享專案給多人時較符合最佳實務

## Credential 的管理位置與好處

* 憑證會集中存放在 Credential tab
* 可在同一處查看、刪除、或重新設定既有憑證

# Google Cloud Console

## Google Cloud Console 與 n8n 的串接目標

* 目標是把 Google 服務（Drive、Gmail、Sheets、Docs 等）一次串好，後續不用每個節點重複設定
* 以 Google Drive node 示範，因為流程與其他 Google nodes 很類似
* 串好一次後，其他 Google 服務多半只需要在 Cloud Console 另外啟用對應 API

## 建立 Google 專案與 OAuth Consent Screen

* 進入 Google Cloud Console，建立新 project
* 到 APIs & Services 設定 OAuth consent screen

* 設定 app information（app 名稱、支援信箱）
* Audience 選 internal 或 external（internal 需 Google Workspace）
* 填寫 contact information 並建立

## 建立 OAuth Client 與取得 Client ID/Secret

* 建立 OAuth client（Application type 選 Web application）
* 從 n8n credential 視窗複製 redirect URL，回填到 Google Console 的 authorized redirect URIs
* 建立後取得 client ID 與 client secret，貼回 n8n 的 credential 欄位

## 需要補做的 Console 設定

* 到 Branding → Authorized domains 加入 n8n.cloud（示範用的網域）
* 到 APIs & Services 搜尋並啟用 Google Drive API（示範先啟用 Drive）
* 到 Audience 將 app 發佈（publish）

## 在 n8n 完成 Google 授權與測試 Drive 觸發

* 在 n8n credential 點「Sign in with Google」完成登入與授權
* 可能出現「Google hasn’t verified this app」提示，示範情境下因為是自己建立的 app 所以繼續
* 授權時勾選需要的權限後完成連線，n8n 顯示 Connection successful
* 連線後可在 Drive node 看到資料夾清單並選取
* 測試 watch trigger：先 fetch test event，若沒資料會顯示目前條件無資料
* 上傳一個檔案到指定資料夾後再測試，可成功抓到上傳檔案的事件資料

## 其他 Google Nodes 的啟用方式

* 要用 Google Sheets / Docs 等，只要回到 Cloud Console 搜尋並啟用對應 API（例如 Google Sheets API）
* 啟用後回 n8n 使用對應節點即可沿用同一套 OAuth 連線

# Workflow 2：Multi-Agent Research Workflow with Perplexity & OpenAI

## AI 研究新聞 Workflow 的目標與結構

* 目標：每日抓最新 AI 新聞寄信，並把標題記錄到 Google Sheet，隔天避免重複
* 流程概念：排程觸發 → Perplexity 搜尋 → 檢查/比對既有標題 → Gmail 寄出摘要 → 寫入新標題到 Sheet

## Scheduled Trigger 設定重點

* 使用 Scheduled Trigger node，每天固定時間觸發（示例 9:00）
* 間隔設為每天一次、分鐘設為 0
* 先 execute step 產生測試資料以便後續節點引用

## 使用 Perplexity 節點的原因與憑證建立

* Perplexity 有原生 node，可直接使用，省去自己手刻 HTTP Request 呼叫 API


* 建立 credential 只需貼入 Perplexity API key


* 取得 API key：到 Perplexity 帳號 settings → API keys 建立
* 需要先開 API billing，示範提到至少儲值 5 美元才能啟用 key

## Perplexity 模型選擇與輸出取向

* 示範選用 Sonar Pro 以取得「最新標題/摘要」的適中輸出
* Deep Research / Reasoning 類型適合更長、更深入的研究，但此例不需要

## Perplexity 的訊息順序規則

* Perplexity node 要求 system message 必須放在 user message 之前
* 需要調整訊息順序：system 先、user 後

## System Prompt 的角色設定

* 定義為 AI 研究分析師，負責追蹤並摘要最新 AI 發展
* 聚焦新模型發布、研究突破、以及主要 AI 公司策略動態

## User Prompt 的關鍵約束與防幻覺設計

* 指定搜尋範圍為最近 24 小時
* 把「今天日期」用 workflow 內建變數動態帶入，避免模型誤判日期而抓到過舊新聞
* 指定優先關注的組織（如 OpenAI、Anthropic、Google、Meta、Mistral、xAI、Hugging Face 等）以加強方向性

## Perplexity 的 Recency Filter 設定

* 使用 Perplexity 提供的 recency filter，限制搜尋在「day」等級的最新範圍

## 節點測試與 Pin Data 的成本控制

* Perplexity 輸出包含 citations、搜尋結果與自然語言摘要內容
* 為避免重複測試耗用 API token，示範會把 Scheduled Trigger 與 Perplexity 節點的輸出 pin 起來

---

## 加入 Formatter／Checking Agent 的目的

* 在 Perplexity 產生每日 AI 新聞後，再用 OpenAI 節點做「去重＋格式化」
* 主要避免同一則大新聞在不同天或同一天被重複報導而反覆寄出
* 透過比對 Google Sheets 的歷史新聞紀錄（news log）來移除重複項目

## OpenAI 節點設定重點

* Perplexity 節點輸出會成為 OpenAI 節點輸入
* Resource 選 text，Operation 選 message and model
* 模型可選 GPT-4 等級作為檢查與整理用途
* 將節點重新命名為 news checking agent 方便辨識

## User Prompt 的內容結構

* 先貼入「Perplexity 今日新聞清單」作為原始輸入內容
* 要求交叉比對 past AI news log sheet 並移除重複新聞
* 要求每則新聞提供 1–2 句精簡摘要
* 每則摘要後附上完整來源 URL
* 使用粗體標示公司名稱或重大更新
* 每則新聞之間留空行提升可讀性
* 若 Perplexity 全部都是重複，回覆「過去 24 小時無重大 AI 新進展」類似訊息

## System Prompt 的用途

* 定義角色為 AI news formatter，負責處理、檢查、清理 Perplexity 結果
* 明確要求在需要時使用 Google Sheet 工具查 past AI news log 以避免重複

## 在 Checking Agent 加入 Google Sheets Tool

* Tool description 設為 automatically，讓模型自行決定何時呼叫
* Resource 指向 sheet within document
* Operation 選 get rows，用來讀取歷史紀錄而不是修改
* 在 Google Sheets tool 選取文件與工作表（例如 past AI news log → Sheet1）
* 將工具重新命名成 past AI news log，讓提示詞中的工具名稱能對上

## 建立 Past AI News Log 試算表結構

* 建立一份 Google Sheet 文件命名為 past AI news log
* 欄位設計為兩欄：date、headlines
* date 記錄日期，headlines 記錄當日新聞摘要內容（或整理後內容）

## Checking Agent 產出格式化結果

* 節點執行時會先讀取 news log（若為空則不會去除任何項目）
* 輸出為已清理、已格式化的新聞清單
* 可在提示中加入規則要求「純文字輸出」與固定開頭句式
* 例：開頭加上「Here’s today’s AI development news. Today is {{today}}」

## 為何 Gmail 用「後續節點」而不是「AI Tool」

* Gmail 作為 AI agent 的 tool：模型可自由決定用不用，可能誤用或漏用
* Gmail 作為 workflow 後續節點：每次 workflow 跑到該節點就一定會寄信
* 適合每日固定寄送摘要的場景，確保行為穩定可預期

## Gmail 節點設定方式

* 操作選 send message
* 收件者固定填同一個 email（每日寄送）
* Subject 固定填 daily AI news digest
* Email type 選 text
* Message 欄位拖入 checking agent 的輸出 content

## 關閉 Gmail Attribution

* Gmail 節點 Options 中找到 append attribution 並關閉
* 避免信件尾端出現「sent automatically by n8n」類似字樣

## 把今日新聞寫回 News Log 的原因

* 讓隔天 checking agent 有資料可比對，避免重複寄送同一批新聞
* 每天跑完一次就把當日結果追加到 log，累積成歷史資料庫

## 新增 Google Sheets「Append row in sheet」寫入 Log

* 新增 Google Sheets 節點，操作選 append row in sheet
* Document 選 past AI news log（也可用 ID/URL 綁定）
* Sheet 選 Sheet1
* date 欄位拖入 today 變數
* headlines 欄位拖入 news checking agent 的 content 輸出
* 執行後會寫入下一個空白列，逐日累積紀錄

---

## 每日 AI 新聞流程的「避免重複」機制

* Perplexity 研究代理每天搜尋最新 AI 新聞
* 另一個新聞檢查代理會把新抓到的標題與 Google Sheet 既有紀錄比對
* 只把未出現過的標題送去 Gmail
* 每天寄出後再把當天標題寫回 Google Sheet，供隔天比對

## 流程可替換的元件

* Perplexity 只是搜尋工具選項之一，可換成其他搜尋或 LLM 服務
* OpenAI/Chat Model 可替換成其他模型供應商
* 通知管道不一定要 Gmail，可改成 Telegram、Slack 等常用平台

# Workflow 8：Fun Slack use case - Let AI do your job

## Slack 讓 AI 代回覆的前置：OAuth 權限調整

* 需要在 Slack API 調整 OAuth scopes 才能「以使用者身分」回覆


* 除了 bot token scopes，還要到 user token scopes 增加必要權限
* 依使用情境加入讀取頻道、群組、私訊等訊息歷史與讀取權限


* 需要新增 chat.write.customize 以允許用指定身分送出訊息
* scopes 更新後需要重新安裝 app（reinstall）讓權限生效

* 取得 user OAuth token，回到 n8n 建立新的 Slack credential 並貼上 token

## Slack Event Subscriptions 設定

* 開啟「代表使用者訂閱事件」的事件訂閱
* 加入事件類型以涵蓋常見場景：message.channels、message.groups、message.im、message.mpim
* 文件可查各事件與權限的對應關係

## n8n Slack Trigger 的改法

* 觸發事件從「bot/app mention」改成「任何事件」以捕捉私訊與更多互動
* 開啟監看整個 workspace，讓任意訊息都能觸發 workflow
* 設定忽略自己的訊息，避免自己回覆又觸發造成迴圈


* 取得自己的 Slack member ID：從個人檔案選單複製 member ID，貼到 ignore 欄位

## 測試用 Workspace 與帳號安排

* 建立一個測試 workspace
* 準備兩個帳號：一個當自己、一個當同事，用來測 direct message 的觸發與回覆

## AI Agent 的系統訊息與模型選擇

* 在 agent 加入 system message，描述要以某個身分回覆、語氣自然友善、符合職場對話


* 切換 chat model（示範改成 GPT-5）以提升處理複雜問題與工具使用的表現
* 保留 simple memory 以維持對話上下文

## Slack Send Message 節點的兩個關鍵改動

* channel ID 改成動態值，才能回覆到實際觸發來源（頻道/群組/私訊）
* 啟用 send as user，並填入自己的 username，讓訊息看起來像本人發出

## 實際觸發與回覆示範行為

* workflow 進入等待事件狀態後，從另一帳號傳訊即可觸發
* agent 會生成回覆並送回 Slack
* 回覆可能帶入工作情境或自行加料，代表 system prompt 仍可再收斂

## 為回覆補上下文：加入簡單 RAG

* 新增一個 Google Docs 節點作為工具（get operation）讀取專案狀態文件


* 在 system prompt 加上規則：被問到專案更新時使用 Google doc 工具


* 當對方問專案進度，agent 會先讀文件再回覆，能引用文件內的進度與 ETA
* 回覆資訊可正確但語氣仍偏機械，需再用 prompt 調整表達方式

## 這類 Slack + RAG 的可用場景

* 可做內部 FAQ、技術支援、HR/法務/行銷/客服等知識回覆型機器人
* 重點在於熟悉 Slack 權限、事件訂閱、動態回覆通道、以及工具取用知識的流程

---
# Slack Setup Intro

## Slack 觸發：On bot app mention
* 在 n8n 選 Slack 觸發器並用「On bot app mention」


* 建立/重建 Slack 憑證，命名後貼入 key 並儲存
* 看到 Connection tested successfully 代表連線成功

## Slack App 設定：Event Subscriptions 與 Request URL

* 到 Slack App 的 API 設定頁進入 Event Subscriptions
* 將 Event Subscriptions 切換為 On
* Request URL 從 n8n 的 webhook URLs 取得


* 測試階段用 Test URL，正式上線用 Production URL

## Challenge 驗證失敗的原因與處理

* 貼上 Request URL 後若出現「URL didn’t respond with challenge」
* 需要回到 n8n 的 Slack trigger 先設定要監聽的 channel
* 在 n8n 先 Execute step 讓 workflow 進入監聽狀態
* 回到 Slack API 頁面按 Retry，成功後會顯示 Verified

## 設定要訂閱的 Bot Events

* 在 Subscribe to bot events 加入 app_mention / at mentioned 事件
* 儲存變更後，Slack 才會在被提及時送事件到你的 webhook

## 把 Slack App 加入要監聽的 Channel

* 到目標 Slack channel 的 Members/Integrations 區
* 將你的 bot app 加入該 channel
* 未加入 channel 時即使訂閱事件也可能收不到觸發

## 測試觸發：在 Slack 提及 Bot

* 在 n8n 的 Slack trigger 按 Execute step 等待事件
* 

* 回 Slack channel 以 @bot 提及並輸入訊息（例如 hello）
* n8n 會收到事件並看到 payload

## Slack Trigger Payload 常用資訊

* text/content：訊息內容（例如 hello）
* user ID：發訊者識別
* channel ID：所在頻道識別
* event timestamp：事件時間戳
* 其他欄位依 Slack 事件類型可能更多

## 加入 AI Agent 讓 Slack 變成可對話機器人

* 在 Slack trigger 後接 AI Agent


* 在 AI Agent 的輸入用 define below
* 從 Slack payload 拖入 text/content 作為 user message
* 加上 chat model（示範選 gpt-4 mini）
* 加上 memory 以保留上下文
* session ID 可用 channel ID，讓同一個 channel 對話能延續脈絡

## Slack 回覆：Send message 節點

* 在 AI Agent 後接 Slack node
* Resource 選 message，Operation 選 send
* 目標選 send message to channel
* Channel 可用 list 選，也可用 by ID


* Channel ID 可在 Slack channel 詳細資訊中複製（例如 C099…）

## 把 AI Agent 回覆內容塞進 Slack Message Text

* 先執行前面節點取得 AI Agent 的輸出
* 將 AI Agent 的回覆欄位拖入 Slack node 的 message text
* 執行後回 Slack channel 可看到 bot 回覆內容

## 關閉 Slack 訊息附帶的 Workflow 連結

* Slack send message 節點的 Options 內有 include link to workflow
* 將其 toggle off 後再執行
* 回覆訊息就不會附上「automated with this workflow」之類的連結提示

---

# 5. HTTP Request Node 實戰應用
# Workflow 3：HTTP Request Node Demo - Calling API - Web Scraper & other Agentic Tools
## 以 HTTP Request 串接第三方工具的方式

* 可透過 API 呼叫、MCP、Webhook 把非原生工具接入 workflow
* HTTP Request node 是最通用的整合方式，可重現 API 文件中的呼叫流程
* 常見情境包含不需驗證的公開 API、需要 API Key 的服務、以及需要非同步輪詢的服務

## 範例一：無需驗證的公開 API（Cat Facts）

* 使用 Trigger Manual 作為起點，因為不需要輸入資料
* HTTP Request 選 GET
* URL 指向公開端點（catfact.ninja/fact）
* 執行後直接取得隨機貓咪事實並輸出成結構化資料

## 範例二：需要 API Key 的天氣 API（OpenWeatherMap）

* 依文件使用城市名稱查詢天氣資料（例如 London）

* 端點需要 API Key，初始做法可把 key 放在 URL query 裡

* 建議做法是把 API Key 改用 Credential 管理，避免硬編碼且可重用

## OpenWeatherMap：用 Credential 取代把 Key 寫在 URL

* Authentication 選 Generic Credential Type
* 選 Header Auth（示範概念是把 key 放在 header 管理）
* 建立新 credential（命名例如 open weather map demo）
* Name 填對應 header key（示範為 X-API-K）
* Value 填 API key
* 移除 URL 裡的 API key 後再次執行，輸出結果維持一致
* 後續新增同服務節點可直接選用相同 credential

## 範例三：呼叫 Web Scraper（Firecrawl Scrape）

* Firecrawl 的 scrape 以 POST 呼叫
* 從文件複製 curl，使用 Import Curl 快速建立 HTTP Request 設定


* JSON body 填入要抓取的目標網址（示範 TechCrunch 的 GenAI 區）


* Authorization 採 Bearer token，建議用 Header Auth credential 管理
* 關閉重複的手動 headers（避免同一欄位出現兩份）


* 執行後輸出包含頁面內容（示範以 markdown 呈現）與相關連結資訊

## Firecrawl Extract：與 Scrape 的差異

* Extract 是 AI 驅動的結構化抽取，可針對單頁、多頁或整站抽取欄位
* 呼叫 Extract 會先送出 POST，服務端需要時間處理
* 需要再用 GET 依照 request/extract ID 取回結果

## 非同步 API：POST 後等待再 GET 的基本流程

* 先執行 Firecrawl Extract POST 取得 request ID
* 加入 Wait node 等待固定秒數（示範 30 秒）

* 新增 HTTP GET request 以 request ID 查詢處理結果
* GET URL 的 ID 以 expression 動態帶入前一步輸出的 request ID

## 避免流程中斷：用 If + Loop 做輪詢
＾

* GET 回傳會帶狀態欄位（示範 completed / in progress）
* If node 判斷 status 是否等於 completed


* True 分支代表結果已完成，可往後續節點傳遞資料（例如寄信或寫入表單）


* False 分支代表尚未完成，接回 Wait 再等待一段時間後重新 GET
* 透過 Wait → GET → If →（False 回 Wait）形成迴圈，直到 completed 才離開迴圈

## 成本與測試操作

* 為避免測試時反覆消耗 API 額度，可在關鍵節點 pin data
* 對於會計費或有速率限制的服務，pin data 有助於反覆調整下游節點不必重打上游 API

---

# 6. AI 影音生成 Workflow
# Workflow 4：Text to Image Generation Agent - Bytedance

## 文字轉圖片 Workflow 目標與整體流程

* 以 Chat Trigger 收到使用者的簡短圖片需求
* 交給「圖片提示詞生成 AI」把簡短需求改寫成更適合影像模型的 prompt
* 用 HTTP Request POST 呼叫 Wspeed AI 的文字轉圖片模型建立生成任務
* Wait 等待一段時間後用 HTTP Request GET 查詢任務結果
* 用 If 判斷 status，未完成就進入等待迴圈，完成就把圖片連結送到 Gmail

## Chat Trigger：輸入圖片需求

* 使用 Chat Trigger 作為起點，讓使用者用一句話描述要生成什麼圖
* 範例輸入：生成一隻貓飛過彩虹圈

## 圖片提示詞生成 AI：用 LLM 產生更有效的 prompt

* 使用 OpenAI Message Model node（重命名為 image prompt generation AI）
* Model 選 GPT-4.1
* User input 直接接 Chat Trigger 的輸入文字


* 加一段 system message，要求只輸出清晰、具體、可直接丟給影像模型的 prompt
* 執行後產生包含主體、場景、風格、光線等細節的 prompt

## Wspeed AI：POST 建立文字轉圖片任務

* 進 Wspeed AI 選 text-to-image 模型並開啟 API 文件


* 複製 curl，用 Import Curl 建立 HTTP Request（POST）
* Authentication 用 Generic Credential Type + Header Auth


* 建 credential 時，Header Name 用 authorization，Value 用 Bearer + API key
* 關閉/移除節點內重複的手動 headers，避免與 credential 重複
* JSON body 的 prompt 欄位改接「圖片提示詞生成 AI」輸出的內容
* 執行 POST 後取得 request ID 與任務狀態

## Wait：避免立刻 GET 導致結果未就緒

* 加 Wait node（示範 15 秒）讓服務端有時間生成圖片
* 為節省成本，可 pin POST 的輸出資料避免重跑消耗額度

## Wspeed AI：GET 查詢任務結果並取得圖片 URL

* 從 API 文件複製 get-result 的 curl，用 Import Curl 建立 HTTP Request（GET）
* 將 URL 路徑中的 request ID 改成 expression，動態帶入前面 POST 的 request ID
* Authentication 使用同一組 Wspeed header credential
* 成功時從輸出中取得 image URL

## If + Loop：處理「尚未完成」避免 workflow 失敗

* If node 判斷 GET 回傳的 status 是否等於 completed
* True 分支代表完成，可往後續節點送出圖片連結
* False 分支代表仍在處理，接一個 Wait（再等 15 秒）


* False 分支的 Wait 之後再連回 GET 節點形成輪詢迴圈
* 迴圈會持續直到 status 變成 completed 才會走 True 分支

## Gmail：把圖片結果送出

* Gmail Send a message node
* Subject 可用固定文字加上 now 變數當時間戳
* Email body 放圖片 URL（純文字即可）
* 最終收件者點連結即可查看生成圖片

---

# Workflow 5：Text to Video Generation Agent - Veo3
## 目標與流程概覽

* 建立文字轉影片（Text-to-Video）自動化流程，邏輯類似前一節文字轉圖片，但改用影片相關節點與模型


* 從 Chat Trigger 接收影片需求規格，交給 Video Prompt Agent 產生更適合模型的影片提示詞


* 使用 V3 系列文字轉影片模型（示範選 V3 Fast）產生影片，完成後把結果連結輸出（示範用 Gmail）

## 節點差異：Video Prompt Agent

* 與文字轉圖片流程的差異主要在於 Video Prompt Agent 的 system prompt 已預先設定
* system prompt 的目的為把 Agent 設定成「影片生成提示詞工程師」，負責把使用者描述轉成更具體可用的影片 prompt
* 使用者輸入會被改寫成具體場景描述（例如鏡頭感、氛圍、動作、光線等）

## 選模型與成本提醒

* 在平台的 Explore Models 篩選 Text-to-Video 類別並搜尋 V3
* V3 會看到兩個選項：V3 Fast 與一般 V3
* 示範選用 V3 Fast，但單次成本偏高（範例提到一次請求約 $3.20）
* 品質不錯但仍可能偏 3D 感，若要更高擬真可改用一般 V3，成本更高

## HTTP Request：POST 送出生成請求


* 從 API 文件複製整段 curl，回到工作流用 Import curl 快速建立 HTTP POST 節點


* 使用先前設定好的通用認證/憑證（沿用同一組 header credential）


* 關閉 Send Headers（避免重複處理），重點調整 Send Body


* 若 curl 匯入後參數對應錯誤，改用 Raw JSON Body，直接貼上 curl 的 JSON body


* 將 body 裡的 prompt 欄位改綁定為 Video Prompt Agent 的輸出內容
* 影片設定可調：aspect ratio、duration、是否產生音訊等

## 等待與資料固定

* POST 成功後先等待 15 秒，因影片生成時間可能較長


* 為避免重複花費，將 POST 回傳資料 Pin 起來，後續測試不用再打一次昂貴請求

## HTTP Request：GET 輪詢取得結果

* 從 API 文件複製 GET 的 curl，Import curl 建立 HTTP GET 節點


* 將 URL 或參數中的 request ID 改為綁定「影片 ID」（由 POST 回傳）
* 沿用相同認證設定
* 執行 GET 檢查狀態（status），直到完成

## If + Loop：避免未完成就中斷

* 加入 If 判斷 status 是否等於 completed
* 若為 true（completed）就往下走到輸出節點


* 若為 false（未完成）就 wait 15 秒後回圈接回 GET 節點重試

* 形成輪詢迴圈，直到影片狀態完成才繼續

## 輸出：用 Gmail 傳送影片連結

* 設定發送訊息節點，內容包含「影片生成」與時間戳（now 變數）
* 輸出僅傳影片結果連結（示範為 email 內的可下載連結）


* 點擊連結下載並播放生成的影片

## 其他模型與後續章節提到的方向

* 若覺得 V3 成本太高，可改用同平台的其他影片模型（文中提到如 runway、clingan、wan 等）
* 下一節將做 Image-to-Video 工作流，補齊完整流程鏈（Text-to-Video、Image-to-Video）

----
# Workflow 6：Image to Video Generation Agent - Seedance & Telegram

## 工作流目標與兩個必要輸入

* 建立 Image-to-Video 工作流，需同時提供「基礎圖片」與「影片生成文字需求」
* 因為需要多輸入與互動回覆，選用 Telegram 作為集中溝通介面

## 觸發設計與整體流程

* 觸發來源可分兩段：先由 Google Drive 上傳圖片觸發，再由 Telegram 回覆文字需求觸發後續流程
* Google Drive 觸發後先通知 Telegram：已上傳圖片，請回覆想要的影片內容
* 使用者在 Telegram 回覆影片想法後，才進入影片 prompt 生成與呼叫影片模型

## Google Drive Trigger 設定

* 節點選 Google Drive，監控指定資料夾的變更（每分鐘檢查）
* 監控條件設定為「檔案建立 / 上傳檔案」
* 測試事件（Fetch test event）可取得上傳檔案的輸出 payload
* 重點欄位是可公開存取的圖片連結（webContentLink）
* 測試期間需將資料夾/檔案權限調整為「知道連結者可存取」以確保流程可抓到圖片

## Telegram 通知節點用途

* Google Drive 偵測到新圖片後，用 Telegram 節點「Send a Photo」把圖片與提示訊息傳到聊天室
* 訊息內容包含圖片本身與一段 caption，要求使用者提供影片生成想法

## 建立 Telegram Bot 與取得 Token

* 在 Telegram 搜尋並開啟 BotFather（需確認官方藍勾）
* 使用 /newbot 建立新 bot，依流程設定 bot 顯示名稱與 bot username
* BotFather 會回傳 bot 連結與 API token


* 在工作流建立 Telegram credential，貼上 token 測試連線成功（顯示綠色連線成功提示）

## 取得 Chat ID 的方式

* 需建立 Telegram Trigger（On Message）暫時用來抓聊天室的 chat id


* 執行 Trigger 後，去與 bot 對話（先 /start，再發送測試訊息）


* 在觸發回傳內容中找到 chat id，複製後回填到 Telegram 發送節點的 chat ID 欄位
* 因為後續都在同一個聊天室互動，所以 chat id 可直接固定寫死不必動態取得

## 綁定圖片 URL 與通知文字

* Telegram 發送照片的 photo 欄位綁定 Google Drive Trigger 回傳的 webContentLink
* caption 內容設計為：告知已上傳圖片，請使用者回覆想生成的影片描述（以此圖片為基礎）


* 測試執行後，Telegram 會收到正確圖片與提示文字，確認第一段流程完成

---
## 用 Google Sheets 做 Image Log（Append Row）

* 新增 Google Sheets 節點並選擇「Append row in sheet」用來追加紀錄
* 節點可命名為 image log，表示這段是在記錄上傳的圖片資訊


* 先建立一個 Google Sheet 文件（例如 image to video log）
* 試算表欄位設兩欄：image URL、date
* 文件分享權限測試時可設為公開（至少可用連結檢視）

## 綁定目標試算表與工作表

* Document 從 list 選 image to video log
* Sheet 選 Sheet1（範例只有一個工作表）
* 節點會自動讀取欄位並顯示 image URL、date 兩個欄位可對應

## 欄位對應方式

* image URL 欄位拖入 Google Drive trigger 的 webContentLink
* date 欄位拖入 now 變數作為上傳/建立時間
* 執行 Execute step 後會把一筆新紀錄寫入下一個空白列

## 切換到 Video Prompt Agent（OpenAI Message and Model）

* 接著新增 OpenAI 的 message and model 節點作為影片提示詞產生器
* 模型選 GPT-4.1
* 先執行 Telegram on message 取得使用者輸入的影片想法文字


* 將 Telegram 訊息文字拖入 OpenAI 節點的 user prompt

## Video Prompt Agent 的 System Prompt 兩個任務

* 任務一：把使用者輸入改寫成更適合影片生成模型的有效 video prompt
* 任務二：輸出必須分成兩個 JSON 欄位
* 欄位一是 prompt（string）
* 欄位二是 image_url（string），提供給下游影片生成 API 使用

## 讓 Agent 從 Google Sheets 取「最新圖片 URL」

* 在 Video Prompt Agent 加入 Google Sheets tool
* Tool 設定為 get rows，Document 指到 image to video log，Sheet 指到 Sheet1


* 在 system prompt 明確要求從該 log 的最後一列抓取 image URL 當作 image_url
* 工具可命名為 Google sheet log 讓提示詞與工具名稱一致


* 節點上可切換輸出為 JSON，確保下游可直接取 prompt 與 image_url

## 呼叫影像轉影片模型：HTTP POST（Cance v1）

* 新增 HTTP request 節點，使用 import curl 匯入 POST 範例


* 選擇 image-to-video 模型（範例為 Cance v1）
* Authentication 使用既有憑證，headers 可視情況關掉避免重複
* 將 body 內的 image URL 改成上一步輸出的 image_url
* 將 body 內的 prompt 改成上一步輸出的 prompt
* duration 可先用 5 秒測試，其他參數可之後再調整
* Execute step 成功會回傳 request/task ID

## 等待與輪詢：Wait + HTTP GET

* 加入 Wait 節點先等 15 秒，避免太快輪詢拿不到結果
* 新增 HTTP GET 節點，import curl 匯入 GET 範例
* 將 request ID 替換為 POST 回傳的 ID
* Authentication 同 POST，headers 同樣可關掉
* 執行 GET 後查看 status（範例為 completed）

## 用 If 節點避免未完成就中斷

* 新增 If 節點判斷 status 是否等於 completed
* 若 completed 走 true 分支進下一步


* 若未完成走 false 分支：再 Wait 15 秒後回到 GET 重新查詢
* 形成輪詢迴圈直到完成

## 完成後用 Telegram Send Video 回傳結果

* 在 true 分支後新增 Telegram「Send a video」節點
* chat ID 可固定硬填或從 trigger 動態帶入
* video 欄位拖入輪詢結果中提供的影片輸出（通常是影片 URL）
* Execute step 後 Telegram 會收到生成影片

---

# Quick Explainer for Subworkflows
## 單一工作表 vs 拆成兩個工作流的考量

* 全部放在同一個 workflow 方便一次看完整流程但較難除錯
* 拆成兩個 workflow 可分離責任並更容易定位問題
* 一個負責上傳圖片與記錄/通知，另一個負責收影片點子與生成/輪詢/回傳

---
# Google Vertex AI Explainer

## 目的與方式概覽

* 說明除了透過 wavespeed 等平台，也能直接用 Google Cloud Vertex AI 呼叫 V3（文字轉影片）


* 以「先跑通 API」為目標，先用手動觸發節點驗證 HTTP POST/輪詢流程可正常運作

## 建立工作流骨架

* 使用 Manual Trigger 節點先執行一次以產生流程輸入
* 新增 HTTP Request 節點並選擇 POST 方式呼叫 Vertex AI 端點

## Vertex AI 端點設定（Project ID / Model ID）

* 從 Vertex AI 文件的 Sample Request 複製簡化版 endpoint URL


* 端點需要替換兩個值：Project ID 與 Model ID
* Project ID 從 Google Cloud 專案儀表板取得（不是 project number）
* Model ID 從文件列出的型號中選用（示範用 VO3 Fast generate 01）

## Google OAuth 認證設定

* 認證方式改用 Predefined Credential Type：Google OAuth（非一般 API Key header）


* 在工作流憑證中建立 OAuth，需填入 Client ID 與 Client Secret


* Redirect URL 需與 Google Cloud Console 中授權的 redirect URL 一致
* 需加入 scope，讓 token 有權限呼叫 Vertex AI 相關 API


* 在 Google Cloud Console 啟用 Vertex AI API 後，於工作流進行 Google 登入授權並連線成功

## POST Body（JSON）與生成參數

* HTTP Request 的 Body 選用 JSON body
* 從文件的簡化 JSON body 複製貼上作為起始範本


* 可在 JSON 設定 prompt、sample count、aspect ratio、duration 等
* 若不設定 storageUri（GCS bucket），結果會以 Base64 回傳到工作流節點
* 示範移除 storageUri，改用回傳 Base64 以便在流程內轉檔下載

## 等待與輪詢取得結果（Long-running Operation）

* POST 送出後先 Wait 15 秒，避免太早輪詢取不到結果


* 新增另一個 HTTP Request（同為 POST）呼叫「poll long-running operation」端點
* 輪詢請求只需帶入 operation name 並使用相同 OAuth 認證

## 錯誤處理：影片時長限制

* 輪詢回傳錯誤指出不支援 5 秒影片時長
* Text-to-Video 支援的 duration 為 8 秒（示範改成 8 後再重跑）

## Base64 結果與大資料量

* 輪詢成功後回傳資料量很大（示範顯示約 6MB），瀏覽器可能短暫變慢
* 因未指定輸出 bucket，回傳內容包含 Base64 影片資料

## If Loop：確保完成才往下走

* 加入 If 判斷狀態欄位（boolean）是否完成
* True 分支往後處理輸出


* False 分支 Wait 15 秒後回圈再 poll，直到完成

## 轉檔與下載（Base64 → 檔案）

* 使用 Set/Edit Fields 節點把 Base64 輸出存成字串欄位（例如 B64）
* 使用 Convert File 節點將 Base64 字串轉成檔案
* 產出檔案後可直接下載，下載的檔案即為生成影片（示範播放成功且包含音訊）

## 平台對比與使用情境差異

* 直接用 Vertex AI 需要處理 OAuth、scope、API 啟用、端點與輪詢流程
* VO3 成本高但品質與音訊表現佳
* 使用 wavespeed 等平台可用同一套介面接多種模型，減少各家 API/憑證設定成本

---

# 7. n8n 架構進階與部署選擇
# Self-Hosting Vs Building on n8n Cloud

## n8n Cloud vs Self-host：取捨重點

* Cloud：註冊就能用，不用管 Docker、維運、更新與資安修補
* Cloud：有官方支援與可用性監控，但需訂閱費、環境掌控度較低、資源受平台限制
* Self-host：環境與資源可完全自訂，能放在內網或特定地區，與內部工具/資料庫整合更彈性
* Self-host：可能更省成本，但需自己維護伺服器、更新 n8n、處理安全性與故障排除

---
# Workflow 7：Calling Subworkflows

## nitn Cloud 與自架取捨

## 為什麼要用 Sub Workflow 拆分

* 原本 Image-to-Video 工作流把兩個 Trigger 放在同一條流程，出錯時需要來回查兩段，除錯不直覺
* 透過拆成「主工作流 + 子工作流」，可以把責任分段，錯誤更容易定位與迭代

## 主工作流的職責（Google Drive → Telegram 通知 → 記錄）

* Trigger：Google Drive 偵測資料夾上傳圖片
* 立刻用 Telegram 傳圖片與提示，要求使用者提供影片想法
* 將圖片 URL 寫入 Google Sheet 作為後續流程要抓取的最新圖片來源

## 主工作流新增 Execute Subworkflow 節點

* 在寫入 Google Sheet 之後加入 Execute Subworkflow 節點
* 需要先建立另一個工作流（子工作流），主工作流才能在清單中選到它
* 主工作流被觸發後，會在指定節點呼叫子工作流接續處理

## 子工作流的 Trigger 改成「Executed by another workflow」

* 子工作流不再用原本的 Telegram on message 觸發
* Trigger 改為「Executed by another workflow」，代表由主工作流呼叫才會啟動
* 被主工作流觸發的子工作流不需要啟用發布也能運行（依平台顯示為不需 activation）

## 主→子資料傳遞模式：Accept all data

* 子工作流可設定輸入資料模式為 Accept all data
* 子工作流執行紀錄可看到從主工作流帶過來的 payload


* 實際能帶過來的欄位取決於主工作流前一節點輸出內容（示範只帶 image URL 與 date）

## 主→子資料傳遞模式：Define using fields below

* 改用 Define using fields below 可只傳指定欄位，控制子工作流的輸入結構
* 只定義 image URL 時，子工作流 payload 就只會有 image URL，不會包含 date
* 定義欄位但主工作流沒傳值時，子工作流會收到空值欄位（示範看到欄位存在但內容為空）

## 子工作流加入 Telegram「Send message and wait for response」

* 子工作流內新增 Telegram 節點，改為詢問並等待使用者回覆影片想法
* chat id 可直接沿用固定值硬編碼，或改成由主工作流傳入以支援多聊天室


* 使用者在 Telegram 提交回覆後，子工作流取得自由文字輸入作為後續提示詞生成素材

## 串接 Video Prompt Agent 的輸入輸出

* 將 Telegram 回覆文字綁到 Video Prompt Agent 的 user prompt
* system message 目的仍是把使用者想法整理成可用的影片生成 prompt
* Agent 輸出要求包含 JSON：生成的 prompt + 從 Google Sheet 取得的 image URL

## 子工作流後段維持原 Image-to-Video 生成邏輯

* 使用 prompt + image URL 呼叫影片模型的 POST API（示範提到 Cance / wavespeed 等）
* Wait 15 秒後進行 GET 取得狀態與結果
* 用 if loop 判斷未完成就等待再輪詢，完成後把影片結果回傳 Telegram

## 拆分後的執行體驗與除錯差異

* 主工作流負責「圖片事件與通知、記錄、呼叫子流程」
* 子工作流負責「收集文字需求、生成 prompt、呼叫模型、輪詢、回傳結果」
* 分成兩條後可分別看主/子流程各自的 execution logs，更容易定位哪段出錯與重跑驗證

----

# Self-Hosting Locally With Docker Desktop and Ollama
## 目標：用 Docker Desktop 在本機自架 n8n

* 透過 GitHub 的 n8n-io/self-hosted-ai-starter-kit 快速建立本機環境
* 這個 starter kit 會一起拉起必要元件（例如 Postgres、Qdrant、n8n、Ollama）
* 本機預設用 localhost:5678 存取 n8n

## 本機前置需求

* 安裝 Docker Desktop（從 docker.com 下載）
* 安裝 Git（用來 clone repo）
* 確認你知道自己的平台（範例是 Mac）

## 本機安裝流程（Mac 範例）

* 到 GitHub 打開 self-hosted-ai-starter-kit 文件並找到 Mac 對應步驟
* 在終端機執行 git clone 下載 repo
* cd 進 repo 資料夾
* 建立/複製環境檔（.env）
* 依平台選對 docker compose 指令
* Apple Silicon / CPU 情境使用對應的 compose（範例使用 CPU 版本）
* 第一次啟動會下載映像：Postgres、Qdrant、n8n、Ollama 等

## 本機啟動後如何驗證

* 瀏覽器開啟 localhost:5678
* 第一次進入會要求註冊帳密（本機環境可用任意 email/password）
* repo 通常會附一個 demo workflow，可直接打開測試

## Demo workflow 與 Ollama 測試

* demo workflow 是基本 LLM chain（Ollama chat model）
* 若流程需要 fallback model，就再加一個 Ollama model 當 fallback
* 在測試輸入框輸入訊息後執行，應可得到模型回覆
* 回覆代表 n8n 與 Ollama 都在本機容器中正常運作

## Docker Desktop 觀察重點

* Docker Desktop 會看到一組 container stack 在跑
* stack 內包含 Postgres / Qdrant / n8n / Ollama
* 若停止 container，n8n 網頁會顯示連線中斷，代表完全依賴容器運行
* Images 可查看/下載映像版本
* Volumes 代表持久化資料位置（帳密、資料庫等會存這裡）

## 需要調整設定時的入口

* 可直接編輯 docker-compose 或相關設定檔
* 常見調整方向：帳號持久化、資料持久化、port 對應、cookie/安全設定等

---
# n8n Hosted on AWS EC2

## 目標與環境來源

* 目標是在 AWS EC2 上用 Docker 部署 nitn
* 透過 CodeCloud playground 啟動 AWS sandbox，取得 AWS Console 登入資訊

## 進入 AWS Console 與建立 EC2

* 從 playground 複製 AWS Console 登入連結、username、password 登入


* 進入 EC2 → Instances，選 Launch instance 建立新主機
* 命名 instance（示範 nan-demo），AMI 選 Ubuntu
* Instance type 選 t2.medium（考量後續會拉較大的套件/模型）


* 建立 key pair（RSA、.pem）並下載到本機
* Network 設定暫時允許 SSH from anywhere
* Storage 調整到 30GB

## Security Group 與入站規則

* 到 Instance 的 Security groups 設定 inbound rules
* 保留/確認 SSH（22）可連線
* 新增自訂 TCP port 5678（nitn 預設埠），來源允許 anywhere
* 儲存規則後再進行連線與測試

## SSH 連線到 EC2

* 對下載的 .pem 執行 chmod 400


* 使用 ssh -i 連線到 Ubuntu@Public IPv4
* 第一次連線會提示 host authenticity，輸入 yes 繼續

## 在 EC2 安裝 Docker 與 Docker Compose v2

* 更新系統套件後安裝 Docker
* 啟用 Docker 服務並調整使用者群組權限（讓使用者可執行 docker）


* 安裝 Docker Compose v2 並用 docker compose version 驗證

## 下載 self-hosted 套件並準備環境檔

* git clone 專案 repo
* 進入 self-hosted AI starter kit 目錄
* 複製 .env 範本建立環境檔

## 環境設定調整（示範用）

* 在 .env 加入設定將 secure cookie 關閉（示範為了避免部分安全限制影響存取）
* 儲存後準備啟動容器

## 啟動服務與確認容器狀態

* 執行 docker compose up（或對應啟動指令）拉取映像並啟動服務


* 用 docker ps 確認容器都在 running 狀態

## 透過 Public IP 開啟 nitn

* 從 AWS Console 複製 EC2 Public IPv4
* 瀏覽器輸入 http://<PublicIP>:5678 開啟 nitn
* 第一次登入可用任意帳密建立初始登入（示範為無持久化既有帳密）

## 驗證功能與資源觀察

* 進入後看到與 nitn cloud 類似的 dashboard
* 預設 demo workflow 會出現，並可看到與 Ollama 相關的預設模板（套件隨 repo 一起部署）
* 在 EC2 介面可查看 instance usage，git clone/拉映像時資源使用會較明顯

---

# 8. 課程總結
## 課程收尾重點回顧

* 從抽象概念（節點、Sub Workflow）到實作出可用的自動化工作流
* 練習用 HTTP Request 節點串接外部 API 與服務
* 建立 AI Agents 自動化真實任務（回信、研究、對話處理）
* 文字/媒體輸入生成圖片與影片
* 用 Sub Workflows 把複雜流程模組化、可重用、易除錯
* 部署方式涵蓋雲端與自架（Docker、AWS EC2 等）
* 介紹 RAG agents（向量資料庫如 Pinecone）讓自動化具備記憶/可查詢背景資料
* 使用 MCPs 在工作流中重用與擴充可組裝的能力模組
* 強調錯誤處理、重試策略、模板市集加速搭建

## Lab Playground 與 nitn Cloud 的差異概覽

* Lab 進入時仍需填 email/姓名/密碼，但不會被保存，可每次用不同資訊
* Lab 有 onboarding 與付費提示可跳過，進入後介面接近雲端 Admin Dashboard
* Lab 與 Cloud 在「金鑰/憑證設定」與部分功能可用性上有差異

## Lab 使用 CodeCloud Keyspace 呼叫 OpenAI 模型

* 在節點選 OpenAI chat model 後，需依左側指引開啟 CodeCloud Keyspace 取得 API Key 與 Base URL
* 建立 OpenAI credential 時需貼上 Keyspace API key，並把 Base URL 換成 Keyspace 提供的 Base URL
* 用「Pick from list」時清單可能對不上常見 GPT 型號，容易造成執行錯誤
* 解法是改用「By ID」，手動填入指定格式的模型 ID（例如 OpenAI/GPT-4.1）才能正常呼叫

## 直接使用 OpenAI 官方 API Key 的差異

* 建立 credential 時只需貼上 OpenAI API key，Base URL 保持預設即可
* 模型可直接從清單選擇，列表與可用型號對應較直覺
* 測試執行可直接看到節點呼叫到正確模型

## Lab 使用 Gmail/Google 工具需自行建 OAuth（與 Cloud 不同）

* nitn Cloud 常見情況可直接用按鈕以瀏覽器登入 Google 完成授權
* Lab 環境多數需要完整走 OAuth 設定流程才能連 Google 服務（Gmail/Sheets 等）

## Google Cloud Console 建立 Gmail OAuth 的步驟

* 在 Google Cloud Console 建立新專案（Google 以專案區分 OAuth 授權配置）
* 啟用 Gmail API（未啟用會無法授權或呼叫）
* 設定 OAuth consent screen（App name、支援信箱、External、聯絡資訊）
* 在 Audience 加入 Test user（要授權使用的 Gmail 帳號）
* 建立 OAuth client ID（Web application），填入 Lab 提供的 Authorized redirect URL
* 取得 client ID 與 client secret，回到 Lab 的 Gmail credential 貼上
* 點「Sign in with Google」完成授權，可能出現「未驗證應用」警告但可繼續
* 授權完成後顯示 connection successful，即可在工作流中測試 Gmail 節點

## Lab 範例：Email AI Agent 走通流程

* 從「Start from scratch」建立 Email AI agent 工作流，trigger 用 chat trigger
* AI agent 不設 system prompt 也能跑通，但內容通常較簡單
* 測試指令示範：要求寄信到指定收件人，執行後可在 Gmail 收到發出的郵件

## 其他環境差異提醒

* 自架或 Lab 可能與雲端版在社群節點、支援版本、部分功能上不同
* 遇到流程或功能落差時，常見原因是部署環境差異而非流程本身錯誤

---

# Terminology
* AI Agent（AI 代理）：可推理、使用工具並完成任務的智慧單元
* AI Playground（AI 遊樂場）：可即時測試與產生 API 金鑰的操作介面
* AI 代理節點（AI Agent Node）：整合模型、記憶與工具的核心智慧節點
* AI 代理節點（AI Agent Node）：負責處理 Slack 訊息並生成回應的智慧節點
* AI 代理（AI Agent）：可根據輸入與上下文自主決策並執行任務的智慧模組
* AI 代理（AI Agent）：能夠理解指令、使用工具並做出決策的智慧節點
* AI 摘要生成（AI-driven Summarization）：利用 AI 自動產生重點摘要的技術
* AI 擷取（AI-powered Extraction）：利用 AI 理解網頁並抽取指定資訊
* AI 研究代理（AI Research Agent）：負責搜尋、整理與分析外部資訊的智慧代理
* API 呼叫錯誤（API Error）：請求失敗時回傳的錯誤狀態
* API 呼叫（API Call）：透過 HTTP 協定與外部服務進行資料交換的請求行為
* API 啟用（API Enablement）：允許專案使用特定 API 的設定
* API 啟用（API Enablement）：允許專案使用特定 Google API 的必要設定步驟
* API 啟用（API Enablement）：在 Google Cloud Console 中啟用特定服務的動作
* API 存取範圍（API Scope）：定義 OAuth 權限可使用服務範圍的設定
* API 整合（API Integration）：將第三方服務或系統功能串接進既有流程的方式
* API 整合（API Integration）：透過 API 連接不同服務
* API 文件（API Documentation）：描述 API 使用方式、參數與回傳格式的說明文件
* API 端點（API Endpoint）：可被呼叫以執行特定功能的 URL
* API 端點（API Endpoint）：對外提供服務存取的特定 URL
* API 配額管理（API Quota Management）：控制與節省 API 使用量的策略
* API 金鑰（API Key）：用於識別與授權 API 存取的憑證
* API 金鑰（API Key）：用於識別與授權應用程式存取 API 的秘密字串
* API 金鑰（API Key）：用於驗證並授權存取第三方服務的密鑰
* API 金鑰（API Key）：用於驗證與授權 API 存取的憑證
* API 金鑰（API Key）：用於驗證與授權模型或服務存取的秘密憑證
* API 金鑰（API Key）：用於驗證與識別請求來源的憑證
* API 閘道（API Gateway）：統一管理與轉發 API 請求的入口
* API 驗證（API Authentication）：用於確認請求合法性的驗證機制
* API 驗證（API Authentication）：確保請求合法性的身分驗證機制
* API 驗證（API Authentication）：確認請求身分並授權存取的安全機制
* AWS EC2（Amazon Elastic Compute Cloud）：Amazon 提供的彈性虛擬伺服器服務
* AWS 主控台（AWS Console）：管理 AWS 資源的網頁介面
* App Mention 事件（App Mention Event）：當使用者在頻道中 @ 機器人時觸發的事件
* Base64 編碼（Base64 Encoding）：將二進位檔案轉為文字格式的編碼方式
* Base64 編碼（Base64 Encoding）：將二進位資料轉換為文字字串的編碼方式
* Base64 轉檔（Base64 to File Conversion）：將 Base64 字串還原為實際檔案的處理
* Bearer Token（Bearer Token）：常見於 Authorization Header 的權杖格式
* Bearer Token（Bearer Token）：常見於 Authorization Header 的權杖驗證格式
* Bot Events 訂閱（Bot Events Subscription）：指定機器人要監聽的事件類型
* Bot Token（Bot API Token）：Telegram 機器人用於 API 驗證的存取金鑰
* Bot Token（Bot Access Token）：Telegram 機器人與 API 溝通的驗證金鑰
* Bot Token（Bot Token）：Slack 機器人用來驗證與呼叫 Slack API 的金鑰
* Bot Token（Bot Token）：Telegram 機器人呼叫 API 所需的驗證金鑰
* Bot 使用者（Bot User）：Slack 中由應用程式建立的自動化帳號
* Bot 權限範圍（Bot Scope）：限制 Slack 機器人可執行行為的權限集合
* BotFather（BotFather）：Telegram 官方用於建立與管理機器人的工具
* BotFather（BotFather）：Telegram 官方用於建立與管理機器人的服務
* BotFather（BotFather）：Telegram 官方用於建立與管理機器人的服務
* CPU 模式（CPU Mode）：不使用 GPU、僅以處理器執行模型的運行方式
* CURL 匯入（Import CURL）：直接匯入 CURL 指令來建立 HTTP 請求
* Challenge 驗證（Challenge Verification）：Slack 用來驗證 Webhook 是否有效的安全機制
* Chat ID（聊天識別碼）：唯一識別 Telegram 對話或群組的 ID
* Chat ID（聊天識別碼）：唯一識別 Telegram 對話的數值 ID
* Chat Trigger（聊天觸發器）：以對話輸入啟動工作流的觸發方式
* Client ID（Client ID）：OAuth 驗證流程中用於識別應用程式的公開識別碼
* Client ID（用戶端識別碼）：OAuth 中標識應用的公開 ID
* Client Secret（Client Secret）：OAuth 驗證流程中用於交換存取權杖的私密金鑰
* Client Secret（用戶端密鑰）：OAuth 中用於驗證應用的私密金鑰
* Code Key（Code Key）：整合多模型存取的統一 API 金鑰服務
* Define Below 模式（Define Below）：手動指定 AI 代理輸入來源的設定方式
* DevOps 整合（DevOps Integration）：將自動化流程納入開發與維運管線
* DevOps 自動化（DevOps Automation）：自動化部署、監控與維運流程
* Docker Compose v2（Docker Compose v2）：新版 Compose 指令整合於 Docker CLI
* Docker Compose（Docker Compose）：用於定義與啟動多容器應用的工具
* Docker Compose（Docker Compose）：用於定義與管理多容器應用的工具
* Docker Dashboard（Docker 儀表板）：用於監控容器狀態的視覺化介面
* Docker Desktop（Docker Desktop）：在本機執行與管理 Docker 容器的工具
* Docker Desktop（Docker Desktop）：在本機執行與管理 Docker 容器的桌面工具
* Docker 安裝（Docker Installation）：在伺服器上部署 Docker 引擎
* Docker 容器化（Docker Containerization）：將應用與其依賴封裝成可移植容器的技術
* Docker 容器（Docker Container）：映像檔執行後的獨立運行實體
* Docker 映像檔（Docker Image）：用來建立容器的唯讀模板
* Docker（Docker）：以容器化方式封裝與執行應用程式的平台
* EC2（Elastic Compute Cloud）：AWS 提供的彈性虛擬運算服務
* Firecrawl（Firecrawl）：支援智慧爬取與結構化擷取的網頁爬蟲工具
* GCS 儲存桶（GCS Bucket）：Google Cloud Storage 用於存放檔案的儲存空間
* GET 方法（GET Method）：用於查詢任務狀態或結果的 HTTP 方法
* GET 請求（GET Request）：向 API 取得已存在資源或處理結果的請求方式
* GET 請求（GET Request）：向 API 查詢任務狀態或結果的請求方式
* GET 請求（GET Request）：向 API 查詢任務狀態或結果的請求方式
* GET 請求（GET Request）：向外部服務查詢生成結果或任務狀態的請求方式
* GET 請求（GET Request）：用於取得資源資料的 HTTP 方法
* GPT-4 模型（GPT-4）：具備較強推理與語意理解能力的語言模型
* GPT-4.1 Mini（GPT-4.1 Mini）：兼顧效能與成本的輕量級推理模型
* GPT-4.1 Mini（GPT-4.1 Mini）：適合即時對話、成本較低的語言模型
* GPT-4.1（GPT-4.1）：具備高理解能力、適合複雜提示生成的語言模型
* GPT-4.1（GPT-4.1）：具備高階理解與生成能力的語言模型
* GPT-4.1（GPT-4.1）：適合複雜理解與生成任務的語言模型
* GPT-5 模型（GPT-5）：具備強化推理與工具使用能力的最新語言模型
* Git 儲存庫（Git Repository）：用於版本控制與原始碼管理的倉庫
* GitHub 儲存庫（GitHub Repository）：存放原始碼與設定檔的版本控制平台
* Gmail API（Gmail API）：用於讀取與發送 Gmail 郵件的介面
* Gmail API（Gmail API）：用於讀寫電子郵件的 Google 服務介面
* Gmail 工具（Gmail Tool）：讓 AI 能讀寫 Gmail 信件的整合工具
* Gmail 節點（Gmail Node）：用於寄送電子郵件的獨立工作流程節點
* Google API 整合（Google API Integration）：在工作流中使用 Google 服務
* Google Cloud Console（Google Cloud Console）：管理 Google 專案、API 與 OAuth 設定的平台
* Google Cloud Console（Google 雲端控制台）：管理 Google API 與專案的入口
* Google Cloud 專案（Google Cloud Project）：管理雲端資源與 API 權限的單位
* Google Docs API（Google Docs API）：用於操作 Google 文件內容的介面
* Google Drive API（Google Drive API）：用於存取與管理 Google Drive 檔案的介面
* Google Drive 觸發器（Google Drive Trigger）：當雲端硬碟資料夾發生變更時自動觸發的事件節點
* Google Drive 觸發器（Google Drive Trigger）：監控指定資料夾檔案變化並啟動流程的節點
* Google Drive 觸發器（Google Drive Trigger）：監聽指定資料夾檔案變化以啟動工作流程的事件節點
* Google Gmail API（Gmail API）：用於自動收發與管理電子郵件的介面
* Google Sheets API（Google Sheets API）：用於讀寫 Google 試算表資料的介面
* Google Sheets 工具（Google Sheets Tool）：供 AI 或流程查詢試算表資料的工具
* Google Sheets 工具（Google Sheets Tool）：讓 AI 或流程讀取試算表資料的整合工具
* Google Sheets 日誌（Google Sheets Log）：用於記錄流程歷史資料的試算表
* Google Sheets 節點（Google Sheets Node）：用於讀寫試算表資料的自動化節點
* Google Sheets 記錄節點（Google Sheets Log Node）：將資料寫入試算表以供後續讀取的節點
* Google 專案（Google Project）：Google Cloud 中用於管理 API 與資源的邏輯單位
* Google 文件節點（Google Docs Node）：存取 Google 文件資料的整合節點
* Google 試算表日誌（Google Sheets Logging）：將結構化資料寫入試算表作為長期紀錄
* HTTP 節點（HTTP Node）：在工作流中發送 HTTP 請求的功能節點
* HTTP 請求節點（HTTP Request Node）：在工作流中直接發送 HTTP API 請求的功能節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫 REST API 的通用節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 API 並傳送或接收資料的功能節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 API 以提交或取得生成結果的節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 API 的通用節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 API 的通用節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 API 的通用節點
* HTTP 請求節點（HTTP Request Node）：用於呼叫外部 REST API 的通用節點
* HTTP 請求節點（HTTP Request Node）：用於發送 GET、POST 等 HTTP 請求的核心節點
* HTTP 請求（HTTP Request）：透過 HTTP 與外部服務通訊
* HTTP 請求（HTTP Request）：透過標準網路協定呼叫外部服務的方式
* ID 指定方式（Select by ID）：以唯一識別碼指定 Slack 頻道的設定方式
* JSON 回應（JSON Response）：API 回傳的結構化資料格式
* JSON 格式（JSON Format）：常見的結構化資料表示方式
* JSON 結構輸出（JSON Structured Output）：以固定 JSON 格式輸出模型結果的設計
* JSON 結構輸出（Structured JSON Output）：將模型結果以固定 JSON 格式輸出的設計
* JSON 請求主體（JSON Body）：以 JSON 格式傳送的 API 請求內容
* JSON 請求主體（JSON Request Body）：以 JSON 格式傳送模型參數的請求內容
* JSON 資料結構（JSON Data Structure）：以鍵值對方式表示的結構化資料格式
* JSON 輸出格式（JSON Output Format）：以結構化 JSON 形式回傳模型結果
* JavaScript 表達式（JavaScript Expression）：用於動態資料綁定的運算語法
* LLM 可插拔架構（Pluggable LLM Architecture）：可自由替換不同大型語言模型的設計
* MCP（Modular Capability Package）：可被多個工作流共用的功能模組
* Markdown 內容（Markdown Content）：以 Markdown 格式呈現的文字資料
* NOW 變數（Now Variable）：代表當前時間的內建動態變數
* OAuth 2.0 憑證（OAuth 2.0 Credential）：用於安全存取 Google Cloud API 的授權機制
* OAuth 2.0（OAuth 2.0）：Google Cloud 用於安全授權的身份驗證協定
* OAuth 2.0（OAuth 2.0）：用於安全授權第三方存取帳戶的標準協議
* OAuth 2.0（OAuth 2.0）：第三方應用安全存取使用者資源的標準授權協定
* OAuth 2.0（OAuth 2.0）：第三方授權與存取控制的標準協定
* OAuth 同意畫面（OAuth Consent Screen）：使用者授權應用存取資料時顯示的介面
* OAuth 同意畫面（OAuth Consent Screen）：使用者授權應用存取資料的介面
* OAuth 同意畫面（OAuth Consent Screen）：使用者授權應用的介面
* OAuth 憑證（OAuth Credential）：包含 Client ID 與 Client Secret 的授權設定
* OAuth 權限管理（OAuth Scope Management）：控制應用可存取資源範圍的安全機制
* OAuth（OAuth）：常見的第三方授權與存取控制協定
* Ollama（Ollama）：用於在本地執行與管理 LLM 的服務工具
* OpenAI 節點（OpenAI Node）：在工作流中用於呼叫大型語言模型的節點
* OpenAI 節點（OpenAI Node）：在工作流程中呼叫 OpenAI 模型進行推理與生成的節點
* OpenAI 節點（OpenAI Node）：專用於呼叫 OpenAI 模型的節點
* OpenAI 聊天模型（OpenAI Chat Model）：由 OpenAI 提供的對話型語言模型服務
* OpenAI 訊息與模型節點（OpenAI Message & Model Node）：用於呼叫語言模型的處理節點
* OpenAI 訊息與模型節點（OpenAI Message & Model）：用於生成文字與結構化輸出的模型節點
* OpenAI 訊息與模型（OpenAI Message & Model）：用於文字生成與結構化輸出的模型節點
* POST API 呼叫（POST API Call）：向外部服務提交資料以觸發處理的請求方式
* POST 方法（POST Method）：用於提交資料並建立任務的 HTTP 方法
* POST 請求（POST Request）：向 API 傳送資料以啟動影片生成任務
* POST 請求（POST Request）：向 API 傳送資料以建立任務的請求方式
* POST 請求（POST Request）：向 API 提交資料以建立或觸發處理的請求方式
* POST 請求（POST Request）：向伺服器送出資料的 HTTP 方法
* POST 請求（POST Request）：提交生成任務或資料給外部服務的請求方式
* POST 請求（POST Request）：用於提交資料並觸發後端處理的 HTTP 方法
* POST 請求（POST Request）：用於提交資料並觸發處理的 HTTP 方法
* Perplexity 節點（Perplexity Node）：用於即時搜尋與彙整新聞或知識內容的來源節點
* Perplexity 節點（Perplexity Node）：用於即時網路搜尋與研究型查詢的 AI 節點
* Pinecone（Pinecone）：常用於 RAG 架構的雲端向量資料庫服務
* PostgreSQL（PostgreSQL）：開源關聯式資料庫管理系統
* RAG 架構（Retrieval-Augmented Generation）：結合檢索系統與生成模型的 AI 架構
* REST 架構（REST Architecture）：以資源為核心的 API 設計風格
* SSH 連線（SSH Access）：透過安全通道遠端管理伺服器
* SSH（Secure Shell）：安全遠端登入伺服器的通訊協定
* Sandbox 環境（Sandbox Environment）：用於測試與學習的隔離雲端環境
* Slack API（Slack API）：與 Slack 平台進行程式化互動的官方介面
* Slack 事件負載（Slack Event Payload）：Slack 傳送給工作流程的完整事件資料
* Slack 使用者權杖（Slack User OAuth Token）：代表使用者身份進行操作的授權權杖
* Slack 應用程式（Slack App）：在 Slack 平台中建立、用於整合外部服務的應用
* Slack 機器人提及觸發器（On Bot App Mention）：當 Slack 頻道中提及機器人時觸發工作流程的節點
* Slack 發送訊息節點（Slack Send Message Node）：用來回覆訊息到 Slack 的節點
* Slack 頻道加入（Add App to Channel）：將機器人加入指定頻道以接收事件
* Starter Kit（啟動套件）：快速建立特定系統或應用的預設專案組合
* Telegram Bot（Telegram 機器人）：用於接收與發送訊息、串接自動化流程的 Telegram 帳號
* Telegram Bot（Telegram 機器人）：負責接收與發送 Telegram 訊息的自動化帳號
* Telegram 傳送影片（Telegram Send Video）：透過 Telegram 推送影片的操作
* Telegram 回傳影片（Telegram Video Delivery）：透過 Telegram 傳送生成完成的影片
* Telegram 憑證（Telegram Credential）：在自動化平台中儲存並使用的 Telegram 驗證設定
* Telegram 憑證（Telegram Credential）：在自動化平台中設定的 Telegram API 認證資訊
* Telegram 機器人（Telegram Bot）：在 Telegram 平台上用於自動收發訊息的帳號
* Telegram 發送影片（Send Video）：透過 Telegram 將生成影片回傳給使用者
* Telegram 發送照片（Send Photo）：透過 Telegram 節點主動推送圖片訊息
* Telegram 訊息觸發器（Telegram On Message Trigger）：當機器人收到訊息時啟動流程的節點
* Telegram 通知節點（Telegram Notification Node）：在 Telegram 中主動推送訊息或媒體的節點
* UI 相容性（UI Compatibility）：介面與底層功能匹配的程度
* URL 指定方式（Select by URL）：透過 Slack 頻道網址指定目標頻道
* Ubuntu（Ubuntu）：常用於伺服器的 Linux 發行版
* V3 Fast 模型（V3 Fast）：以速度優先、成本較高的文字轉影片模型
* V3 文字轉影片模型（Veo / V3 Text-to-Video Model）：Google 提供的高品質文字轉影片模型
* V3 模型（Veo 3 / V3）：Google 提供的高擬真文字轉影片生成模型
* Vertex AI API（Vertex AI API）：Google Cloud 提供的 AI 模型呼叫介面
* Vertex AI（Google Vertex AI）：Google Cloud 上用於訓練、部署與呼叫機器學習模型的平台
* Vertex AI（Vertex AI）：Google Cloud 提供的機器學習與生成式 AI 平台
* Volume（資料卷）：Docker 中用於保存資料的儲存空間
* Web 爬蟲 API（Web Scraper API）：透過 API 擷取網頁內容的服務
* Webhook URL（Webhook URL）：Slack 用來傳送事件資料至工作流程的端點
* cURL 匯入（Import cURL）：將 API 文件中的 cURL 指令直接轉換為工作流設定
* cURL 匯入（Import cURL）：將 API 文件中的 cURL 指令轉換為節點設定
* cURL 匯入（Import cURL）：將 API 文件的 cURL 指令轉換為節點設定
* cURL 指令（cURL Command）：用於測試與呼叫 API 的命令列工具語法
* cURL 指令（cURL）：以指令列方式呼叫 API 的工具與語法
* compose.yaml（Compose File）：描述多個服務與網路設定的設定檔
* docker ps（Docker PS）：列出目前執行中容器的指令
* 上下文視窗長度（Context Window Length）：模型可回顧的歷史對話數量
* 上下文視窗（Context Window）：模型可同時考慮的文字範圍
* 上游節點輸出（Upstream Output）：前一個節點產生並傳遞給下一節點的資料
* 主旨生成（Subject Generation）：由模型自動產生郵件主旨
* 事件時間戳（Event Timestamp）：Slack 事件發生的精確時間記錄
* 事件訂閱（Event Subscriptions）：設定 Slack 將特定事件推送給外部系統的機制
* 事件訂閱（Event Subscription）：讓應用接收特定事件通知的 Slack 機制
* 二進位轉換（Binary Conversion）：將 Base64 字串還原為實際檔案的過程
* 今日變數（Today Variable）：動態取得當前日期並注入流程的系統變數
* 以使用者身分發送（Send as User）：讓訊息看起來像由真人帳號發送
* 任務完成狀態（Completed Status）：表示外部處理已完成的狀態值
* 任務識別碼（Request ID）：用於追蹤生成任務並查詢結果的唯一 ID
* 任意事件觸發（Any Event Trigger）：對所有符合條件事件進行監聽的觸發方式
* 低程式碼自動化（Low-code Automation）：以最少程式碼建構自動化流程的方法
* 低程式碼（Low-code）：以最少程式碼完成系統建構
* 作業名稱（Operation Name）：識別長時間作業的唯一名稱
* 使用者 ID（User ID）：發送 Slack 訊息的使用者唯一識別碼
* 使用者互動式工作流（Interactive Workflow）：需要使用者中途回覆才能繼續的流程
* 使用者回覆輸入（User Text Response）：由使用者在聊天中提供的文字指令
* 使用者忽略清單（User Ignore List）：避免工作流回應特定使用者或自身訊息
* 使用者提示（User Prompt）：提供給模型的主要任務指令與需求說明
* 使用者提示（User Prompt）：由使用者提供、引導 AI 產生回應的輸入內容
* 使用者提示（User Prompt）：由使用者輸入、作為生成內容基礎的文字描述
* 使用者提示（User Prompt）：由使用者輸入、驅動模型生成內容的文字指令
* 使用者提示（User Prompt）：由使用者輸入並驅動模型生成內容的文字
* 使用者權限範圍（User Scope）：允許應用以使用者身份執行操作的權限設定
* 使用者訊息（User Message）：由使用者直接輸入、驅動模型回應的指令
* 使用者註冊（User Signup）：建立本地系統帳號的流程
* 來源連結附加（Source URL Attachment）：在摘要後附上原始新聞連結
* 依 ID 呼叫（Call by ID）：透過模型識別碼直接指定模型
* 假分支（False Branch）：條件不成立時執行的流程路徑
* 傳送圖片節點（Send Photo Node）：用於向聊天平台發送圖片的動作節點
* 儲存 URI（Storage URI）：指定輸出檔案存放位置的路徑
* 內部系統整合（Internal Integration）：與企業內部資料庫或服務進行私有整合
* 公網 IP（Public IP Address）：可從網際網路存取的伺服器位址
* 公開 API（Public API）：不需驗證即可存取的應用程式介面
* 公開分享權限（Public Sharing Permission）：允許外部系統存取檔案的設定
* 公開存取連結（Public Access URL）：可被外部系統或 API 存取的檔案網址
* 公開存取連結（Public Access URL）：可被外部系統讀取的檔案網路連結
* 公開權限設定（Public Sharing Setting）：允許任何人透過連結存取檔案的權限配置
* 公開聊天介面（Public Chat Interface）：允許外部使用者透過網址互動的聊天入口
* 公開連結（Public Web Content Link）：可供外部系統存取的 Google Drive 檔案 URL
* 分支流程（Branching）：工作流中同時或分別執行多條路徑
* 動作節點（Action Node）：在工作流中實際執行操作的節點
* 動作類型（Action Type）：描述觸發事件性質的欄位，例如送出訊息
* 動態內容生成（Dynamic Content Generation）：由模型即時生成變動內容
* 動態參數綁定（Dynamic Parameter Binding）：依流程輸出即時填入節點欄位
* 動態表達式（Dynamic Expression）：在節點中動態引用前序資料的語法
* 動態表達式（Expression）：在節點中以變數或邏輯動態產生值的機制
* 動態變數（Dynamic Variable）：在工作流執行時自動變化的即時資料欄位
* 動態輸入綁定（Dynamic Input Binding）：將前一節點輸出動態綁定到下一節點輸入
* 動態頻道回覆（Dynamic Channel Reply）：依事件來源自動回覆對應頻道或對話
* 匯入 cURL（Import cURL）：自動將 cURL 指令轉換為工作流設定的功能
* 即時互動（Real-time Interaction）：Slack 與工作流程之間的即時雙向通訊
* 即時回傳（Inline Response）：不經儲存直接回傳結果資料的方式
* 即時文件查詢（Live Document Query）：在回應前動態讀取最新文件內容
* 即時時間變數（Now Variable）：系統自動產生的當前時間值
* 即時時間變數（Now Variable）：系統自動產生的當前時間參數
* 即時時間變數（Now Variable）：系統自動產生的當前時間變數
* 即時資訊擷取（Real-time Information Retrieval）：從網路或 API 取得最新資料的能力
* 即時通知（Real-time Notification）：在事件發生時即刻通知使用者的機制
* 即時通訊整合（Messaging Integration）：將輸出傳送至 Telegram、Slack 等平台
* 即時通訊整合（Messaging Platform Integration）：透過 Telegram 等通訊平台作為工作流程互動入口
* 即時通輸出（Messaging Output）：將結果發送至 Slack、Telegram 等平台的方式
* 原始 JSON 主體（Raw JSON Body）：以完整 JSON 格式直接傳送的請求內容
* 原始碼複製（Git Clone）：將遠端儲存庫完整下載至本機的操作
* 去重邏輯（Deduplication Logic）：避免同一內容被重複處理或輸出的判斷規則
* 可擴展性（Extensibility）：系統支援新增功能與整合的能力
* 可讀性格式化（Readability Formatting）：調整段落、間距與標示以提升閱讀體驗
* 向量資料庫（Vector Database）：以向量形式儲存語意資訊
* 向量資料庫（Vector Database）：以向量形式儲存資料以支援語意搜尋的資料庫
* 向量資料庫（Vector Database）：用於儲存與搜尋向量嵌入的資料庫
* 品質與成本取捨（Quality-Cost Tradeoff）：在生成效果與執行費用之間的平衡決策
* 啟動模板（Starter Kit）：快速建立標準環境的預設專案配置
* 回圈流程（Looping Flow）：未完成時重複等待與查詢的流程設計
* 回寫編輯器（Copy to Editor）：將歷史執行資料回填至編輯模式以便測試
* 回應自然化（Response Naturalization）：讓 AI 回覆更貼近人類語言風格的調整
* 回退模型（Fallback Model）：主要模型失效時替代執行的模型
* 固定模式（Fixed Mode）：欄位內容為固定不變文字的設定方式
* 圖像提示代理（Image Prompt Agent）：專門負責將簡單描述轉為高品質圖像提示的 AI 節點
* 圖片訊息推送（Send Photo）：透過 Telegram 發送圖片給使用者的操作
* 執行個體（Instance）：雲端中運行的一台虛擬主機
* 執行子工作流節點（Execute Subworkflow Node）：用於呼叫其他工作流的控制節點
* 執行日誌（Execution Logs）：顯示節點內部處理流程與狀態的紀錄
* 執行節點（Execute Step）：手動啟動節點以回應 Slack Challenge 的動作
* 執行紀錄（Execution Log）：記錄每次工作流執行狀態與資料的紀錄
* 執行記錄（Executions）：保存每次流程執行輸入與輸出的歷史紀錄
* 基底網址（Base URL）：API 請求的主要服務端點
* 基礎設施即服務（IaaS, Infrastructure as a Service）：提供虛擬化運算資源的雲端服務模式
* 基礎設施維運（Infrastructure Maintenance）：持續管理與更新伺服器環境的工作
* 多代理系統（Multi-agent System）：多個 AI agent 協同完成任務
* 多模型存取（Multi-model Access）：透過單一平台呼叫不同供應商模型的能力
* 多模態生成（Multimodal Generation）：結合文字、影像、影片等多種資料型態的生成方式
* 多輸入工作流（Multi-input Workflow）：需要同時接收多種輸入資料（如圖片與文字）的流程設計
* 多輸入觸發（Multi-input Trigger）：需要同時接收影像與文字描述等多種輸入條件的觸發機制
* 多重輸入設計（Multi-input Design）：同時需要圖片與文字提示作為流程啟動與處理依據的架構
* 大型語言模型（LLM, Large Language Model）：能理解與生成自然語言的 AI 模型
* 大型語言模型（Large Language Model, LLM）：提供語言理解與生成能力的核心模型
* 大型語言模型（Large Language Model, LLM）：驅動 AI agent 的語言理解與生成核心
* 天氣 API（Weather API）：提供即時或預測天氣資訊的服務介面
* 失敗防護流程（Fail-safe Loop）：避免流程中斷的重試設計
* 失敗防護（Failure Guard）：避免任務未完成時導致整個工作流中斷的設計
* 失敗防護（Failure Guard）：避免流程因未完成結果而中斷的設計
* 媒體生成（Media Generation）：利用 AI 生成影像、影片或音訊的總稱
* 子工作流觸發器（Executed by Another Workflow Trigger）：專供被其他工作流呼叫的觸發方式
* 子工作流（Sub-workflow）：將大型流程拆分為可重用的小型流程單元
* 子工作流（Sub-workflow）：被主流程呼叫、負責特定任務的獨立流程模組
* 字串（String）：文字型資料
* 安全 Cookie 設定（Secure Cookie Setting）：控制 Cookie 傳輸安全性的設定
* 安全合規（Security Compliance）：符合企業或法規對資料與系統安全的要求
* 安全最佳實務（Security Best Practice）：避免硬編碼敏感資訊的設計原則
* 安全群組（Security Group）：控制雲端主機進出流量的防火牆規則
* 完成狀態檢查（Completion Status Check）：判斷影片生成是否完成的邏輯
* 完成狀態（Completed Status）：表示任務已成功處理完成的狀態值
* 完成狀態（Completed Status）：表示影片生成任務已完成的狀態值
* 完成狀態（Completed Status）：表示生成任務已完成並可取得結果的狀態
* 完成狀態（Completed Status）：表示非同步任務已處理完成的狀態值
* 完整控制權（Full Control）：對系統設定、資源配置與存取權限擁有完全掌控
* 官方支援（Official Support）：由平台提供的技術支援與問題排除服務
* 客服代理（Customer Support Agent）：自動回應客戶問題的 AI 系統
* 容器化部署（Containerization）：將應用與其依賴封裝為可攜式容器
* 容器化（Containerization）：將應用與其相依環境封裝為可移植單位的技術
* 容器（Container）：由映像檔啟動的執行實例
* 容錯設計（Fault Tolerance）：避免因暫時錯誤導致整個流程中斷的設計
* 實驗環境差異（Environment Differences）：雲端、實驗室與自託管版本的功能差別
* 專案 ID（Project ID）：Google Cloud 中用於識別專案的唯一名稱
* 專案 ID（Project ID）：Google Cloud 專案的唯一識別名稱
* 專案狀態文件（Project Status Document）：集中記錄專案進度與資訊的文件來源
* 專案（Project）：Google Cloud 中的資源與設定單位
* 對話上下文（Conversation Context）：先前互動所形成的語意背景
* 對話記憶（Conversation Memory）：保留上下文以維持連續對話的一致性
* 對話識別鍵（Session Identifier）：用來區分不同對話上下文的識別值
* 嵌入（Embedding）：將文字轉為向量表示的技術
* 工作區監聽（Workspace-wide Listening）：監控整個 Slack 工作區訊息的設定
* 工作流分段（Workflow Segmentation）：將複雜流程拆分成多個邏輯區段的設計
* 工作流可擴充性（Workflow Extensibility）：能隨需求新增節點與邏輯的能力
* 工作流可讀性（Workflow Readability）：流程結構是否清晰易懂
* 工作流執行（Workflow Execution）：實際運行自動化流程
* 工作流實驗環境（Workflow Sandbox）：用於測試自動化流程的隔離環境
* 工作流程分拆（Workflow Segmentation）：將大型流程拆解為多個子流程的設計策略
* 工作流程啟用（Activate Workflow）：將流程切換為正式對外運作狀態
* 工作流程整合（Workflow Integration）：將 Slack 與 AI、記憶模組串接的整體設計
* 工作流程節點（Workflow Node）：構成自動化流程的基本模組
* 工作流程連結附加（Include Workflow Link）：Slack 訊息中自動附加工作流程來源連結
* 工作流穩定性（Workflow Stability）：流程在錯誤或延遲情況下仍能正常運作的能力
* 工作流穩定性（Workflow Stability）：確保流程在各種情況下持續運作的能力
* 工作流編排（Workflow Orchestration）：協調多個節點依序或分支執行
* 工作流編排（Workflow Orchestration）：協調多個節點與步驟完成複雜任務的設計
* 工作流編排（Workflow Orchestration）：將多個節點依邏輯順序組合成自動化流程
* 工作流自動化平台（Workflow Automation Platform）：以節點化方式建立自動化流程的系統
* 工作流自動化（Workflow Automation）：以節點串接方式自動執行任務流程
* 工作流自動化（Workflow Automation）：以視覺化流程將人工任務轉為自動執行
* 工作流自動化（Workflow Automation）：透過節點與邏輯編排，自動執行重複性任務的技術
* 工作流迴圈（Workflow Loop）：透過排程與條件檢查反覆執行相同流程的設計模式
* 工作流迴圈（Workflow Loop）：透過條件與回跳實現重複執行的流程
* 工作流重用（Workflow Reusability）：可在不同情境下重複使用的流程設計
* 工作表選擇（Sheet Selection）：指定文件內實際要讀寫的工作表
* 工作表（Worksheet / Sheet）：試算表中的單一分頁
* 工作階段 ID（Session ID）：用來識別同一聊天互動流程的唯一識別碼
* 工具使用決策（Tool Calling Decision）：AI 判斷是否需要呼叫外部工具的能力
* 工具可替換性（Tool Swappability）：在不影響核心邏輯下更換外部工具或服務
* 工具呼叫（Tool Calling）：AI 主動使用外部功能或 API
* 工具掛載（Tool Attachment）：讓 AI 代理可存取外部資料來源的設定方式
* 工具描述（Tool Description）：提供模型判斷是否使用該工具的說明文字
* 工具節點（Tool Node）：供 AI 代理呼叫外部系統或服務的功能節點
* 工具自動選擇（Automatic Tool Selection）：由模型自行判斷是否呼叫工具的能力
* 工具誤用風險（Tool Misuse Risk）：模型可能在不必要時使用或忽略工具的問題
* 工具附加（Tool Attachment）：讓 AI 節點可存取外部資料來源的機制
* 已授權網域（Authorized Domains）：允許 OAuth 流程合法運作的網域清單
* 布林值（Boolean）：真或假的邏輯值
* 平台型生成服務（Generation Platform）：提供多種生成模型與 API 的集中式平台
* 平台聚合（Model Aggregation Platform）：整合多種模型於單一 API 的服務模式
* 幻覺（Hallucination）：AI 生成看似合理但實際不正確的內容現象
* 建立時間欄位（Created Date Column）：記錄影像上傳或建立時間的欄位
* 引用來源（Citations）：AI 回應中所依據的新聞連結或資料來源清單
* 影像 URL 擷取（Image URL Retrieval）：從資料表中讀取最新影像連結的流程
* 影像來源解析（Image Source Resolution）：確定影片生成所使用的影像來源
* 影像參考輸入（Image Reference Input）：影片生成模型用來參考的原始圖片
* 影像日誌表（Image Log Sheet）：專門記錄影像 URL 與時間戳的資料表
* 影像日誌表（Image Log Sheet）：用於記錄影像 URL 與時間的試算表
* 影像生成模型（Image Generation Model）：負責產生圖片內容的深度學習模型
* 影像紀錄表（Image Log）：用於保存影像來源與時間的結構化資料表
* 影像網址欄位（Image URL Column）：儲存影像公開存取連結的資料欄位
* 影像轉影片工作流程（Image-to-Video Workflow）：以靜態圖片為基礎並結合文字提示自動生成影片的流程設計
* 影像轉影片工作流（Image-to-Video Workflow）：以靜態圖片為基礎，結合文字指令生成動態影片的自動化流程
* 影像轉影片流程（Image-to-Video Workflow）：以靜態圖片與文字提示為輸入，自動生成影片的完整自動化流程
* 影片下載連結（Video URL）：指向生成影片資源的存取網址
* 影片回傳節點（Send Video）：將生成完成的影片透過 Telegram 傳送給使用者
* 影片完成狀態（Completion Status）：表示影片生成是否已完成的狀態值
* 影片提示代理（Video Prompt Agent）：專門生成影片描述提示的 AI 節點
* 影片提示代理（Video Prompt Agent）：專門負責產生高品質影片提示詞的 AI 元件
* 影片提示代理（Video Prompt Agent）：負責將使用者描述轉換為專業影片生成提示的 AI 節點
* 影片提示代理（Video Prompt Agent）：負責生成專業影片生成提示的 AI 節點
* 影片提示代理（Video Prompt Agent）：負責生成適合影片模型的結構化提示詞的 AI 節點
* 影片提示生成代理（Video Prompt Agent）：專門負責產生高品質影片提示詞的 AI 節點
* 影片生成 API（Video Generation API）：負責依提示與影像生成影片的外部服務介面
* 影片生成提示詞（Video Generation Prompt）：用於描述影片內容、風格與動作的文字說明
* 影片生成模型（Image-to-Video Model）：將影像與文字轉換為影片的模型
* 影片生成模型（Video Generation Model）：專門用於產生影片內容的 AI 模型
* 影片生成模型（Video Generation Model）：負責產生動態影像內容的生成模型
* 影片輸出（Video Output）：模型生成的最終影片結果
* 影片長度設定（Video Duration）：指定生成影片播放時間的參數
* 影片長度（Video Duration）：控制生成影片播放時間的設定
* 影片長度（Video Duration）：生成影片的時間長度設定
* 影片風格控制（Video Style Control）：定義影片視覺風格的提示設計
* 影片風格控制（Video Style Control）：透過提示詞指定畫面風格與敘事方式
* 憑證儲存區（Credential Store）：系統中安全保存所有 API 與 OAuth 憑證的位置
* 憑證測試（Credential Testing）：驗證 API 金鑰是否可正常使用
* 憑證管理（Credential Management）：集中管理與重複使用 API 金鑰的機制
* 憑證重用（Credential Reuse）：在多個節點或工作流中共用相同驗證資訊
* 憑證類型（Credential Type）：集中管理與重複使用 API 驗證資訊的設定物件
* 應用重新安裝（App Reinstallation）：權限變更後重新授權應用的必要步驟
* 成員管理（Channel Members）：管理頻道中使用者與應用程式的設定區
* 成員識別碼（Member ID）：Slack 中唯一標識使用者的系統 ID
* 成本控制（Cost Control）：透過資料釘選與測試避免不必要 API 呼叫的做法
* 成本控制（Cost Control）：避免重複呼叫高成本模型以降低費用的策略
* 成本控制（Cost Management）：依模型與使用頻率規劃 API 使用費用
* 成本計算（Cost Per Run）：每次模型執行所消耗的費用
* 手動觸發器（Manual Trigger）：由使用者手動啟動的工作流觸發節點
* 手動觸發器（Manual Trigger）：由使用者手動啟動的流程起點
* 手動觸發器（Manual Trigger）：需由使用者手動點擊才能啟動的測試用觸發節點
* 持久化儲存（Persistent Storage）：在容器重啟後仍保留資料的機制
* 挑戰式學習（Challenge-based Learning）：以問題驅動、實作導向的學習模式
* 授權標頭（Authorization Header）：HTTP Header 中用於身份驗證的欄位
* 授權範圍（Scope）：定義 OAuth 權杖可存取 API 資源範圍的設定
* 排程自動化（Scheduled Automation）：依固定時間週期自動執行的工作流行為
* 排程觸發器（Schedule Trigger）：依照固定時間或週期自動啟動工作流的觸發器
* 接收全部資料（Accept All Data）：將上一流程的所有輸出直接傳遞
* 推理模型（Reasoning Model）：強調邏輯推理與分析能力的 AI 模型類型
* 提示工程（Prompt Engineering）：設計與優化提示以引導模型產生理想結果的方法
* 提示工程（Prompt Engineering）：設計與優化提示詞以提升模型輸出的技術
* 提示工程（Prompt Engineering）：設計高品質提示以控制模型行為的技術
* 提示工程（Prompt Engineering）：設計高品質提示以提升模型輸出的技術
* 提示工程（Prompt Engineering）：透過精細設計提示提升 AI 回應品質的技術
* 提示詞工程（Prompt Engineering）：設計與優化提示詞以提升生成結果品質的技術
* 提示詞工程（Prompt Engineering）：設計與優化輸入提示以獲得更好生成結果的技術
* 搜尋代理（Search Agent）：專門負責查詢外部搜尋引擎或 AI 搜尋服務的代理
* 搜尋新鮮度（Recency Filter）：限制搜尋結果只包含最近時間範圍內的資料
* 摘要內容（Summarized Content）：由前置模型或工具壓縮後的重點資訊
* 操作模式（Operation）：定義工具具體要執行的行為，例如傳送
* 擴展性（Scalability）：系統隨需求成長而擴充的能力
* 收件者推斷（Recipient Inference）：由模型自動判斷郵件接收者
* 數值（Number）：整數或浮點數資料
* 文件檢索工具（Document Retrieval Tool）：用於讀取與查詢文件內容的工具節點
* 文件選擇（Document Selection）：指定要操作的 Google 試算表文件
* 文字內容綁定（Text Binding）：將 Slack 訊息文字作為 AI 輸入的流程
* 文字轉圖片（Text-to-Image）：將文字描述轉換為靜態影像的生成技術
* 文字轉影像（Text-to-Image）：依據文字描述生成對應影像的生成式 AI 技術
* 文字轉影片（Text-to-Video）：依據文字提示生成動態影片內容的模型能力
* 文字轉影片（Text-to-Video）：將文字描述轉換為影片內容的生成技術
* 文字轉影片（Text-to-Video）：將文字描述轉換為影片內容的生成技術
* 文字轉影片（Text-to-Video）：根據文字提示生成動態影片內容的生成流程
* 新聞去重機制（Deduplication Mechanism）：避免重複處理或發送相同新聞內容的邏輯
* 新聞摘要（News Summary）：將多個資訊來源濃縮成重點敘述的結果
* 新聞日誌表（News Log Sheet）：用來記錄過往新聞標題與日期的 Google 試算表
* 新聞檢查代理（News Checking Agent）：負責比對歷史新聞並移除重複項目的代理
* 日期欄位（Date Column）：用來標記新聞發佈或記錄時間的欄位
* 日誌比對代理（Log Comparison Agent）：將新資料與歷史紀錄進行比對的 AI 或邏輯節點
* 日誌記錄（Logging）：將處理過的資料永久保存以供後續比對與查詢
* 映像檔（Image）：Docker 容器的唯讀模板
* 映像管理（Image Management）：下載、更新與刪除 Docker 映像的作業
* 時間戳記（Timestamp）：標記事件或輸出的發生時間
* 最新資料列擷取（Latest Row Fetch）：取得試算表中最後一筆資料的邏輯
* 最新資料列擷取（Latest Row Retrieval）：從試算表中讀取最新一筆資料的邏輯
* 最新資料擷取（Latest Record Retrieval）：從資料來源中取得最新一筆紀錄的操作
* 服務啟動（Service Startup）：啟動並運行容器化服務的流程
* 服務帳戶（Service Account）：用於伺服器對伺服器驗證的帳戶機制
* 服務暴露風險（Service Exposure Risk）：系統對外開放可能帶來的安全風險
* 本機服務埠（Localhost Port）：本地端應用對外開放的連接埠
* 本機模型（Local LLM）：在本地硬體上執行的大型語言模型
* 本機端部署（Local Deployment）：在個人電腦上執行服務的方式
* 格式化代理（Formatter Agent）：負責整理、重組與美化輸出內容的 AI 代理角色
* 條件判斷節點（If Condition Node）：根據條件結果決定流程走向的控制節點
* 條件判斷節點（If Node）：依條件結果分流流程走向的控制節點
* 條件判斷節點（If Node）：根據條件分流流程的控制節點
* 條件判斷節點（If Node）：根據條件決定流程走向的控制節點
* 條件判斷節點（If Node）：根據條件結果分支流程的控制邏輯
* 條件判斷（Conditional Logic）：依條件決定流程走向
* 條件回應（Conditional Response）：根據是否有新資料決定輸出內容的行為
* 條件節點（IF Node）：依任務狀態分流工作邏輯的控制節點
* 條件節點（IF Node）：依條件判斷分支執行流程的節點
* 條件節點（If Node）：根據邏輯判斷分流工作路徑的節點
* 標頭驗證（Header Authentication）：將 API 金鑰或權杖放在 HTTP Header 中進行驗證
* 標頭驗證（Header Authentication）：將驗證資訊放入 HTTP Header 的方式
* 標頭驗證（Header Authentication）：將驗證資訊放置於 HTTP Header 的方式
* 標題欄位（Headlines Column）：儲存新聞標題或摘要內容的欄位
* 模型 ID（Model ID）：用於指定要呼叫的 AI 模型版本識別碼
* 模型供應商（Model Provider）：提供 LLM 服務的平台或公司
* 模型清單（Model List）：平台可用模型的集合
* 模型版本選擇（Model Version Selection）：依品質與成本需求選擇不同模型版本
* 模型識別碼（Model ID）：用於指定特定 AI 模型的唯一識別字串
* 模型識別碼（Model ID）：用於指定特定模型的唯一字串
* 模型選型（Model Selection）：根據品質、成本與需求選擇合適模型的過程
* 模型選擇策略（Model Selection Strategy）：依品質、成本與需求選擇合適模型的決策
* 模型選擇（Model Selection）：依需求選擇合適語言模型的設定流程
* 模型選擇（Model Selection）：根據需求選擇合適 AI 模型的過程
* 模組化設計（Modular Design）：以獨立模組組成系統以利維護與擴充
* 模組化設計（Modular Design）：將系統拆分為可重用單元以降低複雜度的架構方式
* 檔案建立事件（File Created Event）：當新檔案上傳時觸發的自動化事件
* 檔案建立事件（File Created Event）：當新檔案上傳至資料夾時觸發的事件類型
* 檔案建立事件（File Created Event）：當新檔案被上傳時觸發的特定事件類型
* 檔案權限（File Permission）：控制檔案可讀寫執行權限的設定
* 檔案轉換節點（Convert File Node）：用於處理檔案格式轉換的節點
* 檢查代理（Checking Agent）：專門用於比對、驗證與去重資料的 AI 代理
* 檢索增強生成（RAG, Retrieval Augmented Generation）：結合外部資料來源提升回應準確度
* 檢索增強生成（Retrieval Augmented Generation, RAG）：先檢索資料再生成回應的架構
* 欄位定義傳遞（Define Using Fields）：僅傳遞指定欄位資料以簡化介面
* 歷史資料持久化（Data Persistence）：將資料長期保存以供後續查詢與比對
* 歸屬標示（Automation Attribution）：顯示訊息由自動化流程產生的標記
* 歸屬標記（Attribution Footer）：系統自動附加於郵件底部的來源說明
* 歸屬關閉（Disable Attribution）：移除 Slack 訊息中的自動化來源標示
* 每日摘要排程（Daily Digest Scheduling）：設定每日自動產生並寄送新聞摘要的機制
* 泛用憑證（Generic Credential）：可重複使用的通用驗證設定
* 流程拆分（Workflow Separation）：將大型流程拆成多個子流程以提升維護性與除錯效率
* 深度研究模型（Deep Research Model）：適合產出長篇、結構化研究內容的 AI 模型
* 清單選擇方式（Select from List）：從可用頻道清單中選擇目標頻道
* 測試 URL（Test URL）：僅用於測試階段的 Webhook 接收網址
* 測試事件擷取（Fetch Test Event）：用於測試觸發器是否正常運作的功能
* 瀏覽器實驗室（Browser-based Labs）：無需本地安裝即可操作的線上實作環境
* 無工具聊天模式（Tool-less Chat）：AI 僅進行對話、不呼叫外部工具的運作模式
* 無驗證請求（Unauthenticated Request）：不需要 API Key 或 Token 的請求方式
* 版本更新（Version Updates）：系統功能與安全修補的升級流程
* 物件（Object）：由鍵值對組成的結構
* 狀態判斷（Status Check）：依據回傳狀態值決定後續流程的邏輯
* 狀態旗標（Done Flag）：表示任務是否完成的布林值
* 狀態檢查（Status Check）：判斷任務是否完成的邏輯
* 狀態檢查（Status Check）：確認任務是否完成或仍在處理中的判斷步驟
* 狀態警示（Change Indicator）：提示節點設定已變更、需重新執行的標記
* 狀態輪詢（Status Polling）：反覆查詢任務狀態以確認是否完成的模式
* 狀態輪詢（Status Polling）：定期檢查任務狀態以確認是否完成的流程設計
* 環境變數檔（.env File）：集中管理應用設定參數的檔案
* 環境變數（Environment Variables）：用於設定應用行為的外部參數
* 環境隔離（Environment Isolation）：不同部署環境之間相互獨立的設計
* 生成品質調校（Generation Tuning）：透過提示與參數微調提升生成結果品質
* 生成時長（Video Duration）：影片輸出的時間長度設定
* 生產 URL（Production URL）：工作流程正式上線後使用的 Webhook 接收網址
* 生產環境推送（Production Deployment）：將工作流程正式啟用並定期自動執行
* 生產級工作流（Production-ready Workflow）：可穩定運行於正式環境、具備錯誤處理能力的流程
* 用戶測試名單（Test Users）：允許存取未驗證應用的測試帳號
* 用戶端密鑰（Client Secret）：OAuth 中用來驗證應用程式身份的私密金鑰
* 用戶端識別碼（Client ID）：OAuth 中用來識別應用程式的公開識別碼
* 畫面比例（Aspect Ratio）：定義輸出影像或影片寬高比的參數
* 畫面比例（Aspect Ratio）：影片寬高比設定，例如 16:9
* 當前日期變數（Current Date Variable）：系統自動提供的即時日期時間參數
* 發送操作（Send Operation）：設定 Slack 節點執行傳送訊息的動作
* 真分支（True Branch）：條件成立時執行的流程路徑
* 知識來源工具（Knowledge Source Tool）：為 AI 提供事實依據的外部資料節點
* 短期記憶（Short-term Memory）：維持對話連續性的暫存記憶
* 硬編碼參數（Hardcoded Parameter）：在流程中直接固定設定、不隨輸入變化的參數
* 硬編碼參數（Hardcoded Parameter）：直接寫死在節點中的固定值設定
* 硬編碼識別碼（Hardcoded ID）：在流程中直接固定使用的識別碼設定方式
* 硬編碼（Hard Coding）：將敏感資訊直接寫死在參數或程式碼中的不安全作法
* 確定性流程（Deterministic Flow）：不依賴模型判斷、每次必定執行的流程設計
* 社群節點限制（Community Node Limitation）：不同部署方式對擴充節點的支援差異
* 社群節點（Community Nodes）：由社群開發的擴充節點
* 社群節點（Community Node）：由社群開發並分享的非官方功能節點
* 空結果處理（Empty Result Handling）：在沒有新資料時回傳替代訊息的策略
* 第三方工具整合（Third-party Tool Integration）：透過 API、Webhook 或 MCP 將外部服務接入工作流
* 等待節點（Wait Node）：在工作流中暫停指定時間的控制節點
* 等待節點（Wait Node）：在流程中延遲執行以等待結果的節點
* 等待節點（Wait Node）：在流程中暫停指定時間以等待結果的節點
* 等待節點（Wait Node）：在流程中暫停指定時間再繼續執行的控制節點
* 等待節點（Wait Node）：在流程中暫停指定時間再繼續執行的節點
* 等待節點（Wait Node）：暫停流程以等待外部任務完成的控制節點
* 等待節點（Wait Node）：讓工作流暫停一段時間以等待外部任務完成
* 等待節點（Wait Node）：讓工作流暫停一段時間再繼續執行的節點
* 管理儀表板（Admin Dashboard）：集中管理工作流與設定的介面
* 節點串接（Node Chaining）：確保每次流程執行時固定依序執行各節點
* 節點停用（Deactivate Node）：暫停節點參與流程執行的設定
* 節點執行按鈕（Execute Step）：僅執行單一節點而非整個流程的功能
* 節點輸入輸出（Node Input/Output）：節點之間資料流動與傳遞的基本機制
* 節點重新執行（Execute Step）：單獨執行某一節點進行測試
* 節點（Node）：工作流中的最小功能單元，代表一個動作或觸發
* 範例工作流程（Demo Workflow）：預先載入的示範自動化流程
* 範例請求（Sample Request）：官方文件提供的簡化 API 呼叫範本
* 範本市集（Template Marketplace）：提供現成工作流範例以加速開發的平台
* 簡易記憶（Simple Memory）：基於最近互動次數保存上下文的基礎記憶機制
* 粗體標示（Bold Highlighting）：使用粗體強調公司名稱或重大更新
* 系統人格提示（Persona System Prompt）：定義 AI 行為與語氣的角色設定提示
* 系統提示工程（System Prompt Engineering）：設計模型角色與輸出規範的提示方法
* 系統提示（System Prompt）：定義 AI 行為與角色的高優先指令
* 系統提示（System Prompt）：定義模型角色、行為與輸出格式的背景指令
* 系統提示（System Prompt）：定義模型角色、行為邊界與整體任務目標的高優先提示
* 系統提示（System Prompt）：用來定義 AI 行為、角色與規則的高優先指令
* 系統提示（System Prompt）：用於定義 AI 行為與角色的指令內容
* 系統提示（System Prompt）：用於定義模型角色、規則與輸出格式的隱性指令
* 系統提示（System Prompt）：用於約束與定義 AI 行為與角色的高優先級指令
* 系統更新（System Update）：安裝最新安全修補與套件的作業
* 系統編排（System Orchestration）：協調多個服務與流程協同運作的能力
* 系統訊息（System Message）：用來定義模型角色、行為與限制的高優先提示
* 終端機（Terminal）：以指令方式操作系統與程式的介面
* 結構化擷取（Structured Extraction）：將非結構化內容轉為結構化資料
* 結構化資料（Structured Data）：具有固定欄位與層級的資料
* 結構化輸出（Structured Output）：確保模型輸出符合預期欄位與型別
* 結構描述（Schema）：以結構化方式定義資料欄位，方便後續拖曳與對應
* 結構描述（Schema）：將 JSON 資料以型別結構方式呈現的格式
* 維運成本（Maintenance Overhead）：自行維護系統所需的人力與時間成本
* 聊天 ID（Chat ID）：Telegram 對話的唯一識別碼
* 聊天模型（Chat Model）：用於即時對話回應的語言模型類型
* 聊天觸發器（Chat Trigger）：以即時文字輸入作為工作流啟動條件的節點
* 聊天觸發節點（Chat Trigger）：透過即時文字輸入啟動工作流的觸發機制
* 聊天訊息觸發器（On Chat Message Trigger）：當接收到聊天輸入時即時啟動工作流程的觸發節點
* 聊天識別碼（Chat ID）：唯一標識 Telegram 對話的參數
* 聊天輸入內容（Chat Input）：使用者在聊天介面中輸入的實際文字內容
* 自動化管線（Automation Pipeline）：由多個節點串接而成的自動處理流程
* 自架部署（Self-hosting）：由使用者自行管理伺服器、環境與安全性的部署方式
* 自然語言生成（Natural Language Generation, NLG）：AI 將結構化資料轉換為人類語言的能力
* 自行託管（Self-hosting）：在自有環境中部署與管理應用服務
* 自行託管（Self-hosting）：將系統部署於自有伺服器或私有雲環境
* 自託管環境（Self-hosted Environment）：自行部署與管理的執行環境
* 處理中狀態（Processing Status）：表示任務仍在執行中的狀態值
* 表格視圖（Table View）：將資料以表格形式呈現，方便快速檢視
* 表達式模式（Expression Mode）：以變數或 JavaScript 表達式動態填值的設定
* 表達式（Expression）：在節點中動態引用前序資料
* 表達式（Expression）：用來存取、計算或組合前序節點資料的語法
* 視覺一致性（Visual Consistency）：確保生成內容在風格與構圖上的一致性
* 觸發節點（Trigger Node）：啟動工作流的起點事件
* 觸發節點（Trigger Node）：用來啟動整個工作流的起始節點
* 觸發節點（Trigger Node）：用來啟動整個工作流的起始節點
* 觸發節點（Trigger Node）：用來啟動整個工作流程的起始節點，當指定事件發生時自動執行流程
* 訂閱制（Subscription Model）：以月費或年費形式支付使用雲端服務的計費模式
* 訊息內容（Message Text）：使用者在 Slack 中輸入的文字內容
* 訊息分發節點（Message Dispatch Node）：負責將內容傳送到指定平台的節點
* 訊息與模型操作（Message & Model Operation）：以單次訊息搭配模型進行回應生成的操作模式
* 訊息觸發器（On Message Trigger）：當使用者發送訊息時啟動的觸發節點
* 訊息觸發器（On Message Trigger）：當收到新訊息時啟動流程的事件節點
* 訊息說明文字（Caption）：附加在圖片或影片下方的文字說明
* 訊息說明（Caption）：附加在圖片或影片下方的文字提示
* 訊息輸出節點（Message Output Node）：將最終結果發送到通訊平台的節點
* 記憶機制（Memory Mechanism）：讓 AI 保留過往互動資訊
* 記憶機制（Memory Mechanism）：讓 AI 工作流保留並利用歷史資訊的設計
* 記憶節點（Memory Node）：用來保存對話上下文的節點
* 記憶節點（Memory Node）：讓 AI 能記住先前 Slack 對話內容的模組
* 試算表文件（Spreadsheet Document）：Google Sheets 中的資料容器
* 試算表查詢工具（Google Sheets Tool）：供 AI 節點查詢試算表資料的工具
* 試算表讀取工具（Google Sheets Get Rows）：從 Google Sheets 讀取資料列的操作
* 試算表追加列（Append Row）：將新資料新增至 Google Sheets 下一個可用列
* 認證標頭（Authorization Header）：HTTP 中用於傳遞驗證資訊的欄位
* 認證標頭（Authorization Header）：HTTP 標頭中專門用於傳遞身份驗證資訊的欄位
* 語言模型存取（LLM Access）：透過 API 呼叫大型語言模型的能力
* 請求 ID（Request ID）：用於查詢非同步任務結果的唯一識別碼
* 請求 ID（Request ID）：用於識別特定 API 任務的唯一識別碼
* 請求識別碼（Request ID）：用於追蹤非同步任務的唯一識別值
* 讀取列操作（Get Rows Operation）：從試算表中擷取既有資料列的操作
* 變數拖放（Variable Mapping）：將前一節點輸出拖入下一節點欄位的操作
* 變數插入（Variable Injection）：將其他節點的輸出動態插入提示中的機制
* 資料傳遞模式（Data Passing Mode）：主工作流與子工作流之間的資料交換方式
* 資料回填（Data Replay）：將過往執行資料重新載入編輯器的操作
* 資料型別（Data Type）：資料的基本分類
* 資料夾監控（Folder Monitoring）：定期掃描資料夾以偵測新增或變更檔案的機制
* 資料契約（Data Contract）：明確定義工作流之間資料格式的設計概念
* 資料持久化（Persistent Storage）：容器重啟後仍能保留資料的機制
* 資料橋接（Data Bridging）：在不同節點或系統間傳遞資料的設計方式
* 資料流程控制（Data Flow Control）：管理資料在節點間傳遞與使用的邏輯
* 資料流（Data Flow）：資料在節點之間傳遞的過程
* 資料釘選（Data Pinning）：固定節點輸出以避免重複消耗 API 資源
* 資料釘選（Data Pinning）：固定節點輸出以防止重複消耗 API 資源
* 資料釘選（Pin Data）：固定測試資料以避免重複觸發成本操作
* 資料釘選（Pin Data）：固定節點輸出以避免重複呼叫外部服務
* 資料釘選（Pin Data）：固定節點輸出資料以避免重複執行與消耗 API 資源
* 資源限制（Resource Limitation）：雲端平台對 CPU、記憶體或執行數量的配額限制
* 資源類型（Resource Type）：指定 Slack 節點操作的對象，例如訊息
* 資源類型（Resource Type）：指定工具操作的對象，例如郵件
* 身分模擬（Impersonation）：AI 模擬特定使用者語氣與風格進行回應
* 身分驗證（Authentication）：確認使用者或系統身分的安全機制
* 輪詢機制（Polling Mechanism）：定期檢查任務狀態直到完成的流程設計
* 輪詢機制（Polling Mechanism）：定期檢查任務狀態直到完成的流程設計
* 輪詢機制（Polling Mechanism）：定期檢查任務狀態直到完成的設計
* 輪詢機制（Polling Mechanism）：定期檢查任務狀態直到完成的設計
* 輪詢端點（Polling Endpoint）：用於查詢作業狀態的 API URL
* 輪詢請求（Polling Request）：定期查詢任務狀態直到完成的策略
* 輸入承接（Input Binding）：自動將前一節點輸出作為目前節點輸入的機制
* 輸入負載（Input Payload）：節點接收到的資料內容
* 輸出管道（Output Channel）：將結果傳送到 Email、Slack 等平台
* 輸出節點（Output Node）：將結果傳送至外部系統的節點
* 輸出結果（Output Result）：節點處理後產生的資料
* 輸出資料（Output Data）：由節點產生並傳遞給下一個節點的資料
* 輸出連結（Output URL）：生成完成後取得影像或影片的存取連結
* 迴圈控制（Loop Control）：透過條件與等待反覆執行流程的設計
* 迴圈控制（Loop Control）：透過條件與等待節點反覆執行直到滿足條件
* 迴圈機制（Loop Mechanism）：重複執行流程直到條件滿足的設計
* 追加列操作（Append Row）：將新資料寫入試算表下一列的操作方式
* 追加列操作（Append Row）：將新資料寫入試算表下一空列的操作
* 通知管道抽象化（Notification Channel Abstraction）：可替換 Gmail、Slack、Telegram 的輸出設計
* 連接埠轉發（Port Mapping）：將容器服務對外開放的網路設定
* 連線測試（Connection Test）：驗證第三方服務憑證是否正確設定的流程
* 進行中狀態（In-progress Status）：表示任務尚未完成的狀態值
* 進行中狀態（Processing Status）：表示生成任務尚未完成的狀態
* 部署彈性（Deployment Flexibility）：依需求選擇不同部署環境的能力
* 郵件主旨固定化（Static Subject）：使用不隨內容變動的主旨設定
* 郵件代理（Email Agent）：可自動撰寫與寄送郵件的 AI 節點
* 郵件內容綁定（Message Binding）：將上游節點輸出綁定為郵件本文
* 郵件固定收件者（Fixed Recipient）：設定每次寄送到相同電子郵件地址
* 郵件格式（Email Format）：定義郵件內容類型，如純文字或 HTML
* 郵件歸屬移除（Attribution Removal）：關閉系統自動附加的寄送來源標示
* 郵件節點（Gmail Node）：將生成結果透過電子郵件發送的輸出節點
* 重新導向 URI（Redirect URI）：OAuth 驗證完成後回傳授權結果的指定網址
* 重新導向 URI（Redirect URI）：OAuth 驗證完成後的回傳位址
* 重新導向 URL（Redirect URI）：OAuth 流程中回傳授權結果的網址
* 重用性（Reusability）：流程或元件可在多個場景中重複使用的特性
* 重複新聞過濾（Duplicate News Filtering）：透過比對歷史紀錄移除重複新聞的流程
* 重複檢查代理（Deduplication Agent）：用於避免重複處理或發送相同資訊的邏輯節點
* 重試機制（Retry Mechanism）：在失敗時自動重新嘗試執行的設計
* 重試機制（Retry Mechanism）：失敗後自動再次嘗試
* 金鑰對（Key Pair）：SSH 驗證用的公開金鑰與私密金鑰
* 錯誤處理（Error Handling）：在流程發生異常時進行攔截與修復的機制
* 錯誤處理（Error Handling）：流程失敗時的應對機制
* 錯誤防護（Failure Prevention）：避免流程因未完成任務而中斷的設計策略
* 錯誤隔離（Error Isolation）：將錯誤限制在單一模組中以降低影響範圍
* 長時間作業（Long-running Operation）：需要輪詢狀態才能取得結果的 API 任務
* 長時間運作任務（Long-running Operation）：需要多次查詢結果的雲端生成任務
* 長期記憶（Long-term Memory）：可長期保存並檢索的知識
* 閃電圖示（Lightning Icon）：用來辨識觸發節點的視覺標記
* 開源平台（Open-source Platform）：原始碼公開、可自行部署與擴充
* 防火牆規則（Security Group Rules）：控制伺服器進出流量的安全設定
* 附加列操作（Append Row Operation）：將新資料新增到試算表底部的操作
* 陣列（Array）：多個元素組成的清單
* 除錯效率（Debugging Efficiency）：快速定位並修正錯誤的能力
* 集中式溝通介面（Centralized Communication Interface）：統一接收與回覆使用者輸入的溝通平台
* 集中式通訊入口（Centralized Communication Channel）：用單一平台（如 Telegram）作為人機互動與流程控制入口
* 雲端主機（Cloud VM）：由雲端供應商提供的虛擬伺服器
* 雲端平台（Cloud Platform）：提供託管與運算資源的線上服務
* 雲端虛擬機（EC2 Instance）：AWS 提供的可彈性配置運算資源
* 雲端託管（Cloud Hosting）：由官方平台代管基礎設施、更新與維運的部署模式
* 雲端託管（Cloud Hosting）：由第三方雲端平台提供運算與維運服務的部署方式
* 雲端資源監控（Cloud Resource Monitoring）：追蹤 CPU、記憶體與磁碟使用狀況
* 電子郵件節點（Gmail Node）：透過 Gmail 發送通知或結果的整合節點
* 非原生整合（Non-native Integration）：透過 HTTP 或 API 方式連接非內建服務
* 非同步 API 模式（Async API Pattern）：先提交任務再查詢結果的 API 設計
* 非同步任務（Asynchronous Job）：需要等待處理完成才能取得結果的任務模式
* 非同步任務（Asynchronous Task）：需等待處理完成後才能取得結果的任務
* 非同步任務（Asynchronous Task）：需要時間處理並透過狀態查詢取得結果的任務模式
* 非同步作業（Asynchronous Operation）：需等待背景處理完成的長時間任務
* 非同步影片生成（Asynchronous Video Generation）：需要等待處理完成的影片生成模式
* 非同步處理（Asynchronous Processing）：請求提交後需等待後端完成的處理模式
* 非同步處理（Asynchronous Processing）：請求提交後需等待背景處理完成的機制
* 非同步處理（Asynchronous Processing）：請求提交後需等待處理完成的模式
* 非結構化資料（Unstructured Data）：如文字、圖片等無固定結構資料
* 音訊生成（Audio Generation）：影片中同時產生背景聲音的能力
* 音訊生成（Audio Generation）：是否同時產生影片背景音或聲音的功能
* 順序執行（Sequential Execution）：節點依連線順序執行
* 預設連接埠 5678（Default Port 5678）：n8n 本地實例常用的服務埠
* 頻道 ID（Channel ID）：Slack 頻道的唯一識別碼
* 頻道 URL（Channel URL）：可用來識別或設定頻道來源的網址
* 頻道作為 Session（Channel as Session）：以 Slack 頻道 ID 作為對話記憶的依據
* 頻道監聽（Channel Listening）：設定工作流程僅接收特定 Slack 頻道的事件
* 頻道訊息回覆（Channel Reply）：將 AI 回應直接發送到原 Slack 頻道
* 風格描述（Style Descriptor）：用於指定影像或影片藝術風格的提示詞元素
* 高價值任務（High-value Tasks）：需要人類判斷、創意或策略的工作內容
* 高可用性（High Availability）：系統持續運作並降低停機時間的能力
* 高擬真度（High Fidelity）：影片在畫面與音效上的真實程度
* 高擬真度（High Fidelity）：影片畫面細節與真實感的品質指標