预测

Manus的产品合伙人在产品正式发布之前发了一个预告的公众号内容，我做了一个预测，最后发现基本都猜中了，现在回想一下其实整个逻辑并不复杂，就像他们自己说的一样，其实没有什么秘密，只是大家好像都没有注意到一些底层技术变化带来的影响。

当时预测的逻辑是这样的：

• 公众号里面有个视频，提到了两点，一个是大家对于Agent的名称的一些滥用，非常多的产品其实完全不能叫Agent。第二点是提到了Devin
• 第一点其实很好理解，确实Agent没有明确的概念的定义，但是从2023年AutoGPT火起来的时候，关于Agent其实有个非常大的前置的前提一定是能自主地去完成任务，而不是我们后面看到的大部分的产品是需要非常多的人工的介入的。所以可以猜想到产品大概率是能自主完成任务的，有点类似2024年下半年大家看到的各种电脑或者手机自动执行任务的产品形态
• 上面这种产品有个比较大的问题，就是程序在运行的时候是需要占用用户的的电脑或者手机的，相当于用户需要看着AI干活，但是这个过程只有一长，体验就会非常不好，而Devin就就很好地解决了这些问题，给AI一个完全独立的虚拟环境，来保证AI与用户互不打扰

所以从上面的几点也基本可以推断出来大概的产品形态，虽然基于之前的信息能基本预测到，但是实际能做出来看到最终的产品还是非常惊喜的，有种仿佛看见思想的齿轮咬合现实世界的传动轴，思维星火在物质世界燎原成功

实现猜想

对Manus实现猜想分析的出发点并不是想去了解所谓的是不是套壳或者所谓的壁垒，而是希望通过分析的方式来锻炼自己对于AI的技术进展和能力边界的思考，这才是更有价值的部分。

所有的分析都是基于一些用户自己分享的案例和官方的大部分的案例，所以大概率是错的，但是对错并不重要，能促进思考和启发更加重要

Agents

在开始分析之前，我们还是需要沿着预测的逻辑看看Agent到底是什么。Agent的第一次被大众所认知，应该是在2023年3月GPT-4发布之后，几个开源项目的发布，其中最引人关注的就是AutoGPT，截止到目前，这个项目在github上的Star数是夸张的173K，当时看过相关的效果之后，最大的感触就是原来还可以这样设计和使用AI，而不是单纯地进行问答而已

当然实际体验之后我们也会发现这个项目在当时AI能力的加持下的一些问题：

1. 稳定性太差了，非常容易有些任务在规划和执行的时候进入了死循环，导致非常高的成本，毕竟当时GPT-4的价格比现在高出非常多，而如果不是GPT-4作为底层模型，可能连基本的规划任务都没办法很好完成，所以我们可以看出来底层模型的智能程度和成本情况对于Agent的影响非常大（而这正是2024年AI巨大进展的地方，推理模型的出现极大的增强了模型的规划和反思的能力，DeepSeek的各种创新也在极大的降低模型使用和训练的成本）
2. Agents对于工具的调用非常不成熟，以及能支持的工具也比较有限（特别是coding能力），由于基本完全依赖模型在提示词层面进行工具的调用，以及需要有多个模块协作来完成任务，一个环节出问题就可能导致任务失败，所以这种多Agents的架构下的任务成功率非常低，基本是不可用的程度。（工具调用在2024年也有非常大的进展，不管是基于多模态的内容识别，还是在后训练的时候基于工具调用的微调而不是基于用户对话进行微调，使得AI使用工具使用的成功率都有了极大的提升）

所以从上面的两点我们也可以看到，底层模型的智能程度和工具使用是Agent的两大基础，而这两大基础在2024年下半年都有了非常大的进展

• OpenAI O1的发布让大家看到了基于强化学习给模型推理能力带来的潜力
• claude 3.5的发布让大家看到了coding能力上的飞跃，关于coding能力的提升其实不是单纯的写代码的能力，而是更进一步的模型使用工具的能力，因为本质上工具都是可以通过coding的方式实现的，甚至我记得当前关于Agent的研究有个方向就是让模型自己基于需求来写工具而不是去调用第三方的工具，当时肯定是效果不好的，但是现在来看，我们可能已经在这么做了

