Cua 开源仓库开发指南跨语言 Monorepo 的组件地图、工具链与协作规范【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cuaCuaComputer Use Agent是一个覆盖 Rust、Python、TypeScript、Swift 与 Docker 镜像的多语言 Monorepo。根目录下的 Development.md 是贡献者的第一站入口文档它不重复每个组件的细节而是提供一份组件地图 通用环境 质量门禁 发布流程的总览指引你顺着链接进入对应组件的开发文档。读完本篇你将掌握如何按组件选择工具链、搭建可复现的开发环境、运行根级格式检查、理解 cua-driver 的分层验证模型并搞清楚版本发布与产物落地的完整链路。一、定位为什么 Monorepo 需要一份入口地图Cua 仓库变化很快目录结构只是定位辅助而不是包注册表。根目录的 Development.md 明确声明了自身边界每个组件拥有自己的详细构建、测试与开发说明根文档只负责先在这里再跟着离你要改的代码最近的指南走。这种设计背后是对 Monorepo 规模的务实回应仓库内含多个语言生态Rust/Cargo、Python/uv、TypeScript/pnpm、Swift/SPM、Docker没有任何一条根命令能证明所有包、桌面驱动、虚拟机与镜像都正确。TESTING.md 同样强调先跑你改动组件所拥有的测试把 CI workflow 当作可执行的测试权威来源。根文档因此只承担导航与通用规范职责。二、组件地图先选组件再进组件文档Development.md 的第一张表是全仓库的组件索引下面按当前仓库实际路径做了整理与扩展区域主要路径工具链从这里开始cua-driverlibs/cua-driver/rust、libs/cua-driver/pythonRust、平台 SDK、Linux 用 Nixlibs/cua-driver/README.md、libs/cua-driver/rust/README.mdPython SDK 与服务libs/python、libs/cua-benchPython 3.12 uv各包的pyproject.toml与 READMETypeScript SDKlibs/typescriptNode.js pnpmlibs/typescript/README.md 及package.jsonscriptsCuaBotlibs/cuabotNode.js pnpmlibs/cuabot/README.mdLumelibs/lumeSwift、Xcode 命令行工具libs/lume/Development.md沙箱与容器镜像libs/kasm、libs/lumier、libs/qemu-docker、libs/xfceDocker 组件工具链组件内 README 或 Development 文件公开文档docs/content/docsNode.js pnpm Fumadocsdocs/README.md示例samples依示例而定示例旁的 README几个要点cua-driver 是仓库的核心桌面驱动它通过 MCP over stdio 与 Agent 通信可驱动原生 macOS 应用而不抢占焦点。其 Rust 工作区由cua-driver主 CLI/MCP 守护进程与集成测试、cua-driver-core共享协议、工具模型、配置与 CDP 辅助、platform-macos/platform-windows/platform-linux按cfg(target_os)选中的平台 crate等组成具体列表见 libs/cua-driver/rust/README.md。根 uv workspace 只包含声明在 pyproject.toml 中的成员即libs/python/agent、core、computer、computer-server、som、mcp-server、bench-ui。libs/python下其他目录是独立包必须使用它们自己的pyproject.toml和 CI workflow。根 Node 包只安装仓库级 Prettier见 package.json 的prettier:check/prettier:format脚本。libs/typescript、libs/cuabot、docs各自的依赖要在各自目录内执行pnpm install。三、通用环境搭建按组件最小化安装工具链克隆并进入仓库git clone https://github.com/trycua/cua.git cd cuaDevelopment.md 的原则是只安装你组件需要的工具链不要全量装齐工作类型必需工具Python 包Python 3.12 与 uvTypeScript、CuaBot 或文档组件声明的 Node.js 版本与 pnpm 版本cua-driverRust 目标 OS SDKLinux 可复现链路用 NixLumemacOS、Swift 与 Xcode 命令行工具镜像Docker 或组件文档指定的镜像构建器从根 pyproject.toml 可以看到环境约束的细节requires-python 3.14,3.12即 Python 版本锁定在 3.12dev 依赖组[dependency-groups].dev包含 cua 各核心包、black、isort、mypy、ruff、pre-commit 等。关于 API 密钥文档有一条明确的红线普通构建与确定性测试不需要任何 API key。只有显式调用外部提供商的测试或示例才需要添加凭据且严禁提交进仓库。四、根级格式化门禁pre-commit 与 Prettier 检查4.1 安装根级开发工具与 Git Hooksuv sync --group dev uv run pre-commit install对全仓库执行所有已配置的钩子uv run pre-commit run --all-files4.2 当前钩子清单与源码对照从根目录的 .pre-commit-config.yaml 可以确认当前生效的钩子与 Development.md 的描述完全一致Prettierv3.0.0 mirrorprettier3.6.2覆盖ts/tsx/js/jsx/json/md/mdx/yaml/yml文件TypeScript workspace typecheck本地钩子pnpm -C libs/typescript typecheck只针对libs/typescript下改动isort7.0.0--profile black与black25.9.0Python 格式化ruffv0.14.1--fixPython 静态检查。注意mypy 虽然在 pyproject.toml 中配置为 strict 模式strict true、disallow_untyped_defs true但在 pre-commit 中因untyped codebase被临时禁用注释清晰说明了这一点它不是 pre-commit 的门禁。4.3 只读的仓库级格式检查如果你不想触发写操作可以执行pnpm install --frozen-lockfile pnpm prettier:checkRust、TypeScript、Swift 与文档的组件级检查仍由各组件自己的指南负责测试地图见 TESTING.md。五、cua-driver 开发三层验证模型cua-driver 的验证体系是整个仓库最讲究的部分Development.md 将其明确划分为三层Rust 单元与协议测试不需要目标 GUI 应用。例如cargo test -p cua-driver-core与cargo test -p cua-driver --test protocol_mcp_test默认应保持 headless、对 CI 安全。源码构建的 Harness E2E 测试在真实用户桌面会话中驱动 Electron、Tauri 与原生工具包的 fixture 应用。这些 Rust harness 是桌面行为的权威来源source of truthPython 测试不会重复这套矩阵。已安装应用的可选检查runner 声明其为 canonicalmacOS 计算器/文本编辑行还是 optionalLibreOffice。从 TESTING.md 还能看到更细的 E2E 入口Linux X11/session: scripts/ci/linux/run-rust-e2e.sh Linux Sway: scripts/ci/linux/run-rust-e2e-wayland.sh Linux nested: scripts/ci/linux/run-rust-e2e-inject.sh Linux GNOME/KDE: scripts/ci/linux/run-rust-e2e-desktop.sh gnome|kde Linux real Xorg: scripts/ci/linux/run-rust-e2e-desktop.sh xorg Windows: .\scripts\ci\windows\run-rust-e2e.ps1 -RequireGui macOS: scripts/ci/macos/run-rust-e2e.sh会话前提非常关键Windows桌面测试需要真实用户会话活动的控制台或 RDP 会话macOS需要已登录会话且进程获得辅助功能Accessibility与屏幕录制Screen Recording权限——macOS 的 TCC 授权绑定的是有责任的应用身份而非裸可执行路径托管 Linux Sway 与嵌套合成器 runner会创建受控会话GNOME、KDE 与真实 Xorg 验证则依赖已有的图形登录。从 libs/cua-driver/README.md 可以进一步了解驱动支持standard默认、无提示、bounded仅放行已审清单中的工具与资源、unrestricted需--dangerously-bypass-approvals三种权限模式模式在进程启动时固定运行中更改需重启守护进程。六、文档贡献Fumadocs 与 Diataxis 四分法公开文档基于 Fumadocs 构建遵循 Diataxis 体系文档命令统一在docs目录下执行详见 docs/README.mdtutorials教读者完成第一次成功how-to guides解决一个具体任务concepts解释约束与设计reference陈述命令、契约、支持范围与限制。一个重要的协作约定仅面向贡献者的实现笔记应保留在组件旁如libs/cua-driver/docs/下的 repo-local spec而不是进入公开文档导航。这样公开站点只呈现面向用户的内容。文档质量验证命令来自 docs/README.mdpnpm install --frozen-lockfile pnpm docs:check-hygiene pnpm docs:check-links pnpm build生成式 reference 变更还需运行属主组件检查pnpm docs:check:cua-driver或pnpm docs:check:lume而pnpm docs:check是显式的完整审计。七、发布机制CD: Bump Version 工作流发布由维护者通过 .github/workflows/release-bump-version.yml 触发。从工作流源码看机制要点如下service输入即发布目标注册表覆盖pypi/*cua、agent、auto、bench、bench-ui、cli、computer、computer-server、cloud、core、mcp-server、sandbox-apps、som、train、npm/*cli、computer、core、fleet、playground、cuabot与docker/*cuabot、kasm、xfce-cua、xfce、lumier、qemu-android、qemu-linux、qemu-windows。bump_type可选patch/minor/majortarget_branch默认main。授权门禁工作流第一 job 只允许f-trycua、r33drichards或cua-release-bot[bot]触发否则直接失败。一次只 bump 一个目标每个包的.bumpversion.cfg、Cargo manifest 或包 manifest 各自持有版本号与 tag 格式工作流在 bump 前会检查 tag 是否存在发布 tag 不可变随后运行bump2version并把生成的 tag 通过 GitHub App token 推送到目标分支。发布由 tag 触发的 CD 工作流完成工作流末尾的注释写明tag push 会自动触发对应的cd-py-*.yml、cd-ts-*.yml、cd-swift-lume.yml等发布流程无需在此手动调用。这也与 .github/workflows 中大量的cd-*与ci-*文件相互印证。根目录 Makefile 只提供本地版本检查与 dry-run 辅助例如make show-versions、make dry-run-patch-core不发布生产版本其注释明确说明版本 bump 由 GitHub Actions 管理。八、产物与本地文件纪律不要提交构建产物、暂存的 harness 二进制、本地 VM 工件、凭据、权限数据库以及编辑器专属状态。只有当某个产物稳定成为 fixture、示例或受维护的文档时才应提升进版本控制。从仓库结构看这一纪律已有实际落地evidence/下保存了 Lume Metal 能力 shim 的可复现实验证据含 SHA256SUMS、results.csv、metadata.mddocs/public/examples、samples/与tests/fixtures/则承载稳定的示例与 fixture——这正是产物稳定后才入库的实践体现。九、快速上手指南从零开始一次贡献综合以上所有环节一次规范贡献的路径可以概括为定位组件在组件地图中找到目标区域进入该组件 README最小环境按需安装 Python 3.12 uv、Node pnpm、Rust 或 Docker不装多余工具链装好门禁uv sync --group dev uv run pre-commit install开发与自测跑组件拥有的确定性测试Python 用 pytest、TS 用 Vitest/typecheck、Rust 用 cargo test、Lume 用swift test涉及桌面行为时跑 E2Ecua-driver 相关改动走 Rust harness 矩阵注意 Windows/macOS 对真实会话与权限的硬性要求提交前过全量检查uv run pre-commit run --all-files与pnpm prettier:check并按需运行docs:check-*保留证据跑不了的测试要如实记录原因不能靠删减用例换取绿灯。这套流程把多语言 Monorepo 的协作复杂度收敛为入口导航 组件自包含 分层验证三个可执行原则正是 Development.md 想传达的核心工程理念。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cua 开源仓库开发指南跨语言 Monorepo 的组件地图、工具链与协作规范【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cuaCuaComputer Use Agent是一个覆盖 Rust、Python、TypeScript、Swift 与 Docker 镜像的多语言 Monorepo。根目录下的 Development.md 是贡献者的第一站入口文档它不重复每个组件的细节而是提供一份组件地图 通用环境 质量门禁 发布流程的总览指引你顺着链接进入对应组件的开发文档。读完本篇你将掌握如何按组件选择工具链、搭建可复现的开发环境、运行根级格式检查、理解 cua-driver 的分层验证模型并搞清楚版本发布与产物落地的完整链路。一、定位为什么 Monorepo 需要一份入口地图Cua 仓库变化很快目录结构只是定位辅助而不是包注册表。根目录的 Development.md 明确声明了自身边界每个组件拥有自己的详细构建、测试与开发说明根文档只负责先在这里再跟着离你要改的代码最近的指南走。这种设计背后是对 Monorepo 规模的务实回应仓库内含多个语言生态Rust/Cargo、Python/uv、TypeScript/pnpm、Swift/SPM、Docker没有任何一条根命令能证明所有包、桌面驱动、虚拟机与镜像都正确。TESTING.md 同样强调先跑你改动组件所拥有的测试把 CI workflow 当作可执行的测试权威来源。根文档因此只承担导航与通用规范职责。二、组件地图先选组件再进组件文档Development.md 的第一张表是全仓库的组件索引下面按当前仓库实际路径做了整理与扩展区域主要路径工具链从这里开始cua-driverlibs/cua-driver/rust、libs/cua-driver/pythonRust、平台 SDK、Linux 用 Nixlibs/cua-driver/README.md、libs/cua-driver/rust/README.mdPython SDK 与服务libs/python、libs/cua-benchPython 3.12 uv各包的pyproject.toml与 READMETypeScript SDKlibs/typescriptNode.js pnpmlibs/typescript/README.md 及package.jsonscriptsCuaBotlibs/cuabotNode.js pnpmlibs/cuabot/README.mdLumelibs/lumeSwift、Xcode 命令行工具libs/lume/Development.md沙箱与容器镜像libs/kasm、libs/lumier、libs/qemu-docker、libs/xfceDocker 组件工具链组件内 README 或 Development 文件公开文档docs/content/docsNode.js pnpm Fumadocsdocs/README.md示例samples依示例而定示例旁的 README几个要点cua-driver 是仓库的核心桌面驱动它通过 MCP over stdio 与 Agent 通信可驱动原生 macOS 应用而不抢占焦点。其 Rust 工作区由cua-driver主 CLI/MCP 守护进程与集成测试、cua-driver-core共享协议、工具模型、配置与 CDP 辅助、platform-macos/platform-windows/platform-linux按cfg(target_os)选中的平台 crate等组成具体列表见 libs/cua-driver/rust/README.md。根 uv workspace 只包含声明在 pyproject.toml 中的成员即libs/python/agent、core、computer、computer-server、som、mcp-server、bench-ui。libs/python下其他目录是独立包必须使用它们自己的pyproject.toml和 CI workflow。根 Node 包只安装仓库级 Prettier见 package.json 的prettier:check/prettier:format脚本。libs/typescript、libs/cuabot、docs各自的依赖要在各自目录内执行pnpm install。三、通用环境搭建按组件最小化安装工具链克隆并进入仓库git clone https://github.com/trycua/cua.git cd cuaDevelopment.md 的原则是只安装你组件需要的工具链不要全量装齐工作类型必需工具Python 包Python 3.12 与 uvTypeScript、CuaBot 或文档组件声明的 Node.js 版本与 pnpm 版本cua-driverRust 目标 OS SDKLinux 可复现链路用 NixLumemacOS、Swift 与 Xcode 命令行工具镜像Docker 或组件文档指定的镜像构建器从根 pyproject.toml 可以看到环境约束的细节requires-python 3.14,3.12即 Python 版本锁定在 3.12dev 依赖组[dependency-groups].dev包含 cua 各核心包、black、isort、mypy、ruff、pre-commit 等。关于 API 密钥文档有一条明确的红线普通构建与确定性测试不需要任何 API key。只有显式调用外部提供商的测试或示例才需要添加凭据且严禁提交进仓库。四、根级格式化门禁pre-commit 与 Prettier 检查4.1 安装根级开发工具与 Git Hooksuv sync --group dev uv run pre-commit install对全仓库执行所有已配置的钩子uv run pre-commit run --all-files4.2 当前钩子清单与源码对照从根目录的 .pre-commit-config.yaml 可以确认当前生效的钩子与 Development.md 的描述完全一致Prettierv3.0.0 mirrorprettier3.6.2覆盖ts/tsx/js/jsx/json/md/mdx/yaml/yml文件TypeScript workspace typecheck本地钩子pnpm -C libs/typescript typecheck只针对libs/typescript下改动isort7.0.0--profile black与black25.9.0Python 格式化ruffv0.14.1--fixPython 静态检查。注意mypy 虽然在 pyproject.toml 中配置为 strict 模式strict true、disallow_untyped_defs true但在 pre-commit 中因untyped codebase被临时禁用注释清晰说明了这一点它不是 pre-commit 的门禁。4.3 只读的仓库级格式检查如果你不想触发写操作可以执行pnpm install --frozen-lockfile pnpm prettier:checkRust、TypeScript、Swift 与文档的组件级检查仍由各组件自己的指南负责测试地图见 TESTING.md。五、cua-driver 开发三层验证模型cua-driver 的验证体系是整个仓库最讲究的部分Development.md 将其明确划分为三层Rust 单元与协议测试不需要目标 GUI 应用。例如cargo test -p cua-driver-core与cargo test -p cua-driver --test protocol_mcp_test默认应保持 headless、对 CI 安全。源码构建的 Harness E2E 测试在真实用户桌面会话中驱动 Electron、Tauri 与原生工具包的 fixture 应用。这些 Rust harness 是桌面行为的权威来源source of truthPython 测试不会重复这套矩阵。已安装应用的可选检查runner 声明其为 canonicalmacOS 计算器/文本编辑行还是 optionalLibreOffice。从 TESTING.md 还能看到更细的 E2E 入口Linux X11/session: scripts/ci/linux/run-rust-e2e.sh Linux Sway: scripts/ci/linux/run-rust-e2e-wayland.sh Linux nested: scripts/ci/linux/run-rust-e2e-inject.sh Linux GNOME/KDE: scripts/ci/linux/run-rust-e2e-desktop.sh gnome|kde Linux real Xorg: scripts/ci/linux/run-rust-e2e-desktop.sh xorg Windows: .\scripts\ci\windows\run-rust-e2e.ps1 -RequireGui macOS: scripts/ci/macos/run-rust-e2e.sh会话前提非常关键Windows桌面测试需要真实用户会话活动的控制台或 RDP 会话macOS需要已登录会话且进程获得辅助功能Accessibility与屏幕录制Screen Recording权限——macOS 的 TCC 授权绑定的是有责任的应用身份而非裸可执行路径托管 Linux Sway 与嵌套合成器 runner会创建受控会话GNOME、KDE 与真实 Xorg 验证则依赖已有的图形登录。从 libs/cua-driver/README.md 可以进一步了解驱动支持standard默认、无提示、bounded仅放行已审清单中的工具与资源、unrestricted需--dangerously-bypass-approvals三种权限模式模式在进程启动时固定运行中更改需重启守护进程。六、文档贡献Fumadocs 与 Diataxis 四分法公开文档基于 Fumadocs 构建遵循 Diataxis 体系文档命令统一在docs目录下执行详见 docs/README.mdtutorials教读者完成第一次成功how-to guides解决一个具体任务concepts解释约束与设计reference陈述命令、契约、支持范围与限制。一个重要的协作约定仅面向贡献者的实现笔记应保留在组件旁如libs/cua-driver/docs/下的 repo-local spec而不是进入公开文档导航。这样公开站点只呈现面向用户的内容。文档质量验证命令来自 docs/README.mdpnpm install --frozen-lockfile pnpm docs:check-hygiene pnpm docs:check-links pnpm build生成式 reference 变更还需运行属主组件检查pnpm docs:check:cua-driver或pnpm docs:check:lume而pnpm docs:check是显式的完整审计。七、发布机制CD: Bump Version 工作流发布由维护者通过 .github/workflows/release-bump-version.yml 触发。从工作流源码看机制要点如下service输入即发布目标注册表覆盖pypi/*cua、agent、auto、bench、bench-ui、cli、computer、computer-server、cloud、core、mcp-server、sandbox-apps、som、train、npm/*cli、computer、core、fleet、playground、cuabot与docker/*cuabot、kasm、xfce-cua、xfce、lumier、qemu-android、qemu-linux、qemu-windows。bump_type可选patch/minor/majortarget_branch默认main。授权门禁工作流第一 job 只允许f-trycua、r33drichards或cua-release-bot[bot]触发否则直接失败。一次只 bump 一个目标每个包的.bumpversion.cfg、Cargo manifest 或包 manifest 各自持有版本号与 tag 格式工作流在 bump 前会检查 tag 是否存在发布 tag 不可变随后运行bump2version并把生成的 tag 通过 GitHub App token 推送到目标分支。发布由 tag 触发的 CD 工作流完成工作流末尾的注释写明tag push 会自动触发对应的cd-py-*.yml、cd-ts-*.yml、cd-swift-lume.yml等发布流程无需在此手动调用。这也与 .github/workflows 中大量的cd-*与ci-*文件相互印证。根目录 Makefile 只提供本地版本检查与 dry-run 辅助例如make show-versions、make dry-run-patch-core不发布生产版本其注释明确说明版本 bump 由 GitHub Actions 管理。八、产物与本地文件纪律不要提交构建产物、暂存的 harness 二进制、本地 VM 工件、凭据、权限数据库以及编辑器专属状态。只有当某个产物稳定成为 fixture、示例或受维护的文档时才应提升进版本控制。从仓库结构看这一纪律已有实际落地evidence/下保存了 Lume Metal 能力 shim 的可复现实验证据含 SHA256SUMS、results.csv、metadata.mddocs/public/examples、samples/与tests/fixtures/则承载稳定的示例与 fixture——这正是产物稳定后才入库的实践体现。九、快速上手指南从零开始一次贡献综合以上所有环节一次规范贡献的路径可以概括为定位组件在组件地图中找到目标区域进入该组件 README最小环境按需安装 Python 3.12 uv、Node pnpm、Rust 或 Docker不装多余工具链装好门禁uv sync --group dev uv run pre-commit install开发与自测跑组件拥有的确定性测试Python 用 pytest、TS 用 Vitest/typecheck、Rust 用 cargo test、Lume 用swift test涉及桌面行为时跑 E2Ecua-driver 相关改动走 Rust harness 矩阵注意 Windows/macOS 对真实会话与权限的硬性要求提交前过全量检查uv run pre-commit run --all-files与pnpm prettier:check并按需运行docs:check-*保留证据跑不了的测试要如实记录原因不能靠删减用例换取绿灯。这套流程把多语言 Monorepo 的协作复杂度收敛为入口导航 组件自包含 分层验证三个可执行原则正是 Development.md 想传达的核心工程理念。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
