最近在看一些 multi-agent orchestration 的論文，有個問題一直在腦子裡轉：為什麼大家花那麼多力氣讓單一 agent 更聰明，卻很少認真處理「多個 agent 怎麼被組合起來」這件事？

我做 NLP 研究，平常接觸的系統大多是 pipeline 式的，有時候也會遇到需要多個 module 串接的場景。坦白說，每次要決定「誰先跑、誰處理什麼、遇到錯誤怎麼辦」，都是靠人工經驗在排，沒有什麼系統性的方法。

這個問題在 agent 系統裡更嚴重。現在很多「multi-agent framework」其實只是把幾個 LLM call 包在一起，workflow 的設計完全依賴工程師的直覺。一旦 agent registry 變大、任務變複雜，這套做法就撐不住了。

workflow composition 是一個 retrieval + systems design 問題

嚴格來說，「給定一個使用者需求，找出最適合的 agent 組合，排出合理的執行順序」，這本質上是兩個問題疊在一起：

第一個是 retrieval。agent registry 裡有幾百個 agent，你怎麼找出適合這個 task 的那幾個？硬把所有 agent description 丟進 LLM 的 context 讓它選，在 registry 小的時候還行，稍微大一點 context window 就爆了，而且 LLM 在超長 context 下的選擇品質也很不穩定。

比較合理的設計，應該是先用 fast retriever 縮小候選集，再用 LLM re-ranker 做精確選擇。這其實就是 RAG 的思路，只是對象從「文件段落」換成「agent 的能力描述」。這個拆分看起來簡單，但背後需要 agent 有結構化的 capability schema，不是隨便寫個 description 就夠的。

第二個是 systems design。找到 agent 只是開始，真正的問題是怎麼把它們排成一個 execution graph，讓整體 workflow 在面對 latency、availability 或 resource constraint 時還能跑得起來。

我覺得這裡有個常被忽略的細節：execution graph 不應該只有一條路。如果某個 agent 掛了或太慢，有沒有 redundancy path 可以切換？這需要在設計 graph 的時候就保留多條路徑，而不是等 runtime 出問題再想。

plan 和 agent selection 要放在一起驗證

另一個我覺得重要但常被跳過的設計，是整體 plan 和 agent selection 的一致性檢查。

常見的做法是：LLM 先產生一個 plan，然後針對每個 step 各自找 agent。問題是，這兩個步驟是分開做的，沒有人確認「這些被選出來的 agent 放在一起，跑完真的能達成原始目標嗎？」

比較嚴謹的設計是加一個 critique 層，不是只看某個 step 的 agent 選得對不對，而是回頭看整個 workflow 的 agent 組合是否跟 overall plan 相容。這種全局視角在系統小的時候不必要，但規模一大就會很重要。

這件事為什麼值得認真看待

做研究的人可能會說，這些聽起來只是 engineering 細節，不是真正的 research 問題。但我覺得不是。

「自動化 multi-agent workflow composition」要真的能用，需要解決幾個目前沒有好答案的問題：agent capability 要怎麼表示才能被有效 retrieved？execution graph 的搜尋空間怎麼剪枝？critique agent 要怎麼設計才不會只是另一個產生 hallucination 的 LLM call？

把這些問題框架清楚，是讓 multi-agent 系統從「demo 好看」到「production 可用」的必要條件。

我個人覺得，未來一兩年，workflow composition 這塊會成為 agent 研究裡相對獨立的方向，有點像當年 retrieval 在 QA 系統裡逐漸變成獨立子問題一樣。現在還早，框架還不成熟，但方向對的人已經在做了。🔬