自主繁衍的AI开发团队兴起与技术架构解析

AI编码环境发展迅速，从简单的基于聊天的提示，到检索增强生成（RAG），再到最近的自主代理。每一步都提高了输出质量，同时也引入了新的工作流程模式。例如，基于代理的编码通常意味着更长的执行周期：代理自主工作一段时间后，再返回获取人类反馈。

这种转变类似于从同步的for循环过渡到异步、事件驱动的架构。现在不再是单一AI逐步工作，而是有多个并行编码代理独立运行并汇报结果——这既带来了速度，也带来了复杂性。

为什么要并行化？（速度与探索）

速度
第一个原因是我们希望加速编码过程。其理念是我们可以并行完成多个任务，然后合并结果。这几乎就是人类产品管理规划的工作方式：让不同的开发人员并行处理不同的功能，然后再将它们合并回来。

探索
但速度并非唯一原因。另一个可能更重要的好处是能够并行探索不同的想法。作为人类，我们会让多个人或团队执行相同的任务，并让他们采用不同的策略。这有助于创新过程，也能更好地理解解决方案空间。

“选项选择”的最初形式之一出现在gpt-engineer（现为Lovable）生成多个UI版本中。我们在第三个AI原生开发模式“从交付到发现”中捕捉到了这种模式，我们解释说交付无论如何都是自动化的，因此我们可以专注于发现新想法。

如何构建这种新的工作流程？

从规范到子任务（规划）
为了并行化，我们需要将大型规范分解为原子任务，以便代理可以独立工作。这就是推理代理扮演架构师和规划师角色的地方。

我们看到任务管理正成为代码生成工具的核心功能：

• Aider引入了架构师模式
• Task-master帮助分解你的PRD
• Claude Code拥有规划模式
• Roocode的编排器模式

审查与合并策略
一旦构建和编码任务完成，我们人类的工作又开始了。现在我们有多个任务结果需要审查！

人们正在试图弄清楚这将如何改变代码审查过程：

• 如何浏览所有并行实现？
• 提供对所有运行中的应用实例的访问？
• 帮助比较同一任务的不同输出？

因此，我们最终会处于一个混合了多个标签页和代码差异的状态，有些人使用颜色编码来标记不同的环境。

一些新兴工具正试图管理这种工作流复杂性：Async Code Agent、Crystal、CCManager、SplitMind、Claude squad、Claude Code crew，它们都有自己新的UI工作流程。

另一种方法是，当需要更多反馈时，从终端循环中打开IDE，例如Claude Code的VSCode插件。

此外，这引发了一个问题：我们能否也自动化审查？我还没有看到任何集成的具体实现，但我可以想象所有CI/CD审查工具在这里也能帮助我们。从AI工程中，我们肯定可以借鉴LLM作为裁判的概念。现在，除了构建应用程序的规范，我们还需要指定示例和指南来审查应用程序和更改。

风险与信任边界
说实话——并行代理并非没有危险：我们都知道LLM和代理可能会出错，并且如果授予错误的访问权限，可能会做坏事，例如删除你电脑上的所有内容。然而，如果我们想要委派任务，我们“被迫”信任并接受代理拥有更多的访问权限。否则，我们将不得不始终参与其中以批准代理的每一步。这就是为什么你会看到人们启用危险设置和YOLO模式。这也清楚地表明，我们必须减少可能的爆炸半径。

代理工作空间：隔离谱系
人类开发人员通常在各自的环境中拾取任务和编写代码。对于代理来说，这意味着我们也必须给它们自己的开发环境。让我们来看看工作空间隔离策略的谱系：从混乱到云原生。

工作空间策略	隔离度	可合并性	用户体验影响
多IDE窗口	低	手动	高
Git工作树	中	容易	中
开发容器/云	高	外部	低

多个IDE窗口（和屏幕混乱！）
我看到人们尝试并行化环境的第一种方式是启动多个IDE并将它们指向同一个代码库。这在echohive的视频“multiple Cursor Composer and Windsurf Cascade agents”中有所展示。这会产生很多窗口，导致屏幕混乱。你还需要一个清晰的目录分区策略，以避免它们都写入同一个位置。

