Cua 開源：給 AI 代理一台真實電腦

Cua 是 trycua 團隊開源的電腦操作代理基礎設施，把 macOS、Linux 與 Windows 的桌面交給 AI 代理使用。專案於二零二六年十一月初累積三萬一千六百六十四顆星標、二千三百四十七次分叉與一百五十五名貢獻者，核心以 Rust 撰寫，授權採 MIT 與 FSL 雙軌並行。

這個專案的名稱帶著一點自嘲意味。Cua 是 Computer-Use Agent 的縮寫，也是西班牙語中「洞穴」的意思，而在加泰隆尼亞語中，它指向巢穴。README 開頭只寫一句話：給 AI 代理一些它們能用的電腦。這句短句背後是一整套基礎設施，從虛擬機、沙盒、驅動程式到評估框架。

Cua 是什麼？

Cua 是一套讓 AI 代理操作真實電腦的開源基礎設施，包含桌面應用、本機虛擬機管理器、跨平台驅動程式、沙盒 SDK 與評估框架，核心以 Rust 撰寫，主體採 MIT 授權。

專案於二零二五年一月三十一日建立，至今不到兩年，已經推出三十個標籤版本的規模。它並非單一工具，而是把電腦操作代理所需的每個環節拆成獨立組件，再以統一的命令列與 SDK 串接。

這個設計取向與市場上多數方案相反。常見做法是把瀏覽器自動化、截圖辨識與模型推理包成一個黑箱產品，使用者只拿到結果。Cua 選擇把每一層都開放出來，讓開發者自行替換模型、替換執行環境、替換評估方式。

Cua 的四個組件如何分工？

四者分工明確：Cua Spaces 提供桌面環境，Lume 管理本機虛擬機，Cua Driver 操作原生應用，Cua Bench 建立任務並評估表現，彼此可獨立使用。

Cua Spaces 是給人看的入口。它是一款 macOS 桌面應用，把每個虛擬桌面包成一個 Space，常駐在選單列與瀏海，使用者可以即時看到代理正在做什麼，必要時接手操作。

Lume 處理底層虛擬化。它利用蘋果的 Virtualization.Framework，在 Apple Silicon 機器上建立 macOS 與 Linux 虛擬機，不依賴 Docker，也不依賴第三方虛擬化層。

Cua Driver 是代理的手。它以命令列、MCP 伺服器與型別化 SDK 三種形式暴露能力，讓代理檢視並操作 macOS、Windows、Linux 上的原生應用與瀏覽器。

Cua Bench 則是裁判。它讓使用者建立任務、執行參考解答、驗證評估器是否回報正確分數，並匯出軌跡用於訓練。

Cua Spaces 如何把桌面變成代理的工作台？

每個 Space 是一台在本機建立的 macOS 虛擬機，或一個 Linux 映像。它們跑在使用者自己的 Mac、其他自有電腦，或自己的雲端帳戶上，並以選單列即時顯示狀態。

README 列出三項核心能力。第一項是 Teleport，把已登入的 Chrome 或 Slack 搬進 Space，搬進去之後仍保持登入狀態，工作階段存在加密的本機 Keyvault 中，只有使用者批准後才會送達 Space。

第二項是多人協作。使用者與代理共用同一個桌面，各自擁有游標，人可以隨時介入做選擇，然後把桌面交還給代理。這種設計把「人在迴路」從抽象原則變成具體的互動方式。

第三項是代理就緒映像。Space 啟動時已內建 cua-spacesd 常駐程式，代理立即取得行程、檔案、截圖與輸入控制，不需要額外安裝代理層。

這些能力有明確的平台邊界。完整體驗要求 macOS 26 或以上，Linux 與 Windows 版本以 Tauri 建構的共享核心提供，功能覆蓋仍在推進。

Lume 為何要自行實作虛擬機管理？

因為代理需要乾淨、可重置的桌面。Lume 直接呼叫蘋果虛擬化框架，在 Apple Silicon 上建立 macOS 與 Linux 虛擬機，避免依賴 Docker 或雲端服務。

虛擬機是這類系統的關鍵環節。代理在桌面上的操作可能刪錯檔案、改錯設定，甚至被頁面內容誘導執行危險動作。每次任務前重置環境，是最直接的防護手段。

Lume 的取捨在於平台綁定。它只支援 Apple Silicon，換來的是接近原生的效能與較低的記憶體開銷。官方文件同時提供 lumier，以 Docker 相容介面包裝 Lume 虛擬機，方便既有容器流程接入。

沙盒與虛擬機為何分成兩條路線？

