這次來導讀另一篇文章好了, 由 Cognition 發表的文章:
Don’t Build Multi Agents.
這半年來經手的問題, 越來越多都是 context 處理不當造成的 ( 就是所謂的 context engineering ), 不過把 AI agent 對比成真人的話, 這其實這就是團隊溝通跟管理技巧而已..
—
以下, 我一律把 agent 當作真人看待, 來思考解決方案。而在這之前，你要先理解 AI 跟真人之間有何差異:
智商: 真人每個人的智商都不同，而 AI 只要你用同一個模型，我就當作是一樣的。真人智商很難大規模提升，而 AI 很容易 (模型幾個月能力就翻一輪了，模型一換所有 Agent 智力就提升了)
經驗: 說穿了就是你念過的書 (long term memory)，以及你過去解過問題的經驗 (system prompt)。同樣的真人的經驗很難複製，特別是越厲害的專家越困難。而 Agent 只要大家都存取同一套知識庫 (RAG)，共享 prompt, 甚至共享進行中任務的 context, 就能複製經驗 (依據經驗來做目前任務的判斷)
真人的團隊中, 你很難湊滿整個團隊都是高智商的, 但是 Agent 可以。真人團隊中你很容易靠成員自己不斷調整工作流程, 持續改善, 而 Agent 還沒辦法, 你需要仰賴 domain 專家來持續調教 system prompt.
這對比的方法非常重要，這也是我延續過去 20+ 年工作經驗的方法。當我有能力對比的時候，我能運用的是 20+ 年的能力x來設計 Agent, 沒有的話我只是個 2 年經驗的新鮮人…
—
回到 Multi-Agents 的問題，越複雜的問題，越需要拆解成多個子任務，交給多個 Agent 各個擊破。然而 Agent 之間協作效率跟品質好不好，直接影響了解題的品質觀念。很多專家或架構師，都告訴你任務交給 AI 的時候要切的越小越明確越好，但是他們沒有講的是…
切越小，整體的正確率是越好還是越差? 品質是越好還是越差?
先來看一下現實世界的幾種分工模式:
-
無腦分工, 大家只聽老闆分配任務, 彼此不溝通。 效率最好，但是缺乏協作。工廠或生產線可以這樣做，但是越是需要創意或是設計的任務，相依性越高，你的設計會影響別人下一步工作方式，這就行不通 (對照文章的第一個例子: almost surely unreliable)
-
分工 + 交接給下一棒: 平行處理時彼此一樣不協作，維持好效率，但是彼此都要清楚地把工作日誌交給下一棒。等到需要合併兩者任務結果時，他就有依據可以做調整。不過成效有限，因為後面的階段已經無法改變前面交付的成果了，他頂多只能修正或調整，整個做錯不合用的東西是修不過來的.. (對照文章的例子: still unreliable)
-
流水線，依序完成任務: 其實就是線性代理。前一關完成任務後，完整交代工作日誌給下一棒。下一棒可以依據日誌來決定他要怎麼做。如果沒辦法接手，也可以在第一時間退回 (至少第二棒不會白做)，一路往下，直到完成為止。這方法簡單且可靠，但是越大規模的任務，拆解後越後面的關卡，他的認知負擔最重 ( context window 放不下 )。為了完成他的任務，他可能要看完前面 100 關的所有工作日誌… (對照文章的例子: simple & reliable, 以及 but struggles with longer tasks)
即使如此，基本的工作方法其實已經足以解決大部分的問題。你只需要做些優化或調整，就能更擴大這方式的應用範圍。文內介紹的一種方式，就是簡化工作日誌，意思是工作日誌中只放摘要，或是關鍵的重點，降低後面每一關的認知負擔，同時能維持它的效益 (文內的例子: reliable on longer tasks, but hard to get right )
前半段 ( reliable on longer tasks ) 很直覺, 後半段 ( but hard to get right ) 是什麼意思? 簡單的說，你摘要的 “重點” 是不是真正的 “重點”，如此而已。如果我把重點對比成這階段產出的 QC ( quality check ) 結果，那關鍵就是你的 check list 做的夠不夠好? 有多少 QC pass 的成果流到下一關結果不能正常運作? 換成其他的 key moments & decisions 也一樣, 你摘要的重點能不能讓後面的關卡做好決策?
這 ( hard to get right ) 就很吃團隊 SOP 的成熟度，以及管理者的經驗能力 (這邊就是 agent 的設計者了, 經驗還沒那麼好複製 XDD)。在目前 AI 還沒涵蓋到這範圍之前，這仍屬於 hard to get right 的範圍。
在真人團隊中, 有效的工作方法 (例如 Agile, 每日站立每個人講三件事, 就是有效的協作) 能改善這些狀況，而 Agent 則需要仰賴有經驗的專家來調整 system prompt / instructions 來持續改善跟評估成效。
原文提到他們額外微調一個專屬的小模型來做這件事，這是作者解題的手段，目的是有效的取出關鍵資訊。你不一定要跟他們一樣微調或訓練小模型，但是你至少要有辦法解決這問題。用明確的 SOP，寫成夠清楚的 system prompt 來負責摘要，也是個方法。
其實不是說不要用 Multi-Agents 啦，文章內自己也講了，必要的時候再用。一來單純的架構其實已經足以解決很多問題了 (如上所述)。真正踏入 Multi-Agents 的世界，就像真正的工作場合一樣，你找越多人效率不一定越好，因為會有更多機會彼此意見不合，你需要付出額外的管理成本才能讓他們有效率的協作… 只有在有必要時你才應該考慮 Multi-Agents, 而且你需要像管理真人團隊一般, 設計好 Multi-Agent 之間的協作機制與對話機制。
—
這篇出自 cognition 的技術部落格, 沒聽過這公司的話，它就是開發 Devin, 業界第一個 software engineer Agent 的公司。同時它們也是最近收購了 Windsurf 的那家公司.. 它們的本業就是開發一堆 agent 來完成軟體開發的任務, 我想這主題由它們來探討, 算是蠻有說服力的 XD
原文我貼在留言, 有興趣請自行參考~
