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 公众号都可获取。目前《万有引力》栏目已上线小宇宙平台，欢迎大家关注！
（文：AI科技大本营）