当时还有一篇文章也详细的介绍了Agents的框架和相关设计逻辑，现在回看我们会发现，Agent怎么做其实一直都有方向，只是从2023年开始到现在我们不停的被各种其他的事情带偏了，而没有对于底层技术的发展引发的上层应用的变化保持足够的关注

现在仔细看之前的文章和研究看一遍，发现答案可能一直都在。当然这可能也是当前AI产品创业中最难的部分，你不知道现在不行的事情是不是什么时候就可以了，而如果你没有意识到这个事情的发生的话，你就可能会做了非常多的无用功，或者错过一切

具体案例的分析

主要的分析方式就是把官方的案例和一些用户的案例进行回看，看看里面到底发生了什么，有哪些特殊的地方，以及基于这些表现来完成产品设计层面的猜想。当前也会结合一些官方的说法来综合考虑可能的技术方向和具体的解决方案

这个过程中也发现有些官方的案例中也存在一些明显的错误情况，可能也是产品早期表现不稳定的一个表现

基于我们能看到的部分：

1. 任务是在一个独立的虚拟机环境执行的，虚拟机是linux的环境，每次都会基于任务进行单独的文件夹的新建

• 文件夹的价值应该是一个所谓的环境信息，在最终的任务交付的时候会把文件夹中所有的文件都展示给用户，同时也是模型再进行一些规划和决策时候的上下文的背景信息，可以理解是一个任务的工作环境中产生的背景内容
• 在一个任务的任务完成之后，如果用户又提出补充的需求，比如已经分析得到了一个文档的交付物，我们需要一个图表，可以看到文件夹和todo文件都会重新新建一遍（下面的图就是一个对话任务中两个文件和todo），至于这个过程是工程实现的还是模型决策，个人感觉模型自发决策的概率更高，这样人工设计的内容更少（Less structure, more intelligence）简单来说就是尽可能相信模型自己的能力，更少的干涉来发挥模型的效果

• 所以一轮对话中，用户提出新的要求之后具体的动作，是模型自己基于环境、任务情况自主决策的，可能会新建一个新的环境，也可能会直接在之前的任务环境中持续更新。所以用户的请求进入产品后第一步大概率是一个综合性的规决策模型，主要的任务目标就是进行任务的规划，看是继续执行，还是找用户要反馈，是新建文件夹还是更新todo文件的内容，全是这个模型决定的

2. 新建文件夹之后，会进行todo.md文件的新建，拆分本次任务具体的todo内容，这个内容的拆分也有几个值得注意的地方

• 同时还有一点值得关注的是，todo文件并一定是所有的子任务都执行完成了，比如上图中就存在整个任务全部完成了，但是还有两个子任务没有完成的情况。所以对于任务执行进展的判断和规划大概率是模型自己决策的，由于模型执行中可能存在不稳定的情况，所以有概率出现有些任务未执行的情况，或者可能实际执行了，但是模型进行文件更新的时候没有生效
• todo文件的机制也是为什么大家可能刚开始对于manus有质疑的地方，因为看上去还是workflow，只是这个workflow是AI生成的，不是人为预先设定的，这部分我们在后面在详细展开

• 有些对外展示的任务过程中todo文件不是一定是第一步就显示出来的，所以到底是先创建还是可能基于一些检索之后在创建可能是个问题，以及好像有任务比较简单的时候甚至是没有todo文件的。进一步的分析之后，初步的猜想还是第一步就会创建，因为我们可以看到中途更新的todo文件，每个子任务前面就已经有小的状态标识有些任务已经完成了，至于是不是一定创建这个文件，应该是主模型自己决策的，所以有理由猜测todo文件的创建和任务拆分就是主模型的能力之一
• todo文件有更新机制，主要基于拆分之后的任务执行情况进行markdow文档内容的更新，用于记录当前任务的状态和持续执行后续的上下文的一部分，可以看到下图中每个子任务前面都有一个x用来标识任务的完成情况
  
  
  
  3. 接下来就是每个子任务的执行了，这部分没有什么太特别的，大家也发现都是一些最近有比较大进展的相关能力，比如Browser user和coding的能力
  
• 所有这些能力上的进展都让工具使用变得更加高效和稳定，同时也让Agents的通用变得更有可能性，能更加泛化地完成不同的任务类型

• 用户的输入会有一个建议的新知识的选项，可以把自己对于具体任务的执行方式的的性化要求更新到知里面，比如所有的分析都新建一个仪表盘之类的

