我们能从Manus学到什么，企业版的Manus会长什么样？

AI资讯 3周前 charles

1.6K 0 20

Manus的明牌

Manus被引爆了。

子弹飞到现在，正面和负面评价同时存在。但在我看来，Manus的结果是否准确并不重要，重要的是它又把我们想象中可以独立自主运行的Agent形态向前推进了一步。

这一次，它的主要创新点是：他给了Agent配了一个虚拟机，也就是Agent终于拥有了自己独立的电脑，而不管是之前Anthropic 的Computer use，还是OpenAI的Operator，Agent并没有拥有独立的电脑。

我们把Manus与几个已经被市场认可的的AI产品对比一下：

也就是说：

Perplexity = 搜索结果 + AI。

Monica = 浏览器内容 + AI。

Cursor = IDE(集成开发环境) + AI。

而Manus是：

Manus = 虚拟机（浏览器 + code + 调用第三方API + 部署发布） + AI

在这里，我配一张官网截图，你能看得更透彻：

也就是说，Manus不仅能让普通人进行搜索、使用浏览器，编码，还能把应用在虚拟机上部署，发布，意味着任何人可以把自己的需求做成可以直接使用的产品，再也不用求着开发去做功能了。

不过这些产品的运行都是需要云资源的。到这里，我想你能理解为什么Manus不能开放邀请码了，因为每个邀请码背后除了Token消耗之外，还意味着一台虚拟机资源。并且Manus还要根据用户诉求在这个虚拟机上安装不同的代码库，这些代码库能否正确安装会决定任务能否正确被执行。因此，团队在没有经过充分的测试之前，一定会控制使用范围。

其实，在Manus发布前，创始人肖弘就在一次访谈中提到：

”一个虚拟服务器，一个浏览器，（agent）能自己写代码去调用API，他就能胜任各种各样的长尾任务，这是我们在做的事情。“

访谈的录制时间至少早于Manus发布一个礼拜，所以Manus其实打的是明牌，而它火爆程度可能真的是超出了团队之前的预料。

Manus的启发

对于一个经历了互联网、云计算、AI三代的人来说，我欣喜地看到这三代技术在Manus里融合了，这是因为：

浏览器是互联网的产物。
虚拟机 + API（微服务架构）是云计算时代的关键产物。

第二点理解起来比较晦涩，云原生的朋友（2010年后毕业）不一定体会，我和大家解释一下：

”云计算本质上是资源共享+分布式架构；虚拟机就是在一台物理机上运行多个操作系统，意味着多个服务可以共享一台物理机；而为了实现分布式，就需要降低系统之间的耦合度，让每个单独的系统能独立运行，但又能高效通讯，这就是微服务架构，也就是API service。我2015年加入一家传统软件公司后，核心做的就是将公司内部所有的服务上云，具体工作就是将服务单元拆解再拆解，直到形成足够细致、独立的API供外部团队使用。“

所以，Manus是继承式的组合创新。即便今天Manus的核心能力依然依靠基座模型本身的能力，但它绝对不能简单地用套壳来形容，如果Manus是套壳，那么天下就只会有模型公司和套壳公司。

同时，Manus也再一次提醒我们：

1. 新技术来临之时，不要抛弃过去的技术积累。比如过去十年云计算发展离不开互联网的普及，互联网发展离不开个人电脑的普及。同样，今天AI的发展，依然要与旧技术充分融合，这是产品演进的客观规律。

2. 在AI时代，不要幻想也别要求软件公司还有技术壁垒，就连梁文锋也说技术壁垒很快会被打破，更不要说一个做AI应用的小公司了。无论如何，做出来是最重要的。

但作为一个常年服务企业的AI产品经理，其实今天我更关心的是：如果把Manus的形态放在toB场景中，会是什么样子？

企业版的manus应该长什么样？

首先和大家展示我们目前的产品Chat2API一小段执行截图，它部分能代表我个人对企业版Manus的期待。

在这个case里，我们完成的是一个飞书任务：给手机号1xxxx92的用户发你好的消息，Agent首先会做plan：

1. 找到手机号1xxxx92的UserID。

2. 发送信息。

然后选择对应的接口，从上下文中找到需要的信息生成API request，并执行这个接口请求。我们还可以完成其他任务，比如：

“将昨天的销售会议纪要转换为 PDF 格式，并发送给销售团队”

”把xxx客户最新的进展发送给销售总监。“

这类灵活任务我们称为非SOP任务。除此之外，我们还会有相对复杂的任务，比如：

”每月初，把上月的销售漏斗报告，并发送给销售总监“

这个任务是要固定执行的，我们称之为 SOP任务。这种任务相对复杂，我们需要根据销售漏斗的定义：从每月新增客户中，找出有多少客户是试用了的，有多少客户是购买了的，并将这三个数字按照漏斗表示。

对于企业来说，通常这样的SOP会形成需求，纳入软件迭代内容，需要开发人员完成。未来我们希望也可以通过Agent 完成编码、部署、发布，让更多、更丰富的SOP沉淀下来，满足更多个性化诉求。

在Manus之前，我们的思路是让开发人员辅助完成，而Manus给了另外一个思路，那就是启用虚拟机完成开发、部署、发布。

所以企业版的Manus，就是既能灵活地完成非SOP任务，又能将SOP在业务中自然沉淀为软件的功能。从企业管理上来说，这里的SOP不是从上而下预制的，是由下而上自然形成的，这会让流程创新变得极度自然、高频。

企业版Manus有哪些不同

企业版的Manus和个人场景会有两个显著不同：

一是：上下文需要强烈依赖企业内部的信息

二是：客户需要更加安全

对于第一点，企业内部信息的获取渠道现在主要有两个：数据库和API。现有的Text2SQL类产品，和我们自己的产品Chat-to-API是两个必不可少的途径。这其中我也遇到了非常多挑战，比如：

1. 模型输出的不确定性

2. 发API管理不完善；

3. 指令理解不精准；

...

如果采用虚拟机完成开发、部署、发布，那么还会有：虚拟机环境的维护、资源调配等问题。

但我们都正在一一克服。我们相信企业的AI转型中，API一定是AI应用与云原生应用充分融合最佳媒介，带着这个理念，Chat2API也在快速迭代。到今天，Chat-to-API已经完全颠覆了去年12月的设计。目前，我们正在和一家云原生公司合作，基于他们内部几百个API完成SOP任务的API编排、应用生成，在这一点上，已经能够辅助新入职程序员快速搭建应用。

同时，我们依然在招募合作伙伴，如果你的场景中希望有一个Agent能调用数以千计的API，欢迎通过公众号联系我们。您会收获一份免费的AI转型咨询，更进一步，您也可以尝试用我们的方法来解决您的业务问题。同时感谢已经联系过的朋友们，我们近期会和大家约见demo~

最后和大家分享并和大家共勉：

以前，中国企业软件有一个共识是：企业软件只有项目，没有产品。有购买力的客户要求个性化，能接受标准化诉求的客户没购买力。

但在AI时代，也许会改变这个局面。因为AI软件的灵活性会”软件承载最佳实践“的定律，支持更灵活的SOP，那么它就能以统一的产品形态满足企业客户个性化诉求，解决toB软件在中国的商业化难题。

接下来，敬请期待！

我是关注和开发AI产品的产品二姐，致力于带来丰富的 AI 学习分享、体会，欢迎你和我一起学习，如果你觉得文章有用，欢迎关注、点赞、转发。

往期精选