大家好，我是玄姐。

?在這個行業(yè)待了足夠久，見證了無數(shù)技術(shù)的興衰更迭。見過新框架引發(fā)的狂熱追捧，見過革命性工具許下的美好承諾，也聽過那些宣稱 “將改變一切” 的激動人心的預(yù)言。但大多數(shù)時候，這些技術(shù)不過是裹著營銷噱頭的漸進式改進。

但并行智能體（Parallel AI Agents）不一樣。這是第一次可以毫不夸張地說，正在見證一項將從根本上改變軟件開發(fā)方式的技術(shù)。

一、發(fā)展歷程回顧

要理解當下的技術(shù)現(xiàn)狀，我們需要回顧 AI 輔助編碼的完整發(fā)展史。一切始于 GitHub Copilot，它首次引入了 AI 結(jié)對編程的概念。在你打字時，Copilot 能自動補全代碼、推薦函數(shù)、完成實現(xiàn)，還能處理重復(fù)性工作。

之后出現(xiàn)了 Windsurf 和 Cursor 這類 AI 驅(qū)動的編輯器。它們將 AI 深度集成到開發(fā)環(huán)境中，把這一概念推向了新高度。除了自動補全，你還能和 AI 圍繞代碼交流，尋求重構(gòu)建議，甚至獲得調(diào)試幫助。AI 能理解你的整個代碼庫，提供貼合上下文的輔助。

今年，我們開始接觸一種名為 “氛圍編程”（vibe coding）的方式，用自然語言描述需求，AI 就能從零生成完整的函數(shù)、類或?qū)崿F(xiàn)方案。比如你說 “創(chuàng)建一個支持谷歌、GitHub 和微軟登錄選項的注冊表單”，它就能生成可用的代碼，完美契合你的需求氛圍。

“氛圍編程” 這個術(shù)語是安德烈?卡帕西（Andrej Karpathy）在 X 推文中提出的，精準捕捉到了這種新編程方式的核心體驗：

“我把這種新的編程方式稱為‘氛圍編程’，完全沉浸在氛圍中，擁抱指數(shù)級效率，甚至忘了代碼本身的存在。這之所以可行，是因為大語言模型（比如搭載 Sonnet 模型的 Cursor Composer）已經(jīng)變得太強大了。而且我現(xiàn)在還能用 SuperWhisper 和 Composer 直接對話……”

這無疑是具有革命性的。突然間，你只需通過描述，就能生成樣板代碼、構(gòu)建簡單函數(shù)、創(chuàng)建 UI 組件，甚至完成復(fù)雜的實現(xiàn)。許多工程師都采用了這些工具，并發(fā)現(xiàn)它們在特定類型的工作中極為實用。

這項技術(shù)的效果足夠好，以至于改變了我們許多人的編程思路。不再需要從空白文件開始，你可以直接基于可用的實現(xiàn)方案進行優(yōu)化。它加快了原型設(shè)計速度，減少了編寫重復(fù)代碼的枯燥感，為快速開發(fā)開辟了新可能。

二、并行運行智能體

現(xiàn)在的核心突破在于：你可以同時運行多個 AI 智能體，每個智能體負責(zé)處理不同的問題。無需等待一個智能體完成任務(wù)再開始下一個，你可以讓多個智能體同步工作：一個負責(zé)構(gòu)建用戶界面，另一個編寫 API 接口，第三個創(chuàng)建數(shù)據(jù)庫模式。

核心優(yōu)勢很簡單：能同時處理多項任務(wù)。這無關(guān) AI 更智能或算法更優(yōu)秀，關(guān)鍵在于并行化，還是之前的氛圍編程工具，只是同時運行多個實例而已。

第一個提供成熟解決方案的公司是 GitHub，他們推出的云端 GitHub Copilot 就是如此。你只需在 GitHub 上找到一個問題并詳細描述，當你認為描述足夠清晰、能讓 AI 理解所需功能時，將其分配給 Copilot，然后等待結(jié)果即可。

在實際操作中，你可以查看現(xiàn)有問題，判斷是否提供了足夠的上下文供 AI 處理。之后只需等待系統(tǒng)通知，即可查看并審核結(jié)果。

這徹底改變了代碼編寫方式。你不再需要關(guān)注微觀的實現(xiàn)步驟，而是扮演資深工程師的角色，為多個在代碼庫中實現(xiàn)功能的智能體提供指導(dǎo)和上下文。作為工程師，你的工作變成了審核代碼準確性、確保做出合理的架構(gòu)決策、驗證功能是否符合用戶需求，以及保證代碼滿足所有必要的安全和合規(guī)標準。

