Luker 手機裡跑完整 RP 後端——把 SillyTavern 拆成獨立模組的設計取捨

一個手機裡能跑完整後端的 RP 聊天平台

Luker 是一款專為 AI 角色扮演（RP）打造的聊天平台。它不是市面上那種套個聊天界面接 API 的輕量應用——從 SillyTavern（社區俗稱「酒館」）分叉而來的血緣，決定了它要處理的是 RP 玩家真正的痛點：一個車跑幾百樓後角色忘了早期劇情、回覆跳節奏出戲、換模型要重調一整套參數、手機端要折騰 Termux 才能跑完整後端。

直覺上你會覺得，這些問題加起來，做一個更重的前端就能解決。但 Luker 團隊選了一條更激進的路：把 SillyTavern 的整個後端連同前端一起打包進 Android APK，讓手機本身就是完整的 RP 運行時，不需要 Termux、不需要埠轉發、不需要電腦當跳板。

這個決策的後果是 Luker下載 的 APK 體積來到 400MB 量級——同類產品通常只有幾十 MB。代價顯而易見，但為什麼他們甘願付出這個代價？答案藏在它另外幾個獨有設計裡：記憶圖、多 Agent 編排、預設解耦。這幾件事加在一起，才構成 Luker 真正的技術取舍邏輯。

安裝

Luker官網 的安裝包是標準 Android APK，大小約 402MB，下載後點擊安裝即可。第一次啟動時有兩條路：如果你手上有 SillyTavern 的數據（角色卡、聊天記錄、世界書），APK 會彈出導入嚮導，按引導選擇 ZIP 包就能把舊數據整體搬進來，角色卡列表、聊天記錄、預設、API 密鑰全部在位；如果之前沒用過同類平台，直接跳過嚮導進主界面即可。

安裝後的首次配置只有一件事：接入至少一個大模型 API。Luker 本身不帶任何模型，所有回覆都由外部大模型生成——平台的價值在於把你的提示詞、角色卡、記憶、編排結果組織成高質量請求發給模型。連接管理器支援保存多套配置並一鍵切換（日常閒聊掛低成本模型、重要劇情切旗艦模型、離線場景切本地模型），預設與連接解耦，切換連接不會影響你當前的提示詞組合。

需要注意的一個細節：如果你選擇手動搬移數據而不是走嚮導，必須先打開一次 APK 讓它創建數據目錄，再強制停止應用後才開始搬——跳過這兩步是數據出問題的兩大主因。Android 11 及以上對應用私有目錄有訪問限制，不同廠商放行方式不同，嚮導方案完全繞開這個坑。

為什麼把後端塞進 APK——從記憶圖說起

我先說一個生活化的類比幫非技術讀者建立直覺：SillyTavern 的做法像是廚房裡只有一口大鍋，所有東西——角色卡、世界書、系統提示、聊天歷史——全部扔進這口鍋裡煮。鍋子能裝多少、煮得好不好，全靠你不斷攪拌、不斷倒掉舊料給新料騰空間。鍋子就是模型的上下文窗口，煮了幾百樓之後，早期的食材早就沉底糊掉了。

Luker 的做法是把這口大鍋拆成了幾口專用鍋：角色卡是一邊的配菜盤、世界書是案頭的調料罐、聊天歷史是正在煮的主鍋、而記憶圖是掛在牆上的烹調日誌——它不直接下鍋，而是把整個故事裡的關鍵節點（去過哪裡、遇過誰、做了什麼決定）提取成結構化的節點，需要時按語義檢索注入上下文，而不是把全部歷史文本一股腦塞進模型。

這個設計的妙處在於它觸及了 RP 長線運行的一個根本矛盾：上下文窗口是稀缺資源，但故事的前後一致性又是硬性要求。記憶圖把「我要記住什麼」這個判斷從模型身上拿掉，交給一個獨立的圖結構來管理——模型只負責處理當前要講的這段話，記憶圖負責告訴模型「過去發生過什麼相關的事」。這樣做的結果是，一個跑了幾百樓的車，角色仍然能記得十幾樓前去过的那座廢棄工廠，而模型的 Token 消耗卻不會隨著樓數線性增長。

記憶圖的節點檢索流程大致是這樣：每次要發送請求給模型之前，系統先拿當前對話的語義向量去記憶圖裡做近似查詢，找出最相關的幾個歷史節點，把它們的摘要注入提示詞的特定位置。這些注入的節點本身也會被標上「已用」，避免連續幾次請求都重複同一批記憶。整個過程對用戶來說是透明的——你感覺到的只是角色好像真的「記得」之前的事。

這個設計的代價也很實際：記憶圖本身是一張會隨著故事推進不斷增長的數據結構，需要定期清理舊節點、合併重複節點，否則檢索速度會隨著節點數量增加而變慢。Luker 在設置裡提供了記憶圖的自動清理規則配置，也允許手動編輯節點——但這對普通用戶來說無形中增加了一個維護負擔，而 SillyTavern 用戶從來不需要做這件事，因為他們根本沒有這張圖。

