Agent 核心工作方式
根据 Google 官方 Agent 文档解释 Antigravity Agent 的组成：reasoning model、tools、artifacts、knowledge、并行 conversations 与删除边界。
Antigravity 里的 Agent 是产品的主 AI 能力。Google 官方文档把它描述成一个由 frontier LLM 驱动的 multi-step reasoning system：它能围绕现有代码推理，调用多种工具，包括 browser，并通过 tasks、artifacts 等方式和用户沟通。
这说明两件事。第一，Agent 不是一次性回答模型，而是会分步骤理解、执行、验证。第二，Agent 的质量不只取决于模型，还取决于工具、上下文、artifacts 和权限策略。
这一篇先建立底层模型：学 Antigravity 的 Agent，不要只问“它用什么模型”，要同时看 reasoning model、tools、artifacts、knowledge 和 conversation 管理。
阅读目标：读完本章，你应该能把一次 Agent 任务拆成目标、上下文、工具调用、artifacts、审查反馈和后续执行，而不是只看模型回复。
1. Agent 是多步推理系统
普通聊天模型的输出通常是一次回答。Antigravity Agent 的工作方式更接近工程循环：
flowchart LR
Goal["用户给目标"] --> Context["读取代码和上下文"]
Context --> Reason["reasoning model 推理"]
Reason --> Tools["调用工具"]
Tools --> Artifacts["产出 artifacts / tasks"]
Artifacts --> Review["用户审查和反馈"]
Review --> Reason
style Reason fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
style Tools fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
style Review fill:#dcfce7,stroke:#22c55e,stroke-width:2px这个循环决定了你的提示词要写成任务说明，而不是写成“问答题”。一个合格的任务应该包含：
- 目标：要修什么、做什么、查什么。
- 边界：哪些目录能改，哪些不能改。
- 验证：跑什么测试，交什么截图或 walkthrough。
- 审查点：什么时候停下来等你确认。
2. 四个核心组件
官方 Agent 文档列出四个 core components。
| 组件 | 作用 | 你要怎么用 |
|---|---|---|
| Reasoning model | 负责理解目标、规划、判断下一步 | 根据任务复杂度选择模型和模式 |
| Tools | 读写文件、终端、浏览器等能力入口 | 用权限和 allow/deny 控制副作用 |
| Artifacts | 任务计划、实现计划、截图、录屏、diff 等产物 | 用来审查，而不是只看聊天文本 |
| Knowledge | Antigravity 保存和调用的项目知识 | 让长期项目不必每次从零解释 |
新手常见误区是只关注第一项：模型。模型当然重要，但如果 tools 没有限权、artifacts 没有审查、knowledge 写进了过时结论，再强模型也会把任务推偏。
3. Tools 包括 browser
官方文档特别提到 Agent 可以使用 wide range of tools，包括 browser。对开发任务来说，这意味着 Agent 不只是“在文件里改代码”。
它可以围绕这些现场行动：
- 代码文件：读项目、修改文件、看 diff。
- 终端：运行构建、测试、格式化、CLI。
- 浏览器：打开页面、点击、滚动、填写输入、做 UI 验证。
- Artifacts：把计划、结果、截图、录屏交给你审查。
工具越多，能力越强，风险也越大。第一天的正确做法是从只读工具开始，逐步放开终端和浏览器权限。
第一步：只读分析 workspace。
第二步：允许单文件修改。
第三步：允许受控 terminal 命令。
第四步：允许 localhost 浏览器验证。
第五步：再考虑真实后台或外部网站。4. Tasks 和 Artifacts 是沟通层
Antigravity 不要求用户盯着每一步模型输出。Agent 会通过 tasks、artifacts 等方式和用户沟通，这正是 agent-first 工具的关键。
你应该重点看：
- Task group 是否把任务拆清楚。
- Implementation plan 是否先说明方案再改文件。
- Diff 是否只覆盖目标范围。
- Screenshot / browser recording 是否能证明 UI 或流程真的跑过。
- Knowledge 是否记录了可长期复用的项目事实。
如果一个任务没有 plan、没有 diff、没有截图或没有 walkthrough，却声称“已完成”，不要直接接受。Agent 的结果必须能被 artifacts 审查。
深读：为什么 Agent 不是“更长的聊天”
官方 Agent 文档把 Antigravity Agent 描述为 multi-step reasoning system，这个定义会影响你的工作方式。你给它的不是一道问答题，而是一组可以被执行、审查、反馈、再执行的工程任务。
因此，好的提示词要把目标、边界、工具、验证和停顿点写清楚。否则 Agent 可能会把“我理解了”误当成“我可以直接执行”，或者把一次复杂任务拆成不可审查的大改动。
5. 可以并行开多个 Agent conversation
官方文档说明，用户可以启动多个 Agent conversations，包括并行运行。这个能力很适合把相互独立的任务拆开：
| 适合并行 | 不适合并行 |
|---|---|
| 一个 agent 查文档，一个 agent 修 UI | 两个 agent 同时改同一个文件 |
| 一个 agent 跑排障，一个 agent 写测试计划 | 多个 agent 同时改同一个模块接口 |
| 不同 workspace 的独立任务 | 同一 Git 分支上无边界大改 |
并行不是为了热闹，而是为了让边界清晰的任务同时推进。并行前至少要说清楚：
Agent A 只读分析认证模块，不修改文件。
Agent B 只修改 docs 目录，不碰 src。
两个 agent 都不要提交 git。6. 删除 conversation 的边界
官方 Agent 文档提到，删除 Agent conversation 可以在 Agent Manager 中右键选择 Delete Conversation，也可以在 Editor 的 Agent panel 里点击 trash icon。
这类删除动作要理解边界：
- 删除 conversation 主要影响会话记录和任务上下文。
- 它不等于自动撤销已经写入文件的代码改动。
- 真正的文件回退仍然要看 Git diff、undo、revert 或手动恢复。
不要把“删掉 conversation”当成“撤销任务”。只要 agent 改过文件，就必须检查 Git 状态。
7. 一个安全的 Agent 启动模板
第一次对真实项目使用 Agent，可以这样写：
先只读分析当前 workspace，不要创建、修改或删除文件。
请输出：
1. 你判断这个项目的技术栈。
2. 本任务可能涉及的目录。
3. 你需要调用哪些工具。
4. 你建议的最小执行计划。
5. 哪一步需要我确认后才能继续。如果要让它继续执行，再补一条：
按刚才计划执行第一步，只允许修改一个文件。
执行任何 terminal 命令前先请求确认。
完成后交付 diff、验证命令和可能风险。这能把 Agent 的多步能力控制在可审查范围内。
本章自检
完成本章后，用这 3 个问题检查自己是否真正理解：
- Antigravity Agent 的四个核心组件分别是什么？
- 为什么 tools 越多，越需要权限和 artifacts 审查？
- 删除 conversation 为什么不等于撤销已经写入文件的改动？
通过标准：你能为真实项目写出一条只读启动 prompt，并明确下一步允许哪些工具、修改哪些文件、交付哪些证据。
官方来源
- Google Antigravity Agent —— 官方说明 Agent 的定义、核心组件、并行 conversations 和删除方式。
- Google Antigravity Documentation —— 官方文档入口，用于核对 Agent Manager、Artifacts、Browser 等关联章节。