可自行架設的流程自動化平台，功能類似 Zapier，但可以裝在自己的伺服器上。
💰 Freemium⚖️ ⚠️ 有條件——不是 OSI 開源🔒 自架不上傳，資料留在自己的伺服器📌 活躍（n8n 官方維護）
不適合沒有人能維護伺服器的團隊、⚠️ 想把它包成自己的服務轉賣給客戶
看完整判斷
你需要注意- ⚠️ fair-code 授權不是開源，轉售與部分功能受限
- 自架要有人維運與更新
- 串接第三方服務時資料仍會送到那些服務
開源的流程自動化平台，定位是 Zapier 的開源替代，可自架且支援 AI 與 MCP。
💰 Freemium⚖️ 社群版可商用（MIT）🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Activepieces 官方維護）
不適合完全沒有技術人力的團隊、需要成熟商業支援的關鍵流程
看完整判斷
你需要注意- 生態比 Zapier 小，冷門服務的整合可能要自己寫
- 自架要有人維運
- 企業版與社群版功能界線要先看清楚
持久化工作流引擎：讓跨越數天、會失敗、要重試的流程能可靠地跑完，狀態不會因為重啟而遺失。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Temporal Technologies 維護）
不適合簡單的定時任務（cron 就夠）、沒有工程人力的團隊、只是要串兩個 SaaS（Zapier 類更快）
看完整判斷
你需要注意- 概念門檻高（workflow／activity／determinism），學習曲線陡
- 自架要維運資料庫與叢集
- 小規模需求是過度設計
Python 的資料工作流編排工具：排程、重試、快取、事件觸發，把腳本升級成能上線的流程。
💰 Freemium⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Prefect 官方維護）
不適合不寫 Python 的團隊、單純兩個系統串接（Zapier 類更快）
看完整判斷
你需要注意- 要寫 Python
- 自架要維運伺服器與資料庫
- 版本之間 API 有過較大變動，升級要看遷移指南
做 AI Agent 的編排框架：支援持久化執行、狀態記憶、以及在流程中插入人工確認。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（LangChain 官方維護）
不適合單次問答就結束的需求（直接呼叫模型就好）、不寫程式的團隊、還沒試過寫死流程（Workflow）就想上 Agent
看完整判斷
你需要注意- ⚠️ Agent 難以驗收——先確認寫死的流程真的做不到再上
- 版本更新快
- 除錯需要搭配追蹤工具才看得清楚
多 Agent 協作框架：用角色分工的方式讓多個 AI 代理人一起完成任務，也支援事件驅動的固定流程。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（CrewAI 官方維護）
不適合單一 Agent 就能做完的任務（多開只會更難驗收）、對輸出穩定性要求高的正式流程
看完整判斷
你需要注意- ⚠️ 多 Agent 的成本與不可預測性都是倍增的，先確認單一 Agent 真的不夠
- Agent 之間的交接容易累積誤差
- 驗收設計比開發更花時間
視覺化的 LLM 應用開發平台：工作流、RAG 管線、Agent、模型管理與觀測一整套，可自架。
💰 Freemium⚖️ ⚠️ 可商用但有兩條硬性限制🔒 自架不上傳（取決於你接的模型）📌 活躍（LangGenius 官方維護）
你會在什麼情況下想到它要做一個「查得到出處」的問答機器人，而你不想從向量庫、切塊、檢索、prompt 組裝一路自己寫。
怎麼用（最短路徑）
- 自架或用雲端版，建一個 workspace（＝一個 tenant，這個詞等一下會咬人）。
- 知識庫丟文件，它幫你切塊建索引；切塊大小與重疊可調，這是後面答不答得準的關鍵。
- 建一個 Chat App 掛上知識庫，prompt 裡把「答不出來就說不知道、並附出處」寫死。
- 拿 API Key 打 /chat-messages，blocking 或 streaming 兩種模式擇一。
- 前面接你自己的管道：LINE、Teams、網頁 widget。
真實案例：產銷履歷法規諮詢 LINE 客服服務約 6,000 位農民本站作者實作
LINE Webhook → Cloudflare Workers 中繼層 → Dify /chat-messages → LINE Reply API
為什麼不讓 LINE 直接打 Dify？中間那層 Worker 看起來多餘，但它做四件 Dify 不會幫你做的事。這是整個案子最值錢的一個決定。
- 驗簽LINE 的 x-line-signature 要用 channel secret 做 HMAC-SHA256 驗證，失敗回 401。沒有這層，任何人都能對你的 endpoint 灌訊息，每一則都燒你的 token。
- 群組防洗版Bot 拉進農民群組後，每句閒聊都會觸發。規則設成只有 @提及，或 #問／#／？／? 開頭才回應。
- 非文字訊息直接丟掉貼圖、照片、位置不進 Dify，不消耗額度。
- 逾時防呆LINE 的 reply token 有時效。Dify 慢了要回一句友善的預設訊息，不能讓農民看到空白。
踩坑
- 授權不是 Apache。官方 LICENSE 兩條硬限制：未經書面授權不得用原始碼經營多租戶環境（官方定義「一個 tenant 對應一個 workspace」），以及不得移除或修改 console 與應用前端的 LOGO 與著作權資訊（原始碼的 web/ 目錄，或 Docker 的 web image）。
- 「幫三個客戶各開一個 workspace」就是多租戶。顧問最常用的交付方式，正好踩在這條上——這是授權問題，不是技術問題。
- 答不準，先回頭調切塊與檢索，不要急著換模型。切塊大小、重疊、取幾段才是主要變因；換更貴的模型通常只是變貴。
- blocking 模式的逾時要自己抓。平台不會替你處理下游（LINE、Teams）的時限。
什麼時候不要用它
- 只有 20 題 FAQ：直接塞進 prompt，不需要向量庫，也不需要平台。
- 要白牌交付給客戶：先把商業授權的錢算進報價再決定。
- 已經有 n8n 或 Make 在跑，而且只是要串一支 API：那段用既有平台就好。
要換的話
RAGFlow（切塊與文件解析更細）、AnythingLLM（更輕、更快上手），或完全不要平台——自己寫檢索直接接模型 API，像上面那個案子的中繼層一樣。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 多租戶與品牌兩條限制是自架公司最容易違反的
- 自架要有人維運（Docker、資料庫、升級）
- 版本更新快，升級前要看遷移說明
視覺化拖拉建 AI Agent 流程的工具。⚠️ 官方 repo 已於 2026-08-13 封存。
💰 Free⚖️ 可商用🔒 自架不上傳（取決於你接的模型）📌 已封存
不適合⚠️ 新專案（上游已封存，不宜當長期基礎）、需要持續安全更新的正式環境
看完整判斷
你需要注意- ⚠️ **官方 repo 已於 2026-08-13 封存**，後續發展要看官方公告
- 新專案建議改用仍在維護的替代方案
- 封存後的安全性更新不可期待
Model Context Protocol 的官方參考伺服器：讓 AI 助理能安全地存取檔案、Git、記憶體等外部工具與資料。
💰 Free⚖️ 可商用🔒 視你接的 AI 服務而定📌 活躍（由 MCP steering group 維護；已封存的伺服器另移他處）
不適合⚠️ 直接拿參考實作上正式環境（官方明說是教育用途）、不寫程式的使用者
看完整判斷
你需要注意- ⚠️ 官方明示這些是參考實作、供教學用，不是 production-ready
- ⚠️ 給 AI 檔案系統存取權限本身就是風險，範圍要收窄
- 社群伺服器品質參差，要個別評估
Anthropic 官方公開的 Agent Skills 範例集：把「怎麼做某件事」寫成 Claude 可以動態載入的資料夾。
💰 Free⚖️ ⚠️ 依個別 skill 而定🔒 訓練政策未查證📌 活躍（Anthropic 官方維護）
不適合⚠️ 未經測試就用在關鍵任務（官方明示為示範與教育用途）、不熟 AI 工具的一般使用者
看完整判斷
你需要注意- ⚠️ 官方免責：僅供示範與教育，實作可能與 Claude 內建行為不同，關鍵任務前要自行充分測試
- ⚠️ 文件類 skill 非開源授權
- Skill 的效果取決於你寫得多清楚，不是複製就會變強
在邊緣節點跑後端程式的無伺服器平台，配 KV 鍵值庫與 D1 SQL 資料庫。本站需要後端的作品（代理外部 API、排程寫資料）都跑這裡。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（Cloudflare 官方營運）
不適合每天寫入量大的資料服務（免費 D1 每天 100,000 列寫入）、重運算（免費方案每次請求 CPU 只有 10 ms）、直接搬 Node 程式上來不改（執行環境不是 Node）
看完整判斷
你需要注意- ⚠️ 額度是每天算的，資料量一大就是長期工程
- 執行環境不是 Node，本機測過不等於線上會跑
- 免費 D1 單庫 500 MB，超過要付費
- KV 同一個鍵每秒只能寫 1 次
跑在 Cloudflare Workers、Deno、Bun、Node 上的輕量 Web 框架：路由、JSON、中介層幾行搞定，用的是 Web 標準的 Request／Response。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Yusuke Wada 與社群維護）
你會在什麼情況下想到它健康家族那種一支 Worker 塞八個小 App、或農漁產行情那種要開幾個查詢端點的後端，原生 `fetch(request)` 裡的 if/else 已經長到看不懂。
怎麼用（最短路徑）
- `npm i hono`，`const app = new Hono()`，`app.get('/x/:id', c => c.json(...))`，`export default app`——wrangler 直接認得。
- 路徑參數 `c.req.param('id')`、JSON body `await c.req.json()`、環境綁定 `c.env.DB`。
- `app.notFound()` 與 `app.onError()` 一開始就寫，不要讓 Workers 回預設的空白錯誤。
- 本機 `wrangler dev --local` 起來，用 Node 的 `fetch` 寫測試腳本打它。
真實案例：一支 Worker：三個端點加 404，接本機 D14 個路由、含 GROUP BY 彙總本站作者實作（最小落地，2026-09-19）
Hono → drizzle-orm/d1 → wrangler dev --local 的 D1
為什麼測試腳本改用 Node fetch，不用 curl？因為 curl 在 Windows 的 Git Bash 下會把中文參數轉成 ANSI 碼頁送出，資料寫進資料庫就是亂碼——這不是 Hono 的錯，但你會先怪它。
- 路由GET /health、POST /prices、GET /prices/:item、GET /stats 加 notFound，全部各回對應狀態碼（201／200／404）。
- 中文參數用 Node fetch 打 `/prices/青江菜` 與 `/prices/%E9%9D%92…` 兩種寫法，`c.req.param()` 都回「青江菜」、查到 2 筆——原生就解碼，不用自己 decodeURIComponent。
- 假警報同一個端點用 Git Bash 的 curl 送「高麗菜」，寫進 D1 的是 CP950 亂碼，查詢當然 0 筆。花了一輪才確認是殼層，不是框架。
- 啟動wrangler dev 幾秒內 Ready，之後每個請求在本機都是毫秒級。
踩坑
- Windows 殼層會污染中文測試。Git Bash 呼叫原生 exe 時中文參數走 ANSI 碼頁；測試一律用 Node 腳本或檔案輸入，不要在命令列打中文。
- 中介層順序就是執行順序。驗簽、CORS 要註冊在路由之前，寫在後面等於沒寫。
- `export default app` 之後 wrangler 的 scheduled（排程）handler 要另外掛，Hono 只接 fetch。
什麼時候不要用它
- 只有一個端點：原生 fetch handler 更短。
- 要 Session、樣板、完整後端：那是 Next.js／Remix 那一層的事，Hono 是路由層。
- 不是跑在 Web 標準執行環境（例如老的 Express 專案）：沒有換的理由。
要換的話
itty-router（更小、更少功能）、原生 fetch handler（單端點）、Cloudflare 自家的 Pages Functions（檔案即路由，適合放在 Pages 專案裡）。
費用、授權、資料政策與維護狀態
你需要注意- 路由靠字串比對，路徑設計要先想好
- 中介層順序決定行為，驗簽要放最前面
- 在 Windows 用 Git Bash 的 curl 測中文會被殼層轉成 ANSI 碼頁，看起來像框架的錯