亚洲av激情综合欧美另类,亚洲一区二区免费av,国产精品国产三级国产在线,国产99久久久久,国产成a人无v码亚洲福利

作者 | 萬有引力

出品 | CSDN（ID：CSDNnews）

當(dāng) Manus 以其驚艷的自主任務(wù)執(zhí)行能力點燃 AI Agent 領(lǐng)域的熱潮時，其“一碼難求”的現(xiàn)狀也讓眾多開發(fā)者望而卻步。幾乎在同時，一個名為OpenManus的開源項目以“火箭般”的速度問世，不僅成功復(fù)刻了核心功能，更以完全開放的姿態(tài)，在短短不到一個月的時間內(nèi)于 GitHub 吸引了超過四萬 Star 數(shù)的關(guān)注（截止本文發(fā)布，項目 Star 數(shù)已經(jīng)達(dá)到 42.2k）。

OpenManus 項目 Star 數(shù)

這一現(xiàn)象背后，站著一群充滿活力的 00 后程序員。他們利用下班后的短短三小時，憑借對技術(shù)的熱愛與開源精神，迅速將一個想法變成了現(xiàn)實。這種驚人的執(zhí)行力與純粹的“Just for Fun”動機，引發(fā)了業(yè)界的廣泛討論：這一代年輕開發(fā)者是如何學(xué)習(xí)、成長并擁抱前沿技術(shù)的？他們與 AI 工具的深度協(xié)作達(dá)到了何種程度？支撐他們快速行動的技術(shù)積累和開源理念又是什么？OpenManus 的誕生僅僅是復(fù)刻嗎？其技術(shù)內(nèi)核與未來方向又將如何演進(jìn)？

OpenManus 項目

項目鏈接：https://gitcode.com/OpenManus/OpenManus, https://github.com/mannaandpoem/OpenManus

為了深入探尋這些問題的答案，CSDN 特別策劃的《萬有引力》欄目邀請到了 OpenManus 項目一作、華東師范大學(xué)在讀研究生、MetaGPT 開源核心貢獻(xiàn)者梁新兵，以及 DeepWisdom 算法研究員、OpenManus 核心作者、阿里全球數(shù)賽 AI 賽道獲獎?wù)?strong>向勁宇，與欄目主理人 CSDN &《新程序員》執(zhí)行總編唐小引一同，深度解碼 OpenManus 的幕后故事，分享 00 后程序員的真實代碼世界、開源實踐與 Agent 探索之旅。

觀點搶先看

梁新兵：

我入行 AI Agent 也是陰差陽錯，寫第一個 Agent 應(yīng)用時很多代碼還是 AI 幫我生成的。
看新代碼庫？直接用工具把代碼扒下來，扔給大模型讓它畫架構(gòu)圖！
OpenManus 的核心就是 Tool 和 Prompt，我想用幾千行代碼把 Agent 核心邏輯展示給用戶。
MCP 就是 AI 界的 Type-C 接口，目標(biāo)是“一次編寫，處處運行”。
多 Agent 協(xié)調(diào)太難了，我們暫時把它優(yōu)先級降低了。

向勁宇：

感覺繼續(xù)學(xué)物理，自己沒有找到合適的方向，加上 ChatGPT 沖擊，就果斷轉(zhuǎn)了 AI。
Manus 一出我就知道能火，半夜兩三點發(fā)消息給新兵：明天下班“爆肝”復(fù)刻一個！
AI 取代程序員？沒關(guān)系！未來需要懂研究、產(chǎn)品、代碼的混合人才。
OpenManus 開源不是為了技術(shù)平權(quán)那么高尚，主要是科普+推廣簡潔實現(xiàn)。
框架優(yōu)先保證簡潔易懂，Token 消耗優(yōu)化可以后續(xù)再說。

從社群黑客松到 Agent，00 后的 AI 啟蒙與轉(zhuǎn)向

唐小引：歡迎新兵和勁宇！兩位作為 OpenManus 的核心主創(chuàng)，都是非常年輕的 00 后開發(fā)者。請先做個自我介紹，聊聊你們最初是如何走上編程和 AI Agent 這條路的？

梁新兵：我叫梁新兵，00 年出生，現(xiàn)在是華東師范大學(xué)研二在讀。本科是在廣州大學(xué)讀的網(wǎng)絡(luò)工程專業(yè)，算是科班出身。

說實話，我進(jìn)入 AI Agent 這個領(lǐng)域有點陰差陽錯。本科大三、大四的時候比較迷茫，思考是繼續(xù)讀研還是直接工作。當(dāng)時決定讀研，但感覺自己手頭上沒什么項目經(jīng)歷或者說資本，就想著參加一些比賽拿點獎，或許對考研復(fù)試有幫助。正好接觸到一個 CV（計算機視覺）相關(guān)的 AI 比賽，去參加并拿了個國家三等獎。那時覺得，嗯，以后可能就深耕 CV 領(lǐng)域了。

沒想到，考研那年（2022年）12 月份 ChatGPT 橫空出世，我跟它“Battle”了好幾天——當(dāng)時它的語料庫還沒那么完善，我就一直嘗試“說服”它——這個過程讓我覺得 NLP 領(lǐng)域好像非常有意思，大模型很有前景。考完研后就在 CV 和 NLP（自然語言處理）之間做選擇，最終覺得 ChatGPT 代表的 NLP 這條路更有潛力。

后來加入了 MetaGPT 的社群，看到他們發(fā)起了像狼人殺、Minecraft（我的世界）、斯坦福小鎮(zhèn)等游戲的 Agent 應(yīng)用的黑客松活動，我就報名參加了。說實話，當(dāng)時我的代碼能力還不是很強，寫那個狼人殺游戲時，很多代碼還是讓 AI 幫我生成的。但正是這次經(jīng)歷，讓我真正走上了 Agent 的道路。

向勁宇：我是向勁宇，01 年的，剛從西南交通大學(xué)應(yīng)用物理系本科畢業(yè)半年多，現(xiàn)在在 DeepWisdom 擔(dān)任 Agent 方向的算法研究員。

我之前學(xué)物理，后來感覺物理這條路可能大家能做的方向不太多了，前輩們都走到了瓶頸期，加上 22 年底 ChatGPT 那波沖擊力很強，就開始接觸大模型相關(guān)的東西。到 23 年的時候，身邊同學(xué)主要都在準(zhǔn)備考研。當(dāng)時打算轉(zhuǎn)向數(shù)據(jù)科學(xué)領(lǐng)域，但發(fā)現(xiàn)技術(shù)壁壘可能不是特別高同時也很卷，所以就想著轉(zhuǎn)向 AI。自己學(xué)了一些基礎(chǔ)知識，也和新兵的經(jīng)歷類似，參加了 MetaGPT 那個黑客松活動，我當(dāng)時參與的是 Minecraft 的 Agent 項目。那次經(jīng)歷算是把我正式帶上了 Agent 這條路。黑客松結(jié)束之后，就大概知道 Agent 是怎么一回事了。

后來，我基本上就是自己立一些項目或者參加一些比賽，也拿到了一些第一名。再后來就是參加了 2024 年阿里那個全球數(shù)學(xué)競賽，他們新開設(shè)了 AI 賽道，我拿了第二名。之后我現(xiàn)在公司的老板就找到了我，問我有沒有明確的去向，可以考慮去他們那邊。加入 DeepWisdom 之后，老板給了一些論文的 idea，后來也發(fā)表了一些論文（像 ICLR 2025 Oral 的 AFlow，還有 SPO），工作重心就更偏向 Research 一些了。

