Agent Teams 避坑指南：別再用它寫全端的「展示用小玩具」了

你在 YouTube 上一定看過這種「好像很厲害」的展示影片： 給出一個超長的 Prompt：「請用 Agent Teams 幫我開發一個全端背單字 App！Agent A 負責前端、Agent B 負責後端、Agent C 負責 UI、Agent D 負責 QA Test。」

然後看著終端機裡的多個 Agent 互相交談，分配任務，最後竟然真的跑出一個 App，感覺超級神奇對吧？

但我必須說：在真實世界的專案中，這是非常糟糕的作法。

這種用法頂多只能做出一個「小玩具」。在這種展示影片裡，那個所謂的「QA Test Agent」其實是在做假——整個專案能順利跑完，純粹是因為它本質上就是個「展示用」的簡單專案。QA Test 實際上只是拿著跟開發者同一個 Prompt 的上下文在自嗨測試，根本無法抓出真實場景的各種 Edge cases。

到底怎樣才是 Agent Teams 的正確打開方式？

要避免把 Agent Teams 當成進階版的玩具，我們必須回歸官方的定義。根據 Claude 官方的建議，Agent Teams 真正能發揮威力的是以下這些場景：

• Research and review（研究與審查）：多個隊友同時調查問題的不同層面，然後分享並「互相挑戰」彼此的發現。
• New modules or features（新模組開發）：隊友各自負責獨立的區塊，不互相踩腳 (stepping on each other)。
• Debugging with competing hypotheses（競爭假說除錯）：隊友平行測試不同的理論，像科學辯論一樣，更快收斂出正確答案。
• Cross-layer coordination（跨層協作）：一項涵蓋前端、後端和測試的總體變動，由不同隊友分別負責。

看出來了嗎？使用 Agent Teams 的本質，在於它們的協作必須具備 互動調查的意義。

目標不能太大：讓討論產生實質意義

Agent Teams 最核心的概念就是 目標一致。這也意味著，丟給 Team 的目標絕對不適合太大。

如果你只是丟一句「幫我寫個全端 App」，各個 Agent 之間根本沒有具體的技術問題需要討論，只會淪為各說各話的代碼生成器。 但如果你把目標縮小到具體的痛點，例如：修復這個跨層的 Bug、針對這個效能瓶頸進行 Research。這種時候，Agent 之間的討論才會產生價值，因為它們是真的在一層層剝開技術細節，而不是在跑過場。

寫前後端功能？用 Superpowers 反而更好

如果你真的想要穩紮穩打地寫出一個具備前後端的真實功能，我反而比較推薦用我們之前介紹過的 Superpowers 框架 + Git Worktree 的作法。

為什麼？因為在實際的功能開發流程中，我們更需要的是「紀律」：這多出了 Brainstorm -> Plan -> TDD（測試驅動開發） 這種一步一步來的硬性規範。Superpowers 的強制檢核機制，比起讓一堆 Agent 在 Task List 裡自由發揮，更能保證中大型專案產出程式碼的品質和可靠性。

下一步：更厲害的進階用法

當我們把 Agent Teams 聚焦在「縮小目標、互動調查」之後，其實這套機制還有一個非常厲害的進階玩法。

我們下一篇文章，將會接著探討 Anthropic 官方提出的另一種模式：Harness design for long-running apps，看看我們要怎麼設計，才能讓 AI 的協同工作發揮最大的長期價值！