Meta以20亿美元收购Manus的消息在AI圈掀起轩然大波。这看似"套壳"的应用凭什么价值连城？关键在于它构建了一套能将大模型"聪明"转化为"能干"的工程体系——从提示词技巧到系统架构设计的工业化跃迁。本文将深度解析Manus如何通过极致的"上下文工程"成为数字世界的"终极打工人"。

说实话，当Meta用20亿美元收购Manus的消息传出来的时候，我朋友圈里做AI的同行们，反应挺两极分化的。一部分人觉得不可思议，一个自己不训练大模型，看起来就是调用别家API的“套壳”应用，凭什么值这么多钱。另一部分人，包括我，在短暂的震惊之后，更多的是一种“果然如此”的感觉。

为什么这么说呢?因为作为天天跟AI产品打交道的人，我们太清楚现在AI应用的痛点了。模型能力确实一天比一天强，能写诗、能画画、能聊天，看起来无所不能。可一旦你想让它干点正事，干点需要多个步骤、需要稳定输出的复杂任务，那翻车率简直高得吓人。就像你请了个天才儿童，他能背整本字典，你让他去帮你买瓶酱油，他可能走到半路就被蝴蝶吸引走了，最后空手而归。

大家都在讨论模型参数多大，上下文窗口多长，好像只要模型本身够强，一切问题就迎刃而解。可Manus这个案例，就像一记响亮的耳光，打醒了很多人。它告诉市场，真正的价值，可能藏在那些看起来不那么性感的、脏活累活的工程细节里。它根本就不是一个薄薄的“套壳”，它是在大模型这个“地幔”之上，硬生生构建出了一层厚重、稳定、有自己生态循环的“地壳”。

这20亿美金，买的不是一个更聪明的模型，而是买了一套能把“聪明”转化为“能干”的顶级工程体系。买的是一种从“提示词技巧”这种炼丹术，到“系统架构设计”这种工业化生产的思维跃迁。我觉得，这才是Manus案例给我们这些AI产品从业者最大的启示，也是我今天想跟你聊透的核心。

一、重新定义Agent：从“聊天”到“完工”的产品哲学

要理解Manus的价值，我们得先搞明白它到底是个什么东西。很多人把它跟我们手机里的各种智能助手混为一谈，觉得不就是个高级点的聊天机器人嘛。这个理解偏差可就大了去了。在我看来，Manus做的，是对AI Agent这个概念的一次产品层面的重新定义。

传统的Chatbot，本质上是一个“建议者”。你问它问题，它给你答案；你让它帮忙，它给你步骤。比如你问它“帮我规划一个五天的东京旅行”，它会给你一个详细的行程单，包括景点、餐厅、交通建议。看起来很棒，对吧。可接下来呢，订机票、订酒店、买门票，这些实际的“执行”动作，还得你自己一个一个去完成。Chatbot只负责“说”，不负责“做”。

Manus的哲学完全不同，它的定位是一个“交付者”，一个追求“完工”的通用Agent。你给它的指令不是“告诉我怎么做”，而是“帮我做完”。还是那个东京旅行的例子，你对Manus说“帮我规划并预订一个五天的东京自由行，预算两万，下周末出发，我喜欢动漫和美食”。理想情况下，它会自己去搜索航班、对比酒店、规划路线、购买门票，最后把所有的电子票据和一份确定的行程单交付给你。你从一个“执行者”变成了一个“委托者”。

这种从“给建议”到“交付成果”的转变，听起来简单，背后是产品哲学的根本差异。它意味着产品追求的不再是交互的流畅或者回答的巧妙，而是任务完成的“确定性”和“高质量”。它必须能理解复杂的意图，能把任务拆解成上百个步骤，能在执行过程中应对各种意外，并且最终交出一份让你满意的答卷。这难度完全不是一个量级的。

