Antigravity 是什麼

Antigravity 不是"又一個帶 AI 的程式碼編輯器"。Google 官方文件把它定位成 agentic development platform（代理驅動的開發平臺）：開發者不只在編輯器裡逐行寫程式碼，而是在更高的任務層級管理 agent（代理），讓 agent 跨 editor、terminal、browser 完成端到端開發任務，並透過 artifacts（產物證據）留下可審查的過程。

這句話很重要。它決定了學習 Antigravity 的順序：先理解它的三個介面（surface），再學如何啟動 agent、審查 artifacts、限制許可權和回到程式碼 diff。只學編輯器快捷鍵，會錯過它真正不同的部分。

這一篇用來建立產品心智模型：Antigravity 的核心不是補全程式碼，而是把 agent 從編輯器側邊欄抽出來，變成可以在多個 workspace 中非同步執行任務、彙報進展和接受審查的工作物件。

閱讀目標：讀完本章，你應該能用自己的話區分 Editor、Agent Manager、Browser 和 Artifacts，並知道後續學習為什麼要圍繞“任務、證據、許可權”展開。

1. 官方定義裡的三個關鍵詞

Google 官方 Home 文件給出的定位可以拆成三層：

agentic development platform：它面向的是 agent 驅動的開發流程，不只是聊天、補全或單檔案編輯。
task-oriented level：開發者要管理的是任務、workspace、計劃、驗證結果，而不是每一步都手動指揮模型。
editor、terminal、browser：agent 可以圍繞這三個開發現場行動，Antigravity 也因此必須強調驗證、許可權和 artifacts。

換成中文開發者更可操作的表達：

普通 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。正確順序是：

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 組織。

這意味著它不是一個簡單的“任務列表”。它要解決的是下面幾個問題：

一個 agent 正在做什麼。
它屬於哪個 workspace。
它的計劃是什麼。
它已經產出了哪些 artifact。
哪些內容需要你審查或繼續反饋。

在真實開發裡，這比“AI 在側邊欄說了什麼”更重要。因為一個長任務不一定馬上結束，你需要知道它有沒有偏離目標、有沒有用瀏覽器驗收、有沒有留下 diff、有沒有等待人工批准。

判斷是否真正用到 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 補完區域性片段。

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

5. Browser Agent 為什麼是核心能力

官方 Home 文件把 Browser Agent 列為主功能之一：它可以讀取和操作瀏覽器，用於 dashboard reads、SCM actions、UI testing 等開發任務。

這類能力很強，也更需要邊界。因為瀏覽器不是純程式碼環境，它可能連線後臺、賬號、支付、部署面板、GitHub、CI、日誌系統。學習 Browser Agent 時要先建立三條原則：

先只讀，再允許點選。
先本地頁面，再真實後臺。
先截圖或 walkthrough 驗收，再讓 agent 繼續擴大操作範圍。

它最適合的第一批任務是本地 UI 驗收：

启动本地服务，打开页面，检查登录按钮是否可见。
只允许访问 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	架構判斷是否和程式碼一致

實戰用法：每次讓 agent 做較大任務時，都要求它先交 task list 或 implementation plan；涉及 UI 時要求 screenshot；涉及互動流程時要求 browser recording 或 walkthrough。

深讀：為什麼 Artifacts 決定了 Antigravity 的學習方式

普通聊天式 AI 工具的風險在於：模型說自己完成了，但你很難判斷它到底讀了什麼、改了什麼、驗證了什麼。Antigravity 把 task list、implementation plan、diff、screenshot、browser recording 等內容放進 artifacts，本質是在給非同步 agent 增加可審查證據。

所以學習順序不能只按“怎麼提問”來排。更合理的路徑是：先知道任務被拆成什麼，再看 agent 計劃怎麼做，再審查它實際產生的 diff 和視覺證據，最後才決定是否繼續擴大許可權或釋出。

7. 用一句話區分 Antigravity 和普通 AI IDE

普通 AI IDE 的學習重點通常是：如何提問、如何補全、如何看 diff。

Antigravity 的學習重點要再往上提一層：

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

這就是後續教程的主線。安裝只是起點，真正要學的是 agent 編排、許可權審查和驗收閉環。

本章自檢

完成本章後，用這 3 個問題檢查自己是否真正理解：

Antigravity 為什麼不是單純的“Editor + Chat”？
Agent Manager、Editor、Browser 三個介面（surface）分別負責什麼？
為什麼 artifacts 比聊天回覆本身更適合作為驗收依據？

透過標準：你能把一個開發任務描述成”在哪個介面啟動、由哪個 agent 執行、用哪些 artifacts 驗收、受哪些許可權限制”。

官方來源

Google Antigravity Documentation —— 官方 Home 文件，定義 Antigravity 的產品定位、核心介面（surface）、Agent、Tab、Command 和 Artifacts。
Google Antigravity —— 官方產品入口，用於核對下載、文件和產品當前狀態。