我在這個行業(yè)摸爬滾打多年，目睹各種技術浪潮翻涌又退去。見過人們對新框架的熱烈追捧，聽過革命性工具許下的承諾，也見識過那些聲稱要“顛覆一切”的夸張預言。但大多數(shù)時候，這些技術最終不過是營銷話術包裝下的漸進式改進。

但并行智能體（parallel agents）呢？這次完全不同。這是我從業(yè)以來第一次能夠毫不夸張地說，我們正在見證一種將深刻重塑軟件開發(fā)模式的技術。

1.發(fā)展歷程

要理解當下，我們需要回溯 AI 編程輔助工具的完整演變過程。這一歷程的起點是 GitHub Copilot，它首次將 AI 結對編程的概念帶入現(xiàn)實。這款工具能在你鍵入時自動補全代碼 —— 推薦函數(shù)功能、完善實現(xiàn)邏輯、協(xié)助處理重復性任務。

隨后出現(xiàn)的 Windsurf 和 Cursor 等這類 AI 驅動的編輯器，將這一理念推向新高度。它們將 AI 深度集成至開發(fā)環(huán)境中，不再局限于自動補全，而是允許開發(fā)者與 AI 直接對話：討論代碼邏輯、尋求重構方案、獲取調試建議。此時的 AI 已能理解整個代碼庫，提供真正貼合上下文的輔助。

今年，我們進入了所謂的“氛圍編程”（vibe coding）時代 —— 只需使用自然語言描述需求，AI 工具就能從零生成完整函數(shù)、類或整個實現(xiàn)方案。當你說出“創(chuàng)建支持谷歌登錄、GitHub 登錄和微軟登錄的注冊表單”，它便能輸出符合預期“氛圍”的可運行代碼。

“氛圍編程”這一術語由安德烈·卡帕西（Andrej Karpathy）在下列這段推文中首次提到，它精準地捕捉了這種編程新范式的使用體驗：

有一種編程新范式我稱之為“氛圍編程” —— 開發(fā)者只需沉浸于“氛圍”之中，擁抱 AI 輔助編程工具所帶來的指數(shù)級效能提升，甚至無需在意代碼本身。這之所以成為可能，是因為 LLM（例如搭載 Sonnet 的 Cursor Composer）已強大得超乎想象。我現(xiàn)在甚至直接通過 SuperWhisper 與Composer 對話...

— 安德烈·卡帕西 (@karpathy) 2025 年 2 月 2 日[1]

這種突破無疑是革命性的。突然間，生成樣板代碼、構建簡單函數(shù)、創(chuàng)建 UI 組件乃至處理復雜的代碼實現(xiàn)，都只需通過語言描述即可完成。許多工程師使用這些工具后，發(fā)現(xiàn)它們在處理特定類型的工作時展現(xiàn)出超乎想象的實用價值。

這項技術已經(jīng)成熟到足以改變我們許多人的編程工作方式：開發(fā)者不再需要從零開始搭建代碼框架，而是直接基于 AI 生成的可用代碼雛形進行迭代優(yōu)化。這使得原型設計可以更快完成，減少了重復編碼的枯燥勞動，為高效開發(fā)開辟了全新可能。

2.并行運行智能體

現(xiàn)在的突破在于：你可以同時運行多個 AI 智能體，讓它們各自處理不同任務。無需等待一個智能體完成工作后再啟動下一個，您可以同時運行多個智能體 —— 一個構建用戶界面，另一個編寫 API 接口，第三個創(chuàng)建數(shù)據(jù)庫模型。

其核心優(yōu)勢很簡單：實現(xiàn)真正的多任務并行處理。這并非源于更聰明的 AI 或更優(yōu)的算法，而是并行化能力的突破。使用的仍是之前的氛圍編程工具，只是現(xiàn)在能同時運行多個實例。

首個提供成熟解決方案的是 GitHub 推出的運行在云端的 GitHub Co-Pilots。你只需在 Github 代碼庫中創(chuàng)建 issue 并描述需求。當你確認需求描述都已準備就緒，足以清晰定義該功能時，就可以將其分配給 Co-Pilot，然后等待處理結果。

在實際應用中，這意味著你可以遍歷現(xiàn)有的 issue，判斷其是否具備交由 AI 處理的完整上下文。之后只需等待系統(tǒng)發(fā)送通知并對結果進行審核就行了。

