在打造 AI VTuber 的過程中，許多開發者最常面臨的挑戰，就是如何讓角色「看起來像個活生生、有個性的人」，而不是一個只會一問一答的無聊機器人。要突破這個瓶頸，關鍵就在於兩大核心設計：長期記憶 與 主動/自主行為。
本篇文章將基於專案實作經驗，分享如何在有限的預算與硬體配置下，務實地為 AI VTuber 注入靈魂。在閱讀本文前，也建議先閱讀這篇前置文章：AI-VTuber 是什麼-白話入門。
這裡的核心原則是：我們必須誠實面對當前大語言模型（LLM）的能力邊界，先用最省成本、最穩定的做法把「像活的」感覺做出來，而不要一開始就盲目追求讓 AI 去玩高難度的遊戲。
1. 長期記憶的四種層次與設計
目前大多數的 AI VTuber 原型（Prototype）通常只具備短期記憶。也就是說，她們只能記得上下文窗口（Context Window）裡最後 8 輪左右的對話，只要程式一關掉，記憶就會完全歸零。
要幫 AI VTuber 加上長期記憶，由淺到深可以分為以下四種做法：
| 做法 | 怎麼運作 | 成本/難度 | 適合場景 |
|---|---|---|---|
| (a) 事實清單 | 將重要事實寫成靜態檔案（例如「觀眾 A 是常客」、「上次玩過薩爾達」），開場時直接注入 system prompt。 | 零成本、最穩定 | 起步階段首選，最推薦此方案 |
| (b) 滾動摘要 | 當對話長度超過限制時，呼叫 LLM 將舊對話壓縮成摘要並存檔，下次對話時再注入。 | 低（僅需幾分錢的 API 費用） | 適合控制 token 數量、跨天數的記憶 |
| (c) 向量庫 RAG | 將每一條記憶做成向量（embedding）存入 Chroma 或 FAISS 等向量資料庫，需要時透過語意檢索找出最相關的幾條注入上下文。 | 中等；embedding 可以使用本地端模型免費執行（即便用 GTX 1660 顯卡也沒問題） | 記憶量龐大、多個角色需要共享同一個世界觀時 |
| (d) 知識圖譜 | 記錄實體（Entity）與實體之間的關係。 | 高 | 難度極高，多數個人專案其實用不到 |
真正的難點：何時寫入（Write Policy）
長期記憶最大的挑戰不在於「怎麼存」，而在於「什麼時候該記」。如果把每句對話都存下來，記憶庫很快就會充斥垃圾訊息。
目前業界的標準作法是採用「反思（Reflection）」機制： 在每場直播結束後，讓 LLM 回顧整場的對話紀錄，自己萃取出值得長期記住的幾條關鍵資訊，再進行存檔。
這套「記憶流（Memory Stream）+ 重要性評分 + 反思」的框架，最早出自史丹佛大學 2023 年著名的論文 Generative Agents: Interactive Simulacra of Human Behavior（俗稱 AI 小鎮），這也是目前此領域最經典的藍圖。
具體來說，我們需要讓 AI 記住以下三類資訊：
- 角色自身設定與「人生經歷」：用來維持人格的一致性。
- 觀眾互動：記住誰是常客、聊過什麼（需特別注意隱私問題）。
- 事件記憶：玩過的遊戲、直播中發生的趣事。
適合個人開發者的務實路線
如果你的預算有限、想先進行實驗，建議採取以下階段：
- 第 1 階段：先採用 (a) 事實清單 + (b) 滾動摘要。這種純檔案、零成本的做法，對於「一個角色每天進行直播」的場景已經非常足夠且穩定。
- 第 2 階段：等記憶量累積到一定程度，或是想做「一群角色」共享世界觀時，再升級到 (c) 向量庫 RAG，並將 Embedding 步驟放到本地端用免費模型（如 bge-small）跑即可。
2.「自我意識」與自主行為的工程實作
在開始動手前，我們必須先打破一個迷思： 目前的 LLM 並沒有真正的意識或主觀體驗。
像是知名 AI VTuber “Neuro-sama” 看起來之所以「有自我、會主動」，完全是透過工程編排出來的錯覺。它是由：① 主動迴圈、② 人格一致性、③ 長期記憶 這三要素堆疊出來的。只要這三點做好，觀眾就會覺得她像是活的。這本質上仍是程式碼的藝術，而非 AI 真的覺醒。
2.1 如何創造自主行為：主動迴圈
一般的 prototype 都是被動式的：必須等使用者在聊天室打字，AI 才會回應。 要讓 AI 看起來具有「自主性」，關鍵就在於加入一個主動迴圈（Active Loop）。
即使聊天室沒人說話，系統也會定時（例如每隔一段時間）去「戳」一下 LLM，問它：「你現在想說點什麼或做點什麼？」 如此一來，AI 就會自己開啟新話題、吐槽、或是主動回頭去看剛剛遺漏的彈幕。這是讓 AI VTuber「看起來有生命」CP 值最高、也相對最容易實作的一步，只需要一個簡單的排程器，並給模型幾個可選的動作指令即可。
2.2 玩遊戲是另一個量級的工程
許多人想讓 AI VTuber 自己玩遊戲，但這在工程上是完全不同的難度等級，主要會拆解成以下三個步驟，且每一步都充滿挑戰：
- 看畫面（感知）：定時截圖，並將畫面餵給視覺語言模型（VLM，如 Qwen-VL 或 GPT-4o）來理解。VLM 的 API 費用昂貴且速度慢；如果想在本地用 GTX 1660 執行大型 VLM 也相當吃力，通常只能走 API，這會導致成本與延遲大幅上升。
- 決策：由 LLM 根據畫面資訊決定下一步的動作。
- 操作（執行）：透過程式模擬鍵盤或手把輸入。
不同遊戲類型的難度天差地遠：
| 遊戲類型 | 可行性評估 |
|---|---|
| 文字遊戲、回合制、猜謎、瀏覽器小遊戲 | 高度可行，非常適合做為起點。 |
| 具有開放程式 API 的遊戲（如西洋棋引擎、Pokemon 模擬器、透過 Mineflayer 控制的 Minecraft） | 可行，但需要耗費心力去撰寫對接的 API 接口。 |
| 即時動作遊戲（如 FPS、複雜的動作遊戲） | 屬於研究級別的難題，VLM 的傳輸延遲是致命傷。 |
業界的「偷吃步」做法： 事實上，很多看似在「玩遊戲」的 AI VTuber，背後其實是半自動的。通常是由真人或預設腳本在操作遊戲，而 AI 本人只負責「用嘴玩」——也就是進行旁白、吐槽，或偶爾看看畫面給出評論。 像 Neuro-sama 玩 osu! 或 Minecraft 這種神乎其技的表現，是針對該遊戲進行的專門工程優化，並非通用的 AI 遊戲能力。 (延伸參考：GPT-4 在 Minecraft 中進行自主探索的專案 Voyager，那也是在有專屬程式介面輔助下的特例。)
2.3 針對 1660 顯卡與低預算的務實建議
如果你手邊只有 GTX 1660 等級的顯卡、預算有限，千萬別一開始就挑戰「自主玩任意遊戲」，那會耗盡你所有的開發時間與資金。建議採用以下「擬自主」的開發順序：
- 實作主動迴圈（冷場時自己找話題、主動回聊天室）：這是最能體現「活著」的感覺，也是最該優先實現的功能。
- 開發可程式化的簡單互動（如文字遊戲、猜數字、觀眾問答、讀彈幕做反應）。
- 「看畫面吐槽」（定時截圖，送至 VLM API 進行評論，這比讓 AI 直接操作遊戲便宜且可行得多）。
- 將真正的「自主操作遊戲」放在最後，或僅挑選有開放 API 的特定遊戲做技術 Demo。
3. 風險與安全護欄
當 AI VTuber 具備了 24/7 自主運行與主動發言的能力時，隨之而來的就是管控風險。
- 發言失控風險：AI 很有可能在直播中說錯話，或被懷有惡意的觀眾透過「釣魚」字眼帶風向。
- 安全護欄（Guardrails）：在將訊號送往直播串流平台（如 YouTube）前，務必加上一層過濾機制。這包括敏感詞過濾、拒答特定話題的政策，以及人設邊界的限制。
- 成本控制：主動迴圈的頻率不要設得太頻繁，否則不僅 Token 的花費會失控，也會讓 AI 顯得過於碎念而失去真實感。
相關資源
在深入開發前，你也可以參考以下相關的技術指南與專案紀錄：
小結
要讓 AI VTuber 展現出生命力，未必要追求最前沿、最昂貴的技術。在資源有限的情況下，誠實地面對技術邊界，利用「事實清單」做好長期記憶，並透過「主動迴圈」建立起 AI 的自主發言機制，就能以極低的成本創造出令人驚豔的互動效果。先從簡單的文字與畫面吐槽開始，一步步完善你的 AI Agent 吧！