唐小引：勁宇你從物理轉(zhuǎn) AI，這個跨度不小。中間難道不會覺得從一條有難度的賽道進(jìn)入另一條更有難度的賽道，挑戰(zhàn)很大嗎？比如編程語言的切換？

向勁宇：挑戰(zhàn)肯定是有的。轉(zhuǎn)過來之前，我其實沒怎么系統(tǒng)學(xué)過 Python，之前主要寫 Matlab，因為在學(xué)校打數(shù)學(xué)建模比賽用得多。但編程語言是有一點相通之處的。再加上后面大模型的能力越來越強，很多不懂的東西可以隨時問到，所以我覺得學(xué)習(xí)速度和適應(yīng)曲線還是挺快的，沒有想象中那么困難。

唐小引：聽下來你們倆的共性都是因為 MetaGPT 的黑客松活動，對 Agent 有了直觀深刻的認(rèn)識，并由此確定了自己的研究方向。這似乎也驗證了“多參加黑客松”這條開發(fā)者成長路徑的普適性。你們是什么時候開始真正接觸開源社區(qū)的？在社區(qū)里日常會做些什么？

梁新兵：我這邊確實也是因為 MetaGPT 舉辦的這些活動才走向開源之路的。我們參加黑客松產(chǎn)出的代碼，比如我參與的狼人殺項目，最終是合并到了 MetaGPT 這個開源倉庫里的。之后我也持續(xù)在 MetaGPT 里面貢獻(xiàn)了很多代碼，都是以開源的方式提交 PR 然后合并進(jìn)去。所以 MetaGPT 是我貢獻(xiàn)的第一個開源項目，能直接參與到一個高 Star 且與自己主業(yè)方向相關(guān)的項目，感覺非常好。

向勁宇：我其實也差不多。不過我當(dāng)時在 Minecraft 項目里沒有寫太多核心代碼，因為剛接觸不久，主要是幫他們做一些數(shù)據(jù)分析相關(guān)的工作，比如處理游戲過程中產(chǎn)生的數(shù)據(jù)。但是整個項目的主流程我全部跟下來了，所以當(dāng)時就把 Agent 的那套運作模式給搞懂了。

梁新兵：說實話，我有個還蠻后悔的事情。勁宇和另一位同學(xué)（他參加了斯坦福小鎮(zhèn)那個黑客松項目）一起參加了阿里的數(shù)學(xué)競賽，拿了第二、三名。當(dāng)時其實我也有看到這個比賽信息，但我一看，介紹里好像只提了初賽，沒說有復(fù)賽，當(dāng)時就沒太看清楚具體要做什么，也就沒有去參與。結(jié)果他們拿獎了，還是有點遺憾。

唐小引：機會總是留給有準(zhǔn)備和積極行動的人啊。你們倆一個科班出身，一個非科班轉(zhuǎn)行，日常一起搭檔做項目，覺得這兩種背景在合作中有什么具體的不同或者互補之處嗎？

向勁宇：我覺得新兵作為科班生，代碼能力會更強一些。我經(jīng)常遇到代碼上的問題需要請教他。我自己的話，可能因為是跨學(xué)科背景，思維方式會不太一樣，更容易產(chǎn)生一些不同的 Idea。另外在項目宣傳、產(chǎn)品化思考方面我也可以幫上忙。我自己還是個騰訊音樂人，所以覺得這種跨學(xué)科的經(jīng)歷還是帶來了一些獨特的優(yōu)勢吧。

梁新兵：我感覺勁宇本身能力就很強，不關(guān)乎學(xué)科。而且我發(fā)現(xiàn)，現(xiàn)在這個時代，有大模型的加持，就算是不同領(lǐng)域背景的人來做 AI 或者計算機相關(guān)的工作，門檻好像確實越來越低了。因為我們可以很方便地通過大模型去了解如何寫代碼、理解代碼邏輯。所以從這個角度來看，科班與非科班之間的差距或者說區(qū)別，可能沒有以前那么顯著了。

唐小引：聽起來像是勁宇貢獻(xiàn)點子和想法，新兵負(fù)責(zé)技術(shù)實現(xiàn)？

向勁宇：差不多是這樣，沒錯。

00 后的 AI Coding 工作流

唐小引：你們都是在 ChatGPT 爆火之后深度接觸大模型的，現(xiàn)在日常工作中肯定也離不開 AI Coding 工具了。能更具體地講講你們是如何利用 AI 工具來學(xué)習(xí)新技術(shù)、提升編程技能的嗎？常用的工具有哪些？這些工具給你們的工作流帶來了哪些實質(zhì)性的變化？

梁新兵：是的，日常使用頻率非常非常高。舉幾個例子：當(dāng)我需要了解一個新的領(lǐng)域或者一篇新論文時，想快速掌握核心內(nèi)容，我會讓 Kimi 幫我總結(jié)論文的要點，遇到不懂的概念就直接問它，讓它用通俗易懂的方式給我解釋。又或者說，我想快速理解一個陌生的代碼倉庫，可能會用一些像 Repo Mix 這樣的工具，它可以一鍵把某個模塊甚至整個倉庫的代碼結(jié)構(gòu)和內(nèi)容提取出來，形成一個長文本。然后我直接把這個文本粘貼發(fā)給大模型（比如 Qwen、Claude、Grok 等），讓它幫我講解代碼含義、實現(xiàn)了什么功能，甚至讓它基于代碼生成項目的架構(gòu)設(shè)計圖。

一旦有了架構(gòu)圖，我一看就能大致明白各個模塊是如何運作的，項目的核心原理是什么。如果把整個倉庫的代碼都給大模型分析并生成架構(gòu)圖，那就能非常清晰地了解整個項目的運作方式。我在實現(xiàn) OpenManus 的時候就大量運用了這些技巧，去看別人相關(guān)的開源倉庫是怎么完成的，通過對比學(xué)習(xí)獲得啟發(fā)，然后形成自己的思考，再動手寫新的東西。

唐小引：能再舉一個更具體的場景例子嗎？比如你最近研究 DeepResearch 這個概念的時候，整個工作流是怎樣的？

梁新兵：OpenAI 發(fā)布了 DeepResearch 功能之后，它非?；?，網(wǎng)上也出現(xiàn)了一些開源的復(fù)刻項目。我當(dāng)時就在想，這個 DeepResearch 到底是怎么實現(xiàn)的？看起來效果很厲害，現(xiàn)在很多公司也想做類似的功能。我看到 GitHub 上有相關(guān)的開源項目，但是點進(jìn)去一看，代碼量很大，我不可能也沒那么多時間去逐行閱讀理解。但我又想在 OpenManus 里面嘗試添加類似的功能。

于是，我就找到了幾個復(fù)現(xiàn) DeepResearch 的代碼倉庫，把它們的核心代碼復(fù)制下來（可能是一個模塊的代碼），形成幾段比較長的文本。然后我把這些文本分別扔給大模型，讓它為每個倉庫生成一個架構(gòu)圖。這樣我就得到了三個不同的設(shè)計思路。接下來，我可能會讓大模型幫我比較這三個設(shè)計圖，或者我自己看完之后有了新的想法。然后我會把我頭腦中想要實現(xiàn)的概念用文字描述出來，告訴大模型：“這是我想要實現(xiàn)的功能描述，下面是我調(diào)研得到的三個相關(guān)倉庫的設(shè)計圖?！卑堰@些信息整合在一起給大模型，讓它幫我設(shè)計一個新的、融入了我自己想法（insight）的架構(gòu)圖。有了這個新的架構(gòu)設(shè)計圖之后，我再讓 AI 編程工具（比如 Cursor）幫我生成適配 OpenManus 框架的新代碼文件。這樣就完成了一個從調(diào)研、理解、構(gòu)思到初步實現(xiàn)的過程。

