Antigravity 是什么
从 Google 官方 Home 文档理解 Antigravity 的产品定位、核心界面、Agent、Artifacts、Editor 与 Browser 的职责边界。
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:2px3. 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
我要它顺着我正在写的代码补 -> Tab5. 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 —— 官方产品入口，用于核对下载、文档和产品当前状态。