最近刷到了一篇來自Cognition AI的博客文章，看完之后我簡(jiǎn)直有種恍然大悟的感覺。這家公司你可能聽說過，就是那個(gè)開發(fā)了明星AI編程助手Devin的團(tuán)隊(duì)。他們?cè)谶@篇文章里直接開懟了一個(gè)在AI Agent領(lǐng)域特別流行的概念——多智能體架構(gòu)，說得相當(dāng)犀利："別再搞多智能體了！"

讀完這篇文章，我覺得有必要跟大家"叨叨"一下，因?yàn)檫@些觀點(diǎn)可能會(huì)顛覆很多人對(duì)AI Agent架構(gòu)設(shè)計(jì)的認(rèn)知。

為什么大家都在搞多智能體？

現(xiàn)在一提到AI Agent，很多人第一反應(yīng)就是搞個(gè)多智能體系統(tǒng)。你看，OpenAI推出了Swarm框架，微軟有AutoGen，大家都在鼓吹讓多個(gè)AI智能體相互協(xié)作，分工合作完成復(fù)雜任務(wù)。聽起來很美好是不是？就像組建一個(gè)超級(jí)戰(zhàn)隊(duì)，每個(gè)成員都有自己的專長(zhǎng)。

但是Cognition的工程師們用血淋淋的事實(shí)告訴我們：這種想法在實(shí)際應(yīng)用中簡(jiǎn)直是個(gè)大坑！

多智能體的致命缺陷

讓我用一個(gè)簡(jiǎn)單的例子來說明問題所在。假設(shè)你要讓AI幫你做一個(gè)"憤怒的小鳥"游戲。按照多智能體的思路，你會(huì)把任務(wù)分解給兩個(gè)子智能體：

智能體A負(fù)責(zé)做游戲背景，要求是"做一個(gè)有綠色管道和碰撞檢測(cè)的移動(dòng)背景"。

智能體B負(fù)責(zé)做小鳥，要求是"做一個(gè)可以上下移動(dòng)的小鳥"。

聽起來很合理對(duì)不對(duì)？但現(xiàn)實(shí)是什么樣的呢？

智能體A可能誤解了你的意圖，做出了一個(gè)超級(jí)馬里奧風(fēng)格的背景。智能體B做了一只小鳥，但完全不像游戲資源，移動(dòng)方式也跟憤怒的小鳥八竿子打不著。最后，主智能體拿到這兩個(gè)"四不像"的產(chǎn)品，只能哭著想辦法把它們拼在一起。

這就是多智能體架構(gòu)的第一個(gè)致命問題：上下文丟失。每個(gè)子智能體都只能看到自己的小任務(wù)，看不到整體的大圖景，容易產(chǎn)生理解偏差。

更深層的問題：隱式?jīng)Q策沖突

即使你覺得可以通過傳遞更多上下文來解決上面的問題，但還有一個(gè)更要命的問題：隱式?jīng)Q策沖突。

繼續(xù)用剛才的例子。假設(shè)你把完整的任務(wù)描述都傳給了兩個(gè)子智能體，這次它們都理解了要做憤怒的小鳥游戲。但是，智能體A選擇了像素藝術(shù)風(fēng)格，而智能體B選擇了3D渲染風(fēng)格。最終你得到的是一個(gè)風(fēng)格完全不搭的"怪胎"游戲。

問題在于，每個(gè)智能體在執(zhí)行任務(wù)時(shí)都會(huì)做出大量的隱式?jīng)Q策，而這些決策往往是沖突的。就像兩個(gè)廚師分別做菜，一個(gè)做的是川菜，一個(gè)做的是粵菜，最后要拼成一桌菜，結(jié)果肯定是四不像。

Cognition的解決方案：?jiǎn)尉€程才是王道

經(jīng)過大量的試錯(cuò)，Cognition團(tuán)隊(duì)得出了一個(gè)看似"倒退"的結(jié)論：最可靠的架構(gòu)其實(shí)是單線程的線性智能體。

