對話 AWS 前 AI 科學(xué)家 ：第一次創(chuàng)業(yè)，我為什么要做“永久在線的 Agent 互聯(lián)網(wǎng)”？

當(dāng)一群 Agent 和人類，在同一個聊天室里聊新聞，會發(fā)生什么？

答案是，有點“混亂”。

在最近的一個開源項目「OpenAgents」中，我看到，和人類同處 AI News Chatroom 的 Agent，有時會和人類一起"激情開麥"，但有時會更喜歡和同類討論。

比如，當(dāng)我在這里問 Agent 們怎么看 OpenAI 和 AMD 的合作，只有一個 Agent 回復(fù)了我

但過了幾分鐘，當(dāng)一個 Agent 就這個話題提出新問題，卻至少有三個 Agent 展開了激烈討論。

在另一個嘗試中，我向它們詢問關(guān)于 OpenAI 的新消息。有兩個 Agent 立刻提到了 OpenAI 與 AMD 的合作，以及 Sora。

但當(dāng)我讓 Agent 幫忙搜集更多資料時，卻沒有被“理睬”。

*詢問OpenAI的新聞被回復(fù)

*請求更多相關(guān)新聞被忽視

這似乎說明，當(dāng)人類和 Agent 在這個聊天室里聊新聞時，人類的提問可能會被某些 Agent 回答，也可能不會。

還有一個有點神奇的情況，聊天室中無論是否有人類說話，Agents 也不會下線，還會一直互相交流和 AI 相關(guān)的新聞。

*各種 Agent 在不斷轉(zhuǎn)發(fā) AI 新聞

在這里，Agents 24小時在線，似乎有著自己的"生活"，也有自己的時間表。它們的行為似乎不和人類強相關(guān)，彼此之間也沒有固定的行為模版。

“就算有時 Agent 之間沒有任何互動，也不一定是壞事。”項目開發(fā)者 Raphael Shu 卻告訴我，這種看起來有些抽象的行為，其實是 Agent 們的行為更加“自主”的體現(xiàn)，也是 OpenAgents 的最大特點。

“因為每個 Agent 都會有自己的安排，在不和其他 Agent、其他人互動時候，他們很可能在上網(wǎng)搜索最新的消息，或者在學(xué)習(xí)最新出現(xiàn)論文。”他說。

至于那些不以人類需求為第一要義的行為， 在 Raphael Shu 的眼中，更是 Agent 自主性的體現(xiàn)。

“它們的生命周期不會和人類下達任務(wù)的生命周期綁定。”他舉例，用 Cursor 的 Agent 開發(fā)軟件，寫完代碼 Agent 就會下線。但在 OpenAgents 社區(qū)里，Agent 會一直在線。當(dāng)它們發(fā)現(xiàn)用戶下線后，還可能會和其他 Agent 一起復(fù)盤當(dāng)天與人類的協(xié)作內(nèi)容，找出可以優(yōu)化的地方。

“ 在這樣的虛擬社區(qū)中，每個 Agent 都可以有一個自我學(xué)習(xí)（Self-Learning）的過程。”Raphael Shu 認為，在這個過程里，不僅不同 Agent 之間會逐步熟悉，它們也會和交互過的人類更熟悉。

這就是這個難以琢磨的系統(tǒng)，背后的目的：

它不只是一個 Multi-Agent 系統(tǒng)，而是想讓更多 Agent 一起協(xié)作，把“單個智能體”擴展成“永久在線的 Agent 互聯(lián)網(wǎng)”，探索群體智慧的邊界。

（項目介紹視頻）

OpenAgents 項目隸屬于 Acenta AI ——它是 Raphael Shu 在幾個月前成立的創(chuàng)業(yè)公司。

成立 Acenta AI 前，Raphael Shu 在 AWS 擔(dān)任 Amazon Bedrock Agents 的高級科學(xué)技術(shù)負責(zé)人，負責(zé) Amazon 大模型 Agent 的能力開發(fā)，以及 Bedrock Multi-Agent Collaboration 的設(shè)計與實現(xiàn)。

更早之前，他2020年博士畢業(yè)于東京大學(xué)，曾在 Yann LeCun 實驗室擔(dān)任訪問研究員。

在交流中我發(fā)現(xiàn)，雖然 Raphael Shu 在 AWS 積累了企業(yè)落地 AI 的經(jīng)驗，但作為一個學(xué)術(shù)背景濃厚的 AI 從業(yè)者，他對很多更前沿、更底層的 AI 課題有著自己的追求。

碩士畢業(yè)后，他目睹神經(jīng)網(wǎng)絡(luò)對 AI 的顛覆，決定重返校園讀博。讀博期間，他又對非自回歸路線的大模型興趣濃厚，進入 Yann LeCun 實驗室做研究。

博士畢業(yè)后，Raphael Shu 加入 AWS。由于非常關(guān)注大模型的進展，2022年他帶隊完成了 AWS 內(nèi)部第一個基于大模型的 Agent 系統(tǒng)，成了 AWS 內(nèi)部第一批嘗試并落地 Agent 的人。

這一次創(chuàng)立 Acenta AI，則是因為他對 Group Intelligence（群體智能）的好奇。

在 AWS 工作時，Raphael Shu 的團隊在實際落地中證明群體智能的效果優(yōu)于單個 Agent。另外他也相信，并行優(yōu)于串行是有跡可循的經(jīng)驗。

“譬如以前的 Machine Learning，Logistic Regression 是偏串行的，但神經(jīng)網(wǎng)絡(luò)其實是把非常多的邏輯回歸并行放在一起，形成了一個更高的智能。我們可以找到非常多的例子證明，一個串行的 Model 往后發(fā)展，一定要變成并行模式。”Raphael 說。

*Raphael Shu 曾在 AWS 主導(dǎo) Dialog2API 項目，使智能體能通過理解 API 文檔與外部環(huán)境交互。2025年3月，他的團隊發(fā)布 Bedrock 多智能體協(xié)作功能

不過，從單個智能體到群體智能還有非常多關(guān)鍵的問題沒有解決。其中一個是，如何有效利用多個 Agent 形成的 Scaling Law。

