非 AI 的总结
– Manus 没有基座模型层面的突破性技术，但工程实现能力很强。
– Manus 的产品理念相对超前。
– 通用 Agent 会普及，垂类 Agent 仍有机会。
– 虽然但是小扎确实是冤大头。
2025 年底，Meta 宣布以约 20 亿美元收购 Manus 的消息在 AI 圈引发热议。围绕扎克伯格是否“花冤枉钱”的争论也持续到了 2026。曾经我也跟风觉得 Manus 不过是个“套壳 GPT”。然而，进入 2026 年，字节与 Anthropic相继在通用 Agent 方向发力，我个人也开始越来越依赖 AI 处理个人事务，并亲手上手开发 Agent 应用。我觉得是时候再谈 Manus——看它究竟在 AI 的发展路程中扮演“指路人”还是“投机者”。
需要声明的是，在 AI 技术和产品方面，我都是刚入门的小白，欢迎大家积极讨论，贡献更多有意义的观点。
技术
AI Agent的三个关键技术
首先需要明确：我们谈论 AI 大模型时，必须区分“基座模型”与“At”。类似 DeepSeek、Qwen、Seed、GPT 等都是基座模型——它们本身不具备尝试迭代的能力，文件处理工具或会话记忆，只是对输入的 token 进行概率预测并输出结果。
而 DeepSeek 网页、千问 App、豆包 App、ChatGPT 等更接近我们日常所说的AI：它们有 GUI、能读文件、能搜索网页、能记住你上一次的对话内容，我觉得可以称之为AI Agent。Agent 的核心工作是调用基座模型生成回复，基座模型的能力决定了 Agent 的上限；但 Agent 如何组织“发给模型的内容”与“从模型返回的结果”、如何调用各种工具、如何在多轮对话后仍然围绕原始目标推进，我个人总结为 Agent 应用的三个关键点：
– 前后处理框架（Prompt/Response 的结构化编排）
– 工具调用（Browser/Code/Docs 等能力的稳健封装与调度）
– 上下文管理（记忆、检索与长任务的目标对齐）
基于这三个关键点来看 Manus：虽然它在“基座模型”层面没有原创性贡献，但以 2025 年出现的时间点，其工程实现非常有实力。Manus 具备“推理—分解—执行”的框架，能处理多种格式的文档，能自主调用浏览器，能产出稳定可读的文档；对长周期任务，也较少出现“做了后面忘了前面”的错误。
这些能力用起来平平常常，但我自己上手 Agent 开发后才知道，仅工具适配与 I/O 格式解析，就需要大量不那么“快乐”的脏活累活。基座模型决定上限，而下限往往由这些外围工程技术保障。所以，从技术角度看，早期“Manus 没技术贡献、只是调用器”的质疑并不完全公平。能把“调用器”做好并不容易——至少从功能体验上，Manus 作为创业公司作品，与2026年字节出品的 AnyGen差距不大，本身就是技术能力的体现。
当然，如今 ChatGPT 也能处理文件、搜索网页，Manus 似乎仍难摆脱“套壳 GPT”的嫌疑。要回答这一点，就得谈谈 Manus 的产品理念。
产品
最近我开始读《人人都是产品经理》，惊讶于这本书跨越互联网、移动互联网和 AI 三个时代，仍持续带来新的认知——足以证明优秀的知识不会过时。现在就斗胆实践一下书中的一些方法，从产品经理的角度看看 Manus。
沙盒机制的一举三得
《人人都是产品经理》一书中的一个重要观点是：用户“说的需求”不一定等于用户真正“想要的”。例如当用户说“我希望 AI 全自动操作电脑”时，潜在的真实需求往往是“让 AI 全自动完成重复性工作”，而不是“看见 AI 在自己的设备上到处点来点去”。
以此视角看 Manus 的“沙盒机制”，这是非常巧妙的设计：
1. 安全性：沙盒确保 AI 只在自己的“虚拟电脑”上操作，而不会直接影响用户电脑。即使执行 `rm -rf *` 这样的危险指令，也不会对用户设备造成实际破坏。这层隔离让用户更放心地授权 AI 自动执行。
2. 聚焦度：沙盒将注意力限制在项目范围之内——只关注该项目需要的文件、会话与信息，不被无关内容干扰；相当于为每个项目构建一个“专属 Agent”。我用 Agent 的习惯是：一个项目一个会话，把可能用到的文件都扔进去建知识库，后续相关处理都在这个会话中完成。前 AI 时代的 App 多是“横向聚焦某一功能”（如支付、聊天）；如今借助 AI，我们可以补上“纵向的项目骨架”，一横一纵加起来才更贴近现实世界的工作组织方式。
3. 可视化的执行过程：Manus 将 AI 在沙盒中的操作流程“摊开给用户看”，用户看到的是 AI 在忙碌地思考、处理数据、生成报告。这在技术上或许不难，但在产品上非常精彩，可以媲美 DeepSeek 展示思考过程，满足用户对 AI 的期望，提供显著的情绪价值。
结合开头的观点，沙盒机制既满足了用户的“表象需求”（看见 AI 自动执行），又满足了“真实需求”（自动完成任务），并契合项目制的工作方式，可谓一举三得。
为什么是“通用助手”
Manus 自称“全球第一款通用 Agent”。我更愿意叫它“日常 Agent”：很多测试表明，在一些专业领域（如 Coding），仍需要更强的专用 Agent 才能高质量完成；这并非说 Manus 不能写代码，而是它在专业场景里“不够好”。但对日常生活任务，我个人觉得它能覆盖 90% 的任务。
Manus 团队也谈到为何要做“通用助手”。不是每个任务都像 Coding 那样，能明确定义输入输出、对交付质量有严格指标、且有足够需求需要开发专用 Agent。现实生活里存在大量长尾需求，这些需求对交付“够 60 分”即可——这正是AI Agent 的最佳战场，因为越是专业的领域，对于交付的结果要求越高，相对应的上下文构建的要求也越高。在模型能力无法输出确定性的高质量内容时，做通用Agent反而是更讨巧的做法。
我最近主要用 AnyGen 处理了三个项目：开通淘宝店 AI 客服、规划婚礼、制定训练计划。
– AI 客服项目：让 AI 调研实现方式，自主搜索并总结与我们商品品类相关的 50 个通用问题及回复，并汇总成多份文档。之后可以持续迭代文档，成为专属知识库。
– 婚礼项目：让 AI 把婚礼策划给到的时间线转成网页，并在网站上集成开支统计与物品采购统计，用一个网站管理婚礼有关的所有内容。
– 训练项目：让 AI 根据我的需求定制训练计划，然后访问我的运动平台获取数据，生成训练报告并决定是否需要更新计划。
这些项目细小却属于长尾需求，如果为每个需求都开发一个垂类 App（如婚礼助手、某品类客服助手），手机很快会被海量 App 淹没，且可能只发挥出背后“几百亿参数”模型实力的 1%。从这个逻辑看，把 Manus 定义为“通用 Agent 应用”是很有远见的。
随着深入使用 AI，我常常感慨其能力，“状 AI 多智而近妖”；马圣也预言“3 年后 AI+机器人将取代所有人类工作”。然而同时我也发现，通用 Agent 仍有局限，通用智能时代似乎没那么快到来——下面抛砖引玉聊一点个人思考。
个人思考
垂类 Agent 仍有机会，以及与 AI 共生直至实现共产主义
以“AI 制定训练计划”项目为例：如果只让 AI 分析运动数据，它能返回一些有效建议（如训练量过大或时长不足），但也止步于此；如果明确要求使用心率分区或功率分区，则能进一步分析训练负荷、有氧/无氧占比；再进一步，要求使用 Banister 模型与 TRIMP 冲量分析，并结合短期—长期负荷模型，它就能给出更专业的评估报告。
从这个流程看，当前的基座模型像一个“超级大仓库”：包罗万象，但因为“东西太多”，不是所有人都能准确找到自己要的内容；尤其是自己不熟悉的领域，仍需要一些专业知识的引导——这正是垂类 Agent 的机会所在。
垂类 Agent 的价值在于为基座模型提供前置的领域知识：相较通用助手，垂类应用能更精准地组装提示词、调用专用工具、解析专有数据格式、提供更深的洞察——这就是它的独特价值。
在这个过程中，很容易发现我们仍然需要各领域人类专家的参与，才能发挥出大模型的最大价值。从最底层的数据标注到最上层的提示词，专业知识仍然有存在意义。大模型很“通用”，但如果只是普通提示词，往往只能得到平庸回答；只有专业的提示词才能产出真正有价值的内容。所以，我认为在 AI 时代，至少目前，干掉人的不是 AI，而是“会用 AI 的另一群人”。
然而，虽然我们现在还能与 AI 共生，但 AI 的进化速度太快了。2025 年初仍有人觉得 AI Coding 工具不甚实用；到了 2026 年初，恐怕已少有人坚持“古法手工编程”。马斯克预言“三年内机器人+AI 将重塑所有人类职业”，或许带有商业上的乐观，但我基本认同按照目前的发展趋势，最终的结局是 AGI 接管所有工作内容——先是搬运比特的数字世界，再是搬运原子的物理世界。至于之后会不会走向某种“理想社会”，恐怕没人说得清——即使是 AI 。
总结一下：相比 2025，到了 2026 年再看 Manus，从技术与产品两个角度，我更愿意给出正面评价。这来自我的理论知识的拓展与实践经验的增加。虽然如今的 AI 已强大到超越绝大多数个体，但我依旧不愿“温柔地走进那良夜”——因为一切还远未到终局。
最后，欢迎使用我的链接来体验Anygen，助力我白嫖会员，谢谢各位老板。\
I’m using AnyGen to supercharge my productivity with AI – it’s an amazing workspace. I think you’ll find it useful too! Sign up with my link and have a try.