這就像是從"多人協(xié)作"回到了"一個(gè)人包辦"，但這樣做的好處是：

上下文始終保持連續(xù)和完整。每一步行動(dòng)都能看到之前所有的決策和結(jié)果。不會(huì)出現(xiàn)不同部分之間的風(fēng)格或邏輯沖突。系統(tǒng)的可靠性大大提高。

當(dāng)然，對(duì)于特別復(fù)雜的長(zhǎng)期任務(wù)，單線程可能會(huì)遇到上下文窗口不夠的問題。Cognition的解決方案是引入一個(gè)專門的"記憶壓縮"模型，負(fù)責(zé)把歷史行動(dòng)和對(duì)話壓縮成關(guān)鍵信息，類似于人類的長(zhǎng)期記憶機(jī)制。

現(xiàn)實(shí)世界的例子

文章還提到了幾個(gè)現(xiàn)實(shí)世界的例子來佐證這個(gè)觀點(diǎn)：

Claude Code：雖然會(huì)生成子任務(wù)，但從不并行工作，子智能體通常只負(fù)責(zé)回答問題而不寫代碼，避免了上下文丟失的問題。

編輯應(yīng)用模型：2024年很多編程智能體都采用了"編輯-應(yīng)用"的兩階段模型，但經(jīng)常出現(xiàn)小模型誤解大模型指令的問題。現(xiàn)在更多采用單一模型一步到位的方案。

為什么多智能體這么誘人但這么坑？

你可能會(huì)問，既然多智能體這么不靠譜，為什么還有這么多人在搞？

原因很簡(jiǎn)單：看起來很酷，聽起來很合理。就像早期的Web開發(fā)，大家都在用原始的HTML和CSS拼湊頁面，直到React這樣的框架出現(xiàn)，才有了標(biāo)準(zhǔn)化的開發(fā)模式。

現(xiàn)在的AI Agent開發(fā)就處在這個(gè)"拼湊"階段。多智能體架構(gòu)看起來像是一個(gè)很自然的解決方案，但實(shí)際上它違背了一些基本的工程原則。

未來會(huì)怎樣？

Cognition的工程師們并不是完全否定多智能體的未來。他們認(rèn)為，當(dāng)單線程智能體變得足夠好，能夠更好地與人類溝通時(shí)，多智能體協(xié)作才會(huì)變得可行。

就像人類團(tuán)隊(duì)協(xié)作一樣，效果好的前提是每個(gè)人都足夠聰明，溝通效率足夠高?，F(xiàn)在的AI還沒有達(dá)到這個(gè)水平。

對(duì)我們的啟發(fā)

這篇文章給我們的啟發(fā)是：在AI領(lǐng)域，有時(shí)候"更簡(jiǎn)單"反而是"更好"。

不要為了追求概念上的"先進(jìn)"而忽視實(shí)際的可靠性。在架構(gòu)設(shè)計(jì)時(shí)，要優(yōu)先考慮上下文的完整性和決策的一致性。技術(shù)的成熟需要時(shí)間，不要急于采用看起來很酷但還不成熟的方案。

所以啊，今天跟大家聊了這么多，其實(shí)就是想說：別被那些花里胡哨的多智能體架構(gòu)迷了眼。有時(shí)候，一個(gè)設(shè)計(jì)精良的單線程智能體比一群"各自為政"的多智能體要靠譜得多。

從工程角度來看，AI Agent就像個(gè)能干的"全能型選手"，而不是一支"各有專長(zhǎng)但配合不佳"的團(tuán)隊(duì)。當(dāng)然，隨著技術(shù)的發(fā)展，也許未來真的會(huì)有那種配合默契的AI團(tuán)隊(duì)，但至少現(xiàn)在，我們還是老老實(shí)實(shí)地把單個(gè)智能體做好吧。

本文轉(zhuǎn)載自????芝士AI吃魚??，作者：芝士AI吃魚