如何在開發團隊中擴充套件 AI 編碼代理

一個開發者使用編碼代理是一個生產力故事。這很容易講述，演示效果很好，並且確實真實。

五個開發者使用二十個代理則完全是另一回事。這是一個協調問題，而協調問題並不能透過創造它的工具來解決。這是沒人寫的部分，因為它只在熱情階段之後出現：個人收益是真實的，它們立即到來，然後在第三或第四個開發者左右，團隊開始花費新的速度來清理自己的後果。

接下來是失敗順序。這不是抽象中的最佳實踐列表，而是事情實際破裂的順序，因為以錯誤的順序修復它們會浪費一個季度。

首先破裂的是什麼：共享上下文

每個執行代理的開發者都在悄悄地教它自己版本的程式碼庫。

一個人告訴他們的代理專案使用伺服器操作而不是 API 路由。另一個人從未提及，因此他們的代理編寫 API 路由。第三個人提到過一次，在三天前結束的會話中。沒有人是錯的，沒有人是在撒謊，而程式碼庫現在包含了對同一約定的三種解釋。你會在審查佇列中注意到這一點，而這並不是注意到它的正確地方：到那時程式碼已經存在。

修復方法很無聊，但這是本頁上最高效的事情。將約定放在一個檔案中，提交該檔案。

CLAUDE.md 用於 Claude Code，AGENTS.md 用於 Codex 和大多數其他 CLI 代理，實際上很多團隊保持 一個便攜上下文檔案，而不是維護兩個逐漸分離的檔案。機制比檔名更重要：指令儲存在程式碼庫中，因此它們隨著 git pull 到達，而不是透過任何恰好在房間裡的人到達。

它應該包含的內容：

• 代理無法從閱讀程式碼中推斷出的約定，特別是程式碼庫當前在某些地方違反的約定
• 命令：如何執行測試、建置、程式碼檢查器，以及哪些可以自動執行
• 程式碼庫中危險的部分，以及原因
• 團隊不想要的內容：沒有人要求的重構，絕對不能新增的依賴，正在遷移的模式

不應該包含的內容，而這正是團隊遭遇問題的地方：任何特定於一臺機器的內容。絕對路徑、個人 API 令牌、本地埠、某人的首選編輯器。當機器特定的值出現在提交的上下文檔案中時，其他每個開發者都會繼承一個對他們來說錯誤的設定，而代理在忠實執行不再適用的指令方面非常出色。

在新增一行之前的有用測試：如果一個隊友拉取這個，它是幫助他們還是破壞他們？

其次破裂的是什麼：兩個代理，一個檔案

代理不會進行協商。它們不會檢查是否有人正在編輯。兩個指向同一模組的代理將相互覆蓋，而不會提及，因為從每個代理的角度來看，工作成功完成。

單獨使用時，這種情況是不可見的。你一次執行一個代理，或者你執行幾個，它們恰好接觸不同的內容。在團隊中，這變得結構化，併產生最糟糕的錯誤型別：在兩個綠色測試執行之間悄然消失的工作。

有兩種機制可以修復它，你需要兩者。

隔離。 Git 工作樹 為每個任務提供其自己的程式碼庫檢出，因此並行代理在物理上無法碰撞。這是解決方案的便宜部分，沒有理由不這樣做。

所有權。 隔離阻止了覆蓋；但它並不能阻止兩個人以兩種不相容的方式在兩個分支中兩次解決同一個問題。這個問題在分配時解決，透過將每個任務的範圍限制在一組檔案中，並在任務本身中說明。不是「改善檢出流程」，而是「更改支付步驟，在這三個檔案中，不要觸碰購物車」。

第二部分是團隊跳過的部分，而這部分決定了合併是形式上的還是一個下午的工作。

第三破裂的是什麼：審查

團隊規模的審查一切都源於一個數字：每小時到達的差異量。