为了实现这个目标，Manus在用户定位上也做出了一个非常聪明的选择。它服务的不是普通大众，而是所谓的“Prosumer”，也就是那些有消费能力、愿意为效率和结果付费的专业人士或高端消费者。这些人时间宝贵，他们不关心你用了什么模型，也不想学习复杂的提示词技巧。他们要的就是一个可靠的助理，把事情交给你，你就能办妥。他们愿意为这种“确定性”和“省心”的服务支付高昂的费用。这就为Manus的商业化奠定了坚实的基石，让它有底气去投入巨大的研发成本，去打磨那些极致的工程细节。

所以你看，Manus从一开始就没想做一个陪聊的玩具，它的野心是成为数字世界里的“终极打工人”，一个能真正干活、能交付价值的生产力工具。这种产品哲学上的升维，是它能构建起“地壳”级护城河的起点 。

二、核心护城河：极致的“上下文工程”

聊完了产品哲学，我们得深入到最硬核的部分了。Manus那层厚厚的“地壳”到底是用什么材料构建的？在我看来，核心就是四个字：“上下文工程”。这个词可能听起来有点玄乎，看我给你拆解一下，你就明白它为什么是Manus的命脉所在。

我们都知道，大模型就像一个只有几秒钟记忆的金鱼，它的所有思考都依赖于你给它的“上下文”。上下文就是它在回答你当前问题时，能看到的所有历史信息。上下文窗口越大，它能记住的东西就越多。可问题是，这个窗口是有限的，而且非常非常贵。每一次调用，上下文里的每个字都在烧钱。怎么在有限的、昂贵的上下文里，让Agent能记住关键信息、执行长任务、还能从错误中学习，这就是“上下文工程”要解决的核心问题。Manus在这方面，做到了近乎变态的极致。

2.1 性能与成本的精算师：KV-Cache导向设计

先说一个可能有点技术，但极其关键的东西：KV-Cache。你可以把它理解成大模型在处理上下文时，给自己打的一个“草稿”。每次模型生成一个新的字，它都要回顾一遍前面的所有内容，这个过程非常耗时。KV-Cache就是把前面内容计算后的中间结果存起来，下次就不用重复计算了，大大加快了速度。

这玩意儿是所有生产级Agent的生命线。为什么？因为它直接决定了两个核心指标：响应速度和推理成本。尤其是在Agent这种需要多轮对话、反复思考的场景里，如果每次都要从头计算，那用户体验会慢到爆炸，成本也会高到公司破产。

Manus的聪明之处在于，它把整个系统设计都围绕着“如何最大化KV缓存命中率”来展开。他们做了几个看起来很小，但效果拔群的工程选择。比如“前缀稳定”，就是确保每次发给模型的上下文，前面那一大段长长的、不变的部分，在字符串层面都是一模一样的。这样一来，模型的KV缓存就能百分之百命中，只有最后新增的一小部分需要重新计算。

还有“只增不减”和“确定性序列化”。意思是，整个任务过程中，上下文信息只会增加，不会随意删改，并且所有信息都按照一个固定的、可预测的格式来组织。这就像你整理书架，永远只往右边加新书，并且所有书都按同一个标准分类。这样做的好处是，模型的“草稿”可以被最大程度地复用，几乎不会浪费。

这些操作听起来像是程序员的洁癖，但带来的业务价值是巨大的。据说通过这些优化，Manus把首次响应延迟TTFT做到了极低，并且把推理成本降低了整整10倍。10倍是什么概念？就是别人做一个任务要花10块钱，它可能只需要1块。在AI时代，这就是生与死的区别。

这给我们的产品启示是，我们做AI产品，不能再只盯着模型参数了。很多时候，一个巧妙的缓存策略，一个看似不起眼的工程细节，对用户体验和商业模式的决定性作用，可能比你换个更强的模型要大得多。工程实现，本身就是产品设计的一部分，而且是越来越重要的一部分。

2.2 对抗“遗忘”：用“复述”机制操控注意力

Agent执行长任务，最大的敌人就是“遗忘”。当任务步骤一多，上下文信息一爆炸，模型就很容易“忘了我是谁，我要干嘛”。这就是所谓的“上下文爆炸”和“上下文腐烂”。就像一个人在信息洪流里，很容易就迷失了最初的目标。

