開源專案 on KnightLi的博客

Joplin：離線優先、支援同步和加密的開源筆記應用

Sat, 30 May 2026 14:39:48 +0800

Joplin 是一個開源筆記與待辦應用，支援 Windows、macOS、Linux、Android 和 iOS。它的定位不是輕量便箋，而是一個可以長期保存大量筆記、同步到多裝置，並盡量讓資料掌握在使用者手裡的知識管理工具。

Joplin 的筆記使用 Markdown 格式，支援筆記本、標籤、全文搜尋、附件、待辦事項、外掛、主題和瀏覽器 Web Clipper。對於想從 Evernote 遷移出來，或者想用更開放格式管理個人資料的人來說，它是很常見的選擇。

Joplin 解決什麼問題

很多筆記應用用起來方便，但資料容易被鎖在某個帳號、某個雲服務或某種私有格式裡。Joplin 的思路更偏開放：本地保留完整資料，筆記正文使用 Markdown，再透過使用者選擇的同步目標在多裝置之間同步。

它適合下面幾類需求：

想把筆記長期保存為 Markdown。
想在電腦和手機之間同步筆記。
想從 Evernote 匯入舊筆記和附件。
想使用端到端加密同步。
想用外掛和主題擴展筆記應用。
想把網頁內容快速剪藏到自己的筆記庫。

核心特性速查

特性	說明
開源	倉庫公開，專案長期維護，授權為 AGPL-3.0 license
跨平台	支援 Windows、macOS、Linux、Android、iOS
Markdown	筆記正文使用 Markdown，便於閱讀、遷移和長期保存
離線優先	本地始終保存資料，沒有網路也能查看和編輯
同步	支援多種同步目標，包括 Joplin Cloud、Nextcloud、Dropbox、OneDrive 等
端到端加密	同步時可以啟用 E2EE，降低雲端儲存風險
匯入	支援從 Evernote 匯入，也支援普通 Markdown 檔案匯入
擴展	支援外掛、主題和 Web Clipper

離線優先是什麼意思

Joplin 官方 README 中強調它是 “offline first”。這意味著筆記不是只存在於雲端，而是保存在本機或手機中。即使沒有網路，也能打開、搜尋和編輯已有筆記。

這個設計對筆記工具很重要。網路不好、同步服務臨時不可用，或者帳號服務出現問題時，本地仍然有完整資料。同步只是讓多裝置保持一致，而不是把所有使用體驗都綁定到雲端。

Markdown 與匯入能力

Joplin 的筆記使用 Markdown，這讓它比完全私有格式更容易遷移和備份。使用者可以直接匯入普通 Markdown 檔案，也可以從 Evernote 匯入筆記。

Evernote 匯入時，Joplin 會嘗試轉換格式化內容，並保留資源檔案，例如圖片和附件，同時保留建立時間、更新時間、地理位置等中繼資料。對有多年 Evernote 資料的人來說，這一點比單純複製文字更重要。

不過，任何跨應用遷移都不應該盲信「一鍵完成」。複雜排版、表格、附件、內部連結和標籤結構都建議先用少量樣本測試，再遷移完整資料庫。

同步與加密

Joplin 支援多種同步方式。常見選擇包括：

同步目標	適合場景
Joplin Cloud	想省心使用官方服務
Nextcloud	已經有自建雲或團隊協作環境
Dropbox	習慣使用 Dropbox 的個人使用者
OneDrive	使用 Microsoft 生態的使用者
檔案系統 / WebDAV 等	想自己控制同步位置的人

同步可以配合端到端加密使用。啟用後，筆記內容在同步到雲端前會先加密，雲服務更多只是保存加密後的資料。這樣可以降低第三方雲碟或同步服務洩露內容的風險。

加密也會帶來管理成本。使用者需要妥善保存密碼和恢復資訊，否則換裝置或重裝後可能無法解密舊筆記。

Web Clipper 與外掛

Joplin 還提供瀏覽器 Web Clipper，用來從 Chrome、Firefox 等瀏覽器保存網頁和截圖。對做資料收集、網頁剪藏和研究筆記的人來說，這是很實用的入口。

外掛和主題則讓 Joplin 更接近一個可擴展平台，而不是固定功能的筆記軟體。使用者可以根據自己的工作流程擴展編輯、展示、搜尋、匯入匯出等能力。

和 Obsidian 的區別

Joplin 和 Obsidian 都常被 Markdown 使用者拿來比較，但兩者側重點不同。

維度	Joplin	Obsidian
主要定位	開源筆記與待辦應用，內建同步方案和加密能力	本地 Markdown 知識庫，強調雙鏈、外掛生態和圖譜
資料組織	應用管理筆記本、標籤、附件和資料庫索引	直接圍繞資料夾和 Markdown 檔案工作
同步	內建多種同步目標和 E2EE	官方同步是付費服務，也可自行使用第三方同步
適合人群	想要開箱即用、跨端同步、兼顧隱私的人	想深度定制個人知識庫和本地檔案工作流程的人

如果你想要一個「開源版 Evernote + Markdown + 同步加密」，Joplin 更貼近這個需求。如果你想圍繞本地 Markdown 檔案搭建高度定制的知識系統，Obsidian 可能更順手。

適合誰使用

Joplin 適合幾類使用者：

想從 Evernote 遷移出來的人。
想把筆記保存為 Markdown 的使用者。
需要 Windows、macOS、Linux、Android、iOS 多端同步的人。
關心隱私，希望啟用端到端加密的人。
希望筆記軟體開源、可自託管、可長期遷移的人。
需要網頁剪藏和附件管理的人。

它不一定適合只想要極簡便箋的人。Joplin 功能較完整，配置同步、加密、外掛和匯入時，也需要花一點時間理解。

使用建議

如果你準備試用 Joplin，可以按這個順序開始：

先在桌面端建立一個測試筆記本。
匯入少量 Markdown 或 Evernote 樣本。
檢查圖片、附件、標籤、建立時間和格式是否正常。
再設定同步目標，例如 Joplin Cloud、Nextcloud、Dropbox 或 OneDrive。
如果要開啟端到端加密，先確認所有裝置都能正常同步和解密。
最後再遷移完整筆記庫。

這樣做比直接把多年筆記一次性匯入更穩，也方便在正式遷移前發現格式或同步問題。

我的判斷

Joplin 的優勢在於把幾個重要方向放在了一起：Markdown、開源、跨平台、離線優先、同步和端到端加密。它不只是一個寫 Markdown 的編輯器，更像一個面向長期使用的個人筆記系統。

如果你希望筆記資料盡量開放，又不想完全自己拼同步、加密和移動端應用，Joplin 是很值得試的選擇。它尤其適合從 Evernote 遷移、重視隱私、多裝置使用，並希望以後仍能把資料遷走的使用者。

專案連結：laurent22/joplin
官方文件：Joplin documentation

Jimmy：把 Evernote、Notion、Google Keep 等筆記匯出轉換成 Markdown

Sat, 30 May 2026 11:55:56 +0800

Jimmy 是一個筆記轉換工具，目標是把不同筆記應用或文件格式裡的內容轉換成 Markdown。它適合想把筆記從封閉應用裡遷出來、放進 Obsidian、Joplin，或者只想長期保存為純文字的人。

專案文件裡的定位很直接：匯出或備份原筆記應用的資料，運行 jimmy 轉換，再把結果匯入 Joplin、Obsidian，或者直接用 VSCode 等文字編輯器查看。

Jimmy 解決什麼問題

很多筆記應用都有自己的匯出格式。換應用時，最麻煩的往往不是文字內容，而是圖片、附件、標籤、內部連結和 front matter 這些結構化資訊。

Jimmy 做的事情就是把這些匯出資料盡量整理成更通用的 Markdown 目錄：

筆記正文轉換為 Markdown。
盡量保留圖片、資源和附件。
盡量保留標籤、外部連結和筆記內部連結。
輸出 Markdown + front matter。
結果可以匯入 Joplin、Obsidian 等工具，也可以直接用文字編輯器查看。

這類工具的意義在於降低遷移成本。筆記一旦變成 Markdown，就不再強綁定某個應用，後續備份、搜尋、版本管理和 LLM 處理都會簡單很多。

支援的筆記應用很多

Jimmy 支援的來源覆蓋面很廣，包括 Anki、Anytype、Bear、CherryTree、ColorNote、Day One、Diaro、Drafts、Dynalist、Evernote、Google Docs、Google Keep、Joplin、Notion、Obsidian、OneNote、QOwnNotes、RedNotebook、Reflect、Roam Research、Signal、Simplenote、Standard Notes、Synology Note Station、Telegram、Tiddlywiki、Turtl、UpNote、Wordpress、Zim、Zoho Notebook 等。

並不是所有來源的保真度都完全一樣。實際遷移時，仍然要先用一小批筆記試跑，重點檢查圖片、附件、標籤、內部連結和日期欄位是否符合預期。

也能轉換普通文件

除了筆記應用匯出，Jimmy 也能處理一些常見文件格式。文件中提到可以轉換單一檔案，也可以遞迴轉換整個資料夾，適合把雜亂的資料目錄整理成 Markdown。

常見支援格式包括：

類型	例子
辦公文件	DOCX、ODT、RTF
標記語言	Asciidoc、DocBook、Markdown、MediaWiki、reStructuredText
網頁與電子書	HTML、MHTML、EPUB
資料與結構化檔案	CSV、OPML、Jupyter Notebook
其他	PDF、EML、Fountain、txt2tags

如果只是把 DOCX、PDF 或 HTML 批量轉成 Markdown，Jimmy 也可以作為一個離線批次處理工具來用。

兩種使用方式

Jimmy 提供 CLI 和 TUI 兩種介面。

介面	適合場景	說明
CLI	批次處理、腳本、完整功能	適合一次性轉換資料夾、寫遷移腳本、指定來源格式
TUI	互動式轉換	適合手動操作，目前功能子集仍處於 beta 狀態

官方 README 給出的 Linux 示例命令如下：

# 使用互動式 TUI 轉換
jimmy-linux tui

# 轉換一個 pandoc 支援的單檔案
jimmy-linux cli libre_office_document.odt

# 轉換整個資料夾
jimmy-linux cli path/to/folder

# 轉換 Google Keep 匯出
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

這些命令說明它不是只面向某一個筆記應用，而是把「筆記匯出包」和「普通文件目錄」都納入了同一套轉換流程。

它的幾個特點

特點	說明
離線運行	轉換過程不依賴雲服務，適合處理私人筆記
開源	倉庫採用 GPL-3.0 license
跨平台	官方提供 Linux、Windows、macOS 下載
獨立二進位檔	不要求使用者額外安裝 Docker、Python 或 Node.js
不使用 AI	轉換過程不調用 AI，結果更可控，也減少隱私顧慮
Markdown + front matter	方便匯入筆記軟體，也方便後續用 Git 管理

其中「離線」和「不使用 AI」很適合筆記遷移場景。筆記裡經常有私人資訊、工作資料和歷史附件，把轉換放在本地完成，會讓風險邊界更清楚。

適合誰使用

Jimmy 適合幾類人：

想從 Evernote、Notion、OneNote、Google Keep 等工具遷移到 Markdown 的使用者。
想把筆記匯入 Obsidian、Joplin 或其他純文字工作流的人。
想把長期資料保存為未來更容易讀取格式的人。
想把筆記或文件準備成 LLM 可處理文字的人。
需要遞迴轉換 DOCX、PDF、HTML、ODT 等資料夾內容的人。

它不一定適合追求「一鍵完美遷移」的使用者。不同筆記應用匯出格式差異很大，複雜頁面、資料庫、嵌入內容和內部連結都可能需要人工複查。

使用前的檢查建議

真正遷移前，建議按這個順序做：

