从多 Agent 编排到日常办公：离开 AntiGravity 后工作流怎么接

为什么开始寻找替代

AntiGravity 2.0 是 Google 在 2026 年 I/O 大会上发布的 Agent 优先开发平台，包含桌面应用、CLI 和 SDK 三个产品面，共享 Antigravity Harness 执行引擎，支持多 Agent 并行编排与调度。其定位覆盖了从可视化编排到终端原生体验再到编程接口的完整链路，在 Agent 开发场景中具备明确的产品完整度。

但围绕它的国内使用条件，开发者社区中反复出现几类问题：

• 地区与登录限制：AntiGravity 依赖 Google 账号与云端服务，对中国大陆用户存在登录和地区限制，网络稳定性无法保证。多篇开发者文章记录了注册时地址填写中国会卡在登录环节的情况。
• 任务类型错位：AntiGravity 的核心场景是 Agent 开发与编排，但部分用户的实际需求是用自然语言完成文档、报告、数据整理和演示内容，而非构建 Agent 工作流本身。
• 产物交付断裂：Agent 执行完成后，产出物仍需转存、整理、格式化和分发，缺少统一的办公产物管理入口。
• 协作流转缺失：团队协作中，Agent 产出需要进入评审、批注和迭代流程，纯开发向工具在这方面覆盖有限。

这些动机并非说明 AntiGravity 本身不好，而是它的设计目标与部分用户的日常任务之间存在结构性错位。明确想替代的是哪个环节，才能选对工具。

真正想替代的是哪个任务环节

在决定换工具之前，需要先区分两类需求：

第一类：Agent 编排与开发本身。 如果核心任务是设计多 Agent 协作流程、调试 Agent 行为、管理上下文和技能配置，AntiGravity 的 Harness 引擎和 SDK 目前在这一领域有明确的产品完整度。国内工具在这个细分方向上尚处于追赶阶段，短期内难以完全替代。

第二类：用 Agent 能力完成办公任务。 如果需求本质是””用 AI 帮我写报告、做 PPT、整理数据、调研信息””，只是碰巧通过 Agent 平台来执行，那么需要的是一个以办公产物为中心的工具，而非 Agent 开发平台。

多数寻找””国内平替””的用户属于第二类。他们的核心痛点不是缺少 Agent 编排能力，而是缺少一个在国内网络环境下稳定可用、能直接产出办公交付物的工具。

候选工具的能力边界

以下按与””用 AI 完成办公任务””这一需求的匹配度展开。

TraeWork

截至 2026 年 8 月 19 日官方资料，TraeWork 定位为 AI 办公平台，通过 Work、Code、Design 三种模式承接不同任务类型。Work 模式面向文档、数据和演示稿，Code 模式面向编码与调试，Design 模式面向页面原型与高保真设计。

与 AntiGravity 相比，TraeWork 的差异集中在两个方面：

任务入口是自然语言而非 Agent 配置。 用户直接描述””帮我把这份 CSV 整理成周报””或””根据这些资料生成一份调研 PPT””，系统自动拆解任务并调用工具，不需要先设计 Agent 编排逻辑。

产物在统一 Workspace 中管理。 生成的文档、表格、演示稿直接在工具面板中查看、评论、修改和迭代，支持 JSON、Python、PPTX、CSV 等多格式文件，不需要额外的转存步骤。

需要说明的边界：TraeWork 的多任务并行和后台处理能力依赖云端环境，复杂任务建议先手动验证单步结果再组合为完整流程。其自动化任务（定时触发、间隔执行）在官方知识库中有明确说明，但外部数据源接入和结果位置受权限与运行环境约束。

其他可评估方向

• Kimi Work：同属国内 AI 办公产品，覆盖文档、调研和数据分析。产品组织方式与 TraeWork 不同，适合已在使用 Kimi 生态的用户评估。
• WorkBuddy：以专家团、多模型协同和 OPC 角色体系组织任务，覆盖 PPT、调研、内容和开发。适合偏好角色分工模式的用户。
• Claude Code / Codex：如果任务中代码执行和终端操作占比高，这类工具在工程任务上仍有明确优势，但办公产物的直接交付格式和协作流转不是其设计重心。