唐小引：所以你的工具鏈主要是具體的 LLM 用于理解和設(shè)計，再加上 AI IDE 用于代碼生成和集成？

梁新兵：是的，基本是這樣。調(diào)研分析、理解概念階段可能直接用模型的網(wǎng)頁版或者 API。到了具體編碼、需要與現(xiàn)有項目框架結(jié)合的時候，用 Cursor 這樣的 IDE 會更方便，因為它能更好地理解項目上下文，生成更適配的代碼。

唐小引：OpenManus 有多少代碼是 AI 寫的？

梁新兵：現(xiàn)在的話，應(yīng)該很多了。不僅是我自己寫的時候會用，我看社區(qū)里很多人提交的 PR（Pull Request），感覺他們也大量使用了 Cursor 或者其他大模型來輔助編寫代碼，然后提交上來。當(dāng)然，AI 生成的代碼質(zhì)量參差不齊，有些很好，有些可能就需要我花時間去仔細(xì) review 和修改。

唐小引：那你們聽到現(xiàn)在很多“AI 取代程序員”的言論，結(jié)合自己的實際使用，有什么感想？

向勁宇：我覺得沒有關(guān)系吧，甚至感到?jīng)]什么聯(lián)系。因為程序員自己也在用 AI。我覺得只是說，未來不同行業(yè)或者不同工種之間的壁壘會更小。未來需要的是那種混合能力，比如我既有研究能力，又有產(chǎn)品思維，又能寫代碼，可能會更受歡迎一些。

梁新兵：對于當(dāng)前這一兩年，我感覺 AI 還是我們程序員（或者說寫代碼的人）一個非常大的助理。它真的能幫我們提高工作效率，減輕很多編寫重復(fù)、模板化代碼的痛苦。它現(xiàn)在主要還是我們強大的幫手。

唐小引：但使用 AI 寫代碼也會遇到問題吧？比如有評論說“AI 寫代碼很快，但改代碼很痛苦”，你們有同感嗎？如何處理 AI 生成代碼的質(zhì)量和維護問題？

向勁宇：對，這個確實是存在的。如果你對代碼完全不懂，那 AI 寫完之后你肯定不知道哪里寫得對不對，有沒有隱藏的問題。但是，如果說你至少對整體的語法、邏輯都懂的話，當(dāng) AI 生成代碼后，你能一眼看出來它寫的是否符合你的需求，哪里可能存在問題。然后你可以基于你的判斷，再跟 AI 進(jìn)行溝通，讓它修改或者你自己動手修改。這種人機協(xié)作的模式會更好一些。

梁新兵：是的，AI 生成的代碼，特別是涉及復(fù)雜業(yè)務(wù)邏輯或者底層實現(xiàn)的部分，還是非常需要人類開發(fā)者去進(jìn)行仔細(xì)的審查（review）和必要的修改。不能完全依賴 AI，把它當(dāng)成一個加速器和輔助工具是比較合適的定位。

OpenManus 的誕生與“過山車”體驗

唐小引：我們來重點聊聊 OpenManus 這個項目本身。它是你們自需而來，利用業(yè)余時間“爆肝”搞出來的，特點是能快速把一個想法實現(xiàn)出來。它在開源社區(qū)獲得了巨大的反響，增速非常迅猛。能分享一下從 0 到 40k+ Star 的感受，以及你們認(rèn)為它為什么能這么快、這么火嗎？這其中有什么心路歷程的變化？

向勁宇：我是從一開始就猜到這個東西（復(fù)刻 Manus 并開源）肯定會火的。當(dāng)時 Manus 剛發(fā)了兩個小時，大概是晚上 9 點到 10 點的樣子，我就看到我的朋友圈里很多投資人還有一些自媒體的朋友都在轉(zhuǎn)發(fā)這個。包括各種技術(shù)社群里面，反響也比較熱烈。

我當(dāng)時的判斷是，大家之所以會如此震驚，主要是因為他們第一次如此直觀地看到 AI 在他們面前使用瀏覽器或者操作電腦。但實際上，實現(xiàn)這個事情本身，在學(xué)術(shù)圈或者說在 Agent 這個技術(shù)圈內(nèi)，并不是那么遙不可及的難事。

那我就覺得，如果我們弄一個開源的版本出來，可能一方面是能給大家科普一下這個事情本身的實現(xiàn)難度到底是多少；另一方面，也能給那些不太了解 Agent 的開發(fā)者展示一下具體要怎么實現(xiàn)，它的原理是什么。正好，之前新兵他在下班的業(yè)余時間就有在寫一個叫做 AgentHub 的項目，我覺得正好可以利用他那個項目的代碼基礎(chǔ)來快速搭建 OpenManus。

這樣做，也相當(dāng)于把我們之前在 AgentHub 里設(shè)計的一些簡潔的理念順勢宣傳出去了。所以，當(dāng)時我臨睡前（大概是凌晨兩三點的時候）就給新兵發(fā)了消息，我說明天（等我們都下班了）可以搞個 OpenManus 出來，我覺得肯定可以火。

梁新兵：說實話，對于我來說，是完全沒有想過它會爆火的。因為確實是勁宇找到我，叫我來一起弄這個項目的。當(dāng)時接到這個提議的時候，我也就覺得，好像可以弄一下試試看吧。我對它后續(xù)會不會火、能火到什么程度，是沒有任何概念的，也從未想過它會如此爆火。

當(dāng)時可能就花了一點時間把它初步弄出來了。記得剛發(fā)布不久，看到 GitHub 上一下子漲了 70 個 star。當(dāng)時已經(jīng)是深夜，我本來已經(jīng)躺在床上了，準(zhǔn)備睡覺了，但腦子里就一直在想著這個開源項目的事情。因為也看到 Star 在漲，雖然只有幾十個，但已經(jīng)讓我感到非常興奮和開心。于是就又從床上爬起來，打開電腦，半夜里再改一改發(fā)現(xiàn)的某個 bug，然后又提交了一次代碼。真的沒想到，從那之后，Star 就一路瘋漲，從幾十漲到幾百，再漲到幾千，最后漲到幾萬。這個漲幅對我來說，感覺就像坐過山車一樣，非常震驚。