沙盒輕量、啟動快，適合大量並行任務；虛擬機隔離徹底，適合需要完整桌面或敏感憑證的工作。兩者以同一個 SDK 介面操作，可依任務性質選擇。

SDK 把兩者統一在同一個抽象層。建立沙盒只需數行指令，執行環境在首次使用時自動配置，之後可以執行命令、截圖、清除。

程式碼層面同樣簡潔。Python 版本以非同步上下文管理器包裝，進入時建立沙盒，離開時自動清除，適合寫成測試或批次任務。

值得留意的是沙盒本身不含代理層。SDK 只提供執行環境，代理迴圈由使用者自己的框架驅動，這種切割讓同一套環境可以配合不同的代理實作。

Teleport 與多人協作解決什麼實際問題？

兩者處理登入狀態與交接成本。Teleport 讓已登入的應用連同工作階段一起搬進虛擬桌面，多人協作則讓人在代理卡住時直接接手，不必重建環境。

登入狀態是自動化流程的長期痛點。多數自動化工具在全新環境中遇到雙重驗證就停下，需要人工補上驗證碼或授權。把已登入的瀏覽器搬進虛擬機，等於繞過了整段重新驗證的流程。

這種做法也帶來新的風險面。憑證在虛擬機內可用，意味著代理在同一環境中理論上也能取用。專案以 Keyvault 與逐次批准作為對應，實際防護效果取決於使用者是否維持嚴格設定。

多人協作的價值在除錯。代理執行長流程時，人可以看到每一步的畫面，發現方向錯誤就即時接手，避免等到任務結束才發現整段白跑。

CUA-S1 這批小模型在做什麼？

CUA-S1 是專為介面決策設計的小型模型系列，以快速、有界的判斷取代逐字生成，例如決定某個欄位該填什麼值，或某個元件是否應該略過。

專案把 System 1 當作工程比喻，指快速而範圍有限的決策，與通用代理的規劃推理分開處理。這種切分符合實際執行流程：長流程需要規劃，單一步驟只需要判斷。

第一個研究檔名為 CUA-S1-FORMS，專注表單填寫。它對結構化介面元素與文件數值評分，再由應用程式碼排序動作，最後交給 Cua Driver 執行，每個動作都有明確邊界。

模型權重放在 Hugging Face，程式碼與資料生成流程留在儲存庫，原始碼採 MIT 授權。README 明言這是早期研究釋出，模型與資料集的適用範圍需各自查閱卡片說明。

Cua Bench 如何評估代理能力？

它以任務為單位建立評測：先寫出參考解答，再讓評估器驗證結果是否達到預期分數，最後匯出執行軌跡，可用於比較不同代理或作為訓練資料。

入門門檻刻意壓低。官方建議從不需要虛擬機、Docker 或模型金鑰的模擬任務開始，安裝只需 Python 3.12 或 3.13 與套件管理工具，再補上瀏覽器執行檔。

評估器是這套框架的核心設計。它要求每個任務都有可驗證的成功條件，避免出現「看起來完成」卻無法確認的結果。這對比多數代理示範只展示錄影、不提供量化分數，差別明顯。

Cua 的授權條款有什麼需要留意？

主體程式碼採 MIT，但 Cua Spaces 與 Cua Driver Bench 使用 FSL-1.1-MIT，禁止提供競爭性託管服務，每個版本發佈兩年後自動轉為 MIT 授權。

這種雙軌安排對商業使用者有實際影響。自行使用、修改、內部部署都不受限制，但若打算把 Spaces 包成對外服務販售，就需要另外取得商業授權。

第三方元件的授權更複雜。可選的 cua-som 套件採 AGPL-3.0，其 Ultralytics 依賴另有條款；cua-perception 擴充結合 OmniParser 模型與其他元件，README 明確警告重新散布或在網路提供服務可能觸發 AGPL 的源碼義務。

專案同時列出已棄用的套件。其中 cuabot 被標註為不要執行，理由是存在已知安全問題，使用者應停止並卸載，改用 Cua Driver 或新的命令列工具。

Cua 的商業模式與定價如何運作？

Cua Spaces 對個人免費，Pro 每月十八美元，Teams 每人每月三十美元，最低一席起。收費落在桌面應用與團隊協作，SDK、驅動程式與評估框架維持開源。

這個分層策略把商業價值放在體驗層。開源部分解決技術整合，付費部分解決同步、託管與團隊管理，兩者共用同一套底層能力。

對個人開發者而言，免費層已經足夠完成大部分實驗。對需要多台機器、多人共用桌面或雲端帳戶整合的團隊，付費層的價值主要來自省下的維運時間。