先從原筆記應用匯出一小批樣本。
用 Jimmy 轉換樣本，而不是一上來轉換全部筆記。
檢查 Markdown 正文、圖片、附件、標籤、建立時間、內部連結。
確認目標應用，例如 Obsidian 或 Joplin，能正確識別目錄結構和 front matter。
再對完整匯出包執行轉換。
保留原始匯出包和轉換結果，至少等確認無誤後再清理。

這個流程雖然慢一點，但能避免遷移後才發現附件遺失、連結斷掉或標籤結構不對。

我的判斷

Jimmy 的價值在於把筆記遷移從「依賴某個應用的匯入器」變成「先轉成通用 Markdown」。它支援的來源很多，輸出也足夠通用，適合把個人知識庫從封閉格式裡釋放出來。

如果你只是偶爾匯出一兩篇筆記，可能用不到它。但如果你有多年積累的筆記、附件和文件目錄，想遷移到 Obsidian、Joplin 或 Git 管理的 Markdown 工作流，Jimmy 很值得試。它最適合做遷移中間層：先把資料變成可讀、可備份、可批次處理的文字，再決定放進哪個筆記系統。

專案連結：marph91/jimmy
文件連結：Jimmy - Note Conversion Tool

AI 自動用手機哪家強？MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use 對比

Fri, 29 May 2026 21:47:24 +0800

最近連續整理了四個行動端 GUI 智能體專案：MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use。它們都和「讓 AI 操作手機或行動 App」有關，但定位並不一樣。

簡單說：MobiAgent 更像可客製化的手機智能體研究系統；Mobile-Agent 是通義實驗室圍繞 GUI agent 的系列工作集合；Mobilerun 更偏向可落地的本地/雲端行動裝置控制框架；mobile-use 則強調真實 App 操作、任務拆解、資料抽取和 AndroidWorld 評測。

基本資訊對比

專案	站內文章	GitHub	主要定位	裝置/平台	開源協議	更適合誰
MobiAgent	站內介紹	IPADS-SAI/MobiAgent	可客製化手機 GUI 智能體系統，包含模型、runner、記憶、加速和評測	主要面向 Android/Harmony 手機	Apache-2.0	研究者、行動智能體實驗團隊
Mobile-Agent	站內介紹	X-PLUG/MobileAgent	通義實驗室 GUI 智能體家族，覆蓋行動端、桌面、瀏覽器和工具調用	手機、PC、網頁、雲手機/雲桌面	MIT	關注 GUI agent 技術路線的人
Mobilerun	站內介紹	droidrun/mobilerun	LLM 無關的行動裝置 agent 框架，支援 CLI、Python API 和雲端裝置工作流	Android、iOS、本地裝置、雲端裝置	MIT	開發者、QA、自動化工作流團隊
mobile-use	站內介紹	minitap-ai/mobile-use	用自然語言操作真實行動 App，強調任務拆解、結構化抽取和 AndroidWorld	Android 實機/模擬器、iOS 模擬器	Apache-2.0	做行動 App agent、資料抽取和評測的人

MobiAgent

MobiAgent 來自 IPADS-SAI，定位是一個可客製化的手機智能體系統。它不是只提供一個執行腳本，而是把 MobiMind 模型家族、AgentRR 動作記錄與回放、MobiFlow 評測基準、手機 runner、資料採集和 Android app 放到同一套體系裡。

它的特點是研究系統比較完整。MobiAgent 關注真實手機任務中的準確率、效率、記憶和可複用動作序列。README 中提到的使用者畫像記憶、經驗記憶、動作記憶，以及多任務執行，都說明它在嘗試處理長期任務和重複任務。

它的門檻也相對高。完整運行需要裝置、ADB、模型部署、依賴環境、可選的向量資料庫和圖資料庫配置。更適合研究或工程實驗，不太像面向普通使用者的「安裝即用」手機助手。

Mobile-Agent

Mobile-Agent 來自 X-PLUG/通義實驗室。這個倉庫已經從早期手機操作智能體，擴展成一個 GUI 智能體家族：Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl、ToolCUA 等都在同一條技術線上。

它的特點是跨度大。Mobile-Agent 不只關心手機，還覆蓋桌面、瀏覽器、雲手機、雲桌面、GUI 感知、grounding、錯誤診斷、強化學習和 GUI/工具路徑編排。GUI-Owl 系列模型讓它更像一個跨平台 GUI agent 基礎模型路線，而不是單一行動自動化專案。

它的不足也來自這個跨度：倉庫更像研究成果集合，使用者需要先判斷自己要跑哪個子專案、哪個模型和哪個場景。它適合跟蹤技術演進和復現實驗，不一定是最快接入業務流程的選擇。

Mobilerun

Mobilerun 來自 droidrun，定位更工程化：讓 LLM agent 透過自然語言控制 Android 和 iOS 裝置。它提供 CLI、TUI、Docker、Python API、Portal-based control、vision mode、reasoning mode、結構化輸出、自訂工具、app cards、執行軌跡和雲端裝置服務。

它最突出的地方是模型無關和部署形態清楚。開發者可以接 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 或 OpenAI-compatible providers；也可以選擇本地框架或 Mobilerun Cloud。對真實團隊來說，這種「裝置控制層和模型層解耦」的設計很重要。

它也有行動端自動化常見的門檻：Android 需要開發者選項、USB 偵錯和 Portal app；iOS 需要單獨流程；複雜任務還要處理權限彈窗、頁面變化、失敗重試和日誌排查。它更適合願意把 mobile agent 當成工程元件接入的人。

mobile-use

mobile-use 來自 minitap-ai，目標是讓 AI agent 使用真實 Android 和 iOS App。它支援自然語言控制、UI-aware automation、資料抽取、不同 LLM 配置，並強調 AndroidWorld 基準表現。README 中還提到專案是首個在 AndroidWorld benchmark 上達到 100% 的 agentic framework。

它的亮點是任務拆解和結構化抽取。比如從 Gmail 中找未讀郵件，並按指定 JSON 格式返回寄件者和主題，這類任務比「打開設定看看電量」更接近真實生產需求。它把行動 GUI agent 從「會操作」推進到「能把 App 裡的資訊整理出來」。

它的限制主要在裝置支援和運行環境。Android 可以用實體手機或模擬器；iOS 目前主要支援 macOS 上的模擬器，物理 iOS 裝置還不支援。Docker 快速啟動也主要面向 Android。評估它時，要先確認目標裝置和 App 場景能否被當前執行通道覆蓋。

功能對比

功能維度	MobiAgent	Mobile-Agent	Mobilerun	mobile-use
自然語言任務	支援	支援	支援	支援
真實手機操作	強，偏 Android/Harmony	強，含行動端與雲手機	強，Android/iOS	強，Android；iOS 偏模擬器
桌面/瀏覽器擴展	不是重點	強，含 PC-Agent、GUI-Owl、ToolCUA	不是主要定位	不是主要定位
模型層	自帶 MobiMind 系列	GUI-Owl、Mobile-Agent 系列	LLM 無關，接多家模型	可配置多種 LLM
執行器/runner	強，含 ADB runner、多任務 runner	子專案各自提供	強，CLI/TUI/Python API/Docker	有原始碼、Docker 和平台入口
記憶能力	使用者畫像、經驗、動作記憶	v3/v3.5 路線中強調記憶與反思	更偏軌跡、日誌和工程偵錯	更偏任務拆解與狀態執行
評測	MobiFlow	多個論文/基準方向	有 benchmark 結果入口	AndroidWorld 表現突出
雲端裝置	不是主要賣點	支援雲手機/雲桌面體驗	Mobilerun Cloud 是重點	有平台入口
結構化輸出	可透過工程流程實現	視子專案而定	明確支援	明確支援

優缺點對比

MobiAgent 的優點是系統完整，適合研究手機 GUI agent 的模型、記憶、加速和評測閉環；缺點是部署鏈路長，工程配置重，普通開發者上手成本較高。

Mobile-Agent 的優點是技術路線最寬，能看到 GUI agent 從手機走向桌面、瀏覽器、工具調用和基礎模型的演進；缺點是專案族複雜，想直接落地某個具體場景時，需要先做較多篩選。

Mobilerun 的優點是工程介面清晰，模型無關，本地框架和雲服務分層明確，適合把行動裝置自動化接入產品或內部工具；缺點是仍然要面對行動裝置權限、環境、App 狀態和雲端成本問題。

mobile-use 的優點是聚焦真實 App 使用、任務拆解和結構化資料抽取，AndroidWorld 方向也讓它更容易評估；缺點是 iOS 物理裝置支援有限，完整使用仍然需要配置模型、裝置和運行環境。

適用範圍建議

如果你要做行動智能體研究，優先看 MobiAgent 和 Mobile-Agent。前者更聚焦手機端系統閉環，後者更適合觀察 GUI agent 的跨平台演進。

如果你要做行動 App 自動化、QA、資料抽取或內部工作流，優先看 Mobilerun 和 mobile-use。Mobilerun 更像可接入工程系統的運行框架，mobile-use 更適合驗證自然語言 App 操作和結構化抽取。

如果你關注未來個人助手形態，四個都值得跟蹤。MobiAgent 代表手機 agent 的系統化研究，Mobile-Agent 代表跨平台 GUI agent 路線，Mobilerun 代表裝置控制基礎設施，mobile-use 代表真實 App 任務拆解和評測驅動路線。

我的判斷

這四個專案的差異說明，行動端 GUI agent 已經不只是「讓模型看截圖點按鈕」。真正的問題變成了：模型如何理解介面，執行器如何穩定控制裝置，任務如何拆解和評估，雲端裝置如何管理，結果如何結構化返回，風險如何被限制。

短期內，最現實的落地場景會是 QA、資料抽取、內部流程自動化和受控裝置池。長期看，誰能把裝置控制、模型能力、權限邊界、日誌追蹤和使用者確認機制做穩，誰就更接近真正可用的行動端 AI 助手。

mobile-use 看點：讓 AI 操作真實 App，還能提取資料

Fri, 29 May 2026 21:43:46 +0800

mobile-use 是 minitap-ai 開源的行動端 AI agent 框架，目標是讓智能體像人一樣使用真實 Android 和 iOS App。使用者用自然語言描述任務，框架負責理解介面、操作 App，並把結果返回給調用方。

從 README 看，mobile-use 的重點不只是「能點手機」，還強調 UI-aware automation、資料抽取、可配置模型，以及在 AndroidWorld 基準上的表現。專案還提供雲平台、文件和論文入口，說明它既是開源框架，也是一個圍繞行動端智能體搭建的產品與研究體系。

它和普通手機自動化有什麼不同

傳統手機自動化通常依賴腳本、座標、控制項 ID 或固定流程。它適合穩定頁面，但遇到介面變化、彈窗、搜尋結果、列表滾動和跨 App 操作時，很容易失效。

mobile-use 的路線是讓 AI agent 直接處理自然語言目標和 UI 狀態：

使用者用自然語言描述任務，不必預先寫死每一步。
框架讀取行動端介面，並結合模型判斷下一步操作。
可以從 App 中抽取資訊，並按指定格式返回，比如 JSON。
支援不同 LLM 配置，包括 OpenAI API compatible providers。
Android 可以透過實體手機或模擬器運行，iOS 目前主要面向 macOS 上的模擬器。

這類框架更適合「半結構化」的行動任務：目標明確，但每次頁面狀態、資料內容和路徑不完全一樣。

AndroidWorld 結果值得注意

mobile-use README 中提到，專案在 AndroidWorld benchmark 上達到 100% 完成表現，並連結了對應論文。無論具體評測細節如何，這都說明專案團隊把「任務拆解」和「可評測執行」放在了很高的位置。

這點比單純展示更關鍵。GUI agent 最容易出現的問題是：一個影片裡看起來很聰明，但換一個任務、裝置或初始狀態就不穩定。基準測試不能完全代表真實使用，卻能逼迫系統面對一組標準化任務，並暴露規劃、定位、恢復和狀態理解能力。