向勁宇：所以，到了第二天早上，新兵先做了一些相關(guān)的技術(shù)調(diào)研。等到我們都下班之后，就開始動手實現(xiàn)。實際上，核心的開發(fā)時間并沒有用到三個小時那么久，甚至可能連三個小時都不到。因為我們之前確實有一些相關(guān)的代碼積累?？赡芎诵牡恼{(diào)試和功能實現(xiàn)就花了一個小時左右，基本的效果就已經(jīng)調(diào)出來了。后面主要是在做一些效果的優(yōu)化、文檔的編寫以及后續(xù)的維護工作，新兵在這方面投入了很多。七七八八加起來，從開始動手到最終發(fā)布出來，總共可能也就花了兩三個小時的時間。

唐小引：現(xiàn)在對 Manus 的復(fù)刻項目也有一些，而且 Manus 自己也在準(zhǔn)備開源部分內(nèi)容。你們當(dāng)時選擇如此迅速地開源 OpenManus，除了技術(shù)科普和推廣簡潔實現(xiàn)理念之外，有沒有想過要做 Agent 領(lǐng)域的技術(shù)平權(quán)？

向勁宇：我倒也沒有想到那么高尚的一個理念。因為我覺得 Agent 技術(shù)本身的發(fā)展趨勢就是越來越開放和普及的，開源社區(qū)里已經(jīng)有很多非常好的框架了，比如像 OpenHands 等等。我覺得我們當(dāng)時的主要目的，還是想借著 Manus 引發(fā)的這波巨大的流量，把我們 OpenManus 這個項目，特別是它背后所代表的那種簡潔的實現(xiàn)方式，給推廣出去。

當(dāng)時新兵寫的代碼是盡可能地按照簡潔、易懂的方式來組織的。相比于其他一些可能功能更全面但結(jié)構(gòu)更復(fù)雜的框架，大家可能確實能把它們跑起來用起來，但是不太容易深入理解里面到底是什么原理。而我們 OpenManus 那個框架可能總共就幾千行代碼，對于想入門 Agent 的開發(fā)者來說，他們應(yīng)該能比較容易地去弄懂中間到底發(fā)生了一些什么事情，核心的邏輯是怎樣的。

梁新兵：我也是在做之前主要參考了 OpenHands 的代碼實現(xiàn)?？梢园l(fā)現(xiàn)，其實后來 Manus 官方也提到他們主要是使用了 CodeAct 框架，那這個框架的核心思想和 OpenHands 是非常接近的。我當(dāng)時看了 OpenHands 的代碼，感覺他們這種基于 function call 的實現(xiàn)方式非常有趣，寫得很精簡，也很巧妙。當(dāng)時就覺得這是一個非常簡潔、優(yōu)雅的 Agent 實現(xiàn)范式。

但是，對我個人來說，可能覺得 OpenHands 的整體代碼庫還是太龐大了，包含了很多模塊和功能。雖然它的核心部分很精巧，但對于初學(xué)者或者只想理解核心機制的人來說，可能學(xué)習(xí)成本還是比較高。所以，我就想把這部分最核心的、基于 function call 的 React 模式的精華給抽離出來，用一個只有幾千行代碼的、更輕量級的項目把它展示給所有的用戶。

OpenManus 設(shè)計與實現(xiàn) (Show me the code)

唐小引：接下來進(jìn)入程序員最期待的環(huán)節(jié)。新兵，能給大家詳細(xì)演示一下 OpenManus，深入講講它的設(shè)計理念、代碼結(jié)構(gòu)以及關(guān)鍵的技術(shù)細(xì)節(jié)嗎？

梁新兵：好的，沒問題。我先給大家通過流程圖和類圖來整體介紹一下 OpenManus 的架構(gòu)。

OpenManus 架構(gòu)流程圖

我們設(shè)計的整體流程大致是這樣的：當(dāng)用戶輸入一個需求時，系統(tǒng)會先使用一個 planning tool 來制定一個執(zhí)行計劃。這個計劃可能是線性的，比如包含十個子任務(wù)。然后，系統(tǒng)會把每個子任務(wù)分配給一個相應(yīng)的 Agent 去執(zhí)行。每個 Agent 再采用 react（思考-行動）的模式，去調(diào)用所需的工具 (tool) 來完成分配給它的任務(wù)。

比如說，如果任務(wù)需要上網(wǎng)查資料，Agent 就會使用 browser use 這個 tool 去打開你本地的瀏覽器，訪問網(wǎng)頁、提取信息。Agent 會以一個循環(huán)的方式來執(zhí)行它的任務(wù)，完成后把結(jié)果和中間狀態(tài)傳遞給下一個 Agent。下一個 Agent 再以同樣的方式去完成它被分配的任務(wù)。當(dāng)所有的子任務(wù)都完成之后，系統(tǒng)就會把最終的結(jié)果返回給用戶。

類結(jié)構(gòu)

從類結(jié)構(gòu)來看，我們有幾個比較重要的模塊：flow、Agent 和 tool。flow 模塊主要是用來協(xié)調(diào)多 Agent 的，比如我們實現(xiàn)了一個 Planning Flow 類，它負(fù)責(zé)使用 planning tool 生成規(guī)劃，并將任務(wù)分配給不同的 Agent。但坦白說，在多 Agent 協(xié)作這一塊，我們目前還沒有做得非常深入，只是提供了一個基本的實現(xiàn)示例在代碼倉庫里，還有很大的優(yōu)化空間。

我們目前的核心工作主要還是在單 Agent 和工具 (tool) 這兩塊。這里有一個基類 BaseAgent，所有具體的 Agent，它們最上層的父類都是這個 BaseAgent。每個繼承它的 Agent 都需要定義自己的名字（name）、描述（description）以及系統(tǒng)提示詞（system_prompt）等。定義好這些基本信息就可以了。Agent 的工作是由 run 這個方法來驅(qū)動的。在 run 方法內(nèi)部，它會調(diào)用 step 函數(shù)，通常是在一個循環(huán)里不斷調(diào)用 step 函數(shù)去完成任務(wù)。

對于一個 Agent，我們在這個框架里面實現(xiàn)了一個 React 框架。React 就是 Reason（思考）和 Act（行動）的縮寫。所以 React Agent 這個抽象類里有幾個主要的方法：step、sync 和 act。step 函數(shù)內(nèi)部又會依次調(diào)用 sync 和 act。React Agent 也是通過 run 方法驅(qū)動的，它會在一個循環(huán)里面不斷地執(zhí)行 step 函數(shù)。

然后，我們繼承了 React Agent，寫了一個具體的 tool call Agent。這個 Agent 的核心特點是，它利用了大模型的 function call（或者叫 tool call）能力來集成和使用工具。它也擁有 sync 和 act 這兩個方法。只不過，在它的實現(xiàn)里，sync 的時候是思考具體要使用哪個工具，而 act 則是實際去執(zhí)行選中的那個工具。

tool call Agent 最重要的依賴就是 tool 模塊。在我們設(shè)計 Agent 的時候，我們認(rèn)為 tool 和 prompt 是定義一個Agent能力和行為的最重要的兩個部分。

最后，我們項目中的 Manus Agent（此處指 OpenManus 項目里的 Manus 實現(xiàn)，而不是原始的 Manus 產(chǎn)品），它其實就是繼承了 tool call Agent。它所擁有的核心工具就是我們前面提到的：瀏覽器操作 (browser use)、文件編輯 (editor)、代碼執(zhí)行器（比如 bash 或者 Python execute 用于執(zhí)行代碼）以及一個用于結(jié)束任務(wù)的工具。

app/agent/base.py

現(xiàn)在我們來看一下具體的代碼實現(xiàn)。以上是 BaseAgent 基類，定義了 Agent 的基本接口。

app/agent/manus.py

上面是 Manus Agent 的實現(xiàn)代碼。就像剛才講的，在我們這個框架里，定義一個 Agent 最重要的兩個部分就是工具 (tools) 和提示詞 (prompts)。代碼中定義了 system_prompt，它賦予了 Agent 一個角色身份，說明了它能做哪些事情，它的職責(zé)和任務(wù)是什么。還有一個 next_step_prompt，用戶可以在其中加入一些特殊的指令、行為規(guī)范或者限制，來進(jìn)一步引導(dǎo)大模型的行為。所以說，prompt 定義了這個 Agent 的行為模式。

而 tools 列表則定義了這個 Agent 能夠使用的能力。通過這些工具，Agent 能夠接觸到用戶的本地或遠(yuǎn)程資源。比如說，通過 editor 工具去寫文件、寫文檔；通過 browser_use 工具去訪問網(wǎng)頁、點擊元素、輸入文本等等。

有了 prompt 和 tool 這兩個核心要素之后，Manus Agent 就可以去幫助用戶完成各種任務(wù)了。

app/agent/toolcall.py

它的核心執(zhí)行邏輯主要在父類 tool call Agent 的 sync 和 act 方法里。以上是 tool call Agent（工具調(diào)用智能體）的代碼。這里最重要的就是 sync 和 act 這兩個函數(shù)。sync 和 act 共同構(gòu)成了一次 step（一個執(zhí)行步驟）。在一個 step 中，會先執(zhí)行 sync，然后再執(zhí)行 act（當(dāng)然，中間會有一些判斷邏輯）。

在 sync 方法里面，主要做的事情就是調(diào)用大模型的 API（利用 function call 或 tool call 的能力），把當(dāng)前的對話歷史、可用的工具列表等信息傳給大模型，讓大模型判斷當(dāng)前最應(yīng)該調(diào)用哪個工具，并返回選中的工具名稱以及需要傳遞給該工具的參數(shù)。觀察代碼，會發(fā)現(xiàn)這里得到了一個 response，然后我們會從 response 里面去解析出大模型決定要調(diào)用的工具信息。

在 act 方法里面，就是把上一步 sync 選中的工具實際執(zhí)行起來。比如，如果 sync 決定要調(diào)用 browser_use 工具去訪問某個鏈接，那么在 act 里就會去執(zhí)行相應(yīng)的代碼，最終效果就是彈出一個瀏覽器窗口并導(dǎo)航到指定的 URL。

app/agent/react.py

再從這段代碼看看 React Agent 是怎么組織 step 的。step 函數(shù)內(nèi)部的邏輯就是先調(diào)用 sync，再調(diào)用 act，最后再回到最頂層的 BaseAgent。step 函數(shù)在 run 函數(shù)內(nèi)部的一個 while 循環(huán)里被調(diào)用。當(dāng)用戶發(fā)出一個 prompt（一個任務(wù)需求）時，系統(tǒng)就調(diào)用 run 方法去執(zhí)行這個需求。在執(zhí)行過程中，它會以一個 while 循環(huán)的方式不斷地執(zhí)行 step，進(jìn)行思考、行動、再思考、再行動……直到任務(wù)完成或者達(dá)到某個停止條件。

Agent 的核心工作流程就是這樣：run -> 循環(huán)執(zhí)行 step (sync -> act) -> 完成任務(wù)。

開源社區(qū)的回饋

唐小引：你們目前支持調(diào)用哪些核心工具？Manus 據(jù)說有 27 種工具來確保執(zhí)行精度，你們的工具設(shè)計思路是怎樣的？實現(xiàn)成本高嗎？

梁新兵：OpenManus 這里的核心工具其實數(shù)量不算特別多，主要就是我剛才提到的四個大類：瀏覽器操作 (browser use)、文件編輯器 (editor)、代碼執(zhí)行器（executor，包含 bash 和 python）以及一個結(jié)束任務(wù)的工具 (finish)。總共加起來大概有接近十個工具。

但是，工具數(shù)量的多少其實也取決于如何定義工具的粒度。就拿 browser use 這個工具來說，在我們的實現(xiàn)里，它內(nèi)部其實包含了很多具體的 action（動作），比如 goto_url（訪問鏈接）、click（點擊元素）、input_text（輸入文本）、scroll_up（向上滾動）、scroll_down（向下滾動）等等。在某些其他的 Agent 框架里面，可能會把這里的每一個 action 都作為一個獨立的工具來注冊和使用。但在 OpenManus，所有的這些瀏覽器相關(guān)的 action 都被歸屬于 browser use 這一個工具之下。

所以，我們的工具粒度相對來說會更大一些。這也是為什么我說，有些框架可能會聲稱他們的瀏覽器相關(guān)功能有十幾個甚至更多工具，而在我們這里只算是一個 browser use 工具。因此，OpenManus 工具數(shù)量看起來較少，主要是因為我們的工具粒度更大，將多個相關(guān)動作整合到了一個工具中，而不是工具總的功能覆蓋范圍小。

唐小引：OpenManus 的這些核心代碼主要是由你編寫的嗎？

梁新兵：主體代碼是我完成的。當(dāng)然，在開發(fā)過程中，我也經(jīng)常利用大模型來輔助編程，特別是在 browser_use 這部分，它的一些實現(xiàn)思路也是借鑒了現(xiàn)有的瀏覽器自動化實踐。

你可以看到代碼里，像 browser_use 內(nèi)部其實有很多具體的動作實現(xiàn)，比如 wait（等待）、click_element（點擊元素）、input_text（輸入文本）等等。在一些底層的瀏覽器自動化框架里面，它們可能會通過比如 register_action 這樣的機制，把 input_text 這樣的動作注冊為一個獨立的工具。但在我們的 OpenManus 設(shè)計里，我們是把所有這些瀏覽器相關(guān)的動作都?xì)w屬于 browser_use 這一個更高層級的工具之下。這就是我們所說的工具粒度上的不同。