Cua 與其他電腦操作代理有何差別？

差別在開放程度與環境所有權。多數同類方案把執行環境放在供應商雲端，Cua 允許跑在自己的機器、自己的雲端帳戶，並開放每一層供替換。

環境所有權直接影響成本結構。雲端沙盒按分鐘計費，長流程任務的成本會快速累積；在本機執行虛擬機，邊際成本接近零，代價是硬體與維護。

第二個差別是整合面。Cua Driver 以 MCP 伺服器形式發布，可直接接進 Claude Code、Codex、Cursor 等編碼助理，也可以接進其他支援同一協定的代理框架。

第三個差別在評估。專案把基準測試當作獨立產品維護，並開放軌跡匯出，這種安排讓社群的比較結果具備可重現的基礎。

安裝與試用需要什麼條件？

macOS 使用者可執行官方安裝腳本，需 macOS 26 或以上；其他平台可安裝命令列工具與驅動程式。虛擬機功能僅限 Apple Silicon 機型。

安裝腳本會先說明產品內容，再讓使用者選擇是否一併安裝桌面應用與驅動程式。命令列工具一律安裝，登入流程會詢問是否自動配置編碼助理。

Windows 使用者透過 PowerShell 取得驅動程式，Linux 使用者使用 shell 腳本。文件同時提供連接自架代理的方式，包含 Claude Code、Codex、Cursor 與其他框架的設定步驟。

若只需要評估能力，可以先安裝 Cua Bench 並執行模擬任務，這條路徑不需要虛擬機，也不需要模型金鑰，是驗證整條流程最快的入口。

現階段有什麼限制？

限制包括完整功能綁定 macOS 26、虛擬機僅支援 Apple Silicon、未結問題超過一千四百個、部分套件已棄用且存在安全問題，以及授權條款需逐目錄確認。

專案規模帶來相應的維護壓力。一千四百多個未結問題對應三十個版本標籤，說明功能推進速度快於問題收斂速度，使用前宜先查閱對應版本的已知問題。

平台支援的落差也需計入規劃。Linux 與 Windows 目前以共享核心提供桌面應用，部分能力仍在補齊，跨平台團隊在評估時應以實際測試結果為準。

授權審查同樣不能省略。README 逐項列出哪些目錄屬於 MIT、哪些屬於 FSL、哪些第三方元件帶有 AGPL 義務，企業採用前需要法務逐條核對，而不是只看儲存庫首頁顯示的授權標籤。

Cua 的社群與數據表現如何？

截至二零二六年十一月三日，專案累積三萬一千六百六十四顆星、二千三百四十七次分叉、一百五十五名貢獻者，並在當日連續發布多個版本，活躍度處於高位。

發佈節奏值得注意。十一月三日當天，專案連續推出桌面應用 0.19.4、SDK 0.10.1、0.20.0 測試版與每日建置，這種密度通常出現在有專職團隊與自動化流程的專案上。

語言組成反映架構取向。Rust 佔最大比重，TypeScript、Python 與 Swift 依次跟隨，這個組合對應核心、前端、SDK 與原生桌面四個層次。

常見問題有哪些？

以下四題處理最常見的疑問，包括是否必須使用官方雲端、Windows 與 Linux 的支援程度、模型是否只能用 CUA-S1，以及企業內部部署的授權邊界。

出處連結有哪些？

本文資訊整理自 Cua 的 GitHub 儲存庫、README、十一月三日的版本發佈記錄與官方文件站，數據截至二零二六年十一月三日，全部可公開查閱。

• GitHub 儲存庫：https://github.com/trycua/cua
• 官方網站：https://cua.ai
• 文件站：https://cua.ai/docs
• Cua Spaces 定價：https://cua.ai/pricing
• 授權說明：https://github.com/trycua/cua/blob/main/legal/LICENSING.md

總結：Cua 適合什麼團隊？

適合想把代理跑在自己硬體、需要完整桌面環境，並願意投入整合工作的團隊。若只需要瀏覽器層級的自動化，或要求開箱即用，現階段的學習曲線偏高。

這個專案值得記錄的地方，在於它把電腦操作代理的每個難題攤開處理。環境要能重置、憑證要能隔離、操作要能觀察、成果要能評分，這些需求通常散落在不同工具裡，Cua 把它們收進同一個儲存庫。

三萬一千顆星與不到兩年的開發節奏，說明市場對這類基礎設施確有需求。是否適合長期採用，取決於團隊願意投入多少整合成本，以及對平台綁定與授權條款的接受程度，而不是取決於功能清單的長度。