很多团队的解决方案是寄希望于更大的上下文窗口，比如从几千个token卷到几百万个token。但这治标不治本，窗口再大也有极限，而且成本和延迟会急剧上升。Manus的思路就特别产品化，它没有硬刚技术瓶颈，而是设计了一个聪明的机制来“操控”模型的注意力。

这个机制，我称之为“主动复述”。具体怎么做呢？举个例子，当Agent开始一个复杂任务时，它会先创建一个叫 todo.md 的文件。这个文件里写着整个任务的最终目标和主要步骤。在接下来的每一步操作中，无论它在做什么，它都会被强制要求重新“背诵”一遍这个 todo.md 文件的核心内容，并把它放在上下文的最前面。

这就像一个登山队员，每走一段路，就停下来抬头看看山顶，确认一下自己的方向。通过这种不断的、主动的“复述”和“回顾”，Manus把最重要的全局目标，像一个图钉一样，死死地钉在了模型有限的注意力范围内。不管中间执行了多少步，产生了多少临时信息，那个最终目标永远不会被“淹没”。

这个设计给我的启发太大了。一个优秀的产品设计，不应该盲目依赖底层技术的能力，而是要通过机制的设计，去主动管理和引导用户的认知负荷。在这里，用户就是模型本身。我们不能假设模型是完美的，我们得把它当成一个聪明但容易分心的孩子，用一套行之有效的规则和流程，牵着它的手，确保它一步步走向终点这才是高级的产品思维 。

2.3 从失败中学习：“错误保留”的反直觉智慧

在Agent产品中，最头疼的就是处理错误。Agent在执行任务时，出错是家常便饭，可能是代码写错了，可能是网页元素找不到了，可能是API调用失败了。常规的策略是什么？出错即重置。一旦发现走不通，就清空记忆，回到上一个检查点，换条路再试。这很符合直觉，对吧？

Manus的做法，恰恰相反，非常反直觉。它选择“保留错误轨迹”。当Agent执行某个操作失败时，系统不会把这次失败抹掉，而是会把整个出错的过程，包括它尝试的命令、返回的错误信息，完完整整地记录下来，并作为新的信息，喂回到上下文里。

这是什么操作？这不是在污染上下文，让模型更困惑吗？一开始我也这么想，后来才明白其中的智慧。Manus把每一次失败，都看作是一次宝贵的“负样本”学习机会。它告诉模型：“你看，你刚才这么做，失败了，错误信息是这个。现在，基于你已经知道‘此路不通’这个事实，再想想下一步该怎么办”。

这极大地提升了Agent的自我纠错和恢复能力。它不再是无头苍蝇一样反复试错，而是学会了从失败中总结经验。比如它第一次尝试用A方法解析数据失败了，它就会在下一次尝试中主动避开A方法，去尝试B方法。这让整个Agent系统变得非常有韧性，也就是我们常说的“鲁棒性”。

这个产品启示对我来说，就是重新思考了“智能”的定义。一个智能体的“智能”，或许不体现在它能一次性百分百成功，那更像是机械的自动化。真正的智能，体现在它从失败中恢复的能力，体现在它的反思和学习能力。所以我们设计产品时，不应该把所有精力都放在追求完美的单次执行上，而应该花更多心思去设计容错和自学习的循环。让系统在不断的磕磕碰碰中，变得越来越强大，这可能才是通往通用人工智能的正确路径。

2.4 无限记忆：文件系统即“外部大脑”

前面我们反复提到，上下文窗口是有限的，是Agent记忆的瓶颈。即使有百万级别的长上下文，对于一个需要处理大量文档、跨越数天甚至数周的复杂任务来说，也远远不够。而且，把所有东西都塞进上下文，成本高得离谱，性能也差得要命。

Manus的解决方案，是给Agent配了一个“外部大脑”——文件系统。这个想法不新鲜，很多系统都在用。但Manus把它做到了极致。它不只是简单地把文件存起来，而是建立了一套完整的、与模型交互的记忆管理策略。

