基于 Git Worktrees、Conductor 与 Antigravity 2.0 的并行编码代理
利用 Git worktrees、Conductor 与 Antigravity 2.0 构建的并行编码系统：一个协调器、每个代理一个 worktree，再加上十余项 SRE 功能，仅需大约五小时即可实现。
来源: Orchestrating with Antigravity: A Crescendo of Agents (Part 2)
从终端操作到可视化工具
如果2025年是AI智能体的年份，那么2026年似乎将成为多个智能体协同工作的时代，一位谷歌工程师早先就预测这将是智能体编排的年份。对于那些一直依赖终端工作的人来说，问题很快就会显现。试图协调一组并行运行的子智能体来开发一个简单的时钟游戏，使用tmux分屏、从代码仓库拉取代码，还在显示器上贴便签来记录每个运行任务的内容，最终让一切变得混乱不堪。
这张照片展示了几台macOS桌面，上面布满了带有便签的agy终端，很好地展现了在没有合适工具的情况下管理并行智能体工作空间的状况。
利用多智能体框架构建应用程序的想法源自2026年6月的一篇帖子，该帖子展示了如何通过一个指令生成四个并行工作的开发智能体，并在两分钟内生成可运行的应用程序。虽然功能固定的命令行工具非常适合单线程任务，但多个同时运行的智能体流——每个智能体都有独立的分支、检出机制以及协调反馈循环——无法被容纳在扁平的回滚缓冲区中。正因如此，接下来的步骤便是转向Antigravity 2.0桌面应用程序。
该应用将所有内容按项目分组，相当于一个文件夹，然后在每个文件夹下按最新顺序列出相关任务。个人项目可能包含一个添加带隐藏密码的蓝色登录按钮的任务，以及另一个添加/checkout/后端路由的任务；而工作项目则包含编写doc/PRD.md和添加安全测试的任务。这些任务可以被归档，这样即使重启系统它们也不会丢失，人们也就不再需要实体便签了。
一旦可视化工具框架能够正常使用，接下来的问题就是扩展性。单个沙箱和简单游戏还算容易处理。这套架构还能将桌面应用扩展为支持12个工作流的SRE模拟系统，它使用Git工作树、名为Conductor++的Rails风格调度器以及名为Agostina的客服代理。
插图展示的是一名开发者手持潘妮通蛋糕，试图掌控着一堆工作树子代理的情况。
引发这一切的提示
灵感来源于一个简洁的提示，旨在让一小支客服团队开发出一款酒店房间预订应用。
Let's build a hotel room booking app [..].
First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.
Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS> to interact with the API <details>.
[..] How to sync the 3 sub-agents [..]
Finally, spin up both components and a browser so I can test the live app.
仔细阅读就能了解其中的内容：
- 所需产品的描述，此处为酒店预订应用
- 由三名子代理组成的团队
- 他们之间互动的顺序与时间安排
- 当系统为未深度参与流程的人启动以便检查时会发生什么
- 最重要的一点：共享的文件状态，即公共文件
architecture.md
该图表展示了该示例中各代理之间的互动方式。这属于纯粹形式的元编程。提示词并未描述代码本身，而是描述了将编写代码的团队。而这些代理通过 Markdown 文件进行交流，这意味着规范本身就是沟通渠道。
关于并行架构的设想更进一步：通过 GitHub Issues (GHI) 触发执行，这样每个子代理就能处理真实的工单。
工作流的构成要素
该架构由多个部分组成。
- 问题集成。一旦有相关问题出现，每个子代理都应开始处理该问题。
- AI 的框架支持。Conductor 扩展为代理任务提供了明确的边界规范。仅凭一个问题往往不足以让代理采取行动，有时需要人工介入（HITL）来回答关键问题，这样才能避免执行过程中出现“我当然只是指已认证用户”之类的疏漏。
git worktree。工作树可以防止两个或多个代理破坏同一个仓库。当有N个代理在远程分支上提交拉取请求时，设置一个负责将代码合并到主分支的git服务端也很有必要。这个角色的处理方式应当谨慎保守。当代理X试图发布功能X时，该服务端必须保持冷静，成为保障一致性的最后一道防线——因为代码可能没有问题，但却可能在未运行测试或未更新变更日志的情况下就被发布，而新的上下文窗口能够很好地发现这类问题。为了在多个代码库中复用这套方案，相关的规则和自动化流程被整合到一个开源代理技能中，即conductor-worktree-hitl，昵称为condutree。它的核心组件包括：
- 用于异步实现的
git worktree，每个工作树对应一个子代理，同时还有一个Conductor跟踪任务
using-git-worktrees 功能，实现工作树的自动隔离将此功能视为独立技能而非直接在协调器提示符中输入git命令，主要有三个原因。首先，所有低级的工作区设置、符号链接以及git排除规则都可以集中在一个易于维护的脚本中。其次，协调器提示符保持简洁，仅用于从主代理分配任务给子代理并解答问题，这样代理就不必纠结于git语法。第三，其他开发者可以将该技能引入自己的仓库和工具中，从而在无需重写集成脚本的情况下实现无冲突的并行运行。
拥有该技能的代理会学习四项内容：
- 如何为并行任务创建独立的worktree
- git维护技巧，即通过符号链接方式处理共享的Conductor元数据文件夹，并在本地将其排除，从而使
git status显示清晰 - 一种双重递归HITL协议，可用于发布问题评论、读取本地注册表以及轮询答案，同时不会耗尽API配额
- 如何进行本地提交并将审批记录作为Git注释保存，而无需直接推送到远程服务器
1.0版本已构成坚实的基础，2.0版本计划加入自动配置符号链接及更丰富的辅助脚本功能。
这幅由AI生成的插图描绘了“厨房里厨师太多”的情景：在没有工作树隔离的情况下，众多编码子代理把一个分支弄得一团糟。
压力测试：SRE事故模拟器
为测试并行执行的能力极限，该模型被应用于一个真实的SRE自动化与事故处理模拟器中。测试对象并非简单的演示应用，而是一个能够审计云环境并同时协调多个独立工作空间内事故处理的多智能体系统。在实现无冲突运行之前，必须先解决一些Git版本管理规范及文件命名方面的问题。
- 符号链接污染问题。在Conductor++架构中，每个并行智能体都有独立的个工作目录，例如
.worktrees/telegram_incident_creation/。由于子智能体会将元数据反馈给协调器，因此根目录conductor/会通过ln -s ../../conductor conductor命令被符号链接到每个工作目录中。除该文件夹外，其他所有内容因工作目录不同而有所差异，且由于每个任务都存储在各自的conductor子文件夹中，因此几乎不会出现合并冲突。 - 协调员。负责管理的首席Git管理员名叫阿戈斯蒂娜，她是个冷静且条理清晰的意大利人，靠咖啡因保持高效工作状态，能够让马里奥和路易吉等子代理协同工作而不互相干扰。她特意选择意大利国籍，而且她的名字听起来有点像“反重力”。
- 记录员。这名名为“Amanuense”的专职代理源自拉丁语中的“抄写员”一词，它会将目录创建、代码更改以及代理之间的交互记录连同精确的时间戳一起存入一个中央审计文件中，这样就能查看谁在何时于哪个工作树中做了什么操作。这个系统的设立是为了检测子代理之间的同步效果，并为后续报告提供准确的时间戳和日志记录。
在一个仓库中运行多个AI代理需要严格的隔离机制以及无竞争的通信方式。
在这里，Agostina负责合并Mario和Luigi的修改，而第三个黄色子代理则在其自己的工作树中继续进行操作。
维持仓库秩序的规则
有几项设计决策起到了关键作用。
- 禁止直接推送到远程仓库。如果多个子代理同时执行
git push，会导致远程引用出现锁定冲突，还可能将未经测试的代码引入生产环境。子代理仅能向本地的feature/分支提交代码，并撰写总结性的git备注。只有协调员才有权限推送代码、检出验证分支以及合并功能分支。 - 双重递归问题处理机制。如果多个子代理同时提问，单个全局的
questions.json文件会导致写入冲突。为此，每个子代理会将自己的问题写入其私有的跟踪文件夹（conductor/tracks//metadata.json），这种方式完全避免了冲突。同时，该子代理还会以包含唯一追踪标识的GitHub问题评论形式提交问题。Agostina的轮询脚本首先检查是否有本地跟踪项处于awaiting_human状态，如果没有，则完全跳过对GitHub API的调用，从而节省超过95%的配额。当GitHub上出现匹配的答案后，本地元数据状态会变为answered，进而唤醒对应的子代理。 - 一种共享的维基式记忆机制。无需将整个项目历史都存储在每个子智能体的上下文中，共享的
conductor/目录便充当了持久化内存的角色——这是一个结构化的本地目录，智能体可以像操作维基页面一样对其进行读写。这一设计呼应了Andrej Karpathy关于大语言模型记忆的著名观点，也解决了人们普遍担忧的难题：若智能体记忆管理不善，就会让辅助工具变得功能受限。 - 级联冲突解决。当已完成开发的特性分支逐一被合并时，可能会出现级联冲突现象。马里奥的分支可以顺利合并到验证分支中，但路易吉的分支却存在冲突。如果由人工来解决路易吉在验证分支上的冲突，那么其工作树中的原始特性分支仍会保持冲突状态且过时。为避免这种状况，阿戈斯蒂娜会手动选择合适的解决方案并重新合并到路易吉的分支中，从而使该独立的工作树与已验证过的代码保持一致。
- 通过拉取请求而非直接推送到主分支。若将已合并的验证分支直接推送到
main，则会绕过审查流程，因此集成工作需通过PR来完成。子代理在本地进行提交，Agostina负责拉取代码、在本地进行验证与合并，一旦集成测试通过，她就会推送统一后的分支，并运行gh pr create --title “feat: ...” --body “...”命令。随后，人工审查员可通过GitHub自身的界面查看代码差异及CI检测结果。Agostina会将PR的URL记录在注册表的metadata.json中，并通过gh pr list和gh pr status命令显示实时状态。 - 因概念冲突而终止。两个任务路径可能在逻辑上互不兼容，例如一个实现了某种功能，而另一个则以不兼容的方式对其进行了重构。如果阿戈斯蒂娜发现这种情况，她可能会立即终止其中一个存在冲突的子代理。必须将该终止操作记录在该代理的问题记录中，并将该问题与另一个代理的问题关联起来，以便保留清晰的决策轨迹。这种情况仅发生过一次。
协调生命周期
人类操作员从不直接与子代理交流。它们在其工作树中完全独立运行，操作员仅在两个时刻与协调器沟通：启动运行以及回复HITL监控器转达的问题。
流程图展示了代理与子代理的生命周期，共分为六个步骤：
- 启动。操作员开始运行任务。
- 状态读取。Agostina负责审核活跃的 GitHub 问题以及 Conductor 的任务状态。
- 资源准备。她会创建隔离的工作树，并生成并行运行的开发者子代理。
- HITL 监控器。子代理拦截的问题会被转交给人类处理，处理后的答案再反馈给子代理，从而保持反馈循环的安全性与异步性。
- 清理工作。当子代理完成任务并提交 Pull Request 后，Agostina会删除临时工作树目录。
- 合并到主分支。她会整合这些变更，提交或合并最终的 Pull Request，之后再回到清理步骤处理剩余任务。虽然这个过程可能相当复杂，但代理在处理 Git 合并方面比人类更高效。
回答问题这一功能仍处于高度实验阶段，目前已尝试了三种方法。其中一种方法是使用 Telegram sidecar bridge 作为后台守护进程，通过 Telegram bot 将问题或数据库修改请求发送到开发者的手机，并定期轮询回复。
图表展示了异步的 Telegram 流程。其优点在于以移动端优先的方式处理问题和审批，由于问题存储在各自的目录中，因此不存在文件锁竞争问题，同时还能保留审计轨迹，因为每个决策都会以 JSON 格式保存在仓库中。最简单的方法是通过 questions.json 与主代理通信，但该方法因无法自动解除阻塞且需手动触发而被舍弃，不过未来可通过钩子功能或更新来解决这一问题。
案例研究：五小时内处理十二个 SRE 任务
该测试平台是一个基于SRE扩展构建的Web应用。其众多功能均可并行运行：用户界面、后端接口、由大语言模型支持的聊天助手、Telegram机器人、OpenTelemetry监控工具以及GCP资源的发现功能。
这项工作涉及十二项复杂的SRE功能，它们被拆分成了二十多个具体的GitHub问题。随后系统开始自动处理这些任务。在大约五小时内，主要在无人监督的情况下，Conductor++流水线完成了所有功能的构建、测试，并将它们合并到主分支中。工作范围从在Cloud Run中设置OpenTelemetry追踪功能，到编写交互式的Telegram故障处理向导，以及用于审批待处理变更的注册系统。
集成与合并结果
在并行工作树编排机制下，每个功能模块都经过开发、测试，最终被集成到main分支中。
该表格展示了核心轨道的最终状态审计情况。此外还有8条正在运行的轨道被整合进来，涉及事件状态分类、事件删除与归档、维基项目互链、多环境状态管理、状态迁移至云端、响应式维基用户界面、实时GCP连接器以及待处理的变更。
运行两周后，可通过一个任务执行命令查看Conductor的状态，该命令会启动对代码库的检查工具并输出工作区概要。
$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short
🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS | PROGRESS | RATIO | GHI | AGENT | CHANGED | TRACK ID | 🌳
==============================================================================================================================
NEW | ░░░░░░░░░░ | 0/25 | #23 | | 💻 15days | managed_agents_sandbox_20260616 |
NOT_READY | ░░░░░░░░░░ | 0/17 | #22 | | 💻 15days | mcp_streamline_abilities_20260616 |
NOT_READY | ░░░░░░░░░░ | 0/11 | #15 | | 💻 15days | migrate_tf_cb_logic_20260616 |
NOT_READY | ░░░░░░░░░░ | 0/9 | #21 | | 💻 15days | ai_engineering_practices_20260616 |
NOT_READY | ░░░░░░░░░░ | 0/9 | #19 | | 💻 15days | workspace_agent_installation_20260616 |
NEW | ░░░░░░░░░░ | 0/15 | #31 | antigravity| 🐙 16days | disable_mock_fallback_dev_20260616 |
==============================================================================================================================
TOTAL | | 0/86 | | | | 0 completed, 6 open (6 total) | 0 🌳
工作流程时间线
通过逐步展示执行过程，可以了解协调员、记录员以及各个并行子代理是如何避免相互干扰的。
第一步：初始化轨道与工作树
在主机上，上级协调员准备了工作空间。随后，Conductor inspector CLI列出了所有活跃的轨道，并将它们分配给指定的子代理，其中一个负责处理Discord战室相关事务，另一个负责处理待处理的变异任务。一个包含所有轨道的标志使得同一工具能够显示每个并行工作空间的分支结构及代理状态。
./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all
初始化时捕获的终端输出如下。
================================================================================
CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
Worktree: .worktrees/issue-29-telegram-wizard
Branch: feature/issue-29
Agent: pinocchio
Status: AWAITING_HUMAN (Question: "Verify Telegram Token config?")
GHI URL: https://github.com/palladius/adk-sre-benjamin/issues/29
[Track: unified_incident_lifecycle_observability_20260607]
Worktree: .worktrees/issue-18-discord-warrooms
Branch: feature/issue-18
Agent: grazia
Status: RUNNING
GHI URL: https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================
在那个列表中，负责处理待处理变更的子代理被阻塞，正在等待HITL的回复。
一个自然的问题是GitHub问题与Conductor跟踪项是否为同一概念。它们是两种可能会出现差异的存储方式，有人要求开发代理来检测两者之间的差异。
截图显示了活跃工作树、分支以及子代理分配的概览。要使两者保持一致，只需发出一个指令即可——一种方式是让Conductor为每个问题创建一个新的跟踪项，并逐个处理所有相关问题；另一种方式则是确保每个Conductor跟踪项都对应一个GitHub问题。
详细视图则显示了正在等待GitHub问题端输入的待处理HITL问题。
步骤2：并行工作树隔离
每个代理都在自己的分支上工作，而记录员则完整地记录了文件修改内容和工作区事件，且不存在任何冲突。
这张截图展示的是并发开发过程中的工作树文件监控界面。
反重力线程追踪器显示了正在处理的任务，这样的画面足以让最初的“单指令、四子代理”演示版本也感到震撼。
步骤3：轮询与人工指导
当各子代理需要进一步说明时，它们会提交问题，由轮询脚本 poll_ghi_questions.py 进行解析。为便于在移动设备上实现人工指导，这些问题会通过Telegram侧边桥接工具传递。操作员无需坐在电脑前不断刷新GitHub页面，因为该桥接工具会将每个问题推送到手机上，以便随时快速批准。
截图展示了审批与诊断反馈循环的实际运行情况。
步骤4：最终的绿色状态
在每个功能分支都通过验证并依次合并之后，阿戈斯蒂娜提交了拉取请求，最终审计确认所有十二个SRE任务轨道都已合并到生产分支中。这些任务是否都经过了全面测试，包括它们之间的交互情况？并非全部，这将是后续需要处理的问题。还有一个名为Conductor At Scale的可视化工具，它能将普通的git历史记录转化为类似街机游戏的动画效果，通过JavaScript让Conductor的任务轨道在屏幕上依次出现。
本次实践的启示
第一个启示是尽可能让单个智能体负责所有沟通，只给子智能体分配无需交互的简单、预定义任务。有两种实践方式可以支持这一点。
- 尽量减少智能体与人类之间的等待时间。
/roastme命令是个好方法，它能提前提出棘手问题，让智能体能够持续运行，而Conductor则擅长离线收集问题。不必每五分钟就问一次30秒的问题，只需在30分钟的时间里把所有问题都答完，然后去骑自行车，回来时应用就已经处理完毕了。
那张截图显示的是在Conductor中运行的/roastme，包括其中的拼写错误在内。
- 保持智能体与子智能体之间的结构简洁。业内通常倾向于构建复杂的多智能体层级结构，但在2026年，更安全的选择是那些实施起来较为简单、可重复性高且歧义较少的任务，这样可以避免不必要的协调开销。
此外还有编排成本的问题。编写代码的成本很低，关键在于需求规格，而测试与结果验收则成了新的瓶颈。该领域的其他人士似乎也认同这一点。团队要么能领先于这一趋势，要么就会被其拖垮。
对于想要尝试这种方法的人而言，起点是Antigravity 2.0桌面应用，它能够直接提供可视化的多轨道编排功能。
相关阅读
- 家用气压计中的火山冲击波：来自29,334个气象站记录的早期预警 —— Netatmo气象站、兰姆波物理学以及人工智能代理如何定位火山口、估算爆炸威力，并在不会产生误报的情况下提前数分钟发出预警。