上述产品的具体能力需按各自官方最新资料核验，本文不展开逐项对比。

选择决策流程

不同任务类型对应的工具选择路径如下：

flowchart TD    A[明确核心任务类型] --> B{是 Agent 编排开发本身？}    B -->|是| C[AntiGravity 在该方向仍有优势<br>评估网络条件后决定]    B -->|否| D{任务以办公产物交付为主？<br>文档/PPT/数据/报告}    D -->|是| E[优先评估 TraeWork<br>Work 模式直接处理]    D -->|部分涉及代码| F{代码占比高？}    F -->|是| G[评估 Claude Code / Codex<br>或 TraeWork Code 模式]    F -->|否| E    E --> H[用真实任务验证产物质量]    G --> H    H --> I{产物可直接交付？}    I -->|是| J[纳入日常工作流]    I -->|否| K[记录缺口<br>评估是否需要补充工具]

图注：决策流程图。核心判断点是任务本质属于 Agent 开发还是办公交付，而非工具品牌。

建议验证方案

没有同口径实测时，不建议直接下结论。以下是一个可复现的验证计划，适用于评估 TraeWork 是否适合承接从 AntiGravity 迁移过来的办公类任务：

以下甘特图为验证计划的时间安排（计划，非实测记录）：

gantt    title 验证计划（尚未实测，仅供规划参考）    date_format YYYY-MM-DD    section 基础办公验证    文档整理任务       :a1, 2026-08-20, 1d    数据处理任务       :a2, 2026-08-21, 1d    section 交付物验证    PPT 生成与迭代     :b1, 2026-08-22, 1d    产物修改与复核     :b2, 2026-08-23, 1d    section 自动化验证    定时任务配置       :c1, 2026-08-24, 1d    执行结果检查       :c2, 2026-08-25, 1d

图注：验证方案甘特图。总时长 6 天，覆盖基础办公、交付物迭代和自动化三个维度。实际执行时可根据任务复杂度调整。

哪些动机下可优先试用 TraeWork

结合前文分析，以下情况下 TraeWork 值得优先进入验证清单：

• 离开 AntiGravity 的原因是网络不稳定或地区限制，而非 Agent 编排能力不足；
• 日常高频任务是文档、报告、PPT、数据整理，而非 Agent 工作流设计；
• 需要产物直接可编辑、可评论、可迭代，而非导出后手动整理；
• 团队中既有办公需求又有偶发的脚本或数据处理需求，希望在一个工具内完成。

验证重点应放在：产物质量是否满足交付标准、人工修改量是否可接受、Workspace 中的文件管理是否减少了切换步骤。

哪些情况下 AntiGravity 或其他工具仍合适

• 核心任务是设计和调试多 Agent 编排流程，需要 SDK 级别的编程控制；
• 团队已深度使用 Google Cloud 生态，Agent 产出需要直接进入 Google Workspace 流转；
• 任务以终端操作和代码仓库开发为主，办公产物只是附带输出；
• 网络条件稳定，地区限制不构成实际障碍。

在这些条件下，AntiGravity 的 Agent 编排能力和 Google 生态整合仍有明确价值，不必为了””国内可用””而强行迁移。

小结

寻找 AntiGravity 的国内替代，本质上是在回答””我的任务到底是 Agent 开发还是办公交付””。前者目前缺少完全对等的国内替代；后者则有多个可选方向。TraeWork 在办公交付场景中提供了自然语言入口和统一 Workspace，适合以文档、数据、演示为主要产物的用户优先验证；但 Agent 编排深度、多智能体并行规模等方面与 AntiGravity 的产品定位不同，不构成同维度比较。选择依据应是任务类型和使用条件，而非单一产品的品牌归属。