开发工具

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 大量等待同一个接口或共享测试环境，把并行数从三降到二通常更快。

当任务可以用一个工作树按顺序在十分钟内完成时，不值得为并行建立额外分支、端口和合并流程。