Multi-agent 不是越多越好,先把一個做穩再說
Scale 太快的代價,做 PM 的都見過。
有人把 12-agent 的 OpenClaw 設定整個重建,花了兩天。根本原因:架構決策超前於對工具的理解。12 個 agent 代表 12 份 instruction、12 套 SOUL.md,加上 agent 間的 communication protocol。連單一 agent 怎麼穩定都還沒搞定,就開始水平擴張,維護成本是指數型的,不是線性的。
Communication 是獨立的 design problem
很多人以為在 .md 裡面寫「有問題找 X agent」就算設計了。不是。channel 要明確定義:誰發、誰收、格式是什麼。這跟 microservice 的 interface contract 一樣,不清楚,runtime 就爛掉。
我判斷 complexity 是否超標有個 rule of thumb:一個新成員能不能在一天內看懂整個架構。不行,就代表你已經超出可維護的邊界了。
如果還在早期
先把一個 agent 做穩,不是「大部分時候 work」的穩,是真的穩。第二個 agent 只做一件事,interface 先定義好再動手。混搭不同 model 完全 ok,但基礎架構要先固定。
還有一點:讀 docs 比讓 model 幫你設定快。model 沒有你的 context,你有。
兩天重建說起來不貴,很多 enterprise project 是花了兩個月才意識到同樣的問題。
作者:Vivian L