04 · Antigravity 的 Agent 任务循环
拆解 Antigravity agent 的任务循环：目标、计划、权限、执行、观察、验证、Artifacts、反馈和回退。
Antigravity 的 agent 不应该被当成“长回复生成器”。Google 官方把 Agent 定义为：由前沿 LLM 驱动的多步推理系统，能围绕你已有的代码进行推理、调用包括浏览器在内的多种工具、并通过 tasks 和 artifacts 等方式与用户沟通。换成实操语言，它的工作不是“回答你”，而是进入一个可审查的任务循环：理解目标、读取上下文、制定计划、请求权限、执行、观察结果、交付证据、等待反馈。
这一篇解决什么问题：你要学会看 agent 在循环里的每一步，而不是只看最后一句“完成了”。
阅读目标：读完本章，你应该能把一次 Antigravity 任务拆成可验收目标、plan、权限、diff、测试、截图、walkthrough 和回退点。
1. 循环图
flowchart TD
Goal["目标"] --> Context["读取上下文"]
Context --> Plan["Task list / implementation plan"]
Plan --> Review{"需要人工审阅?"}
Review -->|是| Human["人工评论 / 批准"]
Review -->|否| Permission["权限检查"]
Human --> Permission
Permission --> Execute["执行：edit / terminal / browser / MCP"]
Execute --> Observe["观察输出：diff / logs / DOM / screenshot"]
Observe --> Verify["验证：test / browser flow / artifact"]
Verify --> Walkthrough["Walkthrough"]
Walkthrough --> Feedback{"反馈或接受?"}
Feedback -->|反馈| Plan
Feedback -->|接受| Done["完成"]
Feedback -->|不满意| Undo["回退"]这个循环里最容易忽略的是 Verify（验证）。没有验证的 agent 任务，只是生成了改动，不代表完成。Antigravity 的优势在于它能把 plan（计划）、task list（任务清单）、diff（代码差异）、screenshot（截图）、recording（录屏）、walkthrough（任务总结）变成 artifacts（产物证据）；你的工作是把这些证据串成验收链，而不是只读聊天记录。
2. 官方组件如何落到循环里
官方 Agent 文档列出四个核心组件：reasoning model（推理模型）、tools（工具集）、artifacts（产物证据）、knowledge（长期记忆 / 知识库）。它们在任务循环里分别承担不同职责：
| 组件 | 在循环里的作用 | 你的控制点 |
|---|---|---|
| Reasoning model | 理解目标、拆步骤、判断下一步 | 选择 Planning 或 Fast，给清晰验收条件 |
| Tools | 读写文件、运行终端、控制浏览器、接 MCP | 只开放必要路径、命令和 URL |
| Artifacts | 承载 task list、plan、diff、截图、录屏、walkthrough | 用评论和 Proceed 控制节奏 |
| Knowledge | 沉淀长期项目事实和模式 | 检查是否写入过时结论 |
一个成熟的提示词要覆盖这四层。只写“帮我修一下”会让 agent 自行猜测目标、工具和验收标准；写清边界后，Antigravity 的 artifacts 才能真正发挥作用。
3. Goal 要写成可验收目标
差的目标：
优化一下这个页面。好的目标：
把设置页保存按钮从无响应修到可点击保存。
验收：
1. 点击按钮后显示保存成功状态。
2. 刷新页面后设置仍保留。
3. 交付 screenshot 和 walkthrough。Antigravity 有 browser 和 artifacts，prompt 里就应该写验收证据。否则 agent 可能只交代码，不交证明。
更完整的目标可以这样写：
任务：修复设置页保存按钮无反馈的问题。
范围：只允许修改 app/settings/ 和相关测试文件。
禁止：不要改认证逻辑，不要新增依赖，不要格式化无关文件。
验收：
1. 空输入、有效输入、保存失败三个路径都有反馈。
2. 运行现有测试，并说明结果。
3. 用 browser 验证 desktop 和 mobile。
4. 交付 diff、截图、walkthrough 和剩余风险。这个写法让 agent 很难把任务扩散到无关区域，也让你后续有标准判断它是否完成。
4. Plan 要审三件事
看 implementation plan 时，别纠结每个词，重点看三件事：
| 审查点 | 问题 |
|---|---|
| 范围 | 是否碰到无关目录、配置、依赖 |
| 验证 | 是否包含测试、浏览器、截图或 walkthrough |
| 回退 | 是否知道改了哪些文件，能否撤销 |
如果 plan 没有验证步骤，不要批准。让它补“如何证明完成”。
官方 Implementation Plan 文档说明，Agent 通常会在动手前请求 review，除非你的 Artifact Review Policy 设成 Always Proceed。这里的 Proceed 不是礼貌按钮，而是工程批准。点之前至少确认：
- 计划没有扩大范围。
- 计划没有碰敏感文件。
- 计划说清了验证方式。
- 计划包含失败后如何回退。
- 计划和你最初的验收条件一致。
5. Permission 是任务边界
权限请求不是烦人的弹窗，而是你控制风险的界面。看到 permission request 时问：
- 这个命令是否必要？
- 这个路径是否在 workspace 内？
- 这个 URL 是否和任务有关？
- 这个 MCP tool 是否有外部副作用？
- 拒绝后能否换成更小动作？
第一次上真实项目，建议按这个顺序放权：
只读分析 -> 单文件修改 -> 低风险测试命令 -> localhost 浏览器验证 -> 外部系统只读不要第一天就给完整终端自动执行、workspace 外文件访问和外部网站自由浏览。Agent 能做的越多，越需要 artifacts 留证据。
6. Observe 不是只读日志
agent 执行后会产生多个观察对象：
- terminal 输出
- test 结果
- file diff
- browser screenshot
- console log
- network 或页面状态
- artifact
成熟用法是让 agent 把这些观察结果写进 walkthrough，而不是散落在中间过程里。
观察阶段最常见的误判是“命令没报错，所以完成了”。正确顺序是：
- 先看 diff 是否只改了授权范围。
- 再看测试或构建是否真的运行。
- UI 任务看截图和录屏。
- 浏览器任务检查 console。
- 最后读 walkthrough，确认它和证据一致。
7. Feedback 要贴着 artifact
Antigravity 支持在 artifact 或 diff 上评论。反馈要具体：
差的反馈：
不太好，再改改。好的反馈：
截图里 mobile 宽度下按钮贴到了卡片边缘。
请只调整 `.settings-actions` 的 spacing，不要改颜色和文案。
改完重新截图验证。好的反馈有三个特点：指向具体 artifact，限定修改范围，要求重新验证。不要只说“再优化一下”，那会把 agent 重新推回猜测状态。
8. Done 的标准
一个任务可以接受，至少满足：
- diff 范围合理。
- 没有触碰敏感文件。
- 测试或浏览器验收通过。
- walkthrough 说清做了什么。
- 剩余风险写清楚。
如果只是“代码看起来没问题”，还没到 Done。
本章自检
完成本章后，用这 3 个问题检查自己是否真正理解：
- Antigravity Agent 的任务循环为什么不能只看最后回复？
- Implementation Plan 点 Proceed 前要检查哪三类内容？
- UI 任务为什么必须把 browser 验证和 walkthrough 写进验收条件？
通过标准：你能给一个真实功能修复写出目标、范围、禁止项、验证步骤和证据要求。
官方来源
- Google Antigravity Agent - 官方说明 Agent 是多步推理系统，并列出 reasoning model、tools、artifacts、knowledge。
- Google Antigravity Artifacts - 官方说明 artifacts 用于异步沟通 agent 工作和思考。
- Google Antigravity Implementation Plan - 官方说明 plan review、Proceed 和评论迭代机制。
- Google Antigravity Task List - 官方说明 task list 用于复杂任务的进度跟踪。
- Google Antigravity Walkthrough - 官方说明任务完成后 walkthrough 如何总结变更并承载浏览器证据。