1. 项目概述为什么UI-TARS桌面版的协作功能值得深挖最近在自动化测试和RPA机器人流程自动化的圈子里UI-TARS Desktop桌面版的热度持续攀升。很多朋友在搜索“手把手部署ui-tars”、“codex桌面版安装教程”核心诉求很明确想找一个能稳定运行在个人电脑或服务器上并且能方便地与他人协作的自动化工具。这正是UI-TARS桌面版相较于其云端版本或纯命令行版本的核心优势所在。它把强大的UI自动化能力封装成了一个带图形界面的本地应用而“协作功能”则是将这个本地应用的价值从个人效率工具升级为团队生产力平台的关键。简单来说UI-TARS桌面版的协作功能解决的痛点就是“任务孤岛”。你辛辛苦苦写了一个自动登录系统、自动填报报表或者自动监控网页的脚本在UI-TARS里通常称为“任务”或“流程”它可能只存在于你的电脑上。当同事需要执行类似操作或者你需要把任务部署到另一台机器上时传统方式就是复制脚本文件、重新配置环境繁琐且容易出错。而多用户自动化任务共享就是要打破这个壁垒实现“一次编写多处运行一人创建团队复用”。这不仅仅是文件共享那么简单。它涉及到任务资产脚本、配置、依赖库的集中管理、执行权限的分配、运行日志的集中查看以及最关键的在多用户、多终端环境下保持任务稳定运行的能力。我看到很多搜索词如“ubuntu多用户远程桌面”、“win11 解决多用户同时远程连接教程”这恰恰说明了用户在实际部署中遇到的真实场景如何在服务器上搭建一个环境让多个团队成员都能连接上去使用同一个UI-TARS桌面版实例来管理和运行任务。这正是本指南要深入拆解的核心。2. 核心思路拆解从单机到协同的架构演进要实现多用户共享我们不能简单地把UI-TARS桌面版当成一个普通的单机软件来用。需要从架构层面理解其协作模式。根据网络上的讨论和官方文档的蛛丝马迹UI-TARS桌面版的协作通常通过两种路径实现这也是很多“codex桌面版使用教程”里语焉不详的部分。2.1 路径一远程桌面模式下的共享会话这是最直观、门槛相对较低的方式对应搜索热词“win11 远程多用户”、“winserver2022设置多用户远程桌面服务”。其核心思路是将UI-TARS桌面版安装在一台性能较好的中央服务器可以是Windows Server、安装了桌面环境的Linux服务器如Ubuntu甚至是一台始终开机的PC并在这台服务器上配置支持多用户同时登录的远程桌面服务如Windows的RDS或Linux下的Xrdp、VNC等。为什么选择这种方式环境统一所有用户连接的都是同一个UI-TARS实例任务脚本、依赖的Python库、浏览器驱动版本完全一致彻底避免了“在我机器上能跑在你那就报错”的经典问题。资源集中自动化任务往往需要占用CPU、内存和网络资源。集中部署便于监控和管理资源消耗也方便对接公司内网的其他系统。数据安全任务脚本作为公司资产保留在中央服务器上避免了通过聊天工具传来传去导致版本混乱或泄露。这种模式的局限性并发限制受服务器硬件和远程桌面协议性能限制同时操作的用户数有限。操作冲突如果多个用户同时编辑同一个任务需要良好的版本管理习惯通常需要结合Git。网络依赖用户需要稳定的网络连接才能流畅操作。2.2 路径二客户端-服务器C/S架构下的任务调度这是一种更高级、更工程化的方式隐约体现在“ui-tars远程api调用”、“hermes agent 桌面版”等搜索词中。在这种架构下UI-TARS桌面版本身或其核心引擎作为“服务器端”在后台运行提供一套API可能是HTTP API、RPC或消息队列。用户则通过一个轻量级的“客户端”可能是Web界面、命令行工具CLI或另一个简化版的桌面程序来提交任务、查询状态、下载结果。为什么这是更优的长期方案职责分离用户客户端只关心业务逻辑创建、触发任务无需关心任务在哪个具体的桌面环境执行。服务器端负责资源调度、任务队列管理和稳定执行。高并发与弹性可以更容易地实现任务队列支持大量异步任务。甚至可以结合Docker等技术实现执行环境的动态创建与销毁。体验更佳客户端可以做得非常轻量响应迅速不受远程桌面延迟和卡顿的影响。实际部署中的混合形态在大多数中小团队的实际场景中往往是两种模式的结合。比如开发人员通过远程桌面连接到服务器使用UI-TARS桌面版的图形化界面进行任务的开发、调试和录制因为图形化操作更直观。然后将调试好的任务“发布”到某个中央任务库。其他非开发人员如运营、测试则通过一个简单的Web门户或脚本来触发这些已发布的任务执行。这个“中央任务库”和“执行引擎”可能就是运行在服务器后台的UI-TARS服务。理解了这两种核心思路我们接下来的步骤就有了明确的指导思想我们的目标是搭建一个支持多用户通过远程桌面进行任务开发同时具备任务集中存储和API调用能力的协作环境。3. 环境准备与部署打造稳定的协作基石这一步是后续所有操作的基础也是最容易踩坑的地方。很多“安装失败”、“启动报错”的问题都源于此。我们将以一台安装Ubuntu 22.04 LTS桌面版的服务器为例进行说明Windows Server的思路类似但具体操作不同。3.1 服务器系统准备与优化首先为什么选择Linux服务器从“ubuntu桌面版搭载服务器”、“麒麟v10桌面版”等搜索词可以看出Linux在服务器领域的稳定性和资源占用优势是公认的。对于UI自动化这种可能需要长时间运行、占用图形资源的应用一个轻量级的Linux桌面环境比Windows Server通常更具性价比。关键操作与原理系统安装安装Ubuntu 22.04时务必选择“Ubuntu Desktop”版本而非Server版。Server版默认没有图形界面后续需要额外安装更麻烦。用户管理为每个需要使用的团队成员创建独立的系统账户如user1,user2。这是多用户隔离的基础。使用sudo adduser username命令创建。注意强烈建议为UI-TARS的运行单独创建一个系统账户如uitars避免使用root或个人账户直接运行服务以提高安全性。远程桌面服务安装我们将使用Xrdp它是一个开源的RDP远程桌面协议服务器让用户能用Windows自带的远程桌面连接工具mstsc.exe访问Linux桌面。sudo apt update sudo apt install xrdp -y sudo systemctl enable xrdp sudo systemctl start xrdp安装后默认监听3389端口。请确保服务器防火墙放行该端口sudo ufw allow 3389。解决多用户同时登录问题默认的Ubuntu桌面环境GNOME对多用户远程会话支持不友好。我们需要切换到更轻量级、对多会话支持更好的桌面环境如Xfce或Xubuntu-desktop。sudo apt install xubuntu-desktop -y安装后编辑Xrdp的启动配置文件告诉它使用Xfce会话echo “xfce4-session” ~/.xsession # 将上面的配置复制到 /etc/xrdp/startwm.sh 的末尾在最后一行 ‘. /etc/X11/Xsession’ 之前 sudo nano /etc/xrdp/startwm.sh # 在文件末尾在 ‘. /etc/X11/Xsession’ 这一行之前添加一行 # xfce4-session重启xrdp服务sudo systemctl restart xrdp。图形驱动与虚拟显示对于无物理显示器的服务器如云服务器需要配置虚拟显示驱动否则UI自动化可能无法启动浏览器。安装xvfb(X Virtual Framebuffer)sudo apt install xvfb -y可以配置一个服务让系统启动时自动运行Xvfb创建一个虚拟显示器如:99。3.2 UI-TARS Desktop核心部署这是“codex桌面版安装”的核心步骤。假设我们已经下载好了UI-TARS Desktop的Linux安装包例如一个.AppImage文件或.deb包。部署最佳实践安装位置不要安装在个人用户目录下。建议安装在/opt目录下方便所有用户访问或通过共享方式访问。sudo mkdir -p /opt/uitars # 假设安装包是 uitars-desktop-linux.AppImage sudo cp uitars-desktop-linux.AppImage /opt/uitars/ sudo chmod x /opt/uitars/uitars-desktop-linux.AppImage依赖安装UI-TARS通常依赖Python、Node.js、Chromium浏览器等。在系统级别安装这些依赖确保所有用户环境一致。sudo apt install python3-pip chromium-browser -y # 安装可能需要的Python库如 selenium, playwright等具体看UI-TARS要求 sudo pip3 install selenium playwright sudo playwright install chromium以服务方式运行关键为了实现路径二C/S架构的能力我们需要让UI-TARS的核心服务在后台运行而不是依赖于某个用户的图形会话。这通常需要研究UI-TARS是否提供了“无头模式”或“服务模式”的启动参数。查找启动参数运行./uitars-desktop-linux.AppImage --help查看是否有--headless,--server,--port等参数。创建系统服务如果支持我们可以创建一个Systemd服务文件/etc/systemd/system/uitars-server.service[Unit] DescriptionUI-TARS Automation Server Afternetwork.target xvfb.service [Service] Typesimple Useruitars # 使用专门的用户运行 EnvironmentDISPLAY:99 # 指向虚拟显示器 ExecStart/opt/uitars/uitars-desktop-linux.AppImage --headless --server --port 8080 Restarton-failure RestartSec5 [Install] WantedBymulti-user.target然后启动并启用服务sudo systemctl daemon-reload sudo systemctl start uitars-server sudo systemctl enable uitars-server这样UI-TARS的核心服务就在后台启动并监听8080端口假设提供API。3.3 共享存储空间配置任务脚本、配置文件、数据文件需要在用户间共享。最简单的方式是使用一个共享目录并设置合适的权限。创建共享目录sudo mkdir -p /shared/uitars-projects sudo chown -R uitars:uitars /shared/uitars-projects # 所有者设为uitars用户 sudo chmod -R 775 /shared/uitars-projects # 允许同组用户读写将用户加入共享组将需要协作的用户如user1, user2都加入到uitars组。sudo usermod -a -G uitars user1 sudo usermod -a -G uitars user2用户需要重新登录或开启新会话才能使组权限生效。在UI-TARS中设置默认项目路径每个用户通过远程桌面登录后首次打开UI-TARS桌面版时将其项目工作区指向/shared/uitars-projects。这样所有人创建的任务都保存在同一个地方。4. 5步实现多用户任务共享实操环境就绪后我们进入核心的五个步骤。这五步是一个从基础到进阶的完整工作流。4.1 第一步用户接入与权限初始化团队成员使用Windows“远程桌面连接”输入服务器IP地址使用各自的系统账号user1, user2登录。成功登录后会看到一个独立的Xfce桌面环境。首次登录后的必须操作打开终端验证共享目录权限ls -la /shared/uitars-projects应该可以看到目录属于uitars组并且自己有读写权限。启动UI-TARS桌面版。通常可以通过在终端进入安装目录执行./uitars-desktop-linux.AppImage或者如果已创建桌面快捷方式则直接点击。在UI-TARS中设置工作区或项目根目录为/shared/uitars-projects/你的名字或直接使用根目录。建议每人建立自己的子文件夹便于管理例如/shared/uitars-projects/user1_scripts。实操心得建议为所有团队成员准备一份简单的“入门检查清单”包含上述步骤和服务器连接信息。很多协作失败始于第一步的环境不一致。4.2 第二步标准化任务开发与版本控制在共享目录中开发任务时必须引入最基本的版本管理规范否则很快就会陷入混乱。项目结构标准化约定一个通用的项目结构。例如/shared/uitars-projects/ ├── common/ # 公共模块如登录函数、工具类 │ ├── login.py │ └── utils.py ├── project_a/ # 项目A │ ├── main.flow # UI-TARS任务流文件 │ ├── config.json # 配置文件 │ └── README.md └── project_b/ # 项目B └── ...初始化Git仓库在/shared/uitars-projects目录下执行git init。虽然是在共享文件夹但Git能完美记录每个人的更改解决冲突。cd /shared/uitars-projects git init git add . git commit -m “初始提交”使用.gitignore创建.gitignore文件忽略临时文件、日志、截图等不需要版本控制的文件例如*.log,screenshots/,tmp/。开发流程每个成员在开发新功能或修复bug时应创建新的分支git checkout -b feature-xxx完成后合并回主分支git merge。UI-TARS的任务文件可能是JSON、YAML或特定格式是文本文件完全可以用Git进行版本对比和合并。4.3 第三步任务资产集中管理与复用这是协作的核心价值。避免重复造轮子。创建公共组件库在UI-TARS中通常支持将一段通用的操作序列如“登录OA系统”、“导出Excel”保存为“组件”、“模块”或“子流程”。鼓励团队成员将验证稳定的流程片段保存到共享目录的common/components文件夹下。参数化配置将任务中可能变化的部分如URL、用户名、文件路径提取为参数或外部配置文件如config.json。这样同一个任务脚本不同用户通过传入不同的配置文件就能执行不同的业务。例如一个数据抓取任务其目标网站和存储数据库的配置就可以外置。文档化在每个任务或组件的目录下强制要求一个简短的README.md说明其功能、输入参数、输出结果、依赖环境。这能极大降低其他成员的学习成本。4.4 第四步通过API实现任务调度与触发进阶当任务开发并测试完成后就可以将其“服务化”供其他系统或非技术人员调用。这对应“ui-tars远程api调用”的需求。确认API模式启动我们之前配置的UI-TARS后台服务如果支持。假设服务运行在http://服务器IP:8080。探索API端点通过访问http://服务器IP:8080/docs或http://服务器IP:8080/api如果提供查看Swagger UI或API文档。常见的API可能包括POST /api/tasks/run传入任务ID或任务文件路径触发执行。GET /api/tasks/status/{task_id}查询任务执行状态。GET /api/tasks/log/{task_id}获取任务执行日志。编写调用客户端你可以用任何语言Python、Node.js、Shell编写一个简单的客户端脚本。以下是一个Python示例import requests import json server_url “http://your-server-ip:8080” task_payload { “project_path”: “/shared/uitars-projects/project_a”, “main_flow”: “main.flow”, “parameters”: {“url”: “https://example.com”, “headless”: True} } response requests.post(f“{server_url}/api/tasks/run”, jsontask_payload) if response.status_code 200: task_info response.json() task_id task_info[‘task_id’] print(f“任务已提交ID: {task_id}”) # 可以轮询查询状态 else: print(“任务提交失败:”, response.text)集成到其他系统将这个客户端脚本集成到你的运维平台、监控系统、CI/CD流水线如Jenkins或甚至是一个简单的内部网页按钮上。这样业务人员只需点击按钮就能触发后台复杂的UI自动化任务。4.5 第五步监控、日志与错误处理闭环协作环境下的任务执行必须有统一的监控和排错手段。集中日志收集配置UI-TARS服务将任务日志统一输出到指定文件如/var/log/uitars/tasks.log并配置日志轮转logrotate。确保日志文件对所有协作用户可读。执行状态看板如果UI-TARS服务未提供状态看板可以自己实现一个简单的。通过定时调用GET /api/tasksAPI获取所有任务状态用Flask等框架快速搭建一个状态监控网页显示任务列表、当前状态运行中、成功、失败、开始时间、耗时等。失败告警机制在调用API的客户端脚本中增加对失败状态的判断。一旦检测到任务失败立即通过邮件、钉钉、企业微信等Webhook发送告警信息附上任务ID和日志片段。截图与录像归档UI自动化失败时截图和操作录像是宝贵的排错资料。在任务配置中开启失败自动截图功能并将截图文件保存在共享目录下以任务ID和时间戳命名的文件夹中。定期归档清理。5. 常见问题与深度排错指南在实际部署和运行中你一定会遇到下面这些问题。这里是我踩过坑后总结的解决方案。5.1 远程桌面连接成功但UI-TARS无法启动或白屏现象用户通过远程桌面登录后双击UI-TARS图标程序无法启动或启动后主窗口空白对应“claude code桌面版打开窗口空白”。排查思路检查图形环境在远程桌面的终端里运行echo $DISPLAY。正常应该显示类似:10.0或:100.0。如果为空或不对可能是Xrdp配置问题。尝试在终端里直接执行DISPLAY:xx.0 ./uitars-desktop-linux.AppImage其中xx是$DISPLAY的值来启动。检查依赖库UI-TARS的桌面版可能依赖特定的图形库如GTK、Qt。尝试安装通用图形库sudo apt install libgtk-3-0 libnotify4 libnss3 libxss1 libxtst6 xdg-utils -y查看应用日志尝试从终端启动观察终端输出的错误信息。通常会有动态链接库.so缺失的明确提示。虚拟显示缓冲如果是在无显示器的服务器上确保Xvfb服务已启动并且UI-TARS的启动环境变量DISPLAY指向了正确的虚拟显示器如:99。5.2 多用户同时操作时任务执行冲突现象用户A和用户B同时运行了操作同一个网站的任务导致登录态混乱、页面元素互相干扰。解决方案浏览器实例隔离这是根本解决方法。确保UI-TARS的每个任务启动时都使用独立的、干净的浏览器用户数据目录User Data Dir。在任务配置或代码中为每个任务或每次运行动态指定一个唯一的临时目录。Playwright/Puppeteer示例import tempfile user_data_dir tempfile.mkdtemp(prefix“chrome_profile_”) browser await playwright.chromium.launch_persistent_context(user_data_dir, headlessFalse)Selenium示例通过ChromeOptions的--user-data-dir参数指定。任务队列化对于操作同一关键资源如同一个后台管理系统的任务不要允许并发执行。可以在服务器端实现一个简单的任务队列例如使用Redis的List结构任务触发后先进入队列由单个消费者顺序执行。使用无头模式在调度执行的服务器端任务尽量以无头模式运行减少图形资源冲突也避免多个远程桌面会话对浏览器窗口的争抢。5.3 任务在服务器端后台运行时无法操作浏览器现象通过API调用的任务在后台服务中执行失败日志提示无法启动浏览器或找不到元素。排查与解决确保浏览器可执行在服务器上确保chromium-browser或google-chrome-stable已安装且位于系统PATH中。可以通过which chromium-browser确认。解决无头环境依赖无头服务器通常缺少一些浏览器运行所需的库。安装以下包sudo apt install -y wget ca-certificates fonts-liberation libasound2 libatk-bridge2.0-0 \ libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 \ libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 \ libstdc6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 \ libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release \ xdg-utils虚拟显示缓冲区Xvfb这是最关键的一步。浏览器即使是无头模式有时也需要一个显示环境。确保Xvfb服务已启动并在启动UI-TARS服务或任务脚本前设置DISPLAY:99环境变量。# 启动Xvfb在:99显示端口深度24屏幕尺寸1920x1080 Xvfb :99 -screen 0 1920x1080x24 export DISPLAY:99 # 然后再启动你的任务脚本或UI-TARS服务浏览器驱动匹配确保使用的chromedriver或playwright的浏览器版本与系统安装的Chrome/Chromium版本兼容。不匹配是导致启动失败的常见原因。5.4 权限问题导致文件读写失败现象用户A创建的任务用户B无法读取或执行通过API触发的任务无法写入共享目录。解决方案遵循Linux权限原则如前所述使用共享组uitars并设置目录权限为775文件权限为664。确保所有协作用户都在该组内。SetGID位对于共享目录/shared/uitars-projects可以设置SetGID位这样在该目录下创建的任何新文件其所属组都会自动继承目录的组uitars。sudo chmod gs /shared/uitars-projectsAPI服务用户运行UI-TARS后台服务的用户如uitars必须对共享目录有读写权限。并且通过API创建的文件其所有者是uitars需要确保其他组用户也能读写通过775/664权限实现。小心umask用户的umask设置会影响新创建文件的默认权限。可以在共享目录下创建一个.bashrc或全局配置文件为相关用户设置宽松的umask例如umask 0002对应文件权限664目录权限775。5.5 性能瓶颈与优化建议当用户和任务数量增多后可能会遇到性能问题。服务器资源监控使用htop,nvidia-smi如果有GPU监控CPU、内存、GPU使用情况。UI自动化尤其是非无头模式非常消耗内存和CPU。限制并发任务数在UI-TARS服务端或任务调度器中设置最大并发任务数。例如限制同时运行的浏览器实例不超过5个防止服务器过载。使用轻量级方案尽可能使用无头模式无头模式比图形模式节省大量资源。复用浏览器上下文对于一系列短任务可以考虑启动一个浏览器实例在其下创建多个独立的“上下文”来执行不同任务而不是为每个任务都完全启动和关闭一个浏览器进程。Playwright和Puppeteer支持此功能。优化选择器低效的页面元素选择器如复杂的XPath会显著增加脚本执行时间。尽量使用稳定的ID、CSS选择器。考虑分布式执行如果单台服务器成为瓶颈可以考虑引入简单的分布式架构。例如搭建多个UI-TARS执行节点Worker由一个中心调度器Master通过消息队列如Redis, RabbitMQ分发任务。这对应了更高级的“hermes agent”这类架构的探索方向。部署和运维一个稳定的多用户UI-TARS协作环境就像搭建一个小型的基础设施。它不仅仅是安装软件更是对权限、流程、监控和排错体系的构建。从简单的远程桌面共享到通过API实现自动化调度每一步都解决了团队协作中的具体痛点。最深的体会是标准化和文档化是协作能否持续下去的关键。再好的工具没有约定俗成的使用规范最终也会变得混乱不堪。建议在团队内推行一个简单的“任务开发模板”和“提交检查清单”这能省去未来大量的沟通和维护成本。当一切就绪后你会发现自动化不再是某个人的“黑魔法”而真正成为了整个团队触手可及的生产力。