by Rain Chu 7 月 24, 2026 | 未分類
Ego Lite 是可以讓 Codex、Claude Code 或其他 Agent 能在保留登入狀態的瀏覽器裡工作，同時不搶走你的分頁、滑鼠與注意力。它把 Chromium 瀏覽器、獨立工作空間 Space，以及 ego-browser Skill 組合在一起，讓人與 Agent 可以在同一套瀏覽器資料上並行處理不同任務。
如果你曾經用過 Playwright CLI 讓 Codex 操作瀏覽器 ，Ego Lite 可以視為另一條更偏向日常使用的路線。Playwright 擅長測試與可重現的自動化，Ego Lite 則把重點放在沿用真實登入狀態、讓多個 Agent 任務分開執行，以及把成功流程逐步固化成可重複使用的 Skill。
Ego Lite 是什麼
Ego Lite 是一款以 Chromium 為核心的 Agent Browser。它可以匯入 Chrome 的分頁、書籤、密碼、Cookie、登入工作階段、擴充功能與瀏覽器 Profile，外觀與一般 Chrome 接近，但多了一層專門給 Agent 使用的 Space。
每個 Space 都是獨立工作空間。你可以繼續處理自己的分頁，Codex 在另一個 Space 填表單、整理資料或下載檔案，另一個 Agent 還能同時開第三個 Space 執行其他任務。這些工作不需要共用同一個前景分頁，也不會輪流搶滑鼠焦點 。
Ego Lite 以同一套瀏覽器資料連接使用者與 Agent，再用 Space 隔離不同任務 真正的差異是登入狀態與工作空間
瀏覽器自動化最麻煩的地方，常常不是按鈕怎麼點，而是登入、雙因素驗證、SSO、Cookie、擴充功能與多個 Profile 怎麼延續。傳統自動化工具通常另外啟動一個乾淨的瀏覽器環境，這很適合測試，卻不一定適合處理每天都要登入的後台、社群平台或內部系統。
Ego Lite 把自己定位成你每天可以直接使用的瀏覽器。完成初次匯入後，Agent 可以在自己的 Space 沿用既有登入狀態。這也是它比單純命令列包裝更有意思的地方，因為 Agent 操作的是一個有真實使用脈絡的瀏覽器，而不是臨時建立的空白執行環境。
比較項目 Ego Lite Playwright 或 Puppeteer 一般 Agent Browser CLI 產品形態 可日常使用的 Chromium 瀏覽器加 Skill 程式庫與測試框架 操作瀏覽器的命令列工具 登入狀態 可匯入 Chrome 資料並在 Space 使用 通常自行建立或管理 Profile 多半操作另一個瀏覽器環境 人與 Agent 並行 不同 Space 同時工作 需要自行設計多 Context 或多實例 依工具實作而定 適合情境 登入後台、資料整理、日常重複工作 自動測試、精確流程、持續整合 快速交給 Agent 操作網頁
這不是誰取代誰的問題。需要穩定測試、嚴謹選擇器與 CI 流程時，Playwright 仍然很合理。需要 Agent 直接處理既有登入網站，而且你還要繼續使用瀏覽器時，Ego Lite 的設計更貼近日常工作。另一篇 用 Chrome 與 OpenCLI 控制瀏覽器 ，也能幫你比較不同整合方式。
Ego Browser Skill 如何減少 Token 與反覆試錯
很多瀏覽器 Agent 採用一個動作一次工具呼叫的節奏。先讀頁面，再點一下，重新讀頁面，再填一個欄位。每次來回都要把狀態交給模型判斷，步驟一多，時間與 Token 就跟著增加。
ego-browser 讓 Agent 直接組合一段 JavaScript，把可預測的觀察、點擊、輸入、等待與驗證放在同一次執行裡。它提供接近 Playwright 的 page、locator 與 browser 介面，也加入 taskSpaces、語意 Snapshot 和瀏覽器內請求能力。Agent 不必在每個小動作後停下來重新思考，複雜流程因此有機會用更少回合完成。
官網目前宣稱，特定複雜自動化測試相較 agent-browser 最多可快 3.45 倍，GitHub README 則仍保留最多 2.5 倍的描述。這兩個數字可能來自不同版本或測試組合，適合視為官方基準測試，不應直接套用到所有網站。真正值得觀察的是你自己的任務完成率、重試次數、總 Token 與人工接手次數。
Ego Lite 完整安裝方式
Ego Lite 目前以 macOS 為主要支援平台，Windows 與 Linux 仍在規劃中。最簡單的方法是到官網下載 Mac 版 ，開啟應用程式後完成初次設定。你也可以先把 Skill 加入 Codex 或其他 Agent。
請幫我設定 Ego Lite
專案網址是 https://github.com/citrolabs/ego-lite
請閱讀 skills/ego-browser/references/install.md
依照步驟安裝應用程式與 ego-browser Skill
需要我手動完成匯入或授權時先停下來告訴我初次啟動時，Ego Lite 會詢問是否匯入 Chrome 資料。匯入登入工作階段很方便，也代表 Agent 可能接觸已登入網站。建議只匯入工作所需的 Profile，不要把個人金融、公司管理後台與一般瀏覽資料全部混在同一個高權限環境。
完成應用程式內的 onboarding 後，可以確認命令是否已加入環境。
若找不到命令，常見原因是 ~/.local/bin 尚未加入 PATH。
export PATH="$HOME/.local/bin:$PATH"
command -v ego-browser 最後用最小測試確認執行環境。
printf "console.log('ego-browser ready')\n" | ego-browser nodejs 如何在 Codex 正確下 Prompt
一個好指令至少要包含網站、目標、資料範圍、輸出格式、驗證條件與需要停下來確認的高風險動作。不要只寫「幫我整理這個網站」，因為 Agent 不知道要看幾頁、保留哪些欄位，也不知道什麼情況才算完成。
/ego-browser
開啟我已登入的商品後台
依最新時間排序評論
收集前 100 筆評論的日期、評分、內容與商品規格
移除重複資料後輸出 CSV
完成前檢查總筆數與欄位是否齊全
不要送出表單、修改商品或發布任何內容需要多個來源時，可以明確要求使用不同 Space 並行執行，再把結果合併。例如規劃旅程時，一個 Space 查交通，一個 Space 查天氣，另一個 Space 整理景點與營業時間。最後再要求 Agent 檢查日期是否一致，避免不同網站的資料互相衝突。
/ego-browser
建立三個 Space 並行規劃台北到台南的三日行程
Space 1 查可訂購的高鐵班次與價格
Space 2 查三天逐時天氣
Space 3 查景點營業時間與休館日
最後合併成每日行程表
每個交通與景點資訊都保留來源網址
遇到付款、訂位或登入驗證時停下來交給我三種實際適合的工作
把商品評論整理成 CSV
Agent 可以進入已登入的電商頁面，開啟完整評論、調整排序、向下捲動或翻頁，再把指定欄位輸出成 CSV，第一次完成後，還可以把穩定步驟改成接收商品網址的腳本。之後直接執行腳本，就不必每次都讓模型重新理解同一套操作。
跨網站規劃行程
交通、天氣、地圖與旅遊攻略可以放到不同 Space 同時處理。這類工作真正困難的是登入狀態、日期對齊與多來源整合，剛好能發揮 Space 與既有 Cookie 的優勢。
結合地圖與求職網站篩選職缺
如果目標是找離住家最近的職缺，Agent 可以先從多個求職網站整理職稱、公司與地址，再交給地圖服務估算距離，最後輸出成 CSV，這比只用關鍵字搜尋更接近真正的決策流程，但地址、通勤時間與職缺是否仍有效，都要在結果中保留可追查來源。
從一次成功操作變成可重複 Skill
Ego Lite 最有價值的用法，不是每次都叫 Agent 從頭探索頁面，而是先讓它完成一次，再把成功路徑整理成 Skill 或腳本。探索階段需要模型判斷頁面與處理例外，穩定階段則把固定動作改成程式，僅在網站改版或驗證失敗時再回到 Agent。
先用自然語言描述結果與安全邊界
讓 Agent 完成一次並驗證輸出
整理穩定的頁面定位、等待條件與輸出欄位
將流程固化成 Skill 或可接收參數的腳本
為登入失效、欄位缺漏與網站改版保留明確錯誤訊息
當固定腳本能直接完成任務時，重複執行確實可以把模型 Token 壓到很低，甚至讓執行階段不再呼叫模型。不過這不是所有任務都能達成的零成本承諾。頁面變動、需要理解文字、遇到驗證碼或必須做判斷時，仍然需要 Agent 或人工介入。這個思路也適合延伸到 用 OfficeCLI 把文件工作交給 AI Agent ，把重複的辦公流程逐步變成可驗證的工具。
登入狀態越方便，權限管理越重要
Ego Lite 官方表示瀏覽紀錄、Cookie、密碼與頁面資料都保留在本機，設定時只記錄是否選擇 Chrome 匯入。即使資料不會主動上傳，Agent 仍然可能在你的授權下讀到頁面內容或執行操作，所以安全重點仍是最小權限與明確停止條件。
工作與私人帳號使用不同 Profile
發布、付款、刪除與權限變更必須人工確認
Prompt 清楚列出禁止操作
先用少量資料測試，再放大範圍
輸出要包含來源、筆數與驗證結果
結論
Ego Lite 的核心價值，是把真實瀏覽器狀態、Agent 專用 Space 與可重複 Skill 接在一起。它很適合需要登入、多網站整合、長流程與重複執行的工作，也能讓 Codex 在背景處理任務時，你仍然保有自己的瀏覽器與滑鼠。
最好的導入方式，是先挑一個低風險、每週都會重複的工作。讓 Agent 完成一次，確認輸出可靠，再把流程固化。真正節省的不是某一次點擊，而是把日後的重複思考與試錯一起移除。
常見問題
Ego Lite 可以讓 Codex 操作已登入網站嗎
可以。完成瀏覽器資料匯入與 onboarding 後，Codex 可透過 ego-browser Skill 在獨立 Space 使用既有登入狀態。高風險操作仍建議保留人工確認。
Ego Lite 與 Playwright 有什麼不同
Playwright 是瀏覽器自動化與測試框架，Ego Lite 是可以日常使用的 Chromium 瀏覽器，再透過 Skill 讓外部 Agent 操作。兩者可依測試或日常工作需求選擇。
Ego Lite 是否免費
官方目前標示 Ego Lite 免費且不需要訂閱。Agent 使用的模型是否產生費用，仍取決於 Codex、Claude Code 或其他模型服務的方案。
目前支援哪些作業系統
官方目前提供 macOS 版本，Windows 與 Linux 仍在 roadmap。下載前應以官網最新狀態為準。
瀏覽資料會上傳到 Ego Lite 嗎
官方表示書籤、瀏覽紀錄、Cookie、密碼與頁面資料保留在本機。不過 Agent 取得操作權限後仍可能接觸頁面內容，應以獨立 Profile 和最小權限降低風險。
官方資源
by Rain Chu 7 月 15, 2026 | 未分類
開源 TTS 最近很熱，但 dots.tts 值得特別看，原因不是只有聲音像，而是它把文字轉語音的路線又往前推了一步，它是一個 2B 參數的全連續端到端自回歸 TTS 系統，官方說明裡最關鍵的一句話是，整條管線不使用離散 token，而是用連續 latent 來完成語音生成。
如果你已經看過 Qwen3-TTS 的音色設計 ，或之前玩過 VoxelCPM 本地聲音復刻 ，dots.tts 可以放在同一條脈絡裡理解，以前很多 TTS 工具在可用性上已經不差，現在競爭點開始變成音色相似度、情緒穩定度、跨語言保真，以及能不能進一步做成即時語音 Agent 的底層能力。
先講結論
dots.tts 最適合被理解成一個偏研究與工程兼具的開源 TTS 底座。它不是只把文字念出來，而是把語意編碼器、LLM、自回歸 flow-matching 聲學頭、48 kHz AudioVAE 和 speaker x-vector 接成一條完整語音生成管線。
它目前最吸引人的地方有三個。
第一，官方釋出 pretrained、SCA 和 MeanFlow distilled 三種 checkpoint。
第二，SCA 版本主打更好的 voice cloning 表現。
第三，MeanFlow 版本用比較少的取樣步數換取推理速度，比較適合在產品或本地服務裡評估。
dots.tts 是什麼
dots.tts 是一個 2B 參數的 fully continuous end-to-end autoregressive text-to-speech 系統。官方 README 寫得很直接，它的骨幹由 semantic encoder、LLM 和 autoregressive flow-matching acoustic head 組成，底層則接 48 kHz AudioVAE。
這裡的重點是 fully continuous。傳統語音生成常會把聲音先離散化成 codec token，再讓模型預測 token，dots.tts 選擇不要走這條路，而是在連續 latent 空間裡處理語音。這個設計會讓架構更複雜，但它也讓音色、韻律和情緒細節有更大的保留空間。
三個 checkpoint 怎麼選
官方目前釋出三個 Hugging Face checkpoint，它們共用同一個 backbone，差別在品質、速度與對 voice cloning 的優化方向。
我會先從 dots.tts-soar 開始測，因為 voice cloning 通常是大家最在意的部分。如果要做服務化，才把 dots.tts-mf 拉進來比較延遲與硬體成本。
它的架構重點
官方架構可以拆成四層來看。AudioVAE 負責把 48 kHz mono waveform 編碼成連續 latent，也負責還原成聲音。Semantic encoder 會把新生成的 VAE patch 重新編碼成較緊湊的語意表示，LLM 由 Qwen2.5 1.5B Base 初始化，直接吃 BPE text。最後的自回歸 flow-matching acoustic head 則負責預測下一段聲音 latent。
這個設計有一個很有意思的方向。它不只是 TTS，也比較像是在替語音互動系統準備底座，官方提到 1T1A interleaved mode，可以讓一個 BPE token 和一個 audio step 交錯，目標是低延遲 streaming。這就會和 本地即時語音 Agent 的方向接起來。
數據上有多強
官方 benchmark 裡最直觀的是 Seed-TTS-Eval，dots.tts SCA 在中文測試的 WER 是 0.94，英文是 1.30，中文 hard set 是 6.60，平均 WER 是 2.95。這組數字和 Qwen3-TTS、CosyVoice 3、F5-TTS 放在一起看，已經是開源 TTS 裡非常前段的位置。
模型 參數量 英文 WER 中文 WER 中文 hard WER 平均 WER dots.tts SCA 2B 1.30 0.94 6.60 2.95 Qwen3-TTS 1.7B 1.23 1.22 6.76 3.07 CosyVoice 3 1.5B 2.22 1.12 5.83 3.06 F5-TTS 0.3B 2.00 1.53 8.67 4.10
平均 WER 越低代表文字內容錯誤率越低。這張圖只取官方 README 表格中的部分模型，方便快速比較。 另一個值得注意的是 MiniMax Multilingual ，官方寫到 dots.tts SCA 的平均 speaker similarity 是 83.9，並且在 24 種語言裡有 19 種取得 SIM 領先，另有 2 種並列，這代表它的聲音相似度不是只在中文或英文好看，而是有跨語言保存音色的能力。
本地部署先看這幾件事
官方建議用 Python 3.10 到 3.12 開新的 conda environment，再從 source 安裝。這類語音模型通常對套件版本很敏感，所以我會照官方 constraints 跑，不會一開始就混用自己環境裡的 torch、transformers 或音訊套件。
conda create -n dots_tts python=3.10 -y
conda activate dots_tts
python -m pip install --upgrade pip
python -m pip install -e . -c constraints/recommended.txt 最小測試可以用 CLI。voice cloning 建議給一段乾淨 reference audio，官方建議大約 10 秒就好，太長不會帶來更好的結果。更重要的是 prompt text 要和 reference audio 實際說的內容一致，不一致會讓穩定度變差，甚至出現 word-level 錯誤。
dots.tts --model-name-or-path rednote-hilab/dots.tts-soar --text "這是一段語音合成測試" --prompt-audio /path/to/reference.wav --prompt-text "參考音訊實際說出的文字" --num-steps 10 --output clone.wav 我會怎麼測 dots.tts
第一輪不要急著做長文朗讀，先準備三種 reference audio，分別是乾淨女聲、乾淨男聲、帶一點情緒的自然說話，每段控制在 8 到 12 秒，背景聲音越少越好，然後用同一段中文、英文和中英混合文字跑三次，看它的穩定度和語言切換表現。
第二輪才測情緒與語氣，這裡不要只聽像不像，還要看文字內容是否漏字、重複、破音，還有語尾是否自然，TTS 如果只追求音色相似，很容易忽略可讀性，真正能進工作流的 TTS，應該是長時間輸出也不容易出錯。
第三輪測 streaming，官方 Python API 提供 generate_stream，這對語音助理、客服機器人、角色互動很重要，這也能和我之前整理的 audio.cpp 本地語音 AI 底座 放在一起看，未來本地語音工作流很可能會走向 ASR、LLM、TTS 都可替換的模組化架構。
限制也要先看清楚
dots.tts 不是所有語言都一樣穩，官方風險與限制裡提到，低資源語言會有 WER gap，特別是阿拉伯文、印地文、土耳其文、越南文這類資料覆蓋比較吃緊的語言，它可以保住 speaker similarity，但文字正確率不一定跟高資源語言一樣漂亮。
另一個限制是訓練資料偏 speech-heavy，AudioVAE 雖然原則上是 modality-agnostic，但這次釋出的模型不涵蓋唱歌，也不是統一的 speech 加 sound generation 模型。所以如果你的需求是歌曲翻唱、音效生成或完整聲音設計，它不是最直接的答案。
我的判斷
dots.tts 最值得關注的不是 3 秒復刻這種口號，而是它把開源 TTS 拉到更接近產品級底座的位置，2B 參數、連續 latent、自回歸 flow matching、SCA 對齊、MeanFlow 蒸餾，這些都不是單純 demo 型專案會一次放齊的東西。
如果你只是想快速產生中文旁白，現成工具可能更省事，如果你想研究本地 voice cloning、即時語音 Agent、跨語言音色保留，或把 TTS 放進自己的產品工作流，dots.tts 很值得列入測試清單 。
延伸資源
FAQ
dots.tts 適合拿來做聲音復刻嗎？
適合評估，尤其是 dots.tts-soar。官方把它定位成 voice cloning 表現最好的 checkpoint，但實際品質仍取決於 reference audio 是否乾淨，以及 prompt text 是否和參考音訊一致。
dots.tts-mf 和 dots.tts-soar 差在哪裡？
dots.tts-soar 偏向品質與聲音復刻，dots.tts-mf 是 MeanFlow distilled student，官方建議 4 steps，目標是降低推理成本與提升速度。
參考音訊要多長？
官方建議大約 10 秒。更長不一定更好，乾淨、高取樣率、低背景噪音、自然說話，比單純拉長音訊更重要。
dots.tts 可以做唱歌或音效生成嗎？
不建議把它當成這類任務的主要方案。官方限制裡寫到這次釋出偏 speech-heavy，沒有覆蓋唱歌，也不是 speech 加 sound 的統一生成模型。
by Rain Chu 7 月 12, 2026 | 未分類
LongCat 1.5 最值得注意的地方是它把音訊驅動、人物一致性、長影片穩定性和 ComfyUI 工作流串在一起，讓數字人從單段 Demo 更接近可重複生產的內容流程。
美團開源的 LongCat-Video-Avatar 1.5 建立在 LongCat-Video 基礎模型之上，官方定位是 audio-driven human video generation，也就是用音訊、文字、圖片或既有影片去驅動人物生成。對內容創作者來說，關鍵不只是嘴型同步，而是能不能穩定做出比較長的數字人片段。
LongCat 1.5 解決的是什麼問題
過去很多數字人工具看起來很驚艷，但實際用在長片段時會遇到幾個老問題：嘴型不穩、人物身份漂移、動作重複、背景抖動、分段接不上，LongCat 1.5 的官方 model card 強調幾個方向：用 Whisper-Large 取代 Wav2Vec2 作為音訊編碼器，改善嘴型與語音動態，並強化長影片生成時的身份一致性和時間穩定性。
它支援的任務也不只一種，AT2V 是 Audio-Text-to-Video，適合用音訊和文字描述生成片段，ATI2V 是 Audio-Text-Image-to-Video，可以用參考圖片維持角色形象，Video Continuation 則比較接近延續既有影片，讓後續動作和語音繼續往下生成。
為什麼 RunningHub 工作流有用
LongCat 1.5 本身是模型，真正要變成創作者可用的工具，還需要工作流。這也是 RunningHub 和 ComfyUI 的價值所在。RunningHub 可以把複雜節點封裝成比較容易執行的流程，讓使用者不一定要在本機把所有依賴、模型、節點和顯卡環境都裝好。
如果你還不熟 RunningHub，可以先看我之前整理的 RunningHub 是什麼？把 ComfyUI 工作流變成 AI 內容生產平台 ，這次 LongCat 1.5 的重點就是把「單段生成」改成「循環工作流」，讓多段音訊和多段片段可以自動往下跑，不必每 4 秒就手動複製節點、改連線、重新拼接。
循環工作流的核心概念
實作數字人長片段時，最麻煩的往往不是單次生成，而是分段，假設每段產生 4 秒，20 秒就需要 5 段，30 秒就需要更多段。如果每一段都手動複製節點和連線，工作流會變得又長又難維護。
比較合理的做法是讓工作流自動按時間切段，再把每段送進 LongCat 1.5 生成。這裡有幾個重要參數：
音訊起始時間：決定從第幾秒開始讀音訊。
生成時長：決定每段處理幾秒，實務上可以略大一點，避免音訊尾端被切掉。
幀率：要和模型採樣規則配合。
尺寸：工作流裡常見長邊 1024，也可以提高，但成本會上升。
參考圖和 prompt：決定人物外觀、場景、動作與一致性。
其中「4n+1」這個規則很重要。如果秒數乘上幀率後不是符合模型要求的幀數，採樣器可能直接報錯，好的工作流會用數學節點自動修正幀數，避免使用者每次手算。
設備需求怎麼看
很多人第一個問題會是：本機能不能跑？答案要拆開看，官方安裝方式需要 Python 3.10、CUDA 版 PyTorch、FlashAttention、ffmpeg、librosa 和模型權重。這代表如果要本地完整跑起來，最好有 NVIDIA GPU 和足夠顯存，不然體驗會很痛苦。
RunningHub 的思路則是把算力放到雲端，說明欄提到可以在 RTX 4090 上運行，這對一般創作者比較友好，因為你不用先處理 CUDA、依賴衝突和顯存不足。缺點是需要依平台計費，還要注意素材隱私和商用內容的授權風險。
如果你對本地 AI 影片工作流有興趣，可以對照 OpenMontage 本地部署實測 。如果你的重點是語音和角色互動，也可以延伸看 Hugging Face speech-to-speech 本地即時語音 Agent ，思路都會回到同一件事：模型、音訊、工作流和算力要一起設計。
提示詞要寫得比想像中更細
LongCat 1.5 官方也提醒，長而具體的 prompt 通常比短句更穩。不要只寫「一位女生在說話」。更好的寫法是把人物外觀、動作、服裝、表情、場景都寫清楚，例如：一位長黑髮女性，穿白色襯衫，坐在明亮咖啡館裡，微笑並自然說話。
如果要做商用級數字人，我會把 prompt 拆成四層：
角色：年齡、髮型、服裝、表情、姿態。
場景：室內或戶外、光線、背景、鏡頭距離。
動作：說話、微笑、點頭、手勢、是否走路。
限制：不要誇張表情、不要手部變形、不要背景閃爍、不要換臉。
如果你還需要語音來源，可以搭配 Qwen3-TTS 這類音色設計工具 ，先把聲音品質穩住，再進入數字人生成。音訊不好，嘴型同步再強也很難救。
LongCat 1.5 適合誰
使用者 適合程度 原因 短影音創作者 高 可以把固定角色、音訊和場景變成批量內容。 電商和品牌團隊 高 可做商品介紹、導購、活動宣傳和多語版本。 本機 AI 玩家 中 模型開源，但完整環境和顯卡需求不低。 只想快速試效果的人 高 用 RunningHub 工作流比本地安裝更快。 企業敏感資料場景 中 要評估素材隱私、雲端上傳和合規問題。
如果只是做一張照片講話，過去已經有很多工具可以完成，例如我之前整理過的 Hallo AI 數字人 ，LongCat 1.5 更值得看的地方，是它開始處理更長、更穩、更可工作流化的數字人生成。
注意事項
第一，雲端工作流很方便，但素材上傳前要確認隱私。客戶聲音、真人肖像、商業腳本，都不應該隨便丟到不熟的平台裡。
第二，數字人看起來自然，不代表可直接商用。要確認聲音、人物肖像、參考圖、背景素材和平台條款，尤其是用真人形象時更要小心。
第三，循環工作流能提高效率，但也會放大錯誤。如果第一段人物已經歪掉，後面自動跑再多段也只是把錯誤放大。比較穩的做法是先做 4 到 8 秒測試，確認嘴型、動作和人物一致性，再放大到長片段。
最後
LongCat 1.5 代表數字人工作流正在從單點工具走向內容生產線。模型本身強調嘴型、長影片穩定和身份一致性，RunningHub 工作流則把操作門檻往下壓。對創作者來說，現在最重要的能力不是只會按生成，而是懂得設計音訊、角色、分段、幀率和工作流。
如果你想快速驗證，先用 RunningHub 工作流跑一段短音訊。如果要做可控的長片或商用內容，再回頭研究 ComfyUI 節點、官方 Hugging Face 權重和本地部署成本。這樣比較不會一開始就被環境和顯卡需求卡住。
FAQ
LongCat 1.5 是什麼？
LongCat 1.5 是美團開源的音訊驅動數字人模型，支援用音訊、文字、圖片或既有影片生成數字人片段。
LongCat 1.5 可以本地部署嗎？
可以，但官方安裝需要 CUDA 版 PyTorch、FlashAttention、ffmpeg、librosa 和模型權重，建議有 NVIDIA GPU 再嘗試。
為什麼幀率要注意 4n+1？
部分採樣流程要求輸入幀數符合特定規則，如果秒數乘幀率後不符合，採樣器可能報錯。工作流通常會用數學節點自動修正。
by Rain Chu 7 月 11, 2026 | 未分類
本地部署大模型到了 2026 年，問題已經不只是「模型要選哪一個」。同一張顯卡、同一台 Mac、同一個模型，只要推理框架選錯，吞吐量、延遲、顯存使用率和維運成本都會差很多。
這也是為什麼 vLLM、SGLang、llama.cpp、MLX、Ollama 這五個工具會被放在一起比較。它們不是同一類產品的不同包裝，而是對應不同部署場景的五種答案。選對框架，比盲目追更大參數更實際。
先講結論
如果你要做高併發 API 服務，先看 vLLM。如果你在做 AI Agent、RAG、多輪工具呼叫，SGLang 很值得研究。如果你要跨平台、邊緣設備、低資源環境，llama.cpp 仍然是最靈活的選擇，如果你主要用 Apple Silicon，MLX 是最貼近硬體的路線。如果你只是想快速讓團隊或個人跑起來，Ollama 依然是最省心的入口。
五個框架的定位差異
框架 核心強項 適合場景 不適合情況 vLLM PagedAttention、Continuous Batching、高吞吐 生產 API、多使用者併發、GPU 服務 個人桌機快速試模型 SGLang RadixAttention、KV Cache 重用、結構化輸出 Agent、RAG、多輪對話、JSON 輸出 只想一鍵跑模型 llama.cpp GGUF、生態成熟、跨平台 CPU、邊緣設備、Mac、Windows、Linux、嵌入式 大規模高併發服務 MLX Apple Silicon 統一記憶體最佳化 M 系列 Mac、本地研究、Mac 開發者 NVIDIA GPU 伺服器 Ollama 安裝簡單、模型管理方便、API 友善 個人使用、團隊內部工具、快速 Demo 需要極致吞吐與深度客製
vLLM：高併發服務優先
vLLM 的代表性技術是 PagedAttention，可以把它理解成用作業系統管理記憶體的思路來管理 KV Cache，讓不同長度的請求不會浪費大量顯存，再加上 Continuous Batching，當某個請求完成後，新請求可以馬上進入批次，不必等整批全部結束。
所以 vLLM 最適合放在需要吞吐量的地方，例如公司內部模型 API、客服系統、多人同時使用的知識庫、需要穩定服務層的產品，你如果正在評估顯卡工作站，也可以對照我之前整理的 RTX PRO 6000 Blackwell 選購分析 ，因為推理框架和硬體規格要一起看才有意義。
SGLang：Agent 和 RAG 的效率選擇
SGLang 的重點不只是跑得快，而是能把複雜互動流程裡重複的上下文計算省下來，它的 RadixAttention 對多輪對話、RAG、知識庫查詢、Agent 工具呼叫很有價值，因為這些場景常常有大量共用前綴和重複上下文。
如果你的應用是「使用者問一句，模型答一句」，SGLang 的優勢不一定完全發揮。但如果你要處理多步驟推理、固定系統提示、文件檢索、JSON 格式化輸出，它會比一般推理框架更貼近 Agent 工程需求。
llama.cpp：跨平台與低資源環境的底座
llama.cpp 最大的價值是能跑在很多地方，從 Mac、Windows、Linux，到 CPU-only、小型邊緣設備、GGUF 量化模型，它提供的是一種很穩的本地推理底座，你不一定拿它做高併發生產 API，但它很適合實驗、嵌入式、離線環境、低成本部署。
如果你關心本地離線模型，之前整理過 gpt-oss 本地離線運行 ，那篇的思路也可以放到 llama.cpp 生態來看。
MLX：Apple Silicon 使用者要特別看
MLX 是 Apple Silicon 上很有意思的選擇。M 系列晶片的統一記憶體架構，讓 CPU、GPU 可以更有效率地共享資料，MLX 的價值就在於它不是把 Mac 當成一般電腦硬跑，而是更貼近 Apple 自家的硬體特性。
如果你手上是 Mac Studio、MacBook Pro 或其他 M 系列設備，MLX 適合拿來做本地研究、模型微調實驗、小型推理服務。它不是 NVIDIA 伺服器的替代品，但在 Mac 生態裡，這條路線會越來越重要。
Ollama：最容易讓人開始用
Ollama 的優勢不是極致效能，而是降低使用門檻。安裝、拉模型、切模型、提供本地 API，整個體驗很適合個人、教學、內部工具和快速 Demo。對很多團隊來說，先用 Ollama 把流程跑通，比一開始就追求 vLLM 的生產級架構更務實。
如果你要把 Ollama 放到內網或 AI Server 上，可以看 Ollama 遠端連線教學 。如果你想把開發環境成本壓低，也可以參考 LM Studio 與 Ollama 的零 API 成本開發環境 。
不要只選一個，混合部署更實際
真正成熟的部署，不一定是一個框架包打天下。比較實際的做法是分層：個人和內部 Demo 用 Ollama，Mac 研究環境用 MLX，跨平台和邊緣設備用 llama.cpp，RAG 和 Agent 後端看 SGLang，高併發正式服務再交給 vLLM。
如果你的硬體是 DGX Spark 或其他 AI Server，也可以把 DGX Spark GB10 Ollama 最佳設定 當作入口，再逐步把高併發服務拆到更專業的推理框架。
我的選型建議
個人開發者：先用 Ollama，真的需要跨平台或量化控制，再補 llama.cpp。
Mac 使用者：Ollama 做入口，MLX 做進階研究和 Apple Silicon 最佳化。
企業內部知識庫：先確認 RAG 架構和上下文重用需求，再評估 SGLang。
正式 API 服務：vLLM 是第一優先，特別是多使用者併發和 GPU 成本敏感時。
邊緣設備或離線場景：llama.cpp 的彈性仍然很難取代。
2026 年的本地 AI 部署，重點會從「能不能跑」走向「跑得是否有效率」。模型能力很重要，但推理框架決定了你花出去的硬體成本能不能真正轉成服務能力。選型時不要只看 benchmark，要看你的流量模式、硬體環境、維運能力和未來要不要接 Agent 工作流。
FAQ
本地大模型推理框架要先學哪一個？
一般使用者先學 Ollama，工程師再補 llama.cpp。需要生產服務時，再研究 vLLM 或 SGLang。
vLLM 和 SGLang 差在哪裡？
vLLM 強在高併發吞吐和生產服務，SGLang 更適合多輪對話、RAG、Agent 和重複上下文很多的流程。
Mac 使用者該選 MLX 還是 Ollama？
想快速跑模型先用 Ollama，想深入 Apple Silicon 最佳化和研究實驗，再看 MLX。
llama.cpp 還值得學嗎？
值得。它在 GGUF、量化、跨平台、CPU 和邊緣設備上仍然非常重要，是本地模型生態的底層工具之一。
by Rain Chu 7 月 7, 2026 | 未分類
✅ VoxelCPM vs. 雲端服務實測對比摘要
語音自然度： ★★★★☆（本地部署中文方言表現更佳）。安裝速度&執行穩定性： ✅ 整合包版本極易上手。一次 setup，全部完成！（Windows/Mac 通用）擴展性： 只要 CPU 核心足夠即可批量處理多線程聲音任務！雲端服務更依賴網路狀態與排程延遲。
VoxelCPM 的本地化部署模式，讓 「完全離線語音合成」 這個概念不再是科幻故事。尤其在隱私敏感企業與高頻率應用場景下，它可以節省可觀 API 成本。
5秒複製你的聲音：零門檻本地 TTS 工具 VoxelCPM 實戰指南＋完全離線部署
想不想只需錄短短幾秒鐘的聲音，就能在任何情境下「完美復刻」你自己的語音？現在，不需要昂貴的雲端服務費，也能在自己的電腦上實現這個需求。透過 VoxelCPM （或稱 VoxCPM），您可以直接在本地端訓練專屬的 TTS（文字轉語音）模型，支援 30 種語言與多種方言。
⚡ 為什麼需要本地端 TTS？
隱私保護： 敏感數據（如客戶錄音、個人日誌）不需要上傳到雲端伺服器。零月費門檻： 一次安裝，永不再收 API 費用。對於需要長期大量生成語音的專案來說，省下的費用驚人。完全自定義： 只要幾秒鐘的錄音素材，即可客製化出屬於您的專屬音色！
🔊 VoxelCPM 核心優勢與實測比較
項目 VoxelCPM（本地） 雲端服務 （AWS Polly 等）
數據隱私 極高 （資料全在本地）需要上傳到第三方伺服器端
持續月費 $0 完全免費開源！
按量計費，長期使用成本驚人
方言支援 30+種語言與豐富台語粵語等方言兼容！
標準語音為主，方言受限嚴重
設置難度 中等（Python 或整合包環境）；一鍵部署已極簡化。
低（只需呼叫 API Key 即可）
🛠️ VoxelCPM 實戰教學：快速上手！
步驟一：下載環境 GitHub /AI探索与发现 頻道或官方整合包取得。目前支援 Windows/Mac/Python 虛擬環境，安裝過程已經將複雜依賴性全部打包！pip install -r requirements.txt
步驟二：準備你的聲音素材 (只需 5~10 秒)「今天天氣真好」 的語音。語速正常、環境安靜即可。
步驟三：開始訓練與生成！(One-Click)
🔊特別注意：影片教學中強調的「方言」支援能力。 無論是台語還是其他特定區域口音，VoxelCPM 皆能精準捕捉聲音的特徵變化！
✅ VoxelCPM vs. 雲端服務實測對比摘要
語音自然度： ★★★★☆（本地部署中文方言表現更佳）。安裝速度&執行穩定性： ✅ 整合包版本極易上手。一次 setup，全部完成！（Windows/Mac 通用）擴展性： 只要 CPU 核心足夠即可批量處理多線程聲音任務！雲端服務更依賴網路狀態與排程延遲。
VoxelCPM 的本地化部署模式，讓 「完全離線語音合成」 這個概念不再是科幻故事。尤其在隱私敏感企業與高頻率應用場景下，它可以節省可觀 API 成本。
參考資料
論文
模型
by Rain Chu 4 月 15, 2026 | 未分類
🌍 Google Nano Banana 18 招實戰玩法
1️⃣ 環遊世界攝影（不用出國）
把人物丟進巴黎、東京、冰島
2️⃣ 多主體合成（超強合成能力）
3️⃣ 首尾幀影片生成
只給「開始 + 結束」
4️⃣ 無限 P 圖（換臉＋換裝＋換場景）
👉 一張圖變 100 張
5️⃣ 電商產品圖（Home Canvas）
👉 白底 → 高質感品牌圖
6️⃣ 火柴人 → 動漫影片
草圖 → 完整動畫
7️⃣ 地圖視覺推理
AI 看地圖 → 推理現場畫面
8️⃣ 遊戲人物設計
👉 RPG / 科幻 / 二次元
9️⃣ 海報設計置換
👉 改人物 / 改產品 / 改標題
🔟 真實手辦生成
👉 角色 → 手辦展示圖
1️⃣1️⃣ AI 影片生成
👉 靜態圖 → 動態影片
1️⃣2️⃣ 虛擬形象設計
👉 打造你自己的 AI 分身
1️⃣3️⃣ LINE 貼圖設計
👉 一鍵生成貼圖包
1️⃣4️⃣ 食物美化（美食攝影）
👉 讓普通食物變米其林等級
1️⃣5️⃣ 食物拆解（視覺推理）
👉 漢堡 → 分解食材
1️⃣6️⃣ 一張圖說故事
👉 一張圖就能講完整故事
1️⃣7️⃣ 視角轉換（鏡頭改變）
👉 正面 → 空拍 / 側拍
1️⃣8️⃣ AI 創意無限延伸
👉 所有創意都可以延伸
🧩 核心能力總結
Nano Banana 的強大在於：
🧠 視覺理解（不是只生成）
🔄 可重組（多圖融合）
🎬 動態生成（圖片 → 影片）
🎨 風格自由轉換
👉 已經不是工具，而是「創作引擎」
🚀 適合誰用？
電商賣家（商品圖）
設計師（海報 / 品牌）
自媒體（短影片）
遊戲開發（角色設計）
AI 創作者（虛擬人 / 貼圖）
🔗 官方入口
👉 Google AI Studio
近期留言