• Browser user应该是基于多模态的模型能力实现的，这种方式极大的提升了通用场景的价值，毕竟我们大部分的任务也都是通过操作浏览器完成的
• coding的能力也一样，coding不仅能处理各种文件的内容，进行文件合并分析，同时还可以把最终的展示结果进行网页形式的展示，网页可能还是可以交互的，这也极大的提升了最终交给成功的质量
  
  
  
  4.关于记忆模块，在用户提出需求或者完成任务之后都会有个memory的模块，这部分其实Monica的产品上就有对应的能力了，被很好地迁移到了Manus上，同时我认为这是一个非常被低估的能力和功能设计（很长时间以来，只有ChatGPT有对应的功能）

• 



• 我们可以在看看Monica中的记忆模块，是不是非常相似，这个功能的价值在于进一步的强化了AI大模型可以带来个性化的体验，而且是那种越用越懂你的体验，对于具体的用户而言是非常有价值的以及体验非常好的（虽然我们知道其实不是通过模型层面实现的，但是这种工程的方式也还是非常好的实现了AI最大的价值，就是给每个人带来极致个性化的体验，你的体验和我的体验不一样，你今天的体验和明天的体验可能又不一样）



实际执行的流程

基于前面分析的一些过程信息，我们可以大概的猜测一个Manus的具体框架和可能的运行逻辑

可能的框架：



• 记忆模块：

• 用户提出的任务需求，会有两个分支，第一个是去记忆模块进行记忆更新的判断
• 这里的大模型的能力需不高，只需要通过一个比较小参数的模型来判断是否要对用户的提问进行记忆内容的更新即可（Prompt应该就够，也不排除用开源模型做SFT，效率可能更高，毕竟这个模型只需要执行这个任务）
• 如果用户确认更新的话，则把对应的内容更新到记忆内容中，同时用户在具体的功能页面也能进行修改
• 更新之后的记忆内容会作为上下文的一部分持续的带入具体任务的规划和，实现个性化的任务执行的效果
  
  

• 规划和决策模块：

  这应该是Manus的核心模型，主要的任务包括：

• 用户需求分析，比如是否需要拆分todo文件，还是直接调用工具
• 如果直接调用工具的时候，可能需要RAG来召回工具的具体使用信息，不然所有的工具调用的内容都放到上下文可能会导致长度的问题
• 如果需要创建todo文件来完成具体的执行工作，这会去调用执行模块
• 执行过程中可能会有用户提出新的需求，或者有需要用户确认的部分，都是大模型B基于当前的todo文件的情况、上下文、用户的需求做出上下文来判断的，然后基于自己的决策判断来持续推进任务的执行还是抛出具体的问题给到用户
• 关于大模型B，应该是claude的概率比较大，这个模型需要比较强的规划和判断能力，所以需要一个智能程度更高的模型
  
  

• 执行模块

  执行部分其实有点不太能确认，因为理论上这部分也快成放到规划和决策模型一起，由大模型B直接基于环境上下文来进行任务拆分和执行驱动，但是不太确认放到一起应该怎么做提示词上的设计和构建，感觉有点太复杂了，需要的判断和执行的内容太多了（也可能是太菜了，不太能得清楚放到一起能怎么做），所以比较简化得就是在拆分一个执行模型出来处理。不管实际的框架是怎么样，执行模块的主要任务是：

  如果执行模块是个独立的Agent的话，可能大模型会是一个基于Qwen的开源模型进行SFT之后的大模型，需要的能力相对比较明确

• todo文件的任务内容的拆分
• 调用工具去执行对应的子任务
• 根据工具执行情况的反馈来更新子任务的状态和todo文件
• 任务完成之后把整体情况汇总给到规划和决策模块的大模型，最终给用户返回结果
  
  

• 环境上下文

  环境上下文主要是指的规划和决策模型在每一次的请求的时候所带的上下文的信息，包括记忆、与用户的对话信息、todo文件当前的执行情况、文件夹的情况等等，通过这些上下文来判断当前应该进行具体什么动作

  
  

• 工具调用：

  最后工具的调用只列出来了几个比较重要的，理论上可能会有更多的工具来辅助完成任务