这就是为什么人们开始转向无头执行或基于终端的编码执行。

用于隔离分支的Git工作树
你可以复制文件，但你真正想要的是复制带有版本控制的仓库，因为这将允许你稍后合并结果。Git实际上有一个集成的机制叫做git工作树。它允许你将git仓库克隆和分支到另一个目录中。我第一次看到它在行动是在Indydevdan的视频“Claude 4 ADVANCED AI Coding: How I PARALLELIZE Claude Code with Git Worktrees”中。

该机制也在Claude Code最佳实践页面（向下滚动）中有描述。此外，Claude Code能够生成子代理，仅仅通过在Markdown文件中描述并行过程，人们就让这个并行循环工作了。

人们记录了他们使用这种新颖工作流程的经验，值得一读：

• Claude Code for Parallel Development
• How I Use Claude Code, Start New Thread
• How To Wield Coding Agent Clusters
• Way Enough - Git worktree
• Parallel AI Coding with Git Worktrees
• LLM Codegen go Brrr – Parallelization
• Claude Code Was Surprisingly Well-Crafted and User-Friendly

我们还看到许多围绕这种新工作流程出现的工具（注意：许多是实验性的），例如Uzi、AI - fleet、Claude flow和Claude simone。

容器/开发容器在云或CI中的隔离
在CI/CD系统中，我们通常使用容器来封装构建。或者我们可以使用开发容器进行本地机器隔离。我们也可以将这一点应用于代理：我们给它们各自的机器，保持我们的本地机器清洁。此外，这允许我们通过云扩展机器能力并支持更复杂的技术栈。

我们在“First look at Cursor background agents”中看到了这一点（云中的多个代理：生成一个容器，从github仓库拉取代码，然后报告回来）。Claude也推荐使用容器或在开发容器中运行你的代理（参见此Claude配置）。

因此，某中心的一位前创始人正在研究优化工作流程，以启动容器并合并远程代理工作，这并不令人惊讶。你将容器使用作为MCP服务器提供给代理，它会生成多个容器。这现在也被诸如Claude parallel work这样的框架所使用。

例如：“使用Flask和FastAPI创建一个简单hello world应用的两个变体，每个都在自己的环境中。给我每个应用的URL。”
这将启动两个容器，让它们拉取现有仓库，开始编码，然后启动应用程序的预览版本。

并行化代理的进一步考量

知识整合
并行执行还不够。我们还需要共享内存，这样代理就不会每次都重新发明轮子：当系统学到东西时，我们希望它共享共同的知识。这可以改进代理未来的运行。

其最初粗糙的形式是代理更新一个共享的Markdown文件作为“共享”内存。我们开始看到这被外部化为共享内存服务的初步迹象。这些知识是代理产生的另一个工件，我们需要批准和审查。

我们需要确保知识是最新的且不冲突，就像规范和需求一样。知识的多样化也可以通过为不同任务使用不同模型来促进，在这里，每个模型除了编码的并行线程外，还会经历并行的思考过程。

从CI/CD到持续想象
如果我们认为可以将不同的变体展示给客户以获得反馈，会怎样？

在CI/CD中，测试和审查发生在构建系统上。现在，我们可以将这些构建系统作为我们代理编码的一部分。我们仍然需要弄清楚多个开发人员及其各自的开发代理集将如何协作和合并，但我们已经可以将部分流程左移。

这感觉非常类似于并行功能分支，或者对于最终用户来说是功能标志。这仍是早期阶段，我们正从“自动提交”迈向“自动部署”的第一步，而并行执行实际上将有助于结果的可重现性和共享。

这些并行执行框架可能为“持续AI”奠定基础——迭代、学习和部署在此形成一个无缝循环。所以这不再仅仅是持续集成，而是持续想象。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）或者 我的个人博客 https://blog.qife122.com/
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

公众号二维码