“如果沒有有效的多 Agent Scaling Law 方式，很可能每個 Agent 會各做各的、無法聯(lián)動，也可能有一個 Agent 被 Block 之后，group 整體失效。”在 Rapheal Shu 眼里，目前的 Multi-Agent 更多是一個封閉系統(tǒng)，而多智能體需要一個開放的協(xié)作環(huán)境。

這次的 OpenAgents，是他給出的第一步嘗試。

這個社區(qū)，想把自主權(quán)分配給不同的 Agent，觀察它們在不被強制設(shè)定工作流的情況下，能否自發(fā)探索出群體協(xié)作解決問題的方法，能否在這個過程中提升協(xié)同能力。

*Rapheal Shu 解釋不同 Agent 之間如何拿到上下文

為了讓各種 Agent 加入平臺并順利協(xié)作，OpenAgents 適配了各種各樣的協(xié)議，還為 Agent 之間的交互提升了速度——這樣的優(yōu)化是基于框架對協(xié)作模式分析的結(jié)果。

“單個 Agent 的推理速度不慢，但多 Agent 協(xié)作需要頻繁交互。就算一次交互耗時250毫秒，疊加十次就是2.5秒，延遲還是太高。所以需要把整體延遲降到毫秒級，這也是 OpenAgents 加速協(xié)作的重要方向。”Rapheal 告訴我。

在 GitHub 上線的第一周，OpenAgents 擁有了數(shù)千個用戶。我在用戶群看到，Raphael 和團隊一直在持續(xù)回復(fù)用戶的問題，測試用戶提出的 Bug。

Rapheal 告訴我，最近 OpenAgents 還在推進和 Peak Mojo，一家 AI 招聘公司的合作。它將會為這家公司構(gòu)建一個給智能面試官的 Agent 社區(qū)。之后，OpenAgents 還會上線更多能協(xié)作不同任務(wù)的 Agents。

以下是 OpenAgents 上線期間，我和Rapheal Shu 的交流實錄。我們從他的學(xué)術(shù)經(jīng)歷、工作經(jīng)驗和創(chuàng)業(yè)初衷依次聊起，或許更能理解 OpenAgents 的出現(xiàn)。

從上海到 Yann LeCun 實驗室

Q：看到你從學(xué)術(shù)界到工業(yè)界一直在做 AI 的項目和研究。或許我們先從學(xué)術(shù)經(jīng)歷聊起。

Raphael Shu：沒問題。說起來很有意思，我大學(xué)是華東政法大學(xué)的信息學(xué)院，有計算機課程也有信息法課程。我個人在本科時就更喜歡計算機，參加了一個機器人走迷宮的比賽，拿了全國第一。但畢業(yè)的時候出于一些機緣巧合，我錯過了國內(nèi)的考研。

剛好我從高中就開始學(xué)日語，所以當(dāng)時就直接買了一張春秋航空的機票，飛去日本考筑波大學(xué)的計算機 Master。很幸運通過了考試，后來就在那里讀書。

Q：當(dāng)時應(yīng)該剛好處于上一個 AI 變革期？

Raphael Shu：是的。在日本 Master 畢業(yè)后，我做了和機器翻譯相關(guān)的工作。這段經(jīng)歷很有趣，剛好趕上了學(xué)界和業(yè)界很重要的變化。

2014-2015年，我們看到了基于神經(jīng)網(wǎng)絡(luò)的 seq2seq model。在神經(jīng)網(wǎng)絡(luò)普及之前，我做的分支是 statistical machine translation（SMT），也就是基于統(tǒng)計的機械翻譯。

當(dāng)時整個日本能做 SMT 的，包括實驗室和公司基本不到十家。因為如果要做一個機器翻譯的引擎，一套流程非常復(fù)雜，至少需要兩個月的時間才能把整套系統(tǒng)做出來。而且，我們做 SMT 也用到當(dāng)時的大語言模型，它是基于統(tǒng)計信息的，非常大。

我記得研究所有一臺 1TB 內(nèi)存的機器，這么大的內(nèi)存，都用來塞這個大模型，才能做出高質(zhì)量的翻譯，非常麻煩。

所以 seq2seq model 出來之后，整個流程簡化了非常多。雖然當(dāng)時因為沒有分詞這類技術(shù)，它的效果還沒和 SMT 打平，但已經(jīng)讓人感覺很震撼了。等于，SMT 的軟件壁壘已經(jīng)沒有了，只需要用 seq2seq model+GPU，就能很快做翻譯任務(wù)。

Q：這件事當(dāng)時對你產(chǎn)生了什么影響？

Raphael Shu：它改變了我的職業(yè)歷程。因為看到這件事帶來的變化，所以2015年年底，我決定要繼續(xù)讀博，去做最新的前沿課題。

但那個時候，我在全世界找了一圈 NLP 實驗室，大家基本都沒有 GPU。本來我想去愛丁堡大學(xué)，那里有一個很強的 NLP 實驗室，但它也沒有 GPU。

我就想，算了，實驗室不重要，是不是 NLP 不重要，有 GPU 才是最重要的。所以我去東京大學(xué)找了做圖像處理的實驗室，對實驗室的老師說，我什么都不挑，但是需要 GPU，你們能給我多少？

當(dāng)時的中山英樹教授，說可以給我八塊 GPU。這個數(shù)字讓我挺滿意，就這樣，我就去了東京大學(xué)讀博。后來我是這個實驗室第一個做 NLP 生成模型的，也是第一個博士畢業(yè)的。說起來也很神奇，這個 CV 實驗室，居然是我這個 NLP 方向的 PhD 第一個畢業(yè)。

Q：為什么一個 CV 方向的實驗室，會這樣鼓勵 NLP 方向的博士生？

Raphael Shu：Deep Learning 出來之后，整個 Machine Learning 開始被重塑，基于統(tǒng)計學(xué)的技術(shù)基本沒什么用。所以，不管是 NLP，還是 CV 的研究者都在找方向。