README 中的論文題目也點出了方向：透過任務拆解提升 AndroidWorld 準確率。對行動端智能體來說，複雜任務往往不能靠一個大提示詞直接完成，而需要拆成可執行子任務，並在每一步檢查狀態。

資料抽取是實用入口

mobile-use 的一個現實場景是從原生 App 中抽取資料。很多資訊並不暴露在 API 中，只能在 App 介面裡查看，比如郵件列表、訂單狀態、社交內容、營運後台、訊息通知等。

README 給出的示例是打開 Gmail，找到未讀郵件，並把寄件者和主題整理成 JSON。這個方向很實用，因為它把行動 GUI agent 從「幫我操作一下」推進到「幫我把 App 裡的資訊結構化拿出來」。

不過，這也帶來邊界問題。資料抽取涉及帳號、隱私、平台條款和訪問權限。真正使用時，應該明確裝置歸屬、任務授權、資料保存方式和輸出範圍，不能把手機介面當成無限制的資料源。

部署門檻和限制

mobile-use 支援從平台快速開始，也支援從原始碼運行。原始碼方式需要配置 .env、LLM 配置和依賴環境；Android 側可以使用實體手機或模擬器，Docker 快速啟動目前主要面向 Android；iOS 側需要 macOS、Xcode 和 Facebook 的 iOS Development Bridge，README 也說明物理 iOS 裝置暫不支援。

這些限制並不意外。行動端自動化比瀏覽器自動化更依賴裝置、系統權限和偵錯通道。尤其是 iOS，系統封閉性更強，能穩定接入模擬器已經有價值，但離「任意真實 iPhone 自動化」還有距離。

因此，評估 mobile-use 時不要只看模型效果，還要看自己的目標裝置、App 類型、運行環境和合規邊界是否匹配。

適合誰關注

mobile-use 適合幾類人關注：

想研究 AndroidWorld、行動 GUI agent 和任務拆解方法的研究者。
想把自然語言行動操作接入內部工具的開發者。
需要從原生 App 抽取結構化資料的團隊。
做行動 App QA、回歸測試或探索式測試的人。
想比較 mobile-use、Mobilerun、Mobile-Agent 等不同行動端智能體路線的人。

如果目標是一個面向普通使用者的手機助手，它目前還偏工程和研究框架；如果目標是驗證行動端 agent 的可行性，它提供了一個很好的開源起點。

我的判斷

mobile-use 的亮點在於把真實 App 操作、結構化資料抽取和基準評測放在同一個專案裡。它不是只做「自然語言點手機」的包裝，而是在嘗試把行動端任務拆解成可執行、可評估、可復現的智能體流程。

行動端會是 GUI agent 的重要戰場，因為大量個人和業務任務發生在 App 裡，而不是網頁或 API 裡。mobile-use 這類專案的意義，就是讓智能體從聊天窗口走進真實應用介面。它還沒有把裝置、權限和風險問題全部抹平，但已經給開發者提供了一個足夠具體的實驗平台。

專案連結：minitap-ai/mobile-use

想讓 AI 自動點手機？Mobilerun 支援 Android 和 iOS

Fri, 29 May 2026 21:43:45 +0800

Mobilerun 是 droidrun 開源的行動裝置自動化框架，目標是讓 LLM agent 可以用自然語言控制 Android 和 iOS 裝置。它提供行動端原生工具，讓智能體能夠檢查 UI 狀態、理解截圖、點擊、滑動、輸入、規劃多步任務，並透過 CLI 或 Python API 返回結果。

這個專案的定位很清楚：它不綁定某一家模型，而是做行動裝置與智能體之間的執行層。README 中列出的模型來源包括 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 以及 OpenAI-compatible providers。對開發者來說，這比「只支援一個模型的展示專案」更實用。

它解決什麼問題

行動端自動化最麻煩的地方，是自然語言任務和真實裝置操作之間隔著很多層。模型需要知道目前打開了什麼 App、頁面有哪些控制項、是否需要截圖補充視覺資訊、下一步該點哪裡，以及執行失敗後如何繼續。

Mobilerun 把這些能力整理成一套框架：

透過 CLI 和 TUI 運行一次性自然語言任務、檢查裝置、回放巨集和偵錯流程。
透過 Python API 建構自訂行動自動化工作流。
支援 Android 和 iOS，Android 透過 Portal app 和無障礙能力控制裝置，iOS 走單獨的 Portal 流程。
同時使用 accessibility tree 和截圖，讓模型既能讀結構化 UI，也能看視覺畫面。
支援 --vision、--vision-only 和 --reasoning 等模式，應對不同複雜度的任務。
支援結構化輸出、app cards、自訂工具、憑據和執行軌跡追蹤。

這讓 Mobilerun 更像一個「行動端 agent runtime」，而不是單純把截圖發給大模型再模擬點擊。

本地框架和雲端服務

Mobilerun 把本地框架和 Mobilerun Cloud 分得比較清楚。本地框架適合開發者在自己的機器和裝置上運行 agent，拿到更強的程式碼級控制；Cloud 則面向託管裝置、REST API、SDK 和規模化工作流。

這個分層很重要。很多行動自動化場景開始時只是「幫我在手機上跑一個任務」，但一旦進入團隊使用，就會遇到裝置管理、並發、日誌、失敗重試、權限和 API 調用的問題。Cloud 不是替代本地框架，而是把裝置運維和工作流接入往後端服務方向推進。

README 中還區分了幾類雲端裝置：使用者自己的硬體、託管雲手機、託管實體手機。這裡的差別不只是成本，也涉及應用風控、身份可信度和任務穩定性。對電商、社交、金融或本地生活類 App 來說，真實裝置和虛擬裝置的表現可能完全不同。

為什麼 LLM 無關很關鍵

行動 GUI agent 還處在快速變化階段，很難說哪一家模型長期最好。不同任務對模型的要求也不一樣：有的更依賴視覺理解，有的更依賴長鏈路規劃，有的更看重工具調用，有的則需要低成本批量執行。

Mobilerun 選擇模型無關的框架路線，價值在於把裝置控制、任務執行、日誌追蹤和模型選擇拆開。開發者可以先穩定裝置側流程，再根據任務成本、準確率和延遲切換模型。

這對實際落地很有幫助。企業不會只因為一個模型展示效果好就重寫裝置控制層；更合理的方式是保留統一執行框架，把模型當成可替換元件。

適合哪些場景

Mobilerun 當前適合幾類需求：

行動 App QA 和回歸測試。
從原生 App 中抽取資料並返回結構化結果。
自動執行重複性的手機任務。
為非技術使用者封裝自然語言行動操作流程。
在多台裝置上運行自動化任務。
把日程、通知或自訂觸發器接入行動端工作流。

不過，它也不是「安裝後立刻替你管手機」的消費級助手。Android 側需要 ADB、開發者選項、USB 偵錯和 Portal app；iOS 側也有自己的接入流程。真正跑穩定，還要處理模型配置、裝置狀態、權限彈窗和任務失敗恢復。

我的判斷

Mobilerun 的價值在於把行動裝置控制做成了可程式化、可觀測、可替換模型的 agent 框架。它承認行動自動化不是一個模型問題，而是模型、裝置、執行器、日誌、工具和雲端基礎設施共同組成的系統問題。

短期看，它適合開發者搭建行動端自動化原型和內部工具；長期看，這類框架可能會成為「手機上的 AI 工作流引擎」。如果 GUI agent 要進入真實業務，像 Mobilerun 這樣把本地運行、雲端裝置、結構化輸出和追蹤能力放在一起的專案會越來越重要。

專案連結：droidrun/mobilerun

AI 能自己點手機、用電腦了嗎？Mobile-Agent 專案解讀

Fri, 29 May 2026 21:42:41 +0800

X-PLUG 開源的 Mobile-Agent 已經不只是一個手機自動化專案。按照倉庫當前的定位，它更像是通義實驗室圍繞 GUI 智能體持續沉澱的一組工作：Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl 以及 ToolCUA 等，都被放在同一個專案體系裡展示。

這條線索值得關注。過去談 GUI agent，常見問題是「模型能不能看懂截圖並點對位置」；而 Mobile-Agent 的演進方向更進一步：讓智能體在行動端、桌面、瀏覽器和工具調用之間切換，處理更長鏈路、更複雜的真實任務。

它解決什麼問題

GUI 智能體面對的不是標準 API，而是應用介面。它需要看懂螢幕、定位控制項、規劃步驟、執行點擊或輸入，並在失敗時修正路徑。行動端場景尤其複雜，因為任務往往跨多個 App，介面狀態也會隨著登入、權限、彈窗、網路和個性化推薦變化。

Mobile-Agent 系列把這個問題拆成了幾個方向：

用 Mobile-Agent-v1/v2 探索手機 GUI 的視覺感知與多智能體協作。
用 PC-Agent 把多智能體操作擴展到 PC 場景。
用 Mobile-Agent-v3 和 v3.5 推進多平台 GUI 智能體框架。
用 GUI-Owl 系列模型提供跨平台 GUI 感知、定位和端到端操作能力。
用 GUI-Critic-R1、UI-S1、ToolCUA 等工作補足錯誤診斷、強化學習和 GUI/工具路徑編排。

這讓它不像一個單點 demo，而更像一條圍繞「電腦使用智能體」的研究和工程路線。

v3.5 的重點

倉庫 README 顯示，Mobile-Agent-v3.5 已經可以透過 ModelScope 線上 Demo 和阿里雲百煉線上 Demo 體驗，百煉上也提供了 v3.5 API。2026 年 3 月，v3.5 還上線了阿里雲無影雲手機，面向雲端 Android 環境提供行動使用體驗。

這說明專案正在把「本地跑實驗」之外的使用方式也補上。對於 GUI 智能體來說，雲手機和雲桌面很重要：它們能提供更穩定、更可復現的運行環境，減少本地裝置、系統版本、解析度和 App 狀態帶來的差異。

如果你想評估這類智能體，穩定環境往往比模型本身更容易被低估。沒有可控的執行環境，就很難判斷一次失敗是模型能力不足、介面變化、裝置問題，還是任務定義不清。

GUI-Owl 是底層變化

Mobile-Agent-v3 之後，GUI-Owl 成了這條路線裡的關鍵模型層。README 中把 GUI-Owl 描述為具備 GUI 感知、grounding 和端到端操作能力的多模態跨平台 GUI VLM。到 GUI-Owl-1.5，模型系列已經覆蓋 2B、4B、8B、32B、235B，並支援桌面、行動端和瀏覽器自動化。

這類模型的意義在於，它不只是回答「螢幕裡有什麼」，還要把自然語言目標、截圖內容、介面元素位置和下一步操作連起來。對 GUI agent 來說，視覺理解、座標定位、操作規劃和狀態記憶缺一不可。

當然，模型越通用，工程邊界也越重要。真實部署時仍然需要執行器、權限控制、任務日誌、回滾機制和人工確認。尤其是涉及支付、帳號、檔案、訊息發送等高風險操作時，GUI agent 不能只追求自動完成，還要能清楚說明自己準備做什麼。

ToolCUA 暗示的新方向

2026 年 5 月，專案新聞裡提到 ToolCUA，定位是面向 GUI 與工具最優路徑編排的端到端 Computer Use Agent。這個方向很有意思，因為它承認了一個現實：不是所有任務都應該靠點螢幕完成。

有些事情適合 GUI 操作，比如登入後台、處理複雜表單、讀取沒有 API 的應用狀態；有些事情更適合調用工具，比如檢索、計算、解析檔案、訪問結構化介面。真正可用的電腦使用智能體，需要學會在兩者之間切換。

這也是 Mobile-Agent 系列比早期手機自動化專案更值得看的地方。它不再只問「智能體能不能像人一樣點 App」，而是在問「智能體什麼時候該看螢幕，什麼時候該用工具，什麼時候該停下來確認」。

適合誰關注

如果你只是想找一個開箱即用的手機自動化助手，Mobile-Agent 仍然偏研究和工程框架。它涉及模型、運行環境、評測任務和具體執行器，完整跑通通常需要一定配置成本。

