---
title: "Antigravity 是什么"
description: "从 Google 官方 Home 文档理解 Antigravity 的产品定位、核心界面、Agent、Artifacts、Editor 与 Browser 的职责边界。"
verifiedAt: "2026-05-07"
---

Antigravity 不是"又一个带 AI 的代码编辑器"。Google 官方文档把它定位成 **agentic development platform（代理驱动的开发平台）**：开发者不只在编辑器里逐行写代码，而是在更高的任务层级管理 agent（代理），让 agent 跨 editor、terminal、browser 完成端到端开发任务，并通过 artifacts（产物证据）留下可审查的过程。

这句话很重要。它决定了学习 Antigravity 的顺序：先理解它的三个界面（surface），再学如何启动 agent、审查 artifacts、限制权限和回到代码 diff。只学编辑器快捷键，会错过它真正不同的部分。

> [!NOTE]
> **这一篇用来建立产品心智模型**：Antigravity 的核心不是补全代码，而是把 agent 从编辑器侧边栏抽出来，变成可以在多个 workspace 中异步执行任务、汇报进展和接受审查的工作对象。

> [!TIP]
> **阅读目标**：读完本章，你应该能用自己的话区分 Editor、Agent Manager、Browser 和 Artifacts，并知道后续学习为什么要围绕“任务、证据、权限”展开。

## 1. 官方定义里的三个关键词

Google 官方 Home 文档给出的定位可以拆成三层：

- **agentic development platform**：它面向的是 agent 驱动的开发流程，不只是聊天、补全或单文件编辑。
- **task-oriented level**：开发者要管理的是任务、workspace、计划、验证结果，而不是每一步都手动指挥模型。
- **editor、terminal、browser**：agent 可以围绕这三个开发现场行动，Antigravity 也因此必须强调验证、权限和 artifacts。

换成中文开发者更可操作的表达：

```text
普通 AI 编辑器：你在编辑器里让 AI 改代码。
Antigravity：你在任务层管理 agent，让它在编辑器、终端、浏览器里完成并证明结果。
```

这也是为什么官方文档会反复出现 Agent Manager、Artifacts、Browser Agent、workspace 这些词。它们不是装饰功能，而是 Antigravity 和传统 IDE 的分界线。

## 2. 三个核心界面

官方文档把 Antigravity 的核心 surface（界面层）分成三类。

| Surface | 官方职责 | 学习重点 | 新手最容易踩的错 |
| --- | --- | --- | --- |
| Agent Manager（代理管理器） | 面向 agent-first 的任务编排与审查界面 | 多 workspace、多 agent、conversation、artifacts | 只看聊天气泡，不看 task / artifact / workspace 状态——等于没用 |
| Editor（编辑器） | 映射到单个 workspace 的 AI-powered IDE | 读写代码、Tab、Command、Agent side panel、diff | 把它当作主战场——会错过 Agent Manager 的真正价值 |
| Browser（浏览器） | 让 agent 读网页并执行浏览器动作 | UI 验证、后台读取、SCM 操作、截图和录屏 | 一上来让 agent 操作真实后台——必须先 localhost、先只读、先 allowlist |

新手最容易犯的错，是把 Antigravity 当作“Editor + Chat”。如果只停留在 Editor，会看不到 Agent Manager 的价值；如果直接让 Browser Agent 操作网页，又容易忽略权限和 allowlist。正确顺序是：

```mermaid
flowchart LR
    Model["理解 Surface"] --> Editor["Editor 内单 workspace 协作"]
    Editor --> Manager["Agent Manager 管理任务"]
    Manager --> Artifacts["审查 Artifacts"]
    Artifacts --> Browser["需要视觉或网页验证时引入 Browser"]
    Browser --> Policy["回到权限策略和人工审查"]

    style Manager fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
    style Artifacts fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style Policy fill:#fee2e2,stroke:#ef4444,stroke-width:2px
```

## 3. Agent Manager 解决什么问题

官方 Home 文档把 Agent Manager 描述成一种 agent-first experience：围绕 planning mode、conversation UI 和 artifact review 组织。

这意味着它不是一个简单的“任务列表”。它要解决的是下面几个问题：

1. 一个 agent 正在做什么。
2. 它属于哪个 workspace。
3. 它的计划是什么。
4. 它已经产出了哪些 artifact。
5. 哪些内容需要你审查或继续反馈。

在真实开发里，这比“AI 在侧边栏说了什么”更重要。因为一个长任务不一定马上结束，你需要知道它有没有偏离目标、有没有用浏览器验收、有没有留下 diff、有没有等待人工批准。

> [!IMPORTANT]
> **判断是否真正用到 Agent Manager**：如果你仍然只看聊天气泡，不看 task、artifact、workspace 和 review 状态，那你还没有进入 Antigravity 的 agent-first 工作方式。

## 4. Editor 仍然重要，但不是唯一中心

Antigravity 保留了熟悉的 AI-powered IDE 体验。官方文档明确提到 Editor 是一个 fully-functional AI-powered IDE，并包含开发者已经熟悉的 Agent、Tab、Command 等能力。

这几个入口要分清：

- **Agent**：主要 AI 工作模式，适合读上下文、规划、修改、执行、验证。
- **Tab**：更接近增强补全，适合在你已有明确编辑意图时补代码。
- **Command**：行内指令式能力，适合局部改写、解释或小范围编辑。

学习时不要把三者混用。大任务交给 Agent，小跨度编辑用 Command，正在写代码时让 Tab 补完局部片段。

```text
我要它理解项目并完成任务  -> Agent
我要它改当前这几行        -> Command
我要它顺着我正在写的代码补 -> Tab
```

## 5. Browser Agent 为什么是核心能力

官方 Home 文档把 Browser Agent 列为主功能之一：它可以读取和操作浏览器，用于 dashboard reads、SCM actions、UI testing 等开发任务。

这类能力很强，也更需要边界。因为浏览器不是纯代码环境，它可能连接后台、账号、支付、部署面板、GitHub、CI、日志系统。学习 Browser Agent 时要先建立三条原则：

- 先只读，再允许点击。
- 先本地页面，再真实后台。
- 先截图或 walkthrough 验收，再让 agent 继续扩大操作范围。

它最适合的第一批任务是本地 UI 验收：

```text
启动本地服务，打开页面，检查登录按钮是否可见。
只允许访问 localhost，不要登录任何外部账号。
完成后给我 screenshot 和 walkthrough。
```

如果任务涉及 GitHub、Cloud Console、支付后台或生产 CMS，应先单独设置 browser allowlist、权限策略和人工确认点。

## 6. Artifacts 是信任机制，不是附件

Google 官方文档把 artifacts 定义为 agent 创建的、用于完成工作或向人类沟通成果的内容。它们可以是 rich markdown、diff view、architecture diagram、image、browser recording 等。

把 artifacts 理解成“附件”会低估它。它真正的作用是让异步 agent 的工作可审查：

| Artifact 类型 | 你要检查什么 |
| --- | --- |
| Task list | 任务是否拆得合理，有没有越界 |
| Implementation plan | 是否先理解约束，再动手实现 |
| Diff view | 改动是否集中、可回退、无无关重构 |
| Screenshot / image | UI 结果是否符合预期 |
| Browser recording | 操作路径是否真实可复现 |
| Architecture diagram | 架构判断是否和代码一致 |

> [!TIP]
> **实战用法**：每次让 agent 做较大任务时，都要求它先交 task list 或 implementation plan；涉及 UI 时要求 screenshot；涉及交互流程时要求 browser recording 或 walkthrough。

<details>
<summary>深读：为什么 Artifacts 决定了 Antigravity 的学习方式</summary>

普通聊天式 AI 工具的风险在于：模型说自己完成了，但你很难判断它到底读了什么、改了什么、验证了什么。Antigravity 把 task list、implementation plan、diff、screenshot、browser recording 等内容放进 artifacts，本质是在给异步 agent 增加可审查证据。

所以学习顺序不能只按“怎么提问”来排。更合理的路径是：先知道任务被拆成什么，再看 agent 计划怎么做，再审查它实际产生的 diff 和视觉证据，最后才决定是否继续扩大权限或发布。
</details>

## 7. 用一句话区分 Antigravity 和普通 AI IDE

普通 AI IDE 的学习重点通常是：如何提问、如何补全、如何看 diff。

Antigravity 的学习重点要再往上提一层：

```text
如何把一个开发任务交给 agent，
如何让 agent 跨 editor / terminal / browser 执行，
如何通过 artifacts 审查它是否真的完成，
如何用权限策略避免它越界。
```

这就是后续教程的主线。安装只是起点，真正要学的是 agent 编排、权限审查和验收闭环。

## 本章自检

完成本章后，用这 3 个问题检查自己是否真正理解：

1. Antigravity 为什么不是单纯的“Editor + Chat”？
2. Agent Manager、Editor、Browser 三个界面（surface）分别负责什么？
3. 为什么 artifacts 比聊天回复本身更适合作为验收依据？

通过标准：你能把一个开发任务描述成”在哪个界面启动、由哪个 agent 执行、用哪些 artifacts 验收、受哪些权限限制”。

## 官方来源

- [Google Antigravity Documentation](https://antigravity.google/docs/home) —— 官方 Home 文档，定义 Antigravity 的产品定位、核心界面（surface）、Agent、Tab、Command 和 Artifacts。
- [Google Antigravity](https://antigravity.google/) —— 官方产品入口，用于核对下载、文档和产品当前状态。

## 接下来去哪

<Cards>
  <Card title="下载与基础导航" description="继续跑通安装、平台要求，以及 Editor 与 Agent Manager 之间的切换。" href="/docs/antigravity/official/00-getting-started/01-download-navigation" />
  <Card title="理解第一次安全运行" description="如果你准备马上打开本地项目，先按安全路径做只读任务和小改动。" href="/docs/antigravity/understanding/02-install-first-safe-run" />
</Cards>