所以，有些同學(xué)在使用我們 OpenManus 時可能會發(fā)現(xiàn)，好像一般的大模型很難用好這個系統(tǒng)。這是因為我們把許多復(fù)雜的操作都集成到了粒度更大的工具中（比如 browser_use 這一個工具就包含了多種瀏覽器動作）。因為這要求大模型自己去理解和規(guī)劃，在一個大工具內(nèi)部具體要執(zhí)行哪個子動作以及如何組合它們。

唐小引：為什么項目里還有一個 Bedrock 相關(guān)的文件？

梁新兵：你是說 llm/bedrock.py 這個文件嗎？這個是 AWS 官方團隊提交的一個 PR。

app/bedrock.py

唐小引：是他們提交的？我還以為是你調(diào)用的。

梁新兵：而且還是官方提交的。因為我們核心的 LLM 調(diào)用接口 (llm/lm.py)，主要是按照 OpenAI 的 API 格式來寫的。有些用戶他們是使用 AWS Bedrock 服務(wù)，通過它來調(diào)用大模型（比如 Claude）。所以當(dāng)時 AWS 的同學(xué)就提交了這份適配 Bedrock API 的代碼，方便這部分用戶。我感覺這個實現(xiàn)應(yīng)該還可以改進(jìn)。

唐小引：這正好體現(xiàn)了開源的魅力。既然提到了社區(qū)貢獻(xiàn)，除了 AWS 這個 PR，還有哪些比較典型的社區(qū)貢獻(xiàn)被你們合并進(jìn)來了？

梁新兵：比較典型的就是 Web Search 功能的完善。我們 browser_use 工具最初默認(rèn)使用的是 Google 搜索。對于國內(nèi)用戶來說，訪問 Google 不方便。所以，有很多開源貢獻(xiàn)者為我們提供了適配國內(nèi)環(huán)境的搜索引擎支持，比如百度搜索、Bing 搜索等等。這些搜索工具的實現(xiàn)代碼，幾乎全都是開源社區(qū)的小伙伴們提交 PR，我們審核合并進(jìn)來的。

唐小引：我看這里提交得挺全，連 DuckDuckGo 都有支持。

梁新兵：還有一些其他的（搜索引擎支持 PR）沒合并進(jìn)來。

唐小引：這確實能感受到開源的魅力，大家覺得缺少什么功能，就自己動手提交，然后你來負(fù)責(zé)審核和合并。那么反過來說，在收到的社區(qū) PR 里，有沒有哪些是你們明確拒絕合并的？可以舉一些例子嗎？

