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也再一次提醒我们：
新技术来临之时，不要抛弃过去的技术积累。比如过去十年云计算发展离不开互联网的普及，互联网发展离不开个人电脑的普及。同样，今天AI的发展，依然要与旧技术充分融合，这是产品演进的客观规律。
- 在AI时代，不要幻想也别要求软件公司还有技术壁垒，就连梁文锋也说技术壁垒很快会被打破，更不要说一个做AI应用的小公司了。无论如何，做出来是最重要的。
但作为一个常年服务企业的AI产品经理，其实今天我更关心的是：如果把Manus的形态放在toB场景中，会是什么样子？
企业版的manus应该长什么样 ？
首先和大家展示我们目前的产品Chat2API一小段执行截图，它部分能代表我个人对企业版Manus的期待。
在这个case里，我们完成的是一个飞书任务：给手机号1xxxx92的用户发你好的消息，Agent首先会做plan：
- 找到手机号1xxxx92
的UserID。
-
发送信息。
然后选择对应的接口，从上下文中找到需要的信息生成API request，并执行这个接口请求。我们还可以完成其他任务，比如：
“将昨天的销售会议纪要转换为 PDF 格式，并发送给销售团队”
”把xxx客户最新的进展发送给销售总监。
“
这类灵活任务我们称为非SOP任务。除此之外，我们还会有相对复杂的任务，比如：
”每月初，把上月的销售漏斗报告，并发送给销售总监“
这个任务是要固定执行的，我们称之为 SOP任务。这种任务相对复杂，我们需要根据销售漏斗的定义：从每月新增客户中，找出有多少客户是试用了的，有多少客户是购买了的，并将这三个数字按照漏斗表示。
对于企业来说，通常这样的SOP会形成需求，纳入软件迭代内容，需要开发人员完成。未来我们希望也可以通过Agent 完成编码、部署、发布，让更多、更丰富的SOP沉淀下来，满足更多个性化诉求。
在Manus之前，我们的思路是让开发人员辅助完成，而Manus给了另外一个思路，那就是启用虚拟机完成开发、部署、发布。
所以企业版的Manus，就是既能灵活地完成非SOP任务，又能将SOP在业务中自然沉淀为软件的功能。从企业管理上来说，这里的SOP不是从上而下预制的，是由下而上自然形成的，这会让流程创新变得极度自然、高频。
企业版Manus有哪些不同
企业版的Manus和个人场景会有两个显著不同：
一是：上下文需要强烈依赖企业内部的信息
二是：客户需要更加安全
对于第一点，企业内部信息的获取渠道现在主要有两个：数据库和API。现有的Text2SQL类产品，和我们自己的产品Chat-to-API是两个必不可少的途径。这其中我也遇到了非常多挑战，比如：
-
模型输出的不确定性
-
发API管理不完善；
-
指令理解不精准；
...
如果采用虚拟机完成开发、部署、发布，那么还会有：虚拟机环境的维护、资源调配等问题。
但我们都正在一一克服。我们相信企业的AI转型中，
API一定是AI应用与云原生应用充分融合最佳媒介，
带着这个理念，
Chat2API也在快速迭代。
到今天，
Chat-to-API已经完全颠覆了去年12月的设计。
目前，
我们正在和一家云原生公司合作，基于他们内部几百个API完成SOP任务的API编排、应用生成，在这一点上，已经能够辅助新入职程序员快速搭建应用。
同时，我们依然在招募合作伙伴，如果你的场景中希望有一个Agent能调用数以千计的API，欢迎通过公众号联系我们。您会收获一份免费的AI转型咨询，更进一步，您也可以尝试用我们的方法来解决您的业务问题。 同时感谢已经联系过的朋友们，我们近期会和大家约见demo~
最后和大家分享并和大家共勉：
以前，中国企业软件有一个共识是：企业软件只有项目，没有产品。有购买力的客户要求个性化，能接受标准化诉求的客户没购买力。
但在AI时代，也许会改变这个局面。因为AI软件的灵活性会”软件承载最佳实践“的定律，支持更灵活的SOP，那么它就能以统一的产品形态满足企业客户个性化诉求，解决toB软件在中国的商业化难题。
接下来，敬请期待！
我是关注和开发AI产品的产品二姐，致力于带来丰富的 AI 学习分享、体会，欢迎你和我一起学习，如果你觉得文章有用，欢迎关注、点赞、转发。
往期精选