智能體本身和氛圍編程時一樣存在局限性，可能會產(chǎn)生 Bug、缺乏足夠上下文、無法理解復(fù)雜代碼。但作為工程師（在某種程度上也是產(chǎn)品負責(zé)人和設(shè)計師），你可以引導(dǎo)系統(tǒng)完成實現(xiàn)。

三、如何與多個并行智能體協(xié)作

并行智能體正在改變工程師的工作方式。你不再需要一次專注于一項任務(wù)，而是可以協(xié)調(diào)多個智能體并行處理不同的功能開發(fā)或 Bug 修復(fù)。你需要主動管理多個開發(fā)流程，在每個智能體完成工作后進行審核并提供反饋。

通過這種方式，我可以同時處理 10 到 20 個拉取請求（pull request），每個請求都由專門的智能體負責(zé)。

以下是具體的操作步驟：

1. 準備具備充足上下文的問題描述確保每個 GitHub 問題都包含足夠的上下文，讓智能體能理解需要構(gòu)建的內(nèi)容以及如何與系統(tǒng)集成。這可能包括功能行為細節(jié)、文件位置、數(shù)據(jù)庫結(jié)構(gòu)，或特定要求（比如：顯示特定字段、處理邊界情況等）。
2. 批量分配任務(wù)給智能體問題描述準備就緒后，將其分配給 AI 智能體（如 @copilot）。每次分配通常會創(chuàng)建一個新的拉取請求，智能體會制定計劃、創(chuàng)建檢查清單，然后開始實現(xiàn)。可以同時分配多個問題，讓智能體并行工作。單個智能體完成任務(wù)通常需要 5 到 20 分鐘。
3. 本地審核并迭代優(yōu)化智能體完成任務(wù)后，在本地審核生成的拉取請求。測試功能并驗證準確性至關(guān)重要。如果需要修改，可在拉取請求上留下評論或反饋，智能體會繼續(xù)優(yōu)化解決方案。
4. 保持審核流程的連貫性與傳統(tǒng)工作流程不同，并行智能體的協(xié)調(diào)能讓你始終保持專注和高效。無需等待某個智能體完成，你可以在多個活躍的拉取請求之間切換。根據(jù)需要進行審核、測試和提供反饋。這使得多項任務(wù)能同步推進，且不會帶來過多的腦力負擔(dān)。

以下是實際操作的演示視頻：“使用委托式 Copilot 智能體的體驗太棒了，能并行處理 10 個拉取請求。GitHub 做得好??”（附視頻鏈接：pic.twitter.com/T6sCIBg6bH）

四、并行智能體的預(yù)期效果

與并行智能體協(xié)作，需要不同于傳統(tǒng)編程或氛圍編程的思維模式。這種轉(zhuǎn)變的意義，不亞于從傳統(tǒng)編程轉(zhuǎn)向 AI 輔助開發(fā)。

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

控制權(quán)從 “精準掌控” 轉(zhuǎn)向 “協(xié)調(diào)統(tǒng)籌”。你不再需要控制每一行代碼，而是同時管理多個問題。思考方式要像系統(tǒng)工程師管理 Kubernetes 容器組，而非照看單個服務(wù)器，每個任務(wù)都是可替代、可替換的。

所有工作都變成異步進行。與氛圍編程中實時等待和觀察不同，并行智能體默認異步工作。你前期提供的上下文，將決定 30 分鐘后的結(jié)果。不能再用敷衍的提示詞，邊做邊改，因為這些修改要一小時后才能生效。

批量思維取代線性思維。不再從任務(wù)清單中挑選一個完美的任務(wù)，而是確定一天內(nèi)可以處理的多個問題。一個好方法是：專注于 2 個關(guān)鍵交付項，同時運行 5 到 10 個小型后臺任務(wù)，比如：文案修改、UI 修復(fù)、小 Bug 修復(fù)等，這些任務(wù)可以在你專注于重要工作時同步處理。

4.2 實際成功率

不要期望 100% 的成功率。根據(jù)我個人的編程經(jīng)驗，通常會出現(xiàn)以下情況：

