影片筆記：我的贾维斯开源了，可以语音交互，控制多Agent编排【B站AI创造公开赛】

一句話總結

講者開源其個人開發的語音控制多 Agent 系統 Home Rail，旨在模擬類似「賈維斯（Jarvis）」的家庭 AI 體驗。該系統運行於 NAS 或個人電腦，支援動態工作流編排與語音交互，目前定位為非開箱即用、需具備技術能力進行部署與調優的架構，並推薦透過 Coding Agent（如 Codex）進行調用而非直接使用前端 UI。

核心重點

1. 產品定位與限制：

• 非軟體工程自動化：不適合高質量要求的軟體開發，僅適合人工審查成果非瓶頸的場景。
• 非開箱即用：目前僅提供架構，使用者需具備技術能力，透過 AI Agent 讀取程式碼庫進行部署與調優。
• Token 消耗：未針對 Token 消耗進行優化，建議擁有本地部署或冗余訂閱資源的使用者嘗試。
• 最佳使用形態：推薦透過 Coding Agent（如 Codex）直接調用後端 Agent 編排，而非使用前端 UI。

1. 技術架構與部署：

• 支援 Windows、Mac、Linux 及 NAS 環境。
• 核心為後台 DAG 引擎依賴的 YAML 文件，建議讓 AI 根據邏輯實現編排並調優，無需手動搞懂 DAG 運行原理。
• 支援 Docker 環境構建，可針對特定任務（如影片製作需 FFmpeg）構建鏡像。

1. 功能模組：

• Manager Agent：桌面版模組，負責扮演 Coding Agent 角色，創建編排、接入模型，支援語音控制（需小米 Memo API Key 用於 ASR 和 TTS）及打字功能。
• 前端：可查看每個 DAG 流程，適合調試運行行為。
• Harness 支援：支援 Cloud Code、Kimi Code 以及 Codex。
• 實驗性功能：支援 PS5 手柄控制。

1. 未來路線圖：

• 短期：提升穩定性，支援多個作業系統，讓新手能無障礙使用桌面版。
• 中期：著重於生成式 UI、編排模板和編排 Skill 的優化，透過易於理解的 UI 交互，後台運行複雜邏輯。
• 長期：穩定運行於家庭數據中心（NAS），成為家庭 AI 載體。

詳細大綱

I. 開源宣告與產品定位

• 開源時間點：立 Flag 一個月後正式開源。
• 產品概念：
• 運行於個人電腦或 NAS。
• 語音交互與多 Agent 複雜任務編排。
• 類比為個人電腦上的「賈維斯（Jarvis）」。
• Build in Public：講者將公開開發過程與領悟，接受觀眾監督。

II. 命名由來

• 原名稱：牛馬（因拼音及中文商標已被註冊，避免踩坑）。
• 新名稱：Home Rail。
• Home：為家庭數據中心打造，理想狀態運行於 NAS，也可透過 Windows、Mac、手機、投影、電視、車機等設備訪問。
• Rail（軌道）：代表 Agent 運行的軌道，即 Workflow。特點為「動態調整」，在大方向不變前提下可小範圍調整。

III. 當前狀態與限制（疊假/勸退說明）

1. 非軟體工程自動化：

• 軟體工程複雜，單一 Workflow 無法解決質量問題。
• AI 擅長創造軟體，但軟體未必是最終交付成果（如博主交付的是影片）。
• Home Rail 目標不是更智能的軟體工程，僅適合「人工審查成果非瓶頸」的場景。

1. 非開箱即用：

• 目前僅搭好架構，需使用者理解內部 Agent 編排。
• 需測試適合場景並用 AI 調優流程。
• 需要花費時間研究，非即時可用。

1. Token 消耗與效率：

• 未對 Token 消耗和效率化做優化。
• 講者透過大量併發消耗訂閱來摸索邊界。
• 建議無本地部署或冗余訂閱者等待社區最佳實踐。

