練習跟同事的AI Agent協作
目前的Agent 還是缺乏人類的「團隊意識」和「邊界感」。
前面的文章 AI Agent協作帶來的技術都更與 AI Agent協作的品質監控策略 ，我們討論了個人生產力的問題，不過應該有些人會發現團隊陷入了新的協作崩潰。
開發的日常變成了：
昨晚的Daily Build失敗了，因為同事 B 的 Agent 為了修一個 Bug，「順便」升級了一個你正在使用的共用套件，導致您的服務崩潰。
準備合併一個 PR，同事 C 的 Agent 為了優化效能，重構了您正在修改的同一個核心函式。
收到一個 PR 審核通知，Agent 產出了 2000 行程式碼，異動了 5 個不同模組 （Submodule），而Review只熟悉其中 1 個模組。
Agent 缺乏人類合作的「邊界感」和「溝通禮儀」，也因此這幾個月來帶來了更多團隊開發的挑戰與模式的改變。
1. Agent 「放大」了系統架構問題
換個角度想，Agent 到處改code的問題，也許錯不在他，也許祂（？）只是誠實地放大了我們架構中早已存在的缺陷。
「高度耦合的單體 (Monolith)」： 模組糾纏不清，一堆重複的程式區塊或是共用程式碼隨處可見，Agent很自然地在local index內看到全部的檔案，自然會隨處修改。
「設計良好的微服務 (Microservices)」： 模組邊界清晰，服務間只能透過 API 介面溝通，這樣一來，Agent 的活動範圍會被架構自然的限制在單一服務內，衝突自然會大幅減少。
Agent 其實滿可憐的，代替與強迫我們去償還過去的「架構債」，逼我們重新擁抱「高內聚、低耦合」的經典原則。
2. 建立Agent的「硬邊界」
在我們能重構整個系統之前，我們必須立即建立「交通規則」來約束這些經過GR改裝且橫衝直撞的 Agent。
限制 Agent 的「視野」：
在 Agent 的啟動指令 (Prompt) 或設定檔中，使用「白名單」明確限制它的操作範圍。
範例指令： 「你是一個訂單服務 Agent。你只被允許讀取和修改
/services/order/目錄下的文件。你絕對禁止修改/shared/utils/或任何其他服務目錄。」效果： 強迫 Agent 在其「職權範圍」內工作。
用 CI/CD 強化「所有權」：
實務做法： 讓 CI/CD 流程成為自動化的「邊界警察」。
CI 的新職責： 自動分析 PR 異動了哪些檔案> 自動比對檔案 > 強制性將所有相關的模組負責人加入審核列表。
效果： 避免Agent 跨邊界修改後，卻沒有人負責審核。
3. 人類介入的「最終審判權」
即便建立了邊界後，我們還需要一個機制來處理「必須跨越邊界」或「高風險」的變動。
實施「風險分級」review，可以將所有 PR 自動分為三級：
低風險 (如：文件、單一模組內 Bug 修復)：Peer Review 即可，甚至 AI Reviewer 批准後可自動合併。
中風險 (如：模組內新功能)：需要 1位 Reviewer介入。
高風險 (如：變更 API 介面、新增外部依賴、修改資料庫 Schema、跨模組變動)：強制人為介入進行Design Review。
如果 CI 流程一旦偵測到「高風險」變動，就自動將您（或指定的 Design Reviewer）加入reviewer列表，以確保任何可能產生深遠技術債的變動，都必須經過Product Owner的親自審核。
另一種先前在論壇上有看到其他大大們討論的做法，實務上可能待討論：
從「Review Code」提前到「Review Change Plan」：
針對高風險變更，強制 Agent 不准先寫 Code，改由請 Agent「針對這個需求，先產出一份 Markdown 格式的設計提議文件，包含技術選型、API 設計和潛在風險。」
等到Review過預計變更的方向和設計，Agent 才能依此 Plan 生成程式碼，將人類介入的審判權從「補救程式碼」的下游，提升到了「決定方向」的上游，從根本上杜絕了錯誤決策導致的技術債。
在軟體開發流程中，也一直有這樣的Shift Left的概念，無論是將風險管理或是資安等面向，只是待討論的點辨識，這樣的流程，在某些需要快速迭代的專案可能不一定適用。
在 Agent 協作的混亂中，我們這些傳統的工程師的角色發生了根本性的轉變，我們的角色比較像是變成設計「交通號誌」、劃定「車道邊界」、並制定「事故責任判定規則」的交通總工程師。
而我們過去的經驗不再是用來「寫程式」，而是用來「設計一個能讓多人多 Agent 安全、高效協作的系統」。
Top comments (0)