04 · Antigravity 的 Agent 任務迴圈
拆解 Antigravity agent 的任務迴圈：目標、計劃、許可權、執行、觀察、驗證、Artifacts、反饋和回退。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Agent loop | 代理迴圈 | 規劃、執行、檢查的迴圈。 |
| 計劃審查 | plan review | 執行前先看計劃。 |
| 工件留痕 | artifact | 每步產出可追溯。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你理解 Antigravity agent 的執行迴圈，知道在哪幾步把關。
你是 Antigravity Agent 迴圈顧問。
【角色】
Antigravity Agent 迴圈顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。
【輸入】
- 我想交給它的任務：___
- 成功標準：___
- 對執行過程的疑慮：___
- 可用的驗證手段：___
- 經驗水平：___
【工作流程】
1. 講清 plan-act-verify 迴圈
2. 說明它產出哪些工件
3. 針對我的任務說明它會怎麼做
4. 設定每環的把關點
5. 給驗證
【輸出規範】
▌一、執行迴圈
▌二、產出工件
▌三、針對我任務的流程
▌四、把關點 + 驗證
【硬約束】
- 理解迴圈再放手
- 關鍵步驟人工確認
- 不可逆操作前看工件
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法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 如何總結變更並承載瀏覽器證據。