但如果你關注下面幾類問題，它很值得跟蹤：

行動端 GUI agent 如何從展示走向穩定執行。
桌面、瀏覽器和手機自動化能否統一到同一套智能體框架裡。
GUI 模型如何處理 grounding、反思、記憶和錯誤診斷。
智能體如何在 GUI 操作與工具調用之間選擇路徑。
雲手機、雲桌面是否會成為 GUI agent 的重要運行環境。

這些問題會直接影響個人助理、企業流程自動化、遠端桌面操作、應用測試和無 API 系統整合。

我的判斷

Mobile-Agent 的價值不在於某一個版本的指標，而在於它把 GUI 智能體從「手機截圖點按」推進到了一個更大的系統問題：模型、執行環境、評測、工具調用、錯誤診斷和跨平台任務如何協同。

短期看，它更適合研究者和開發者觀察 GUI agent 的技術路線；長期看，這類專案可能會影響個人 AI 助手和企業自動化工具的形態。真正的難點不只是讓智能體會操作介面，而是讓它在真實應用裡穩定、可控、可追蹤地完成任務。

專案連結：X-PLUG/MobileAgent

MobiAgent 是什麼？一個能操作手機 App 的開源 AI 智能體

Fri, 29 May 2026 21:36:58 +0800

IPADS-SAI 開源了 MobiAgent，定位是一個面向手機 GUI 的可客製化智能體框架。它不是單一模型倉庫，而是把模型、執行器、加速機制、評測基準和行動端應用放在同一個體系裡，目標是讓智能體能在真實手機環境中完成跨應用、多步驟任務。

從專案結構看，MobiAgent 主要由三部分組成：MobiMind 系列智能體模型、AgentRR 記錄與回放加速框架，以及 MobiFlow 評測基準。論文摘要也強調，現有行動智能體在真實任務裡的準確率和效率仍然是主要瓶頸，MobiAgent 的設計就是圍繞這兩個問題展開。

它解決什麼問題

手機 GUI 智能體比網頁或桌面自動化更麻煩。它需要理解截圖、識別控制項、決定下一步操作，還要透過 ADB 或行動端運行環境執行點擊、輸入、返回、切換應用等動作。真實任務往往不是單 App 內的一次操作，而是跨越搜尋、購物、社交、支付、地圖等多個應用的連續流程。

MobiAgent 的價值在於把這些環節系統化：

用 MobiMind 承擔任務規劃、決策和介面定位等能力。
用 runner 連接手機，透過 ADB 執行預定義任務並記錄軌跡。
用 AgentRR 複用成功動作序列，降低重複任務的推理與操作成本。
用 MobiFlow 評測真實行動場景中的任務完成情況。
透過資料採集、標註和處理工具，降低行動 GUI 任務資料建構成本。

這讓它更像一個行動智能體實驗平台，而不是只能跑展示的模型專案。

記憶系統是關鍵補丁

MobiAgent 支援使用者畫像記憶、經驗記憶和動作記憶。使用者畫像記憶用於給規劃提供偏好上下文；經驗記憶用於檢索類似任務的執行經驗；動作記憶則透過 AgentRR 快取和複用成功動作序列。

這很重要，因為手機任務天然帶有重複性。比如使用者常用某個 App 搜尋商品、打開固定聯絡人、在特定頁面填寫資訊。如果每次都從零開始看圖、規劃和點擊，成本高且容易出錯。記憶模組可以把一部分「已經學會的流程」沉澱下來，讓後續任務更快、更穩定。

不過，記憶也會帶來新的治理問題。使用者偏好、歷史任務、應用路徑和操作軌跡都可能包含敏感資訊。真正落地時，專案需要明確哪些內容進入記憶、保存多久、如何刪除，以及是否允許模型在不同任務之間複用這些上下文。

適合誰關注

如果你只是想找一個現成的手機自動化 App，MobiAgent 目前仍更偏研究和工程框架。它需要配置模型服務、行動裝置、ADB、依賴環境和任務檔案，完整跑起來有一定門檻。

但如果你關注行動 GUI agent、端側智能體、多模型 runner、任務軌跡複用或智能體評測，MobiAgent 很值得跟蹤。它把模型、執行、評測和資料流水線放在一起，能幫助研究者和開發者更完整地觀察行動智能體的真實短板。

我的判斷

MobiAgent 的意義不在於又發布了一個 GUI agent，而在於它把手機智能體從「看截圖點按鈕」的單點能力，推進到一個可訓練、可執行、可評測、可加速的系統框架。

行動端是智能體很難繞開的場景。大量個人任務發生在 App 裡，而不是標準化網頁或 API 中。誰能穩定理解手機介面、跨應用執行任務、複用經驗並控制隱私風險，誰就更接近真正可用的個人智能體。

MobiAgent 還沒有把這些問題全部解決，但它提供了一個比較完整的開源起點。短期看，它適合用於行動智能體研究和實驗；長期看，這類框架可能會成為手機作業系統、個人助理和自動化工具之間的重要連接層。

專案連結：IPADS-SAI/MobiAgent
論文連結：MobiAgent: A Systematic Framework for Customizable Mobile Agents

GitHub AI 開源專案分類整理：從 Coding Agent 到 RAG 知識庫

Thu, 21 May 2026 08:53:13 +0800

這裡按應用方向列出 GitHub AI 專案，覆蓋 AI 程式設計與 Coding Agent、Agent 技能與工作流、RAG 與知識庫、多模態創作、本地模型與推理、垂直應用與自動化、AI 應用開發基礎設施等方向。後續新增專案時，也可以繼續按這個結構補充。

分類合計

分類	專案數	適合先看的人
AI程式設計與 Coding Agent	22	經常使用 Claude Code、Codex、Cursor、終端 Agent 或程式碼庫自動化的人
Agent 技能與工作流	7	想把 AI 程式設計、科研、創作流程標準化的人
RAG、知識庫與記憶	7	需要文件檢索、知識庫、長期記憶、網頁抓取和結構化抽取的人
垂直應用與自動化	7	想看金融、交易、閒魚監控、桌面操作、瀏覽器自動化等落地場景的人
多模態與內容創作	5	做圖片、影片、語音轉寫、提示詞庫和內容分發的人
AI 應用開發基礎設施	5	構建 AI 應用、瀏覽器自動化、Prompt/MCP 工具鏈的人
本地模型與推理	1	關心本地 DeepSeek、推理引擎和硬體適配的人

這個分佈可以看出當前 AI 開源專案的幾個高頻方向：AI 程式設計工具明顯最多，其次是 Agent 工作流、RAG 知識庫和具體應用場景。純模型推理專案數量不多，因為很多本地部署內容並不是單獨介紹某個 GitHub 專案，而是圍繞模型、顯示卡或部署方案展開。

AI程式設計與 Coding Agent

這一類聚焦程式碼理解、程式碼修改、工程流程和終端 Agent，是數量最多的一組。共 22 個專案。

專案	文章	GitHub	核心用途	適合人群
Ralph	Ralph 是什麼：把 Claude Code 和 Amp 變成可迴圈執行的自主開發流程	snarktank/ralph	讓 Claude Code / Amp 按 PRD、計劃、執行、評審迴圈推進任務	想把 Agent 程式設計流程拉直的人
Claude-Mem	Claude-Mem：給 Claude Code 加上跨會話長期記憶	thedotmack/claude-mem	為 Claude Code 增加跨會話記憶	高頻使用 Claude Code 的開發者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門	disler/claude-code-hooks-mastery	學習 Claude Code Hooks 生命週期和自動化控制	想定製 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 程式設計變成計劃、執行、評審的工程迴圈	EveryInc/compound-engineering-plugin	把 AI 程式設計拆成計劃、執行、評審迴圈	關注工程化 AI 程式設計的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	透過代理把 Claude Code 接到不同模型後端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比	NousResearch/hermes-agent	本地 Agent 框架，支援工具呼叫和任務執行	想跑本地 Agent 的使用者
OpenHarness	OpenHarness 是什麼：這個開源 Agent Harness 能做什麼	HKUDS/OpenHarness	Agent Harness 與多 Agent 執行框架	研究 Agent 編排的人
CodexBridge	Codex 怎麼接入國產大模型？OpenAI 相容介面與 CodexBridge 使用思路	begonia599/CodexBridge	幫 Codex 接入 OpenAI 相容模型介面	想把 Codex 接到國產模型的人
ccx	Codex 怎麼接入國產大模型？用 CCX 統一管理 OpenAI 相容 API	BenedictKing/ccx	統一管理 Claude、Codex、Gemini 等 API 代理	多模型切換使用者
cc-haha	cc-haha 是什麼？一個把 Claude Code 做成桌面工作臺的專案	NanmiCoder/cc-haha	Claude Code 桌面工作臺與 Computer Use 入口	喜歡圖形介面的 Claude Code 使用者
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 變成終端裡的程式設計智慧體	Hmbown/DeepSeek-TUI	在終端裡執行 DeepSeek 程式設計 Agent	DeepSeek 與命令列使用者
Open Design	Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具	nexu-io/open-design	讓 Claude Code / Codex 參與設計生成	想用 Agent 做設計原型的人
agentmemory	agentmemory 專案解析：給 Claude Code、Codex 和 Cursor 加持久記憶	rohitg00/agentmemory	給 Coding Agent 增加持久記憶層	長期維護專案的開發者
Graphify	Graphify 解決 Claude Code 最大侷限：把程式碼庫變成 AI 可查詢知識圖譜	safishamsi/graphify	把程式碼庫轉成知識圖譜，降低 Agent 重複讀檔案成本	大型程式碼庫使用者
oh-my-pi	oh-my-pi 是什麼？一個把終端、IDE 和偵錯器打通的 AI 編程助手	can1357/oh-my-pi	把終端、IDE、LSP 和偵錯器連接起來，作為本機 AI 編程控制台	想把命令列和 IDE 工作流打通的開發者
Claude Plugins Official	Claude Code 也有外掛市場了：能裝什麼、怎麼裝、要注意什麼	anthropics/claude-plugins-official	Claude Code 官方外掛目錄和安裝入口	想給 Claude Code 擴展能力的使用者
CodeGraph	CodeGraph 是什麼？給 Claude Code、Codex 和 Cursor 加一個本機程式碼地圖	colbymchenry/codegraph	為程式碼庫生成本機索引和關係圖，幫助 Coding Agent 理解專案	維護中大型程式碼庫的開發者
CC Switch	CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多個 AI CLI 工具和賬號/配置切換	同時使用多套 CLI 的人
Warp	Warp 開源：從終端到 Agentic Development Environment	warpdotdev/warp	Agentic 終端與開發環境	終端重度使用者
opencode	opencode、Claude Code、Codex 有什麼區別？開源 AI 程式設計工具使用指南	anomalyco/opencode	開源 AI 程式設計 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一個 AI 路由器	decolua/9router	AI 程式設計模型路由與 token 成本控制	多工具、多模型使用者
goose	goose：桌面端、CLI 和 API 一體的開源 AI Agent	aaif-goose/goose	桌面、CLI、API 一體的開源 Agent	想要通用 Agent 工作臺的人

Agent 技能與工作流

這一類更關注把 AI 能力固化成可重複的技能、流程和規格。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
mattpocock/skills	拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 程式設計補上工程約束	mattpocock/skills	用 Skills 約束 AI 程式設計流程	想給 Agent 加工程規範的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 與軟體開發方法論	想系統化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫	w512/Prompt-Vault	收集可測試 AI 程式設計能力的 prompt 規格	做模型/工具評測的人
web-video-presentation	web-video-presentation：把文章做成可錄屏網頁影片的 Agent Skill	ConardLi/garden-skills	把文章轉成可錄屏網頁影片的 Skill	內容創作者和自動化製作使用者
nuwa-skill	nuwa-skill：把“蒸餾一個人”從靈感變成可執行流程	alchaincyf/nuwa-skill	用 Skill 復刻人物表達和思維流程	做風格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交給 AI Agent 的技能庫	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、資料分析和技術寫作使用者
easy-vibe	easy-vibe：給 Vibe Coding 初學者的一張學習地圖	datawhalechina/easy-vibe	Vibe Coding 入門學習地圖	AI 程式設計新手