這徹底改變了我們的編碼方式。我們不再糾結于具體實現(xiàn)步驟，而是扮演起資深工程師的角色，為多個正在代碼庫中實現(xiàn)具體功能的智能體提供指導和所需的上下文。工程師的工作職責現(xiàn)在轉變?yōu)閷彶榇a的正確性、確保架構決策合理、驗證實現(xiàn)的功能符合用戶預期，并保證代碼滿足所有必需的安全與合規(guī)標準。

但智能體本身仍存在與氛圍編程相同的局限性，它們同樣可能產(chǎn)生錯誤、缺乏足夠的上下文或無法理解代碼邏輯。但此時工程師（某種程度上還兼具產(chǎn)品負責人和設計師的角色）需要引導整個系統(tǒng)為你實現(xiàn)目標。

如何運用并行智能體工作

并行智能體正在重塑工程師的工作方式。現(xiàn)在你無需逐項處理任務，而是可以協(xié)調多個智能體同時開發(fā)不同功能或修復各類缺陷。你需要主動管理多個開發(fā)流程，在智能體完成每項工作時進行代碼審查與反饋指導。

采用這種方法后，我能同時管理 10-20 個開啟狀態(tài)的拉取請求（pull requests），每個都由專屬智能體負責處理。

以下是一些可遵循的實踐步驟：

1） 準備具有充分上下文信息的 issues

首先確保每個 GitHub issue 都包含足夠的上下文信息，讓智能體理解需要構建的內容及其與系統(tǒng)的集成關系。這可能涉及功能行為描述、文件路徑、數(shù)據(jù)庫結構等細節(jié)，或諸如顯示特定字段、處理邊界情況等具體要求。

2）將 issues 批量分配給智能體

準備就緒后，將 issues 分配給 AI 智能體（例如 @copilot）。每次分配通常會新建一個拉取請求，智能體將在此制定實施計劃、創(chuàng)建檢查清單并開始執(zhí)行。支持批量分配多個 issues，實現(xiàn)智能體并行工作。每個智能體通常需要 5-20 分鐘完成其工作。

3）在本地審查并不斷迭代

智能體完成任務后，請在本地環(huán)境審查生成的拉取請求（PR）。必須進行功能測試與正確性驗證。若需要調整，可在拉取請求中留下注釋或反饋，智能體會持續(xù)優(yōu)化解決方案。

4）保持審核流程暢通

與傳統(tǒng)工作流程不同，并行智能體的調度機制能讓工程師始終保持高度專注的狀態(tài)。現(xiàn)在無需等待單個智能體完成任務，即可在多個活躍的拉取請求之間靈活切換 —— 根據(jù)需求隨時進行代碼審查、功能測試與反饋指導。這種工作模式讓我們能在多個任務上同步推進，且不產(chǎn)生過重的心智負擔。

4.對并行智能體的合理預期

使用并行智能體需要完全區(qū)別于傳統(tǒng)編程或氛圍編程的思維模式。這一轉變的重要性，不亞于最初從傳統(tǒng)編程轉向 AI 輔助開發(fā)。

4.1 思維模式轉變

控制方式從精確操控轉向全局調度。你不再需要掌控每一行代碼，而是同時管理多個任務。要以系統(tǒng)工程師管理 Kubernetes Pod 的思維來運作 —— 每個任務都是可替代、可重啟的單元，而非需要精心呵護的獨立服務器。

所有操作轉為異步模式。與需要實時等待反饋的氛圍編程不同，并行智能體默認是異步工作的。此刻輸入的上下文將決定半小時后的產(chǎn)出結果，你無法像過去那樣隨意給出模糊指令再中途修正 —— 因為每次調整都要等待一小時才能收到反饋。

批量處理思維替代線性處理思維。不必從待辦清單內精挑細選某一個“完美任務”，而應找出一天內能協(xié)同推進的多個問題。推薦采用“2+5”模式：集中精力攻克 2 項關鍵任務的同時，并行處理 5-10 個后臺小任務 —— 諸如文案調整、界面優(yōu)化、解決次要 Bugs 這類可以在你專注核心工作時自動處理的事項。

4.2 實際成功率

