Google Antigravity 2.0 マルチエージェントワークフロー: サブエージェント、フック、スケジュールされたタスク間で作業を分割する方法

Antigravity 2.0 は、サブエージェント、フック、スケジュールされたタスク、およびエージェント管理機能も提供します。

それらをすべて開くと自動的に効率が向上するわけではありませんが、複数のエージェントが同じファイルを簡単に変更できるようになります。

4 つの能力は何を担っていますか?

サブエージェントは、独立して引き受けることができるサブタスクに適しています。

フックは、特定のイベントが発生したときに短いルールを実行するのに適しています。

スケジュールされたタスクは、時間によってトリガーされる繰り返しタスクに適しています。

エージェントマネージャーは、タスクの実行を監視し、介入する責任があります。

失敗した再試行を置き換えるためにスケジュールされたタスクを使用しないでください。また、長期的なビルドをホストするためにフックを使用しないでください。

倉庫と所有権を境界設定する

リポジトリにフロントエンド、API、ドキュメントが含まれているとします。

3 種類のタスクのパスの所有権を確立します。

1
2
3


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

共有ロックファイル、CI 構成、データベース移行は、通常のサブエージェントには割り当てられません。

マスターエージェントまたは手動のシリアル処理が必要です。

各サブエージェントは独立した作業ツリーを使用します

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

3 人のエージェントが .env.local を共有しないでください。

メインエージェントのタスクの説明には終了条件を含める必要があります

適格なタスクには、次のことを明確に記載する必要があります。

変更を許可するディレクトリ。
変更が禁止されているファイル。
実行する必要があるテスト。
最終提出。
いつ停止して人間の判断を求めるか。

「フロントエンドを正しく実行する」ということは受け入れられるタスクではありません。

「ログインフォームのキーボードナビゲーションを修正し、3つの特定のテストに合格するようにする」です。

フックは迅速かつ決定的なチェックのみを行います

フックに適したアクション: フォーマットチェック、シークレットスキャン、git diff --check。

フックに適さないアクション: エンドツーエンドのテスト、デプロイメント、自動マージ、データベースのアップグレード。

フックにはタイムアウトが必要です。

フックが失敗すると、次のステップが妨げられ、元の終了コードが Agent Manager に渡されます。

エージェントにエラーテキストに基づいて成功を推測させないでください。

スケジュールされたタスクは重複した実行を防止する必要があります

依存関係レポートを毎日生成する場合は、最初にロックを取得します。

すでに実行中のインスタンスがある場合は、別のエージェントを開始する代わりに、そのインスタンスをスキップします。

タスクの出力は日付で区切られたディレクトリに書き込まれます。

今回使用したモデル、プロンプトバージョン、ウェアハウスコミットを保持します。

同じ日に繰り返し実行すると、一意の実行 ID も生成されます。

マージ順序は依存関係によって決まります

ドキュメントが API フィールドに依存している場合は、最初に API をマージします。

フロントエンドが同じフィールドに依存している場合は、API マージ後にリベースします。

1
2


git fetch origin
git rebase origin/main

競合を 2 人のエージェントが同時に解決できるようにしておかないでください。

1 人の所有者を指定し、もう 1 人は説明を提供するだけです。

エージェントマネージャー何に重点を置く必要がありますか?

各トークンを見つめる代わりに、例外シグナルを見てください。

同じツールが連続的に繰り返されます。
変更はパス範囲を超えています。
検査数が突然減りました。
実行時間が過去のベースラインを超えています。
新しい認証情報またはネットワーク許可を要求しています。

これらの項目のいずれかが表示された場合は、プロンプトの追加を続行するのではなく、タスクを一時停止する必要があります。

ブラウザタスクとコードタスクの分離

反重力はブラウザを制御できますが、テストアカウントは個人アカウントを再利用できません。

独立したテストテナントとリセット可能なデータを準備します。

ブラウザエージェントはテストドメイン名にのみアクセスできます。

運用管理者は許可リストから除外する必要があります。

スクリーンショットやビデオには個人情報が含まれる場合があり、保存期間を明確にする必要があります。

完全なドリル

まず、フロントエンドエージェントにコンポーネントを変更させます。

実行フォーマットとシークレットチェックをフックします。

バックエンドエージェントは、競合のない単体テストも追加します。

マスターエージェントは両方のブランチが完了するのを待ち、差分を読み取ります。

依存関係の順序で統合テストをマージして実行します。

docs エージェントは最終的に、実際のインターフェイスに基づいてドキュメントを更新します。

意図的にフックにゼロ以外の終了コードを返させると、ワークフローが停止することが確認されます。

次に、同じファイルとの競合を意図的に作成して、リゾルバーが 1 つだけであることを確認します。

