冰山 | Manus 的 40 问：先天营销圣体，还是下一代硬实力冠军？
原创 脑洞研究员 脑洞航海家 2025年03月07日 14:30 上海
引言：从早晨的「国运级创新」，到下午的争议塌房，Manus 的风评在 24 小时内坐了一趟过山车。让事件无法很快平息的原因，除了夸张的营销噱头，还有期货式的发布方式——在几大自媒体「AI 顶刊」之外一码难求，许多人都好奇：这到底是三人成虎的剧本，还是厚积薄发的故事？
本文由 Accunote.ai 整理自昨日一场关于 Manus 的行业研讨会。
打开你的脑洞
—————— · ——————
本文阅读时间约为 25 分钟
Q1：Manus 在生成报告方面的亮点和优势是什么？与其他 AI 工具如 Pipeline 或 OpenAI 的 deep research 相比，有哪些特点？
首先，Manus 会为任务列好任务清单 check list，意味着他做完一步会非常实时告诉我做完了，会打上勾。
第二个亮点是他会做数据验证以及交叉引用，很多 deep research 工具都有个问题，他只会去查一遍，查好了这个数据以后直接引用。对很多数据不准或者造假，生成的报告其实不太好。这里他很大程度上确保了准确性，即使只提供简单的 prompt，也能够比较准确地给出公司历史、商业模式等信息。
第三个亮点，Manus 使用虚拟环境，可以理解为在 Manus 服务器上运行的虚拟机或电脑。AI 与这个虚拟环境交互，发送命令并执行操作。这种方式相比其他深度搜索工具有明显优势，能够执行更复杂的任务，具有更大的想象空间和功能扩展性。
第四个亮点，Manus 所有交互都是可追溯的。用户可以查看整个报告生成的过程，包括浏览器搜索信息、访问不同网站等所有步骤。这些片段和最终报告都会保存在云端环境中。和 Devin 一样，但是体验感比 Devin 好得多。
第五个亮点是 Manus 生成的报告具有良好的可读性和用户体验。比如 Pipeline 生成的报告虽然详尽，但是读起来非常吃力。Manus 生成同样一份 17 页的报告，包含封面、目录等结构化元素；PDF 格式的目录可以进行索引，方便用户快速导航和查找信息。
第六个亮点，Manus 的分享功能非常出色。用户可以通过链接分享整个报告生成过程和最终报告，实现了完全的可视化。在交互设计方面，Manus 做得非常出色，界面元素使用恰到好处，包括图标、加载动画等都很合理，没有多余或奇怪的设计。整体用户体验非常流畅自然。
Q2: Manus 在处理用户需求时有哪些特点？包括任务清单、数据验证和交叉引用机制，以及其虚拟环境的运作方式与其他工具有何不同之处？
Manus 的工作流程分为三个主要部分：planning、research 和 generate。其中 AI 在planning 和 research 阶段发挥最大作用。generate 阶段相对固定，主要用于生成文本、PDF 或组装 PDF。
在工具使用方面，Manus 主要需要两个工具：Web search 和 PDF 组装器。然而，Manus 的优势在于它不仅限于这些预设工具。它具有更强大的功能，包括浏览器（用于 Web search）、Linux 系统和编程能力。这三个核心元素使 Manus 能够创造更多可能性。由于有了 Linux 系统，Manus 拥有了文件系统；结合编程能力，Manus 可以基于文件系统创建各种类型的文件。这种灵活性使得 Manus 可以使用更多样化的模型，如适合 coding 的 Claude，或适合数据处理的 OpenAI、千问等其他模型。
Manus 最终生成的不仅仅是单一的报告，还可能是应用程序或网站。它能够构建自己的工具，而不仅仅依赖于预设的 Web search 工具。例如，Manus 可以使用 Python 自行生成 PDF 生成器，将 Markdown 文本转换为 HTML 模板，再生成 PDF，甚至还能考虑到中文支持等细节。
Q3: Manus 在文件处理、网页浏览和生成文件方面有哪些优势？以及它与 Devin 有哪些异同？
Manus 不仅限于处理 PDF 文件，还可以处理 PPT、Excel 等多种文件格式。与ChatGPT 或 Chat Excel 等工具相比，Manus 不需要预置特定的生成器，而是拥有更灵活的虚拟环境。在这个环境中，Manus 可以自行编写代码来创建所需的工具，从而实现更广泛的目标。这种灵活性远超其他 AI 工具。
Manus 配备了文件系统和浏览器功能，这大大增强了其功能性。与仅通过 API 获取文本信息的 deep research 不同，Manus 的浏览器功能更为先进。
Manus 使用的 Linux 系统虽然有一定局限性，但足以满足大多数生成环境的需求。它可以生成简单的网站、小型 APP 或报告等内容。这种基于 Linux 的环境为 Manus 提供了强大而灵活的操作基础。
Devin 在许多方面与 Manus 相似。它们都具备类似的环境设置，包括浏览器、shell （控制台）和编辑器。Devin 的 shell 功能类似于控制台，可以执行多种 Linux 系统命令。Devin 还包含一个 planner 功能，这一点与 Manus 相似。然而 Devin 的 planner 训练更侧重于通用规划，而不仅限于代码编写。与 Devin 相比，Manus 在执行命令方面更加灵活，不需要预装许多专业的开发环境，因为它更多地关注于生成普通用户可以使用的内容。
在演示中观察到，Manus 使用了一种特殊的 API，可能是 accessibility API。这种 API 通常用于辅助视障人士，能够自动提取网页上的文本内容。这使得 AI 能够从人类的角度理解网页内容，尽管这一观察还需进一步确认。
Q4: Manus 的单次请求成本和资源消耗情况如何？
Manus 单次请求可能需要上百万 token。测试的每个子任务大概都有 3-5 个步骤，用到最多的 token 的就是前面步骤，前面的步骤要在互联网上获取 Web search 结果，作为 input 的 token 输进去，估算了一下估计有几十万 token。生成的 token 不多，更多是一个简单的报告，后续的 coding 其实 token 也不会很多，用到 coding 其实是非常简单地执行这些命令行。
按照 Deepseek 的价格计算，每次请求可能花费十几元人民币。
此外，Manus 还需要沙盒环境，这会占用 CPU 资源。一台物理服务器大约可以同时承载 100 个沙盒环境。与传统的 Deep research 相比，Manus 不仅占用 GPU，还需要 CPU和 内存资源来运行沙盒环境和网站。
Q5: Manus 生成报告的效果如何？能否举例说明？
Manus 生成报告的效果很好。以小米 13 Ultra 手机的评测报告为例，Manus 生成的报告简洁明了，一目了然。报告突出了关键信息，如竞品对比、性能参数、赛道表现等，并进行了加粗处理。相比之下，其他工具生成的报告可能内容冗长，难以快速抓住重点。Manus 能够准确理解用户需求，生成有针对性的内容，如小米 13 Ultra 作为高端手机，报告中就包含了赛道表现这一章节。总体而言，Manus 生成的报告能够快速传达用户所需信息。
Q6: Manus 与传统工具在任务执行时间上有哪些差异？
Manus 在任务执行时间上与传统工具存在较大差异。传统的 deep research 工具通常只需 1-2 分钟就能完成一次任务。而 Manus 生成一份报告平均需要 30 分钟，有时甚至更长。例如，生成小米 13 Ultra 的评测报告花费了 30-40 分钟。
此外，由于资源消耗较大，Manus 的服务器可能会出现不稳定的情况。例如，在尝试生成寒武纪的研究报告时，就因为 CPU 资源不足而无法完成任务。
Q7: Manus 产品是基于 Cloud Computer 使用 Open AI 和 Operator 加上 CoT 吗？
Manus 并不完全是这样的组合。它更像是一个 Operator 加上 OpenAI 的 assistant。OpenAI 的 assistant 运行在一个沙盒环境中，可以生成各种工具。Operator 主要处理浏览器的需求。与 OpenAI 或其他类似产品相比，Manus 在任务规划方面做得非常出色。它对任务的切分非常细致，这是许多竞品没有做到的。
Computer Use和 Operator 本质上是更大的两件事。它们实际上想要取代的是 RPA ，但希望比原来的RPA更加自动化。传统的 RPA 可能是使用按键精灵或预定义好的路径，例如从特定文件夹读取数据，从系统读屏，然后将数据粘贴到 Excel 中来完成固定的任务。相比之下，Operator 和 Commit Use 本质上更加灵活。
对 Computer use 和 Operator 有几个观点：① 它们希望能够有更多的应用场景。从 AGI 的角度来看，创造商业价值的方式可能是替代大量白领工作。由于白领主要使用电脑工作，理论上如果能够将处理器和 U 盘结合使用，就可以替代白领工作。② 它们本质上是一个相对封闭的沙盒环境。所有的流程和操作都是多模态的，有明确的处理过程，最终会产生结果。这整套系统可以提供更多的数据来训练下一代强化学习算法。③ Computer Use 对于 Manus、Deep research 或 Devin 来说，是一个更大的范畴。它涵盖了更广泛的应用和可能性。
从开发者的角度来看，对于编码场景，我更期望的是 Copilot 而不是 Manus。但对于一些简单的任务，如制作报告，Manus 的全自动化功能非常有吸引力，因为它可以节省大量时间。
Q8: 如果 Anthropic 的 Claude 被认为是工程化的胜利，那么是否可以理解 Manus 是产品化的胜利？这种体验一旦固化，能否形成壁垒？是否容易被对手追赶上？
Manus 实际上没有任何技术壁垒。它本质上是一个超级 APP 的工厂，使用的技术都非常成熟。例如，沙盒技术已经被多家公司如深信服、微软和 Cloudflare 等成熟应用。对于交互设计，像字节跳动这样的公司非常擅长。因此，开发类似 Manus 的产品在技术上并不困难。
预计在接下来的一两个月内，市场上会出现许多类似的垂直领域或通用型 agent，可能使用相同的技术栈。与模型开发相比，这类产品的技术壁垒要低得多。
Q9: Manus 目前经常出现卡死和使用问题，这是由于 GPU 不足、多个沙盒的 CPU 不足，还是其他原因造成的？
这个问题很可能不是由 GPU 不足造成的，因为现在使用的 API 都是 SaaS 服务，如千问或 Cloud，它们的算力应该是足够的。问题可能出在沙盒环境上。
对此，Manus 可以考虑以下改进：① 开发本地 APP 版本，在用户设备上创建沙盒环境，减少对云端环境的依赖，从而节省 CPU 使用；② 改进交互流程，例如在接收到用户需求后，先展示完整的执行计划，让用户确认每个节点后再开始执行，这样可以大大减少运行成本和 CPU 使用。③ 目前的交互方式可能导致不必要的资源消耗，如生成不符合用户预期的报告。应该让用户更精确地定义需求，然后再开始执行任务。这些改进可以帮助 Manus 提高效率，减少资源浪费，并提供更好的用户体验。
Q10: Manus 与 GPT-4.5 的结果相比如何？Manus 是否采用了一些特殊技术来控制长流程任务的成本？
Manus 和 GPT-4.5 并不是同一类产品，无法直接进行比较。GPT-4.5 是一个基础模型（Base Model），而 Manus 是基于 GPT-3 的一个经过长期微调（Fine-tuning）的版本。GPT-4.5 更多地在情商方面进行了改进，旨在解决当前 AI 回答缺乏人性化的问题。GPT-4.5 的目标是引导对话朝着更具情感化的方向发展，这对未来的机器人、具身智能和情绪陪伴等应用来说非常重要。
从技术角度来看，Manus 是基于 GPT-3 的一个经过深度微调的版本。相比之下，GPT-4.5 可以被视为一个新的基础模型。如果要进行类似的比较，更合适的做法是将GPT-4.5 作为基础模型，然后通过强化学习（RL）进行推理能力的提升，再进行微调，最终得到的产品才能与 Manus 进行对比。这个过程类似于从 GPT-3 发展到 Manus 的过程。Manus 和 GPT-4.5 并不是同一类型的模型。GPT-4.5 被认为是一个偏向文科的模型，而 Manus 则被视为一个偏向理科的模型。这两者在设计目标和应用领域上有所不同。
关于长流程任务的成本控制，Manus 声称单任务成本不到 2 美元。他们采用了一些策略来实现这一目标：① 在代码生成等特定任务中使用 Claude 模型，这些任务实际上消耗的 token 数量较少。② 主要的 token 消耗来自于处理和比对网络搜索结果。③ 使用千问等较为经济的模型来处理大部分任务；尽管千问的 32B 模型价格可能是 Deepseek 的 10 倍，但总体成本仍然相对较低。④ 可能使用了一些自行训练的模型或进行了模型微调。⑤ 将任务切分得非常细致，使得即使较小的模型也能很好地执行和理解任务。
Q11: 未来 CPU 和内存的重要性是否会提升？
对于未来 CPU 和内存重要性的问题：① 随着 AI 应用的发展，可能会更多地使用虚拟机在 CPU 上运行环境。② 许多操作可能需要缓存在内存中，这可能会增加内存的重要性。③ 目前还不能确定这是否是一个过渡形态，还是长期趋势。
总的来说，Manus 通过精细的任务分解、合理的模型选择和高效的资源利用，实现了较低的运营成本。同时，它的技术路线也展现了在特定领域（如网站生成）的独特优势。至于硬件资源的未来重要性，这可能取决于 AI 应用的具体发展方向和计算需求的变化。
Q12: Manus 的产品未来可能会采取哪些模式？虚拟机在其中扮演什么角色？在企业级应用方面有哪些潜力和局限性？这些因素如何影响产品的未来发展？
Manus 的产品未来可能会采取两种模式。对于小白用户或需要在手机上生成报告的用户来说，更理想的环境是线上的沙盒环境，需要使用 CPU 和内存。另一种模式类似于 OpenAI 的 CLI（命令行界面），用户可以选择使用本地 CLI，这可能是一种更低成本的方式。
如果用户下载客户端，可能会更便宜一些。这相当于下载一个 Manus 的客户端 APP，安装后会建立沙盒环境。本质上，这与安装浏览器类似，因为浏览器所有的文件都放在一个 cache 文件夹里。Manus 的客户端也会将所有生成的文件放在一个独立的文件夹下，在那个环境中进行生成操作，不会污染用户的电脑。
关于虚拟机，它主要是为了让用户更方便地生成内容。虚拟机的成本实际上并不高。市场上有很多在线 Linux 沙盒环境，这类环境的成本应该不高，因为主要运行的是一些 Python demo。虚拟化的需求可能会增加，但主要是为了提供更便捷的使用体验，而不是因为成本考虑。
从行业影响的角度来看，Manus 最有可能替代或优化的领域是从互联网搜索信息并整合的工作。这类似于搜索引擎擅长的领域，但 Manus 这类公司可能会做得更好。例如，在生成报告方面，Manus 可能会比现有的搜索引擎做得更出色。这意味着某些行业，如投资银行中需要生成研究报告的工作，可能不再需要实习生来完成。这种变化有可能发生，Manus 等 AI 代理可能会大大提高这类工作的效率和质量。
Manus 在企业级应用方面具有很大潜力。它具备三个环境场景，其中前两个（电脑和浏览器）大多数人都可以使用，但第三个环境（代码编写）是大多数人无法实现的。Manus 能够自主编写代码，制作各种工具，完成复杂任务，这为企业应用提供了巨大的想象空间。将 Manus 部署在企业内部，协助完成工作流程，有非常多的切入场景。
然而，Manus 也存在一些局限性。首先，它的沙盒环境非常有限，无法生成大型应用程序。例如，生成安卓 APP 需要依赖大量编译环境和 SDK，Manus 可能无法完成或效果很差。其次，在复杂的视觉场景方面，由于语言模型主要基于语言和视觉，Manus 在审美能力上还难以替代设计行业等专业领域。尽管如此，Manus 在企业内部应用方面仍有很大潜力。目前可能还处于研究阶段，但未来可以逐步应用于企业内部工作流程。虽然具体的应用场景可能还需要进一步探索，但 Manus 在企业环境中的应用前景是非常广阔的。
Q13: Manus 的 Planning 功能如何实现？它是否具有通用性和智能性？生成高质量报告是否依赖于特定的系统提示或预定义工作流？
Manus 的 Planning 功能表现不错。从小米报告的生成来看，Manus 的能力已经很强了。Manus 在分析小米时列出了 37 个步骤，相比其他 AI 助手，Manus 的思考过程更加细致和详细。
Planning 过程可能是 Manus 的一个重要壁垒，他们可能有自己的专有模型或方法，不太确定仅通过调整提示就能实现同样的效果。总的来说，Manus 在 Planning 方面的表现比其他同类产品要好。
Q14: Manus 官方称这是一个多 agent 系统。这个系统包含哪些 agent？这些 agent 使用的模型规模如何？是否需要微调或额外训练？
Manus 的任务执行似乎主要是线性进行的。虽然官方称之为多 agent 系统，但在演示中并没有明显看出多个 agent 并行工作的迹象。
不过，我们可以从另一个角度理解多 agent 系统：每个 agent 负责不同的任务，如生成研究报告、编写代码、执行命令等。从这个角度来看，Manus 可以被视为一个多agent 结构。至于并行处理，可能在某些步骤中存在，比如同时进行多个搜索，但在整体流程中并不明显。
OpenAI 的 Noam Brown 在做 multi-agent，可能是未来 GPT-5 或 GPT-6 的发展方向，实现真正的 self-play。这不是单个模型的自我互搏，而是多个 agent 之间的互动，以提高自身的明确性。
Q15: Manus 在执行过程中是否允许用户干预？如果发现方向不对，能否中途停止或调整？
根据目前的观察，Manus 存在一些局限性。一旦用户输入任务并开始执行，Manus 就会在后台持续运行，没有提供中途干预或停止的选项。这与一些其他 AI 助手（如Auto-GPT）形成对比，后者允许用户在执行过程中进行干预。这可能是 Manus 未来可以改进的一个方面，增加任务执行过程中的交互性和可控性。
Q16: Manus的出色表现是否主要归功于其底层模型的代码生成能力的提升？
Manus 的优秀表现不仅仅是因为底层语言模型（Claude 3.7）的代码生成能力提升。虽然 Claude 3.7 在某些方面比 3.5 有所改进，特别是在开发人员和程序员能感知到的领域，但对于 Manus 执行的这种通用任务来说，并不需要特别强大的代码生成能力。事实上，即使使用 GPT-4 或其他类似的大型语言模型，也可能生成类似质量的代码，因为这里涉及的代码量并不大。
Q17: Manus 是否具备主动询问和二次确认的功能，以明确用户的问题或需求？
是的，Manus 具备这种功能。它能够主动询问用户，进行二次确认，以确保准确理解用户的问题或需求。这种交互能力有助于提高任务执行的准确性和效率。
Q18: Manus 的通用性体现在哪些方面？
Manus 的通用性体现在多个方面。与仅能进行编程相关任务的其他工具相比，Manus能够执行更广泛的任务。例如，它可以生成 PPT、视频，甚至进行视频格式转换。传统方式下，用户可能需要寻找特定网站或付费 APP 来完成视频格式转换。而使用 Manus，用户只需将视频发送给它，Manus 就能编写视频转换的小工具，完成转换并返回结果。这种多功能性使 Manus 在各种场景下都能发挥作用。
Q19: Manus 的中枢 agent 或 planning agent 使用的是什么模型？开源模型能否实现这种规划能力？
根据公开信息，Manus使用的基座模型是千问加 GPT。然而，基座模型并非核心。Manus 可能使用半年前的模型也能实现其功能。例如，生成简单报告的任务并不需要非常强大的模型，使用千问甚至 Llama 这类模型都可能完成。这是因为 Manus 将任务分解为非常清晰、具体的子任务。每个子任务可能只是生成一段代码或执行一个明确的查询。AI 将大任务切分为小任务后，完成每个小任务的准确度会大大提高。
Q20: 用户在 Manus 的运行过程中能否进行控制或干预？
Manus 在运行过程中不允许用户直接干预。但是，如果用户输入的指令不明确，Manus会与用户进行交互。例如，如果用户表示想要创建一个网站，Manus 不会立即执行，而是会询问用户想要什么样的网站，要求用户提供更详细的描述。只有在用户提供了足够的信息后，Manus 才会开始执行任务。这种交互方式确保了任务的准确性和用户需求的满足。
Q21: 沙盒环境的概念是什么？
沙盒环境本质上是利用 Linux 内核的命名空间概念实现的。在 Linux 系统中，可以建立独立的命名空间，每个命名空间对应不同的驱动、系统、文件系统甚至网络。这种设计使得像阿里云这样的服务提供商能在一台物理服务器上运行几十个甚至上百个虚拟服务器。与 Windows 的用户切换不同，Linux 的这种隔离是完全的，用户无法看到其他命名空间的文件。
使用沙盒的主要目的是保证一个完全隔离的环境。虽然也可以直接在物理服务器上运行 Linux，但为了降低成本，通常会在一台服务器上运行多个沙盒环境，同时提供给多个用户使用。Sandbox 技术已经存在很长时间，网上可以找到很多相关资料。
Q22: Manus 的推理过程是否可以修改？Manus 的产品体验优化在多大程度上是由于整个推理模型的出现而带来的？
实际上，推理模型并没有给 Manus 带来任何实质性的收益。目前完全可以使用预训练模型来完成相关任务。推理模型本质上是通过 CoT（思维链）方法逐步拆解任务，其训练过程仍然基于后续的思考过程。但实际上，不需要严格遵循这些步骤，可以使用简单的预训练模型，通过手动生成步骤来完成任务。甚至在网页浏览和操作的步骤当中，使用传统 RPA 就可以做得很好。
例如，第一个 prompt 可以要求 AI 拆解任务，将任务拆解得尽可能细致。这种拆解不需要专门的推理模型，预训练模型就能很好地完成。至于具体的执行过程，这是Manus 需要设计的部分，这个环节相当复杂。planning 阶段也很复杂，甚至可以让 AI 来编写 planning 的内容。即使使用简单的模型来做 planner，帮助拆解任务，也可能达到同样的效果。
后续的工作主要是工程化的过程，需要将每个任务对应的执行步骤在浏览器中链接起来，将输出结果汇报给 AI，让 AI 进行 debug 和错误报告。这个 workflow 需要结合传统操作系统，整个过程非常复杂。
Q23: Manus 的产品是否类似于有可视化界面的 Code Interpreter？
Manus 的产品有些类似于可视化界面的 Code interpreter，这与 OpenAI 的 assistant API 有相似之处。Code interpreter 运行在一个沙盒环境中，能够执行一些基本的脚本，是一个 Linux 环境，可以进行基本的格式转换等操作。
但 code interpreter 通常是单次操作，即上传内容，进行格式转换，生成结果。而 Manus 的工作流程更加复杂，不仅仅是单次的操作，而是一个持续的过程。目前 Manus 的工作流程中可能存在一些冗余环节，特别是在 APP 升级方面有优化空间。
Q24: Manus 目前的工作流程中有哪些可以优化的冗余环节？
Manus 当前工作流程中一个明显可以优化的点是其服务器使用方式。目前 Manus 使用浏览器进行 Web 搜索，而不是直接使用 Web search API，这可能是最耗时的环节。Manus 似乎在浏览器中使用视觉分析，这个步骤可能有些冗余。例如，在某些情况下，浏览器可能会遮挡部分内容，导致无法通过常规 API 获取完整信息。而使用传统的代码检查方法，从源代码或返回结果中，实际上可以获取到更多内容。
Manus 可能是为了给用户一种高级感，展示它在使用浏览器进行查询的效果。但实际上，在内部可能仍然使用 inspect 或 search API 来完成这些任务。这种方法可能会导致一些效率问题，特别是在服务器负载较高的情况下。
Q25: Manus 对 Perplexity 等 AI 搜索产品的影响是什么？是否打开了新的场景？
对 Perplexity 等 AI 搜索产品，Manus 可能会带来一些影响。Manus 的 pipeline 可以生成报告，试错成本也很低。但 Manus 在时效性上可能并没有明显优势，可能只能将 30 分钟的时间缩短到 10-20 分钟，这个速度仍然有些慢。因此，Perplexity 等产品可能会尝试开发类似 Manus 的功能，但仍会保留原有的深度研究能力，因为生成报告仍是大多数用户的主要需求。
Manus 目前的不足之处在于数据源或 planning 阶段做得不够好，导致生成结果质量不高。这些问题值得其他产品借鉴和改进。
Q26: Manus 的报告目前是否有付费功能？
Manus 的服务仍然是免费的，还没有开始收费。不过未来可能会开始付费。但是现在网站已经无法访问了。
Q27: Manus 在规划的颗粒度上是如何平衡 CoT 和搜索的？为什么它的规划做得很好？
Manus 在规划方面做得不错，但具体是如何实现的还有待进一步了解。这可能涉及到Manus 的核心技术能力，目前还不太清楚具体的实现方式。
Q28: 像 Manus 和类似 Dify、Coze 这样的产品在满足复杂业务需求方面，比如端到端业务流程自动化、多轮对话和跨模型能力编排，各自的优势和瓶颈是什么？
如果 Manus 能够进行前面提到的改进，比如能够根据用户需求（如「小米最新手机值不值得买」）生成类似 Coze 那样的工作流，并让用户确认，那么 Dify、Coze 等产品可能就失去了价值。
Manus 的优势在于它可以将复杂任务分解成更细致的步骤，并能准确执行。如果Manus 能够实现这一点，其他类似产品可能就难以与之竞争。
Q29: Manus 的 agent 任务以小时计，涉及 GPU 和互联 HBM 的问题。很多人关心它是如何将大任务拆分成小任务的，尤其是如何做到细致和准确。是通过模型还是规则来实现这些差异点的？
Manus 将大任务拆分成小任务的能力令人印象深刻，但具体实现方式还不清楚。可能有以下几种可能：① 针对不同任务有预设的模板，直接按模板拆分；② 可能使用了专门训练的 reasoning 模型，类似于训练推理模型那样，能够很好地描述每个步骤；③ 也可能有其他工程化的解决方案，能够将每个步骤写得非常详细。这个问题值得技术团队进一步探索和研究。
Q30: Manus 使用的是哪个模型，特别是在图片生成方面？
具体模型目前还不清楚。有人推测最后的图片生成可能使用了 DALL-E，因为生成的图片风格很像 DALL-E 的作品。但这只是推测，还需要进一步确认。
Q31: Manus 的关键区别在于对虚拟机的应用，从而实现更丰富的拟人操作功能。是否有其他应用采用类似的部署方式？
Manus 的部署方式包括基础大模型加上沙盒环境和虚拟机，这使得它能够执行更丰富的操作。类似的部署方式在其他应用中也有出现，比如 Devin。Devin 已经推出约两年，其核心能力与 Manus 非常相似，包括进度条、障碍回溯等功能。
Q32: Manus 目前主要输出报告，有没有跑程序、做工作或旅行规划的案例？另外，Manus 的 CPU 使用情况如何？
关于 Manus 的应用案例，网上有一些跑程序、做工作或旅行规划的例子，大家可以去查看。至于 CPU 使用情况，Manus 的任务调度会更多地使用 CPU。与传统的主要依赖 GPU 的 AI 应用不同，玛瑙斯替代了许多原本就在 CPU 上运行的工作。
如果最终它能替代大部分此类工作，CPU 的使用可能更像是「自己替代自己」，而不是像 GPU 那样带来增量需求。
Q33: 关于 AI 数据中心的选址、处理过程的存储位置以及玛瑙斯的未来发展，有哪些看法？
对于 AI 数据中心选址，由于延迟要求降低，可以选择离用户更远的地方。关于处理过程的存储，很可能会在云端进行备份。这样做虽然会增加闪存使用，但能确保数据安全，避免断线后需要重新计算，这样做更经济。通常这类系统会有断点续传功能。
Q34: Manus 未来能否作为一类操作系统，类似于一个聚合agent的系统？
Manus 有潜力成为一种类似操作系统的平台，可以调用和聚合其他 agent。这种系统可能会成为未来 AI 应用的一个重要发展方向。
Q35: 关于 Manus 的多模态理解能力，特别是在处理图片和其他非文本内容方面，有哪些看法？
Manus 在多模态理解方面还有提升空间。目前如果仅使用 HTML 来读取网页内容，在处理图片等非文本内容时可能会有局限性。未来很可能需要进一步提升多模态理解能力，以更全面地处理各种类型的信息。
Q36: 作为一个 builder，如何规划 Manus 的结构规则和泛化能力？特别是在生成报告方面，是否应该有固定的模板，还是应该更加灵活？
Manus 在生成报告时使用了一些模板。目前系统在某些方面可能还是比较固定的。作为 builder，需要在结构化规则和泛化能力之间找到平衡。固定模板可以确保输出的一致性，但增加灵活性和泛化能力也很重要，这样可以适应更多样化的任务和需求。
Q37: 关于 Manus 的幻觉问题和数据处理，有哪些看法？
幻觉是当前 AI 系统面临的一个问题。例如，有报告错误地将 Manus 描述为「武汉夜莺公司的 agent」，实际上这是肖弘的上一家创业公司。在 agent 写报告的场景中，幻觉对其影响不大，写报告的本质不是利用底座模型的知识，而是使用 Web 搜索获取的信息进行拼装。如果出现幻觉，很可能是原始引用就存在错误。大模型在这个过程中主要负责任务规划、代码编写以及组装工作，而不会询问自身的知识库。
对于多个数据来源口径不一致的情况，理想的做法是在产品中显示数据差异和选择过程，让用户了解信息的来源和可靠性。当然，也可能是参考的网站本身就有错误信息。未来，改进数据验证和交叉检查机制将是提高 AI 系统可靠性的重要方向。
Q38: MCP 协议是否适用于多环境处理？
MCP 本质上是让大模型外接更多能力，如外接管理控制台和数据。在这个架构中包含了许多 MCP 的规范和协议。从整体架构来看，有相当一部分内容涉及了 MCP 的应用。这种架构允许大模型更灵活地与外部环境和资源进行交互，提高了系统的扩展性和功能性。
Q39: 有人说 Manus 针对一些高频场景提供了固定的工具链给 agents 调用，这种说法是否属实？
Manus 在这方面做了一些工作。工具的积累会逐渐形成工具链，这可能成为公司的一个优势。例如，如果在预设的沙盒环境中已经安装了 PDF 生成器等工具，就可以直接调用，无需编写额外代码，从而节省 coding token。这类似于云服务器预装软件的概念。
然而，这种预装工具可能不会成为绝对的竞争壁垒，因为它更像是一种便利性服务，类似于阿里云预装各种服务在云服务器上。这种做法可以提高效率，但不太可能成为决定性的竞争优势。
Q40: Manus 会启发什么新的投资方向？
中国在产品和应用方面的能力很强。如果国家有政策支持，提高 toB 和 toC 的支付能力，将会有很大机会。各种软件应用，特别是优化人力和流程的软件，在中国也有较大的发展空间。
Manus 由 Monica 公司研发，此前推出的浏览器插件产品 Monica 已获得超过 1,000 万美元的年度经常性收入（ARR）。
原文链接：https://blog.csdn.net/sinat_37574187/article/details/146102012?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522a84a537e317e6cd390e98a522b805663%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=a84a537e317e6cd390e98a522b805663&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-10-146102012-null-null.nonecase&utm_term=manus
