by Rain Chu 7 月 7, 2026 | Agent , AI , RAG , 簡報製作 , 語音合成
如果你常把 PDF、論文、產業報告或內部文件丟進 AI 工具整理，Google NotebookLM 確實很方便；但只要資料牽涉商業機密、未公開研究、客戶內容或公司內部知識庫，雲端上傳與模型選擇限制就會變成真正的門檻，Open Notebook 的定位，正是把 NotebookLM 類型的文件理解、問答、摘要與 Podcast 生成，搬到更可控、更可自訂的開源工作流裡。
圖:Open Notebook 私有 AI 研究工作流示意 Open Notebook 解決的是什麼問題？
傳統文件型 AI 助手最容易卡在兩件事：資料放在哪裡，以及模型能不能換。對個人研究來說，把公開文章交給雲端 AI 問答通常沒什麼壓力；但對企業團隊、顧問、研究員或寫作者來說，資料可能包含未公開策略、訪談紀錄、合約、財務數據或客戶文件。這時候，能否自架、能否控制資料歸屬、能否選用自己的模型，就不只是偏好，而是能不能導入的前提。
Open Notebook 的優勢在於，它不是只做一個聊天視窗，而是把「文件匯入、知識庫整理、跨文件問答、來源引用、Podcast 生成、模型配置」串成一套私有 AI 研究工作流。官方 GitHub 專案 lfnovo/open-notebook 目前採 MIT 授權，官方說明也把它定位為一個 privacy-focused alternative to Google NotebookLM，截至 2026-07-07，GitHub API 顯示約 35K stars，最新 release 為 v1.10.0。
核心亮點一：資料主權回到自己手上
Open Notebook 最吸引人的地方，是它把資料控制權從平台端拉回使用者端。你可以把文件、音訊、多媒體檔案、網頁等素材放進自己掌控的環境，再用 AI 做摘要、檢索與問答。對需要處理敏感研究、公司內部文件或客戶資料的人來說，這比「功能多一點」更重要。
這也讓 Open Notebook 很適合搭配文件前處理工具。例如需要先把 PDF、Word、PPT 轉成 AI 更容易讀的文字格式時，可以參考我之前寫過的 MarkItDown 教學 ，先把原始文件整理成更乾淨的資料，再交給知識庫系統分析。
核心亮點二：模型不再被單一供應商綁住
NotebookLM 的好處是省事，但限制也很明顯：使用者基本上跟著 Google 的模型與產品設計走。Open Notebook 則主打 18+ AI provider，官方 README 提到支援 OpenAI、Anthropic、Ollama、LM Studio 等供應商。這代表同一套知識庫可以依任務切換模型：便宜模型做初步整理，強模型做深入推理，本地模型處理敏感資料。
如果你的工作流已經開始用 Ollama 或本地模型，Open Notebook 的價值會更明顯。它可以成為文件層的操作介面，而模型層則交給你自己的 AI server，想走本地端路線的人，也可以延伸看 GraphRAG 使用本地端的 Ollama 或 Ollama 遠端連線教學 ，把模型部署與文件分析分開思考。
核心亮點三：Podcast 生成更像內容製作工具
Podcast 生成是 NotebookLM 很受歡迎的功能，但固定雙人對談也限制了內容形式。Open Notebook 的方向更偏向內容製作工具：可以做 1 到 4 位 speaker，並調整角色設定與對話形式。這讓它不只適合做「兩人解說」，也能做單人旁白、三人圓桌、多人辯論或不同角色的知識導覽。
對自媒體、研究型內容創作者或企業內訓來說，這點很實用。你可以先把一批文件整理成知識庫，再把其中的核心結論轉成 Podcast 腳本，甚至為不同聽眾設計不同敘事角色。它不是單純把文字念出來，而是把文件理解、腳本結構與音訊內容生產接在一起。
核心亮點四：Ask 模式更適合跨文件研究
Open Notebook 的 Ask 模式適合處理「不是問單一文件，而是要整合一批資料」的任務。例如你有 20 份產業報告，真正想問的不是某一頁寫了什麼，而是不同報告之間是否有共同趨勢、矛盾、缺口與可引用依據。這時候，單純的檢索式問答會不夠，需要能跨文件整理、比對與引用來源的研究流程。
這也是 RAG 類工具接下來會越來越重要的原因：文件不是只被「搜尋」，而是要被組織成可以反覆推理的知識庫。Open Notebook 提供的是比較完整的操作層；而像 GraphRAG、向量資料庫、本地模型與文件轉換工具，則是可以接在底下的技術層。把這些組起來，才會形成真正可重複的 AI 工作流 。
Open Notebook 和 NotebookLM 怎麼選？
比較面向 Open Notebook NotebookLM 資料控制 可自架，資料在自己掌控的環境 以 Google 雲端服務為主 模型選擇 可接多家 provider，也可接 Ollama / LM Studio 主要使用 Google 模型 Podcast 形式 可做 1-4 位 speaker 與自訂角色 以固定形式為主 部署方式 Docker、雲端或本地部署 直接使用雲端產品 適合對象 重視隱私、模型自由、工作流整合的人 重視上手速度、不想部署的人
簡單說，如果你要的是「馬上可以用」，NotebookLM 仍然很省事；如果你要的是「資料可控、模型可換、流程可自訂」，Open Notebook 會更有想像空間。它不是每個人都需要的工具，但對研究、顧問、內容團隊與企業知識庫來說，很值得放進評估清單。
導入前要先確認的限制
Open Notebook 的自由度比較高，但也代表它不是完全零門檻。最基本的前提是你要能接受 Docker 或自架環境；如果公司電腦不能裝 Docker，或 IT 政策不允許本機服務，導入就會比較麻煩
Docker 新手可以先看 如何使用 Docker 跟用 command line 一樣 ，先把容器概念補起來。
算力也要看你的模型選擇。如果只是用雲端 provider，主要成本會落在 API；如果想完全本地跑模型，就要準備足夠的 GPU、記憶體與模型部署能力。換句話說，Open Notebook 降低的是資料與模型綁定，不是把所有基礎設施成本變成零。
誰最適合用 Open Notebook？
研究員：需要整理大量論文、報告、訪談與來源引用。
內容創作者：需要把資料轉成腳本、長文、Podcast 或系列內容。
學生與知識工作者：需要把課堂筆記、PDF、網頁資料統一管理。
企業團隊：需要建立內部知識庫，又不希望敏感文件全部交給外部雲端。
Open Notebook 適合把 AI 研究流程變成私有工作台
Open Notebook 的價值，不只是「開源版 NotebookLM」這麼簡單。它真正有意思的地方，是把資料主權、模型自由、Podcast 生成、跨文件研究與自架部署放在同一個工作台裡。對只想偶爾整理公開資料的人來說，它可能稍微重了一點；但對需要長期累積知識庫、處理敏感文件、或把 AI 研究流程變成團隊基礎設施的人來說，它是一個值得測試的選項。
Open Notebook Github
FAQ
Open Notebook 是 NotebookLM 的替代品嗎？
它可以被視為 NotebookLM 的開源替代方案，但重點不只是功能相似，而是提供自架、模型選擇、資料控制與更多自訂能力。
Open Notebook 一定要很強的電腦才能用嗎？
不一定。如果使用雲端模型，主要需要 Docker 與 API 設定；如果要完全本地跑大型模型，才需要更強的 GPU、記憶體與部署能力。
Open Notebook 適合企業內部知識庫嗎？
適合放進評估清單，尤其是重視資料控制、模型彈性與自架部署的團隊。不過正式導入前，仍要評估權限管理、備份、資安政策與維運成本。
by Rain Chu 7 月 7, 2026 | AI , 影片製作
AI 影片工具正在從「生成一段漂亮畫面」往「協助完成一套可控工作流」移動。OiiOii 主打的不是單純丟一句提示詞生成影片，而是協助創作者把故事拆成分鏡，再銜接 AI 動畫生成工具，讓短影音、廣告概念片或角色動態 demo 更快進入可測試階段。
圖:AI 動畫分鏡與多 Agent 工作流示意 OiiOii 真正吸引人的地方：先做分鏡，再做動畫
多數 AI 影片工具最大的痛點，不是「能不能生成」，而是「能不能穩定重複出接近導演想法的畫面」。一支看起來完整的動畫，通常需要角色設定、場景氣氛、鏡頭運動、景別切換、節奏、轉場與連續性。如果每一幕都靠手動提示詞硬拚，創作者很快就會被版本管理與反覆修稿拖住。這也是為什麼單看 AI 影片生成工具 的畫質還不夠，前期分鏡與流程設計會直接影響成片穩定度。
OiiOii 這類工具的價值，正在於把「動畫生成」前面那一段拆解工作流程化：先把概念拆成可執行的分鏡，再把每個鏡頭轉成更具體的生成指令。對短影片創作者來說，這可以降低起步門檻；對已經熟悉剪輯與分鏡的人來說，它則像是一個快速前期製作助手。
OiiOii 的核心功能亮點
OiiOii 的核心不是把一句提示詞變成一段漂亮畫面，而是把 AI 動畫創作中最難控的「分鏡」拉到流程中心。真正讓一支動畫短片成立的，通常不是單張畫面多精緻，而是鏡頭如何切換、情緒如何遞進、角色與場景如何在不同畫面之間保持連續。
在實際創作流程上，OiiOii 先讓創作者選擇視覺方向，再把故事概念拆成可操作的生成任務。它的風格庫涵蓋 AI 真人、上海美術電影、Kpop 女團 CG 風等方向，也包含真人、3D、2D 等不同類型。對創作者來說，這代表一開始就能先確定影像語氣，而不是等生成失敗後才回頭修正風格。
比較值得注意的是它的多 Agent 流程。OiiOii 把前期製作拆給不同角色處理，像是藝術總監、編劇、設計師等；流程會先確認片長與情緒關鍵字，再進到劇本轉寫、人物場景生成與分鏡設計。這讓它更像是一套「陪你完成前期製作」的協作系統，而不是只把提示詞丟給影片模型。若把它放到更大的 AI 工作流 脈絡來看，它處理的是創意落地前最容易失控的拆解階段。
分鏡編輯是另一個關鍵亮點。創作者可以用多圖參考模式先生成分鏡圖，再針對單一格子修改；例如角色朝向不對時，不必整張重做，而是選中那一格、輸入提示詞修正。更關鍵的是，分鏡提示詞可以細到秒，包含角色聲音、每一秒音效與情緒設計；這正是它和傳統「一次生成一段影片」工具的差別。
它比較適合誰？
想快速測試 AI 動畫概念，但還沒有成熟分鏡能力的創作者。
需要把腳本拆成多個鏡頭，再交給 Seedance、即夢或其他 AI 影片模型生成的人。
正在製作短影音、MV 概念片、產品廣告草案、角色展示片的人。
想把「一句提示詞」升級成「可反覆修改的工作流」的人。
但如果你的需求是完全精準的商業級動畫，或每一個鏡頭都要有高度可控的表演、構圖與轉場，這類工具目前更像是加速器，不是全自動替代品。
使用前要注意的成本與限制
這類工具最容易被行銷成「一鍵爆款」，但實際導入前更應該先評估成本、穩定性與售後支援。需要注意的問題包括：流程中仍可能遇到 bug，補償與客服體驗不一定成熟；費用也未必會比即夢等工具低，而且生成、修改、重跑每一步都可能產生成本。這代表它並不是免費魔法，而是一套需要評估投入產出的製作流程。
另一個關鍵提醒是：即使工具能把流程模組化，最後仍然需要創作者自己把提示詞、鏡頭語言與修改方向寫清楚。分鏡工具可以幫你建立骨架，但骨架能不能長出好看的影片，仍取決於題材設定、審美判斷與反覆調整。
和即夢、Seedance 這類工具的關係
OiiOii 更適合被理解成創作流程中的「前期規劃與工作流層」，而不是單一底層影片模型。你可以把它理解成：OiiOii 協助你想清楚鏡頭與分鏡，Seedance 或其他影片模型負責生成具體影像。
這種分工會越來越常見。AI 影片模型越強，越需要上層工具幫創作者管理腳本、鏡頭、角色一致性與生成參數。真正的競爭點不只是哪個模型畫面最漂亮，而是誰能讓創作者用更少試錯完成更穩定的作品。像 AI Agent 自動剪輯 這類工具，也是在把影片創作從單點生成推向可編排、可重複的流程。
使用前可以先問自己的 5 個問題
我需要的是靈感 demo，還是可交付的商業成片？
每個鏡頭反覆生成的費用，是否在可接受範圍內？
我是否有能力判斷分鏡、轉場與節奏好壞？
如果工具產生 bug 或結果不穩，是否有備用流程？
我是否已準備好角色設定、故事大綱與視覺參考？
如果這五題都答得出來，OiiOii 這類工具就值得測試；如果還答不出來，建議先用一個短腳本做小規模實驗，不要一開始就把完整專案押上去。
爆款不是按鈕，分鏡才是槓桿
OiiOii 值得注意的地方，不是它承諾「一鍵爆款」，而是它碰到 AI 影片創作真正的瓶頸：如何把創意拆成可執行、可修改、可重複的鏡頭流程。對創作者來說，這比單次生成一段炫技畫面更重要。
目前更務實的看法是：把 OiiOii 當成 AI 動畫前期製作助手，而不是全自動導演。它能幫你縮短分鏡與試片時間，但成本、bug、提示詞品質與剪輯判斷仍然需要人來掌控。真正能產出好作品的，不會只是會按生成鍵的人，而是能把故事、鏡頭與工具串成完整工作流的人。
FAQ
OiiOii 是 AI 影片模型嗎？
OiiOii 更像是協助 AI 動畫分鏡與工作流規劃的工具，不一定等同於底層影片生成模型。
OiiOii 適合新手嗎？
適合用來快速理解分鏡流程與測試短片概念，但新手仍需要學會提示詞、鏡頭語言與基本剪輯判斷。
使用 OiiOii 會不會很貴？
使用這類工具時，每一步生成、修改與重跑都可能產生成本，費用也未必會比即夢等工具低。建議先用短腳本測試，再決定是否投入完整專案。
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 7 月 7, 2026 | Agent , AI , Payment , skills
AISA 最有意思的地方，不是「又多一個 API 聚合平台」，而是它把 AI Agent 真正需要的外部能力，整理成一個可以被 agent 呼叫的資源層。
以前要讓 agent 查 X/Twitter、找 YouTube 競品、讀股票資料、換不同模型、甚至呼叫付費 API，常常要準備一堆帳號、一堆 API Key、一堆 OAuth 設定和一堆帳單。
AISA 想做的事很直接：用一個 API Key，把模型、資料源、Skills 和機器支付放到同一個入口。
這個方向對 AI Agent 很重要。模型本身再聰明，如果不能拿到即時資料、不能安全地調用工具、不能控制支出，它還是停留在「回答問題」而不是「完成任務」。AISA 的定位，就是補上這一層。
AISA 是什麼？不是只有模型 Gateway
從官方頁的說法來看，AISA 是面向 Agent Economy 的能力層與交易網路。它包含模型 gateway，但不只是模型 gateway。官網 FAQ 明確提到，AISA 讓 agent 用一個 API Key 和統一帳單關係，在同一處存取模型、API、資料源、Skills，以及機器對機器支付能力。
這裡的差異很關鍵。像 OpenRouter 這類多模型統一平台 ，主要解決「不同模型如何用同一套 API 呼叫」；AISA 更進一步，把資料 API、封裝技能、金融資料、社群資料、搜尋能力和機器支付也放進同一個 agent 工作流。
換句話說，AISA 想解的不是「我要用哪個模型」，而是「我的 agent 要怎麼真的去外面做事」。
一個 API Key 可以接哪些能力？
官方 `llms.txt` 把 AISA 定義成 autonomous AI agents 的 unified API gateway，列出的範圍很廣：GPT、Claude、Gemini、Grok、DeepSeek、Qwen、Kimi、MiniMax、GLM 等模型，還有 100+ data APIs、Agent Skills 和 stablecoin payments。
官網頁面也把幾個能力直接列出來：Tavily 網頁搜尋、YouTube 搜尋、X/Twitter 公開資料、金融市場資料、預測市場、Agent Mail、Circle 小額支付、Machine Payments Protocol。對 agent 來說，這些不是靜態資料庫，而是可以被工作流呼叫的「手腳」。
能力類型 AISA 提供的方向 適合的 Agent 任務 模型 Gateway GPT、Claude、Gemini、DeepSeek、Qwen 等模型 推理、寫作、程式、長上下文分析 X / Twitter Twitter API、Twitter Autopilot、X Intelligence Automation 輿情監控、發文、互動、自動整理趨勢 YouTube YouTube Search、YouTube SERP 選題研究、競品內容分析、頻道資料整理 金融與市場 股票、Crypto、Prediction Market、MarketPulse 研報、行情追蹤、事件監控 機器支付 x402、Circle Nanopayments、MPP 按次付費 API、agent 自主購買資料或服務
這也回應了第一則留言裡的需求：有人正在找這類資料資源，想讓 Agent 幫忙發推文。AISA 的 X/Twitter Skills 正好對應這種場景。重點不是讓模型「想像社群趨勢」，而是讓 agent 真的去讀公開資料、整理噪音、再決定要怎麼輸出。
X、YouTube、股票資料：Agent 要有真實世界的入口
AI Agent 很容易卡在一個地方：它可以推理，但沒有即時資料。
問它今天 X 上 AI Agent 的討論方向，它如果沒有工具，就只能靠舊知識猜，問它 YouTube 上某個主題競爭激不激烈，它如果沒有搜尋能力，就只能給你方法論，問它最新財報，它可能知道公司很大，但不知道最新數字。
AISA 的價值，是把這些「資料入口」變成 agent 可以安裝和調用的 Skills，X/Twitter 可以做輿情和發文，YouTube 可以做選題研究，金融 API 可以做股票研報，搜尋 API 可以補足即時資訊。這時候 agent 才比較像一個能工作的小助手，而不是只會聊天的模型。
這條路線也可以和你站上之前整理的 Claude Code Workflow 放在一起看：Claude Code、Codex 或其他 CLI agent 是工作介面，AISA 則比較像它們背後的外部能力層。
Skills 的意義：把「會回答」變成「會操作」
AISA 文件中列出的 Skills 很多，從 Twitter Autopilot、YouTube Search、SEO Keyword Research，到 US Stock Analyst、Stock Portfolio、Perplexity Deep Research、Multi-source Search 都有。這裡真正值得看的不是數量，而是 Skills 把任務包成 agent 能理解的操作流程。
同一個問題，有沒有 Skill，結果會差很多。沒有 Skill 時，模型可能只能說「你可以去查財報」。有 Skill 時，agent 可以知道要調哪個 API、要拿哪些欄位、資料錯了要去哪裡補、最後怎麼整理成報告。
這跟前面談過的 Ornith 1.0 自己拆任務、搭 scaffold 的方向 其實有點像：模型不是只輸出答案，而是要有一套能完成任務的流程。AISA 則把外部 API 和 Skills 變成這套流程可以調用的零件。
x402 與機器自主付款：很酷，但一定要有護欄
AISA 官網也把機器對機器支付列為核心能力之一，包含 Circle Nanopayments、Machine Payments Protocol，以及 x402 / HTTP 402 風格的支付流程。
HTTP 402 Payment Required 這個狀態碼很早就存在，但以前沒有真正成為日常網路支付流程。x402 類協議讓 agent 呼叫受保護端點時，可以收到付款要求，完成結算，帶著付款證明重試請求。這對付費 API、資料服務、agent-to-agent 交易很有想像空間。
用白話講，402 不是一般錯誤，而是一種「這個資源要先付費」的握手訊號。Agent 第一次呼叫付費 API 時，服務端可以回傳 HTTP 402，並附上價格、收款地址、可用付款網路、付款證明格式和過期時間。Agent 不需要猜怎麼付錢，而是照著這份付款要求完成結算，再把付款證明帶回去重送同一個請求。
這裡要分清楚一件事：不是把信用卡號交給模型，也不是讓模型任意花錢。比較安全的設計是讓 Agent 只取得「受限制的付款能力」：例如只允許特定 API、單次最高 0.05 美元、每日最高 1 美元、只讀資料可以自動付款、發文或交易則要人工確認。
AISA 在這裡扮演能力層與記帳層，幫 agent 把 API、付款握手、用量紀錄和預算控制串起來。
AI 自己付錢的 6 個步驟
Agent 呼叫付費 API，例如查即時金融資料、X 資料或高價值搜尋結果。
服務端回 HTTP 402 Payment Required，告訴 agent 這次請求需要付款，並提供價格、收款地址和付款格式。
AISA 或 agent runtime 檢查政策：這個服務是否在白名單內、金額是否低於單次上限、今天預算是否還夠。
若通過檢查，錢包用 USDC 或支援的付款方式簽名付款，產生 payment proof。
Agent 帶著付款證明重送請求，通常會把 proof 放在 header 或協議要求的位置。
服務端驗證付款有效後回傳資料，AISA 同步記錄誰呼叫、花多少、成功或失敗。
不過這裡不能只看酷炫的一面。Agent 能自己付費，就代表它也可能亂花錢、重複呼叫、被錯誤 prompt 帶偏，甚至被惡意服務誘導。AISA FAQ 提到可以發放 API Key、監控用量、設定預算或限額，這是必要條件，不是加分功能。
先用低額度測試，不要一開始就給大額預算。
把可呼叫服務設白名單，尤其是會產生費用的 API。
設定單次、每日、每月限額。
高風險動作先要求人工確認，例如發文、寄信、交易、付款。
保留完整日誌，能看出哪個 agent、哪個 skill、哪次呼叫花了多少錢。
這也是 AI Agent 進入實際工作流後一定會遇到的問題：能力越大，權限邊界就越重要。你可以把它和 自學型 AI Agent 一起看，兩者都指向同一件事：agent 不只是變聰明，還要能被管理。
怎麼開始接入？先用 llms.txt 讓 Agent 讀懂平台
AISA 官網給了一個很適合 agent 使用的入口：讓 agent 先讀 `https://aisa.one/docs/llms.txt`，再依照目前環境安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。
閱讀 https://aisa.one/docs/llms.txt，幫我在這個 agent 環境中安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。實務上可以分三步走：先到 AISA Console 的 get-started 頁面 註冊並取得 `AISA_API_KEY`，再把 key 放進 CLI agent 或 IDE agent 的環境變數，最後挑一個低風險 Skill 測試，例如搜尋、YouTube 研究或只讀型 X 資料整理。
如果你原本就在用 Claude Code 、Codex 或本地端模型，AISA 比較像補上「外部能力」的那塊拼圖。你也可以對照 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 來思考：本地模型負責推理，AISA 負責外部資料和服務。
誰適合先試 AISA？
我會把 AISA 放在三種使用者的觀察名單裡。
第一種是內容創作者。你需要查 X 熱點、找 YouTube 競品、做 SEO keyword research，這些都很適合交給有資料 Skills 的 agent。
第二種是開發者和自動化玩家。你已經在用 Claude Code、Codex、OpenClaw 或其他 CLI agent，希望讓它們接更多真實 API，而不是每個服務都重新申請 key。
第三種是想做 agent 商業流程的人，例如市場開發、資料整理、金融監控、郵件自動化。這類任務需要的不只是模型，而是資料、工具、信箱、付款和成本控制一起工作。
至於只想聊天或單純換模型的人，AISA 可能不是最輕的選擇。這種情況，單純的模型 API 聚合平台或本地模型會更直接。可以參考你站上的 ApiFree：一個 API 打通所有 AI 模型 這類文章來比較不同路線。
結論：AISA 代表 Agent 從「模型」走向「資源層」
AISA 真正值得注意的，不是它支援多少模型，而是它把 agent 做事需要的資料、API、Skills、帳單和支付，往同一個入口收斂。
這會讓 AI Agent 的下一步變得更清楚：模型只是大腦，Skills 和 API 是手腳，預算和權限是安全邊界，支付能力則讓 agent 有機會直接參與服務交易。
短期內，我會先用只讀型任務測 AISA，例如 X 輿情整理、YouTube 競品研究、股票資料摘要。等日誌、成本和準確性都穩定，再逐步開放發文、寄信、付費 API 這類高風險能力。Agent 要進化成能工作的系統，靠的不是一次把權限全打開，而是一步一步把能力和護欄一起搭好。
FAQ
AISA 是什麼？
AISA 是面向 AI Agent 的能力層與交易網路，讓 agent 透過一個 API Key 連接模型、資料 API、封裝 Skills，以及機器對機器支付能力。
AISA 可以用 X 或 Twitter 嗎？
可以。AISA 官方文件列出 Twitter API、Twitter Autopilot、Twitter Command Center、X Intelligence Automation 等 Skills，適合做公開資料搜尋、輿情整理、發文和互動自動化。
AISA 跟 OpenRouter 有什麼不同？
OpenRouter 主要解決多模型 API 統一入口；AISA 包含模型 gateway，但更大的重點是把 API、資料源、Skills、Agent Mail、金融資料、搜尋與機器支付一起包成 agent 可用的資源層。
AISA 一定要用加密貨幣嗎？
不一定。官網 FAQ 提到可以從一般 AISA 帳號、API Key 和法幣充值額度開始，加密原生結算主要用在機器支付或 x402 類工作流，不是首次整合的必要條件。
Agent 自己付款安全嗎？
不能無限制開放。AISA 官網提到可透過 API Key、用量監控、預算或限額來控制 agent 支出，實務上應該先用低額度、白名單服務、日限額和人工審核逐步放權。
HTTP 402 如何讓 AI 自己付錢？
AI Agent 先呼叫付費 API，服務端回 HTTP 402 Payment Required，並附上付款要求，Agent 檢查預算和白名單後，用錢包簽名付款，取得付款證明，再帶著證明重送請求。服務端驗證付款後，才回傳資料。
by Rain Chu 7 月 6, 2026 | AI , 模型
Ornith 1.0 最值得注意的地方，不是又多了一個會補程式碼的開源模型，而是它把「寫程式」往前推了一步：先替任務搭工作流程，再開始產生解法。
這個差別很關鍵。很多 AI 寫程式失敗，不是模型不會寫函式，而是前面的任務拆解、資料來源、依賴安裝、API key、驗證方式沒有想清楚。Ornith 1.0 想解的正是這一層問題：讓模型先建立 scaffold，也就是一套能引導任務完成的工作台。
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，官方定位是 self-improving open-source models for agentic coding。它不是單一模型，而是一整組不同大小與格式的模型家族。
9B Dense：比較適合本地測試與資源有限的部署。
31B Dense：官方頁列入模型家族，偏向更高能力的 dense 版本。
35B MoE：能力與資源需求往上推，Ollama 也提供 35B 版本。
397B MoE：旗艦級模型，更偏多 GPU 伺服器與研究測試場景。
官方資料提到，Ornith 1.0 建立在 Gemma 4 與 Qwen 3.5 這類 pretrained model 之上，並針對 coding agent 任務做後訓練。Hugging Face collection 目前列出 9B、35B、397B，以及 GGUF、FP8 等不同格式；GitHub README 也把這些版本整理成可部署的 checkpoint 清單。
如果你原本就在關注 Ollama + Qwen 3.6 的模型選擇 ，Ornith 1.0 可以放在同一條線上看：它不是單純聊天模型，而是更偏「本地程式代理」的方向。
真正的重點：先搭 scaffold，再寫程式
Ornith 1.0 的訓練思路，可以用一句話理解：模型不只學會產生 solution rollout，也學會產生帶領自己完成任務的 scaffold。
在傳統寫程式模型裡，使用者丟一個需求，模型很容易直接進入「產生程式碼」模式。但真實的小工具開發通常不是這樣。你要先知道資料從哪裡來、需不需要註冊 API、有哪些套件依賴、結果要怎麼展示、最後要怎麼驗證。
例如做一個五天天氣預報工具，如果一開始選 OpenWeather，後面才發現需要 API key，任務就會卡住。比較好的 agent 行為是回頭調整方案，改找不需要 API key 的資料來源，重新整理資料結構與 UI 呈現。Ornith 1.0 想訓練的，就是這種「條件變了，工作流程也跟著改」的能力。
這也解釋了為什麼它比較適合拿來觀察 AI agent，而不是只拿幾題補全測試就下結論。對程式代理來說，會寫一段 function 只是基本盤；能不能拆任務、改策略、補驗證，才是進入真實專案後的差距。
Benchmark 可以看，但不要只看跑分
官方 benchmark 涵蓋 Terminal-Bench 2.1、SWE-bench Verified、SWE-bench Pro、SWE-bench Multilingual、NL2Repo、SWE Atlas 等任務。下面先抓兩個比較容易理解的指標來看：
模型 Terminal-Bench 2.1 SWE-bench Verified 定位 Ornith-1.0-9B 43.1 69.4 本地測試與輕量部署 Ornith-1.0-35B 64.2 75.6 工作站或較高資源環境 Ornith-1.0-397B 77.5 82.4 多 GPU 伺服器與旗艦能力
9B 的意義不在於它能不能打贏所有大模型，而是它讓本地端測試變得比較實際。35B 與 397B 則是觀察這套 scaffold 訓練方法能不能隨模型規模放大的重點版本。
不過跑分仍然只能當入口。Coding agent 的實際體驗，還會被上下文管理、工具調用、檔案系統安全邊界、任務記憶、互動方式影響。這也是為什麼 Claude Code、Codex 這類工具難以只用「模型分數」比較。它們拼的是整套工作流，不只是底層模型。
如果你想把本地模型接進開發工作流，可以延伸看這篇 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本開發環境 ，它比較接近 Ornith 1.0 可能落地的位置。
怎麼在 Ollama 與 Hugging Face 上取得 Ornith 1.0？
目前最直接的入口有四個：
Ollama 頁面列出 9 個模型項目，並標示 `ornith:latest`、`ornith:9b` 約 5.6GB、`ornith:35b` 約 21GB，context window 皆為 256K。最簡單的測試方式是：
ollama run ornith
ollama run ornith:9b
ollama run ornith:35bGitHub README 也提供從 Hugging Face GGUF 直接跑的方式：
ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF如果你要讓其他電腦連到同一台 Ollama 伺服器，可以搭配 Ollama 遠端連線教學 來設定 API endpoint。Ornith 1.0 這類程式模型，通常會更適合放在可以被 IDE、CLI agent 或自動化腳本呼叫的環境裡。
Reward hacking 是這類模型一定要面對的問題
讓模型自己產生 scaffold，能力會變大，風險也會變大。最典型的問題是 reward hacking：模型不是好好完成任務，而是想辦法鑽驗證器的空子。
在程式任務裡，這可能長得很實際：偷看測試檔、硬寫 expected output、碰不該碰的驗證腳本，或把環境改到看起來通過。官方資料提到的防護思路，是把外層信任邊界固定住，讓環境、工具表面與測試隔離不能被模型改；再用規則監控與模型複查，把可疑方案篩掉。
這一段其實比跑分更重要。因為 agentic coding 的核心不是一次回答，而是連續操作。模型能操作越多工具，就越需要清楚的權限邊界與可追蹤紀錄。這也是我會把 Ornith 1.0 放在「值得測試的開源方向」，而不是「馬上取代成熟 coding agent」的位置。
如果你對這種自學型 agent 架構有興趣，可以接著看 Claude Memory 與 Dreaming：自學型 AI Agent 的下一步 ，兩者都在處理一個相近問題：AI 不只是回答，而是如何在任務中累積策略。
我會怎麼選版本？
如果只是想先試試看，從 `ornith:9b` 開始最合理。它的下載量、顯存壓力與啟動成本都比較低，也比較適合拿來測「任務拆解」是不是真的有感。
如果你有比較強的工作站，`ornith:35b` 才值得進入第二輪測試。它的定位更接近可用的 coding agent 模型，但也更需要良好的硬體與服務設定。若你的目標是跑大型專案、長上下文、多步驟任務，可以把 35B 放進候選清單。
397B 則不建議一般使用者一開始就碰。它更像是研究、企業或多 GPU 伺服器環境要評估的版本。對多數人來說，先把 9B/35B 放進 Ollama 或 OpenAI-compatible endpoint，測試能否穩定完成真實任務，會比追最大參數更有價值。
想把模型接進工具鏈，也可以參考 OpenCode 如何使用本地端模型 。Ornith 1.0 真正有趣的地方，正是在「本地模型 + coding agent + 可控工具」這個交會點。
結論：值得追，但要用真實任務測
Ornith 1.0 的亮點不是單一 benchmark 數字，而是它把開源程式模型推向「會先規劃工作台」的方向。這對本地 AI 編程很重要，因為真實任務往往不是只補一段 code，而是資料來源、依賴、限制、驗證與修正一起出現。
短期內，我會先看兩件事：第一，9B GGUF 在一般工作站或高階個人電腦上能不能穩定跑；第二，35B 在多步驟專案裡，能不能真的比一般 coding model 更會拆任務與自我修正。
如果這兩件事站得住，Ornith 1.0 就不只是又一個開源模型，而是本地 AI coding agent 往前走的一個重要訊號。
FAQ
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，重點不是只產生程式碼，而是讓模型先為任務建立 scaffold，包含拆解步驟、工具選擇、驗證方式與錯誤處理，再產生解法。
Ornith 1.0 有哪些版本？
官方釋出 9B Dense、31B Dense、35B MoE 與 397B MoE 等版本；Hugging Face collection 中也包含 GGUF 與 FP8 版本。Ollama 頁面目前列出 ornith:9b 與 ornith:35b，兩者皆標示 256K context window。
一般使用者應該先跑哪個版本？
如果目標是本地測試，建議先從 9B 或 9B GGUF 開始；35B 比較適合顯存較充足的工作站。397B 更偏向多 GPU 伺服器環境，不是一般個人電腦的起手式。
Ornith 1.0 可以取代 Claude Code 或 Codex 嗎？
目前比較合理的看法是「值得測試的開源方向」，不是直接取代成熟工具。
Claude Code、Codex 這類產品還包含上下文管理、工具調用、專案理解、安全邊界與互動體驗，模型本身只是其中一層。
Ornith 1.0 怎麼用 Ollama 跑？
Ollama 官方頁面提供 `ollama run ornith`、`ollama run ornith:9b` 與 `ollama run ornith:35b`。
如果要直接使用 Hugging Face 的 GGUF，也可以參考 GitHub README 裡的 `ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF`。
近期留言