その部分を自動化しないでください

本番展開の承認をスケジュールされたタスクに渡さないでください。

キーのローテーションは、通常のサブエージェントによって実行されるべきではありません。

ライセンスの変更とデータベースの破壊的な移行には手動によるレビューが必要です。

作業ツリーを削除する前に、差分、テスト結果、タスクログを保存してください。

レビュー指標

並列化後に合計消費時間が減少するかどうかを記録します。

競合と手動介入の数を記録します。

各エージェントの合格率を記録します。

並列処理により 10 分が節約されますが、マージのコストが 30 分追加される場合は、サブエージェントの数を減らす必要があります。

マルチエージェントの正しい目標は、クリティカルパスを短縮することであり、同時に実行できるウィンドウを作成することではありません。

反重力ワークフロー情報

タスクを均等に分割するのではなく、依存関係グラフを使用して並列処理を決定する

まず、インターフェイス定義、バックエンド実装、フロントエンド呼び出し、統合テスト、ドキュメントなどのタスクをノードに書き込みます。事前依存関係のないノードのみが同時に起動されます。

1
2
3


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

インターフェイスがまだ変更中の場合、ドキュメントエージェントを早めに開始しても、手戻りが生じるだけです。マスターエージェントは、各ノードの完了後にコミット SHA を保存し、この最終バージョンをダウンストリームに渡す必要があります。

Worktree の依存関係とポート分離

ノードプロジェクトでは、複数の作業ツリーが書き込み可能な node_modules を共有できるようにすべきではありません。パッケージキャッシュは共有できますが、インストールディレクトリは共有できません。データベースは、エージェントごとに独立したスキーマまたはコンテナを作成します。

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

他のエージェントは、異なるポート、データベース名、および一時ディレクトリを使用します。このようにして、テストが失敗した場合、ログは唯一のタスクに対応することができます。

マージ前に機械可読な引き継ぎメモを生成する

各サブエージェントが完了すると、ブランチ、開始コミット、終了コミット、変更されたファイル、テストコマンド、および未解決の問題が返されます。

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

マスターエージェントは、Git およびテストログからこれらのフィールドを検証します。自然言語では、「すべてパス」ではゼロ以外の終了コードをカバーできないと主張しています。

本当の対立を生み出す

2 つのワークツリーで同じタイプの定義をそれぞれ変更し、1 つはフィールドを追加し、もう 1 つはフィールドの名前を変更します。最初のブランチをマージした後、2 番目のブランチでリベースを実行します。

1
2
3
4


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

競合リゾルバーは、独自のテストを実行するだけでなく、両方のブランチのテストを再実行する必要があります。型チェックに合格したら、読み取り専用レビューエージェントにマージされた結果を 2 つのタスクの説明と比較させます。

スケジュールされたタスクの切り替えを無効にする

各スケジュールされたタスクには、コードの変更を必要としない非アクティブ化エントリが必要です。トリガーが制御不能になると、まずスケジューリングが無効になり、次に開始されたインスタンスが処理されます。

次回の実行時間、最後の成功時間、連続失敗の回数、および現在のロック所有者を記録します。連続した失敗がしきい値に達すると、スケジュール設定を停止し、人間に通知します。エージェントが生成するエラーを永久に修復させないでください。

フック出力コントラクト

フックの戻り値により、人間とエージェントの両方が結果を判断できます。チェック名、対象のコミット、終了コード、検出結果の数、レポートのパスを出力することをお勧めします。

1
2
3
4
5
6
7


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

疑わしいキーのテキストを標準出力に出力しないでください。レポートは、フィンガープリント、ファイルパス、および行番号を使用して検索されます。元のテキストを表示するには、より高い権限が必要です。

ブラウザエージェントのテストデータのクリーニング

自動的に作成されたアカウント、注文、アップロードされたファイルにはすべて実行 ID があります。クリーンアップタスクでは、テストテナント内のその ID を持つデータのみが削除され、「今日作成されたすべてのオブジェクトを削除する」などの広範な条件は使用できません。

クリーンアップが失敗しても、メインテストが成功を示すことはありません。ビジネステスト結果とクリーニング結果はそれぞれレポートに記録されるため、テスト環境にデータが蓄積していることを担当者が発見しやすくなります。

並列処理の数を減らす必要があるかどうかを決定します

待機時間、競合率、失敗した再実行、手動レビュー時間に関する 3 回連続の統計。エージェントが同じインターフェイスまたは共有テスト環境で大量に待機している場合は、多くの場合、並列処理の数を 3 から 2 に減らす方が高速です。

タスクが 1 つの作業ツリーで 10 分以内に順番に完了できる場合、並列化のために余分な分岐、移植、およびマージのプロセスを設定する価値はありません。