它的核心思想是，把昂贵、有限的上下文窗口，只用来做“当前思考”，而把便宜、无限的文件系统，用来做“长期记忆”。当Agent需要处理一个大文件时，它不会傻乎乎地把整个文件读进上下文。它会先浏览一下文件列表，或者用搜索命令找到相关的文件。然后，它只把文件的“引用”或者一个极简的摘要放进上下文，告诉模型：“嘿，这里有个文件，叫report.pdf，里面是关于上个季度的销售数据”。

只有当模型在思考过程中，明确需要文件里的某个具体信息时，它才会生成一个命令，去读取文件的特定部分。比如“读取report.pdf的第三章”。系统执行这个命令，把那一章的内容取出来，再放进上下文供模型使用。这个过程，Manus称之为“可逆压缩”。信息在不需要的时候，被“压缩”成一个文件引用；在需要的时候，再“解压”加载到工作记忆里。

通过这种方式，Manus巧妙地绕过了上下文长度的物理限制，给了Agent一个理论上“无限”的记忆空间。它能处理海量的资料，能执行横跨很长时间的超长任务，而这一切，都建立在一个非常经济、高效的架构之上。

那给我们的产品启示是什么呢？当你的核心资源，比如这里的上下文长度，是有限且昂贵的时候，最优秀的产品架构，一定是懂得如何利用外部系统来做扩展的。不要试图在螺蛳壳里做道场，要学会“借力”。把文件系统、数据库、甚至是其他的API服务，都看作是AI“大脑”的延伸，通过巧妙的架构设计，实现一种“无限记忆”的用户体验。这是一种系统化的产品思维，远比单纯地堆砌资源要高明。

三、超越工程：产品化落地的关键抉择

如果说“上下文工程”是Manus的“地壳”内部的岩层结构，那它在产品化道路上做出的一系列关键抉择，就是决定这块“地壳”板块走向和边界的地质运动。这些选择，与工程细节相辅相成，共同构成了它深不可测的护城河。

3.1 定位选择：通用Agent vs. 垂直Agent

在Agent的赛道上，一直有两条路可以走。一条是做垂直领域的Agent，比如专注于UI设计的Lovart，或者专注于法律合同分析的某个工具。这条路的好处是场景明确，需求聚焦，更容易做出深度，也更容易商业化。另一条路，就是Manus选择的，做通用Agent。它想成为一个能干任何事的数字助理。

通用路径的诱惑是巨大的。它的市场天花板极高，一旦做成，就有可能成为下一个操作系统级的平台入口。可挑战也是地狱级的。通用意味着要应对千奇百怪、无穷无尽的任务类型，这对系统的泛化能力、稳定性和工程底座的要求高到了极点。绝大多数团队，根本不敢碰。

Manus敢走这条路，并且走通了，本身就说明了它对自己那套工程体系的极端自信。它相信自己的“上下文工程”足够扎实，能够支撑起一个通用任务执行的框架。这种定位上的选择，和它的技术核心是互为表里的。没有金刚钻，不揽瓷器活。正是因为它锻造了金刚钻，所以它敢于去挑战整个瓷器店。

3.2 技术范式：CodeAct vs. Tool-Use

这是另一个非常关键的技术路线选择。目前主流的Agent，大多采用“Tool-Use”范式。什么意思呢？就是你预先定义好一堆工具，比如“搜索工具”、“计算器工具”、“订票工具”。Agent在执行任务时，就像一个调度员，根据需要去选择调用哪个工具。这种方式的好处是稳定、可控，因为工具的行为是确定的。缺点是灵活性差，工具集是有限的，遇到工具箱里没有的锤子，它就敲不了钉子。

Manus采用了一种更激进、也更强大的范式：“CodeAct”，也就是“生成并执行代码”。在这种模式下，Agent不再是调用固定的工具，而是直接生成一小段代码比如Python或Bash脚本来完成任务。这给了它无与伦比的灵活性。它不再受限于预设的工具箱，而是拥有了一个可以动态构建任何工具的“代码工坊”。