別指望 100% 的成功率。根據(jù)我使用并行智能體進行編碼時的個人觀察，成功率分布如下：

• 10%：一次生成完美方案，可直接交付。
• 20%：接近完成，僅需約 10 分鐘的本地微調。
• 40%：需要人工介入修正。
• 20%：完全偏離方向，需關閉 issue 并記錄經(jīng)驗教訓。
• 10%：產(chǎn)品方案本身存在缺陷。

即便只有 10% 的任務被智能體完美解決，這個過程依然極具價值。智能體可靠地承擔了基礎工作 —— 定位文件、編寫樣板代碼、添加測試用例。當你進行審查時，大量基礎工作已完成，使你能專注于排查和修復特定問題。

當工程師對編碼智能體應有何種表現(xiàn)沒有合理預期時，挫敗感便會油然而生。有些工程師若得不到完美的解決方案便會直接放棄。我認為應該突破這種思維局限，學會提取智能體的有效產(chǎn)出，并在需要時運用工程知識介入修正。

4.3 優(yōu)勢與短板

并行智能體擅長處理：

• Bugs 的修復與競態(tài)條件問題的處理
• 后端邏輯、控制器模塊（譯者注：負責接收前端請求、協(xié)調不同服務組件并返回響應的代碼模塊。）與驗證邏輯
• 數(shù)據(jù)庫變更與遷移腳本
• 依賴包版本升級與代碼結構轉換
• 目標明確的小型任務

它們處理以下情況則比較困難：

• 全新的 UI 開發(fā)（通常需要實時視覺內容反饋）
• 需實時視覺內容反饋的任務
• 為已存在的 PR 補充未明確寫入文檔的需求或隱含邏輯
• 需要綜合考量超出 issue 范圍的上下文內容才能完成的復雜架構決策

4.4 在新的編程范式下，重要性提升的技能

在并行智能體環(huán)境中，這些傳統(tǒng)技能價值倍增：

全棧理解能力非常重要。若你僅精通前端或后端，將會很快遇到瓶頸。智能體通常需要跨越整個技術棧的指導 —— 從數(shù)據(jù)庫遷移到 UI 更新，貫通前后端才能確保協(xié)作順暢與產(chǎn)出質量。

問題拆解能力成為一項核心技能。龐大復雜的問題難以被智能體有效處理。將大問題分解為定義清晰的小任務，可使智能體獨立并行工作，從而提升整體產(chǎn)出效率，同時也讓代碼審查與集成工作變得更輕松順暢。

書面表達能力變得很重要。智能體依賴你清晰詳細的 issue 描述來產(chǎn)出準確的結果。請避免使用模糊的語言、不必要的術語或模棱兩可的需求。指令越具體有條理，智能體的輸出質量越高。

質量保證和代碼審查技能在此工作流中占據(jù)核心地位。由于審查周期是主要瓶頸，快速評估代碼質量、發(fā)現(xiàn)缺陷及驗證需求是否實現(xiàn)的能力變得尤為關鍵。高效的測試與驗證能確保并行開發(fā)不會堆積未審查或存在故障的代碼。

使用并行智能體工作時，必須優(yōu)化審查速度。你可以同時啟動 50 個任務，但仍需逐一審查、理解與驗證。讓審查周期變得快速（理想情況下能在 10 秒內完成檢出、重構與測試）已成為整個工作流的關鍵所在。

5.實現(xiàn)并行智能體的工程實踐

要有效運用并行智能體，需要一個架構良好、能支持快速迭代與審查的工程環(huán)境。

5.1 快速的 CI/CD Pipeline

穩(wěn)健的 CI/CD 流程能輕松驗證產(chǎn)出結果。當智能體完成工作后，你需要快速驗證這些代碼變更是否正確生效，同時避免人工部署帶來的額外負擔。自動化測試、快速構建和無縫部署流程能有效消除審查環(huán)節(jié)的阻力。若缺乏這些基礎支撐，瓶頸就會從智能體的生成效率，轉移至部署和測試階段。

5.2 系統(tǒng)文檔

當多個智能體在代碼庫的不同部分同時工作時，系統(tǒng)架構文檔就變得至關重要了。智能體需要理解組件間的交互方式、文件存放路徑、遵循的規(guī)范標準以及系統(tǒng)間的集成關系。完善的 API 文檔、架構決策記錄、編碼規(guī)范與系統(tǒng)職責范圍說明，能幫助智能體做出更準確的判斷，減少人工修正需求。