• Browser user 应该就是开源框架的改造和优化，主要执行研究学习相关的任务，底层模型应该说一个有多模态能力的模型
• coding Agent应该是claude，毕竟coding能力摆在那里，主要执行的信息收集、数据分析、最终成果交付等相关任务
• 还有其他的工具可能是一些辅助性质的，比如文件解压缩、网站部署等等，集成一个常见的Linux的指令
  
  

关于RAG

应该是存储了很多工具相关的执行的知识信息，包括记忆模块，可能都是基于RAG的方式，毕竟单次任务需要用到的信息和工具可能不是全量的，这种方式可以减少模型上下文的压力，同时也进一步的减低单次执行的成本

所以官方才会说越狱了模型的提示词其实不太准确，因为你的任务不同，那最终去请求大模型的时候带的上下文的信息是不一样的，看到的可能也只是框架，并不是全部的内容

关于Workflow

这是Manus比较有争议的一点，也是我们在于OpenAI的Deep Research产品的效果对比时能感受到差异，我们用一张表来对比一下



Manus确实相当于开辟了一个新的赛道，不管是从产品的形态，还是从实际采用的技术路线，可以说是在技术发展的过程中找到了一个比较合适的契机和中间状态来把用户的体验从40分带到了60分

coze类的产品之前最大的问题就是泛用性不足以及构建Agent的门槛还是太高了，以及整个过程人为介入的程度还是太多了，本质其实还是一个人类为主的软件，人类驱动和主导。这种情况下其实是弱化了模型的智能表现的，特别是在当前技术的进程下，AI的智能程度已经超过了大部分的人类

所以通过把AI大模型做为主导来驱动Agent是个必然的趋势，当然在这个技术发展趋势下，模型和产品的边界必然会越来越模糊，两条看似不同的技术路线的目标是高度一致的，就算是Manus也不可避免的需要对模型做一些后训练来完成产品体验的提升

Manus对于模型在工具调用或者任务拆分上做的后训练的处理也带来了新的启发，就是模型的后训练对齐不一定非要面向与人类对话对齐，而可以更多的考虑面向工具调用，甚至去操作浏览器的方向去对齐

• RLHF本质是让模型在于人类交互（特别是对话）表现更加友好，包括人类能理解的表达方式，表达习惯，道德要求等等，这个方向的前提是我们认为AI的目标是更好的与人类完成对话，但是随着技术持续的进展，我们发展这个方向对于产品表现是有局限性的，chatbot有各种问题。当然不可否认面向人类对话上的对齐确实让我们能更好地了解到模型的能力和边界
• chatbot之前的问题在于很多任务的执行需要AI与环境进行交互，包括对于电脑的操作、对于各种API的调用等等，而这就是我们在后训练上需要去做的一些调整，可能有些模型的目标就不是为了更好地与人类对话，而是更好的与人类完成具体的任务需要的工具和环境进行交互。

同时从当前我们人类日常产生的数据和内容的角度可能需要更进一步的思考怎么能更好地给AI使用效率更好，之前的所有文件格式、文件夹的设计本质是为人类可读和管理服务的，而以后可能我们需要更多的考虑这些内容怎么更好地被模型消耗掉，可能之前的很多设计都是没有必要的

最近Andrej Karpathy在X上就提到的类似的观点





关于SFT还是RFT

SFT和RFT是在模型后训练阶段两种不同的技术路线和方向，不同的技术也决定了模型最终的表现和上限。

在“12 天 OpenAI 活动”第二天，OpenAI 公布了一种名为“强化微调”的新模型微调技术，最大的特点是相较于SFT的方式，有更少的数据和算力，更高的质量的特点，可能几十条数据就可以完成模型的训练过程

这个RFT的过程给人最终的感受就是一种授人以渔的感觉，就是基于结果来推理和学习过程，更多的强调的是掌握具体的方法和原理，这个方法和原理不是靠死记硬背来的，而是自己去探索和学习理解的。基于SFT的学习就会给人一种在模仿的感觉，而且是那种形似的模仿，而不是神似的模仿

所以RFT可以获得更高的上限和泛化得能力，毕竟掌握基础的原理之后，可能就可以举一反三，做出更好的决策和行为表现

监督微调（SFT）和强化微调（RFT）虽然都依赖标记数据，但应用方式各异