梁新兵：主要的一種情況是，有些貢獻(xiàn)者一次性修改了太多的代碼。如果一個 PR 修改了二三十個文件，我就會非常慎重地考慮，很有可能不會合并。原因有兩點：首先，對我來說，審核如此大量的改動本身就很困難，很難確保每個細(xì)節(jié)都理解到位。其次，更重要的是，我們目前還沒有建立完善的測試用例。如果貿(mào)然合并一個大規(guī)模的改動，可能會引入一些我預(yù)料不到的問題，甚至破壞現(xiàn)有功能，影響到其他普通用戶的使用體驗。

唐小引：這方面目前有什么進(jìn)展嗎？是還不完善的狀態(tài)？

梁新兵：現(xiàn)在還沒寫測試用例，這是一個短板。但我看到已經(jīng)有開源的小伙伴提交了關(guān)于測試用例的 PR，目前還在修改和完善中。估計等到我們正在進(jìn)行的社區(qū)黑客松結(jié)束的時候，應(yīng)該差不多就能合并第一批測試用例了。

Manus 與 OpenManus 異同

唐小引：我這兩天也看到 OpenManus 黑客松正在進(jìn)行中。到目前為止，你有沒有看到一些比較好的 Idea，可以提前向大家透露一下的？

梁新兵：我可以舉一個例子。大家可以看到 Manus 有很多非常驚艷的效果，比如幫助處理數(shù)據(jù)，并且展示的結(jié)果非常精美。但是在 OpenManus 這里，目前更多的是在命令行里運行，顯示結(jié)果沒有那么優(yōu)美。有些開源貢獻(xiàn)者就在嘗試編寫一些可視化的工具，比如數(shù)據(jù)可視化工具。它能夠以一種非常優(yōu)美的方式幫你處理完數(shù)據(jù)并進(jìn)行展示。這個方向非常棒。

唐小引：最開始我看到 Manus 的時候就有點疑惑。你看大家以前寫代碼基本都會用到虛擬機，但我之前沒想過能把所有工具調(diào)用都封裝到用虛擬機來處理。但在實際運行時，有些動作是無法直觀看到的，我就會去猜測它背后的運行機制。你能否結(jié)合你對 Manus 的研究以及開發(fā) OpenManus 的經(jīng)驗，從你的視角（比如算法、后端）講講它大概的運作機制嗎？

梁新兵：你是說 OpenManus 的運作機制嗎？

唐小引：是的，也結(jié)合你對 Manus 的理解。比如，我之前使用 Manus 實現(xiàn)某個功能時，感覺它和傳統(tǒng)的 AI IDE 很不一樣。用那些 IDE 寫代碼，實現(xiàn)功能時，代碼屬性很強，各種環(huán)境安裝、代碼細(xì)節(jié)都需要你關(guān)注。但用 Manus 時，感覺代碼屬性弱化了很多，更像是自然語言交互。這時我就會好奇它背后是怎么通過代碼實現(xiàn)的。從你操作 OpenManus 的演示來看，它的代碼屬性似乎比 Manus 要強一些。所以想請你結(jié)合對 Manus 的觀察和 OpenManus 的實踐，一起談?wù)勥@個機制。

梁新兵：我可以講一下。首先，我對前后端沒有特別深入的了解，所以主要從算法或者說 Agent 設(shè)計的角度來解釋一下背后的運行機制。

核心還是在于工具（Tool）的設(shè)計和使用。如果你的 Agent 配置了很多與代碼相關(guān)的工具，比如 Python 執(zhí)行、代碼編輯等，那么它的行為自然就和代碼關(guān)聯(lián)更緊密。反之，如果你移除這些工具，它的“代碼屬性”就會減弱。Manus 本身是一個多智能體框架。對于單個具體的智能體，它可能不會像我們 OpenManus 目前這樣，默認(rèn)加載這么多與代碼高度相關(guān)的工具。比如，它可能有一個專門的 BrowserAgent，這個 Agent 可能只配備了一兩個核心工具，比如 browser_use 工具和一個用于結(jié)束任務(wù)的工具。這樣，這個 Agent 的行為就非常聚焦于執(zhí)行瀏覽器相關(guān)的操作。

又或者，假設(shè)我們設(shè)計一個新的智能體，叫 DataAnalysisAgent，這個 Agent 的工具集主要是 Python 相關(guān)的工具，以及一些數(shù)據(jù)分析和可視化的專用工具。它的工具集里可能就沒有瀏覽器操作工具了。如果它與可視化強相關(guān)，那么它的整個行為模式就會偏向于執(zhí)行數(shù)據(jù)分析任務(wù)，并能以優(yōu)美的方式向用戶展示結(jié)果。再比如，如果有一個 CodeAgent，它的工具就會更多地圍繞編寫代碼、執(zhí)行代碼等操作。

所以，Manus 的多智能體設(shè)計，使得每個智能體有不同的角色定位和工具集，從而展現(xiàn)出不同的行為特性。而在我們目前的 OpenManus 實現(xiàn)中，主要是將多種工具都放在了一個通用的 Agent 里，使其能力更全面，但可能在特定任務(wù)上不如專門的 Agent 聚焦。

唐小引：整體設(shè)計和代碼結(jié)構(gòu)很清晰。能跑個例子，讓我們直觀看看 OpenManus 的實際效果嗎？

梁新兵：可以。我來運行主入口文件 main.py。比如，我讓它“幫我制定一個去日本的旅行規(guī)劃”。看看它會怎么做。（啟動執(zhí)行）我調(diào)整一下窗口……（等待）啟動好像需要一點時間。

唐小引：啟動速度似乎是慢了點。

梁新兵：有時候是會這樣。也許是加載的工具太多導(dǎo)致 Prompt 過長，或者網(wǎng)絡(luò)延遲。

（Agent 啟動）它首先是打開了瀏覽器，看配置是訪問 Google，并進(jìn)行搜索，但好像沒找到具體的規(guī)劃信息。

唐小引：所以第一步是網(wǎng)頁導(dǎo)航，而不是直接生成內(nèi)容？

梁新兵：對，這個場景下它主要在使用瀏覽器工具。你看，它開始提取頁面內(nèi)容了……但現(xiàn)在好像卡住了，只是在向下滾動頁面，沒有按預(yù)期去整合規(guī)劃。

唐小引：這就是經(jīng)典的“演示必掛”時刻吧？昨天還好好的，今天演示就不行了。

梁新兵：一個潛在問題是上下文長度。交互幾輪后，歷史記錄變長，有時會讓 LLM 混亂，或者像這樣陷入循環(huán)。當(dāng)然，也很可能是我最近改代碼引入了 Bug，這個得查一下。

唐小引：這說得通。長上下文和預(yù)期外的行為是使用 Agent 時常見的挑戰(zhàn)，更別提這種調(diào)試過程中可能產(chǎn)生的 Token 消耗了。這就引出了一個問題，OpenManus 目前是主要側(cè)重于搜索和信息檢索，還是設(shè)計用來處理更復(fù)雜的生成式任務(wù)？比如，它能否整合多個來源的信息，創(chuàng)造全新的內(nèi)容，像繪制一張全面的 AI 技術(shù)棧圖譜？