1. 最佳使用形態：

• 非 UI 操作，而是透過 Coding Agent 直接調用後端 Agent 編排。
• 講者常用 Codex 控制，體驗良好，無需使用前端。

1. 前端 UI 現狀：

• 概念上有大量生成式 UI，但目前內容少、不好看、不高小（疑點：可能為「不高級」或聽誤）。
• 需時間摸索讓生成式 UI 匹配具體任務。

IV. 技術架構與部署指南

• 跨平台支援：
• Windows：需 Docker Desktop 和 Git Bash（類似 Cloud Code 需求）。
• Mac：需 Docker Desktop。
• Linux：需將當前用戶加入 Docker 組，無需 sudo 即可使用 Docker。
• 部署建議：
• 提供 Windows 和 Mac 桌面版，適合不太會部署的朋友。
• 推薦做法：讓 AI Agent 直接讀取程式碼庫進行部署。
• 編排文件（YAML）：
• 核心為後台 DAG 引擎依賴的 YAML 文件。
• 不需手動搞懂 DAG 運行原理，讓 AI 根據邏輯和工作流實現編排並調優。
• 環境鏡像：
• 若任務需特定環境（如影片製作需 FFmpeg），可讓 AI Agent 構建鏡像。
• 安裝後會自動 Build 預設鏡像，也可進行客製化。

V. 功能模組與工具整合

• 桌面版（Manager Agent）：
• 負責扮演 Coding Agent 角色，創建編排、接入模型。
• 支援語音控制（需小米 Memo API Key 用於 ASR 和 TTS）及打字功能。
• 前端（Frontend）：
• 可查看每個 DAG 流程，適合調試運行行為。
• Harness（編排/調試工具）支援：
• 支援 Cloud Code、Kimi Code 以及 Codex。
• 警告：接入 Coding Plan 時需謹慎，部分廠家的 Coding Plan 不支援其他 Harness，混用可能導致崩潰（疑點：原文為「分號」，疑為崩潰或錯誤）。
• 實驗性功能：
• 接入 PS5 手柄 控制。

VI. 未來發展路線圖（Roadmap）

• 短期目標：
• 提升穩定性，支援多個作業系統。
• 讓新手能無障礙使用桌面版。
• 優化 Manager Agent 的 Skill，成為值得信賴的助手。
• 中期目標：
• 著重於 生成式 UI、編排模板 和 編排 Skill 的優化。
• 理念：人類頻寬有限，應透過易於理解的 UI 交互，後台運行複雜邏輯，人類僅在關鍵節點透過生成式動態 UI 面板了解進度。
• 長期目標：
• 穩定運行於家庭數據中心（NAS）。
• 趨勢：NAS 計算性能增長，不再僅是儲存管理，未來可能成為 Agent 載體。
• 講者現狀：Home Rail 運行於 256G 記憶體、96G 顯存的非紐（疑點：可能為品牌名或聽誤）NAS 中，透過投影加手柄控制，操作海量 Agent 完成任務。
• 補齊所有所需模組。

VII. 後續內容預告

• 將圍繞如何使用 Home Rail 推出系列內容：
• 如何接入模型。
• 如何接入 Skill。
• 如何調試編排。

工具 / 模型 / 名詞整理

• Home Rail：影片主角，多 Agent 系統名稱。
• Jarvis（賈維斯）：用於類比該系統的交互體驗。
• NAS：網路附加儲存，目標運行環境。
• Windows / Mac / Linux：支援的作業系統。
• Docker Desktop：Windows 和 Mac 部署所需工具。
• Git Bash：Windows 部署所需工具。
• Cloud Code：支援的 Harness/編排工具。
• Kimi Code：支援的 Harness/編排工具。
• Codex：講者推薦使用的 Coding Agent，體驗良好。
• 小米 Memo：提及的 API Key 來源，用於 ASR（語音識別）和 TTS（語音合成）。
• ASR：Automatic Speech Recognition，語音識別。
• TTS：Text-to-Speech，語音合成。
• YAML：後台 DAG 引擎依賴的編排文件格式。
• DAG：Directed Acyclic Graph，有向無環圖，用於後台引擎。
• Manager Agent：桌面版中負責扮演 Coding Agent 角色的模組。
• PS5 手柄：實驗性功能，用於控制系統。
• FFmpeg：影片製作所需的特定環境工具。