• 10%：完美的一次性解決方案，可直接部署。
• 20%：接近完成，只需 10 分鐘的本地優(yōu)化。
• 40%：需要人工干預(yù)調(diào)整。
• 20%：完全錯誤，關(guān)閉問題并記錄經(jīng)驗教訓(xùn)。
• 10%：產(chǎn)品思路本身有問題。

即使只有 10% 的問題能被智能體完美解決，這個流程依然有價值。智能體可以可靠地完成初始設(shè)置，找到正確的文件、編寫樣板代碼、添加測試。等你進行審核時，大部分基礎(chǔ)工作已經(jīng)完成，你可以專注于排查和修復(fù)特定問題。

工程師的挫敗感往往源于對編程智能體的期望過高。有些工程師如果沒有得到 100% 完美的解決方案就會放棄。但我認為，你應(yīng)該克服這種局限，學(xué)會提取有用的部分，在需要專業(yè)工程知識的地方主動介入。

4.3 適用與不適用場景

并行智能體擅長處理：

• Bug 修復(fù)和競態(tài)條件問題
• 后端邏輯、控制器、驗證功能
• 數(shù)據(jù)庫變更和遷移
• 依賴包版本更新和代碼轉(zhuǎn)換
• 小型、定義明確的實現(xiàn)任務(wù)

它們不擅長處理：

• 新 UI 開發(fā)（構(gòu)建過程中需要實時查看變化）
• 需要實時視覺反饋的任務(wù)
• 為現(xiàn)有拉取請求添加未記錄的功能
• 需要超出問題描述上下文的復(fù)雜架構(gòu)決策

4.4 變得更重要的技能

在并行智能體時代，一些傳統(tǒng)技能變得更加寶貴：

• 全棧認知能力：與并行智能體協(xié)作時，全棧知識儲備非常有價值。如果你的專業(yè)知識僅限于前端或后端，很快就會遇到瓶頸。智能體通常需要跨全棧的指導(dǎo)，從數(shù)據(jù)庫遷移到 UI 更新，因此能夠駕馭前后端的工程師能確保協(xié)作更順暢、結(jié)果更優(yōu)。
• 問題拆解能力：這成為核心技能。大型復(fù)雜問題很難被智能體有效處理，將大問題拆分成小型、定義明確的任務(wù)，能讓智能體獨立并行工作，提高整體效率，也更便于審核和整合成果。
• 書面表達能力：智能體依賴清晰詳細的問題描述來生成準確結(jié)果。要避免模糊表述、不必要的術(shù)語或歧義性要求。指令越具體、結(jié)構(gòu)越清晰，智能體的輸出質(zhì)量就越高。
• 質(zhì)量保證和代碼審核能力：在這種工作流程中，審核環(huán)節(jié)成為主要瓶頸。快速評估代碼質(zhì)量、發(fā)現(xiàn) Bug、驗證需求是否滿足，這些能力至關(guān)重要。高效的測試和驗證能確保并行開發(fā)不會導(dǎo)致未審核或有缺陷的代碼堆積。

與并行智能體協(xié)作時，應(yīng)優(yōu)化審核速度。你可以啟動 50 個任務(wù)，但仍需逐一審核、理解和驗證。讓審核流程快速高效，理想情況下，檢出代碼、重新構(gòu)建和測試的時間控制在 10 秒內(nèi)，這對整個工作流程至關(guān)重要。

“昨天使用 GitHub 并行智能體學(xué)到了很多：

1. 我的思維模式還沒適應(yīng)與智能體的并行異步工作
2. 不能期望 100% 成功，但可以進行一系列小額嘗試
3. 克服阻塞問題的策略
4. 何時使用 Claude Code 以及……”（附鏈接：pic.twitter.com/yKNNkNZnby）

五、支持并行智能體的工程實踐

與并行智能體協(xié)作，需要結(jié)構(gòu)良好的工程環(huán)境，以支持快速迭代和審核。

5.1 快速 CI/CD 流水線

強大的 CI/CD 流程能簡化測試和驗證工作。智能體完成任務(wù)后，你需要快速驗證變更是否正常工作，無需手動部署的繁瑣操作。自動化測試、快速構(gòu)建和無縫部署流程，能減少審核環(huán)節(jié)的阻力。如果沒有這個基礎(chǔ)，瓶頸就會從智能體完成時間轉(zhuǎn)移到部署和測試時間。

5.2 系統(tǒng)文檔