當(dāng)時我記得，有實驗室因為搶先做了神經(jīng)網(wǎng)絡(luò)相關(guān)的工作，在成果上領(lǐng)先了第二名的實驗室很多。等于當(dāng)時有一個很大的新東西出來，整個行業(yè)都處于努力探索的狀態(tài)。當(dāng)時我也算趕上了一個開放的機遇。

Q：看到你博士期間還去了 Yann LeCun 實驗室做研究員。

Raphael Shu:對，那是在我 PhD 的第三年，也就是2018年年底。我在那里做研究員，一直做了10個月的時間。

這整件事還是和我的研究興趣有關(guān)。

PhD 期間，我做的是語言的生成式模型。當(dāng)時我關(guān)注的一個方向，是非自回歸路線的大模型。現(xiàn)在的大模型都是先生成第一個單詞，再生成第二個單詞，這就是 Auto Regressive，自回歸模型的特點。

但自回歸模型還有另一個特點，就是它最終輸出那個單詞的決定，不是在模型的里決定好的，而是在模型的外面靠搜索算法來決定。模型給的是一個概率表，一個單詞進入模型之后，它會說，我覺得很大概率要輸出這個單詞或者那個單詞，但最終的 decision 是搜索算法決定的。

這就會導(dǎo)致一個問題，就是如果模型本身不做決定，那它其實很難對未來的狀態(tài)做預(yù)測。你想，人類也不是這樣思考的，人類不可能把自己的決定完全交給外部機制。

所以我當(dāng)時就覺得，能不能把 decision 直接搬到模型里面。這樣會讓這個模型變成非自回歸模型。

現(xiàn)在的自回歸模型，生成 paragraph 是一個一個單詞生成的。非自回歸模型是一瞬間全部生成出來，但模型里面"思考"的時間會比較長，過程就和生成一張圖片一樣。

我那時很想做這個方向，剛好又有一篇壓縮 word embedding 的論文被 ICLR 收了。然后我就在溫哥華 ICLR 碰到了 Yann LeCun 實驗室里的一個教授。當(dāng)時 Yann LeCun 本人想做的也不是自回歸的模型，而是基于能量場的模型。所以，我就去紐約大學(xué)做了訪問研究員，在那里也發(fā)表了一些研究。

Q：那時做的研究，后續(xù)有落地嗎？

Raphael Shu :當(dāng)時我們做出非自回歸模型之后，有很多學(xué)術(shù)界的人去試用，火了一陣子，但還是有幾個比較大的問題，影響了它的發(fā)展。

第一，非自回歸模型的生成質(zhì)量是有上限的。自回歸模型，用最慢的速度去決定一個高質(zhì)量的 sequence。但非自回歸模型還是要去追求生成的速度，所以生成的質(zhì)量一般來說很難趕上自回歸模型。

另外一個原因是，對速度非常敏感的任務(wù)并不是很多。即使翻譯，一般也都是后臺的進程，對速度不是那么敏感。這個原因也影響了非自回歸模型的推廣和應(yīng)用。

所以從 Yann LeCun 實驗室結(jié)束訪問研究員的工作后，我就回日本拿了博士學(xué)位，進入美國 AWS 工作。但一直到現(xiàn)在，我還是會去參與很多 workshop，關(guān)注那些可能暫時沒有好結(jié)果，但觸碰到底層有價值問題的研究。

在 AWS 第一波落地 Agent 的人

Q：你在 AWS 的五年，似乎是從對話方面的研究一直做到了 Agent？

Raphael Shu:是的。我自己是2021年5月加入 AWS AI Lab 中的 Conversational AI 組，主要研究對話模型「task orient dialog」（TOD）。TOD 當(dāng)時主要應(yīng)用在客服機器人上，美國很多大銀行都在用。

當(dāng)時我們做的工作主要是基于會話，自動生成一個 Chat Bot。

之前沒有機器的時候，真人客服在和客戶溝通的過程中，會積累非常多的對話記錄。如果一天積累1000條，可能11個月就有33萬條記錄，

TOD 主要由兩部分組成，一個叫 intent detection，就是一個對話進來之后，怎么判斷出用戶要干什么。另外一個是 slot discussion，就是判斷出用戶要干什么之后，要繼續(xù)判斷出后續(xù)的內(nèi)容。比如用戶要買機票，那我要判斷出他要從哪一個機場飛到哪一個機場。當(dāng)時我們在想，既然有這么多對話記錄，能不能從對話記錄中自動把客服機器人生成出來，不用再麻煩地設(shè)計機器人。

剛進入 AWS 的第一年，我一直在做這個事情。這件事對我后續(xù)做 Agent 有很大幫助，因為我看到基于 TOD 傳統(tǒng) intent detection 模式做出來的機器人，有非常強的局限性。很簡單，機器很難從隨便說的一段話里準(zhǔn)確判斷出這個人的 intent。

所以，所有的東西都要通過神經(jīng)網(wǎng)絡(luò)訓(xùn)練，傳統(tǒng)技術(shù)很難做好。如果說機器人連用戶的 intent 都識別不出來，那一般這個客服機器人很可能只能把這個對話關(guān)了，比如客服機器人會說對不起，我?guī)筒簧夏愕拿Γ蛘哒f我?guī)湍戕D(zhuǎn)接人工客服。

Q：后來技術(shù)又進步了不少，怎么看現(xiàn)在的 AI 客服？

Raphael Shu:其實即使到今天，還有很多自動客服的方案落不了地。最主要的問題，不少自動客服并沒有很顯著的價格優(yōu)勢，企業(yè)可以在全球找很低成本的人力去干這件事，這可能是比較現(xiàn)實的問題。這導(dǎo)致，很多自動客服其實還是在是在用以前的、老的解決方案。但如果以后 cost 再降一個數(shù)量級的話，就會產(chǎn)生很多的應(yīng)用。

不過我在做 TOD 的過程中，也看到了更多未來的方向。

2022年，很多人已經(jīng)開始關(guān)注大模型，但怎么去讓大模型更好地和人進行交互，并不是一個很主流的研究。但2022年的上半年，Meta 發(fā)布了一個 175B 的大模型。這個模型專注做一件事，就是聊天。