• 在监督微调（SFT）中，标记数据直接引导模型更新。模型将其视为目标输出，并调整参数以减少预测输出与已知正确答案之间的差距。
• 在 RFT 中，模型对标签的接触是间接的，主要用来生成奖励信号而非直接目标。因此，模型在 RFT 中预计需要更少的标记数据——模型的目标是寻找产生我们期望输出的模式，而非直接生成输出，这更有利于模型泛化。所以RFT的验证数据集是需有标准答案的，比如数学、代码都是比较好的能用于RFT的数据集

从实际应用场景的角度，SFT和RFT也有明显的差别：

• 当目标是为了使模型的输出或格式与特定数据集相匹配，或者确保模型遵循特定指令时，SFT 的效果最为显著。
• 当目标是为了模型有更好的通用性和泛化能力，以及数据量可能比较少同时也有一些标准答案的时候，可能RFT是更加合适的方式。

同时RFT还可以作为SFT的数据标注的手段，比如需要大量的SFT的标注数据，可以先用少量的数据进行RFT训练一个标注模型来辅助完成标注工具。所以两个技术本质并不是互斥的，需要基于实际的场景进行技术选择

最后我们可以用一张表来对比展示一下两种技术的差异：



对于RFT感兴趣的可以再把OpenAI发布的时候的视频找来看看，或者这篇文章，非常全面地介绍了RFT

所以关于Manus模型的后训练，个人猜测可能还是SFT居多，当前表现出来的一些套路感可能和这个也有关系。当然RFT也是2024年12月OpenAI才在12天的产品发布活动中对外发布，而且到现在都还没有正式上线，可能关于技术应该怎么做，还是有非常多的需要探索的工作（当然也不排除OpenAI处于竞争的角度决定推后这部分内容的对外发布，毕竟也不是第一次了）

产品层面的思考和分析

产品本身

如果抛开具体技术实现上的考量，Manus的产品本身确实就是非常大的创新，不管是AI+虚拟机的定位，还是在整个过程中都让用户看到整个实现的过程，都给人一种这不是我期望的AI的样子嘛

我们可以设想一下，假如所谓的AGI真的实现了，我们期望的产品是什么样子的？是不是我们就提出需求，AI自己就去干活了，碰到困难或者不确定的地方就来找我们，同时我们还可以看到它的进展情况，以及不要打扰我们自己的工作节奏，甚至越用越懂你，记忆的机制保证很多你的偏好和要求不需要重复的提出来，跟你协作的时间久了你的工作习惯也能get到了。你看这不就Manus现在的样子，所以Manus产品层面是一个具体的创新，至少把我们想象中的AGI的产品给真的做出来了

去年Claude 3.5发布之后，大家用它去解决各种问题而不是单纯的用于工程中写代码，比如教育领域生成各种交互式的网页来更好传递知识，比如制作各种精美的卡片信息比如简历、海报等等

代码能力的提升其实是一种通用能力的提升，因为代码的本质是用一种相当通用的语言去解决各种通用场景的问题，目标是背后的问题，而不是代码本身

大模型对于自然语言与代码之间的打通其实是让自然语言直接与具体的问题打通了，我们可以基于我们自然语言的需求直接去完成对应的任务了，这个变化的趋势被Manus团队敏锐的捕捉到了，coding的能力其实是极大地提升了Agent的通用性

我们可以对比一下Manus和ODR产品的一些差异，我用了一个Manus的用户案例（用户提交的一些使用案例）与Grok的Deepsearch（毕竟可以白嫖）进行对比

注意对比的目标不是比较产品的效果，而是去感受所谓的端到端的RFT模型的表现与基于工程方式实现的差异，以及在当前时间点，Manus明显是通用能力更强的，不仅仅能完成ODR产品信息检索和收集类型的任务，还可以完成一些数据处理和分析类的任务

具体的任务需求是：Can you create resources for me to learn the language telugu?（您能为我创建资源来学习泰卢固语吗？）

先看看Manus的表现：

首先是熟悉的todo list





最后任务完成之后，后非常贴心的交付一个压缩包给到用户



我们再来看看Grok的Deepsearch的情况，同时非常建议看看原始的Thoughts，这个内容可以更好的帮助我们理解端到端RFT之后的差别