需要分析一个复杂的Excel表格？它直接写一段Python脚本，用Pandas库来处理。需要跟一个没有官方API的网站交互？它直接写一段爬虫脚本去抓取数据。这种方式让Agent能够与真实世界的数字环境进行更细粒度、更深度的交互。它能像一个真正的程序员一样，去操作文件、调用系统命令、与各种服务互动。这是它能够完成那些极其复杂任务的根本原因。

3.3 执行环境：深度可控的“沙箱即操作系统”

选择了CodeAct范式，就必须解决一个致命问题：安全。让AI随便在你的电脑上写代码并执行，这无异于引狼入室。万一它写出个 rm -rf / 这样的命令，后果不堪设想。

所以，一个安全、隔离的执行环境就成了刚需。Manus在这方面投入了巨大的精力，自研并维护了一套云端的“沙箱”环境。这个沙箱，绝不仅仅是一个简单的安全隔离区。在我看来，它更像是一个为Agent量身定制的、功能完备的“迷你操作系统”。

这个沙箱环境是基于Linux的，预装了极其丰富的工具链。从Python、Node.js这些编程语言环境，到浏览器、文件编辑器，再到各种常用的命令行工具，应有尽有。Agent在这个环境里，就像一个拥有最高权限的系统管理员，可以随心所欲地施展拳脚，而不用担心会破坏外部世界。它可以在这里安装软件、运行服务、管理文件，几乎能模拟一个真实开发者的所有操作。

这个深度可控的沙箱，是Manus强大执行力的基础。它为CodeAct范式提供了一个完美的舞台。没有这个舞台，再好的演员也演不出戏。这也是一个极难被复制的壁垒，因为它需要长期的、持续的投入和维护，远不是调用一个API那么简单。

3.4 模型策略：“路由器”而非“造车厂”

最后聊聊Manus对大模型的态度，我觉得这体现了它极度的务实和聪明。在所有人都挤破头想“造车”，也就是训练自己的基座模型时，Manus选择做一个“路由器”。

它不自己训练千亿参数的大模型。相反，它接入了市面上所有最顶级的模型，比如来自不同顶级实验室的各种模型。它的核心系统里有一个“模型路由”模块。这个模块会根据当前任务的类型和特点，动态地、智能地选择最适合的模型来执行。比如，需要写代码的任务，它可能会把请求路由给在代码生成上表现最好的Claude系列；需要联网搜索和信息整合的任务，它可能会选择Gemini。需要进行一般性对话或创意写作，它又可能选择另一个模型。

这种策略的好处是显而易见的。它把训练和维护基座模型这个最烧钱、风险最高的环节，“外包”给了全世界最顶级的几个玩家。它自己则可以永远保持“模型中立”，始终为用户提供“当下最优解”的组合。今天这个模型强，我就多用它一点；明天那个模型有了突破，我就立刻把它集成进来。这让Manus能够把所有精力都聚焦在自己的核心优势上——也就是我们前面聊的上下文工程、执行环境和产品体验。

它不是在赌某一个模型的未来，而是在赌“模型能力会持续进步”这个大趋势。只要这个趋势不变，它的“路由器”策略就永远有效。这种产品战略上的清醒和克制，在今天这个浮躁的AI圈子里，显得尤为可贵。

四、启示与挑战：AI产品经理的新思维

聊了这么多Manus的细节，最终还是要回到我们自己身上。

作为一个AI产品经理，这个案例到底能给我们带来什么新思维？我觉得至少有两点是颠覆性的，同时，它也面临着巨大的挑战。

第一个启示，是护城河的转移。过去我们做产品，护城河可能是一个独特的算法，一个巧妙的交互设计，或者一个庞大的用户网络。但在AI应用时代，竞争的焦点正在快速地从模型算法本身，转移到系统工程的实现上。也就是说，你的护城河不再是你“用”了什么模型，而是你“怎么用”这个模型。