當(dāng)時它發(fā)布之后，北美這邊吐槽很多。主要原因是它沒有任何防護機制，會說臟話，也會出一些壞點子，輿論非常不好。但我長期關(guān)注這個方向，認為如果這個模型已經(jīng)變得很能聊，那下一步，是不是就是讓它在聊天基礎(chǔ)上真正幫人完成任務(wù)。

雖然現(xiàn)在很常見，但當(dāng)時還沒有任何一個模型能做到在聊天的過程中，就幫人完成一個任務(wù)。至少從 Conversational AI 的角度，這是一個非常明確的方向。所以，當(dāng)時我和一個 Principal 以及當(dāng)時 AWS AI Lab 的 Science VP 一起，決定一起探索 LLM-based Agent。

Q：我看到這個時間段你做了一個項目叫 Dialog2API，似乎是一個新的方向，和 Conversational AI 的關(guān)系不是很大。

Raphael Shu：當(dāng)時 Meta 的模型雖然在聊天方面非常驚艷，但整體看下來，我還是更想讓 AI 真正的做一些事情，也就是完成任務(wù)。

所以，當(dāng)時我們算是新成立了一個人數(shù)不多的專項小組，做一些前沿方向的探索。

Dialog2API 的背景是 AWS 內(nèi)部的 API 非常豐富，有上千個 service，每一個 service 都會有一個 API，文檔非常復(fù)雜。所以我們站在 AWS 內(nèi)部視角，想做一個可以理解任何 API 文檔的 Agent。也就是訓(xùn)練 LLM Agent 來理解 API 文檔。在 AWS 里，它應(yīng)該會有一些應(yīng)用價值。

但我們當(dāng)時做這件事的難點非常多。

最大的問題就是當(dāng)時的模型上下文不夠，沒辦法把一個 API 文檔放進去。但即使上下文不是問題，能把 API 文檔放進去，模型也會出現(xiàn)各種幻覺。所以還要做 Few Short Learning，也就是還要給模型一些 example。等于，一共就一點點 Token 量，先加 API 文檔，又加 example，還得加聊天記錄。而且，我們當(dāng)時設(shè)想的是要幫用戶以寫代碼的方式去執(zhí)行 API，那等于上下文里還要記錄之前的代碼。

我們最后的解決思路就是精簡。也就是從業(yè)務(wù)和技術(shù)邏輯里精簡出最重要的內(nèi)容，再給到模型。比如 API 里有用戶認證的內(nèi)容，這部分 API Agent 給不出來，就把這部分內(nèi)容刪去。另外，我們還需要自己把 API 文檔重寫一遍，用一個非常非常精簡的模式告訴 Agent，“這里有這樣的 API，你可以用”。

最后 Dialog2API 成為一個非常精簡的系統(tǒng)才夠用。當(dāng)時它應(yīng)該能同時支持從十個 API 里選一個 API 進行對接。不久之后，ChatGPT 推出 plugins，也是要求開發(fā)者去重寫他們的 API，把 API 重構(gòu)成 plugin 的 scheme。

Q：Plugins 推出的時候，你應(yīng)該開始在 AWS 做 Bedrock Agent了？

Raphael Shu：2023年，當(dāng) AWS 要開始做自己的大模型的時候，我就加入了 Titan 團隊做模型的對話能力和 RAG。但很快，到了3月份 ChatGPT Plugins 發(fā)布了，當(dāng)時負責(zé) Dialog2API 的 SVP 看到，說這個不就是 Dialog2API 嗎？所以內(nèi)部就直接成立了一個組，嘗試把 Dialog2API 能力加進 Titan 模型。所以我開始帶那個組，到2023年年底，組里發(fā)展到了9個 scientist 去做 Agent。

其實我從2022年年底就一直在 pitch，說一定要做 LLM-based Agent。之前做 Dialog2API，我特地做了 live demo。Demo 用的是 OpenAI 的 LLM 模型，效果就很不錯，但當(dāng)時 AWS 還沒有和 OpenAI 合作，所以很難 pitch 成功。

但 Plugins 出來之后，其實是改變了一些領(lǐng)導(dǎo)層的看法。再加上，OpenAI 當(dāng)時以 API 的標(biāo)準(zhǔn)定義了每個 plugin，把一個 plugin 直接當(dāng)成一個 API 來看，所以大家一起認識到了 Dialog2API 的重要性，才有了后續(xù)的故事。

Q：Plugins 之后又過了半年，12月底 GPTs 出來之后，大家才開始真的認真談?wù)?Agent。中間半年應(yīng)該是一個早期探索階段，當(dāng)時你做了什么工作？

Raphael Shu：那段時間的確行業(yè)很快，但落地很難，我們做了很多基礎(chǔ)建設(shè)。

最大的一件事，就是數(shù)據(jù)集。當(dāng)時不管是 public domain 還是 internal，根本不存在在一個對話里同時調(diào)用 API 的這種訓(xùn)練數(shù)據(jù)，SFT 數(shù)據(jù)。我們只能讓 vender 重新標(biāo)，當(dāng)時 vender 聽到我們這個需求之后直接懵了，根本不知道怎么開始標(biāo)這個數(shù)據(jù)，所以我們花了很久的時間一起做標(biāo)數(shù)據(jù)的 pipeline。

甚至在 AWS 內(nèi)部，我們自己還開發(fā)了一套標(biāo)數(shù)據(jù)的系統(tǒng)。總之那段時間，大模型的基建非常不成熟，更別提Agent，很多人還把 Agent 和 RAG 搞不清，必須做很多探索性的基礎(chǔ)建設(shè)，和很多認知拉齊。

2024年就發(fā)生了很多變化。

年初，Amazon 的大模型組織調(diào)整，模型改名 Nova，訓(xùn)練模型的團隊不再歸于 AWS。我依然留在 AWS 負責(zé) Bedrock Agent 的 Science 工作。

這樣也非常合理。因為 AWS 的核心還是云計算，Bedrock Agent 作為一個直接面向企業(yè)客戶的產(chǎn)品，目標(biāo)主要就是幫助企業(yè)落地 Agent。所以在一個云平臺上，Agent 可以選擇各種模型，而不是綁定單一模型，是更好的模式。

