by Rain Chu | 7 月 8, 2026 | AI, 影片製作
OpenMontage 最吸引我的地方，不是「一句話自動做完 AI 影片」這種口號，而是它把 AI 影片製作拆成一套比較像真實片廠的工程流程：研究、提案、腳本、分鏡、素材、剪輯、合成、檢查，全部交給 coding agent 去編排。
這件事有意思，因為現在很多 AI 影片工具其實只是在「生成幾段畫面」或「把幾張圖做動」, OpenMontage 的方向不太一樣，它把影片看成一個專案，而不是單一模型輸出, 你可以用生成式素材，也可以走免費素材檢索，也可以讓 Remotion、HyperFrames、FFmpeg、TTS、字幕工具一起工作。
如果你之前看過我寫的 HyperFrames 用 HTML 寫影片，OpenMontage 可以理解成更上層的總控：HyperFrames 或 Remotion 是渲染舞台，OpenMontage 則負責決定要演哪一齣、需要哪些素材、哪個管線比較適合。
先講結論：它不是單一工具，而是一套 agentic video workflow
OpenMontage 官方把它定位成 open-source agentic video production system。
這句話翻成白話就是：你不是打開一個剪輯軟體慢慢拉時間軸，而是把需求丟給 AI coding assistant，讓它在專案裡呼叫一串工具，最後產出可渲染的影片專案。
它目前主打 12 條 production pipelines、52 個 production tools、數百個 agent skills。這些數字先不用神化，真正重要的是架構：OpenMontage 把「做影片」拆成管線選擇問題。要做動畫解說、紀錄片蒙太奇、動態文字、產品廣告、Podcast repurpose、字幕翻譯，走的流程不應該一樣。
這也很符合我對 AI Agent 的看法。真正能落地的 Agent，不是一直聊天，而是能選工具、讀檔、跑命令、檢查輸出、失敗後改路線。這點跟我前面整理過的 Ornith 35B 與 Hermes 工作流是同一個方向：模型不是主角，流程控制才是主角。
本地部署的基本盤：Python、Node、FFmpeg，再加一個 AI coding assistant
OpenMontage 的安裝門檻不算低，但也沒有到很誇張。官方 README 的 Quick Start 是：
git clone https://github.com/calesthio/OpenMontage.git
cd OpenMontage
make setup
如果是在 Windows 環境，配套筆記把步驟拆得更實際：先裝 Git、Python 3.11、Node.js；建立 venv；安裝 Python requirements；進 remotion-composer 跑 npm install；再預熱 HyperFrames。簡化後大概是這樣：
git clone https://github.com/calesthio/OpenMontage
cd OpenMontage
python -m venv venv
venv\Scripts\activate
python -m pip install -r requirements.txt
cd remotion-composer
npm install
cd ..
npx --yes hyperframes --version
OpenMontage 不是只有 Python 腳本，它會用 Remotion 做 React 影片渲染，也會用 HyperFrames 做 HTML/GSAP 類型的動態文字與 motion graphics，也就是說，它本質上是一個跨 Python、Node、前端渲染、影音處理的混合專案。
如果你本來就在研究 AI 影片生成模型，可以延伸看 Wan 2.1 的整理，OpenMontage 不是要取代這些模型，而是把模型、素材庫、TTS、剪輯和渲染器放進同一條可控流程。
零 API Key 可以玩，但不要把零成本理解錯
OpenMontage 官方 README 有一段很重要：沒有付費 API key 也能做東西。它可以用 Piper TTS、本地字幕、FFmpeg、Remotion、HyperFrames，以及 Archive.org、NASA、Wikimedia Commons 這類開放素材來源，配套筆記則建議本地中文配音可以接 dots.tts，走 OpenAI 相容的本地 API 服務。
但我會把這件事講精準一點：零 API Key 不等於零成本。你省下的是雲端生成 API 的帳單，但仍然有時間成本、硬碟成本、顯卡成本、網路下載成本，以及 Agent 跑錯路線後的重跑成本。
比較正確的理解是：OpenMontage 讓你有機會把成本從「每次生成都付費」改成「本地工具與免費素材優先，必要時才接付費 provider」。這也是我喜歡本地 AI 工作流的原因，重點不是假裝不用花錢，而是你可以決定錢花在哪裡。
如果你對本地 TTS 有興趣，可以接著看 VoxelCPM 本地 TTS 與離線部署。OpenMontage 這類工具能不能舒服使用，中文配音品質其實會大幅影響成品觀感。
三條路線：生成類、檢索類、動態文字類
真正開始用 OpenMontage 時，我覺得要先把題目分成三種，不要一律丟給同一條管線。
- 生成類：適合知識動畫、概念解釋、抽象主題。重點是腳本、旁白、視覺生成與字幕。
- 檢索類：適合森林、海浪、城市、科技感、自然景觀這種通用氛圍題。重點是免費素材庫與剪輯節奏。
- 動態文字類：適合頻道預告、產品短片、宣傳片、資訊卡。重點是排版、節奏、字卡與音樂。
這裡最大的坑是「題目和管線不匹配」。例如你想做歷史事件、特定人物、某次火箭發射、某個實驗室場景，免費素材庫不一定找得到精準畫面。這種題目硬走檢索管線，很容易找到一堆氣氛接近但內容對不上的 B-roll。
相反地，如果題目是「地球的呼吸」「雨夜城市」「森林甦醒」這類氛圍型主題，檢索管線就很適合。因為它不需要某個唯一正確鏡頭，只要找到情緒與節奏對的真實素材，就能剪成一支完整作品。
這點也可以和 OiiOii 動畫分鏡工作流放在一起看。AI 影片的關鍵不只是模型，而是你能不能在生成前就把「題目、鏡頭、節奏、素材來源」講清楚。
OpenMontage 最值得記下來的 6 個坑
這次配套筆記最有價值的地方，是把幾個踩坑點寫得很直接。我整理成實作時應該先記在旁邊的清單。
- 不要亂加逐詞字幕。動畫解說如果要求逐字、逐詞字幕，切詞可能會很碎。普通字幕反而比較乾淨。
- 檢索管線要避開大規模 corpus builder。直接把 NASA、Archive.org 整段抓下來建語料庫，很容易下載失控。快速路線是 direct_clip_search，只用 Pexels / Pixabay，720p，限制槽位。
- 不要讓 Agent 自己亂翻中文搜尋詞。檢索素材時，最好把每個鏡頭先翻成 5 個字以內的英文短語，例如 misty forest valley、ocean waves、city rain night。
- 提示詞會影響管線選擇。如果你寫「科普、旁白、TTS、中文字幕」，系統很可能走 animated-explainer；如果你要真實素材蒙太奇，就要明確寫 documentary montage、real footage only、direct_clip_search、no narration。
- 8GB 顯卡不適合硬衝本地影片生成。能塞進去的模型選擇有限，還要 CPU offload，最後可能等很久只得到短短幾秒低解析片段。
- 免費素材路線適合通用題，不適合特定命名物。森林、城市、海浪很好找；某個具名歷史場景或特定設備就不要硬搜。
OpenMontage 現階段最合理的期待值：可以跑通，可以做出東西，但要用對題目、用對管線、不要期待它第一次就像成熟商業剪輯工具。
我會怎麼下 prompt：先鎖管線，再鎖素材來源
OpenMontage 不是越自由越好用。你如果只寫「幫我做一支很酷的 AI 影片」，Agent 會需要猜太多東西：要不要旁白？要不要真實素材？要不要生成圖片？要不要字幕？要用 Remotion 還是 HyperFrames？
比較穩的 prompt 應該長這樣：
製作一支 60 秒紀錄片蒙太奇，主題是「地球的呼吸」。
管線：documentary-montage。
素材：只用真實素材，只從 Pexels / Pixabay 搜尋，走 direct_clip_search，不要 Archive.org，不要 NASA，不要 corpus_builder。
音訊：不要旁白，只放背景音樂。
畫面：720p，10 個素材槽位。
搜尋詞：每個槽位用我給的英文短語，不要自行改寫。
輸出：Remotion 渲染，三段中文畫面文字卡，淡入淡出。
如果要做動態文字宣傳片，就要反過來鎖死：不要檢索、不要生成圖片、全部用程序化排版文字、渲染引擎用 HyperFrames/GSAP。這樣 Agent 才不會跑去找素材，或突然把簡單字卡做成一堆不必要的生成圖。
這也是我覺得 OpenMontage 適合搭配 Codex 這類 coding interface 的原因。它需要的是能讀專案、跑命令、改檔案、看錯誤、重新執行的環境，不只是單純聊天介面。
8GB 顯卡可以玩嗎？可以，但不要從本地影片生成開始
本地影片生成性價比偏低，Wan2.1-1.3B 這類模型可以勉強塞，但要開 CPU offload；輸出通常短、解析度不高，等待時間也不短。圖生影片若不小心切到更大的 14B 模型，8GB 顯卡直接爆掉也不奇怪。
所以如果你的硬體只有 8GB VRAM，我會建議先走三條比較務實的路：
- 用免費素材庫做真實素材蒙太奇。
- 用 Remotion / HyperFrames 做程序化動畫與動態文字。
- 把本地 TTS、字幕、剪輯、自動化流程先跑順。
等流程穩了，再評估要不要加付費 API 或升級硬體，如果你正在考慮 AI 工作站，RTX PRO 6000 Blackwell 顯卡選購那篇可以搭配看，OpenMontage 這種工作流很吃「整體系統」，不只是顯卡型號而已。
適合願意把影片當工程專案的人
OpenMontage 現在比較適合三種人。
- 第一種是技術型創作者：你願意看 log、改 prompt、裝依賴、調管線，OpenMontage 會給你很大的控制權。
- 第二種是想把內容流程自動化的人：例如固定產出知識動畫、短片、宣傳片、字幕版本，這套管線可以慢慢沉澱成自己的模板。
- 第三種是正在研究 AI Agent 的人：OpenMontage 很適合觀察 Agent 如何做工具選擇、階段驗證、失敗重試與輸出檢查。
但如果你期待的是「打一句話、三分鐘後給我商業級成片」，它目前不會是最好的選擇，它更像一個正在快速演化的開源片廠骨架，需要你願意進去調教。
資源與安全連結整理
OpenMontage 的價值在「可編排」，不是魔法
我會把 OpenMontage 看成 AI 影片製作的 agentic framework，而不是一個單純的 AI 影片生成器。它真正有價值的地方，是把影片製作拆成可選管線、可替換工具、可檢查輸出的流程。
它現在最適合的打法，是先從零 API Key 或低成本路線開始：本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg，等流程跑通，再依照題目決定要不要加 Veo、Kling、FLUX、OpenAI TTS 或其他 provider。
一句話總結：OpenMontage 不是把創作變成不用思考，而是把創作變成可以被 Agent 執行、被人類審核、被工程流程反覆改進的系統。這條路如果走通，AI 影片工具會從「生成一段畫面」進化成「管理一個製作流程」。
FAQ
OpenMontage 是什麼？
OpenMontage 是一套開源的 agentic video production system，讓 AI coding assistant 透過管線方式處理研究、腳本、素材、剪輯、渲染與檢查，不只是單一影片生成模型。
OpenMontage 可以不用付費 API Key 嗎？
可以。它可以使用本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg 等工具先跑出作品。不過零 API Key 不等於零成本，仍然有硬體、時間、下載與維護成本。
OpenMontage 適合用在哪些題目？
通用氛圍類題目適合走真實素材檢索，知識解釋適合走動畫解說，產品或頻道宣傳適合走動態文字。特定歷史事件、具名人物或稀有場景，不適合硬走免費素材檢索。
by Rain Chu | 7 月 8, 2026 | AI, Hermes, 模型
Ornith 35B 真正有趣的地方，不是「小模型打敗大模型」這句話本身，而是它把本地 AI 編程 Agent 這條路線重新推到桌面上：我們是不是可以把一部分 coding agent 能力，從雲端 API 搬回自己的機器？
這個問題很現實。雲端工具反應快、整合好，但 token 成本、隱私、企業程式碼外流、模型選擇權，始終卡在開發者心裡。本地模型則剛好反過來：你要自己處理硬體、速度、部署與穩定性，但換來的是成本可控、資料留在本地，以及比較完整的架構控制權。
Ornith 1.0 前一篇已經整理過核心定位，這篇換個角度：如果把 Ornith 35B 接進 Hermes 這類 Agent 工作流，它應該放在哪裡？是主控模型、任務 worker，還是只適合做某些短程工具任務？
先講結論：35B 有想像空間，但不要把 benchmark 當保證書
Ornith 35B 的吸引力在於，它不是 397B 那種多 GPU 伺服器級模型，也不是 9B 那種比較像入門測試的輕量模型。35B 落在一個很微妙的位置：高階個人工作站有機會跑，能力又足以進入 coding agent 測試。
官方數據裡，Ornith 35B 在 Terminal-Bench 2.1 拿到 64.2，SWE-bench Verified 拿到 75.6。397B 更高，Terminal-Bench 2.1 為 77.5，SWE-bench Verified 為 82.4。這些分數很漂亮，但漂亮不等於放進你的專案就穩。
| 模型 | Terminal-Bench 2.1 | SWE-bench Verified | 適合觀察的方向 |
|---|
| Ornith-1.0-9B | 43.1 | 69.4 | 低成本本地測試、短程 worker |
| Ornith-1.0-35B | 64.2 | 75.6 | 本地 coding agent 實驗主力 |
| Ornith-1.0-397B | 77.5 | 82.4 | 企業級或多 GPU 私有部署 |
這也是為什麼我不想把它寫成「35B 擊敗雲端大模型」這種單線結論。更準確的說法是：Ornith 35B 在某些 agentic coding benchmark 和視覺/前端生成任務上很值得測，但長程任務和大型 codebase 仍要小心。
Self-Scaffolding RL 到底改變了什麼？
一般 coding agent 常見的架構，是人類工程師先寫好 harness：
什麼時候讀檔、什麼時候跑 command、失敗怎麼 retry、怎麼記憶、怎麼驗證。模型很聰明，但它通常只是被放進這套流程裡填空。
Ornith 1.0 的 Self-Scaffolding RL 想走的是另一條路：
讓模型不只學 solution rollout，也學會產生任務 scaffold。換句話說，它不只是演員，也開始學會改劇本，任務跑得好，解法和引導解法的 scaffold 都一起被獎勵；任務跑得差，兩者都會被調整。
這和 前一篇 Ornith 1.0 介紹裡談到的「先搭工作台，再開始解題」是同一件事。對開發者來說，重點不是模型多會補 code，而是它能不能在遇到限制、錯誤、缺資料時，重新安排自己的工作流程。
Hermes 的位置：還是 harness，但已經比較動態
Hermes 在這裡比較像運行時的動態編排層。它仍然是 harness，但不是傳統那種完全寫死的腳本；它可以在任務過程中調整步驟、改工具、補資料，讓 agent 比較像真的在做一件工作，而不是只照著固定模板回答。
把 Ornith 35B 接進 Hermes 的想像是：Hermes 負責任務框架、工具調用和流程管理，Ornith 35B 負責本地推理、程式生成、局部 debug 與前端/視覺任務。這樣的分工，比「讓 35B 一個模型主控所有事情」更合理。
站上之前有兩篇 Hermes 相關內容可以放在一起看：
Hermes Agent 完整實測 和 Hermes Agent WebUI。如果 Hermes 是工作台，Ornith 35B 就是可以被放進工作台裡的一顆本地引擎。
實測起來
Ornith 的幻覺率仍然偏高，很多 fine-tune 模型 benchmark 強，但長程任務容易歇菜；更穩的方式可能是官方模型搭配優化過的 Jinja template 來跑長程任務。
小模型非常適合做 worker，處理葉節點任務，用完即毀；但如果拿它當整個系統的主控，很可能是用錯地方，可以當作 Ornith 35B 的導入原則。
- 短程、明確、可驗證的任務，可以交給 35B worker。
- 長程規劃、多輪重構、跨大型 codebase 的任務，先不要完全放權。
- 需要主控決策時，最好搭配更強模型或更嚴格的 Hermes/harness。
- 所有結果要能重跑、能測試、能看 log，不要只看模型自我回報。
這裡的核心不是「小模型沒用」，而是小模型要放對位置，主控、規劃、長上下文記憶是白領工作；批次修小 bug、生成局部元件、跑固定格式分析，反而是本地 35B 很適合切進去的地方。
本地部署的價值：不是零成本，而是可控成本
本地跑 Ornith 35B 很容易被包裝成「零 token 成本」。這句話只說對一半。雲端 token 成本下降了，但你換成了硬體成本、電費、散熱、維護、模型部署和速度瓶頸。
真正的優勢是可控。你知道模型跑在哪裡，知道資料是否離開內網，知道長任務不會因為 token 計費一路燒上去。對需要保護程式碼或內部文件的團隊，這比單純省錢更重要。
如果你本來就在研究本地 AI 開發環境，可以延伸看 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境，以及 Mac Studio 跑大型模型的 VRAM 調整。Ornith 35B 的問題，最後仍然會回到你的硬體、記憶體和任務型態。
我會怎麼把 Ornith 35B 放進 Hermes？
我不會一開始就讓 Ornith 35B 當整個 Hermes 系統的最高決策者。比較合理的導入方式，是先讓它做 worker。
- 先挑 5 到 10 個固定任務，例如小型前端元件、局部 bug 修復、測試補齊、簡單重構。
- 每個任務都要有明確驗證方式，例如單元測試、Playwright 截圖、lint、build。
- Hermes 負責任務切分、重試策略、log 收集和失敗回報。
- Ornith 35B 只處理其中一段，不直接改全專案、不直接做不可逆決策。
- 連續跑幾輪，看錯誤類型是否固定，再決定要不要擴大權限。
這樣的測法比較慢，但比較接近真實工程，AI Agent 的能力不是靠一個漂亮 demo 決定，而是看它能不能在可重複、可驗證、可回滾的流程裡穩定工作。
Ornith 35B 是值得測的本地引擎，不是萬能主控
Ornith 35B 最好的位置，暫時不是取代 Claude Code、Codex 或雲端大模型，而是進入 Hermes 這類 agent 工作流，成為一顆可控、可替換、可驗證的本地推理引擎。
它的優點很清楚：成本可控、資料留在本地、前端與視覺任務有亮點、自我 debug 的思路值得追。它的風險也很清楚：benchmark 不能直接代表長程任務，幻覺與錯誤累積仍然存在，小模型放錯位置會把整個 agent 工作流拖垮。
所以我會把 Ornith 35B 放進觀察名單，但會用 worker 的方式開始，而不是把整個系統交給它。這條路如果走通，本地 AI 編程的價值就不是「省 token」而已，而是開發者重新拿回 AI 架構控制權。
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:35b
GitHub 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`。
by Rain Chu | 7 月 6, 2026 | Agent, AI, claude
Memory 讓 agent 記得自己的工作經驗,Dreaming 則負責在背景整理、驗證與回填這些經驗。
AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。
這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。
為什麼 Agent 需要 Memory?
現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。
這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。
Memory 的設計:把記憶當成檔案系統
這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。
從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。
多 Agent 系統裡,記憶不能只有「我記得」
單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。
這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。
如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。
Dreaming 是什麼?
Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。
這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。
Memory 與 Dreaming 的差別
| 項目 | Memory | Dreaming |
|---|
| 運作時間 | 任務進行中即時讀寫 | 任務外的非同步整理 |
| 主要目標 | 讓 agent 記得當前與過去經驗 | 驗證、去重、回填與組織記憶 |
| 視角 | 單一 agent 或單一 session 為主 | 跨多個 sessions 與多個 agents |
| 適合解決 | 避免重複調查、保留工作脈絡 | 找共同錯誤、萃取模式、清理 stale memory |
| 對效能影響 | 在任務路徑上,要注意 token 與延遲 | 離線執行,不增加 hot path latency |
早期案例透露了什麼?
早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。
圖表只是把兩個早期案例視覺化。它們不是通用保證,但足以說明 memory 與 dreaming 對長任務 agent 的潛力。
這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。
SRE Agent 的例子最容易理解
假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。
這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。
這種模式非常適合 自我進化 AI Agent 架構。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。
實作時最該注意的三件事
第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。
第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。
第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。
我的判斷:Memory 會成為 Agent 系統的資料庫層
如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。
Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。
FAQ
AI Agent memory 是什麼?
AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。
Dreaming 和一般 memory 有什麼不同?
Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。
Memory 會不會讓 agent 學到錯誤資訊?
會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。
什麼情境最適合導入 agent memory?
最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。
近期留言