企业官网建设流程全解析

一文厘清 UI-TARS-desktop 项目中 UI TARS Desktop 与 Agent TARS App：定位、架构、模型与选型指南

【免费下载链接】UI-TARS-desktopThe Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS-desktop

UI TARS Desktop 与 Agent TARS App 是 UI-TARS-desktop（TARS）多模态 AI Agent 技术栈中两条容易混淆的产品线：前者是专为「GUI 桌面自动化」设计的原生桌面客户端，后者则是面向「浏览器与研究类长任务」的通用 Agent 应用。本文以项目内的官方对比博客 difference-between-ui-tars-desktop-and-agent-tars-app.md 为骨架，结合仓库源码与配置逐一拆解二者的本质差异、底层实现与互补关系，帮你按任务类型、平台与模型约束做出正确的下载与选型决策。

背景：为什么同一项目下会有两款容易混淆的应用

在 README.md 开篇的引言中，TARS 被定义为「一套多模态 AI Agent 技术栈（Multimodal AI Agent stack）」，并明确说明该仓库当前同时交付两个项目：Agent TARS与UI-TARS-desktop。二者共用同一技术底座与开源生态，名字都带「TARS」，却服务于差异很大的任务形态：

• UI-TARS Desktop是一个桌面应用，基于 UI-TARS 视觉语言模型提供原生 GUI Agent 体验，官方以本地（local）与远程（remote）的 Computer / Browser Operator 为主要交付形态；
• Agent TARS是通用多模态 AI Agent 栈，将 GUI Agent 与视觉能力带入终端、浏览器、文件系统与你的产品中，主要交付 CLI 与 Web UI（以及早期的桌面 App 预览版）。

社区反馈显示，大量用户因为名字相近而误下载、误配置。官方博客专门为此撰写了澄清说明，其动机原文明确指出：UI TARS Desktop 与 Agent TARS App 的混淆源于文档对两者角色阐释不清，本文将精确还原官方结论，再补上源码级证据。

需要说明：关联博客成文时 UI TARS Desktop 处于 v0.0.8 时代。当前仓库内 apps/ui-tars/package.json 的版本号已迭代到0.2.4，Desktop 也随之加入了 Browser Operator 等能力。阅读本文时请把「博客描述的快照」与「仓库当前实现」区分看待，二者的核心差异定位并未改变。

先看结论：两张表看懂核心差异

官方博客速览表

仓库当前实现对照

UI TARS Desktop：为 GUI 桌面自动化而生的客户端

定位与本质

UI TARS Desktop唯一的使命就是作为 GUI Agent 执行任务：你输入一句自然语言指令，它通过视觉理解屏幕上的界面，输出点击、输入、滚动、按键等 GUI 动作序列，代替人类操作电脑。它本质上是 UI-TARS 视觉语言模型的官方桌面客户端——README.md 的表述是「基于 UI-TARS 模型的、提供原生 GUI Agent 的桌面应用」。

也因此，官方将 GUI Agent 定义为一种以界面视觉为核心理解对象的智能体范式（原始博客引用 arXiv 论文 2411.18279 给出该术语的学术出处）：模型并不依赖可访问性树或坐标注入，而是直接「看懂」屏幕截图，这与后面要讲的 Agent TARS 的通用工具编排路线有本质区别。

版本、平台与运行前提

• 支持平台：Mac 与 Windows（博客成文时点）。
• 安装方式：Mac 上拖拽安装并需在「系统设置 → 隐私与安全性」中授予**辅助功能（Accessibility）与屏幕录制（Screen Recording）**权限；Windows 直接运行安装包。详细步骤见仓库内 docs/quick-start.md。
• 使用前提：进行 GUI 桌面控制需要本地权限配合；若要使用其 Browser Operator 模式，需要预先安装 Chrome、Edge 或 Firefox 之一（docs/quick-start.md 中明确标注）。

模型兼容性：只认 UI-TARS 系的「动作协议」

博客特别强调 UI TARS Desktop模型兼容性仅限 UI-TARS 模型。这不是产品限制，而是架构使然：Desktop 依赖 UI-TARS 系 VLM 输出专有的 GUI 动作格式，再由项目内的动作解析链路解释执行。

从 apps/ui-tars/package.json 的依赖可以清楚看到这条技术链：

@ui-tars/action-parser —— 解析 UI-TARS 模型输出的 GUI 动作 @ui-tars/electron-ipc —— Electron 主进程与渲染进程的动作通道 @ui-tars/operator-nut-js —— 桌面级输入控制（Computer Operator 的执行层） @ui-tars/operator-browser —— 浏览器自动化执行层（Browser Operator） @ui-tars/sdk / @ui-tars/shared / @ui-tars/utio —— SDK、共享工具与可观测上报

其中@ui-tars/operator-nut-js表明 Computer Operator 的底层基于 nut.js 这套跨平台桌面自动化方案实现鼠标键盘与系统级操作；而@ui-tars/action-parser则负责把 VLM 返回的文本动作翻译成可执行指令。也就是说，换掉动作协议等价于换掉模型，这正是 Desktop 无法轻易接入任意第三方模型的原因。

