Manus的技术实现原理浅析与简单复刻

最近Manus可谓是AI圈的“新晋网红”，上线第一天就全网“一码难求”，并且当天晚上就有团队开源了OpenManus项目，剧情跌宕起伏，充满了戏剧性~ 最近有幸实际体验到了Manus的运行效果，结合Manus实际运行的情况、OpenManus的开源代码，在加上网传的Prompt信息，我大致分析出了Manus的技术实现原理，并在后面做了一个简单版本的复刻，本文是参考网络上的信息再加个人理解，行文仓促，难免有疏漏，欢迎大家互相交流探讨~



Manus[1]，是中国的创业公司Monica发布的全球首款通用Agent（自主智能体）产品。Manus定位于一位性能强大的通用型助手，对于用户不仅仅是提供想法，而是能将想法付诸实践，真正解决问题。

Manus作为全球首款真正意义上的通用AI Agent，具备从规划到执行全流程自主完成任务的能力，如撰写报告、制作表格等。它不仅生成想法，更能独立思考并采取行动。以其强大的独立思考、规划并执行复杂任务的能力，直接交付完整成果，展现了前所未有的通用性和执行能力。据团队介绍，Manus在GAIA基准测试中取得了SOTA（State-of-the-Art）的成绩，显示其性能超越OpenAI的同层次大模型。

manus 教程

Manus的名字含义：“Manus”在拉丁文中意为“手”，象征着知识不仅存在于思维中，还应能通过行动得以实现。这体现了Agent与AI Bot（聊天机器人）产品从提供信息到执行任务的本质进阶[2]。

Manus的输入界面，和平时的Chat Bot的设计基本上一样，主界面是一个简单的输入框，同时可以选择模式：





我们以实际运行的阿里云邮箱域名解析诊断为例子，看下Manus的自主思考逻辑。

Manus会先对输入的问题进行规划，分解成多个粗粒度的“步骤”，这个粗粒度的步骤是一下子规划出全局过程的，是能看到总进度的，后续就按照这个总进度运行：



在任务执行的过程中，大模型会根据每个“规划”的步骤，去拆解更细粒度的“子步骤”，这个过程是增量式的规划，就是一步一步的规划，不会一下子规划出全局，比如：执行命令

在需要执行命令的时候，Manus就会实例化一台远程的虚拟机沙箱环境，后续所执行的命令、代码均在这台沙箱环境中运行，在整个会话结束之前会一直保留，这个过程中，模型可以随时创建目录、读取文件，能做到信息的存储和交互等等。



在执行命令的时候，出现报错，比如缺少环境、命令不合法、模型会进行相应调整，然后重新执行、更换命令。这一部分的技术思想是来自CodeAct[6]，也就是大模型可以自主写命令和代码，然后自主观察代码的运行结果，并且进行反思和调整，有兴趣的朋友可以去读一下论文原文。



在环境ready之后，模型决策再次执行之前的命令，这次就拿到了准确、不报错的结果：



a. TODO列表

每次任务完成，模型都会自主更新一个 todo.md 的任务列表，第一次没有todo的任务列表的时候需要创建，创建之后，后续就更新todo列表，每完成一个任务就打✅



b. 过程文件

某些步骤执行过程中，模型会自主判断有些需要的中间过程，需要存储的，会存放到某个.md文件中，作为中间过程文件：



第1步中规划的所有内容执行完成之后，会开始输出最终结果，最终结果的过程中，会结合前文输出解决方案，以及将会话中的文件列出来：



由于Manus是非开源的项目，所以我们没法直接看到其实际的技术设计，但我们可以从显性的自主执行过程、OpenManus[3]等开源项目、网传的Manus Prompt等多方面，来推测出Manus隐含的设计思路。

Agent执行过程流程图

OpenManus的流程是一个比较典型的ReAct的Agent模式，根据开放的源码，可以抽象成下面的流程图，中间Step()的部分就是Agent Loop的过程：



Prompt设计

下面是OpenManus Agent的Prompt配置：

OpenManus的Prompt

除此之外，也可以看下这个MetaGPT Agent框架默认的Planning的Prompt配置：

Planning的Prompt

实际运行时候LLM的对话Log

把上面问Manus的问题，给OpenManus，然后模型配置Qwen2.5-Max，可以看到实际运行对话Log：

实际运行对话Log

由于OpenManus没有提供命令执行的插件，因此模型选择使用PythonExecute来通过Python代码的方式实现对域名解析的查询，但是其背后的原理是一样的。

Agent执行过程流程图

参考OpenManus的代码设计，结合前面显性的执行过程，大致上可以推测出Manus的设计如下：



在实例化的这台虚拟机沙箱里面，有几个基础动作，就可以覆盖绝大部分要做的事情：

根据网传的情况来看，总共有29种工具，还包括一些消息通知、文件内容查找、文件搜索、部署端口等。

Manus Prompt设计

根据网传的Manus的Prompt[5]，我们可以一起来分析一下，这里面描述了Manus的人设、主要技能的Prompt：

触Agent循环调度执行的Prompt：

Agent Loop

Manus使用的主要的几个Tools，可以在一些通用的Agent平台上注册/寻找类似的插件，比如：

然后，仿照上面我们分析的Manus的Prompt，来写一段Prompt，如下所示：

复刻简单版本的System Prompt

然后，模型选择Qwen2.5-Max，基本配置如下，就可以跑出下面的效果了：

比如，测试同样的邮箱域名解析检测逻辑，基本实现了多步调用命令工具的过程，并且根据调用结果模型总结出了相应的原因分析和解决方案，可以说简单的复刻了Manus的效果，基本上有那味了：



当然，这个版本还是基于插件工具的形式实现的单Agent形态的ReAct模式，如果想要实现真正Manus的效果，还需要接入对电脑操作系统的深度访问，才能实现更加智能化的效果，这里还涉及到容器、虚拟化的实现，需要工程层面做一定的改造~

Manus是一种“通用Agent产品”，其实现的技术理想路线值得我们学习，未来AI发展的终态也应该会是类似Manus这样的Computer Use形态，能够通过与人的交互，把需求收集上来，然后Agent可以自主规划、决策完成整个任务，解放人类的生产力，极大提高效率。

当然，这个过程中，如果有更好的人机交互过程，可能效果会更好，比如说在Manus执行完某些步骤之后，可以阶段性的跟人进行对焦，确认方向没有走偏的情况下，再继续执行，可能效果会更好~

在我们的业务场景下，也有着大量的业务需求，需要用更快的、效率更高的方式去解决。

如上所说，Manus这样的形态，非常适合用在

因此，在我们的业务场景下，如果满足上述两个条件的场景，就可以大胆使用Manus这样的形式来设计，比如，在阿里云的客户服务场景下，有许多技术类复杂问题要解决，在这些复杂问题的解决上，可以考虑使用类似Manus这样可以自主规划、拆解问题的方式，来帮助客服做一定的辅助探索和辅助解决。当然，在业务上能否顺利应用，还需要考虑准确性、可控性、运行性能等各种因素，在实际业务场景落地的过程中，依然还有很长的路要走。