一個開發者閱讀每一行是可以的。五個開發者每人執行四個代理，每天生成的差異量超過團隊可以閱讀的量，誠實的結果不是仔細審查，而是批准劇場。一個人在下午六點快速瀏覽九百行差異，產生一個簽名卻沒有產生知識，這比不審查更糟，因為它製造了一個沒有的保證。

存活下來的政策不是「審查所有內容」，也不是「信任代理」。而是將審查移至工作的兩個邊界：在代理開始之前閱讀計劃，因為一個錯誤的計劃完美執行是最昂貴的失敗模式，然後根據變更可能破壞的程度閱讀差異。營銷文案和 CSS 只需快速瀏覽。身份驗證、支付、許可權、個人資料和遷移每次都需逐行閱讀，無論差異看起來多麼乾淨。

這值得單獨討論，我們單獨寫了這篇文章：你還應該審查你的 AI 代理的程式碼嗎 討論了十個客觀跡象，表明更改出現了問題，以及團隊可以直接採用的爆炸半徑表。

一個團隊特定的補充。當多個代理共享一個程式碼庫時，審查需要歸屬：哪個代理，哪個任務，哪個開發者。沒有它，差異沒有作者，審查變成考古學。這是你在透過三或四個併發代理後，設定中最有用的修復。

第四破裂的是什麼：成本，以及關於成本的對話

代幣支出在出現在團隊發票上的那一刻就不再是個人細節。

陷阱在於發票是每月和彙總的，因此它產生的對話也是每月和彙總的，這意味著它產生的是政策而不是修復。有人提出一個更便宜的模型供所有人使用。另一個人提議限制會話。兩者都是猜測。

實際分佈幾乎從來不是均勻的。它是少數幾個長期執行的會話，集中在一兩個專案上，背景整天增長且從未重置。這是一個可修復的行為，只有在你能夠看到每個會話和每個專案的支出，而不是每月的支出時，才能修復它。我們在 如何檢查代幣使用情況 和 如何在不減慢速度的情況下減少它 中涵蓋了這個機制。

在它成為管理主題之前，讓產生它的人看到這個數字。一個開發者如果看到一次會話的費用超過他們整個前一天的費用，會自行改變他們的習慣，而這對團隊在政治上沒有任何成本。

團隊儀式中實際改變的內容

根據我們的經驗和團隊的報告，有三件事。

站會從狀態轉向解除阻礙。 每個人昨天做了什麼在分支中大致可見。值得花五分鐘的是哪些代理被卡住，以及卡住的原因。

提示成為共享資產。 為一個開發者帶來良好結果的指令對團隊的價值超過了它產生的程式碼，而這正是那種在私人終端歷史中蒸發的內容。保持 共享提示庫 的團隊不再每週重新發現相同的措辭。

專業化從個人轉向角色。 一旦代理處理寫作，值得關注的問題是誰審查什麼，團隊自然傾向於將角色分配給代理，就像他們將角色分配給人一樣：一個負責實施，一個負責審查，一個負責測試。這就是 代理團隊 的理念，在這個理念中，一個任務從開發角色轉交給 QA 角色，附帶差異、風險和測試提示，品質門由你的測試套件決定，而不是由代理對其工作的看法決定。

可持續的設定

簡明扼要，按重要性排序：

前四個只需達成一致即可。最後兩個是團隊最終希望在終端之上獲得某種東西的原因：不是因為終端不好，而是因為終端一次只顯示一個代理，並且沒有辦法回答「現在誰在執行什麼，在哪個專案上」。

這就是 AgentsRoom for teams 建置的核心問題：在一個檢視中檢視每個專案中的每個代理，附帶其角色、狀態和成本，以及在團隊不在桌子前時的移動伴侶。它與 Claude Code 和 Codex 的工作方式相同，這比聽起來更重要：大多數團隊最終會同時執行兩者，而假設一個提供者的設定會悄然成為下一個破裂的事情。

不過，從上下文檔案開始。這是免費的，花一個下午的時間，並且比你這個季度可以安裝的任何工具減少了更多摩擦。