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 如何總結變更並承載瀏覽器證據。