作者 | 萬有引力

出品 | CSDN（ID：CSDNnews）

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

OpenManus 項目 Star 數

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

OpenManus 項目

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

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

觀點搶先看

梁新兵：

• 我入行 AI Agent 也是陰差陽錯，寫第一個 Agent 應用時很多代碼還是 AI 幫我生成的。

• 看新代碼庫？直接用工具把代碼扒下來，扔給大模型讓它畫架構圖！

• OpenManus 的核心就是 Tool 和 Prompt，我想用幾千行代碼把 Agent 核心邏輯展示給用戶。

• MCP 就是 AI 界的 Type-C 接口，目標是“一次編寫，處處運行”。

• 多 Agent 協調太難了，我們暫時把它優先級降低了。

向勁宇：

• 感覺繼續學物理，自己沒有找到合適的方向，加上 ChatGPT 沖擊，就果斷轉了 AI。

• Manus 一出我就知道能火，半夜兩三點發消息給新兵：明天下班“爆肝”復刻一個！

• AI 取代程序員？沒關系！未來需要懂研究、產品、代碼的混合人才。

• OpenManus 開源不是為了技術平權那么高尚，主要是科普+推廣簡潔實現。

• 框架優先保證簡潔易懂，Token 消耗優化可以后續再說。

從社群黑客松到 Agent，00 后的 AI 啟蒙與轉向

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

梁新兵：我叫梁新兵，00 年出生，現在是華東師范大學研二在讀。本科是在廣州大學讀的網絡工程專業，算是科班出身。

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

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

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

向勁宇：我是向勁宇，01 年的，剛從西南交通大學應用物理系本科畢業半年多，現在在 DeepWisdom 擔任 Agent 方向的算法研究員。

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

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

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

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

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

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

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

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

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

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

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

唐小引：聽起來像是勁宇貢獻點子和想法，新兵負責技術實現？

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

00 后的 AI Coding 工作流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

唐小引：現在對 Manus 的復刻項目也有一些，而且 Manus 自己也在準備開源部分內容。你們當時選擇如此迅速地開源 OpenManus，除了技術科普和推廣簡潔實現理念之外，有沒有想過要做 Agent 領域的技術平權？

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

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

梁新兵：我也是在做之前主要參考了 OpenHands 的代碼實現。可以發現，其實后來 Manus 官方也提到他們主要是使用了 CodeAct 框架，那這個框架的核心思想和 OpenHands 是非常接近的。我當時看了 OpenHands 的代碼，感覺他們這種基于 function call 的實現方式非常有趣，寫得很精簡，也很巧妙。當時就覺得這是一個非常簡潔、優雅的 Agent 實現范式。

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

OpenManus 設計與實現 (Show me the code)

唐小引：接下來進入程序員最期待的環節。新兵，能給大家詳細演示一下 OpenManus，深入講講它的設計理念、代碼結構以及關鍵的技術細節嗎？

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

OpenManus 架構流程圖

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

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

類結構

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

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

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

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

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

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

app/agent/base.py

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

app/agent/manus.py

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

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

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

app/agent/toolcall.py

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

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

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

app/agent/react.py

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

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

開源社區的回饋

唐小引：你們目前支持調用哪些核心工具？Manus 據說有 27 種工具來確保執行精度，你們的工具設計思路是怎樣的？實現成本高嗎？

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

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

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

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

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

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

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

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

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

app/bedrock.py

唐小引：是他們提交的？我還以為是你調用的。

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

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

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

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

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

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

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

唐小引：這方面目前有什么進展嗎？是還不完善的狀態？

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

Manus 與 OpenManus 異同

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

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

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

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

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

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

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

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

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

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

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

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

梁新兵：有時候是會這樣。也許是加載的工具太多導致 Prompt 過長，或者網絡延遲。

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

唐小引：所以第一步是網頁導航，而不是直接生成內容？

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

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

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

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

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

唐小引：某種程度上，這讓同為開發者的人有點“安心”。我總以為只有“祖傳代碼”才容易牽一發而動全身，沒想到新項目也同樣讓開發者保持警惕。

MCP 就像 Type-C 接口

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

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

app/mcp/server.py

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

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

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

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

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

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

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

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

MCP 結構

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