5.3 預覽與預發(fā)布環(huán)境

需要可靠的預發(fā)布環(huán)境用于人工測試智能體實現(xiàn)的功能。由于智能體采用異步工作模式，必須有一個穩(wěn)定的預發(fā)布環(huán)境來驗證其輸出，且不影響生產(chǎn)系統(tǒng)。該環(huán)境應貼近生產(chǎn)環(huán)境配置，支持快速部署，并允許輕松測試多個并發(fā)的代碼變更。為不同分支或拉取請求（PR）快速創(chuàng)建獨立環(huán)境的能力，能極大優(yōu)化并行審查流程。

5.4 單體倉庫（monorepo）架構優(yōu)勢

采用單體倉庫（monorepo）架構存放關聯(lián)服務與組件，更適配并行智能體的工作模式。這種架構讓智能體在單一代碼庫中即可獲得整個系統(tǒng)的上下文。

當智能體需要跨多個代碼庫操作時，它們會失去對服務間交互、共享庫與依賴關系的上下文認知，這將導致生成的解決方案在獨立環(huán)境中可以運行，卻會破壞系統(tǒng)間的集成接口。而單體倉庫使智能體能通覽完整的變更范圍 —— 在同一 PR 中同步更新 API 的規(guī)范定義、調整客戶端代碼、修改可復用的工具類代碼。

統(tǒng)一的視角有助于做出更好的架構決策。智能體可參照現(xiàn)有的設計模式、復用通用的組件，并確保整個系統(tǒng)的一致性。代碼審查也變得更加有效，因為所有相關的代碼變更都集中在一處可見，便于驗證智能體是否引入了集成部署時才會出現(xiàn)的問題。

對于并行開發(fā)，單體倉庫簡化了部署與測試流程。我們無需跨多個倉庫協(xié)調發(fā)布，就能整體測試系統(tǒng)變更并實現(xiàn)原子化地部署。當需要跨越多服務邊界，去管理多個由智能體并行產(chǎn)生的代碼變更時，這種（單體倉庫）做法能有效降低復雜度。

支持并行智能體的工具

目前已有數(shù)款開發(fā)工具支持運行并行智能體，它們各具特色，成熟度也各不相同。

GitHub Agents 提供最成熟、最完善的體驗。它們直接集成在 GitHub Issues 中，并與 VSCode 無縫協(xié)作。只需將任務指派給 @copilot，智能體便會創(chuàng)建可供本地審查的 PR。雖然仍存在部分待優(yōu)化的細節(jié)，但 GitHub 正通過持續(xù)迭代逐步解決這些問題。

Cursor 目前正通過測試計劃探索并行智能體的支持。該團隊已邀請部分用戶體驗此功能，初期反饋顯示其實現(xiàn)方案頗具潛力。若你已使用 Cursor 進行氛圍編程，待其更廣泛地開放訪問權限后，不妨關注一下他們的并行智能體。

OpenAI 的 Codex CLI 同樣支持在云端運行智能體，從而實現(xiàn)此類并行開發(fā)工作流。該命令行工具可啟動持續(xù)在遠程運行的智能體，使您能夠管理多個并發(fā)編碼任務，而無需占用本地環(huán)境資源。

每款工具對并行執(zhí)行的實現(xiàn)思路略有差異，最佳選擇取決于你現(xiàn)有的開發(fā)流程與工具偏好。

7.總結與展望

我使用并行智能體已有數(shù)周，它徹底改變了我的開發(fā)模式。能夠同步處理多個問題而非依次解決，實實在在地提升了生產(chǎn)效率。

這項技術目前并不完美 —— 我們仍需花費時間審查與修正智能體生成的代碼。但當我們能同時啟動十項任務，且其中大部分無需直接干預便能推進時，它便為我們騰出了寶貴的精力，讓我們能專注于那些真正需要人類判斷的問題。

如果你對嘗試這種方法感到好奇，建議從待辦清單中挑選小型的、定義明確的任務開始。編寫清晰的描述文檔然后觀察運行結果。最壞的情況不過花費幾分鐘審查未達到預期的代碼，而最好的情況則是你或許將找到契合自身風格的全新工作范式。