編者按： 當(dāng)?AI?不僅能寫代碼，還能同時處理多個開發(fā)任務(wù)，軟件工程師這一角色是否正面臨根本性的重塑？

我們今天為大家?guī)淼奈恼?，作者的核心觀點是：并行智能體是將深刻改變軟件開發(fā)模式的革命性技術(shù)。

作者從 AI 編程工具的演進談起，揭示了從 Copilot 的代碼補全到“氛圍編程”的自然語言生成，再到當(dāng)前的范式突破 —— 并行智能體。作者還坦誠分享了實際應(yīng)用中的成功率分布，指出了智能體擅長與不擅長的任務(wù)類型，并強調(diào)了全棧技術(shù)、問題拆解和代碼審查等技能在新工作流中的核心地位。最后，文章提出了支持并行智能體的工程實踐，包括快速 CI/CD、完善文檔和單體倉庫架構(gòu)等關(guān)鍵要素。

作者 | Igor ?ar?evi?

編譯 | 岳揚

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

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

01 發(fā)展歷程

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

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

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

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

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

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

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

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

02 并行運行智能體

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

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

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

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

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

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

03 如何運用并行智能體工作

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

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

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

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

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

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

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

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

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

4. 保持審核流程暢通

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

04 對并行智能體的合理預(yù)期

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

4.1 思維模式轉(zhuǎn)變

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

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

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

4.2 實際成功率

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

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

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

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

4.3 優(yōu)勢與短板

并行智能體擅長處理：

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

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

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

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

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

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

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

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

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

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

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

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

5.1 快速的 CI/CD Pipeline

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

5.2 系統(tǒng)文檔

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

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

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

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

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

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

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

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

06 支持并行智能體的工具

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

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

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

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

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

07 總結(jié)與展望

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

這項技術(shù)目前并不完美 —— 我們?nèi)孕杌ㄙM時間審查與修正智能體生成的代碼。 但當(dāng)我們能同時啟動十項任務(wù)，且其中大部分無需直接干預(yù)便能推進時，它便為我們騰出了寶貴的精力，讓我們能專注于那些真正需要人類判斷的問題。

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

END

本期互動內(nèi)容 ??

?文章提到，工程師的角色正從“編碼者”轉(zhuǎn)向“調(diào)度與審查者”。在你的工作中，是否已經(jīng)感受到了這種變化？

文中鏈接

[1]https://twitter.com/karpathy/status/1886192184808149383?ref_src=twsrc^tfw

本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。

原文鏈接：

https://morningcoffee.io/parallel-ai-agents-are-a-game-changer.html