TARS：字节跳动在赌一个怎样的桌面 Agent 未来？

字节跳动的 TARS（原 UI-TARS-desktop）不是另一个 Claude Computer Use 克隆。33K stars、四层架构、多模型支持、完全开源——它在桌面 Agent 赛道上选了一条跟 Anthropic 完全不同的路。

事情是这样的。

我花了一整天翻完了 TARS（原 UI-TARS-desktop）的全部核心源码，3174 个文件，从 Electron 桌面应用到 MCPAgent 内核到 Operator 层，全部过了一遍。

读完之后最直接的感受是：这个项目的架构设计比我想象的成熟太多了。不是实验室 demo，不是大厂放出来试水的空壳子——它在桌面 Agent 这条路上的选择，跟 Anthropic 的 Computer Use 和 Nous Research 的 Hermes Agent 形成了三种截然不同的路线。

而且，三种路线指向的是三个完全不同的未来。

它是怎么来的

先捋一下时间线。

2025 年 1 月，字节跳动的 Seed 团队在 GitHub 上开源了一个项目，叫 UI-TARS-desktop。当时的定位很明确：让模型直接操控桌面——看屏幕截图，理解界面，然后用鼠标键盘操作。

当时同步发的还有一篇论文（arXiv 2501.12326），标题叫 UI-TARS: Pioneering Automated GUI Interaction with Native Agents。说直白点，就是教模型怎么「看屏幕」和「用手」。

2025 年 4 月，v0.1.0 发布。有了第一个正式的 Desktop App，UI-TARS-1.5 模型也随之放出，在 OSWorld、ScreenSpot 等基准上刷了一波榜。

6 月是一个关键节点。Agent TARS Beta 发布——不再是单纯的 GUI Agent，而是多模态 Agent 栈，带着 CLI、Web UI，支持 MCP 协议。也是这个月，Remote Operator（远程计算机/浏览器操控）上线，完全免费。

11 月，v0.3.0，引入了 Event Stream Viewer、Streaming 支持、AIO Sandbox。

然后到了 2026 年 4 月，项目正式统一品牌——不再叫 UI-TARS-desktop，而是叫 TARS，两条产品线并行：Agent TARS（通用 CLI/Web Agent）和 UI-TARS Desktop（桌面原生 GUI Agent）。

到今天，GitHub Stars 33.3k，Forks 3.3k。

光看这个节奏，你大概能理解——这不是一个「突然冒出来」的项目，是一个持续迭代了一年多的产品。

它在赌什么

好，说正题。

TARS 在赌的，是一个完全开源、不绑定任何厂商模型、多入口（CLI + Desktop App + Web UI + SDK）的多模态桌面 Agent 平台。

我画了一张它的架构图，大概能让你一眼看懂这个赌注有多大：

四层。从用户入口到 Agent 核心到 MCP Server 到 Operator，每层都有清晰的职责边界。

最上面是用户入口层。你有四种方式用这个东西：

1. Desktop App（Electron）—— 普通用户最直接的方式，装上就能用
2. Agent TARS CLI（npx @agent-tars/cli@latest）—— 开发者一行命令起一个 Agent
3. Web UI —— 浏览器里的 Agent 界面
4. SDK（Python + JS）—— 集成到自己的产品里

四套入口，对应四类用户群体，覆盖从普通用户到开发者到企业的全链路。

这不是一个「给 API 去造」的东西，也不是一个「只给开发者用」的东西。字节把门槛降到了普通用户也能用，但没牺牲扩展性。

第二层是 Agent 核心。基于 @tarko/mcp-agent 框架构建的 MCPAgent，以 MCP 协议作为内核通信标准。Planner 实现了 ReAct 循环（参考了 Thinking Machines 那篇论文），Tool Registry 支持自动发现 + 手动注册两种模式，Event Stream 协议驱动了整个上下文工程。

第三层是内置 MCP Server。四个原生 Server：Browser（Playwright CDP）、Filesystem、Commands、Search。覆盖 Agent 最常见的能力。而且支持挂载任意第三方 MCP Server。