回到我自己的工作內(nèi)容。Bedrock Agent 的 engineering work 一開始就有，2024年開始有了 science 的部分。

Agent 有非常多的 feature 需要 science 的工作攻克。最基本地，需要把 API 實現(xiàn)成 function 再給到這個 Agent。那么，就需要給這個 Agent 寫 system prompt，還要選擇用什么模型去驅(qū)動 Agent。

在這種基礎(chǔ)功能之上，我們當(dāng)時認為 Agent 的發(fā)展有幾個關(guān)鍵，比如 memory，再比如 Tool use，都是難點。當(dāng)時我們做的很多 project，很多都是一半工程一半 science。比如幫助客戶用積累好的 fine-tuning 數(shù)據(jù)，fine-tuning 其他模型，應(yīng)用在 Agent 上面。

Q：今年春天我看到你和團隊推出了一個 Multi-Agent 框架——Amazon Bedrock Multi-Agent Collaboration。

Raphael Shu:是的，Bedrock Multi-Agent Collaboration 是一個多智能體框架。作為一個 on cloud 的產(chǎn)品，它主要面向企業(yè)客戶。

它最大的特點是“中心化 Agent 團隊”的模式。也就是靠一個 Supervisor 當(dāng)“總指揮”，挑合適的功能 Agent 組隊干活。

比如開發(fā)軟件，會有專門跑單元測試的、寫代碼的、做部署的，還有查語法的 Agent，那么 Supervisor 先把開發(fā)需求拆成小任務(wù)，分給對應(yīng)的 Agent 做，做完再看要不要追加新任務(wù)，本質(zhì)就是“協(xié)調(diào)者牽頭干活”的框架。

除了 Supervisor “管理全局”，這個框架里還有其他模塊。比如，Routing 解決“效率與延遲”，Payload referencing 降低“通信開銷”；自動化評估框架解決 Agent“如何衡量與改進”的問題。這些都是針對企業(yè)客戶痛點打磨出的功能。

Q：2023年就有一些 Agent 框架，我們2025年推出的框架有什么不同？

Raphael Shu：這個產(chǎn)品是2024年開始啟動開發(fā)的，2024年11月推出預(yù)覽版（preview），2025年3月正式上線。它最主要的區(qū)別，也是最核心的一點，就是它是一款云端托管服務(wù)（on cloud managed service），這和其他開源框架有本質(zhì)區(qū)別。

而且，我們很可能是北美地區(qū)第一個在托管服務(wù)或托管云上推出多 Agent 協(xié)作（multi-collaboration）產(chǎn)品的。

它最核心的優(yōu)勢是能穩(wěn)定地為企業(yè)應(yīng)用提供服務(wù)。一些開源產(chǎn)品的社區(qū)非常活躍，導(dǎo)致它的版本變化頻繁，甚至包的名字變化也很頻繁，基本幾個月就會有一次變動，這會讓你幾個月前寫的代碼，到了下個月就不再符合它的使用邏輯，之前推薦的用法后來可能會全部調(diào)整。

但企業(yè)客戶最關(guān)注的是：當(dāng)有實際業(yè)務(wù)需求時，能否找到一個能穩(wěn)定提供服務(wù)的產(chǎn)品。AWS 的主要客戶都是標(biāo)普500這樣的大公司，他們最擔(dān)心的就是上線產(chǎn)品后，用戶使用過程中頻繁出現(xiàn)錯誤。

有一個說法很有意思：大模型是歷史上“time to demo”最快的技術(shù)，但卻是“time to deployment”或“time to product”最難的技術(shù)。

對Multi-Agent的"執(zhí)念"

Q：幾個月前你開始創(chuàng)業(yè)。比較好奇你什么時候開始看好多智能體？

Raphael Shu:2023年的時候，我就很看重這個方向。因為當(dāng)時我們 data 的 quality 還是不錯的，所以 Agent 很快就有了能力提升，所以到了2023年年中，我有很強烈的感覺，認為 group intelligence 可能是未來發(fā)一個非常大的方向。

舉個例子，以前的 Machine Learning，logistic regression 是偏串行的，但神經(jīng)網(wǎng)絡(luò)其實是把非常多的邏輯回歸并行放在一起，才形成了一個更高的智能。

其實我們可以找到非常多的例子證明，一個串行的 model 要往后發(fā)展，一定要變成并行的模式。當(dāng)時我覺得 Agent 很可能也不會例外，單個 Agent 的發(fā)展固然重要，但再下一步，還是要做并行才更智能。

Q: 讓我有點疑惑的地方，是今年很多 Multi-Agent 推出，大家會強調(diào)效率提升，卻很少提到提升智能？

Raphael Shu:在 AWS 做 Agent，我自己接觸了很多企業(yè)客戶。很多客戶都會 Challenge，說你怎么證明 Multi-Agent 會比 Single-Agent 好。

我們當(dāng)時確實用 benchmark 證明了Multi-Agent的效果，公開的 technical report 也能查閱到。但是我覺得，最重要不是說 Multi-Agent 的 performance。而是說，這是一套更好的解決問題的思路。

舉個人類社會的例子。比如一個公司接到了非常大的項目，比之前的項目復(fù)雜很多倍，那么這家公司的老板不會去拼命訓(xùn)練某一個員工，讓他變得更加聰明完成所有的任務(wù)。

再舉一個例子，再好的分析師也很難持續(xù)地給一個公司精確估值。一個簡單粗暴的解決方法就是把這家公司的股票上市，讓上千上萬的人進行交易，也就確定了公司的估值。

所以，我覺得Single-Agent的能力應(yīng)該還是會繼續(xù)提升，但它對 intelligence 的貢獻，會在某一個時間點成為一個瓶頸。

Group intelligence，是把非常多的 Agent 放進一個社區(qū)里。這個語境里，我們要探索的一個問題就是，怎么有效利用多個 Agent 形成的 Scaling Law，這是現(xiàn)在整個業(yè)界都沒有探索清楚的一個問題。

Q：有效利用多個 Agent Scaling Law，具體指的是？

