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编排、应用生成，在这一点上，已经能够辅助新入职程序员快速搭建应用。
最后分享一段共勉的话：
以前，中国企业软件有一个共识是：企业软件只有项目，没有产品。有购买力的客户要求个性化，能接受标准化诉求的客户没购买力。但在AI时代，也许会改变这个局面。因为AI软件的灵活性会打破“软件承载最佳实践”的定律，支持更灵活的SOP，那么它就能以统一的产品形态满足企业客户个性化诉求，解决toB软件在中国的商业化难题。
接下来，一起期待吧。