Risuai 自架指南：多供應商 LLM 角色扮演前端的能力邊界

Risuai 想解決的是提示詞散落各處的問題

多數人玩 LLM 角色扮演的起點是一個聊天視窗加上一份貼在系統提示裡的角色設定。角色一多，設定就散在記事本、瀏覽器書籤與不同供應商的後台之間；換一顆模型，整個提示詞又要重貼一次。Risuai 把這件事收斂成單一應用程式：角色卡、世界設定、提示詞順序、情緒圖片、語音輸出都放在同一個介面裡，模型則透過多家 API 接入。README 對自己的定位寫得很直白，是一套跨平台的 AI 聊天軟體與網頁應用，主打多 API 支援、聊天內嵌資產與正則功能。

目標使用者不是只想隨手聊兩句的人，而是會花時間調提示詞的人。README 列出的功能裡，提示詞順序可調整、可在提示中扮演角色、可用條件與變數，這幾項只有在反覆微調時才有意義。另一類使用者是自架派：他們不想把對話交給某個託管服務，寧願自己跑一個網頁前端，把 API key 留在自己手上。

技術堆疊與資料流：Svelte 5 前端、Tauri 外殼、你的 API key

從 repository 的徽章與說明可以看出，前端是 Svelte 5 搭配 TypeScript 5.9 與 Tailwind CSS 4，建置工具是 Vite 8，桌面版外殼用 Tauri 2.5。這個組合意味著同一份前端程式碼可以走兩條路：在瀏覽器裡當網頁應用跑，或包進 Tauri 變成桌面程式。Docker 部署文件也印證了網頁這條路是官方支援的場景，README 直接寫明這個方法特別適合網頁託管。

資料流的方向不難推斷：使用者在介面輸入，前端組出提示詞，送往使用者在設定裡選定的供應商，回覆再回到前端做後處理。README 提到的正則腳本就是在回覆進到畫面之前動手腳，用正則改寫模型輸出，官方舉的用途是做出自訂 GUI。外掛則更進一步，README 說可以加入功能與供應商並分享出去，等於把供應商適配層也開放給社群。長期記憶是另一條線：README 列出 HypaMemoryV2/V3 的記憶壓縮與 SupaMemory 的上下文管理，用來維持長對話的連貫性。這些機制的實作細節在 README 裡沒有展開，wiki 被標註為 Work in Progress，要評估就得直接讀原始碼。

安裝路徑有三條，先確認 Node 版本再動手

README 給的建議路徑是官方網站 risuai.net，其次是 GitHub Releases 下載。要自己跑，開發前置條件寫得很明確：Node.js 20.19+ 或 22.12+，套件管理器用 pnpm。這個版本門檻不是裝飾，Vite 8 與 Svelte 5 對 Node 版本有要求，用 18 或更舊的版本大概率會在安裝階段就失敗。

Docker 這條路最短，README 給的是單行指令，把遠端的 docker-compose.yml 直接餵給 docker compose：

curl -L https://raw.githubusercontent.com/kwaroran/Risuai/refs/heads/main/docker-compose.yml | docker compose -f - up -d

啟動後在瀏覽器開 http://localhost:6001。這裡有個實際的取捨：這個指令每次都會抓取 main 分支上的 compose 檔，等於把部署內容交給上游即時決定。要固定版本，就該把 compose 檔抓下來自己保存，而不是每次重跑那行 curl。至於 API key 與供應商設定放在哪個設定檔、有沒有環境變數可以注入，README 沒有交代，這是要自己部署時第一個會撞到的空白。

外掛與正則腳本：可組合，也代表你繼承了別人的程式碼

Risuai 的擴充方式是兩層。淺的一層是正則腳本，針對模型輸出做字串替換，用來改造顯示格式或抽出特定片段。這一層的風險可控，因為它只作用在文字上。深的一層是外掛，README 說它可以新增功能與供應商，並且能分享。能分享就意味著你會載入別人寫的程式碼，而這些程式碼跑在你的環境裡，握有你設定的 API key 與對話內容。README 沒有描述外掛的權限模型或沙箱機制，所以採用前該自己看一眼外掛實際能碰到什麼。

供應商清單同樣值得注意。README 列出的包括 OpenAI、Claude、Gemini、DeepInfra、Ooba、OpenRouter，並以 and More 收尾。這份清單是 README 當下的說法，不是保證；真正要確認某個供應商能不能用，得看程式碼或外掛目錄，而不是看功能列表。

