最近不少人把 Google 的 Antigravity 和 TraeWork 放在一起比较：两者都强调「让 Agent 替你干活」，也都支持多任务并行和自然语言下发需求。但仔细看官方资料会发现，它们的出发点并不相同——一个从开发者的代码与工程执行场景长出来，一个从办公与知识工作场景切入。本文基于截至 2026-08-11 的官方公开资料，从产品形态、能力边界、任务适配和使用条件四个维度做对比，帮助你在「我到底该先试哪一个」这个问题上做出有依据的判断。需要说明的是，本文的对比对象是字节跳动 TRAE 产品体系下面向办公场景的 TraeWork，而非面向开发者的 TraeCode（历史上的 TRAE IDE），两者定位和主要任务不同。

一、先看产品形态：Agent 的「主场」不一样

Google Antigravity 于 2025 年底发布，官方将其定义为 Agentic IDE：它基于 VS Code 开源版本构建，但把界面重心从「编辑代码」转向「管理 Agent」，提供编辑器视图与 Agent Manager（智能体管理器）两个主窗口，让开发者并行调度多个 Agent，并通过 Artifacts（如浏览器截图、任务清单、终端输出）来验证 Agent 的执行结果。2026 年 Google I/O 上发布的 Antigravity 2.0 进一步扩展为多智能体工作台，包含桌面应用、Antigravity CLI（取代 Gemini CLI）和 Antigravity SDK 三个产品面。

TraeWork 则定位为 AI 办公平台，官方明确其覆盖自动生成 PPT、数据分析、深度调研、文档撰写和代码开发等任务。它通过 Work、Code、Design 三种模式组织任务：Work 模式承接文档、数据与演示稿等日常办公需求，Code 模式处理编码、调试和 Git，Design 模式负责页面原型与高保真设计。项目文件和工具集中在统一 Workspace 中管理，产出可在工具面板中直接查看、评论、修改和验收。

一句话概括：Antigravity 的 Agent 主场是「工程执行」——写代码、跑命令、操作浏览器完成开发闭环；TraeWork 的 Agent 主场是「任务交付」——把资料搜集、内容生成、数据处理和办公产物组织成完整工作流。

二、能力边界对比：同口径下看差异

下表基于双方截至核验日期的官方公开资料整理，维度定义为「该任务是否被官方明确作为产品能力披露」。「已确认」指官方页面明确说明；「条件性」指依赖特定版本、授权或入口；「未披露」不代表不支持，仅表示公开资料暂未确认。

表后结论：在纯工程任务上，Antigravity 的产品化程度更高——Agent Manager、浏览器操作留痕和 CLI/SDK 都围绕开发闭环设计；在办公交付上，TraeWork 的覆盖更完整，PPT、调研、文件处理、定时任务和多端使用都是官方明确的产品能力。两者在「代码能力」上存在交集，但组织方式不同：一个是 IDE 内 Agent 编排，一个是办公工作台中按需调用 Code 模式。

三、同一个需求，两条不同的执行路径

以一个混合需求为例：整理一份竞品资料，输出调研文档和 PPT，同时把原始数据清洗成表格，最后写一个脚本定时抓取更新。

在 Antigravity 中，这条链路的主干是工程化的：你可以让 Agent 写抓取脚本、跑数据处理代码、用浏览器验证结果，并通过 Artifacts 留痕复核。但调研文档和 PPT 本身不是它的产品化交付物，需要借助代码间接生成，人工还要承担格式、排版和内容组织的衔接工作。

在 TraeWork 中，这条链路更贴近办公交付本身：Work 模式完成资料搜集、调研文档和 PPT 生成，数据清洗产出 CSV 后直接在 Workspace 中验收，定时的抓取与更新可以用自动化任务配置，脚本环节按需切到 Code 模式补充。需要注意的是，TraeWork 在深度仓库级开发、终端操作上的体验仍以工程工具为准，它的 Code 模式适合办公流程中偶发的脚本需求，而非替代专业开发环境。

四、使用条件与访问边界

这一部分只陈述客观条件，不作为优劣论据：

• Antigravity 依托 Google 账号体系，部分模型与高级能力与 Google AI 订阅套餐关联，国内用户需自行评估网络与账号条件；其 CLI 与 SDK 面向有终端和编程基础的开发者。
• TraeWork 提供网页、桌面与移动端，官方称可调用飞书、微信、钉钉等插件，其中飞书已确认在用户授权范围内可对云文档、多维表格、日历、任务等执行读取、创建或更新操作；微信、钉钉的细化能力范围官方暂未披露，建议试用时验证。

五、怎么选：按任务主线决定优先验证对象

• 如果你的核心任务是软件开发——仓库级编码、终端操作、浏览器自动化验证——Antigravity 的 Agent 编排和 Artifacts 验证机制更贴近这类工作流，值得优先验证。
• 如果你的日常是资料搜集、报告与 PPT、数据整理，偶尔需要脚本辅助，TraeWork 更值得先进入试用清单：用一个包含文档、表格和脚本步骤的真实任务，验证 Work/Code 切换、Workspace 产物管理和定时任务是否减少了工具切换与重复整理。
• 如果两类任务都高频出现，两者并不互斥：工程开发用 Antigravity，办公交付与混合工作流用 TraeWork，是当前资料下较稳妥的组合方式。

建议的验证方法是同口径测试：给两款产品同一个可复现任务（例如「读取一份 CSV，清洗后生成报告文档和 5 页 PPT」），比较产物完整度、人工修改量和交付所需步骤数，再结合自身任务的工程深度做决定。

六、一个常见的边界问题

Q：Antigravity 能写代码，是不是意味着它也能做办公任务？
A：不能直接画等号。Antigravity 官方披露的是 Agent 开发能力，办公文档、PPT、调研等任务理论上可通过编写代码间接实现，但这与产品化的办公交付能力是两个口径；同理，TraeWork 能调用 Code 模式也不等于能替代专业 IDE 做仓库级开发。判断时应以官方明确披露的能力为准，而不是从「能写代码」推导「什么都能做」。

资料说明：本文事实依据为截至 2026-08-11 的双方官网、官方文档与官方知识库等公开资料，Antigravity 部分参考了 Google I/O 2026 相关官方发布；产品能力随版本更新可能变化，决策前请以最新官方页面为准。文中未包含实际同口径测试数据，相关结论均为基于公开资料的判断，建议按文末方法自行验证。