TauriTavern：把 SillyTavern 從 Node.js 搬到 Rust 桌面殼裡
The classic Sillytavern, now has been rewritten in Tauri/Rust.
秒懂
- 它是什麼？
- TauriTavern 用 Tauri v2 重寫 SillyTavern 的後端，前端仍同步上游 1.18.0，目標是讓不想碰 Node.js 與命令列的人直接安裝使用。代價是它繼承了上游的資料格式，也繼承了上游前端擴充的邊界。
- 適合誰用？
- 如果你要的是免安裝 Node.js、雙擊就能用的角色扮演前端，而且能接受上游前端擴充的限制，TauriTavern 值得先裝穩定版試用；如果你的流程依賴上游的 Node-only 後端插件，或需要自行修改前端邏輯後仍與上游合併，這個專案會讓你卡住。動手前先確認三件事：你的資料目錄能否被應用內匯入流程正確讀取、你常用的擴充是否屬於 Node-only 後端插件、以及你是否能接受 AGPL-3.0 對散布修改版本的要求。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 JavaScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是安裝摩擦，不是功能缺口
SillyTavern 本身功能完整，問題出在取得方式：要先有 Node.js，再進命令列啟動服務，然後用瀏覽器連上去。對熟悉終端機的人這只是幾行指令，對只想匯入角色卡開始聊天的人卻是一道牆。TauriTavern 的定位就寫在 README 的第一句，把上游移植成真正的原生應用，不需要安裝 Node.js，不需要命令列，安裝即用。
目標使用者因此很明確：已經在用 SillyTavern、但被部署流程卡住的人，以及想把同一份體驗帶到 Android 或 iOS 上的人。README 列出五個平台，Windows、macOS、Linux、Android、iOS，並強調桌面與移動是同一份體驗。前端同步上游 1.18.0，資料格式與目錄布局完全相容，這意味著角色卡、聊天記錄、預設、世界書與前端擴充都沿用既有檔案，不需要轉檔。
要注意的是專案自己在 README 裡畫了界線：TauriTavern 是獨立維護的開源專案，並非 SillyTavern 官方客戶端。這句話不是客套，它決定了後面所有相容性問題的責任歸屬。
Rust 後端與前端注入層之間的那道 ABI
README 的架構速覽給出的資訊不多，但足夠畫出形狀。Rust 後端是遵循 Clean Architecture 的 Cargo workspace，放在 src-tauri/crates/ 底下。tauritavern 這個 crate 是 Tauri host、命令層與組合根；tt-application、tt-ports、tt-domain、tt-contracts 分別承載用例、埠、領域模型與跨 crate 契約；實際實作則拆到 tt-adapter-* 系列，涵蓋存儲、HTTP、媒體、同步、擴充、分詞。
前端不是重寫的，而是上游 SillyTavern 加上一層模組化的 Tauri 注入層，位置在 src/tauri/main/。兩邊透過 window.__TAURITAVERN__ 這個平台 ABI 通訊。這個設計的含義是：上游前端的改動可以整批拉進來，但凡是需要碰後端能力的地方，都得在注入層重新接線。
README 把細節指向 docs/BackendStructure.md 與 docs/FrontendGuide.md，本文無法確認這兩份文件的完整內容。可以確定的是，這種分層讓後端邏輯可測試、可替換，代價是每新增一項後端能力，就要同時維護契約、埠與注入層三處。對貢獻者來說，這是一道不低的入門門檻。
安裝路徑比多數桌面應用都多
最直接的方式是從官網下載頁取得安裝檔，README 說頁面會自動識別設備並提供最新穩定版。Windows 便攜版（Portable）需要系統已安裝 WebView2 執行階段，這是 Tauri 應用在 Windows 上的共同前提。iOS 走 TestFlight 公開外測，需要 iOS 16 或更高版本，且 README 明講 TestFlight 版本要遵守蘋果的規則、存在使用限制。
套件管理器覆蓋得相當廣。Windows 用 Scoop：
scoop bucket add Darkatse https://github.com/Darkatse/Scoop-Darkatse.git scoop install Darkatse/TauriTavern
macOS 用 Homebrew：brew install --cask tauritavern。Arch Linux 使用者可從 AUR 安裝 tauritavern-bin，README 註明該套件由 @LX2000WASD 維護。Debian、Ubuntu、Fedora、openSUSE 走官方腳本：
curl -fsSL https://raw.githubusercontent.com/Darkatse/TauriTavern/main/scripts/install-linux.sh | sh
Nix 使用者可執行 nix profile add github:Darkatse/TauriTavern#tauritavern，Flatpak 則需先加入 tauritavern 遠端再安裝 com.tauritavern.client。
Canary 頻道每天更新，README 建議在穩定版遇到問題時先試 Canary，確認問題是否已修。Linux 切換頻道是同一支腳本加參數：sh -s -- --channel canary；Nix 則把來源換成 github:Darkatse/TauriTavern/Canary#canary。從 release 列表看，Canary 與 v2.2.0、v2.1.1 這類穩定版並行發布，兩條線的節奏差很多。
擴充生態是它最明顯的邊界
README 在特性亮點裡寫得很直白：內建原生 Git，安裝、更新、切換分支都在介面內完成，但不支援上游 Node-only 後端插件。這一行決定了誰能無痛搬家、誰會踩空。
前端擴充之所以還能用，是因為前端本來就是上游那一份，跑在 WebView 裡。後端插件不行，因為原本的 Node.js 執行環境已經被 Rust 後端取代，插件預期的伺服器端 API 不存在。如果你目前的流程圍繞某個 Node-only 後端插件建立，TauriTavern 不是替代品，而是缺了一塊的替代品。
內建 Git 這個設計也值得多想一層。它讓擴充的取得不需要離開應用，但 Git 操作本身有分支狀態、有衝突、有本地未提交的改動。README 沒有說明這些情況在介面裡如何呈現，本文也無法確認。對照之下，上游的擴充管理是檔案系統層面的事，出問題時你可以直接進目錄看。這裡多了一層抽象，換來的是移動端也能操作。
同步與 Agent 框架：專案自己長出來的部分
有兩項功能不屬於上游移植的範圍，是 TauriTavern 額外加的。第一項是多設備同步：README 說支援區域網路加密配對同步，或經遠端 TT-Sync v2 自動上傳。第二項是 Agent 框架，包含工具呼叫、Skills、子代理與執行時間線，README 的措辭是持續演進中。
這兩項的性質不同。同步解決的是實際痛點，桌面與手機共用同一份資料，否則多平台支援的意義會打折。Agent 框架則更像方向性投資，README 沒有給出穩定的介面承諾，只說持續演進。要採用的人應該把它當成會變動的部分，而不是可以依賴的固定功能。
另外 README 提到效能工程，包括分階段啟動與聊天虛擬 DOM 載入，並說超長聊天記錄依然流暢。這是專案自己的描述，本文沒有實測數據可以佐證，也不打算替它背書。虛擬 DOM 用在聊天列表上是否會影響搜尋或捲動定位，取決於注入層怎麼接，這要看前端實作才能判斷。
遷移路徑與資料主權
從既有 SillyTavern 搬過來，README 給的路徑是資料匯出腳本加上應用內匯入。因為前端同步上游 1.18.0、資料格式與目錄布局完全相容，理論上不需要轉換格式，只需要把檔案放對位置。
這裡有個實際的判斷點：相容的是格式，不是路徑。你的資料原本放在哪裡、匯入流程掃描哪些目錄、行動端的沙箱目錄怎麼對應，README 沒有展開。真要搬家之前，先確認匯入流程讀得到你的資料目錄，比事後補救省事。
資料自主這點 README 說得清楚，資料完全保存在本地，並支援便攜模式。對在意對話內容不經過第三方伺服器的人來說，這是採用它的主要理由之一。便攜模式配合 Windows 便攜版，可以整包放在隨身碟裡帶著走，前提是目標機器有 WebView2。
授權是 AGPL-3.0。README 自己提醒使用前仔細閱讀許可條款。這裡不提供法律意見，只指出實務上的差別：AGPL 對網路服務的散布有額外要求，如果你打算把修改後的版本架成給他人使用的服務，這條授權的適用範圍和 MIT、Apache-2.0 那類寬鬆授權不同。純粹自己用不涉及散布，情況單純得多。
什麼情況下該選別的方案
最直接的替代品就是上游 SillyTavern 本身。兩者的差異不在功能，而在執行模型：上游是 Node.js 服務加瀏覽器前端，TauriTavern 是單一原生應用。這個差異帶來的取捨很具體。
上游的優勢是後端插件生態完整，而且整個服務跑在哪台機器、開哪個埠、怎麼反向代理，全都在你手上。你要把它架在伺服器上讓多台裝置連進來，上游是自然的選擇。TauriTavern 走的是本機應用路線，同步功能是為多裝置設計的，不是為集中部署設計的。
反過來，如果你的使用場景是單機、想雙擊就開、不想管 Node.js 版本，TauriTavern 的價值就成立。前端同步上游 1.18.0 這件事也意味著介面體驗不會有斷層，切換成本主要落在後端插件與資料路徑上。
還有一個容易被忽略的替代選項：繼續用上游，但用容器或一鍵腳本包裝部署流程。這樣做保留了完整的插件生態，代價是要自己維護那層包裝。選哪邊，取決於你缺的是安裝便利還是後端擴充能力，這兩件事 TauriTavern 只解決了前者。
維護成本與版本節奏
從 release 記錄看，專案同時維護穩定版與 Canary 兩條線。穩定版有 v2.2.0 與 v2.1.1 這類帶版號的發布，Canary 則是日期標記的每日建置。這種節奏對使用者的意義是：遇到問題時有一條可以往前試的路，但 Canary 的穩定性 README 自己承認不如穩定版。
自行建構的門檻寫得很清楚。前置要求是 Rust stable（支援 edition 2024）、Node.js 20.19.x 或 22.12+、pnpm 與 Tauri CLI。常用指令包括 pnpm run check 做前端 guardrails、型別與契約檢查加上 Rust dev check，pnpm run web:build 用 Rspack 打包前端資源，pnpm run tauri:dev 與 pnpm run tauri:build 分別對應桌面開發與發行包，行動端則是 pnpm run android:dev 與 pnpm run ios:dev。
專案還接了 Tauri Pilot 這套開發專用插件，讓 AI Agent 透過可訪問性快照檢查與操作桌面端 WebView。README 強調普通開發與發行命令不會啟用這項能力。要用的話先 cargo install tauri-pilot-cli，再跑 pnpm run tauri:dev:pilot，之後在另一個終端依序執行 tauri-pilot ping、tauri-pilot snapshot -i、tauri-pilot click @e3 這類指令。
至於升級成本，前端跟著上游走意味著每次上游改版都要重新對接注入層，這是長期存在的維護負擔。對單純的使用者來說這件事由維護者承擔；對想自己改前端的人來說，這是你每次合併上游都要重做一次的工作。
編輯結論
如果你要的是免安裝 Node.js、雙擊就能用的角色扮演前端，而且能接受上游前端擴充的限制，TauriTavern 值得先裝穩定版試用；如果你的流程依賴上游的 Node-only 後端插件，或需要自行修改前端邏輯後仍與上游合併，這個專案會讓你卡住。動手前先確認三件事：你的資料目錄能否被應用內匯入流程正確讀取、你常用的擴充是否屬於 Node-only 後端插件、以及你是否能接受 AGPL-3.0 對散布修改版本的要求。這三項都能從 docs/BackendStructure.md、docs/FrontendGuide.md 與 README 的擴充說明裡查到答案，不必先寫程式。
社群筆記