对应的模型接入方式在 docs/quick-start.md「Get model and run local operator」一节中有完整实操示例，典型配置如下（以 Hugging Face 托管 UI-TARS-1.5 为例）：

Language: en VLM Provider: Hugging Face for UI-TARS-1.5 VLM Base URL: https:xxx VLM API KEY: your_api_key VLM Model Name: xxx

VolcEngine 上的豆包系模型同样走 UI-TARS 协议：

Language: cn VLM Provider: VolcEngine Ark for Doubao-1.5-UI-TARS VLM Base URL: https://ark.cn-beijing.volces.com/api/v3 VLM API KEY: YOUR_API_KEY VLM Model Name: doubao-1.5-ui-tars-250328

官方同时给出两条硬性注意事项（原文以 [!NOTE] 标注，同样适用于其他兼容端点）：

1. Provider 必须选择对应的 UI-TARS 专用项，否则 VLM 动作解析可能失效；
2. Hugging Face 端点的 Base URL 必须以/v1/结尾，模型名以端点页面展示为准。

此外，UI TARS Desktop 除本地运行外还提供远程（Remote）Operator形态。README News 显示 v0.2.0 引入了 Remote Computer Operator 与 Remote Browser Operator。不过 docs/quick-start.md 也声明：官方远程 Operator 服务已于 2025-08-20 停止试用，需要自托管时可参考火山引擎（VolcEngine）的 Computer Use Agent / Browser Use Agent 部署入口自行搭建。

适用场景小结

UI TARS Desktop 擅长的是系统级 GUI 自动化：操作桌面软件、打开并填写应用、跨窗口完成业务流程等「人类直接面对屏幕」的任务。它的回答方式是「动手做」，而不是「搜索+写报告」。若追求稳定与即装即用，还应留意官方在 docs/quick-start.md 中的提示：当前仅支持单显示器场景，多显示器配置可能导致部分任务失败。

Agent TARS App：面向浏览器与研究任务的通用 Agent

定位与本质

Agent TARS App 于 UI TARS Desktop 之后发布（见同目录下的发布公告博客 announcing-agent-tars-app.md）。它的定位从「专用 GUI 执行器」转向了「通用多模态 AI Agent」：利用 Agent 框架完成任务规划（task planning）与执行（execution），并借助 MCP 生态串联浏览器、搜索、文件、命令行等真实世界工具，最终整合信息产出结论。

换句话说，UI TARS Desktop 回答的是「怎么点」，Agent TARS App 回答的是「先去搜什么、看完得出结论、把结果写成文件」。

版本、平台与模型

• 平台：博客成文时 Agent TARS App仅支持 Mac，Windows 支持计划在后续 beta 版本中提供，且欢迎社区贡献。
• 模型：官方在 [!IMPORTANT] 提示块中特别强调，Agent TARS 当时不支持 UI-TARS 模型，Claude 是其临时最佳选择；关于模型支持的最新进展以项目 GitHub Discussion #377 线程为准。配套的发布公告页 announcing-agent-tars-app.md 亦有相近表述：规划链路基于 Claude 测试，OpenAI 支持尚不稳定并欢迎社区共建。

核心能力拆解（来自发布公告与配置源码）

根据 announcing-agent-tars-app.md，Agent TARS App 的核心体验可归纳为四块：

1. Agentic Workflow Orchestration：通过 Agent 框架编排「搜索 → 浏览 → 逐链接探索 → 信息综合」的长链路任务，并以 Event Stream 与前端 UI 实时同步过程；
2. Comprehensive Tool Support：面向 Deep Research、Operator 类任务执行复杂浏览器操作，同时基于 Model Context Protocol（MCP）接入 search、文件编辑、CLI、编码等大量工具；
3. Real-time Artifact：以流式界面实时展示浏览器、文档等多模态产物，是用户观察 Agent 过程并与之交互的重要入口；
4. Human in the Loop：任务运行过程中可随时通过顶部输入框插入新的思考指令，中途改变 Agent 的工作方向。

使用前需要在设置页完成Model Provider / API Key与Search Provider / API Key两组配置（Azure OpenAI 还可额外配置apiVersion、deploymentName、endpoint）。线程分享支持两种模式：Local Html把整条线程打包成可离线分发的 HTML 文件；Remote Server Url则向用户指定的远端服务器以POST+multipart/form-data上传 HTML bundle，并从返回体的data.url字段取得可分享链接。

从源码看 Agent TARS 的能力构成

当前仓库中的 multimodal/agent-tars/core 完整承载了 Agent TARS 的核心逻辑，是理解其与 Desktop 差异的最佳证据：

