開發工具

Google Antigravity 2.0 多 Agent 工作流：Subagents、Hooks 與定時任務怎麼分工

用一個真實倉庫拆解 Antigravity 2.0 的 Subagents、Hooks、Scheduled Tasks 與 Agent Manager，說明分工、隔離、驗收和失敗恢復。

Antigravity 2.0 同時提供 Subagents、Hooks、Scheduled Tasks 和 Agent 管理能力。

把它們全部打開不會自動提高效率，反而容易讓多個 Agent 修改同一文件。

四種能力各自負責什麼

Subagent 適合可獨立驗收的子任務。

Hook 適合在確定事件發生時執行短小規則。

Scheduled Task 適合按時間觸發的重複任務。

Agent Manager 負責觀察與干預運行中的任務。

不要用定時任務代替失敗重試，也不要用 Hook 承載長時間構建。

用一個倉庫劃出所有權

假設倉庫包含前端、API 和文檔。

爲三類任務建立路徑所有權：

1
2
3

apps/web/**       → frontend agent
services/api/**   → backend agent
docs/**           → docs agent

共享的鎖文件、CI 配置和數據庫遷移不分配給普通 Subagent。

它們需要主 Agent 或人工串行處理。

每個 Subagent 使用獨立工作樹 

1
2
3

git worktree add ../wt-web -b agent/web
git worktree add ../wt-api -b agent/api
git worktree add ../wt-docs -b agent/docs

工作樹讓修改隔離，但不能解決數據庫、端口和緩存衝突。

爲每個任務分配不同端口與臨時目錄。

1
2
3

web: 3101
api: 8101
docs: 4101

不要讓三個 Agent 共用一個 .env.local。

主 Agent 的任務說明必須包含退出條件

一個合格任務應寫清：

  • 允許修改的目錄。

  • 禁止修改的文件。

  • 必須運行的測試。

  • 最終提交物。

  • 何時停止並請求人工判斷。

“把前端做好”不是可驗收任務。

“修復登錄表單鍵盤導航，並讓三個指定測試通過”纔是。

Hook 只做快速、確定性的檢查

適合 Hook 的動作：格式檢查、secret scan、git diff --check。

不適合 Hook 的動作：端到端測試、部署、自動合併和數據庫升級。

Hook 必須有超時。

Hook 失敗應阻止下一步，並把原始退出碼交給 Agent Manager。

不要讓 Agent 根據報錯文本猜測成功。

定時任務必須防止重疊執行

每天生成依賴報告時，先獲取鎖。

已有實例運行就跳過，而不是再啓動一個 Agent。

任務輸出寫入按日期分隔的目錄。

保留本次使用的模型、提示版本和倉庫 commit。

同一天重複執行也應生成唯一運行 ID。

合併順序由依賴關係決定

文檔依賴 API 字段時，先合併 API。

前端依賴同一字段時，在 API 合併後 rebase。

1
2

git fetch origin
git rebase origin/main

衝突不要交給兩個 Agent 同時解決。

指定一個所有者，另一個只提供解釋。

Agent Manager 應重點看什麼

不是盯着每個 token，而是看異常信號：

  • 同一工具連續重複。

  • 修改超出路徑範圍。

  • 測試數量突然減少。

  • 運行時間超過歷史基線。

  • 請求新的憑據或網絡權限。

任何一項出現，都應暫停任務而非繼續追加提示。

瀏覽器任務與代碼任務分離

Antigravity 能控制瀏覽器，但測試賬號不能複用個人賬號。

準備獨立測試租戶和可重置數據。

瀏覽器 Agent 只能訪問測試域名。

生產管理後臺應從允許列表排除。

截圖和錄像也可能包含個人信息，保留週期要明確。

一次完整演練

先讓 frontend agent 修改一個組件。

Hook 運行格式與 secret 檢查。

backend agent 同時補一個無衝突的單元測試。

主 Agent 等兩個分支完成後讀取 diff。

按依賴順序合併並運行集成測試。

docs agent 最後根據真實接口更新文檔。

故意讓一個 Hook 返回非零退出碼，確認工作流會停止。

再故意製造同文件衝突，確認只有一個解決者。

不要自動化的部分

生產部署批准不要交給定時任務。

密鑰輪換不要由普通 Subagent 執行。

許可證變化和數據庫破壞性遷移需要人工複覈。

刪除工作樹之前保留 diff、測試結果和任務日誌。

覆盤指標

記錄並行後總耗時是否下降。

記錄衝突次數和人工干預次數。

記錄每個 Agent 的一次通過率。

如果並行節省 10 分鐘卻增加 30 分鐘合併成本，就應該減少 Subagent 數量。

多 Agent 的正確目標是縮短關鍵路徑，而不是製造更多同時運行的窗口。

Antigravity 工作流資料

用依賴圖決定並行，而不是平均分任務

先把任務寫成節點：接口定義、後端實現、前端調用、集成測試和文檔。只有沒有前置依賴的節點才同時啓動。

1
2
3

接口定义
├─ 后端实现 ─┐
└─ 前端调用 ─┼─ 集成测试 ─ 文档

如果接口還在變化，提前啓動文檔 Agent 只會製造返工。主 Agent 應在每個節點完成後保存 commit SHA，再把這個確定版本交給下游。

Worktree 中的依賴與端口隔離

Node 項目不要讓多個工作樹共享可寫的 node_modules。包緩存可以共享，安裝目錄不能共享。數據庫則爲每個 Agent 創建獨立 schema 或容器。

1
2
3
4

APP_PORT=3101
API_PORT=8101
DATABASE_URL=postgresql://agent_web:[email protected]:5432/agent_web
TMPDIR=C:/agent-tmp/web

另一個 Agent 使用不同端口、數據庫名和臨時目錄。這樣測試失敗時，日誌能對應到唯一任務。

合併前生成機器可讀交接單

每個 Subagent 完成時返回分支、起點 commit、終點 commit、修改文件、測試命令和未解決問題。

1
2
3
4
5
6
7
8

branch: agent/web
base: 8c18d4a
head: 14f24b1
tests:
  command: npm test -- login-form
  exit_code: 0
unresolved:
  - needs API schema v3

主 Agent 從 Git 和測試日誌覈實這些字段。自然語言裏聲稱“全部通過”不能覆蓋非零退出碼。

製造一次真實衝突

讓兩個工作樹分別修改同一個類型定義，一個增加字段，一個重命名字段。合併第一個分支後，第二個分支執行 rebase。

1
2
3
4

git fetch origin
git rebase main
git status --short
git diff --check

衝突解決者必須重新運行兩個分支的測試，而不是隻運行自己的測試。類型檢查通過後，再讓只讀審查 Agent 比較合併結果與兩份任務說明。

定時任務的停用開關

每個 Scheduled Task 都要有一個無需修改代碼的停用入口。觸發器失控時先禁用調度，再處理已啓動實例。

記錄下一次運行時間、最近一次成功時間、連續失敗次數和當前鎖持有者。連續失敗達到閾值後停止調度並通知人類，不要讓 Agent 無限修復自己生成的錯誤。

Hooks 的輸出契約

Hook 返回值要讓人和 Agent 都能判斷結果。建議輸出檢查名稱、目標 commit、退出碼、發現數量和報告路徑。

1
2
3
4
5
6
7

{
  "check": "secret-scan",
  "commit": "14f24b1",
  "exit_code": 1,
  "findings": 2,
  "report": "artifacts/secret-scan.json"
}

不要在標準輸出中打印疑似密鑰原文。報告用指紋、文件路徑和行號定位，查看原文需要更高權限。

瀏覽器 Agent 的測試數據清理

自動化創建的賬號、訂單和上傳文件都帶運行 ID。清理任務只刪除帶該 ID 且位於測試租戶的數據，不能使用“刪除今天創建的全部對象”這類寬泛條件。

清理失敗不應讓主測試顯示成功。報告中分別記錄業務測試結果與清理結果，方便值守人員發現測試環境正在積累數據。

判斷是否應該減少並行數

連續三輪統計等待時間、衝突率、失敗重跑和人工審覈時間。如果 Agent 大量等待同一個接口或共享測試環境，把並行數從三降到二通常更快。

當任務可以用一個工作樹按順序在十分鐘內完成時，不值得爲並行建立額外分支、端口和合並流程。