半年内收入翻倍不止，巨头夹击下的Manus和Genspark跑通变现

封面图片由AI生成

殊途同归。

2025 年 3 月，「Manus」突然将 Agent 的概念带火，邀请码一度被炒到 10 万元以上；紧接着，由前百度副总裁、小度科技 CEO Eric Jing 开发的 AI 搜索产品「Genspark」也宣布转型 Agent。

但热闹散场之后，两款产品都进入了相对沉寂的阶段，移动端收入长期徘徊在 50 万美元左右。更普遍的故事是，大部分 Agent 项目处在 ChatBot 和垂类工具的双向夹击中，通用 ChatBot 向下蚕食轻量任务，垂直工具（做 PPT 的「Gamma」、做转录的「Otter」「Granola」）把单一高频场景的用户截走。

我们一度以为双巨头之外的通用 Agent 难以为继。但到了 2026 年，「Manus」和「Genspark」却在都有爆发之势，走的还是完全不同的两条路。

一、夹击之下，找到被忽视的长尾用户

「Manus」和「Genspark」双端月流水数据（分成后）｜图片来源：AppMagic

本以为绝大多数用户都流向了 Codex 与 CC 的 2026年，「Manus」和「Genspark」在 Web 端和移动端却开始快速增长，最核心的是，用户付费增长明显。

按移动端流水来看，与 2025 年年末的水平相比，「Manus」5 月流水是之前的 3 倍，达到 360 万美元，「Genspark」的基数更小，为原来的 6 倍多，有 130+万美元。（AppMagic）

Web 端同步抬升，没有三方的流水数据监测，但「Manus」和「Genspark」的访问量也分别从去年 11 月的 1527 万和 1140 万，增长到了今年 4 月的 3030 万和 2135 万，5 个月时间均翻倍。（AI 产品榜）

两款产品分列 AI 智能体 4月网站访问量榜的 2、3 名｜图片来源：AI 产品榜

两款形态接近的产品同步起量，背后大概率不是巧合。

「Genspark」联创 Kay 在宣布「Genspark」转型的文章《为什么我砍掉了拥有 500 万用户的 AI 搜索产品》中写过一句话：“用户不再满足于‘帮我总结一下’，他们开始要 pitch deck、视频脚本、跟进邮件。”Agent 类产品切入市场的底层逻辑，本就是将“给出答案”变成“交付成果”，但要在 ChatBot 的下沉压力和垂直工具的截胡之间找到付费用户，并不容易。

从应用商店和 Reddit 上的用户评论看，「Genspark」和「Manus」在 2026 年的破局，更多依赖被巨头们忽略的一批人，设计师、初级运营、律师、独立小店主。他们的共同特征是任务种类多、单项任务频次低——既要做促销海报，又要处理表格；既要写一份合同摘要，又要发跟进邮件。

我们在 Reddit 上看到过一条比较有代表性的评论，一位日本便利店主说：“店里的促销海报和数据处理全部交给「Genspark」，每次能省两三个小时”，相对于高复杂度专业任务被 AI 代理，更类似于一连串的散碎事务被一个入口接管。

「Genspark」在韩国市场的广告素材，主打 All-in-One｜图片来源：广大大

对于他们来说，为每一类任务单独订阅一个垂直工具，订阅费和学习成本都不划算，他们更需要一个 all-in-one 的工作流入口。

面对垂类工具，Agent 们靠 All-in-One 打出差异，而面对巨头的通用 Agent，则靠的是低门槛和灵活定价。

虽然 4 款产品其实都主打完成任务、交付结果，但是 CodeX 和 Claude Code 虽然都有移动端，但作用都是监控和管理，任务仍需跑在 PC 桌面，Claude Code 还要求配置本地开发环境，学习成本高于直接可用的「Genspark」和「Manus」，后者也能够直接在移动端交付结果。