梁新兵：問得好。理論上，它的設(shè)計目標(biāo)不止于基礎(chǔ)瀏覽。雖然這次演示不湊巧地卡在了簡單的瀏覽器操作上，但框架是支持更強大的工具的，比如 Deep Research。理想情況下，這種工具會搜索多個頁面、智能提取關(guān)鍵信息，然后綜合生成新的輸出。瀏覽器交互可能只是其中的一步，甚至只是展示信息來源。這次很可能是 Agent 默認(rèn)使用了（或者因為 Bug 卡在了）基礎(chǔ)瀏覽器工具，沒能調(diào)用到更深度的研究能力。而且看起來后臺那個 Agent 進(jìn)程還在異常運行，確實需要修復(fù)。

唐小引：某種程度上，這讓同為開發(fā)者的人有點“安心”。我總以為只有“祖?zhèn)鞔a”才容易牽一發(fā)而動全身，沒想到新項目也同樣讓開發(fā)者保持警惕。

MCP 就像 Type-C 接口

唐小引：你代碼里也包含了 MCP（模型上下文協(xié)議）的相關(guān)實現(xiàn)。Manus 的火爆也帶火了 MCP 這個概念，但之前有開發(fā)者分析說 OpenManus 似乎沒有實際用到它？你能詳細(xì)講講 OpenManus 中 MCP 的實現(xiàn)情況嗎？

梁新兵：對，當(dāng)時我們注意到 MCP 非?；?。其實一開始我也不太懂 MCP 具體是怎么一回事。我就花了一兩天時間去學(xué)習(xí)了一下，主要是通過大模型幫我理解 MCP 的原理，同時也仔細(xì)閱讀了 Anthropic 官方發(fā)布的 Cloud API 文檔中關(guān)于工具使用的部分。了解之后，我就想，能不能在 OpenManus 里面也實現(xiàn)一個 MCP 協(xié)議的支持？于是，我也利用了大模型幫我寫了一些基礎(chǔ)的代碼框架。

app/mcp/server.py

根據(jù)我的理解，MCP 這個協(xié)議里面，有幾個比較關(guān)鍵的組成部分：host、client 以及 server。最重要的就是這三個角色。

host 就類似于像 Cursor 這樣的 AI 編程助手軟件。你可以把 Cursor 這個應(yīng)用程序本身視為 host。

server 其實可以視為我們 OpenManus 框架里面的這些工具 (tool)。這些工具就是提供具體服務(wù)的實體，比如瀏覽器操作服務(wù)、文件編輯服務(wù)、代碼執(zhí)行服務(wù)等等。在我們 Manus Agent 的例子里，server 就相當(dāng)于我們能接觸到的這些本地或遠(yuǎn)程資源。

client 扮演的角色是 Agent 在執(zhí)行任務(wù)時，想要去調(diào)用某個 server（即某個工具）的那個接口或者說代理。當(dāng) Agent（在 sync 階段）決定要調(diào)用某個工具時，它實際上是通過 client 來表達(dá)這個意圖的。然后 host 再根據(jù) client 的請求去實際調(diào)用對應(yīng)的 server。

在 OpenManus MCP 的代碼實現(xiàn)中，我們定義了一個 MCP Agent，它就扮演了 host 的角色，類似于 Cursor。然后我們定義了 MCP Client，它繼承了 Tool Collection，這意味著 client 知道有哪些可用的工具（server）。這和之前 tool call Agent 使用 Tool Collection 的方式是類似的。

當(dāng)一個 MCP Agent (host) 去執(zhí)行任務(wù)時，在 sync 階段，它會把這些可用的工具信息（按照 MCP 協(xié)議要求的格式）傳遞給大模型。大模型會返回一個它想要調(diào)用的工具的參數(shù)（同樣遵循 MCP 格式）。然后在 act 階段，host (MCP Agent) 再去調(diào)用相應(yīng)的 server（即執(zhí)行對應(yīng)的工具代碼）。

唐小引：從你的視角來看，MCP 和 Agent 之間的關(guān)系是怎樣的？它會對 Agent 的發(fā)展產(chǎn)生什么影響？你能給大家拆解一下嗎？

梁新兵：MCP 本質(zhì)上是一個協(xié)議，就像我們生活中的 Type-C 接口一樣，它旨在形成一個統(tǒng)一的規(guī)范。無論是 OpenAI、Anthropic，還是國內(nèi)的一些大模型公司，都可以遵循這個規(guī)范。這個接口或者說規(guī)范的核心作用，是讓智能體（或者說大模型）能夠更好地使用工具、調(diào)用服務(wù)，從而接觸到本地或遠(yuǎn)程的各種資源。

MCP 結(jié)構(gòu)

簡單來說，讓大模型能更方便地“接觸”到外部世界和能力。在 MCP 出現(xiàn)之前，情況是這樣的：OpenAI 發(fā)布了它自己的 Function Calling 格式規(guī)范；Anthropic（Claude 的公司）也發(fā)布了他們自己的 Tool Use 格式；國內(nèi)廠商又有各自不同的規(guī)范。

這就導(dǎo)致一個問題：大家調(diào)用工具的規(guī)范和格式都不統(tǒng)一。假設(shè)我學(xué)習(xí)并掌握了 OpenAI 的格式，學(xué)會了如何讓 GPT 模型調(diào)用工具，但當(dāng)我切換到其他大模型（比如 Claude）時，發(fā)現(xiàn)這套方法行不通了，我必須再去學(xué)習(xí)和適配 Anthropic 的格式。這對用戶來說，需要學(xué)習(xí)不同廠商的多種格式，非常麻煩。

對于工具開發(fā)者來說，也很痛苦。比如我要開發(fā)一個編輯文件的工具 (edit tool)，為了讓不同模型都能用，我需要為 OpenAI 的格式寫一套實現(xiàn)，為 Anthropic 的格式寫另一套，可能還要為千問或其他模型的格式再寫一套。這相當(dāng)于在重復(fù)制造輪子，非常低效。

MCP 的目標(biāo)就是解決這個問題。它提出了一種統(tǒng)一的協(xié)議、接口或格式，讓所有支持 MCP 的大模型都能用同一種方式來使用工具。這樣就不再區(qū)分是 OpenAI 格式、Anthropic 格式還是其他什么格式了。開發(fā)者只需要按照 MCP 規(guī)范實現(xiàn)一次工具，理論上就能被所有兼容 MCP 的模型調(diào)用。

唐小引：我聽明白了，這有點像“一次編寫，處處運行”（Write Once, Run Anywhere）的理念，是程序員夢寐以求的方向。

梁新兵：是的。

超越 Manus

唐小引：聊完了現(xiàn)狀和演示，我們再談?wù)勎磥怼Ｗ詮?OpenManus 上線以來，我看到你們也提到了一些 Roadmap。能詳細(xì)講講接下來的規(guī)劃嗎？比如之前提到的強化學(xué)習(xí)微調(diào)模型，我看 GitHub 上 Star 漲得不錯，這個進(jìn)展如何？還有哪些正在進(jìn)行或計劃中的工作？我看你們在 GitHub 上已經(jīng)打出了“超越 Manus”的口號了，具體打算怎么做？

梁新兵：非常感謝大家的關(guān)注和支持！關(guān)于那個強化學(xué)習(xí)（RL）微調(diào)的事情，現(xiàn)在還在進(jìn)行中，還沒有完全做出來。所以，雖然 GitHub 上 Star 增長得不錯，但項目本身還處于一個比較初步的階段，正在積極開發(fā)，還沒有到說就完全做出來了的程度。

我們現(xiàn)在主要是基于 Agent Gym 這個框架去做 OpenManus 的一個擴展項目，就是 OpenManus RL。計劃是對一些特定的數(shù)據(jù)集進(jìn)行訓(xùn)練。這一塊的話，大家可以持續(xù)關(guān)注我們的進(jìn)展。

