Agent Manager
理解 Antigravity Agent Manager：workspace、conversation、Fast 与 Planning、Artifacts、异步多 agent 和人工反馈入口。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| Agent Manager | 代理管理器 | 委派和监督 agent 的中枢。 |
| 任务编排 | orchestrate | 管理多个 agent 任务。 |
| 监督 | oversee | 实时看进展和把关。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你搞清 Antigravity Agent Manager 这一组该怎么读、怎么用。
你是 Antigravity Agent Manager 导航顾问。
【角色】
Antigravity Agent Manager 导航顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的具体步骤或示例，不停留在「建议」「考虑一下」这类空泛表述。
【输入】
- 我想委派什么任务：___
- 是否多任务并行：___
- 对自动化的信任度：___
- 项目风险：___
- 经验水平：___
【工作流程】
1. 说明 Agent Manager 的作用
2. 给该组阅读顺序
3. 对应到我的委派需求
4. 标出把关要点
5. 给第一步
【输出规范】
▌一、作用
▌二、阅读顺序
▌三、对应需求
▌四、把关 + 第一步
【硬约束】
- 委派任务要边界清晰
- 并行任务也要逐个把关
- 高危操作审批
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或接口一律以官方文档为准，禁止照搬过时写法Agent Manager 是 Antigravity 和传统 IDE 侧边栏聊天最大的差异。它不是让你一直盯着一个 chat，而是把 agent 任务放进一个类似 mission control 的界面里，让你派发、观察、审阅和反馈多个异步工作流。
这一页解决什么问题：你要知道哪些任务适合丢给 Agent Manager，哪些任务仍然应该留在 Editor 里手工做，以及 Fast / Planning 应该怎么选。
1. Agent Manager 的定位
Google 发布文把 Antigravity 拆成两个主要界面：
| 界面 | 适合什么 | 你扮演什么角色 |
|---|---|---|
| Editor View | 同步编辑、inline command、小范围修改、查看 diff | 写代码的人 |
| Manager Surface / Agent Manager | 异步任务、多 workspace、多 agent、artifact 审阅 | 编排任务的人 |
这不是视觉布局差异，而是工作方式差异。Editor 是“我和 agent 一起改这个点”，Agent Manager 是“我把目标交给 agent，观察计划、执行和验收产物”。
打开 Agent Manager 后，新手最先要找的不是输入框，而是这三个导航：
| 入口 | 你在这里做什么 | 官方位置 |
|---|---|---|
| 左侧边栏 Workspace 列表 | 增删 / 切换多个项目；点 + 按钮新建 workspace；workspace 名旁的 + 开新 conversation | docs/workspaces |
| Inbox（收件箱） | 一站式查看所有 conversation——尤其是哪些在等你批准 terminal 命令、Browser 操作或 implementation plan | docs/inbox |
| Start Conversation 页 + Use Playground 按钮 | 不想新建 workspace 时，点 Use Playground 进独立 playground 立即开聊；做出有用产出再点 Move 一键搬到正式 workspace 保留对话和文件 | docs/playground |
Inbox 是新手最容易忽略但最重要的入口：长任务跑久了 agent 会卡在权限请求等你确认，你以为它"忘了"，其实它在 Inbox 里举手等你。养成"先看 Inbox 再开新 conversation"的习惯，可以避免漏批 / 误以为任务停滞。
2. Workspace 与 conversation
Agent Manager 的基本单位是 workspace 和 conversation：
flowchart TD
Manager["Agent Manager"] --> WorkspaceA["Workspace A"]
Manager --> WorkspaceB["Workspace B"]
WorkspaceA --> Conversation1["Conversation: 修登录页 bug"]
WorkspaceA --> Conversation2["Conversation: 增加测试"]
WorkspaceB --> Conversation3["Conversation: 文档重组"]
Conversation1 --> Artifacts["Artifacts / diffs / requests"]Workspace 决定 agent 可以看到和操作的项目范围。Conversation 是一个具体任务上下文。多 agent 异步工作时，最容易出问题的不是模型不聪明，而是你没有给每个 conversation 清晰边界。
3. Fast 与 Planning
Codelab 展示了两种对话模式：Fast 和 Planning。
| 模式 | 适合任务 | 不适合任务 |
|---|---|---|
| Fast | 重命名变量、运行几条命令、解释单文件、局部小改 | 跨目录重构、复杂 UI、数据库迁移、部署 |
| Planning | 深度研究、复杂功能、需要计划审阅、需要 artifacts 的任务 | 一两分钟能完成的微小修改 |
复杂任务默认用 Planning。你需要看到 implementation plan 和 task list，再决定让不让 agent 继续。
4. Agent Manager 适合的任务
适合派给 Agent Manager 的任务通常有几个特征：
- 需要多个工具：文件、terminal、browser、测试。
- 需要验收产物：截图、录屏、walkthrough、diff。
- 需要等待：启动 dev server、复现 bug、跑测试、爬页面。
- 可以独立边界：一个 bug、一个页面、一个模块、一条文档线。
示例 prompt：
在当前 workspace 中复现并修复设置页保存按钮无响应的问题。
要求：
1. 先输出 implementation plan，等我确认。
2. 修改范围限制在 settings 页面和相关测试。
3. 修完后启动本地服务，用浏览器完成一次保存流程。
4. 交付 screenshot、browser recording 和 walkthrough。5. 不适合派给 Manager 的任务
| 任务 | 更好的做法 |
|---|---|
| “帮我随便优化一下项目” | 先让 agent 只读审计，再拆成明确任务 |
| 涉及生产数据库 | 不让 agent 直接操作，先写迁移计划和回滚方案 |
| 涉及真实账号后台 | 人工操作或只读诊断，禁止默认提交 |
| 需要主观审美判断 | 先生成多个方案，再人工选方向 |
| 大范围重构全仓 | 拆成模块级 conversation，逐个验收 |
6. 观察 agent 的状态
Agent Manager 中要重点看四类信号：
| 信号 | 说明 | 风险 |
|---|---|---|
| Plan / task list | agent 准备怎么做 | 计划太宽会扩大改动面 |
| Permission request | agent 想执行什么动作 | 命令、URL、文件路径是否越界 |
| Artifacts | agent 用什么证明结果 | 没有截图/录屏的 UI 任务很难验收 |
| Diff | 代码实际改了什么 | 是否碰到无关文件或敏感配置 |
把 Agent Manager 当作任务看板，而不是聊天记录。你要审的是边界、证据和 diff，不是每一句中间输出。