图注：「Genspark」和「Manus」均以订阅为主，但按 Tokens 计费，并提供可定制的积分订阅方案，覆盖 20 美元/月与 200 美元/月的中间地带

另一方面，在定价方式上，「Genspark」和「Manus」都以 Tokens 计费，且提供定制订阅方案和额外购买积分选项，相比之下，使用 CodeX 和 Claude Code，都需要用户订阅 ChatGPT 和 Claude，但仅有 20 和 200 美元两档。

虽然 CodeX 也可以额外购买积分，但仍不如「Genspark」和「Manus」灵活，有用户表示，自己的预算没法够到 Claude Max 的级别，还是继续用「Genspark」了。

翻译 1：我改用了 Claude Max 和 Freepik Premium Plus。现在我做大型项目时，不再需要担心额度限制了。顺便说一句，Claude Pro 真的不太行，生成一个 Word（docx）文件就可能消耗很多额度，很容易触发使用限制，所以要小心。

翻译 2：谢谢！这个评论很有帮助。我的预算到不了 Max 套餐，所以我可能还是继续用「Genspark」，需要的时候再额外购买 Credits（积分）

找到了相似的用户，两者收入均爆发式增长，同时，两者区别在于，「Manus」的主要收入来自于美国，而日韩则贡献了「Genspark」的绝大部分流水。

二、「Genspark」追求结果，「Manus」重视过程

两家产品的差异，从首页就已经显露出来。

「Manus」首页（上），「Genspark」首页（下）

「Manus」的输入框写着“分配一个任务”，其核心入口也围绕 Agent、插件、云电脑、定时任务等执行能力展开，与 Codex 很像。「Genspark」的输入框则是“Create anything”，首页最显眼的位置直接展示文档、PPT、图像、视频等具体成果。

往下看功能，分野更加清晰。「Manus」持续强化的是云电脑、定时任务、多信源深度调研这些过程性能力，让用户看到任务如何被拆解、执行、卡在哪一步；而「Genspark」则不断扩展打电话、音乐、自动剪辑、翻译、下载等能交付成果的能力项。

某种程度上说，「Manus」想做的是一个让用户看见过程并可以随时介入的 Agent；「Genspark」则更像一个提出目标然后等结果到货的 Agent。这两种产品哲学并非绝对对立，它们也在互相吸收对方的能力，但底层的“产品人格”差异，决定了它们最终会被哪一类用户买单。

先看「Genspark」在日韩。

根据 Podobas Global 的数据，日本 SaaS 占整体 IT 支出的比重只有 4%，而美国则有 15%-18%。这里面固然有企业级 SaaS 的因素，但对于便利店老板、普通职员这批个人用户来说，问题更直接，日本市场上几乎没有真正针对他们的垂类工具。

这个空白，「Genspark」在持续填补。今年上线的 Call for me 功能，让 Agent 直接替用户打电话完成查询或预约，AI 返回结果，用户全程不用开口。对“社恐”但经常要打电话的日本用户来说，这是一个非常具体的刚需，甚至有日本用户分享用 AI 给领导打电话辞职的场景。

这种功能在美国几乎不会成为卖点，但在日本，它精准回应了一批真实用户的真实需求。

日本用户分享打电话辞职的使用场景｜「Genspark」官网

再看「Manus」和美国。

前文提到的 Gamma、Otter、Notion 等工具几乎都诞生于美国，本土普及率很高。美国用户的工作流本身就是多个 SaaS 工具拼成的——这意味着“一个超级工具直接交付结果”对他们的吸引力其实有限，反而是“能被嵌进现有工作流、过程可见、随时干预”的能力更值钱。

在美国市场用户评论中，「Manus」更多是被嵌进已有工作流的某个环节，而不是替代原有工具。有用户先在 ChatGPT 里做大量前期构思，再把初稿拿到「Manus」里整合成最终文档；还有用户把「Manus」接入 GitHub 和 Vercel，跟「Manus」一起写代码，满意了它直接推送上线。两类用法的共同点是：用户没有离开原有工具，而是让「Manus」承接了执行和整合那一环。

