1. 首頁 > 生活百科 > >

多個編碼智能體同時使用會不會混亂？海外開發者熱議

網絡安全安全漏洞

多個編碼智能體同時使用會不會混亂？海外開發者熱議

文章圖片

多個編碼智能體同時使用會不會混亂？海外開發者熱議

文章圖片

多個編碼智能體同時使用會不會混亂？海外開發者熱議

文章圖片

多個編碼智能體同時使用會不會混亂？海外開發者熱議

文章圖片


機器之心報道
編輯：冷貓
AI 編程工具的進步速度正在迅速加快 。
如果各位讀者從事涉及代碼相關的工作 ， 應該很能察覺到近兩年 AI 編程能力的進化幅度 ， GPT-5 和 Gemini 2.5 等最新前沿大模型已經讓開發者在實際任務中一定程度實現了自動化 ， 近期發布的 Sonnet 4.5 又再次推動了這一進展 。
再結合現在已經非常成熟 CLI、IDE 工具等的輔助 ， 采用編碼智能體進行開發工作已經成為了一種常態 ， 甚至成為了一種新的生活方式 。
不僅僅是程序員 ， 產品類、設計類崗位的從業人員都已廣泛采用 AI 編碼智能體輔助工作 ， AI 生成的代碼比例越來越高 。
但是 ， AI 編碼智能體仍然存在一些問題 ， 比如代碼質量不高 ， 智能體分析效率低下等等 。
那么 ， 與其等待智能體分析生成或是多次「抽卡」的低效 ， 有沒有可能同時并行使用多個智能體進行工作呢？
Datasette 的創建者 ， 獨立開源開發者 Simon Willison 已經成為了同時使用多個編碼智能體的開發者 。
為此 ， 他發布了一篇全新博客 ， 分享了自己同時運行多個編碼 AI 的經歷和寶貴經驗 ， 引起了海外開發者們廣泛的關注 ， 在 X 上的推文已破 10 萬閱讀量 。


博客標題：Embracing the parallel coding agent lifestyle 博客鏈接：https://simonwillison.net/2025/Oct/5/parallel-coding-agents/擁抱并行編碼代理生活方式
Simon Willison 起初對此是持懷疑態度的 。 AI 生成的代碼必須經過審查 ， 而審查速度天然是瓶頸 。 光是跟上單個大模型的產出速度就已經很吃力了 ， 如果同時運行多個代理 ， 只會更加落后 ， 那又有什么好處呢？
盡管一開始有顧慮 ， 但過去幾周他發現自己其實已經悄然接受了這種「并行編碼代理」的工作方式 。
在工作中 ， 他發現可以并行啟動越來越多的小任務 ， 而不會給主要工作增加太多認知負擔 。
以下是 Simon Willison 總結的一些高效使用并行代理的模式：
概念驗證研究任務
第一個適合并行代理的任務類別是研究 。
研究任務用于回答問題或提供建議 ， 而不會直接修改你計劃保留的項目代碼 。
許多軟件項目都始于概念驗證階段 。 例如：能否用 Yjs 和 Python 后端實現一個簡單的協作筆記工具？這些庫雖然存在 ， 但它們能否順利協同工作？
如今的編碼代理已經能夠用新庫快速構建原型 ， 驗證這些基礎性問題 。 即便新庫不在模型的訓練數據中也沒關系 —— 直接讓代理去克隆這些依賴的倉庫、閱讀代碼、自己摸索使用方法 。
系統機制回溯
當你需要回憶系統中某一部分的工作原理時 ， 現代的「推理型」大模型能在一兩分鐘內給出詳細且可操作的答案 。
無論代碼庫多大 ， 代理都可以借助諸如 grep 之類的工具 ， 在數十個文件之間追蹤調用路徑 。
你可以讓它：
記錄簽名 cookies 是在哪里設置和讀取的； 分析你的應用如何使用子進程與線程； 或指出 JSON API 哪些部分還未被文檔覆蓋 。這些由 LLM 生成的解釋非常值得保存起來 —— 它們可以作為后續 prompt 的上下文材料 ， 非常有價值 。
小型維護任務
接下來是真正打算保留的代碼修改 ， 盡管它們風險較低 。 事實證明 ， 有許多小問題只需一點額外的「腦力負擔」 ， 這些完全可以交給代理處理 。
例如警告信息（warnings）：如果測試套件拋出某個棄用（deprecated）警告 ， 把它丟給一個代理 ， 讓它運行測試、找到并修復問題 。 你無需中斷正在進行的主要任務來解決這種小煩惱 。
發現這種機會是一種能力 。 最好的練習方式就是多嘗試 —— 任何小的維護任務都值得交給代理試一試 。 無論成功或失敗 ， 你都能從中學到東西 。
精確指定的實際工作
審查一段「從天而降」的代碼改動是很費力的 。
首先得推測作者的意圖：它要解決什么問題？這個問題是否值得解決？方案是否合理、能否與后續計劃兼容？這些都需要思考大量高層問題 ， 才能開始看具體實現 。
但如果代碼是根據你自己寫的詳細規格說明生成的 ， 那么審查負擔就輕得多 。 當你已經確定了目標、方法和實現細節 ， 只需要驗證代理產出的代碼是否符合你的要求即可 。
現在的使用方式
目前 ， Willison 的主力工具是：
Claude Code（Sonnet 4.5） Codex CLI（GPT-5-Codex） Codex Cloud（用于異步任務 ， 經常直接從手機觸發）此外 ， 還在嘗試：
GitHub Copilot Coding Agent（集成在 GitHub 網站界面的內置代理） Google Jules（谷歌目前免費的 Codex Cloud 替代方案）他仍在摸索最適合自己的工作模式 ， 預計還會持續調整 。
他經常同時打開多個終端窗口 ， 在不同目錄中運行不同的代理實例（通常是 Claude Code 與 Codex CLI 的組合） ， 以 YOLO 模式（無需批準）執行那些安全性可控的任務 。
對于風險較高的任務 ， 主要使用異步代理（通常是 Codex Cloud） 。 這樣即便出問題 ， 最糟糕的情況只是源碼泄露 。
他偶爾也會使用 GitHub Codespaces 來運行 VS Code 的 agent 模式 —— 它出乎意料地高效 ， 且完全在瀏覽器中運行 。 這在 workshop 或演示場景中特別好用：只要有 GitHub 賬號即可使用 ， 無需額外的 API 密鑰 。
開發者熱議
這篇博客一經發布就受到廣泛關注 ， 非常契合現在代碼相關開發工作的痛點 。 越來越多人正在嘗試同時使用多個編碼智能體進行開發工作 。
Google Labs 的產品總監 Kath Korevec 有 80% 左右的編碼工作是由 AI 輔助完成的 ， 她同樣表達了對并行智能體工作流的熱情 。

還有一些開發者分享了自己關于并行智能體開發范式的理解：


當然 ， 很多開發者表達了一些擔憂的聲音 ， 尤其是關于智能體生成代碼產生的不可控因素：



更多開發者討論 ， 可以關注原推文：
【多個編碼智能體同時使用會不會混亂？海外開發者熱議】https://x.com/simonw/status/1974835974938206222

    推薦閱讀