RAG、知識庫與記憶

這一類主要解決文件檢索、知識庫構建、長期記憶和結構化抽取問題。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
LangExtract	Google LangExtract：用 LLM 從長文字里抽取結構化資料	google/langextract	從長文字中抽取結構化資訊	做資訊抽取和資料處理的人
qmd	qmd：給 AI Agent 使用的本地 Markdown 文件搜尋工具	tobi/qmd	本地 Markdown 文件搜尋	用 Markdown 管理知識庫的人
Firecrawl	Firecrawl 專案整理：給 AI Agent 用的網頁搜尋、抓取與互動 API	firecrawl/firecrawl	網頁抓取、搜尋和結構化資料入口	做 RAG 和 Agent 資料入口的人
RAGFlow	RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法	infiniflow/ragflow	開源 RAG 引擎	企業知識庫和文件問答使用者
OpenHuman	OpenHuman 速讀：開源個人 AI Agent 的桌面化路線	tinyhumansai/openhuman	本地優先的個人 AI Agent 與記憶層	想整合個人資料的人
OpenKB	OpenKB：把文件編譯成可持續更新的 LLM 知識庫	VectifyAI/OpenKB	把文件編譯成可更新知識庫	文件知識庫維護者
PageIndex	PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析	VectifyAI/PageIndex	不依賴向量庫的推理式文件索引	關注 RAG 新路線的人

多模態與內容創作

這一類面向圖片、影片、語音轉寫和內容分發等創作場景。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
rembg	rembg 專案整理：本地圖片背景移除工具	danielgatis/rembg	本地圖片背景移除	電商、美工和圖片處理使用者
awesome-gpt-image-2-prompts	GPT-Image 2 提示詞寶庫：電商、海報、人像、UI 全收錄	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示詞和案例庫	AI 繪圖和提示詞使用者
faster-whisper	faster-whisper：更快的 Whisper 轉寫引擎	SYSTRAN/faster-whisper	高效能語音轉文字	做字幕、轉寫和語音處理的人
Pixelle-Video	Pixelle-Video：一句主題生成短影片的開源 AI 引擎	AIDC-AI/Pixelle-Video	一句話生成短影片工作流	短影片和 AIGC 內容創作者
AiToEarn	內容發太多平臺太累？AiToEarn 想用 AI Agent 幫創作者省點事	yikart/AiToEarn	多平臺內容分發與創作者自動化	內容運營和創作者

本地模型與推理

這一類關注本地模型執行和推理實驗，當前數量較少。共 1 個專案。

專案	文章	GitHub	核心用途	適合人群
ds4	本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試	antirez/ds4	在 Apple Silicon 上嘗試執行 DeepSeek 4	本地模型和推理實驗使用者

垂直應用與自動化

這一類是把 Agent 或 AI 能力落到金融、交易、瀏覽器、桌面和電商監控等具體場景。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
TradingAgents-CN	TradingAgents-CN：面向中文使用者的多智慧體金融交易研究框架	hsliuping/TradingAgents-CN	多智慧體金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：開源金融終端、量化研究和 AI Agent 工作臺	Fincept-Corporation/FinceptTerminal	金融終端、量化研究和 AI Agent 工作臺	金融分析和量化使用者
Anthropic financial-services	Anthropic financial-services：把金融 Agent 場景做成可複用模板	anthropics/financial-services	金融服務 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自動盯閒魚商品的開源監控系統	Usagi-org/ai-goofish-monitor	AI 商品監控和閒魚自動化	二手交易監控使用者
CloakBrowser	CloakBrowser 是什麼？給 Playwright 和 Puppeteer 換一個更像真實使用者的瀏覽器	CloakHQ/CloakBrowser	更像真實使用者的瀏覽器自動化環境	瀏覽器自動化和 Agent 操作場景
UI-TARS-desktop	讓 AI 自己操作電腦？UI-TARS-desktop 把桌面、瀏覽器和工具都接了起來	bytedance/UI-TARS-desktop	桌面、瀏覽器和工具操作 Agent	想讓 AI 操作電腦的人
AI-Trader	AI-Trader 是什麼？一個讓 AI Agent 釋出交易訊號、做模擬交易的平臺	HKUDS/AI-Trader	AI Agent 交易訊號和模擬交易平臺	金融 Agent 與交易研究使用者

AI 應用開發基礎設施

這一類提供構建 AI 應用和 Agent 工具鏈所需的基礎元件。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
Prompt Optimizer	Prompt Optimizer：開源提示詞最佳化、測試與 MCP 工具	linshenkx/prompt-optimizer	提示詞最佳化、測試和 MCP 工具	做 prompt 工程和應用調參的人
Playwright CLI	Playwright CLI 使用入門：安裝、Skills、會話管理與常用命令	microsoft/playwright-cli	面向 coding agent 的瀏覽器自動化 CLI	需要瀏覽器操作能力的 Agent 使用者
Vercel AI SDK	Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包	vercel/ai	TypeScript AI 應用開發 SDK	前端和全棧開發者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 統一封裝成 API	router-for-me/CLIProxyAPI	把多個 AI CLI 和 OAuth 登入狀態封裝成相容 API	想統一接入 Codex、Claude Code、Gemini CLI 的使用者
CLIProxyAPI Management Center	CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理介面，管理設定、帳號、日誌和 OAuth	把 CLIProxyAPI 當團隊閘道或帳號池使用的人

PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex 是一個很有意思的 RAG 專案。它不從「再建一個向量庫」開始，而是把長文件先整理成類似目錄的樹狀結構，再讓 LLM 沿著這棵樹做推理式檢索。

專案地址：VectifyAI/PageIndex

截至本文整理時，GitHub 頁面顯示專案約有 31.8k stars、2.7k forks，授權為 MIT。README 給它的定位是：Vectorless, Reasoning-based RAG，也就是無向量庫、基於推理的 RAG。

它想解決什麼問題

傳統 RAG 的常見路徑是：切塊、向量化、寫入向量資料庫，再用相似度搜尋召回片段。這套方法簡單、通用，也很成熟，但在長篇專業文件裡容易遇到幾個問題：

相似度不等於真正相關。
文件結構被切塊打散，章節關係丟失。
召回結果可解釋性弱，很難說明為什麼命中這一段。
對財報、監管文件、法律文書、技術手冊這類材料，問題往往需要跨章節推理。

PageIndex 的思路是反過來：先把文件組織成語義樹，再讓模型像人類讀目錄、翻章節、逐層定位一樣查找相關內容。

PageIndex 的基本工作流

README 裡把 PageIndex 的檢索分成兩步：

為文件生成類似 Table-of-Contents 的樹狀結構索引。
透過樹搜尋做 reasoning-based retrieval。

這棵樹不是簡單的檔案目錄，而是面向 LLM 使用的文件結構。節點裡會有標題、頁碼範圍、摘要、子節點等資訊。這樣模型在回答問題時，不必一開始就面對大量零散 chunk，而是可以先判斷應該進入哪個章節，再繼續向下搜尋。

這種方式更適合結構清晰但內容很長的文件，例如：

金融報告和 SEC filings。
監管材料和合規文件。
學術教材和論文。
法律文件。
技術手冊和產品文件。
超過模型上下文視窗的大型 PDF。

和傳統向量 RAG 的差異

PageIndex 的主要賣點可以概括成五點。

第一，不需要 Vector DB。它依賴文件結構和 LLM 推理來定位內容，而不是只做向量相似度搜尋。

第二，不做傳統 chunking。文件會按自然章節組織，而不是被切成固定長度片段。

第三，可解釋性更強。檢索路徑可以對應到頁碼、章節和樹節點，比「向量相似度命中某段文字」更容易追蹤。

第四，檢索是上下文感知的。問題、對話歷史、領域背景都可以影響樹搜尋路徑。

第五，更接近人類專家讀文件的方式。人通常不是把整份文件切成小塊再算相似度，而是先看目錄，再定位章節，最後讀細節。

這並不意味著向量庫沒有價值。更準確的說法是：PageIndex 適合那些「語義相似不夠，需要結構和推理參與」的長文件場景。

本地怎麼跑

README 提供了本地自託管方式。先安裝依賴：

`1`	`pip3 install --upgrade -r requirements.txt`

然後在專案根目錄建立 .env，寫入 LLM API key。專案透過 LiteLLM 支援多模型：

`1`	`OPENAI_API_KEY=your_openai_key_here`

對 PDF 生成 PageIndex 結構：

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

也可以處理 Markdown：

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

常見可選參數包括：

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 裡也提醒，本地開源版本使用標準 PDF 解析。如果是複雜 PDF，專案方的雲服務會提供增強 OCR、樹構建和檢索流程。

Agentic Vectorless RAG 示例

專案還提供了一個 agentic vectorless RAG 示例，使用自託管 PageIndex 和 OpenAI Agents SDK。安裝可選依賴後執行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

這個示例的價值在於，它把 PageIndex 從「生成文件樹」推進到「讓 Agent 使用文件樹檢索」。如果你正在做企業知識庫、財報問答、法規問答或技術文件 Agent，這個示例比單純看 README 更值得跑一遍。

雲服務、MCP 和 API

PageIndex 不只是一個 GitHub repo。專案頁面還給了幾類入口：

自託管：用開源程式碼本地執行，適合試驗和可控部署。
Chat Platform：類似 ChatGPT 的文件分析平台。
MCP / API：方便接入現有 Agent 或自動化流程。
Enterprise：面向私有化或本地部署。

這說明它的定位不是單純的 demo，而是想把「推理式文件檢索」做成一套可整合的文件智能基礎設施。

適合哪些場景

PageIndex 比較適合這些任務：

長 PDF 問答。
財報、年報、招股書、監管文件分析。
法律和合規文件檢索。
技術手冊問答。
多章節教材或論文檢索。
需要可解釋檢索路徑的企業知識庫。
給 Agent 提供結構化文件上下文。

如果你的材料本身很短、結構不明顯，或者只是普通 FAQ，傳統 embedding + vector DB 可能已經夠用。PageIndex 的優勢更容易出現在長文件、強結構、專業領域和需要推理的問題裡。

需要注意什麼

第一，PageIndex 仍然依賴 LLM。樹構建、摘要和檢索品質會受模型能力、提示詞、文件解析品質影響。

第二，本地版本使用標準 PDF 解析，複雜掃描件、圖表密集型 PDF、版式混亂材料可能需要 OCR 和更強的預處理。

第三，無向量庫不等於零成本。樹構建本身也會消耗模型呼叫和時間，尤其是大規模文件庫。

第四，它更像是文件結構索引和推理檢索框架，不是直接替代所有 RAG 技術棧。實際生產裡，也可能和向量檢索、關鍵字檢索、權限控制、快取、稽核系統一起使用。

小結

PageIndex 的有趣之處在於，它把 RAG 的重點從「文字相似度召回」轉向「文件結構 + LLM 推理」。對於長文件和專業文件，這個方向很值得關注。

如果你正在做企業文件問答、金融報告分析、法規檢索或技術手冊 Agent，可以把 PageIndex 當成一個新的 RAG 架構參考：先讓文件有結構，再讓模型沿著結構推理，而不是一開始就把所有內容切碎丟進向量庫。

參考來源：

GitHub：VectifyAI/PageIndex

Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具

Mon, 18 May 2026 18:57:16 +0800

Open Design 是 nexu-io 推出的開源 AI 設計專案，定位是 local-first、open-source 的 Claude Design / Figma 替代方案。

它想解決的問題很明確：Claude Design 證明了大模型可以直接生成設計製品，但這類能力如果只存在於閉源、雲端、單一模型的產品裡，使用者就很難自託管、接入自己的 Agent、替換模型、沉澱私有設計系統，或者把產物放進本地工作流。