在美国市场用户评论中，呈现了 2 类比较典型的用法，一类是多个工具切换，将半成品丢给「Manus」修改、成文；另一类是模糊想法后，通过多轮交互打磨成可交付版本。两类用法的共同点是“用户在场”，建立一套流程，全程可干预。

之前在《Manus，困在沙盒中的手办》中讨论过「Manus」在管理咨询场景里的局限——因为缺少专家洞察、企业内部数据和第三方 Benchmark，「Manus」当时被困在“麦肯锡式高大上”的图谋里。回过头看，2026 年「Manus」真正跑通的市场，不是它最早想象中的咨询替代场景，而是把“过程可控”这个长板，下沉到了那群每天处理一堆零散 SaaS 任务的美国普通工作者身上，通过“用户群体下移找到 PMF”。

三、多模型路由 vs 主模型上下文：架构是产品哲学的技术表达

而产品理念上的差异，为它们找到了不同的用户，但往更底层看，更源于技术架构的差异。

「Genspark」走的是多模型路由路径。用户的输入会先通过路由层做任务拆解和分类，然后被分发到 30 多个模型和自封装工具进行处理，每个模型权重相对均等。这种方式的代价是用户不知道具体由哪个模型完成了哪一步，无法明确追溯过程，但好处也很直接，对大量不需要复杂推理的标准化任务（处理表格、电话查询等等），延迟更低、成功率更高。

这种“暗箱但快”的产品体感，契合日韩市场用户“结果交付”的偏好。

图片来源：CloudRivers 的技术博客（侵删）

而「Manus」则选择了另一条路线，主模型+辅助模型+上下文优化。它将大模型视为“大脑”，把记忆管理、工具调用和任务状态等原本要塞进上下文窗口的东西剥离，交给一个独立的 Agent Runtime 负责协调，再通过专属各任务的虚拟机方案，完成实际操作。

图片来源：CloudRivers 的技术博客（侵删）

这种架构下，Agent 能够持续调用历史记录、文件和中间结果完成复杂任务，避免将所有信息都塞进上下文窗口。重要的是，任务执行过程完全可见，用户能够追踪、检查甚至干预每一步操作，相比 CodeX 的沙箱方案，「Manus」的沙箱更强调可见性，任务怎么跑的、每一步在做什么，用户全程看得到。

某种程度上说，两家的技术选择并不是孤立的工程决策，同时是产品理念的技术表达。「Genspark」要的是“一个入口接住一切”，所以需要路由层让 30 多个模型在背后分工；「Manus」要的是“用户全程在场”，所以把执行过程从模型里搬到沙盒外，让一切都能被看见和介入。

「Manus」和「Genspark」最有意思的地方，不在于它们各自找到了什么客户，而在于它们共同证伪了“Agent 会有统一产品形态”的预期。

回过头去看 2025 年关于通用 Agent 的争论，大家默认假设是这个赛道最终会跑出一两个“普适型 Agent”，把所有用户和场景一网打尽。但 2026 年的数据告诉我们：Agent 的产品路径，本质上是和“用户现有工具组合复杂度”反向匹配。在 SaaS 稀缺的市场（日韩），用户要的是一个 All-in-One 的超级入口，于是「Genspark」的“卖结果”打通了；在 SaaS 高度成熟的市场（美国），用户要的是一个能嵌进现有工作流、过程可控的助手，于是「Manus」的“卖过程”打通了。

这种“反向匹配”的方法论，可能比“Agent 找到了 PMF”本身更值得关注。

参考文章：

1、「Genspark」 正在逼近 「Manus」？ AI Search 市场的新竞争已经开始

2、「Genspark」 vs 「Manus」 架构深度分析

3、OpenClaw vs 「Manus」 vs 「Genspark」 三方架构对比