Antigravity Dynamic Workflows 怎麼用？用 /run-workflow 驗收批次審查

先決定什麼算審查完成#

以下是交給 Antigravity 的提示範例。先用兩個已知結果的檔案驗收一次，再擴大範圍。

1
/run-workflow 只讀審查我提供的檔案清單，每個檔案交給一個代理。
2
檢查新增的輸入欄位是否有空值測試。每筆回傳 path、status、
3
evidence，status 限 covered、missing、unknown。
4
evidence 附測試檔路徑與行號。代理不可改檔。
5
彙整時逐一核對輸入清單。缺少結果的檔案列為 unknown。

審閱生成的 Python 腳本時，先核對它讀取的檔案清單，以及每個子代理收到的限制。JSON Schema 可約束輸出欄位和狀態，測試是否存在仍需要從回傳的位置查證。讓樣本包含一個有測試的檔案、一個缺測試的檔案，確認兩個狀態分得開。若改用已知路徑測試失敗情境，也要確認彙整保留缺少的檔名。

Google 的 parallel() 會按輸入順序回傳，任一項失敗會取消其他項。若希望單一檔案無法讀取時其他檔案照常審查，讓子任務把這類預期錯誤回傳為 unknown，並檢查整階段失敗時的呈現。逐項執行可用 pipeline()；若後段要讀取前段結果，可在腳本中等候前段完成後再傳入。

把腳本核准和子代理權限一起看#

依官方文件，執行前會顯示生成的腳本供核准，已允許執行的權限預設組合例外。子代理仍依權限設定在各自對話提出核准要求。只讀審查時，確認腳本與子代理提示都限定檔案範圍。若日後要讓多個代理同時改檔，官方的 workspace: branch 模式會為各代理提供獨立 Git worktree，成果仍需檢閱與整合。

一次委派單一研究或建置工作，可直接用 subagent。代理需要彼此協調介面或審查修改時，可用 /swarm。難以定位的競態或演算法問題，可用 /boost 做深入推理與獨立查證。需要固定階段、指定回傳欄位和重跑同一份檔案清單時，才值得審閱並保留 workflow 腳本。

若 App 尚未出現指令，先確認 App 版本與帳號方案。透過 OpenClaw 使用 Antigravity 的讀者可參考整合版本排錯，核對自己操作的是哪個入口。

參考資料：

Google Antigravity：Dynamic Workflows

Google Antigravity：Changelog