最下面是 Operator 层。这是它跟其他 Agent 框架最大的区别——它有真正的「手」。Computer Operator（xdotool / AppleScript / Powershell 跨平台）、Browser Operator（Playwright CDP）、ADB Operator（Android 设备），还有一个 AIO Sandbox 做安全隔离。

字节赌的不是模型能力，而是架构。

Claude Computer Use 赌的是「模型本身能理解桌面」。Hermes Agent 赌的是「Agent 和你一起编码」。而 TARS 赌的是「一套开放、可扩展、多入口的 Agent 基础设施」——你甚至可以用 Claude 的模型来驱动它。

跟其他两条路线比

我把三个项目摆在一起做了个对比表：

如果从表上看还不过瘾——说三组我翻完源码后的直接感受。

第一，TARS 是国内唯一的桌面 Agent 入口。 这不是夸张。Anthropic 的 Computer Use 依赖 Claude API，在国内不稳定。OpenAI Operator 也是。其他开源的 Agent 项目要么只做编码（像 Hermes Agent），要么只做对话。TARS 是目前唯一一个同时满足：完全开源、国内可访问、有桌面 App、能本地部署、支持多模型的方案。

第二，产品完整度上 TARS 吊打，但可靠性上还不确定。 四套入口 + 双 Operator + SDK —— 这个产品完整度是真的高。但 GUI Agent 的可靠性还没被大规模验证。Claude Computer Use 经过 Anthropic 大量后训练调优，在桌面操控场景下的成功率是有保障的。TARS 依赖 UI-TARS-1.5/2 或者你自己选的模型，效果取决于模型本身加怎么调。我目前没有看到足够的公开案例证明它在复杂桌面任务上的稳定性。

第三，商业模式不清晰是目前最大的隐患。 开源 + Apache-2.0 对社区很好。但字节为什么要做这个？我的猜测是为 Volcengine（火山引擎）引流——你不绑 Claude，但你可能会用 Doubao 模型，跑在火山引擎上。如果这个猜测是对的，那未来大概率会出现「开源版能力降级，企业版收费」的割裂。AI 基础设施市场不缺先开源后收割的故事。

值得警惕的地方

说完了好的，说三个我现在不太放心的点。

更新节奏在放缓。 最后 release 是 2025 年 11 月的 v0.3.0。作为一个每天还在涨星的 33k 项目，更新频率跟不上社区预期是个危险信号。可能进入了维护模式，而不是快速迭代期。

第二，TARS 这个名字撞车。 这个名字的出名程度大概仅次于 LLM——Meta 有 TARS（PyTorch 数据加载），还有其他好几个 TARS。品牌识别度是个问题。

第三，上面的商业模式隐患。 不说第二遍了。

我的判断

如果只给一个结论：TARS 是当前中文互联网生态里最值得关注的桌面 Agent 项目。

它在产品完整度（四入口设计）、架构清晰度（四层 + MCP 内核 + Event Stream）、模型灵活性（多模型支持）上做得相当克制和务实，没有大厂项目常见的「为做大而做大」的毛病——架构是真的经过设计思考的。

但项目节奏在放缓是个隐患。如果字节不继续投入，它可能会慢慢落后于社区和竞品的发展。如果字节持续投入，配合 Volcengine 的云底座，它有机会成为国内桌面 Agent 的事实标准。

对你来说：

• 想玩桌面 Agent —— 这是目前门槛最低、生态最完整的入门选择。下载 Desktop App 装个模型就能跑
• 想研究 Agent 架构 —— 源码质量值得一看，尤其是 MCP Agent 的 ReAct 循环和双 Operator 设计
• 想上生产 —— 建议先做好 Python 沙箱和 Operator 的可靠性验证。等一两个大版本稳定再说
• 想站队 —— 我的判断是这个方向是对的，但字节的投入力度还不确定。观望可以理解，但别完全错过

桌面 Agent 这个赛道，TARS 是目前国内选手里的独苗。它不是最好的，但它是唯一一个齐全的。就是这么拧巴的事实。