并行 AI 智能体：改变研发方式的技术革新
在这个行业待了足够久，见证了无数技术的兴衰更迭。见过新框架引发的狂热追捧，见过革命性工具许下的美好承诺，也听过那些宣称 “将改变一切” 的激动人心的预言。但大多数时候，这些技术不过是裹着营销噱头的渐进式改进。【AI大模型教程】
但并行智能体（Parallel AI Agents）不一样。这是第一次可以毫不夸张地说，正在见证一项将从根本上改变软件开发方式的技术。
一、发展历程回顾
要理解当下的技术现状，我们需要回顾 AI 辅助编码的完整发展史。一切始于 GitHub Copilot，它首次引入了 AI 结对编程的概念。在你打字时，Copilot 能自动补全代码、推荐函数、完成实现，还能处理重复性工作。
之后出现了 Windsurf 和 Cursor 这类 AI 驱动的编辑器。它们将 AI 深度集成到开发环境中，把这一概念推向了新高度。除了自动补全，你还能和 AI 围绕代码交流，寻求重构建议，甚至获得调试帮助。AI 能理解你的整个代码库，提供贴合上下文的辅助。
今年，我们开始接触一种名为 “氛围编程”（vibe coding）的方式，用自然语言描述需求，AI 就能从零生成完整的函数、类或实现方案。比如你说 “创建一个支持谷歌、GitHub 和微软登录选项的注册表单”，它就能生成可用的代码，完美契合你的需求氛围。
“氛围编程” 这个术语是安德烈・卡帕西（Andrej Karpathy）在 X 推文中提出的，精准捕捉到了这种新编程方式的核心体验：
“我把这种新的编程方式称为‘氛围编程’，完全沉浸在氛围中，拥抱指数级效率，甚至忘了代码本身的存在。这之所以可行，是因为大语言模型（比如搭载 Sonnet 模型的 Cursor Composer）已经变得太强大了。而且我现在还能用 SuperWhisper 和 Composer 直接对话……”
这无疑是具有革命性的。突然间，你只需通过描述，就能生成样板代码、构建简单函数、创建 UI 组件，甚至完成复杂的实现。许多工程师都采用了这些工具，并发现它们在特定类型的工作中极为实用。
这项技术的效果足够好，以至于改变了我们许多人的编程思路。不再需要从空白文件开始，你可以直接基于可用的实现方案进行优化。它加快了原型设计速度，减少了编写重复代码的枯燥感，为快速开发开辟了新可能。
二、并行运行智能体
现在的核心突破在于：你可以同时运行多个 AI 智能体，每个智能体负责处理不同的问题。无需等待一个智能体完成任务再开始下一个，你可以让多个智能体同步工作：一个负责构建用户界面，另一个编写 API 接口，第三个创建数据库模式。
核心优势很简单：能同时处理多项任务。这无关 AI 更智能或算法更优秀，关键在于并行化，还是之前的氛围编程工具，只是同时运行多个实例而已。
第一个提供成熟解决方案的公司是 GitHub，他们推出的云端 GitHub Copilot 就是如此。你只需在 GitHub 上找到一个问题并详细描述，当你认为描述足够清晰、能让 AI 理解所需功能时，将其分配给 Copilot，然后等待结果即可。
在实际操作中，你可以查看现有问题，判断是否提供了足够的上下文供 AI 处理。之后只需等待系统通知，即可查看并审核结果。
这彻底改变了代码编写方式。你不再需要关注微观的实现步骤，而是扮演资深工程师的角色，为多个在代码库中实现功能的智能体提供指导和上下文。作为工程师，你的工作变成了审核代码准确性、确保做出合理的架构决策、验证功能是否符合用户需求，以及保证代码满足所有必要的安全和合规标准。
智能体本身和氛围编程时一样存在局限性，可能会产生 Bug、缺乏足够上下文、无法理解复杂代码。但作为工程师（在某种程度上也是产品负责人和设计师），你可以引导系统完成实现。
三、如何与多个并行智能体协作
并行智能体正在改变工程师的工作方式。你不再需要一次专注于一项任务，而是可以协调多个智能体并行处理不同的功能开发或 Bug 修复。你需要主动管理多个开发流程，在每个智能体完成工作后进行审核并提供反馈。
通过这种方式，我可以同时处理 10 到 20 个拉取请求（pull request），每个请求都由专门的智能体负责。
以下是具体的操作步骤：
- 准备具备充足上下文的问题描述确保每个 GitHub 问题都包含足够的上下文，让智能体能理解需要构建的内容以及如何与系统集成。这可能包括功能行为细节、文件位置、数据库结构，或特定要求（比如：显示特定字段、处理边界情况等）。
- 批量分配任务给智能体问题描述准备就绪后，将其分配给 AI 智能体（如 @copilot）。每次分配通常会创建一个新的拉取请求，智能体会制定计划、创建检查清单，然后开始实现。可以同时分配多个问题，让智能体并行工作。单个智能体完成任务通常需要 5 到 20 分钟。
- 本地审核并迭代优化智能体完成任务后，在本地审核生成的拉取请求。测试功能并验证准确性至关重要。如果需要修改，可在拉取请求上留下评论或反馈，智能体会继续优化解决方案。
- 保持审核流程的连贯性与传统工作流程不同，并行智能体的协调能让你始终保持专注和高效。无需等待某个智能体完成，你可以在多个活跃的拉取请求之间切换。根据需要进行审核、测试和提供反馈。这使得多项任务能同步推进，且不会带来过多的脑力负担。
以下是实际操作的演示视频：“使用委托式 Copilot 智能体的体验太棒了，能并行处理 10 个拉取请求。GitHub 做得好👏”（附视频链接：pic.twitter.com/T6sCIBg6bH）
四、并行智能体的预期效果
与并行智能体协作，需要不同于传统编程或氛围编程的思维模式。这种转变的意义，不亚于从传统编程转向 AI 辅助开发。
4.1 思维模式的转变
控制权从 “精准掌控” 转向 “协调统筹”。你不再需要控制每一行代码，而是同时管理多个问题。思考方式要像系统工程师管理 Kubernetes 容器组，而非照看单个服务器，每个任务都是可替代、可替换的。
所有工作都变成异步进行。与氛围编程中实时等待和观察不同，并行智能体默认异步工作。你前期提供的上下文，将决定 30 分钟后的结果。不能再用敷衍的提示词，边做边改，因为这些修改要一小时后才能生效。
批量思维取代线性思维。不再从任务清单中挑选一个完美的任务，而是确定一天内可以处理的多个问题。一个好方法是：专注于 2 个关键交付项，同时运行 5 到 10 个小型后台任务，比如：文案修改、UI 修复、小 Bug 修复等，这些任务可以在你专注于重要工作时同步处理。
4.2 实际成功率
不要期望 100% 的成功率。根据我个人的编程经验，通常会出现以下情况：
- 10%：完美的一次性解决方案，可直接部署。
- 20%：接近完成，只需 10 分钟的本地优化。
- 40%：需要人工干预调整。
- 20%：完全错误，关闭问题并记录经验教训。
- 10%：产品思路本身有问题。
即使只有 10% 的问题能被智能体完美解决，这个流程依然有价值。智能体可以可靠地完成初始设置，找到正确的文件、编写样板代码、添加测试。等你进行审核时，大部分基础工作已经完成，你可以专注于排查和修复特定问题。
工程师的挫败感往往源于对编程智能体的期望过高。有些工程师如果没有得到 100% 完美的解决方案就会放弃。但我认为，你应该克服这种局限，学会提取有用的部分，在需要专业工程知识的地方主动介入。
4.3 适用与不适用场景
并行智能体擅长处理：
- Bug 修复和竞态条件问题
- 后端逻辑、控制器、验证功能
- 数据库变更和迁移
- 依赖包版本更新和代码转换
- 小型、定义明确的实现任务
它们不擅长处理：
- 新 UI 开发（构建过程中需要实时查看变化）
- 需要实时视觉反馈的任务
- 为现有拉取请求添加未记录的功能
- 需要超出问题描述上下文的复杂架构决策
4.4 变得更重要的技能
在并行智能体时代，一些传统技能变得更加宝贵：
- 全栈认知能力：与并行智能体协作时，全栈知识储备非常有价值。如果你的专业知识仅限于前端或后端，很快就会遇到瓶颈。智能体通常需要跨全栈的指导，从数据库迁移到 UI 更新，因此能够驾驭前后端的工程师能确保协作更顺畅、结果更优。
- 问题拆解能力：这成为核心技能。大型复杂问题很难被智能体有效处理，将大问题拆分成小型、定义明确的任务，能让智能体独立并行工作，提高整体效率，也更便于审核和整合成果。
- 书面表达能力：智能体依赖清晰详细的问题描述来生成准确结果。要避免模糊表述、不必要的术语或歧义性要求。指令越具体、结构越清晰，智能体的输出质量就越高。
- 质量保证和代码审核能力：在这种工作流程中，审核环节成为主要瓶颈。快速评估代码质量、发现 Bug、验证需求是否满足，这些能力至关重要。高效的测试和验证能确保并行开发不会导致未审核或有缺陷的代码堆积。
与并行智能体协作时，应优化审核速度。你可以启动 50 个任务，但仍需逐一审核、理解和验证。让审核流程快速高效，理想情况下，检出代码、重新构建和测试的时间控制在 10 秒内，这对整个工作流程至关重要。
“昨天使用 GitHub 并行智能体学到了很多：
- 我的思维模式还没适应与智能体的并行异步工作
- 不能期望 100% 成功，但可以进行一系列小额尝试
- 克服阻塞问题的策略
- 何时使用 Claude Code 以及……”（附链接：pic.twitter.com/yKNNkNZnby）
五、支持并行智能体的工程实践
与并行智能体协作，需要结构良好的工程环境，以支持快速迭代和审核。
5.1 快速 CI/CD 流水线
强大的 CI/CD 流程能简化测试和验证工作。智能体完成任务后，你需要快速验证变更是否正常工作，无需手动部署的繁琐操作。自动化测试、快速构建和无缝部署流程，能减少审核环节的阻力。如果没有这个基础，瓶颈就会从智能体完成时间转移到部署和测试时间。
5.2 系统文档
当多个智能体在代码库的不同部分工作时，系统架构文档至关重要。智能体需要了解组件间的交互方式、文件位置、遵循的规范以及不同系统的集成方式。完善的 API 文档、架构决策记录、编码标准和系统边界说明，能帮助智能体做出更好的决策，减少人工修正的需求。
5.3 预览和预发布环境
需要一个可靠的预发布环境来手动测试功能。由于智能体异步工作，你需要一个稳定的环境来验证它们的输出，而不影响生产系统。这个环境应与生产环境一致，部署迅速，并能轻松测试多个并发变更。为不同分支或拉取请求创建独立环境的能力，能简化并行审核流程。
5.4 单体仓库（Monorepo）架构的优势
将相关服务和组件集中在一个单体仓库中，更适合与并行智能体协作。单体仓库能让智能体在同一个代码库中获取整个系统的上下文。
如果智能体跨多个仓库工作，就会丢失关于服务交互、共享库和依赖关系的上下文，导致解决方案在孤立环境中可行，但在集成时出现问题。而在单体仓库中，智能体能理解所需的全部变更，更新 API 契约、调整客户端代码、修改共享工具库，所有这些都能在一个拉取请求中完成。
统一的视图有助于做出更好的架构决策。智能体能看到现有的模式、重用通用组件，并在整个系统中保持一致性。代码审核也更有效，因为所有相关变更都集中在一个地方，便于验证智能体是否引入了集成问题。
单体仓库还简化了并行开发的部署和测试。无需协调多个仓库的发布，你可以一起测试完整的系统变更，并实现原子化部署。这降低了管理跨服务边界的多个并发智能体生成变更的复杂性。
六、支持并行智能体的工具
现在有几款开发工具支持运行并行智能体，它们各有优势和成熟度：
- GitHub Agents：体验最完善，直接集成到 GitHub Issues 中，与 VSCode 无缝协作。将问题分配给 @copilot 后，智能体会创建拉取请求，你可以在本地审核。虽然仍有一些小瑕疵，但 GitHub 通过定期更新不断改进这些问题。
- Cursor：目前正在通过测试版程序尝试支持并行智能体。他们邀请了部分用户测试这项功能，早期反馈显示这是一个很有前景的实现。如果你已经在使用 Cursor 进行氛围编程，等它开放更广泛的访问权限后，值得一试其并行智能体功能。
- OpenAI 的 Codex CLI：也支持在云端运行智能体，支持这种并行开发工作流程。通过 CLI 启动的智能体能在远程持续运行，让你无需占用本地环境，就能管理多个并发的编程任务。
每种工具的并行执行方式略有不同，最佳选择取决于你现有的开发工作流程和工具偏好。
七、总结
我使用并行智能体已有几周时间，它彻底改变了我的开发方式。能够并行处理多个问题，而非按顺序推进，这对工作效率的提升是实实在在的。
这项技术并非完美无缺，你需要花费时间审核和修复智能体生成的代码。但当你能同时启动 10 个任务，并且大部分任务能在无需直接干预的情况下推进时，你就能腾出脑力，专注于那些真正需要人类判断的问题。
如果你好奇并想尝试这种方式，可以从任务清单中挑选一些小型、定义明确的问题开始。编写清晰的描述，看看结果如何。最坏的情况不过是花费几分钟审核无法使用的代码，而最好的情况是，你可能会发现一种适合自己开发风格的全新工作方式。
好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~
