编者按： 当 AI 不仅能写代码，还能同时处理多个开发任务，软件工程师这一角色是否正面临根本性的重塑？
我们今天为大家带来的文章，作者的核心观点是：并行智能体是将深刻改变软件开发模式的革命性技术。
作者从 AI 编程工具的演进谈起，揭示了从 Copilot 的代码补全到"氛围编程"的自然语言生成，再到当前的范式突破 ------ 并行智能体。作者还坦诚分享了实际应用中的成功率分布，指出了智能体擅长与不擅长的任务类型，并强调了全栈技术、问题拆解和代码审查等技能在新工作流中的核心地位。最后，文章提出了支持并行智能体的工程实践，包括快速 CI/CD、完善文档和单体仓库架构等关键要素。
作者 | Igor Šarčević
编译 | 岳扬
我在这个行业摸爬滚打多年，目睹各种技术浪潮翻涌又退去。见过人们对新框架的热烈追捧，听过革命性工具许下的承诺，也见识过那些声称要"颠覆一切"的夸张预言。但大多数时候，这些技术最终不过是营销话术包装下的渐进式改进。
但并行智能体（parallel agents）呢？这次完全不同。这是我从业以来第一次能够毫不夸张地说，我们正在见证一种将深刻重塑软件开发模式的技术。
01 发展历程
要理解当下，我们需要回溯 AI 编程辅助工具的完整演变过程。这一历程的起点是 GitHub Copilot，它首次将 AI 结对编程的概念带入现实。这款工具能在你键入时自动补全代码 ------ 推荐函数功能、完善实现逻辑、协助处理重复性任务。
随后出现的 Windsurf 和 Cursor 等这类 AI 驱动的编辑器，将这一理念推向新高度。它们将 AI 深度集成至开发环境中，不再局限于自动补全，而是允许开发者与 AI 直接对话：讨论代码逻辑、寻求重构方案、获取调试建议。此时的 AI 已能理解整个代码库，提供真正贴合上下文的辅助。
今年，我们进入了所谓的"氛围编程"（vibe coding）时代 ------ 只需使用自然语言描述需求，AI 工具就能从零生成完整函数、类或整个实现方案。当你说出"创建支持谷歌登录、GitHub 登录和微软登录的注册表单"，它便能输出符合预期"氛围"的可运行代码。
"氛围编程"这一术语由安德烈·卡帕西（Andrej Karpathy）在下列这段推文中首次提到，它精准地捕捉了这种编程新范式的使用体验：
有一种编程新范式我称之为"氛围编程" ------ 开发者只需沉浸于"氛围"之中，拥抱 AI 辅助编程工具所带来的指数级效能提升，甚至无需在意代码本身。这之所以成为可能，是因为 LLM（例如搭载 Sonnet 的 Cursor Composer）已强大得超乎想象。我现在甚至直接通过 SuperWhisper 与Composer 对话...
--- 安德烈·卡帕西 (@karpathy) 2025 年 2 月 2 日1
这种突破无疑是革命性的。突然间，生成样板代码、构建简单函数、创建 UI 组件乃至处理复杂的代码实现，都只需通过语言描述即可完成。 许多工程师使用这些工具后，发现它们在处理特定类型的工作时展现出超乎想象的实用价值。
这项技术已经成熟到足以改变我们许多人的编程工作方式：开发者不再需要从零开始搭建代码框架，而是直接基于 AI 生成的可用代码雏形进行迭代优化。这使得原型设计可以更快完成，减少了重复编码的枯燥劳动，为高效开发开辟了全新可能。
02 并行运行智能体
现在的突破在于：你可以同时运行多个 AI 智能体，让它们各自处理不同任务。无需等待一个智能体完成工作后再启动下一个，您可以同时运行多个智能体 ------ 一个构建用户界面，另一个编写 API 接口，第三个创建数据库模型。
其核心优势很简单：实现真正的多任务并行处理。这并非源于更聪明的 AI 或更优的算法，而是并行化能力的突破。使用的仍是之前的氛围编程工具，只是现在能同时运行多个实例。
首个提供成熟解决方案的是 GitHub 推出的运行在云端的 GitHub Co-Pilots。你只需在 Github 代码库中创建 issue 并描述需求。当你确认需求描述都已准备就绪，足以清晰定义该功能时，就可以将其分配给 Co-Pilot，然后等待处理结果。
在实际应用中，这意味着你可以遍历现有的 issue，判断其是否具备交由 AI 处理的完整上下文。之后只需等待系统发送通知并对结果进行审核就行了。
这彻底改变了我们的编码方式。我们不再纠结于具体实现步骤，而是扮演起资深工程师的角色，为多个正在代码库中实现具体功能的智能体提供指导和所需的上下文。 工程师的工作职责现在转变为审查代码的正确性、确保架构决策合理、验证实现的功能符合用户预期，并保证代码满足所有必需的安全与合规标准。
但智能体本身仍存在与氛围编程相同的局限性，它们同样可能产生错误、缺乏足够的上下文或无法理解代码逻辑。但此时工程师（某种程度上还兼具产品负责人和设计师的角色）需要引导整个系统为你实现目标。
03 如何运用并行智能体工作
并行智能体正在重塑工程师的工作方式。现在你无需逐项处理任务，而是可以协调多个智能体同时开发不同功能或修复各类缺陷。你需要主动管理多个开发流程，在智能体完成每项工作时进行代码审查与反馈指导。
采用这种方法后，我能同时管理 10-20 个开启状态的拉取请求（pull requests），每个都由专属智能体负责处理。
以下是一些可遵循的实践步骤：
1. 准备具有充分上下文信息的 issues
首先确保每个 GitHub issue 都包含足够的上下文信息，让智能体理解需要构建的内容及其与系统的集成关系。这可能涉及功能行为描述、文件路径、数据库结构等细节，或诸如显示特定字段、处理边界情况等具体要求。
2. 将 issues 批量分配给智能体
准备就绪后，将 issues 分配给 AI 智能体（例如 @copilot）。每次分配通常会新建一个拉取请求，智能体将在此制定实施计划、创建检查清单并开始执行。支持批量分配多个 issues，实现智能体并行工作。每个智能体通常需要 5-20 分钟完成其工作。
3. 在本地审查并不断迭代
智能体完成任务后，请在本地环境审查生成的拉取请求（PR）。必须进行功能测试与正确性验证。若需要调整，可在拉取请求中留下注释或反馈，智能体会持续优化解决方案。
4. 保持审核流程畅通
与传统工作流程不同，并行智能体的调度机制能让工程师始终保持高度专注的状态。现在无需等待单个智能体完成任务，即可在多个活跃的拉取请求之间灵活切换 ------ 根据需求随时进行代码审查、功能测试与反馈指导。这种工作模式让我们能在多个任务上同步推进，且不产生过重的心智负担。
04 对并行智能体的合理预期
使用并行智能体需要完全区别于传统编程或氛围编程的思维模式。这一转变的重要性，不亚于最初从传统编程转向 AI 辅助开发。
4.1 思维模式转变
控制方式从精确操控转向全局调度。 你不再需要掌控每一行代码，而是同时管理多个任务。要以系统工程师管理 Kubernetes Pod 的思维来运作 ------ 每个任务都是可替代、可重启的单元，而非需要精心呵护的独立服务器。
所有操作转为异步模式。 与需要实时等待反馈的氛围编程不同，并行智能体默认是异步工作的。此刻输入的上下文将决定半小时后的产出结果，你无法像过去那样随意给出模糊指令再中途修正 ------ 因为每次调整都要等待一小时才能收到反馈。
批量处理思维替代线性处理思维。 不必从待办清单内精挑细选某一个"完美任务"，而应找出一天内能协同推进的多个问题。推荐采用"2+5"模式：集中精力攻克 2 项关键任务的同时，并行处理 5-10 个后台小任务 ------ 诸如文案调整、界面优化、解决次要 Bugs 这类可以在你专注核心工作时自动处理的事项。
4.2 实际成功率
别指望 100% 的成功率。根据我使用并行智能体进行编码时的个人观察，成功率分布如下：
- 10%：一次生成完美方案，可直接交付。
- 20%：接近完成，仅需约 10 分钟的本地微调。
- 40%：需要人工介入修正。
- 20%：完全偏离方向，需关闭 issue 并记录经验教训。
- 10%：产品方案本身存在缺陷。
即便只有 10% 的任务被智能体完美解决，这个过程依然极具价值。智能体可靠地承担了基础工作 ------ 定位文件、编写样板代码、添加测试用例。当你进行审查时，大量基础工作已完成，使你能专注于排查和修复特定问题。
当工程师对编码智能体应有何种表现没有合理预期时，挫败感便会油然而生。有些工程师若得不到完美的解决方案便会直接放弃。我认为应该突破这种思维局限，学会提取智能体的有效产出，并在需要时运用工程知识介入修正。
4.3 优势与短板
并行智能体擅长处理：
- Bugs 的修复与竞态条件问题的处理
- 后端逻辑、控制器模块（译者注：负责接收前端请求、协调不同服务组件并返回响应的代码模块。）与验证逻辑
- 数据库变更与迁移脚本
- 依赖包版本升级与代码结构转换
- 目标明确的小型任务
它们处理以下情况则比较困难：
- 全新的 UI 开发（通常需要实时视觉内容反馈）
- 需实时视觉内容反馈的任务
- 为已存在的 PR 补充未明确写入文档的需求或隐含逻辑
- 需要综合考量超出 issue 范围的上下文内容才能完成的复杂架构决策
4.4 在新的编程范式下，重要性提升的技能
在并行智能体环境中，这些传统技能价值倍增：
全栈理解能力非常重要。 若你仅精通前端或后端，将会很快遇到瓶颈。智能体通常需要跨越整个技术栈的指导 ------ 从数据库迁移到 UI 更新，贯通前后端才能确保协作顺畅与产出质量。
问题拆解能力成为一项核心技能。 庞大复杂的问题难以被智能体有效处理。将大问题分解为定义清晰的小任务，可使智能体独立并行工作，从而提升整体产出效率，同时也让代码审查与集成工作变得更轻松顺畅。
书面表达能力变得很重要。 智能体依赖你清晰详细的 issue 描述来产出准确的结果。请避免使用模糊的语言、不必要的术语或模棱两可的需求。指令越具体有条理，智能体的输出质量越高。
质量保证和代码审查技能在此工作流中占据核心地位。 由于审查周期是主要瓶颈，快速评估代码质量、发现缺陷及验证需求是否实现的能力变得尤为关键。高效的测试与验证能确保并行开发不会堆积未审查或存在故障的代码。
使用并行智能体工作时，必须优化审查速度。 你可以同时启动 50 个任务，但仍需逐一审查、理解与验证。让审查周期变得快速（理想情况下能在 10 秒内完成检出、重构与测试）已成为整个工作流的关键所在。
05 实现并行智能体的工程实践
要有效运用并行智能体，需要一个架构良好、能支持快速迭代与审查的工程环境。
5.1 快速的 CI/CD Pipeline
稳健的 CI/CD 流程能轻松验证产出结果。当智能体完成工作后，你需要快速验证这些代码变更是否正确生效，同时避免人工部署带来的额外负担。自动化测试、快速构建和无缝部署流程能有效消除审查环节的阻力。若缺乏这些基础支撑，瓶颈就会从智能体的生成效率，转移至部署和测试阶段。
5.2 系统文档
当多个智能体在代码库的不同部分同时工作时，系统架构文档就变得至关重要了。智能体需要理解组件间的交互方式、文件存放路径、遵循的规范标准以及系统间的集成关系。完善的 API 文档、架构决策记录、编码规范与系统职责范围说明，能帮助智能体做出更准确的判断，减少人工修正需求。
5.3 预览与预发布环境
需要可靠的预发布环境用于人工测试智能体实现的功能。由于智能体采用异步工作模式，必须有一个稳定的预发布环境来验证其输出，且不影响生产系统。该环境应贴近生产环境配置，支持快速部署，并允许轻松测试多个并发的代码变更。为不同分支或拉取请求（PR）快速创建独立环境的能力，能极大优化并行审查流程。
5.4 单体仓库（monorepo）架构优势
采用单体仓库（monorepo）架构存放关联服务与组件，更适配并行智能体的工作模式。这种架构让智能体在单一代码库中即可获得整个系统的上下文。
当智能体需要跨多个代码库操作时，它们会失去对服务间交互、共享库与依赖关系的上下文认知，这将导致生成的解决方案在独立环境中可以运行，却会破坏系统间的集成接口。而单体仓库使智能体能通览完整的变更范围 ------ 在同一 PR 中同步更新 API 的规范定义、调整客户端代码、修改可复用的工具类代码。
统一的视角有助于做出更好的架构决策。智能体可参照现有的设计模式、复用通用的组件，并确保整个系统的一致性。代码审查也变得更加有效，因为所有相关的代码变更都集中在一处可见，便于验证智能体是否引入了集成部署时才会出现的问题。
对于并行开发，单体仓库简化了部署与测试流程。我们无需跨多个仓库协调发布，就能整体测试系统变更并实现原子化地部署。当需要跨越多服务边界，去管理多个由智能体并行产生的代码变更时，这种（单体仓库）做法能有效降低复杂度。
06 支持并行智能体的工具
目前已有数款开发工具支持运行并行智能体，它们各具特色，成熟度也各不相同。
GitHub Agents 提供最成熟、最完善的体验。它们直接集成在 GitHub Issues 中，并与 VSCode 无缝协作。只需将任务指派给 @copilot，智能体便会创建可供本地审查的 PR。虽然仍存在部分待优化的细节，但 GitHub 正通过持续迭代逐步解决这些问题。
Cursor 目前正通过测试计划探索并行智能体的支持。该团队已邀请部分用户体验此功能，初期反馈显示其实现方案颇具潜力。若你已使用 Cursor 进行氛围编程，待其更广泛地开放访问权限后，不妨关注一下他们的并行智能体。
OpenAI 的 Codex CLI 同样支持在云端运行智能体，从而实现此类并行开发工作流。该命令行工具可启动持续在远程运行的智能体，使您能够管理多个并发编码任务，而无需占用本地环境资源。
每款工具对并行执行的实现思路略有差异，最佳选择取决于你现有的开发流程与工具偏好。
07 总结与展望
我使用并行智能体已有数周，它彻底改变了我的开发模式。能够同步处理多个问题而非依次解决，实实在在地提升了生产效率。
这项技术目前并不完美 ------ 我们仍需花费时间审查与修正智能体生成的代码。 但当我们能同时启动十项任务，且其中大部分无需直接干预便能推进时，它便为我们腾出了宝贵的精力，让我们能专注于那些真正需要人类判断的问题。
如果你对尝试这种方法感到好奇，建议从待办清单中挑选小型的、定义明确的任务开始。编写清晰的描述文档然后观察运行结果。最坏的情况不过花费几分钟审查未达到预期的代码，而最好的情况则是你或许将找到契合自身风格的全新工作范式。
END
本期互动内容 🍻
❓文章提到，工程师的角色正从"编码者"转向"调度与审查者"。在你的工作中，是否已经感受到了这种变化？
文中链接
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：