最近工具圈最容易讓人興奮的，不是模型分數又提升了幾分，而是「工作方式」開始被改寫。

這篇 Threads 提到 Opus 4.6 之外，Claude Code 同步推出的 Agent Teams：你可以快速建立多個分身，讓它們彼此溝通、協作，前端遇到 API 問題能直接通知後端，少掉一層 Team Lead 的傳話成本。

作者後來也補充一個重要細節：Team Lead 仍然是必要的，只是 AI 之間多了 mailbox 機制，資訊不必再經過中間人轉述。

我認為這個修正點，剛好點出「Agent Teams 真正的價值」：它不是讓你少掉管理，而是讓你把管理從「轉述訊息」移到「定義規則與驗收」。

Agent Teams 不是多開幾個聊天視窗

很多人第一次聽到多 agent，直覺是：

• 多找幾個角色來腦力激盪
• 一個寫前端、一個寫後端、一個寫測試

這當然有用，但還停留在「分工」層級。

Agent Teams 更值得注意的是協作機制：當 agent 之間能互相質疑、互相校對，且訊息可以被正確路由，你就有機會把工作變成一個可被並行的流程，而不是靠你一個人維持所有上下文。

仍然需要 Team Lead：原因很現實

貼文裡有人問：「他們有衝突能自己解決嗎？」作者的回答很務實：

• 想法衝突，可能會吵架但逐漸收斂
• 實作衝突，可能會互相覆蓋彼此的工作

這其實就是多 agent 最常見的兩種失敗模式：

1. 語意衝突：每個 agent 對需求的理解不一致
2. 寫入衝突：同一份檔案或同一段邏輯被同時改動

所以 Team Lead 的角色依然存在，因為你需要有人負責：

• 最終決策（到底採用哪個方案）
• 邊界切分（誰負責哪一塊、介面怎麼定）
• 合併策略（避免互相覆蓋、確保可回滾）
• 品質門檻（測試、lint、review、風險）

Agent Teams 讓你不用當傳令兵，但你仍然要當總編與總工。

我會怎麼用：三個最常見的落地場景

1) 前後端聯動：用「介面契約」當作共同語言

• Team Lead 先把 API contract（request/response/schema/error codes）寫成明確文件
• 後端 agent 以 contract 實作
• 前端 agent 以 contract 串接
• 測試 agent 針對 contract 做整合測試

把衝突收斂在介面層，能大幅降低互相覆蓋的機率。

2) 既有專案重構：一個 agent 拆風險，一個 agent 做改動

• 探勘 agent：掃描 codebase、列出風險點與依賴
• 實作 agent：只負責改動
• 驗證 agent：寫回歸測試、跑 CI、檢查破壞性變更

讓「改」和「驗」分離，能避免自我說服。

3) PR review 升級：讓不同 agent 用不同視角挑刺

• Security 視角：檢查權限、注入、敏感資訊
• Reliability 視角：錯誤處理、重試、邊界條件
• DX 視角：可讀性、命名、維護成本

你會得到更接近真實團隊的 review 風格。

你真正要學的，不是指令，而是「協作設計」

很多人會問：「要怎麼開？」例如貼文留言提到環境變數、實驗開關。

但我覺得更關鍵的問題其實是：

• 你要怎麼切任務，讓 agent 彼此獨立又能整合？
• 你要怎麼定義驗收標準，讓產出可比較、可淘汰？
• 你要怎麼設計訊息流，避免資訊在轉述中失真？

當你把這三件事想清楚，Agent Teams 才會從「好玩」變成「可重複的生產力」。

原文連結：Threads 貼文

ClaudeCode #AIAgent #軟體開發 #工程效率 #多代理協作