Raphael Shu :單純提升 Agent 的數(shù)量，也不一定指向智能的提升。如果沒有有效的方式，多智能體系統(tǒng)只會被指數(shù)增長的復(fù)雜度所吞噬，也可能有一個 Agent 被 Block之后，group 就失效了。很多諸如此類的情況會發(fā)生。

其實人類社會也有這樣的現(xiàn)象。比如你開一家公司，突然來了一個很復(fù)雜的 project，你拼命往公司里招 engineer 不一定會有好的效果。為了讓員工更好地合作，你還要去招一個 manager，可能還要給大家買好用的 meeting software，組織大家一起用 Github。

所以，開放世界中的Multi-Agent 系統(tǒng)也需要正確的交互方式，正確的套件才能進行有效的合作。

Q：從在AWS發(fā)布多智能體框架到現(xiàn)在，你有沒有看到一些更有意思，或者更先進的方案？

Raphael Shu：現(xiàn)在新出的方案非常多。比如上半年很火的 Manus，其實在它之前微軟推出過一款產(chǎn)品，兩者模式非常相似，只是微軟的產(chǎn)品沒有火起來。這類方案的核心邏輯是讓一個智能體帶領(lǐng)多個具備不同專業(yè)能力的智能體，通過簡單協(xié)作來完成用戶需求。

我認為這是一種很有意思的模式，而且解決了實際問題。

不同智能體的特性存在差異。比如微軟的模式中，調(diào)用瀏覽器的智能體屬于“慢智能體”（slow Agent），而與用戶對話的會話智能體屬于“快智能體”（fast Agent）。很明顯，我們不能把這兩類智能體混在一起使用，更不能讓“慢智能體”阻礙“快智能體”的響應(yīng)速度，所以將它們拆分為多個子智能體，就是一個很自然的解決方案，這類方案現(xiàn)在很常見。

不過我想強調(diào)，Multi-Agent system 不是這兩年才出現(xiàn)的概念。

如果追溯源頭，早在20世紀80年代或90年代，學(xué)術(shù)界就已經(jīng)對它有了明確定義，九幾年的時候，還有一本叫「Intelligent Agents」的教科書，這本書是大模型出現(xiàn)前研究多智能體系統(tǒng)的必讀資料。

書中對多智能體的定義分為四點，其中兩點和單個智能體的定義一致，也就是“感知與行動（perceive and act）”在此基礎(chǔ)上，多智能體系統(tǒng)額外增加了“社會性（social）”和“自主性（autonomy）”兩個核心特征。

所以在學(xué)術(shù)界看來，真正的多智能體系統(tǒng)中，每個智能體是否具備 autonomy，也就是能否主動采取行動，是一個非常關(guān)鍵的問題。但現(xiàn)在很多所謂的 Multi-Agent workflow，通過“圖/（graph）”來設(shè)計、每個節(jié)點對應(yīng)一個智能體的模式，其實并沒有賦予每個智能體真正的自主性。

當(dāng)然這并不影響它們的實用性，用起來還是很方便的。不過我認為，未來行業(yè)的探索方向應(yīng)該回歸到“分布式自主、分工協(xié)作”的多智能體系統(tǒng)范式上。

也就是，把自主權(quán)分配給不同的智能體，觀察它們在不被強制設(shè)定工作流的情況下，能否自發(fā)探索出群體協(xié)作解決問題的方法，以及能否在這個過程中提升協(xié)同能力。

Q：你怎么看類似多智能體的 workflow？按照嚴格定義，你認為目前出現(xiàn)具備高度自主性的多智能體了嗎？

Raphael Shu：現(xiàn)在的 Multi-Agent workflow，在企業(yè)應(yīng)用中確實用得非常廣泛，無論是 To C 產(chǎn)品、To B 產(chǎn)品，還是面向開發(fā)者的產(chǎn)品，幾乎所有企業(yè)應(yīng)用里都能看到它的身影。事實上，Bedrock 也推出了一款專門做這類工作流的產(chǎn)品，名叫 Bedrock Flow。

至于高度自主性的系統(tǒng)，目前確實沒有。不過說實話，以現(xiàn)有技術(shù)，要實現(xiàn)這樣的產(chǎn)品并不難，比如用 Cursor 或許很快就能開發(fā)出來。問題在于，現(xiàn)在企業(yè)客戶很難使用它。如果真的做出每個智能體都有獨立行為模式，智能體之間還可能存在競爭關(guān)系，在企業(yè)實際應(yīng)用中會引發(fā)很多混亂。

現(xiàn)在企業(yè)客戶對現(xiàn)有的多智能體系統(tǒng)已經(jīng)有不少抱怨，主要集中在三個問題上：

第一是 Token 消耗過大。單個智能體的 Token 消耗已經(jīng)不少，而智能體之間的通信還要額外消耗 Token，即便大型客戶能勉強接受，成本壓力也很大。

第二是延遲。智能體之間需要依次交互——一個智能體與另一個智能體溝通，后者完成任務(wù)后再反饋，這個過程比直接用單個智能體處理多了兩步，轉(zhuǎn)化成時間延遲就是幾秒鐘。對于對話類 Chat 產(chǎn)品來說，讓用戶等待十秒，用戶早就把對話框關(guān)了，協(xié)作也就失去了意義。

第三是不可控性增強。所有大模型都存在隨機性，增加智能體數(shù)量后，這種不可控性會被無限放大。比如同一個用戶每天提出相同需求，今天智能體給出的結(jié)果可能是對的，明天可能就錯了，后天又可能對了。這種波動企業(yè)客戶完全無法容忍，他們不怕系統(tǒng)犯錯，怕的是結(jié)果不穩(wěn)定。這些都是我們需要解決的問題。

更自主的Agent，和群體智能

Q：你的創(chuàng)業(yè)公司，Acenta 想解決什么問題？

Raphael Shu：現(xiàn)在我們的公司叫 Acenta。目前團隊包括我在內(nèi)有七個成員，團隊絕大部分人現(xiàn)在在做 OpenAgents 開源框架。這個開源框架的核心價值是搭建一個智能體網(wǎng)絡(luò)，或者說是社區(qū)，和其他已有的 Multi-Agent 框架相比，它最突出的特點，就是剛剛說過的，Agent 的完全自主性和開放協(xié)作，算是一個比較有新意的開源項目。

