仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
前几天号称“东方破晓”的Manus.im[1]着实火了一把。但这几天的演进也充满戏剧性，已经有一大堆开源项目来复刻他们。OpenManus[2]算是比较早的一个，号称3小时就复刻了，但其实他们背后的MetaGPT团队已经搞Agent很久了。
我感觉目前的产品惊艳或者翻车都很正常，整个行业才刚开始。但OpenManus这样的项目是一个很不错的学习Agent开发的切入点，它足够简单，也覆盖了足够多的东西。这篇文章是我的一个学习笔记外加一些思考，跟大家交流。
事先说明，开源代码库变化很快，我是2025年3月7号下载的，所有内容都基于当时的版本。先来看一下整个工程的结构：
可以说是非常简单的，除掉资源、readme、配置，一共只有30来个文件。不过朋友们可能会想也许是requirements里有很多强大的包干了很多基础性工作，所以来看下工程依赖，我把每个包干嘛用的也写出来：
可以看到并没有啥特别的，主要是一些跟agent工具相关的包。
工程结构也很清晰，分为agent、flow、prompt、tool四个目录，app这个主目录还有一些辅助的类定义。
看过Manusdemo的朋友应该对里面的plan过程印象比较深刻，它会建一个文件，用markdown格式写下一步一步要做什么，然后做完了打勾。这里的planning.py干的就是这事儿，它维护了一个计划的状态。
browser_use[3]本身就是一个很成功的agent项目，让AI可以操作浏览器。根据官网介绍，这个项目获得了yc的投资，团队就2个人。
说到tool，我准备在后面写一篇文章聊一下对最近蛮火的MCP的理解，大家感兴趣的话可以点个关注。当然，OpenManus这个项目没有用到MCP。
再来看一下OpenManus的prompt，就看两个，一个是planning，prompt如下
还有Manus的prompt
都是非常朴素的指令。我想说的是，从prompt这么简单基本上就可以推断出实际的效果并不会很好。
再来看agent目录，继承关系是这样的:BaseAgent–>ReActAgent–>ToolCallAgent–>Manus，逐个来看：
BaseAgent：定义了一个agent的基础字段比如name、memory、systemprompt等和基础行为，比如执行、判断是否卡住等。
ReActAgent：更细致定义了每一步应该怎么做，遵从论文里的定义先think再act
ToolCallAgent:更细致地定义了think是要选择工具，act里要执行think选择的工具
Manus：没有定义新功能，只是覆盖了ToolCallAgent的systemprompt和nextstepprompt
ReAct是Agent领域较早期的一篇著名论文，当时还没有现在的reasoningmodel，大家都是通过prompt的方法让模型在干活前先想一想，从而表现出推理的行为。非常像老师教学生怎么做题。而现在的reasoningmodel是把这一行为内化了，模型会自主地产生思考的过程，然后再进行实际的输出。从各种benchmark来看，推理模型已经大大超过了原来靠prompt的方法，成了一个青出于蓝而胜于蓝的学生。
这里帮大家梳理一下manus的运行流程
用户输入一个需求，调用Manusagent的run函数来执行这个需求
run函数是一个循环，在超过步数限制或得到结果之前不停运行agent的step函数，这个step是在ReActAgent里定义的，里面又包括两步
think:执行Manus的SYSTEM_PROMPT，主要就是选工具
act:依次执行think里选的工具，把工具执行的结果放在memory里
仔细看Manusagent的实现会发现它其实没有用到planning，只有一些基础工具可供使用。所以这也许是好多人反馈效果差的原因。因为你实际上只是使用了一个两年前就有的ReAct模式的Agent。
Readme里有写到有一个unstable的flow版本，这个版本确实应该更强大一些，它是在Manus上再套一层planning，有个planningflow来做agent的调度。
flow文件夹包含了管理AI代理如何处理和执行任务的编排层。它定义了执行模式并协调代理之间的交互。
BaseFlow类是一个抽象基类，其主要功能包括：
管理代理集合（支持单个、列表或字典格式）
为每个流程确立“主要代理”的概念
提供代理管理方法（获取/添加）
定义所有流程必须实现的抽象execute方法
使用Pydantic进行数据验证和类型安全检查
PlanningFlow继承自BaseFlow，实现了一种基于规划的执行策略：
使用PlanningTool创建和管理执行计划
将用户任务拆分为连续的步骤
跟踪每个步骤的状态（未开始、进行中、已完成）
管理计划执行的整个生命周期
处理计划检索和执行过程中的错误恢复
这个流程的执行步骤如下：
awaitself._create_initial_plan(input_text)来创建一个计划。对比一下刚才的ManusAgent，那里只是在每一步想想要哪个工具，并没有做更全面的规划。
按照计划，调用一个agent来执行计划里的每一步。这里他们实际上只有一个agent，就是上面的ManusAgent。一个很容易想到的扩展就是引入更多专业的agent，然后充分发挥不同agent的特长。
检查计划是否被执行完或者出了问题
这里还有一个不同就是会每一步根据整个plan的状态来动态生成一个agent的input。而在ManusAgent里，输入就是用户说的一句话。
总的来说，planning像是一个自动写prompt的过程，就是通过它来给agent更多的上下文信息，和更细致的指令。
在我看来，从这个项目里基本已经可以看出现在的Agent开发到底是在干什么
升级模型。这个我相信99.99%的开发者没有能力做，基本是在等大厂升级，然后水涨船高。小部分开发者可以针对里面的具体环节做一些训练，比如挑工具、规划等等。
给模型提供更好的工具，比如信息召回、写代码、用浏览器。工具做得越厚，agent这里就可以做得越薄。工具其实也是一个个agent。browser-use就是这个模式，从工具出发，先卖铲子，再看有没有更大的机会。
用prompt来弥补模型的短板。模型懒惰不肯多想，我明确给你分阶段先想后做；模型关注当下没有大局观，我给你整一个planning环节先谋划谋划。绝大部分开发者应该在这里，但很明显1可能会吃掉3，但只要场景够细，我感觉prompt都还有空间。
找好的showcase，提升颜值。Manus这个项目应该给大家上了一课，好看天然就有传播力，更容易火，更容易成。现阶段指望一个执行成功率非常高的通用Agent还挺难的，多少有点抽卡的成分。
跳出来看，Cursor就是一个把上面四个环节全覆盖了的公司，而且能写代码的Agent意味着巨大的想象空间（相当于学会了制造工具！🦍vs🧑🤝🧑）。
以上就是本文全部内容，欢迎大家多交流。下下周有去GTC的朋友也可以约个线下。
参考资料
Manus.im:https ://Manus.im
OpenManus:https ://github.com/mannaandpoem/OpenManus
browser-use:https ://github.com/browser-use/browser-use
进技术交流群请添加AINLP小助手微信（id:ainlp2)
请备注具体方向+所用到的相关技术点
关于AINLP
AINLP是一个有趣有AI的自然语言处理社区，专注于AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
