修仙世界模擬器：把每個 NPC 交給 LLM，把規則交給程式碼
基于 AI Agent 工作流的修仙世界模拟器，旨在还原智能、开放的仙侠世界。| An open-source Cultivation World Simulator using Agentic Workflow to create a dynamic, emerging Xianxia world.
秒懂
- 它是什麼？
- 4thfever/cultivation-world-simulator 用 FastAPI 後端加 Vue 3 前端，讓每個修士成為獨立 Agent，再由一套修仙規則約束其輸出。它的核心判斷是：AI 負責決策，規則負責邊界，開發者不寫劇本。
- 適合誰用？
- 如果你要的是一個能改規則、能接外部 Agent、能用 Python 直接調試的 LLM 群像模擬沙盒，這個專案值得先跑一次 Dcoker 或原始碼部署；如果你要的是穩定可預期的遊戲成品，或不想為每個 NPC 的推理付費，它不適合你。先確認三件事：你的模型服務能否穩定支撐多 Agent 並行推理、docker-compose 的 8123 埠與 CWS_DATA_DIR=/data 是否符合你的資料落地要求、以及倉庫的 NOASSERTION 授權條款對二次創作與商業分發的實際約束。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 30 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是「生成文字」，而是「讓一群角色各自行動」
多數 LLM 應用處理的是單輪問答或單一角色的長對話。修仙世界模擬器處理的是另一種問題：場上有大量 NPC，每個都要有自己的性格、記憶、人際關係與行為邏輯，而且這些 NPC 的決策必須互相看得見、互相影響。README 的寫法是每個修士都是獨立的 Agent，可以自由觀測環境並做出決策。
這裡的難點不在生成，而在協調。如果放任 LLM 自由發揮，世界會迅速失控：角色設定漂移、時間線矛盾、數值不合理。專案的解法是把 AI 的想像力限制在一套修仙邏輯框架內，README 明確列出靈根、境界、功法、性格、宗門、丹藥、兵器、武道會、拍賣會、壽元等元素，並稱其為世界運行的基石。
目標讀者因此很明確：想研究多 Agent 湧現行為的人、想做 Agentic Workflow 實驗的人、以及想拿一個現成規則骨架來二次創作的開發者。玩家只是其中一類使用者，而且不是需要讀這篇文章的那一類。
規則系統與 LLM 的分工，決定了這個專案的天花板
從 README 能確認的架構資訊是：後端 Python 3.10+ 搭配 FastAPI，前端 Vue 3 搭配 TypeScript、Vite 與 PixiJS。這意味著模擬狀態由後端持有，前端負責呈現，兩者透過 HTTP API 溝通。
真正值得注意的是它對外暴露的 API 命名空間。README 建議外部 Agent 或自動化腳本圍繞兩個穩定命名空間開發：唯讀查詢走 /api/v1/query/*，受控寫入走 /api/v1/command/*。查詢類的起點介面包括 GET /api/v1/query/runtime/status、GET /api/v1/query/world/state、GET /api/v1/query/events，以及帶 type 與 id 參數的 GET /api/v1/query/detail。寫入類則有 POST /api/v1/command/game/start、POST /api/v1/command/avatar/* 與 POST /api/v1/command/world/*。
把讀與寫拆成兩組前綴，是這個設計裡最務實的一筆。外部程式可以先查 runtime/status 判斷當前是否已開局，未開局再呼叫 game/start 初始化，形成「觀察、決策、干預、再觀察」的閉環。這也解釋了為什麼它同時是遊戲也是模擬器：遊戲介面是給人看的，API 是給程式看的，兩者共用同一套世界狀態。
README 沒有說明的是：這些 Agent 的推理是同步還是非同步、一輪世界推進要呼叫多少次模型、狀態存在記憶體還是資料庫。這些恰好是評估成本時最需要的資訊。
三種部署路徑，對應三種完全不同的人
專案把入口分成三條，而且分工清楚。
想直接玩的人走 Epic Games Store 桌面版，README 說這是免費發布的，安裝後按設定頁提示確認模型配置即可開新局。想改程式碼或除錯的人走原始碼部署，需要 Python 3.10+、Node.js 18+ 與可用的模型服務，指令是 pip install -r requirements.txt，接著 cd web && npm install && cd ..，最後 python src/server/main.py --dev。開發模式會自動拉起前端開發伺服器，README 說通常位於 http://localhost:5173，若沒自動開啟就查啟動日誌。
第三條是 Docker，README 自己在標題旁標註了「未測試」。這點必須照實說：專案作者對這條路徑沒有給出驗證承諾。指令是 git clone 後進目錄執行 docker-compose up -d --build，前端在 http://localhost:8123。容器用 CWS_DATA_DIR=/data 統一持久化設定、金鑰、存檔與日誌，預設映射到宿主機的 ./docker-data，因此 docker compose down 之後再 up 資料仍在。
三條路徑的共同前置條件是模型服務。README 提到的預設包括 DeepSeek、MiniMax 與 Ollama，配置會自動保存到使用者資料目錄。也就是說，這個專案本身不提供模型，它只提供呼叫模型的世界框架。
模型配置是設定頁的事，不是設定檔的事
這個專案在配置上的選擇值得單獨指出：模型預設是在前端設定頁選擇的，而不是要你先編輯某個 YAML。README 反覆強調「在前端設定頁選擇模型預設後，即可開始新遊戲」，並說明配置會自動保存到使用者資料目錄。
這對玩家友善，對自動化部署則是個摩擦點。如果你要在 CI 或無頭環境中啟動，就必須先弄清楚這份自動保存的配置實際落在哪個路徑，而 README 只給出使用者資料目錄這個說法，沒有列出檔名。Docker 情境下可以推斷它在 CWS_DATA_DIR 指向的 /data 之下，但這是推斷，不是文件明言。
唯一被明確點名的唯讀配置是 static/config.yml，README 在講區域網路存取時提到其中的 system.host。要讓後端監聽所有介面，README 建議用環境變數啟動，例如 PowerShell 的 $env:SERVER_HOST='0.0.0.0'; python src/server/main.py --dev，並補充若需改預設值才去動 static/config.yml。把設定分成「執行期環境變數」與「唯讀檔案」兩層，順序寫得明確，這部分文件品質比多數同類專案好。
前端要對外服務則得改 web/vite.config.ts，在 server 區塊加上 host: '0.0.0.0'。README 同時提醒行動端 UI 尚未完全適配，僅供嘗鮮。
成本與不確定性都集中在「每個 NPC 都是一次推理」
最需要讀者自己算清楚的，是推理規模。README 說每個 NPC 都獨立基於 LLM 驅動，有獨立的性格、記憶、人際關係與行為邏輯。這種設計的推論是：世界中的角色越多、推進越久，模型呼叫量越大。
README 沒有給出任何關於單輪成本、並行度或快取機制的說明。這不是文件疏漏可以輕描淡寫帶過的問題，因為它直接決定這個專案能不能長時間跑。用本機 Ollama 可以避開 API 費用，但換來的是推理速度；用雲端 API 則相反。專案把這三種預設並列，等於把取捨交回使用者手上。
另一個不確定性是穩定性。README 標榜湧現式劇情，並說開發者也不知道下一秒會發生什麼。這是產品的賣點，同時也是工程上的風險：沒有預設劇本意味著沒有可回歸測試的固定輸出，行為異常時很難判斷是規則漏洞還是模型抖動。專案聲稱用修仙世界觀與運行規則來避免 AI 幻覺與過度發散，但規則能約束數值與行動選項，約束不了語言層面的偏離。
如果你需要的是可重現、可審計的模擬結果，這個架構會讓你很難受。
與其說它像遊戲引擎，不如說它像一個有前端的 Agent 執行環境
拿它跟傳統文字修仙遊戲比並不公平，因為那些專案的劇情是預先寫好的，分支再多也是有限集合。真正的對照是通用 Agent 框架，例如直接拿 LangGraph 或 AutoGen 之類的工具去搭多 Agent 對話。
差別在約束的來源。通用框架給你的是訊息傳遞、工具呼叫與狀態圖，世界觀要你自己從零寫；修仙世界模擬器則已經內建靈根、境界、功法、宗門、丹藥、兵器、武道會、拍賣會、壽元這一整套數值與關係，並且附帶一套現成的 UI 來觀察這些狀態。你要做的是改規則，不是造世界。
代價是耦合。通用框架的每個元件都可以替換，這個專案的規則與呈現綁在一起，前端用 PixiJS 渲染，後端用 FastAPI 提供狀態。想只取模擬核心、丟掉前端，就得自己沿著 /api/v1/query/* 與 /api/v1/command/* 這兩個命名空間把狀態接出來。README 為這條路留了門，但沒有提供範例程式碼，只列出起點介面。
授權與維護：先別把它當成可依賴的基礎設施
倉庫標示的授權是 NOASSERTION，這在 GitHub 上通常表示授權條款無法被自動識別，或採用了非標準條款。README 沒有提到授權章節，因此從現有材料無法判斷二次創作、商業分發與再授權的邊界。這不是可以靠推測補上的資訊，任何要把它放進商業產品的團隊都應該直接去倉庫確認 LICENSE 檔案的實際內容，而不是依賴這篇文章。
維護節奏方面，材料顯示最近版本為 v4.0.1，時間是 2026-08-02，前一版 v4.0.0 在 2026-08-01，再前一版 v3.9 在 2026-07-19。v4.0.0 到 v4.0.1 只隔一天，屬於修補型發布；v3.9 到 v4.0.0 相隔約兩週，是主要版本跳躍。最後推送時間為 2026-08-16，與 v4.0.1 相隔兩週。
主要版本號在兩週內從 3.9 跳到 4.0，意味著 API 或資料結構存在變動的可能。README 稱 /api/v1/query/* 與 /api/v1/command/* 為穩定命名空間，但穩定的是前綴，不是回應結構。若你要圍繞這組 API 寫外部 Agent，應該預期跟版升級時需要重新核對欄位，並在部署時鎖定具體版本而非追蹤 main 分支。
編輯結論
如果你要的是一個能改規則、能接外部 Agent、能用 Python 直接調試的 LLM 群像模擬沙盒，這個專案值得先跑一次 Dcoker 或原始碼部署；如果你要的是穩定可預期的遊戲成品，或不想為每個 NPC 的推理付費，它不適合你。先確認三件事：你的模型服務能否穩定支撐多 Agent 並行推理、docker-compose 的 8123 埠與 CWS_DATA_DIR=/data 是否符合你的資料落地要求、以及倉庫的 NOASSERTION 授權條款對二次創作與商業分發的實際約束。這三項沒確認之前，不要把它排進正式產品的依賴清單。
社群筆記