Open Design 的思路不是重新造一個大模型，而是把你電腦上已有的 coding-agent CLI 接進一個設計工作台。Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot CLI、Kimi、DeepSeek TUI 等工具，都可以成為它的「設計引擎」。

Open Design 是什麼

Open Design 可以理解為三個部分的組合：

一個 Web UI，用來對話、預覽、管理專案和匯出產物。
一個本地 daemon，負責調度 Agent、管理文件、保存專案和提供 API。
一組 Skills、Design Systems 和模板，用來約束 Agent 生成更像設計作品，而不是隨手拼出來的 AI 頁面。

使用者輸入需求後，Open Design 不只是把一句話丟給模型。它會先讓使用者補充設計簡報，選擇場景和方向，再把專案元資料、目前設計系統、Skill 文件、模板、檢查清單等上下文注入給 Agent。Agent 在真實文件夾裡讀寫文件，最後生成可在沙盒 iframe 中預覽的 artifact。

這讓它更接近「AI 設計工作流」，而不是單次網頁生成器。

為什麼它和普通 AI 生成網頁不一樣

很多 AI 工具都能生成一個 HTML 頁面，但 Open Design 的重點不是「讓模型寫頁面」，而是「讓模型按設計流程交付可預覽、可匯出、可迭代的製品」。

它強調幾個設計：

先問問題，再生成。新設計 brief 會先出現互動式 question form，用來鎖定受眾、語氣、品牌上下文、約束和視覺方向。
Skills 是文件，不是黑盒外掛。每個 Skill 由 SKILL.md、assets/、references/ 組成，可以被閱讀、替換和擴展。
Design Systems 是 Markdown，不是固定主題 JSON。顏色、字體、間距、元件、動效、品牌語氣和反模式都可以寫進 DESIGN.md。
Agent 在真實專案目錄裡工作。它能讀模板、寫文件、生成圖片、輸出 .pptx、.pdf、.zip 等文件。
產物在沙盒 iframe 中預覽，減少直接執行不受控程式碼的風險。

這套結構的目標，是讓 AI 更像一個有規範、有素材、有檢查清單的設計協作者。

它支援哪些 Agent

Open Design 的一個亮點是「把 Agent 當運行時」，而不是綁定某一家模型。

README 中列出的支援對象包括 Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUI 等。它會從 PATH 中自動檢測這些 CLI，並允許使用者切換。

如果本地沒有合適的 CLI，也可以走 OpenAI-compatible 的 BYOK proxy，把自己的 baseUrl、apiKey 和模型填進去，讓 daemon 把串流輸出規範化成同一套聊天流。

這種設計的好處是：

不鎖定單一模型。
可以複用使用者已經安裝和配置好的 Agent。
本地文件讀寫由 daemon 管理，權限邊界更清楚。
對企業或重度使用者來說，更容易接入自己的模型和 API 供應商。

Skills 和 Design Systems 是它的核心資產

Open Design 內建了大量 Skills 和 Design Systems。README 中提到，專案內建的 Skills 覆蓋網頁原型、SaaS landing page、dashboard、mobile app、gamified app、社群輪播圖、雜誌海報、PPT、週報、財務報告、HR onboarding、invoice、kanban、OKR 等場景。

Design Systems 則用於給 Agent 提供品牌級視覺約束。倉庫介紹中列出了 Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小紅書等設計系統來源。

這兩者的關係可以這樣理解：

Skill 決定「這次要交付什麼類型的作品」。
Design System 決定「作品應該長成什麼品牌風格」。

如果沒有這兩層約束，AI 很容易生成那種看起來熟悉但缺少判斷的通用頁面。有了 Skill 和 Design System，模型至少有了清楚的任務邊界、視覺參考和檢查規則。

它能生成什麼

Open Design 不是只做網頁原型。

按 README 的描述，它覆蓋 web、desktop、mobile prototypes、slides、images、videos、HyperFrames 等方向，並支援 HTML、PDF、PPTX、ZIP、Markdown 等匯出形式。媒體生成方面，它把圖片、影片、音訊也放在同一個設計循環裡，例如海報、頭像、資訊圖、地圖插畫、短影片和 HTML 轉 MP4 動效。

這意味著它的使用場景可以很寬：

創業團隊快速做 pitch deck。
產品團隊生成 landing page 或功能原型。
營運團隊做活動頁、社群圖、週報。
設計師用它做 moodboard、視覺方向和第一版 layout。
開發者把需求轉成可運行的前端 artifact。

它的價值不只是「生成一個頁面」，而是把多個內容形態放進同一套 Agent 工作流。

本地優先是什麼意思

Open Design 強調 local-first。它不是把所有東西都交給一個遠端 SaaS 後端，而是在本地跑 daemon 和專案工作區。

倉庫 README 裡描述的架構大致是：

前端是 Next.js / React / TypeScript。
本地 daemon 使用 Node、Express、SQLite 和 SSE。
專案、會話、訊息、tab、模板等資料保存在本地 SQLite 和 .od/projects/<id>/ 目錄。
Agent 透過 child_process.spawn 啟動，並在專案 artifact 文件夾中讀寫。
預覽透過沙盒 iframe 渲染。
匯出包括 HTML、PDF、PPTX、ZIP、Markdown。

這種結構更適合希望把設計產物留在本機、接入本地 Agent、控制 API key、維護私有工作區的使用者。

不過 local-first 不等於完全離線。實際生成仍然取決於你使用的 Agent 和模型。如果你用的是雲端模型 API，內容仍然會發往對應供應商。Open Design 更準確的定位，是把工作區、調度、文件和預覽放回本地，把模型層交給使用者自己選擇。

和 Claude Design / Figma 的關係

Open Design 在 README 中明確把自己稱為 Claude Design / Figma 的開源替代方向，但它並不是傳統意義上的 Figma 複刻。

Figma 是設計師手動編輯、協作和交付設計稿的專業工具；Open Design 更偏 Agent-native：使用者透過自然語言、表單、Skills 和設計系統驅動 Agent 產出可運行 artifact。

它更像是把幾個東西合在一起：

Claude Design 的 artifact-first 體驗。
Figma 的設計系統意識。
Claude Code / Codex 這類 Agent 的文件讀寫和執行能力。
本地 daemon 的專案管理和沙盒預覽。

所以它未必會替代專業設計師的全流程工具，但很適合做「從想法到可預覽原型」的快速通道。

適合誰使用

Open Design 更適合這些人：

已經在使用 Claude Code、Codex、Cursor、Gemini CLI 等 Agent 的開發者。
想把 AI 設計產物放到本地專案目錄裡管理的人。
需要快速生成網頁原型、PPT、海報、營運素材的創業團隊。
希望自定義 Skills、Design Systems、提示詞棧的進階使用者。
不想被單一模型或單一雲端產品鎖住的團隊。

不太適合這些人：

只想打開網頁、輸入一句話、立刻下載圖片的輕量使用者。
完全不想碰 Node、pnpm、daemon、CLI 和本地配置的人。
需要成熟多人協作、設計評審和向量編輯能力的專業 Figma 流程。

換句話說，Open Design 更像給 Agent 使用者和技術型設計團隊準備的工具，而不是面向所有人的輕量設計 SaaS。

需要注意的地方

Open Design 的 README 標註了 0.8.0-preview，並說明專案仍在快速迭代。這類專案的活力很強，但也意味著 API、資料目錄、桌面版遷移、Skills 結構和匯出流程可能還會變化。

使用前最好注意幾點：

不要把它當成穩定企業級設計平台。
先用測試專案體驗工作流，再匯入重要資料。
如果要遷移 .od/ 資料，先備份，確保 daemon 和桌面應用都已停止。
BYOK 時注意 API key、代理地址和本地私有網路存取風險。
生成的設計仍需要人工審查，尤其是品牌、版權、文案和視覺一致性。

開源專案最大的好處是可檢查、可改、可貢獻；代價是你需要接受一定的工程摩擦。

小結

Open Design 的看點，不只是「開源版 Claude Design」。它真正有意思的地方，是把 Agent CLI、Skills、Design Systems、本地 daemon 和沙盒預覽組織成一個設計工作流。

它把設計生成從單次 prompt 推向了更結構化的流程：先問問題，選方向，載入設計系統，讀取 Skill，寫入真實文件，預覽 artifact，再匯出結果。

如果你已經習慣用 Claude Code、Codex 或 Cursor 處理程式碼，那麼 Open Design 值得關注。它代表了一種新的產品形態：不是 AI 幫你畫一張圖，而是 AI 在本地專案空間裡，按設計系統和任務技能，生成一組可以繼續迭代的設計製品。

參考資料

nexu-io/open-design GitHub 倉庫

OpenHuman 速讀：開源個人 AI Agent 的桌面化路線

Fri, 15 May 2026 14:52:31 +0800

OpenHuman 是 tinyhumansai 推出的開源個人 AI Agent 專案。它的目標不是再做一個聊天視窗，而是把桌面應用、個人記憶、第三方整合、語音、編碼工具和本機知識庫放進同一個 agent harness 裡，讓 AI 更快理解你的日常工作上下文。

專案 README 給它的定位是 “Personal AI super intelligence”，官網也強調 private、simple 和 extremely powerful。這個說法很有野心，但更適合拆開看：OpenHuman 真正值得關注的地方，是它試圖把「個人上下文」作為產品核心，而不是把模型呼叫、外掛設定和文件檢索留給使用者自己拼。

截至本文查看時，GitHub 倉庫約有 7.8k stars、629 forks，最新 release 顯示為 OpenHuman v0.53.43，時間是 2026 年 5 月 13 日。專案仍處在 Early Beta，README 明確提醒正在活躍開發中，應該預期會有粗糙邊緣。

它想解決什麼問題

很多 AI 助手的問題不是模型不夠強，而是上下文太冷。你每次都要重新解釋專案背景、最近郵件、日程、程式碼倉庫、文件、任務和偏好；一旦跨到 Gmail、Notion、GitHub、Slack、Calendar、Drive、Linear、Jira 這些系統，資訊又被拆散到不同工具裡。

OpenHuman 的思路是：先把這些資料接進來，再透過自動抓取、壓縮、摘要和本機知識庫，構建一個可以持續更新的個人記憶層。這樣 agent 不是只記得當前對話，而是能圍繞你的工作流形成長期上下文。

這也是它和普通聊天機器人最大的差異。聊天機器人往往圍繞 prompt 工作；OpenHuman 更像一個桌面端個人操作系統入口，試圖把連接器、記憶、工具和模型路由都預先打包。

主要能力

OpenHuman README 裡列出的核心能力包括：

桌面優先的 UI 和較短的上手路徑，不要求使用者先從終端設定開始。
一個帶「臉」的桌面 mascot，可以說話、響應環境，並參與 Google Meet。
118+ 第三方整合，覆蓋 Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira 等工具。
自動抓取機制：專案描述中提到每 20 分鐘遍歷活躍連接，把新資料拉入 memory tree。
Memory Tree：把連接資料和活動資訊壓縮成 Markdown 區塊，並存入本機 SQLite。
Obsidian-compatible vault：把知識區塊落成 .md 檔案，使用者可以用 Obsidian 打開、瀏覽和編輯。
內建搜尋、網頁抓取、編碼工具、檔案系統、git、lint、test、grep、語音輸入輸出等能力。
Model routing：按任務把請求路由到不同模型類型。
TokenJuice：在工具結果、網頁抓取、郵件正文、搜尋結果進入 LLM 前做 token 壓縮。
可選 Ollama，用於本機 AI 工作負載。

這些能力聽起來很多，真正的重點可以歸納成兩條：一是減少設定和外掛拼裝；二是把你的個人資料變成 agent 可檢索、可壓縮、可持續更新的記憶。

安裝方式

專案提供網站下載入口，也給了終端安裝命令。