能不能在保证体验的同时，把成本控制到极致？能不能让Agent在执行上百个步骤的长任务时，保持稳定不“跑偏”？能不能构建一个既灵活又安全的执行环境？这些问题的答案，都藏在系统架构、成本控制、任务稳定性和用户体验的工程实现里。对于AI产品经理来说，这意味着我们不能再满足于画原型、写PRD了。我们必须更深入地理解技术，理解那些“看不见”的工程细节，因为那里才是未来产品竞争力的核心所在。

第二个启示，是体验的重构。Agent产品正在催生一种全新的交互范式，我称之为“异步委托”。传统的软件交互是“交互式问答”，你点一下，它动一下，你和软件是同步的。而Agent的核心体验是，你把一个复杂的任务委托给它，然后你就可以关掉页面，去干别的事了。几个小时甚至几天后，它完成了任务，再来通知你。这是一种异步的、基于信任的委托关系。

这种体验的转变，对产品设计提出了全新的要求。我们怎么设计任务的下达和澄清过程？怎么在Agent执行过程中，给用户提供恰到好处的、不打扰的进度反馈？怎么建立用户对一个“黑盒”系统的信任，让他敢于把重要的任务交出去？这些都是全新的课题，需要我们去探索全新的交互设计语言和信任构建机制。

当然，Manus的未来也并非一片坦途，它面临的挑战同样巨大。

最直接的挑战就是成本与规模化的平衡。它那套极致的工程体系，虽然优化了成本，但每一次成功的复杂任务执行，背后依然是海量的token消耗和计算资源的调用。这种高昂的推理成本，决定了它目前只能服务于少数高净值用户。未来如何降低成本，实现规模化的普及，同时还能保持盈利，这是一个巨大的商业难题。

另一个更长远的威胁，来自大模型平台自身的“降维打击”。像OpenAI、Google这样的巨头，也在不断地把Agent的能力内化到他们的模型底层。如果有一天，基础大模型自己就具备了超强的长任务执行能力、自我纠错能力和工具使用能力，那Manus这样的“中间层”价值会不会被稀释？这是悬在所有AI应用层公司头上的达摩克利斯之剑。

最后，还有生态整合的难题。被Meta收购后，Manus如何与Instagram、WhatsApp这些拥有数十亿用户的生态进行深度融合，是一个巨大的机遇，也是一个巨大的挑战。它能不能从一个独立的“智能工具”，真正跃迁成为驱动整个社交生态的“智能操作系统”？这不仅是技术问题，更是复杂的组织、文化和产品战略问题。走错一步，就可能从“香饽饽”变成“鸡肋”。

结语：智能体的未来，一次构建一个上下文

聊到这里，我们再回头看“从‘套壳’到‘地壳’”这个标题，或许会有更深的感触。

大模型的能力，就像潮水，它会周期性地涨落，今天你领先，明天他赶超。把公司的全部身家都押在潮水本身，风险是极大的。而Manus这样的公司，给我们展示了另一种可能性：在潮水之上，建造一艘坚固的、设计精巧的船。

这艘船的龙骨，是它“从聊天到完工”的产品哲学；船身的主体，是它极致的“上下文工程”；船上的帆和舵，是它在技术范式、执行环境和模型策略上做出的一系列关键抉择。潮水可以涨落，但只要船足够坚固，航海技术足够高超，它就能在任何水位的海面上航行。

我觉得，AI智能体的未来，不只在于模型变得更聪明、更强大。更关键的，在于我们如何像Manus一样，通过精巧的、体系化的“上下文工程”，把模型那强大的、不稳定的、昂贵的“潜力”，一步一步地转化为稳定、可靠、可大规模交付的用户价值。

对于我们这些身处其中的AI产品经理而言，这意味着一个时代的结束，和另一个时代的开始。那个靠着几个巧妙提示词就能做出爆款的时代，可能已经过去了。未来，我们需要像建筑师一样，去理解材料的特性，去设计稳固的结构，去关注每一个承重和连接的细节。我们需要深入到那些“看不见”的工程里去，因为那里，才是定义下一代AI产品的真正战场。

智能体的未来，或许就是这样，一次构建一个上下文，一行执行一段代码，在一个个看似枯燥的工程细节中，慢慢地，但无比坚实地，被建造出来。