• Agent 基座是通用 MCP Agent：核心类AgentTARS直接继承自@tarko/mcp-agent的MCPAgent（见 agent-tars.ts），并通过环境向父类注入 MCP 服务注册表（environment.getMCPServerRegistry()）。这解释了为什么 Agent TARS 不依赖 UI-TARS 的专有动作协议——它走的是「通用模型规划 + MCP 工具执行」路线。
• 能力被组织为多个 Environment：environments/local 下分别有 browser（含浏览器控制策略、导航 / 内容 / 截图 / 状态等工具集）、filesystem（文件系统工具管理）与 search（搜索工具）三组执行环境；另提供aioSandbox全隔离执行环境选项。
• 浏览器控制策略是分层可选的：在 browser-control-strategies 目录中可看到browser-visual-grounding-strategy（视觉定位）、browser-hybrid-strategy（混合）与browser-dom-strategy（DOM）三种策略。值得注意的是，构造时调用的validateBrowserControlMode(options.model?.provider, ...)（见 agent-tars.ts）会根据模型 Provider校验并调整浏览器控制模式——从源码结构看，这正体现了「不同模型在视觉落点能力上差异显著」这一 Agent TARS 生态的既有认知。
• WebUI 配置体现任务形态：默认 Web UI 配置 webui-config.ts 中的欢迎卡片按Research、AI Browser、CodeAct、MCP等分类组织示例任务（例如调研股票、查询网站备案、修复 Git 报错、绘制图表等），与「研究 + 浏览器 + 代码 + MCP 工具」的通用 Agent 定位一一对应；该配置还暴露了 GUI Agent 子配置（如截图渲染策略）与调试用的 Event Stream 查看器开关。
• CLI 交付并存：除桌面 App 外，multimodal/agent-tars/cli 以agent-tars为 bin 提供命令行交付形态（cli/package.json），说明 Agent TARS 是「CLI + Web UI + App」多形态的整套 Agent 栈。

适用场景小结

Agent TARS App 适合长链条、研究型、浏览器密集型任务：深度资料调研、竞品分析、多来源信息交叉验证、页面级操作配合命令行的复合工作流。它在执行中不断产出可回放的过程记录与结构化产物，而不是单纯替用户点几下屏幕。

一图看懂互补关系：怎么选？

官方博客的总结可浓缩为一句话：UI TARS Desktop 用于系统级 GUI 自动化（本地/远程操作你的电脑），Agent TARS 聚焦浏览器与研究工作流。二者并非升级替代关系，而是互补的两条产品线，选择时可以按三个维度快速决策：

几点选型提醒：

1. 看模型再下载：如果你手头已部署/购买了 UI-TARS 系模型的端点（Hugging Face、VolcEngine 或自部署），请务必选择 UI TARS Desktop；Agent TARS 并不消费 UI-TARS 模型的专用动作输出。
2. 看平台再下载：Agent TARS 桌面形态发布初期仅 Mac；Desktop 则同时覆盖 Mac 与 Windows。
3. 看任务再下载：短平快的「替我点一下」类任务属于 Desktop 的主场；「帮我写一份关于 X 的深度报告并保存到本地」则是 Agent TARS 的主场。
4. 关注版本演进：仓库迭代速度较快（Desktop 已从 v0.0.8 演进至 0.2.4，能力边界持续扩展），官方博客文末也预告会持续统一与增强两款应用的功能。正式选型前建议以 README.md 的 News 栏目与各 Release 说明为准。

常见误区 FAQ

Q1：Agent TARS 是不是 UI TARS Desktop 的新版本？不是。Agent TARS 是一个独立定位的通用 Agent 产品线，与 Desktop 并行存在于同一仓库，从首版起就定位为浏览器/研究型任务 Agent。

Q2：我能在 Agent TARS 里跑 UI-TARS 模型吗？在当时（博客成文时间点）不可以——官方明确说明 Agent TARS 不支持 UI-TARS 模型，Claude 是临时最佳选项；而 UI-TARS 系模型恰好只能被 Desktop 充分发挥动作解析能力。

Q3：Desktop 能换成 Claude 来驱动吗？不可以直接替换。Desktop 的 GUI 动作依赖 UI-TARS 系模型输出的专有协议，需要action-parser链路配合（见 apps/ui-tars/package.json 依赖），换用其他模型会破坏动作解析，这也是它在 Provider 配置上强制限定 UI-TARS 专用项的原因。

Q4：两个都要装吗？如果你的工作流既包含桌面 GUI 自动化、又包含深度浏览器调研，那么它们可以各司其职、互补使用——这正是官方所称「unique purposes and target different scenarios」的完整含义。

延伸阅读

• 官方对比博客原文：difference-between-ui-tars-desktop-and-agent-tars-app.md
• Agent TARS 发布公告（功能与配置详解）：announcing-agent-tars-app.md
• 项目总览与两条产品线定义：README.md
• UI TARS Desktop 安装与模型接入步骤：docs/quick-start.md
• UI TARS Desktop 设置项说明：docs/setting.md
• UI TARS SDK 说明（构建 GUI 自动化 Agent 的跨平台工具链）：docs/sdk.md
• Agent TARS 核心实现（MCPAgent 基座与环境注册）：agent-tars.ts
• Agent TARS 浏览器控制策略与 WebUI 配置：multimodal/agent-tars/core/src/environments/local/browser/browser-control-strategies、webui-config.ts

【免费下载链接】UI-TARS-desktopThe Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS-desktop