• Thought中的内容可以看过是模型的思考过程，可以看到基于具体的需求，模型会去思考先做什么，用什么关键词去检索，检索之后还需要结合实际的内容怎么去思考等等，这就是端到端的好处，我们人类执行复杂的任务的时候其实不是一开始就会把整个workflow给想出来的，而是做的过程中基于反馈持续的思考和调整的，所以就算是AI自己生成的workflow，还是会有点不太自然的感觉，因为我们人类不是这么做的。而基于RFT的方式，则可以更好的学会这个持续思考和反思的过程
• Manus给人的感觉就会更加机器一点有点死板，就是反正任务来了拆分任务然后执行就好了，所有的事情好像都需要结构化，就是SFT之后的那种套路的感觉，有点类似很厉害的人可能说过自己的技巧是结构化思考，然后另外一个人就模仿这个人的做事方式，什么都结构化思考，什么时候都总分总

对于具体的对比感兴趣的可以，分别看下原始的内容，这是Manus的回答，这是Grok的回答

不过你要是看结果，很多时候可能Manus的结果是不差的，甚至你会感觉比当前ODR的效果更好，我觉得这是个边界和泛化的问题，就像我们会发现推理模型R1的回答很多时候可能都比非推理模型好，但是我们真的所有的问题都需要深度思考吗？回到Manus上，我们真的所有的任务都需要结构化思考吗？以及我们真的所有的任务都拆分结构化之后分步骤执行就可以的吗？

显然如果从更加通用的角度，我们需要的是能更底层的模拟人的思考的方式，会反思，会基于反馈改进自己的思路和方式，而不是一切都按照线性的方式进行规划执行

所以这个点其实也限制了Manus更加广泛的通用性，注意我不是说Manus不是通用的，而是可能还不够通用，后面也会展开一下关于“通用”这个点

所以单纯从产品的角度，其实Manus是非常好的创新，特别是具体的形态和表现上，满足了大家对于AGI的期待和想象，对于底层技术的进展和和场景的把握都非常精准，能很好地完成融合，特别是自己尝试去复现和设计整个框架的过程，更是能深刻的体会到

如果从技术路线的角度，明显是面临更大的挑战的，毕竟你的直接竞争对手可能就是OpenAI、巨头Google这些巨头了，后面的迭代上技术路线的选择可能也是关键，怎么能更好地把能力内化到模型层面是更有挑战的

基于模型和产品的边界趋于模糊，Manus与阿里Qwen的全面合作就显得尤为关键，合作除了更好地服务国内的用户（毕竟有合规和监管的需求），怎么能更好地与模型结合来完成产品层面体验的持续优化也是重点。技术内核上能怎么与模型结合得更加紧密是非常值得期待的，毕竟Qwen在开源模型生态和推理模型上的进展都是国内非常领先的，怎么能1+1大于2就是接下来的重头戏了




产品宣发

这也是Manus这次比较有争议的部分，我不想聊具体的细节，因为其实也算是经历了他们从最小的圈子持续破圈的过程，其实跟DeepSeek的事件有点类似，但是整个过程都有点太快了，不管是开始的出圈还是快速地反转都太快了，中间有太多的噪音了，也深刻地感受到了产品宣传这个事情很多时候是不太受到产品团体自己控制的，或者说自己能控制的只有很小的一部分而已

• 整个过程最大的感受就是媒体很多时候跟你的目标是不一致的，你的产品到了媒体的手上之后，后续的传播可能就不受控制了，特别是你还不是跟他们有合作的情况下，因为对于很多媒体而已，他们其实为他们的受众服务的，是为了那些受众的情绪服务的，而不是你的产品的宣传目标，你的产品可能只是他们的工具而已，你产品的的具体表现、实际的真实情况可能都不是最重要的部分了，这可能就是这个时代媒体宣发上最大的陷阱了
• 关于Manus产品宣发上，有个比较突出的点就是关于所谓的“通用性”。关于所谓的通用Agents的定义，从官方的视角，他们肯定是希望自己的产品定位是通用的，毕竟先发的用户心智肯定非常有必要的，同时当前的产品能力也确实是在一些场景下有通用的能力表现，所以产品宣发视角可能是没啥问题的，你换个其他团队，如果是一样的产品，大概率可能也是这么个定位。但是大众对于通用的期待和理解明显不止于此，我们期望更加泛化和通用的场景的覆盖，这个可能就跟技术路径有关系了。
• 可以看到Manus当前能完成的任务还是比较有特点的，数据分析、信息收集和整理、市场调研等等，这些的特点就是基本只需要依赖互联网就可以完成，同时可能都是比较线性的流程，也不太需要与外部的用户或者其他人有更多的交互，所以显然这是不能覆盖大众所期望的通用的，当前这个定位本身没有什么问题，毕竟他们的目标肯定也不是单纯的完成当前这些任务类型而已

