ENTRY 002
前端＝面孔：一套 mokagi 核心、多個入口
設計原意：把
core/mokagi.py 的 process_message() 當「身體」，
每個 index.html／前端只是「衣服＋面孔」——同一個身體，換不同衣服＝不同人設與上下文。
差異只靠兩個參數：agent（用哪個 Agent＝哪個 soul 目錄）與
context_files（該 Agent 的 soul/*.md 要載哪幾個）。核心不用改，前端自由長。
① 各入口是否都走 mokagi 對話？
| 入口／前端 | 最終路徑 | 是否進 process_message | context_files | 備註 |
|---|---|---|---|---|
主頁 html/index.html＋main.js | /api/chat/start（舊 /api/chat） | ✅ 是 | 無 | None＝全部 soul 檔；與 TG 同級 |
個人對話 html/user.html | /api/chat | ✅ 是 | ['agent.md'] | 只載 agent.md |
API／客服 html/static/api.js | /api/chat | ✅ 是 | CONFIG.context_files || ['agent.md'] | 沒設時只載 agent.md |
會議模式 html/會議模式/index.html | /api/chat | ✅ 是 | ['agent.md','user.md'] | 不含 soul.md |
直播房3 agent/病毒引擎/jobs/直播房3/index.html | /api/llm_bridge/<agent>（白名單 稚／春／影片女）→ 本機 8935 _llm_bridge.py → /api/chat | ✅ 是（經一層 bridge） | 無 | bridge 再前置注入【直播模式】守則＋真實時間、以 guest 入 core；mokagi 失效時 fallback raw deepseek（此時不走 core） |
Telegram frontends/mok_tg.py | 直接呼叫 core | ✅ 是 | 無 | None＝全部 soul 檔 |
小遊戲 html/game/（/game/、/game2/） | mok_web.py 靜態資產路由 | ❌ 否 | ─ | 不注入 LLM 上下文 |
② 方向對了幾成？欠甚麼？
| 項目 | 狀態 | 說明 |
|---|---|---|
| 一套核心、多前端 | ✅ 已成立 | 所有對話最終都收斂到 process_message()；前端用 agent＋context_files 決定面孔 |
| 換衣服＝換上下文 | ✅ 大致做到 | 使用者／客服／會議已各自指定 context_files |
| 換衣服＝換「面孔／行為」 | ⚠️ 部分 | 目前只差在 soul 檔組合；model、max_tokens、temperature、工具白名單、TTS 聲音等仍綁在 Agent 設定，未能 per-入口 覆寫 |
| 直播房這類「特殊入口」 | ⚠️ 半外掛 | 靠一支獨立 bridge（8935）而非 mok_web 內建；多一層 fallback，行為不完全等同主線 |
| 統一的「入口宣告」機制 | ❌ 缺 | 沒有單一設定（如 frontends.json）集中定義每入口用哪個 agent／context_files／模型；改了要逐頁改 |
| 文件同步 | ❌ 缺 | 本 WIKI 與官方 README 曾落後於程式碼，需手動比對（本條目即為補齊） |
一句話結論：方向對了——核心已成功抽象成「身體」，前端是「衣服」。
已把「上下文」這層外衣做好（
context_files），但還沒把「模型／工具／聲音」也變成可換的外衣，
且缺少集中的入口註冊表，導致入口越多、越依賴各自為政的橋接與手改。