操作流程整理

1. 環境準備：

• Windows 用戶安裝 Docker Desktop 和 Git Bash。
• Mac 用戶安裝 Docker Desktop。
• Linux 用戶將當前用戶加入 Docker 組。

1. 部署與編排：

• 推薦讓 AI Agent 直接讀取程式碼庫進行部署。
• 透過 YAML 文件定義後台 DAG 引擎依賴的編排。
• 若任務需特定環境（如影片製作），讓 AI Agent 構建鏡像（如 FFmpeg）。

1. 交互與控制：

• 使用 Manager Agent（桌面版）創建編排、接入模型。
• 支援語音控制（需配置小米 Memo API Key 用於 ASR 和 TTS）及打字功能。
• 推薦透過 Coding Agent（如 Codex）直接調用後端 Agent 編排，而非使用前端 UI。
• 可透過前端查看每個 DAG 流程以調試運行行為。
• 支援接入 Cloud Code、Kimi Code 以及 Codex 作為 Harness。
• 實驗性功能：可接入 PS5 手柄控制。

值得注意的限制或風險

1. 非軟體工程自動化：不適合高質量要求的軟體開發，僅適合人工審查成果非瓶頸的場景。
2. 非開箱即用：目前僅提供架構，需使用者具備一定技術能力，透過 AI Agent 讀取程式碼庫進行部署與調優。
3. Token 消耗與效率：未針對 Token 消耗進行優化，建議擁有本地部署或冗余訂閱資源的使用者嘗試。
4. Harness 混用風險：接入 Coding Plan 時需謹慎，部分廠家的 Coding Plan 不支援其他 Harness，混用可能導致崩潰（疑點：原文為「分號」）。
5. 前端 UI 現狀：概念上有大量生成式 UI，但目前內容少、不好看、不高小（疑點：可能為「不高級」或聽誤）。

逐字稿辨識疑點

• 「不高小」：原文描述前端生成式 UI 時提到「不過好看，也不過高小」，疑為聽寫錯誤，可能意指「不高級」或「不夠小/精緻」，需查證。
• 「非紐 NAS」：原文提到「非紐 NAS」，疑為品牌名稱聽誤（如「非紐」可能為某品牌音譯或特定型號），需查證。
• 「搞不好會分號」：原文警告接入 Coding Plan 時若支援其他 Harness 混用，「搞不好會分號」，疑為聽寫錯誤，可能意指「崩潰」、「報錯」或「崩潰（crash）」，需查證。
• 「小米 memo 的 api key」：原文提及「小米 memo」，疑為特定產品或服務名稱，需查證是否為「小愛同學」或其他小米生態產品之誤聽。
• 「dx 某版」：原文提到「由於 dx 某版還是不夠多」，疑為特定版本或平台名稱聽誤，需查證。
• 「256 記憶體 96G 顯存」：數值具體，但「非紐」品牌不明，需查證硬體規格是否合理或為特定自組裝/品牌機。

可延伸追問

1. 如何具體配置「小米 Memo API Key」以實現 ASR 和 TTS 功能？
2. 對於非技術背景的使用者，是否有更簡化的部署指南或預設模板？
3. 在「人工審查成果非瓶頸」的場景下，具體有哪些案例可以參考？
4. 如何避免 Harness 混用導致的崩潰風險？是否有官方推薦的組合？
5. 未來生成式 UI 的具體實現方案是什麼？如何確保其與具體任務的匹配度？