壁垒问题

不知道是不是受到上一轮互联网创新和创业的影响，大家对于当前AI产品和应用的进展总是特别苛责，上线第一天就喜欢去质问壁垒是什么？好像第一天就期望看到终局一样

但是终局是非常难预测的呀，不知道有多少人还记得小红书刚开始是做什么，谁能想到他们会变成今天这个形态和生态位置呢？事情是做出来的呀，壁垒其实也是一样的，没有什么是你做的第一天就有壁垒的。当然对于壁垒的思考是产品团队需要思考的，但是我觉得不是从所谓的壁垒的角度去思考，而是怎么能给用户持续交付更好的体验和和价值，这是不变的核心，这才是一切根本

下面这个观点也是对于这个事情和壁垒比较好的阐述

Manus 有点像当年的理想one，用一种技术上来看略显蹩脚的手段，证明了一个庞大用户需求市场的存在。 就像理想定义了无续航焦虑+冰箱彩电大沙发的家庭汽车，Manus 也奠定了未来 3 年内AI应用的产品方向




展望未来

最后我们可以来展望一下未来，今年年初DeepSeek开启的RL的新路径到Manus对于Agent的呈现都让我们对于2025年的AI的持续进展充满希望

从Manus的角度肯定是机遇和挑战并存的

• 与模型厂商的直接竞争

虽然我们还叫Manus是AI应用，OpenAI发布的是底层模型，但是明显感觉到边界在越来越模糊，ODR就不仅仅是个产品，还是一个模型，是一个o3的RFT版本

深度研究模型由针对网页浏览优化的早期版本 OpenAI o3 提供支持，该模型学习了核心浏览能力（搜索、点击、滚动、解析文件），并通过对这些浏览任务的强化学习训练，学会了如何推理以综合大量网站信息，找到特定内容或编写全面报告，类似于 Deep Search，Agent 必须在内部执行目标任务：它们"动态指导自己的过程和工具使用，控制完成任务的方式"。

当然Manus与阿里的合作也是在借助更多的力量展开竞争，开源模型、DeepSeek的R1毕竟是在RL路线上的第一代的版本，所以我们有理由期待底层模型和后训练上持续地进展，能对于Agent的表现有多的加持

• 更广泛的场景和通用性

当前Manus完成的任务还是比较偏一个人有一台电脑就能完成的场景，但是我们有更多的场景是需要与人协作完成的，很多工作不是独立完成的，Agent怎么与其他人协作，甚至你的Agent怎么与别人的Agent进行协作都是值得我们期待的

• 更低的门槛和更多的上下文的结合

最后还有一点就是关于上下文的和外部环境信息的获取，虽然现在Manus可以上传文档，可以去定义一些任务完成的偏好信息，但是这样还是门槛太高了，对于我们实际使用的时候还是体验不是那么好的




想象一下，假如AI不仅能控制自己的电脑，还能看到用户的电脑和资料信息，同时能智能的判断哪些资料和信息是当前的任务需要的，而不是靠用户自己的选择和上传，是不是能更好地完成更广泛的任务，如果真的可以到这种程度，可能就真的不是我们在驱动AI了，AI不需要我们提出一个问题和任务才能给我们一个回复，而是随时随地与我同在，看到我们所看到的，然后更加自主的去完成相关的任务解决相关的问题




最后还是想补充一句，你真的尝试去思考、设计其他产品的实现过程，你才会理解和感受 评价比实际去做容易太多了

所以不要太多的关注所谓的是不是套壳，是不是有付费宣传之类的，什么几个小时开源复现等等，那些都不重要，你能把产品做出来解决用户的问题才是重要的

希望大家都可以少些噪音，多些自己的思考，当然我想强调一遍，对于Manus的实现思路的思考也完全是自己的猜测，大概率是错的。





思考的过程更重要，结果不是那么的重要