AionUi：把多個 AI Agent 組成可遠端協作的開源 Cowork 工作台

查證結果

專案：AionUi
GitHub URL：https://github.com/iOfficeAI/AionUi
查證時間：2026-09-22 UTC
GitHub 星數：33,041
最近推送：2026-09-09
授權：Apache-2.0
主要語言：TypeScript
版本線索：根目錄 package.json 顯示版本 2.2.2，workspace 使用 packages/*。

以上數字來自 GitHub REST API；功能描述則以專案 README 與根目錄 package.json 交叉核對。README 內的行銷性敘述，例如支援的平台數量與「24/7」定位，本文會標示為專案宣稱，不把它們當成獨立效能測試結果。

文章大綱

為什麼 AionUi 不只是聊天介面
從單一 Agent 到多 Agent 工作台
MCP、檔案操作與文件產出的實作價值
WebUI、訊息平台與排程任務
如何快速試用，以及部署前的安全檢查
適合誰、不適合誰

完整文章

先說結論：它想解決的是「Agent 太分散」

很多 AI 工具各自很強，卻把使用者切成不同工作流：聊天工具在一個視窗，CLI Agent 在終端機，MCP 設定散落在不同檔案，遠端操作又要另外架服務。AionUi 的核心方向，是把這些 Agent 放進一個可以持續工作的 Cowork 工作台。

這個定位和單純的 Chat UI 不同。依照 README，AionUi 內建 Agent 可以讀寫檔案、搜尋網路、使用 MCP 工具、產生圖片，也能整合 Claude Code、Codex、Gemini CLI、Hermes Agent、OpenClaw 與其他 CLI Agent。這些能力未必代表每個整合在所有平台都同樣成熟，但產品設計的問題意識很清楚：使用者需要管理任務與權限，而不只是得到一段回答。

從一個對話框變成 Agent 工作台

AionUi 的第一個實作亮點，是同時保留內建 Agent 與外部 Agent。對剛開始使用的人，README 宣稱安裝後即可使用內建 Agent，不必先安裝其他 CLI；對已經有既有工具鏈的人，則可讓 AionUi 偵測並整合外部 Agent。這種設計降低了遷移成本，也讓它比較像控制面板，而不是另一個封閉模型客戶端。

從原始碼結構看，專案根目錄是以 TypeScript workspace 組織，桌面啟動、WebUI、測試、文件與多個 packages 分開管理。package.json 的 scripts 顯示它同時提供 Electron 開發流程、WebUI 啟動方式、打包腳本，以及 Vitest、Playwright 等測試入口。這些不是完整的架構文件，但足以確認它是一個有桌面應用與服務模式的實作型專案，而非單純的 prompt 或資源清單。

多 Agent 協作：重點不是「同時開很多分頁」

README 描述的 Team Mode 包含 Leader 與 Teammate：Leader 接收任務、拆分子任務，再透過內建 Team MCP Server 委派給其他 Agent；Teammate 可以平行執行，並透過非同步 mailbox 與共享 task board 回傳結果。這個模型值得注意，因為它把多 Agent 從 UI 層的多視窗，推進到任務協調層。

實務上，這種設計最有價值的地方不是「Agent 越多越好」，而是能否將工作拆成彼此邊界清楚的子任務。例如一個文件產製流程，可以讓一個 Agent 整理資料、一個 Agent 產生初稿，另一個 Agent 負責檢查格式；共享 workspace 則讓結果能回到同一個交付目錄。相對地，若任務無法拆分，平行 Agent 反而可能造成檔案衝突、重複工作與成本失控。

README 也提到每個 Agent 有自己的權限確認對話框，並在側欄顯示待核准操作。這是本地 Agent 產品很重要的 UX 細節：真正的自動化不是完全取消人類控制，而是把批准點放在可理解的位置。

MCP 與文件工作流，才是它的差異化來源

AionUi 把 MCP 視為統一管理的一部分，並依照各 Agent 的能力同步或注入相容的 transport。這讓 MCP 不再只是開發者在終端機手動維護的設定，而是可以在工作台中跟對話、權限與 Agent 選擇一起管理。

專案 README 還列出一組偏實務的內建助手與技能，例如 PPT、Word、Excel、PDF、Mermaid 與資料處理工作流。這些名稱本身不能證明每個輸出都達到生產環境品質，但它們反映了 AionUi 的目標使用情境：讓 Agent 直接處理檔案與交付物，而不只回答問題。對企業或個人工作者來說，能不能把結果落成可編輯的 .pptx、.docx、.xlsx 或 Markdown，往往比聊天回覆更接近真正的生產力。

WebUI、訊息平台與排程：從桌面程式延伸成服務

根目錄 scripts 提供 webui、webui:remote、webui:prod 等啟動入口；README 則描述可以透過瀏覽器、Telegram、Lark、DingTalk、WeChat 等方式遠端互動。這使 AionUi 不只是一個本機桌面應用，也可以被當作遠端 Agent 工作台。

另一個值得觀察的功能是排程任務。README 宣稱支援標準 cron、固定間隔與一次性觸發，並可以選擇沿用既有對話或每次建立新對話。這個設計適合報表彙整、檔案整理與定期提醒等工作；但「無人值守」不等於「不需要治理」。只要任務能讀寫檔案、呼叫外部服務或傳送訊息，就必須限制 workspace、API 權限、網路暴露範圍與失敗重試行為。

三步驟試用，先從低風險任務開始

專案 README 提供跨平台 Release 下載方式，也列出 macOS、Windows、Linux 的支援範圍；根目錄則提供 npm run dev、npm run webui 與測試腳本。第一次試用時，建議採用以下順序：

從 GitHub Releases 取得與作業系統相符的版本，或依專案文件建立開發環境。
只先配置一組權限受限的模型 API 金鑰，並使用專用測試資料夾。
先執行可回復的任務，例如整理副本、產生 Markdown 報告，再測試文件輸出與遠端連線。

若要開啟 WebUI 或訊息平台整合，請先確認監聽介面、身份驗證、反向代理與 TLS 設定。不要因為 README 寫著「遠端存取」就直接把服務暴露到公網；Agent 具備檔案與工具權限時，遠端入口就是高價值攻擊面。API 金鑰也不應寫入共享 workspace、聊天紀錄或截圖。

適合誰？

AionUi 適合已經開始使用多個 AI Agent，想把桌面、CLI、MCP 與文件工作流集中管理的人；也適合需要跨平台與遠端操作，又不想被單一模型供應商綁定的團隊。它最有潛力的場景，是「有明確交付物、可以拆成多個步驟、需要人工核准」的工作。

它不一定適合只想要簡單問答、或沒有能力管理本機檔案權限與遠端服務的使用者。多 Agent 會增加設定、觀測與成本複雜度；內建技能很多，也代表需要建立自己的使用規範，否則工作台最後可能只是另一個資訊分散的地方。

最後觀察：開源 Cowork 的競爭點在治理

AionUi 的價值不只在「支援多少模型」或「能開多少 Agent」，而在於它試圖把 Agent 的執行環境、檔案、權限、MCP、排程與交付格式放在同一個產品邊界內。這是從聊天工具走向工作系統的一步。

不過，這類產品的成熟度不能只看 GitHub 星數。真正值得持續追蹤的是：多 Agent 協作是否穩定、權限模型是否細緻、遠端入口是否安全、任務失敗後是否可觀測，以及文件輸出能否在真實工作流中節省時間。若你正在尋找一個可以把 Hermes Agent、Codex、Claude Code 等工具放在同一個介面裡實驗的開源專案，AionUi 是一個值得在隔離環境中試用的候選。

參考資料與查證連結

GitHub Repository：https://github.com/iOfficeAI/AionUi
GitHub REST API Repository Metadata：https://api.github.com/repos/iOfficeAI/AionUi
README（原始檔）：https://raw.githubusercontent.com/iOfficeAI/AionUi/main/readme.md
根目錄 package.json：https://raw.githubusercontent.com/iOfficeAI/AionUi/main/package.json
Releases：https://github.com/iOfficeAI/AionUi/releases

本文依 2026-09-22 UTC 可取得的公開資料撰寫；版本、星數與功能可能隨專案更新而變動。