對于現(xiàn)在還在進(jìn)行中的一些工作：

工具（Tool）生態(tài)的豐富與增強：我之前也講到，工具是 Agent 能力的核心。我們最近有在 OpenManus 里面添加 Deep Research 這個 tool。你可以看到我們不僅更新了 Web Search 工具，讓大家能更好地使用各種搜索引擎，并且我們還基于 Web Search 寫了一個 Deep Research 的工具實現(xiàn)。但是我們現(xiàn)在還沒有明確指定哪個 Agent 會默認(rèn)使用它。大家如果感興趣，可以試一下這個工具的效果怎么樣。這些都是近期剛剛完成并提交的一些代碼。
MCP 協(xié)議的持續(xù)完善與落地：我們最近也支持了這個 MCP 協(xié)議。但是里面還有一些需要處理的事情，比如讓這個 MCP Agent 能夠支持那些不具備 function calling 能力的模型也能使用我們的框架。這一點我們還沒有完全實現(xiàn)，所以這里也是一個待做的事情。
多 Agent 協(xié)調(diào)（Flow）機制的完善：就像我之前提到的，flow 模塊我們還沒有很好地完成一個多 Agent 協(xié)調(diào)的工作。這塊比較復(fù)雜，有很多不同的實現(xiàn)思路，我還沒想好最佳的方案。所以這里也是一個待做的事情。目前主要還是單智能體的狀態(tài)，雖然我們有寫 flow 模塊，但它還沒有很好地協(xié)調(diào)起各個智能體。
測試用例的建立與完善：這是提高項目質(zhì)量和可維護性的關(guān)鍵。就像剛才提到的，已經(jīng)有社區(qū)小伙伴在貢獻(xiàn)相關(guān)的 PR 了，正在修改中，希望能盡快建立起一套覆蓋核心功能的測試體系。
社區(qū)互動與貢獻(xiàn)管理：我們會繼續(xù)保持開放的態(tài)度，積極響應(yīng)社區(qū)的 Issue 和 PR。同時也會堅持對 PR 的質(zhì)量進(jìn)行把控，優(yōu)先保證核心框架的穩(wěn)定性和簡潔性。希望社區(qū)貢獻(xiàn)者在提交 PR 時能盡量聚焦問題、拆分改動，方便我們審核和集成。另外，我們也會關(guān)注黑客松項目中涌現(xiàn)出的優(yōu)秀工具，比如可視化工具或其他有意思的工具，考慮將它們集成進(jìn)來。

基本上就是這些事情。主要可以關(guān)注這幾個模塊（文件夾）的進(jìn)展：flow（多Agent）、agent（MCP 支持）、tool（新工具集成）以及測試用例的建設(shè)。

唐小引：你在學(xué)習(xí)其他開源項目（比如 Agent 項目）時，是如何理解他們的代碼，然后借鑒到自己項目中的？你的流程是怎樣的？比如說會不會把代碼復(fù)制粘貼出來，然后去問 ChatGPT 或 Kimi/Grok 這些大模型？能給大家分享一下你的實際操作嗎？

梁新兵：很大程度上就像這位小伙伴說的那樣。我在之前的分享中也提到過具體的操作方式。

舉個例子，比如我去看 claude-tool-use 這個倉庫。我會先看一下它的項目結(jié)構(gòu)。我一開始會先關(guān)注核心模塊，比如 agent 或者 browser 相關(guān)的代碼。

我可以給大家分享一個我平常經(jīng)常使用的工具，叫 RepoMix（或其他類似的代碼閱讀/分析工具）。

RepoMix 工具

比如，我把 claude-tool-use 倉庫的地址輸入到這個工具里，它就能幫我抓取整個倉庫的文件結(jié)構(gòu)和代碼內(nèi)容，整合成一個大的文本文件。這里面會包含項目結(jié)構(gòu)樹，以及下面每個代碼文件的具體內(nèi)容。我可以直接復(fù)制這些內(nèi)容。

復(fù)制之后，我就會把這些代碼或者項目結(jié)構(gòu)信息扔給大模型，比如 Kimi、ChatGPT 或者 Claude。我會讓它幫我講解這段代碼的邏輯，或者根據(jù)項目結(jié)構(gòu)幫我用 Markdown 畫出系統(tǒng)架構(gòu)圖。有了架構(gòu)圖之后，就能更好地理解整個項目的運作方式。

當(dāng)然，有時候整個倉庫的代碼量太大，一次性復(fù)制給大模型可能會超出 token 限制。這時，我會分模塊來看。比如，先只復(fù)制 agent 模塊下的代碼，粘貼給大模型，讓它先幫我理解這個核心模塊。

等我通過這種方式大致了解了項目的各個模塊及其運作原理后，我就能知道關(guān)鍵代碼在哪里。我會嘗試將這個項目中的精華部分，或者我需要的功能，整合到我自己的 OpenManus 項目里來。

像對于 browser_use 這個功能，我了解了它的實現(xiàn)后，可能會把它的核心邏輯和依賴導(dǎo)入到我的項目中。我會基于我們 OpenManus 的 BaseTool 這個基類，讓 AI 編程助手（比如 Cursor）幫我生成一個符合我們框架規(guī)范的新工具類。AI 會幫我生成初始的代碼框架，當(dāng)然，生成的代碼往往還需要我自己進(jìn)行后續(xù)的修改和調(diào)試，補充一些細(xì)節(jié)?；旧暇褪沁@樣一個流程。

唐小引：你在開發(fā) OpenManus 的過程中，因為整個項目推進(jìn)速度很快，而且你之前可能也沒有特別豐富的開發(fā) Agent 應(yīng)用的經(jīng)驗。我想了解一下，你現(xiàn)在構(gòu)建 Agent 的思路是怎樣的？在功能實現(xiàn)上，是否需要做一些平衡和取舍？有哪些功能是你經(jīng)過綜合考慮后，決定暫時先擱置或者降低優(yōu)先級的？

梁新兵：在做這個項目的過程中，感覺最難的部分是多智能體協(xié)作（Multi-Agent Coordination）。關(guān)于多個智能體如何交互、協(xié)作，學(xué)術(shù)界和工業(yè)界提出了很多不同的方法和框架，但目前還沒有一個公認(rèn)的最佳實踐。

所以在 OpenManus 里，我當(dāng)時主要是參考了 Manus 展示出來的效果，實現(xiàn)了一種基于規(guī)劃（Planning）的、線性的多智能體協(xié)作方式。但在完成了一個初步的版本之后，我就沒有再繼續(xù)深入地去修改或優(yōu)化它了。主要原因是我還沒想好更優(yōu)的方案應(yīng)該是什么樣的，感覺這塊比較復(fù)雜，所以暫時先把它的優(yōu)先級降低了。

唐小引：那從社區(qū)反饋來看，有沒有開發(fā)者圍繞多智能體這塊提出比較多的建議或討論？

梁新兵：暫時還沒看到很多關(guān)于多智能體的深入反饋或討論。這也從側(cè)面說明，這塊可能確實對大家來說都還有一定的探索難度，是一個有挑戰(zhàn)性的方向。

關(guān)于《萬有引力》：

這是由 CSDN &《新程序員》執(zhí)行總編唐小引主理的對話欄目。技術(shù)趨勢多變，一不留神總擔(dān)心錯過。正在發(fā)生的技術(shù)事件，對于我們開發(fā)者意味著什么？我們面臨的諸多困惑從何尋找答案？《萬有引力》即志在于此，直面事件與困惑，抽絲剝繭，解讀技術(shù)真相。