多 Agent 編排——為什麼一個模型不能一次幹完所有事

RP 場景裡還有另一個常見問題：回覆跳節奏、忘設定、突然跳出來做總結。SillyTavern 的思路是不斷往系統提示裡加約束條款——「你不能做 X、必須做 Y、如果發生 Z 就回 A」。但提示詞越长，模型對後半段的約束就越敏感、前半段反而容易被忽略，這是 Transformer 注意力機制的固有特點，不是你寫再多條款就能解決的。

Luker文檔 的解法是多 Agent 編排：把原本一個模型要幹的活拆成幾個角色（Agent），每個 Agent 只負責一件事——有的負責跟角色對話、有的負責審查這段對話是否符合世界觀、有的負責決定什麼時候該推進劇情、有的負責把新發生的事寫進記憶圖。Agent 之間透過一個輕量的調度器串起來，調度器維護著一個當前任務的佈程表，每個 Agent 做完自己的事就把結果丟回佈程表，下一個 Agent 接著上。

把一件事拆成多個 Agent 幹的好處是，每個 Agent 的系統提示可以寫得非常精簡、只關注自己的職責——審查 Agent 的提示詞裡不需要包含如何寫對話的規則，寫對話的 Agent 也不需要知道記憶圖怎麼更新。這意味著每個 Agent 的輸出質量會更穩定，因為它的注意力只需要覆蓋一個窄而深的領域。

代價當然是更複雜的調度邏輯和更高的 Token 消耗——你本來一次請求就能拿到一個回覆，現在變成了幾個 Agent 各自發一次請求再把結果拼起來。Luker 預設的編排模式是讓用戶選擇「簡單」或「完整」，簡單模式只啟用對話和審查兩個 Agent，Token 消耗接近傳統單模型模式；完整模式把記憶更新和劇情推進 Agent 也拉進來，長線運行時質量更好但成本翻倍。

預設解耦——為什麼數據能雙向兼容

記憶圖和多 Agent 編排都是 Luker 獨有的數據結構，但它們不會破壞從 SillyTavern 搬過來的舊數據。這個兼容性來自一個設計原則：預設與連接解耦。

傳統 SillyTavern 裡，一套預設是把提示詞條目、採樣參數、連接地址全部綁在一起的。你換個模型，就得重調一整套預設，甚至連角色卡都可能要改。Luker 把這幾件事拆開了：提示詞條目和採樣參數組成「預設」，API 地址和密鑰組成「連接配置」，兩者完全獨立。預設的導出檔是純 JSON、不含任何連接信息，分享給別人不會洩漏你的密鑰；連接配置存在另一個地方，換模型時只需要切換連接，預設原封不動。

這個解耦設計還有一個隱藏好處：它讓 Luker 的獨有數據（記憶圖節點、Agent 編排配置、Skills 技能庫）都能存在各自的狀態文件裡，而不去改動 SillyTavern 已經在用的那批數據檔案。SillyTavern 讀不到這些新文件，自然不會崩壞；哪天你想把數據搬回 Termux 老酒館，把數據目錄裡 SillyTavern 認得的那部分拷回去就能跑，角色卡和聊天記錄原樣保留。

這套原理意味著什麼

把後端塞進 APK、引入記憶圖、做預設解耦——這三件事不是孤立的決策，它們共同指向一個目標：讓手機上的 RP 體驗不需要任何妥協。手機算力有限，但一個輕量的本地後端跑得動；記憶圖在長線運行時比單純堆上下文更省 Token；預設解耦讓你換模型時不用重新配置整套東西。

但這套設計也有明確的邊界。如果你只跑短線對話、一次聊個幾十樓就換下一張卡，記憶圖和多 Agent 編排的好處幾乎體現不出來，反而增加了維護負擔和 Token 成本。如果你主要在電腦上用 SillyTavern、數據從來不離開電腦，那 APK 帶來的手機端便利也對你沒什麼吸引力。

真正適合 Luker 的，是那些把 RP 當成長期項目來經營的玩家——一個車跑幾百樓、有十几張常用角色卡、在電腦和手機之間切換著用、願意花一點時間理解記憶圖怎麼配置。對他們來說，400MB 的 APK 體積和偶爾需要調一下編排模式，換來的是不用折騰 Termux、不用在幾百樓後看著角色忘記自己是誰、不用每次換模型都重調整套預設。

這套設計取捨，某種程度上是在回答一個問題：RP 聊天平台的核心競爭力，到底是「接了多少模型」，還是「能不能讓一個故事真正長期跑下去」。Luker 選了後者，於是有了把後端塞進手機的 400MB APK、有了記憶圖這個看起來有點重的功能、有了預設解耦這個讓數據能雙向兼容的架構選擇。它不是最輕量的 RP 方案，但對那些把長線 RP 當成主要使用場景的玩家來說，這些取捨是值得的。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。