長期記憶是賣點，也是最少文件的一塊

HypaMemoryV2/V3 與 SupaMemory 被放在功能列表的最後，但它們處理的是角色扮演最難的問題：對話拉長之後，模型還記不記得前面發生過什麼。README 的說法是記憶壓縮與上下文管理，用途是維持長期對話的上下文。壓縮代表有資訊會被丟掉，丟什麼、怎麼丟，決定了角色會不會突然失憶或性格走鐘。README 沒有給出壓縮策略、觸發門檻或可調參數，wiki 又標著 Work in Progress。

這不是說功能不能用，而是說它的行為無法從文件預測。如果你的用途是幾十輪的短對話，這塊根本不會被觸發，可以忽略；如果你要跑數百輪的長篇，就得自己讀實作、自己觀察壓縮前後的回覆差異。把這一項當成需要驗證的功能，而不是可以信任的規格。

什麼時候不該用 Risuai

第一種情況是你想要一個託管服務。Risuai 的網頁版在 risuai.net，但自架版本要你自己處理 API key、網路暴露與更新。放在公網上又沒有額外驗證層，等於把一個能呼叫你付費 API 的介面公開出去，這件事 README 沒有討論，Docker 章節也只講到 localhost。

第二種情況是你的團隊無法接受 GPL-3.0。這個授權對內部使用通常沒有問題，但如果你打算把 Risuai 嵌進自家產品再散布，GPL-3.0 的傳染性會牽動你的整個衍生作品。這不是法律意見，只是採用前必須先問清楚的問題。

第三種情況是你只需要一個穩定的 API 客戶端。Risuai 的複雜度來自角色資產、情緒圖片、群組聊天、TTS 與記憶系統，這些你都不用的話，換來的只是更多設定項與更多出錯的地方。

替代方案：SillyTavern 走的是社群外掛路線

同類工具裡最常被拿來對比的是 SillyTavern。兩者的差異不在功能清單長度，而在擴充機制的重心。Risuai 把外掛與供應商適配都放進應用本身，用 TypeScript 與 Svelte 寫成，桌面版靠 Tauri 打包，等於提供一套統一的技術底層。SillyTavern 則以 Node.js 伺服器加上瀏覽器前端的形式運作，擴充多半透過社群外掛與前端腳本。

對使用者的實際差別是：選 Risuai，你得到的是一個有明確技術堆疊與桌面打包路徑的應用，外掛要跟著它的介面走；選 SillyTavern，你得到的是一個社群累積較久、外掛生態更分散的環境。兩者都要自己接 API key，都要自己承擔提示詞調校的成本。真正該問的不是哪個功能多，而是你打算寫外掛還是只用現成的：要寫，Risuai 的 TypeScript 介面比較好追；只用現成的，就去看哪邊有你需要的供應商與腳本。

維護成本與授權：release 節奏快，升級要留退路

從 release 清單看，Risuai 的版本號採日期式命名，v2026.8.250、v2026.8.240、v2026.6.215，其中前兩版只隔一天。這種節奏說明專案在活躍推進，也說明你如果跟著 main 分支跑，隨時可能遇到行為變動。Docker 那行 curl 指令抓的正是 main 分支的 compose 檔，等於每次重啟都在接受最新狀態。要降低風險，就把 compose 檔與映像版本固定下來，升級前先確認 release notes 有沒有動到你依賴的設定鍵。

授權是 GPL-3.0。自用、內部使用通常不觸發散布條件；一旦你要把修改後的版本提供給外部，就得面對原始碼開放的義務。這部分請找法律專業確認，此處只指出這是採用前該納入評估的一項，而不是一句可以略過的細節。

編輯結論

Risuai 適合願意自行管理 API key、且需要把提示詞順序、角色資產與長期記憶集中在一套介面的人；不適合期待開箱即用雲端服務、或無法接受 GPL-3.0 授權條件的團隊。動手前先確認三件事：你的 Node.js 是否為 20.19+ 或 22.12+、Docker 部署後 6001 埠是否可連、以及你打算使用的供應商是否在 README 列出的支援清單內。這三項都對得上，再談提示詞怎麼搬。

官方來源

1. kwaroran/Risuai on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases