---
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="/zh-Hant/docs/antigravity/official/00-getting-started/01-download-navigation" />
  <Card title="理解第一次安全執行" description="如果你準備馬上開啟本地專案，先按安全路徑做只讀任務和小改動。" href="/zh-Hant/docs/antigravity/understanding/02-install-first-safe-run" />
</Cards>