macOS 或 Linux x64：

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows：

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

如果是日常主力機，建議先從官網下載安裝包，或者至少先打開安裝腳本檢查內容，再決定是否直接執行遠端腳本。OpenHuman 涉及郵箱、文件、程式碼倉庫、日曆和本機檔案權限，安裝和授權都應該比普通小工具更謹慎。

開源和技術棧

OpenHuman 倉庫採用 GPL-3.0 license。倉庫語言占比顯示 Rust 為主，TypeScript 次之，另外還有 JavaScript、Shell、CSS 和 PowerShell。README 的貢獻說明要求 Node.js 24+、pnpm 10.10.0、Rust 1.93.0、CMake，以及平台相關桌面構建依賴。

本機開發的大致路徑是：

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

提交前推薦跑 focused checks，例如：

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

從目錄結構看，它不是一個輕量腳本專案，而是包含桌面應用、前端、Rust 後端、文件、測試、示例和構建腳本的完整產品型倉庫。

Memory Tree 和 Obsidian vault 為什麼重要

OpenHuman 裡最值得單獨看的概念是 Memory Tree。README 描述它會把連接進來的資料標準化成不超過約 3k token 的 Markdown chunks，打分後折疊進層級摘要樹，並存入本機 SQLite。相同內容也會進入 Obsidian 相容 vault。

這條路線有幾個好處：

使用者可以直接看到 agent 的知識庫，而不是只能相信黑盒記憶。
Markdown 檔案方便搜尋、備份、版本管理和人工修訂。
SQLite 適合本機索引和快速查詢。
層級摘要比一堆平鋪文件更適合長期上下文壓縮。

但它也有現實挑戰：資料同步是否穩定、摘要是否會丟關鍵細節、權限邊界是否足夠清晰、刪除和撤銷是否完整、不同連接器的語義是否能被一致處理。這些都不是 README 裡一句 “remembers everything” 就能解決的，需要長期使用和審計才能判斷。

TokenJuice：成本和延遲的中間層

OpenHuman 還強調 TokenJuice。它的作用是在網頁、郵件、搜尋結果和工具呼叫結果進入模型前做壓縮，例如把 HTML 轉成 Markdown、縮短長 URL、移除部分非必要字元等。README 宣稱這可以減少成本和延遲，最高降低 80% token 使用。

這個方向是合理的。Agent 系統真正燒錢的地方，往往不是一次聊天，而是後台抓取、工具呼叫、搜尋、網頁解析和長上下文注入。把資料先清洗再交給模型，通常比直接塞原始內容更穩。

不過壓縮層也會帶來新問題：它會決定哪些資訊被保留，哪些被丟棄。如果你用它處理合約、帳單、醫學記錄、合規材料或生產事故日誌，就不能只看 token 節省，還要看可追溯性、原文回查和壓縮誤差。

隱私：賣點也是審查重點

OpenHuman 的賣點之一是 private。官網提到本機 AI 模型可處理低階任務，README 也強調 workflow data stays on device、encrypted locally、treated as yours。

這類設計方向很吸引人，因為個人 AI Agent 一旦接入 Gmail、Drive、Calendar、Slack、GitHub，就會碰到最敏感的工作資料。相比完全雲端的助手，本機優先的記憶層和可見的 Markdown vault 至少給了使用者更多控制感。

但也要把話說完整：OpenHuman 同時提到 one subscription、30+ providers、model routing、ElevenLabs TTS、OAuth integrations 等能力。這意味著它不是純離線工具。真正評估隱私時，需要看每個連接器、每類模型呼叫、每個語音和搜尋能力分別把什麼資料送到哪裡。

適合誰關注

OpenHuman 現在更適合三類人：

想要個人 AI 操作台，而不是單點聊天機器人的使用者。
願意嘗試 Early Beta，並能接受功能變化和粗糙邊緣的開發者。
關注本機記憶、Obsidian 工作流、agent connector 和上下文壓縮的人。

如果你只是想找一個穩定、輕量、隱私邊界極簡的離線助手，那它目前可能太重。如果你想研究下一代個人 AI Agent 會如何整合桌面、連接器、記憶和工具，OpenHuman 則是一個值得跟蹤的開源樣本。

我的建議是先把它當成「產品型開源實驗」觀察：看 release 節奏、issue 品質、連接器權限、資料匯出能力、刪除機制和本機 vault 的可讀性。個人 AI 的關鍵不只是能不能回答問題，而是它是否能長期、透明、可控地承載你的上下文。

參考連結

本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試

Mon, 11 May 2026 08:51:37 +0800

Antirez 開源了一個新專案：ds4。它不是通用 LLM 框架，而是一個面向 DeepSeek V4 Flash 的本地推理引擎，重點放在 Apple Silicon 和 Metal 後端上。

專案地址：https://github.com/antirez/ds4

ds4 是什麼

ds4 的目標很明確：在 Mac 上本地執行 DeepSeek V4 Flash。

它目前提供三種使用方式：

互動式 CLI。
HTTP server。
一個實驗性的 Agent 模式。

從定位看，它更像是一個針對特定模型深度最佳化的推理專案，而不是要取代 llama.cpp、Ollama 或 vLLM 這類通用工具。

為什麼值得關注

這類專案值得看，主要有三個原因。

第一，作者是 Redis 作者 Antirez。他長期關注底層系統、效能和簡單工具，專案風格通常比較直接。

第二，DeepSeek V4 Flash 屬於面向高效推理的模型方向。如果本地執行體驗足夠好，對 Mac 使用者來說會很有吸引力。

第三，ds4 直接面向 Apple Metal。相比「先支援所有平台，再慢慢最佳化」的路線，它更像是先把一個明確場景做深。

適合誰用

ds4 更適合這幾類使用者：

使用 Apple Silicon Mac。
想在本地執行 DeepSeek V4 Flash。
關注 Metal 推理效能。
願意嘗試 alpha 階段專案。
想研究輕量推理引擎和模型執行細節。

如果你的目標是穩定部署、跨平台執行、OpenAI API 相容生態，現階段它未必是首選。它更適合作為實驗工具和技術觀察對象。

使用方式

專案 README 給出的基本流程是先建置，再執行。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

互動式執行：

./ds4

啟動 HTTP server：

`1`	`./ds4 --server`

Agent 模式：

`1`	`./ds4 --agent`

具體參數和模型檔案準備方式，建議以倉庫 README 為準，因為專案仍在快速變化。

目前的風險

ds4 還處在早期階段，使用前要有預期：

功能可能不完整。
參數、模型格式和命令列行為可能變化。
相容性主要圍繞 Apple Silicon 和 Metal。
Agent 模式更偏實驗，不適合直接用於生產流程。
遇到問題時，需要自己閱讀 README、issue 或原始碼排查。

也就是說，它現在更像「值得動手試的開源實驗」，還不是面向普通使用者的一鍵工具。

和通用推理工具的區別

通用推理工具通常追求模型格式、平台、後端和 API 的廣泛相容。ds4 的方向更窄：圍繞 DeepSeek V4 Flash 和 Metal 做本地執行。

這種選擇有利有弊。

好處是實作可以更集中，效能和體驗更容易圍繞單一目標最佳化。代價是適用範圍有限，不適合拿來執行各種不同模型，也不適合取代完整的部署平台。

如果你已經在用 llama.cpp 或 Ollama，ds4 可以作為補充測試工具，而不是馬上替換現有工作流。

小結

ds4 的看點不在「又一個本地大模型工具」，而在於它把範圍收得很窄：DeepSeek V4 Flash、Apple Silicon、Metal、本地推理。

如果你手上有合適的 Mac，並且願意折騰早期專案，可以關注它後續的效能表現、模型支援方式和 server/agent 能力演進。對於生產環境，建議繼續觀望，等介面和使用方式穩定後再評估。

參考

GitHub 專案：https://github.com/antirez/ds4

Pixelle-Video：一句主題生成短影片的開源 AI 引擎

Thu, 07 May 2026 20:25:17 +0800

Pixelle-Video 是 AIDC-AI 開源的全自動短影片生成引擎。它的目標很直白：使用者輸入一個主題，系統自動完成影片文案、AI 配圖或影片、語音解說、背景音樂和最終合成。

這類工具適合短影片批量創作、知識科普、口播內容、小說解說、歷史文化類影片和自媒體素材實驗。它不是單一的「文生影片模型」，而是把多種 AI 能力接成一條生產流水線。

它能自動做什麼

Pixelle-Video 的預設流程可以概括為：

輸入主題或固定文案；
由大型語言模型生成解說詞；
根據分鏡規劃生成配圖或影片素材；
使用 TTS 生成語音解說；
添加背景音樂；
套用影片模板並合成最終成片。

README 中給出的流程是「文案生成 → 配圖規劃 → 逐幀處理 → 影片合成」。這種模組化設計的好處是清晰：每一步都可以替換模型、調整參數或改用自訂工作流。

功能亮點

專案支援的能力相當完整：

AI 智慧文案：根據主題自動生成影片解說詞；
AI 配圖：為每句話或每個分鏡生成插圖；
AI 影片生成：支援接入 WAN 2.1 等影片生成模型；
TTS 語音：支援 Edge-TTS、Index-TTS 等方案；
背景音樂：可以使用內建 BGM，也可以放入自訂音樂；
多尺寸輸出：支援直式、橫式等不同影片比例；
多模型選擇：可接入 GPT、通義千問、DeepSeek、Ollama 等；
ComfyUI 工作流：可以使用預置工作流，也可以替換生圖、TTS、影片生成等環節。

最近更新裡還提到動作遷移、數位人口播、圖生影片、多語言 TTS 音色、RunningHub 支援、Windows 一鍵整合包等內容。這說明專案已經不只是一個腳本，而是在往完整創作工具方向發展。

安裝和啟動方式

Windows 使用者可以優先看官方提供的一鍵整合包。它的定位是降低安裝門檻，不需要手動準備 Python、uv 或 ffmpeg，解壓後執行 start.bat，再在瀏覽器裡打開 Web 介面配置 API 和圖像生成服務。

如果從源碼啟動，README 給出的基本方式是：

1
2
3

git clone https://github.com/AIDC-AI/Pixelle-Video.git
cd Pixelle-Video
uv run streamlit run web/app.py

源碼方式適合 macOS、Linux 使用者，也適合需要修改模板、工作流或服務配置的人。前置依賴主要是 uv 和 ffmpeg。

配置重點

第一次使用時，關鍵不是先點「生成」，而是把幾個外部能力接好。

LLM 配置決定文案品質。你可以選擇通義千問、GPT、DeepSeek、Ollama 等模型，並填寫對應的 API Key、Base URL 和模型名。如果想盡量降低成本，本地 Ollama 是一個方向；如果追求穩定效果，雲端模型會更省心。

圖像和影片生成配置決定畫面品質。專案支援本地 ComfyUI，也支援 RunningHub。懂 ComfyUI 的使用者可以把自己的工作流放進 workflows/ 目錄，用來替換預設生圖、影片或 TTS 流程。

模板配置決定最終成片的視覺形態。專案用 templates/ 目錄組織影片模板，靜態模板、圖片模板和影片模板按命名規則區分。對內容創作者來說，這比只生成一段素材更實用，因為最終交付物是可以直接預覽和下載的影片。

適合什麼人

Pixelle-Video 比較適合三類使用者：

短影片創作者：想快速把選題變成可發布的草稿影片；
AIGC 工具玩家：想把 LLM、ComfyUI、TTS 和影片合成串起來；
開發者和自動化使用者：想基於開源專案改模板、改工作流，甚至接入自己的素材和模型。

如果你只想偶爾做一支高品質精品影片，它未必能直接替代人工剪輯；但如果你想批量生成結構一致的解釋類、口播類、科普類內容，它的流水線思路很有價值。

需要注意的地方

這類工具的上限由多個環節共同決定。文案模型不好，內容會空；配圖模型不好，畫面會散；TTS 不自然，影片會顯得粗糙；模板不合適，最終成片也會缺少辨識度。