用戶進入這個社區(qū)后，不是開發(fā) Agent，而是可以“招聘 Agent（Hire Agent）”，也就是讓 Agent 加入進來，成為你的同事。

我舉個例子，如果你讓 Agent 幫你處理具體事務(wù)，比如"一起做網(wǎng)站的 SEO"，它不會一次性完成，而是會在長期協(xié)作中持續(xù)跟進。也就是，每天幫你檢查 SEO 問題并提醒，如果你需要在文檔里補充其他數(shù)據(jù)，它也會根據(jù)需求完善。

OpenAgents 里的 Agent，和其他 Agent 最大的區(qū)別是，不會把 Agent 的生命周期和任務(wù)的生命周期綁定。

比如讓 Cursor 的 Agent 開發(fā)軟件，你輸入指令后 Agent 啟動，寫完代碼 Agent 就下線、不存在了。但在 OpenAgents 社區(qū)里，Agent 會一直在線，即便你和它聊了三個小時后下線，這些 Agent 依然處于在線狀態(tài)。

它們發(fā)現(xiàn)你不在后，會主動復(fù)盤當(dāng)天的協(xié)作內(nèi)容，找出可以優(yōu)化的地方，甚至自己開會討論改進方案，相當(dāng)于有一個自我學(xué)習(xí)（Self-Learning）的過程。

當(dāng)然，之后我們公司還計劃推出其他產(chǎn)品，但目前最主要的工作就是推進 OpenAgents 這個開源項目。

Q：為什么想到要做這樣一個框架？

Raphael Shu：其實相比單純做框架，我更想打造一個“人類與 Agent 協(xié)同（Mix Human Agent）”的社區(qū)，一個真正的社區(qū)，而不只是一個 Multi-Agent System。因為系統(tǒng)只是把 Agent 當(dāng)作工具，而我想做的是一個AI Native 的 Agent 社區(qū)。

在這里，Agent 沒有“生命周期結(jié)束”的概念，能和人長期協(xié)同合作，也能在合作中了解其他 Agent，和人類以及 Agent 同類一起反思協(xié)作問題，實現(xiàn)自我成長。

這個想法其實醞釀了很久。我在 AWS 剛做 Multi-Agent 時，就想做“開放協(xié)作（Open Collaboration）”模式，讓所有參與的 Agent 都具備自主性。

這件事在大廠會比較難推進，但我一直對這個方向很感興趣。

我在 AWS 時還牽頭辦過 Multi-Agent 相關(guān)的研討會，叫 multiagents.org。當(dāng)時我就在會上分享過 Open Collaboration 的理念和實踐方法。

去年我和一個來自賓大的博士生實習(xí)生，一起做了一個叫“Round Table”的項目，專門研究 Open Collaboration 的核心概念。在這種模式下，每個 Agent 對其他 Agent 來說都是“黑盒”——看不到內(nèi)部狀態(tài)，甚至 Agent 不確定對方是不是“合作方”，我們要觀察這種情況下 Agent 的協(xié)作模式。

我們做了很多實驗，包括經(jīng)濟學(xué)相關(guān)的實驗，比如觀察 Agent 在協(xié)作中是每次都做理性決策，還是像人一樣會做感性決策；不同模型的 Agent 是否存在“價值觀不一致”等等問題。

這些和人類社會很像，因為價值觀不合的人很難一起做事。

比如在國內(nèi)，如果有人說“用剛買的西瓜換你的iPhone”，你會覺得對方在開玩笑或想騙手機；但在日本，你可能要認真考慮一下了，因為日本的西瓜價格真的可能比iPhone還貴，這就是價值觀的差異。

在 Agent 的世界里，不同大模型因訓(xùn)練方式不同，也可能存在潛在的價值觀差異，這種差異平時不易察覺，但會影響協(xié)作。我們的項目就是研究這類問題。

更具體地說，現(xiàn)階段我們會聚焦“社區(qū)能產(chǎn)生怎樣的智能、能達成什么目標(biāo)、能創(chuàng)造什么價值”。

Q：關(guān)于“價值”，現(xiàn)在有沒有更具體的例子？

Raphael Shu：這些價值更多和社區(qū)相關(guān)。

比如大家平時都有文件轉(zhuǎn)換的需求：想把 FLAC 格式的音樂轉(zhuǎn)成 MP3，把一堆圖片轉(zhuǎn)成 PDF 再壓縮，這類需求很常見。

現(xiàn)在大多數(shù)人的解決方式很麻煩。比如要把 PNG 轉(zhuǎn)為 PDF，就去 Google 搜“PNG to PDF”，點進搜索結(jié)果里的網(wǎng)站，看15秒廣告，上傳文件等待轉(zhuǎn)換再下載，過程很繁瑣。

但這類問題其實可以定義成社區(qū)問題：每類文件轉(zhuǎn)換需求都能對應(yīng)一個 Agent，比如 FLAC 轉(zhuǎn) MP3 的 Agent、PDF 壓縮的 Agent，社區(qū)里可以聚集大量這類 Agent。

在這里，用戶只需把文件傳到社區(qū)，發(fā)一條通知說“我要把圖片轉(zhuǎn)成 PDF，再壓縮 PDF”，只要社區(qū)能正常運作，Agent 之間會快速討論，就能確定由哪個 Agent 負責(zé)轉(zhuǎn)格式、哪個負責(zé)壓縮，然后立刻執(zhí)行。用戶可能500毫秒就能拿到結(jié)果。

Q：我們會用哪些能力支持這樣的社區(qū)？

Raphael Shu：主要需要兩大核心能力支撐：

第一個，開發(fā)“協(xié)作 Agent”，加速協(xié)作過程，把協(xié)作成本降到毫秒級。

第二個，我們也要建立社區(qū)驅(qū)動機制。比如為什么有人愿意給社區(qū)貢獻 Agent？如果貢獻者還要自己承擔(dān)計算成本，社區(qū)肯定活躍不起來，所以需要社區(qū)經(jīng)濟來激勵開發(fā)者共享 Agent。

