Rivet：把 AI 提示詞鏈變成可視化圖形，但別忘了它背後是 TypeScript
The open-source visual AI programming environment and TypeScript library
秒懂
- 它是什麼？
- Rivet 是 Ironclad 開發的開源可視化 AI 程式設計環境，包含桌面 IDE 與 TypeScript 執行函式庫。它讓開發者用圖形方式編排複雜的 agent 與提示詞鏈，但上手前需要先理解它的圖形模型與整合限制。
- 適合誰用？
- Rivet 適合想要把提示詞鏈與 agent 邏輯視覺化、並需要與自家 TypeScript 程式碼互相呼叫的團隊。它不適合只想要輕量 prompt 管理、或完全不想碰圖形節點的人。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Rivet 解決的是提示詞鏈的除錯與編排問題
寫 AI agent 的人常遇到一個麻煩：提示詞一多、條件分支一多，程式碼裡的邏輯就變成難以追蹤的字串拼接。Rivet 把這個過程搬到圖形介面上，讓你把 prompt、模型呼叫、資料處理畫成節點與連線。它主要服務兩類人：一是想快速實驗複雜 agent 行為的開發者，二是需要把 AI 流程嵌入既有應用程式的 TypeScript 團隊。Rivet 的定位不是 prompt 管理工具，而是一個完整的視覺化程式設計環境，圖形本身可以被執行、除錯，也能被匯出成程式碼。
圖形即程式：Rivet Core 的執行模型
Rivet 分成兩個部分：桌面應用程式負責編輯圖形，Rivet Core 是 TypeScript 函式庫，負責執行這些圖形。關鍵在於 Core 不只被 IDE 使用，也能放進你自己的應用程式。這代表圖形不是靜態的設計稿，而是可被呼叫的執行單元。文件說明，Rivet 可以呼叫你應用程式裡的程式碼，你的應用程式也能呼叫 Rivet 圖形。這種雙向整合讓圖形成為應用邏輯的一部分，而不是隔離的實驗工具。實際運作時，你需要透過 NPM 安裝 @ironclad/rivet-core 或 @ironclad/rivet-node，然後載入圖形檔案並觸發執行。
從下載到串接：實際的啟動路徑
取得 Rivet 最直接的方式是下載預編譯的二進位檔。README 列出 macOS 的 Rivet.dmg、Linux 的 AppImage 與 dmg、Windows 的 Rivet-Setup.exe，都從 GitHub releases 頁面取得。想從原始碼執行，則要參考 CONTRIBUTING.md 的建置說明。整合到應用程式時，官方文件指向 Integration Getting Started 頁面，並提供 @ironclad/rivet-core 與 @ironclad/rivet-node 兩個套件。README 沒有給出安裝指令或程式碼範例，這點對想快速評估的人來說是個門檻，你必須自己連到文件網站找 API 用法。
支援的服務與整合邊界
Rivet 的 LLM 支援涵蓋 OpenAI GPT-3.5 與 GPT-4、Anthropic Claude Instant 與 Claude 2，以及 Claude 3 Haiku、Sonnet 與 Opus。嵌入與向量資料庫方面，支援 OpenAI Embeddings 與 Pinecone。另外還有 AssemblyAI 的 LeMUR 框架與語音轉文字。這份清單決定了你能在圖形裡直接使用的服務，不在清單上的模型或資料庫，就得靠自訂程式碼節點來補。換句話說，Rivet 的便利性高度依賴官方整合的廣度，如果你的主力模型是 Mistral 或 Cohere，圖形介面能直接拖曳的元件就會少很多。
套件分裂與版本節奏：維護成本的訊號
Rivet 的釋出歷史顯示 IDE 與 Core 各自獨立版本。IDE 目前到 app-v1.11.3，Core 則到 v1.25.0，兩者的更新日期也不同步。這種分裂對使用者有實際影響：當你升級 Core 套件時，IDE 可能還是舊版，反之亦然。好消息是兩者都是 MIT 授權，商用或內部使用都少一層法律顧慮。壞消息是，版本不同步代表你必須自己追蹤哪個 IDE 版本對應哪個 Core 版本，文件若沒寫清楚，整合時可能踩到相容性地雷。這是採用前需要確認的重點，不是程式碼品質問題，而是專案治理的現實。
圖形化 AI 程式設計的取捨
Rivet 的圖形模型不是唯一選擇。另一條路是直接用 TypeScript 寫 prompt 鏈，搭配 LangChain 之類的框架，用程式碼控制流程。差別在於 LangChain 把邏輯寫在程式碼裡，除錯時看的是堆疊追蹤與日誌；Rivet 則把流程視覺化，你可以在圖形上看到每個節點的輸入輸出。前者適合習慣傳統開發、需要精細控制執行順序的人，後者適合需要向非工程師展示流程、或想快速重組節點的場景。Rivet 的圖形介面降低了理解門檻，但也把控制權從程式碼轉移到圖形檔案，這對習慣版本控制與程式碼審查的團隊來說，是必須適應的變化。
該不該採用：界線在哪裡
Rivet 最適合的團隊，是已經用 TypeScript、且需要把多步驟 AI 流程視覺化的開發者。它能讓圖形與應用程式碼互相呼叫，這點比純 prompt 工具更接近真實產品整合。不適合的情況有兩種：一是你的 AI 服務不在支援清單內，二是你偏好純程式碼的開發流程。採用前要驗證的事包括：Core 套件能否在你的 Node 版本執行、圖形匯出格式是否容易被 CI/CD 處理、以及 IDE 與 Core 的版本對應關係。Rivet 的 README 對安裝與 API 著墨不多，實際整合成本必須靠文件網站補足，這點在評估時要納入時間預算。
編輯結論
Rivet 適合想要把提示詞鏈與 agent 邏輯視覺化、並需要與自家 TypeScript 程式碼互相呼叫的團隊。它不適合只想要輕量 prompt 管理、或完全不想碰圖形節點的人。採用前應先確認你需要的模型與服務是否在支援清單內，例如 OpenAI、Anthropic Claude 3、AssemblyAI 與 Pinecone，並實際用 @ironclad/rivet-core 跑一個簡單圖形，驗證匯出與執行流程符合你的部署方式。若你的應用重度依賴自訂程式碼或非 TypeScript 環境，Rivet 的圖形模型可能反而增加轉換成本。
社群筆記