所以使用 Pixelle-Video 時，建議先從一個固定場景開始調試，比如「60 秒知識科普直式影片」。把 LLM、畫面風格、TTS 音色、BGM 和模板固定下來，再逐步擴大到其他主題。

另外，專案雖然支援本地免費方案，但本地方案通常需要顯卡、ComfyUI 配置和模型檔案。沒有本地推理環境的使用者，可以用雲端 LLM 加 RunningHub 的方式降低部署難度，但要留意呼叫成本。

簡短判斷

Pixelle-Video 的看點不只是「輸入一句話生成影片」，而是它把短影片生產拆成可替換的模組：文案、畫面、語音、音樂、模板和合成。對普通使用者，它是一個低門檻 AI 影片工具；對開發者，它更像一個可改造的短影片自動化框架。

如果你正在研究 AI 短影片流水線，或者想把 ComfyUI、TTS、LLM 和模板合成串成一個可用產品，Pixelle-Video 值得試用和拆解。

Warp 開源：從終端到 Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp 是 Warp 的開源客戶端倉庫。Warp 官方現在把它定位為一個「從終端生長出來的 agentic development environment」，也就是以終端為基礎，但把 AI coding agent、程式碼庫索引、任務管理和開發工作流放進同一個環境裡。

這不是一個普通的終端模擬器開源倉庫。它更像是在回答一個問題：當 Claude Code、Codex、Gemini CLI 這類 agent 越來越常見時，終端本身要不要變成一個能調度、觀察和管理 agent 的開發環境？

Warp 的答案是：要。

這個倉庫現在是什麼狀態

截至 2026 年 5 月 7 日查看，warpdotdev/warp 是公開倉庫，GitHub 頁面顯示約 56k stars、4.1k forks。倉庫 README 說明，Warp 的客戶端程式碼已經開源，並歡迎社群貢獻。

倉庫的主語言是 Rust。GitHub 語言統計裡，Rust 占比超過 98%。這和 Warp 的定位一致：它不是網頁殼，而是一個跨平台的原生開發工具。

README 中有幾個資訊點很重要：

Warp 是一個 agentic development environment, born out of the terminal。
它可以使用內建 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI agent。
OpenAI 是新開源 Warp 倉庫的 founding sponsor。
倉庫中的 agentic management workflows 由 GPT models 驅動。
Warp UI framework 相關 crate 使用 MIT license，其餘程式碼使用 AGPL v3。

這些資訊說明，Warp 開源不是單純把一個終端放出來，而是把它作為「agent 工作流實驗場」來營運。

Warp 不只是終端

傳統終端主要解決三個問題：

啟動 shell。
執行命令。
顯示輸出。

Warp 早期的差異化，是讓終端更現代：命令區塊、補全、歷史、協作、UI 化互動、跨平台體驗。現在它的重心繼續往前走，開始圍繞 AI agent 組織開發流程。

從 README 看，Warp 不再只強調「更好用的 terminal」，而是強調：

內建 coding agent。
支援外部 CLI agent。
issue triage。
spec 編寫。
PR review。
contributor coordination。
可觀察的 agent sessions。

也就是說，Warp 想把終端從「你輸入命令的地方」，變成「你和多個 agent 一起工作的地方」。

Oz 和開源專案管理

README 裡多次提到 Oz。

Warp 的貢獻概覽頁面可以看到成千上萬個 Oz agents 在做 issue triage、寫 specs、實作改動、review PR。這個設計很有意思，因為它把 AI agent 從「幫個人寫程式碼」擴展到了「幫開源專案管理協作」。

傳統開源專案最難的不是寫程式碼，而是維護：

issue 太多，沒人分類。
bug 和 feature request 混在一起。
新貢獻者不知道哪些任務能做。
PR review 壓力大。
維護者很難持續跟進社群討論。

Warp 的思路是，讓 agent 先承擔一部分專案管理和協作工作。README 中還提到 Oz for OSS，這是面向維護者的合作計畫，用於把類似 agentic open-source management workflows 帶到其他開源倉庫。

這說明 Warp 的野心不只是終端產品本身，也包括探索 AI 時代開源維護的新模式。

倉庫結構和技術棧

從倉庫結構看，Warp 是一個大型 Rust 專案。

根目錄裡能看到：

app/：主應用相關程式碼。
crates/：核心 Rust crates。
assets/：資源檔案。
command-signatures-v2/：命令簽名相關內容。
docker/、script/、resources/、specs/ 等工程目錄。
.claude/、.warp/、.agents/skills 等 agent 相關配置。

WARP.md 裡給出了更詳細的工程說明。它提到 Warp 是 Rust-based terminal emulator，並使用一個自研 UI framework WarpUI。

主要模組可以粗略理解為：

app/：終端模擬、shell 管理、AI 整合、Drive、認證、設定、workspace 和 session。
crates/warp_core/：核心工具和平台抽象。
crates/editor/：文字編輯功能。
crates/warpui/ 和 crates/warpui_core/：自研 UI framework。
crates/ipc/：行程間通訊。
crates/graphql/：GraphQL client 和 schema。

WARP.md 還提到幾個架構特點：

Entity-Handle system。
模組化 workspace 結構。
macOS、Windows、Linux 跨平台，以及 WASM target。
AI integration，包含 Agent Mode、上下文感知和程式碼庫索引。
Warp Drive 雲端同步。

這說明 Warp 的複雜度已經接近一個完整 IDE，而不是傳統意義上的輕量 terminal。

本地建置方式

README 給出的本地建置方式很簡潔：

1
2
3

./script/bootstrap
./script/run
./script/presubmit

其中：

./script/bootstrap：執行平台相關初始化。
./script/run：建置並執行 Warp。
./script/presubmit：執行格式化、clippy 和測試等提交前檢查。

WARP.md 裡還列出了更細的命令：

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

如果要給 Warp 提交程式碼，./script/presubmit 基本是必須跑的。

貢獻流程

Warp 的貢獻流程不是簡單「發 PR 就行」。

README 描述了一個從 issue 到 PR 的輕量流程：

先搜尋已有 issue。
沒有重複再提交 bug 或 feature request。
維護者會 review issue，並可能打上 readiness label。
ready-to-spec 表示設計可以被貢獻者展開成 spec。
ready-to-implement 表示設計已相對明確，可以開始寫程式碼 PR。
貢獻者可以認領帶標籤的 issue。

這個流程適合大型開源專案。它把「想法」「設計」「實作」拆開，減少貢獻者一上來就寫錯方向的風險。

對 AI agent 來說，這也很適合。agent 可以先整理 issue、寫 spec、補測試，再進入實作。Warp 自己也在用這種方式展示 agentic project management。

授權：MIT + AGPL v3

Warp 採用雙授權結構。

README 說明：

Warp UI framework，也就是 warpui_core 和 warpui crates，使用 MIT license。
倉庫其餘程式碼使用 AGPL v3。

這點很重要。AGPL v3 對網路服務和分發有更強的開源要求。如果你只是學習、研究、貢獻程式碼，問題不大；但如果想把 Warp 程式碼用於商業產品或閉源衍生專案，就必須認真讀 license，必要時諮詢法律意見。

簡單說，Warp 是開源了，但不是「隨便拿去閉源商用」的寬鬆授權。

值得關注的地方

第一，Warp 把終端、agent、專案管理放在一起。

很多 AI coding 工具仍然是 CLI 或編輯器外掛。Warp 試圖從終端入口出發，把 agent 任務、程式碼執行、命令輸出、PR 工作流和團隊協作整合起來。

第二，Warp 的開源方式很適合觀察 agent 工作流。

它不只是發布程式碼，還把貢獻概覽、agent session、issue triage 和 spec 流程公開出來。對於想研究 AI 如何參與開源協作的人，這個倉庫本身就是樣本。

第三，Warp 是一個複雜 Rust 桌面應用。

如果你想學習 Rust GUI、終端模擬器、跨平台應用、GraphQL client、雲端同步和 AI 整合，Warp 倉庫有不少可看的結構。但它不是小專案，新貢獻者需要先讀文件和 issue 流程。

第四，Warp 支援「自帶 agent」和「bring your own CLI agent」兩條線。

這點很現實。開發者不會只用一個 agent。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等工具會長期共存。Warp 如果能成為它們的工作台，就比單一終端更有價值。

適合誰關注

如果你是普通終端使用者，關注 Warp 的意義在於：終端可能正在從命令列工具變成 AI 工作台。

如果你是 AI coding agent 重度使用者，Warp 值得關注，因為它試圖管理多個 agent，而不是只做一個聊天入口。

如果你是開源維護者，可以關注 Oz for OSS 這條線。它試圖用 agent 做 issue triage、PR review、社群協作和貢獻者引導。

如果你是 Rust 開發者，Warp 是一個大型真實桌面應用樣本，可以研究它如何組織 UI、終端、雲端同步、AI 整合和跨平台程式碼。

如果你只是想找一個能馬上替代傳統終端的工具，建議先下載正式版使用，再決定是否研究源碼。直接從源碼建置更適合貢獻者和深度玩家。

簡短判斷

Warp 開源的重點，不只是「一個現代終端開源了」。

更準確地說，Warp 正在把終端升級成 agentic development environment：終端負責連接 shell、程式碼庫、命令執行、agent、issue、PR 和協作流程。

在 AI coding agent 持續增長的背景下，開發環境的入口可能會發生變化。過去是 IDE 統治開發體驗，終端負責命令執行；現在終端可能反過來成為 agent 協作的中心。Warp 這個倉庫，正是在探索這種可能性。

開源專案 on KnightLi的博客

Joplin：離線優先、支援同步和加密的開源筆記應用

Joplin 解決什麼問題

核心特性速查

離線優先是什麼意思

Markdown 與匯入能力

同步與加密

Web Clipper 與外掛

和 Obsidian 的區別

適合誰使用

使用建議

我的判斷

Jimmy：把 Evernote、Notion、Google Keep 等筆記匯出轉換成 Markdown

Jimmy 解決什麼問題

支援的筆記應用很多

也能轉換普通文件

兩種使用方式

它的幾個特點

適合誰使用

使用前的檢查建議

我的判斷

AI 自動用手機哪家強？MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use 對比

基本資訊對比

MobiAgent

Mobile-Agent

Mobilerun

mobile-use

功能對比

優缺點對比

適用範圍建議

我的判斷

mobile-use 看點：讓 AI 操作真實 App，還能提取資料

它和普通手機自動化有什麼不同

AndroidWorld 結果值得注意

資料抽取是實用入口

部署門檻和限制

適合誰關注

我的判斷

想讓 AI 自動點手機？Mobilerun 支援 Android 和 iOS

它解決什麼問題

本地框架和雲端服務

為什麼 LLM 無關很關鍵

適合哪些場景

我的判斷

AI 能自己點手機、用電腦了嗎？Mobile-Agent 專案解讀

它解決什麼問題

v3.5 的重點

GUI-Owl 是底層變化

ToolCUA 暗示的新方向

適合誰關注

我的判斷

MobiAgent 是什麼？一個能操作手機 App 的開源 AI 智能體

它解決什麼問題

最近更新值得關注

記憶系統是關鍵補丁

適合誰關注

我的判斷

GitHub AI 開源專案分類整理：從 Coding Agent 到 RAG 知識庫

分類合計

AI程式設計與 Coding Agent

Agent 技能與工作流

RAG、知識庫與記憶

多模態與內容創作

本地模型與推理

垂直應用與自動化

AI 應用開發基礎設施

PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析

它想解決什麼問題

PageIndex 的基本工作流

和傳統向量 RAG 的差異

本地怎麼跑

Agentic Vectorless RAG 示例

雲服務、MCP 和 API

適合哪些場景

需要注意什麼

小結

Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具

Open Design 是什麼

為什麼它和普通 AI 生成網頁不一樣

它支援哪些 Agent