這就導致一個問題：大家調用工具的規范和格式都不統一。假設我學習并掌握了 OpenAI 的格式，學會了如何讓 GPT 模型調用工具，但當我切換到其他大模型（比如 Claude）時，發現這套方法行不通了，我必須再去學習和適配 Anthropic 的格式。這對用戶來說，需要學習不同廠商的多種格式，非常麻煩。

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

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

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

梁新兵：是的。

超越 Manus

唐小引：聊完了現狀和演示，我們再談談未來。自從 OpenManus 上線以來，我看到你們也提到了一些 Roadmap。能詳細講講接下來的規劃嗎？比如之前提到的強化學習微調模型，我看 GitHub 上 Star 漲得不錯，這個進展如何？還有哪些正在進行或計劃中的工作？我看你們在 GitHub 上已經打出了“超越 Manus”的口號了，具體打算怎么做？

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

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

對于現在還在進行中的一些工作：

• 工具（Tool）生態的豐富與增強：我之前也講到，工具是 Agent 能力的核心。我們最近有在 OpenManus 里面添加 Deep Research 這個 tool。你可以看到我們不僅更新了 Web Search 工具，讓大家能更好地使用各種搜索引擎，并且我們還基于 Web Search 寫了一個 Deep Research 的工具實現。但是我們現在還沒有明確指定哪個 Agent 會默認使用它。大家如果感興趣，可以試一下這個工具的效果怎么樣。這些都是近期剛剛完成并提交的一些代碼。

• MCP 協議的持續完善與落地：我們最近也支持了這個 MCP 協議。但是里面還有一些需要處理的事情，比如讓這個 MCP Agent 能夠支持那些不具備 function calling 能力的模型也能使用我們的框架。這一點我們還沒有完全實現，所以這里也是一個待做的事情。

• 多 Agent 協調（Flow）機制的完善：就像我之前提到的，flow 模塊我們還沒有很好地完成一個多 Agent 協調的工作。這塊比較復雜，有很多不同的實現思路，我還沒想好最佳的方案。所以這里也是一個待做的事情。目前主要還是單智能體的狀態，雖然我們有寫 flow 模塊，但它還沒有很好地協調起各個智能體。

• 測試用例的建立與完善：這是提高項目質量和可維護性的關鍵。就像剛才提到的，已經有社區小伙伴在貢獻相關的 PR 了，正在修改中，希望能盡快建立起一套覆蓋核心功能的測試體系。

• 社區互動與貢獻管理：我們會繼續保持開放的態度，積極響應社區的 Issue 和 PR。同時也會堅持對 PR 的質量進行把控，優先保證核心框架的穩定性和簡潔性。希望社區貢獻者在提交 PR 時能盡量聚焦問題、拆分改動，方便我們審核和集成。另外，我們也會關注黑客松項目中涌現出的優秀工具，比如可視化工具或其他有意思的工具，考慮將它們集成進來。

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

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

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

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

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

RepoMix 工具

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

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

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

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

像對于 browser_use 這個功能，我了解了它的實現后，可能會把它的核心邏輯和依賴導入到我的項目中。我會基于我們 OpenManus 的 BaseTool 這個基類，讓 AI 編程助手（比如 Cursor）幫我生成一個符合我們框架規范的新工具類。AI 會幫我生成初始的代碼框架，當然，生成的代碼往往還需要我自己進行后續的修改和調試，補充一些細節。基本上就是這樣一個流程。

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

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

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

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

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

關于《萬有引力》：

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

• 欄目定位：一檔面向開發者群體，聚焦解讀技術事件的對話直播欄目。

• 直播觀看平臺：CSDN 視頻號、CSDN 網站 & App

• 多形式：文章、視頻、音頻都會有，持續關注 CSDN 公眾號都可獲取。目前《萬有引力》欄目已上線小宇宙平臺，歡迎大家關注！
  

AMDROCm AI 開發者專場來啦！

為促進 AMD ROCm 開發者技術交流，探索大模型與開源工具的實踐路徑

AMD 將于 4 月 19 日在上海 舉辦 ROCm 開發者專場活動！本次活動包含深度技術解析、Workshop 現場互動、開發者福利三大環節，現場更有幸運抽獎（獎品包含基于 AMD 全新 GPU 架構的 Radeon? 系列顯卡等）

歡迎開發者朋友們一起交流碰撞，用 ROCm 打開大模型推理加速新可能！