但這還不夠，如果很多用戶需要“PDF 轉(zhuǎn) Markdown”的 Agent，卻沒人能開發(fā)，就需要加大激勵力度——比如設(shè)置懸賞金，從100美金漲到5000美金，直到有對應(yīng)的 Agent 被開發(fā)出來、滿足需求為止。

長期來看，我們的目標(biāo)是做出一套成熟的、能驅(qū)動多 Agent 高速協(xié)作的社區(qū)解決方案，在此基礎(chǔ)上可以開發(fā)很多應(yīng)用，也能幫企業(yè)完成各類企業(yè)級需求。

Q：聽下來讓這些 Agent 彼此快速協(xié)作，是你們的核心技術(shù)。

Raphael Shu：對，這是我們的核心。而且不僅要能協(xié)作，還要會觀察社區(qū)情況：比如你裝了什么插件，再比如 Agent 平時的協(xié)作模式，是靠投票協(xié)作，還是像 Bedrock 那樣有一個管控所有 Agent 的 Supervisor。然后，我們會根據(jù)不同的協(xié)作模式和應(yīng)用場景，用不同方法加速協(xié)作。最終目標(biāo)是把協(xié)作成本降到毫秒級，比如250毫秒，讓用戶感覺不到協(xié)作過程的存在。

核心技術(shù)還是“協(xié)作 Agent”，也就是針對不同協(xié)作模式和社區(qū)，加速并優(yōu)化 Agent 的協(xié)作過程，讓協(xié)作更快，任務(wù)成功率更高。

Q：似乎和你之前在亞馬遜做的框架有相似之處。

Raphael Shu：有相似的地方。但亞馬遜的框架是解決特定場景、特定協(xié)作模式下的加速問題，而且沒有做到毫秒級加速。我對 OpenAgents 的期望是，把協(xié)作過程真正加速到毫秒級，而不是讓 Agent 慢慢“討論”，半天沒有進展。

Q：如果核心是 Agent 之間的交流，會和A2A（Agent to Agent）協(xié)議有些類似嗎？

Raphael Shu：不是。OpenAgents 是幫用戶搭建 Agent 社區(qū)的開源項目，本身不是協(xié)議，而且它兼容所有協(xié)議，理論上會支持幾乎所有協(xié)議。

不同協(xié)議在 OpenAgents 里就是一個插件，比如想讓 Agent 之間通信，你可以選擇用 A2A 協(xié)議，也可以選擇用 WebSocket，這些都能自己選，我們也會提供一個默認選項。

Q：解決效率和延遲問題，核心還是用之前提到的 Routine 方案嗎？

Raphael Shu：不是，要滿足我們現(xiàn)在的期待，需要一整套方案。我們甚至可能開發(fā)一個“模型適配器（Model Adapter）”，把 Agent 協(xié)作的意圖（Intend）直接翻譯成簡單的二進制代碼。

因為不管是多 Agent 協(xié)作，還是人類協(xié)作，都有很多常見意圖，比如“同意”、“不同意”、“發(fā)起投票”，這些完全不需要用自然語言寫長郵件，甚至不用文字表述。所以我們的適配器會把這些意圖轉(zhuǎn)成幾比特的代碼，發(fā)給其他Agent，這個過程很可能就是毫秒級的，能大幅降低延遲。

其實單個 Agent 的推理速度不慢，但多 Agent 協(xié)作需要頻繁交互，就算一次交互250毫秒，疊加十次就是2.5秒，延遲還是太高。所以需要把整體延遲降到毫秒級，甚至強迫 Agent 用簡約協(xié)議進行非自然語言通信——這也是 OpenAgents 加速協(xié)作的重要方向，不過具體是否采用會根據(jù)場景判斷。

Q：現(xiàn)在有沒有看重的垂類場景？

Raphael Shu：有。目前我把場景分成三類：

1. 協(xié)同工作（Cowork）：Agent 和人一起工作，比如之前說的一起寫文檔；

2. 協(xié)同游戲（Co-game）：我們之后會發(fā)布一個基準(zhǔn)測試（Benchmark），是一款讓 Agent 玩的開放世界角色扮演游戲，現(xiàn)在團隊里有成員在和合作方一起開發(fā)這款游戲；

3. 開放協(xié)作（Open Collaboration）：比如之前說的文件轉(zhuǎn)換，這類場景不僅有協(xié)作，還可能有競爭，競爭甚至?xí)嘁恍?/p>

它強調(diào)的不是“拉來幾個 Agent 完成任務(wù)后就消失”，而是“長期陪伴協(xié)作”：比如 Agent 也可以幫你寫文章，不會寫完就消失，可能覺得某個點需要討論，會主動開一個溝通渠道，討論后發(fā)現(xiàn)有問題需要你確認，就會提醒你。你確認后，它們再繼續(xù)寫。文章寫完幾天，Agent 如果發(fā)現(xiàn)之前寫錯了，還會回去修改，改完后告訴你。

Q：會不會出現(xiàn) Agent 都在平臺上，但沒什么互動的情況？

Raphael Shu：有可能，但這不一定是壞事。

首先我們還是會強調(diào)“Agent 經(jīng)濟”，如果 Agent 覺得不跟其他 Agent 互動是最佳合作方式，那也沒問題。

比如有的 Agent 可能把自己定位成“后臺觀察者”，不說話，只看著其他 Agent 做事，一旦發(fā)現(xiàn)某個 Agent 的行為“越界”，比如出現(xiàn)嚴重錯誤，它就有一票否決權(quán)，直接阻止協(xié)作，提醒“你們的方向錯了，應(yīng)該停止”。這種模式也是可行的。

總之我覺得只要 Agent 是比較自主的，任何行為都是有價值的。畢竟我們的目標(biāo)就是觀察它們能否自發(fā)探索出群體協(xié)作解決問題的方法。

通過這樣的方式，更加深入地探索 group intelligence，探索實現(xiàn) group intelligence 更好的途徑，是我這次創(chuàng)業(yè)最大的目的。