Hexabot v3 的取捨：YAML 工作流、Action 契約與 FCL-1.0-ALv2 授權
Hexabot v3 is an AI workflow automation platform, combining workflows, actions, agents, and conversational channels in one runtime.
秒懂
- 它是什麼？
- Hexabot v3 把工作流、Action、代理與對話通道收進同一個 TypeScript 執行環境，用 YAML 定義流程、用 Zod 定義契約。它的價值在於把 AI 流程寫成可版控的檔案，代價是 Node.js ^24.17.0 的硬門檻與一份非標準的授權條款。
- 適合誰用？
- 如果你需要把 AI 流程寫成可進版控的 YAML 檔、讓非工程角色也能讀懂流程結構，而且團隊的 Node.js 版本可以拉到 ^24.17.0，Hexabot v3 值得開一個專案實測。若你的環境卡在 Node 20 或 22、CI 需要全自動初始化、或者法務對非 OSI 標準授權有否決權，先不要動。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 23 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Hexabot v3 想解決的是流程散落，不是模型不夠強
多數對話式 AI 專案的失敗點不在模型，而在流程。提示詞散在程式碼各處，工具呼叫寫死在 handler 裡，換一個通道就要重寫一次串接邏輯。Hexabot v3 的定位是把這些東西收斂成同一個執行環境：workflow、action、agent、channel 四個概念共用一套 runtime。README 的標語是 Automate the Boring, Keep the Magic，但真正透露意圖的是下一句，用 YAML、tools、MCP、memory 與 RAG 來建構跨通道的 agentic workflow。
目標讀者很明確。第一種是已經在用 n8n 或 LangChain 拼流程、開始覺得流程邏輯與程式碼糾纏不清的團隊。第二種是需要讓非工程角色看懂流程長什麼樣子的組織，YAML 至少比 TypeScript 好讀。第三種是本來就在做多通道客服或行銷自動化、不想為每個通道各寫一份串接層的人。
反過來說，如果你的需求只是單一通道、單一模型的問答機器人，這套東西的抽象層會變成負擔。你得多學一層 Action schema、多維護一份 YAML，換來的跨通道彈性在你身上用不到。
Action 契約與 Binding：Hexabot 把可重用性放在哪裡
README 的 Core Capabilities 列出六項，其中三項構成實際的執行骨架。Action 定義工作流的行為，輸入、輸出與設定都經過 schema 驗證。Binding system 把可重用的能力與設定綁定，跟任務邏輯分開。Schema-first architecture 則說明整套東西大量使用 Zod 做驗證與共用契約。
把這三句放在一起看，設計意圖就清楚了：Action 是可替換的行為單元，Binding 是可替換的連線設定，兩者之間靠 Zod schema 對接。同一個 Action 換一組 Binding，就能從測試環境切到正式環境，或從一家供應商換到另一家。這比把 API key 與端點寫死在 Action 裡的做法乾淨，代價是你必須先定義 schema 才能寫邏輯，前期比較慢。
Memory 與 MCP 是另外兩塊。README 說 memory 有明確的定義與 runtime 整合，MCP 則提供 tool 與 context 的互通點。這裡要注意措辭：README 用的是 integration points，不是完整的 MCP 實作承諾。實際支援到什麼程度，得看 docs.hexabot.ai 與 packages 目錄，這份材料無法確認。
Multi-channel continuity 被列為核心概念，但 README 沒有說明通道抽象層怎麼處理各平台不同的訊息格式與速率限制。這是評估時要自己驗證的地方。
從 npm 安裝到 localhost:3000：實際的啟動路徑
前置條件寫得很死：Node.js ^24.17.0。這個 caret 範圍代表 24.17.0 以上、25.0.0 以下。如果你們的基礎映像還停在 Node 20 或 22，這一步就會卡住，而且是硬卡，不是警告。另外需要一個套件管理器，npm、pnpm、yarn、bun 皆可，Docker 則只有要用 Docker 服務時才需要。
安裝 CLI 有兩種方式。全域安裝是 npm install -g @hexabot-ai/cli。不想裝全域就用 npx @hexabot-ai/cli --help 直接跑。
建立並啟動專案：
hexabot create my-project cd my-project hexabot dev
create 會自動偵測套件管理器，也可以用 --pm 強制指定，例如 hexabot create my-project --pm npm。啟動後預設端點有三個：Admin UI 在 http://localhost:3000，API 在 http://localhost:3000/api，API 文件在非正式環境下位於 http://localhost:3000/docs。
這裡有個容易踩的坑。README 明確寫著 create 會詢問初始管理員帳密，需要互動式終端（TTY），在 CI 或非互動 shell 中必須先在本機終端跑過一次。也就是說，用容器化流程一鍵佈署的團隊，第一次初始化得手動來。這不是 bug，是設計上的取捨，但它會影響你的自動化佈署腳本怎麼寫。
其餘常用指令包括 hexabot start、hexabot stop --docker、hexabot env init、hexabot check、hexabot config show、hexabot migrate。start 支援 --build 與 --services 指定服務清單，stop 支援 -v 一併移除 volume。完整的參數說明在 packages/cli/README.md。
資料層方面，TypeORM 是標準後端，SQLite 是預設的本機選項，Postgres 則被列為正式環境的一級選項。連線透過 DB_TYPE 與 DB_* 這組環境變數設定。本機開發用 SQLite 起手、上線換 Postgres，是文件暗示的路徑。
YAML 工作流與 TypeORM 資料層之間，有幾件事文件沒說
README 把 agentic workflows 描述為 YAML workflow definitions with typed runtime contracts。這句話有兩個關鍵詞：YAML 與 typed contracts。YAML 讓流程可讀、可 diff、可進版控，typed contracts 則意味著 YAML 不是自由格式，它會被對應到型別定義上。
問題在於，這份材料沒有給出任何一份完整的 YAML 範例。工作流的頂層結構長什麼樣、action 怎麼在 YAML 裡被引用、memory 與 MCP 的設定放在哪一層，全部要看 docs.hexabot.ai。這對評估來說是真實的障礙：你無法從 repo 首頁判斷這套 YAML 的學習曲線是半天還是一週。
同樣沒說清楚的還有版本落差。Recent releases 列出的最新版本是 v2.2.2，時間是 2025 年 1 月，而 README 通篇在講 Hexabot v3，最後一次推送是 2026 年 8 月。也就是說 v3 的程式碼在主線上持續推進，但沒有對應的正式 release 標籤。這代表什麼，材料不足以判斷，可能是 v3 還在開發中、以 main 分支為準，也可能是 release 流程尚未跟上。無論哪一種，採用前都該先確認你要追的是 main 還是某個 v2 標籤，兩者的 API 穩定度承諾不一樣。
資料層還有一個未解的問題：TypeORM 的 entity 與 migration 是否跟著 v3 的 schema-first 架構走。CLI 有 hexabot migrate 指令，說明 migration 是既有機制，但 README 沒有交代 Action 或 workflow 定義的變更是否會產生對應的 migration。
FCL-1.0-ALv2：一份需要法務看過的授權
授權欄位在 GitHub 上顯示為 NOASSERTION，README 則寫明 Licensed under FCL-1.0-ALv2，版權方是 Hexastack，年份 2025，完整條款在 LICENSE.md。
FCL-1.0-ALv2 不是 OSI 核准的常見授權，也不是 Apache-2.0 或 MIT 的別名。名稱裡的 ALv2 字樣通常指向 Apache License 2.0 的某種變體，但這只是命名慣例的推測，不能當成事實。NOASSERTION 的意思是 GitHub 的自動辨識無法歸類，這本身就值得注意。
對工程團隊的實際影響是：你不能靠既有經驗判斷這份授權允許什麼。能不能商用、能不能修改後閉源、要不要回饋修改、有沒有商標或專利條款，全部得回到 LICENSE.md 逐條看。這不是法律建議，只是提醒：在把 Hexabot 放進產品路徑之前，讓法務讀過 LICENSE.md，比讀十篇技術評測有用。
授權型態也會影響維護成本的計算方式。如果授權允許你自由 fork，那麼上游停滯時你有退路；如果不允許，上游的活躍度就變成你唯一的依靠。這份材料無法回答這個問題，但它決定了你該用什麼心態評估這個專案。
什麼時候該選 n8n 而不是 Hexabot
最直接的替代方案是 n8n。兩者都提供視覺化或宣告式的工作流，都能串接外部服務與 LLM，差別在抽象層的位置。
n8n 的核心是節點圖，流程在圖形介面上編輯，節點是預先寫好的整合。好處是上手快，幾百個現成節點直接拉；代價是流程本身以 JSON 存在資料庫裡，diff 與 code review 的體驗差，複雜分支一多，圖就變成一團。
Hexabot 走的是另一條路：YAML 檔在工作流這一層，TypeScript 在 Action 這一層，兩者靠 Zod schema 對接。流程定義是文字檔，可以進 git、可以 code review、可以在 PR 裡看到改了哪個節點。代價是沒有幾百個現成節點，你得自己寫 Action，或者靠 extensions 生態補。README 有指向 hexabot.ai/extensions，但這份材料沒有列出實際的擴充數量與維護狀態。
選哪一個，取決於你的流程是「接很多現成服務」還是「有自訂邏輯需要版本控制」。前者選 n8n，後者 Hexabot 的模型更合適。如果你的流程兩者兼具，那就得先確認 extensions 生態能不能覆蓋你的整合需求，這是採用與否的分水嶺。
誰該採用，以及動手前必須驗證的三件事
Hexabot v3 適合已經在做多通道對話自動化、而且團隊有 TypeScript 能力、願意自己寫 Action 的組織。它不適合只想拉幾個節點接起來就收工的人，也不適合 Node.js 版本被凍結在 20 或 22 的環境，更不適合需要全自動 CI 初始化的佈署流程，因為 hexabot create 需要 TTY。
維護成本方面，材料能支持的部分有限。CLI 提供 hexabot check、hexabot config、hexabot migrate 這些維運指令，說明專案有考慮升級路徑。但 v3 沒有對應的正式 release 標籤，最新標籤仍是 2025 年 1 月的 v2.2.2，這讓「升級」這件事的定義變得模糊。追 main 意味著你要自己承擔 breaking change，追 v2 標籤則可能拿不到 README 描述的那些 v3 能力。
動手前請確認：LICENSE.md 中 FCL-1.0-ALv2 對你商業模式的實際約束；hexabot create 在你的 CI 環境是否確實無法非互動執行；以及 packages/cli/README.md 裡 migrate 與 config set 的實際參數與行為。這三項沒確認完，後面的架構評估都是空談。
編輯結論
如果你需要把 AI 流程寫成可進版控的 YAML 檔、讓非工程角色也能讀懂流程結構，而且團隊的 Node.js 版本可以拉到 ^24.17.0，Hexabot v3 值得開一個專案實測。若你的環境卡在 Node 20 或 22、CI 需要全自動初始化、或者法務對非 OSI 標準授權有否決權，先不要動。動手前請確認三件事：LICENSE.md 中 FCL-1.0-ALv2 對你商業模式的實際約束、hexabot create 在你的 CI 環境是否真的無法非互動執行、以及 packages/cli/README.md 裡 migrate 與 config set 的實際參數。這三項沒確認完，後面的架構評估都是空談。
社群筆記