當多個智能體在代碼庫的不同部分工作時，系統(tǒng)架構(gòu)文檔至關(guān)重要。智能體需要了解組件間的交互方式、文件位置、遵循的規(guī)范以及不同系統(tǒng)的集成方式。完善的 API 文檔、架構(gòu)決策記錄、編碼標準和系統(tǒng)邊界說明，能幫助智能體做出更好的決策，減少人工修正的需求。

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

需要一個可靠的預(yù)發(fā)布環(huán)境來手動測試功能。由于智能體異步工作，你需要一個穩(wěn)定的環(huán)境來驗證它們的輸出，而不影響生產(chǎn)系統(tǒng)。這個環(huán)境應(yīng)與生產(chǎn)環(huán)境一致，部署迅速，并能輕松測試多個并發(fā)變更。為不同分支或拉取請求創(chuàng)建獨立環(huán)境的能力，能簡化并行審核流程。

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

將相關(guān)服務(wù)和組件集中在一個單體倉庫中，更適合與并行智能體協(xié)作。單體倉庫能讓智能體在同一個代碼庫中獲取整個系統(tǒng)的上下文。

如果智能體跨多個倉庫工作，就會丟失關(guān)于服務(wù)交互、共享庫和依賴關(guān)系的上下文，導(dǎo)致解決方案在孤立環(huán)境中可行，但在集成時出現(xiàn)問題。而在單體倉庫中，智能體能理解所需的全部變更，更新 API 契約、調(diào)整客戶端代碼、修改共享工具庫，所有這些都能在一個拉取請求中完成。

統(tǒng)一的視圖有助于做出更好的架構(gòu)決策。智能體能看到現(xiàn)有的模式、重用通用組件，并在整個系統(tǒng)中保持一致性。代碼審核也更有效，因為所有相關(guān)變更都集中在一個地方，便于驗證智能體是否引入了集成問題。

單體倉庫還簡化了并行開發(fā)的部署和測試。無需協(xié)調(diào)多個倉庫的發(fā)布，你可以一起測試完整的系統(tǒng)變更，并實現(xiàn)原子化部署。這降低了管理跨服務(wù)邊界的多個并發(fā)智能體生成變更的復(fù)雜性。

六、支持并行智能體的工具

現(xiàn)在有幾款開發(fā)工具支持運行并行智能體，它們各有優(yōu)勢和成熟度：

• GitHub Agents：體驗最完善，直接集成到 GitHub Issues 中，與 VSCode 無縫協(xié)作。將問題分配給 @copilot 后，智能體會創(chuàng)建拉取請求，你可以在本地審核。雖然仍有一些小瑕疵，但 GitHub 通過定期更新不斷改進這些問題。
• Cursor：目前正在通過測試版程序嘗試支持并行智能體。他們邀請了部分用戶測試這項功能，早期反饋顯示這是一個很有前景的實現(xiàn)。如果你已經(jīng)在使用 Cursor 進行氛圍編程，等它開放更廣泛的訪問權(quán)限后，值得一試其并行智能體功能。
• OpenAI 的 Codex CLI：也支持在云端運行智能體，支持這種并行開發(fā)工作流程。通過 CLI 啟動的智能體能在遠程持續(xù)運行，讓你無需占用本地環(huán)境，就能管理多個并發(fā)的編程任務(wù)。

每種工具的并行執(zhí)行方式略有不同，最佳選擇取決于你現(xiàn)有的開發(fā)工作流程和工具偏好。

七、總結(jié)

我使用并行智能體已有幾周時間，它徹底改變了我的開發(fā)方式。能夠并行處理多個問題，而非按順序推進，這對工作效率的提升是實實在在的。

這項技術(shù)并非完美無缺，你需要花費時間審核和修復(fù)智能體生成的代碼。但當你能同時啟動 10 個任務(wù)，并且大部分任務(wù)能在無需直接干預(yù)的情況下推進時，你就能騰出腦力，專注于那些真正需要人類判斷的問題。

如果你好奇并想嘗試這種方式，可以從任務(wù)清單中挑選一些小型、定義明確的問題開始。編寫清晰的描述，看看結(jié)果如何。最壞的情況不過是花費幾分鐘審核無法使用的代碼，而最好的情況是，你可能會發(fā)現(xiàn)一種適合自己開發(fā)風(fēng)格的全新工作方式。

好了，這就是我今天想分享的內(nèi)容。

本文轉(zhuǎn)載自???玄姐聊AGI??  作者：玄姐