最近AI圈的焦点几乎都被Meta的一笔重磅交易锁定——花数十亿美元收购了成立不到1年的Manus AI。这个成立时间短到连行业站稳脚跟都算不上的初创公司，却能撬动如此巨额的估值，难免让人好奇，它到底藏着怎样的技术硬实力，能让Meta甘愿砸下重金？

抛开Meta的AI布局焦虑，也不谈外界争议的“套壳质疑”，我们深入拆解Manus的技术架构与工程优化细节就会发现，它的价值不在于颠覆式的新模型，而在于找到了一套让现有大模型发挥极致效能的“组合拳”。这套架构从决策到执行，从优化到落地，每一处都透着精细化的工程思维，最终实现了“会思考的大脑+能动手的身体”的智能代理闭环。

一、核心架构：决策与执行的双向奔赴

Manus的整体架构可清晰拆分为两大模块：决策系统与执行环境。前者是它的“大脑”，负责思考、规划与纠错；后者是它的“躯干”，提供稳定、高效的操作载体。两者协同运作，构成了Manus智能代理的核心骨架。

1. 决策系统：三智能体的协作闭环

Manus的决策系统遵循“少预设规则，多依赖智能”的核心理念，通过Planner（规划者）、Executor（执行者）、Verifier（验证者）三个智能体的分工协作，实现对复杂任务的拆解与落地。这三个角色各司其职，又通过动态反馈形成闭环，避免了单一智能体的决策偏差。

Planner作为“总指挥官”，核心职责是将用户模糊的指令拆解为可执行的子任务。比如用户提出“分析最近一周AI圈的重要事件并总结”，Planner会快速梳理出清晰的执行路径：搜索权威新闻源、筛选AI相关内容、提取关键信息、生成结构化摘要、格式化输出。更关键的是，它不会一次性定死计划，而是会维护全局状态，根据执行反馈动态调整。若是某一新闻源访问失败，它会立即切换到备用数据源，避免整个任务卡壳。

Executor则是“动手实践者”，负责将子任务转化为具体操作。这里最亮眼的设计是“代码即行动（Code As Action）”范式——面对任务时，Executor会优先编写Python代码完成操作，而非依赖预定义的API接口。这种方式带来了极强的灵活性：处理非结构化数据时可调用专业库，进行复杂运算时能编写自定义逻辑，甚至还能通过代码对数据做后处理，大幅降低模型上下文的Token开销。比如处理大量网页数据时，它会编写代码提取关键信息并保存为文件，而非将所有内容塞进上下文窗口，既提升了效率又节省了成本。

Verifier则是“质量监督员”，负责在每个关键步骤后校验结果是否符合预期。小到代码语法错误、数据提取为空，大到网页截图是否包含目标信息、格式是否正确，它都会逐一检查并生成详细的错误报告，触发自我修正机制。比如代码运行报错时，Verifier会标注错误堆栈，让Planner调整计划，Executor重新编写代码，确保任务不偏离预设目标。

2. 六步迭代：让决策落地的运转机制

三个智能体的协作并非无序进行，而是依赖一套六步迭代循环机制驱动，这套机制通过“分析-规划-执行-观察”的反复迭代，确保任务稳定推进。根据逆向分析Manus的Prompt可知，整个循环流程清晰且严谨：

第一步是分析事件。Planner会读取包含7种类型的事件流，全面掌握用户需求与当前状态。这些事件包括用户消息、Agent工具调用记录、工具返回结果、任务规划清单、背景知识、数据源API文档等，同时结合System Prompt中的语言配置、能力边界、规划方法论等核心模块，为后续决策奠定基础。

第二步是更新计划。Planner根据分析结果调整任务清单（todo.md），明确下一个子任务的优先级。若是上一步执行失败，它会重新规划路径，比如更换工具或调整操作顺序，避免在无效路径上浪费资源。

第三步是选择工具。Executor从27种预置工具中挑选最适配当前任务的工具调用。这里有两个关键设计：一是每次迭代只选一个工具，防止复杂操作导致执行跑偏，确保每一步都可观测、可调整；二是刻意控制工具数量，Manus的测试数据显示，工具从10个增加到500个时，系统性能会从90%暴跌至30%，因此它选择用“代码生成”替代工具堆砌，既精简了架构又提升了灵活性。

第四步是执行操作。选定的工具会在专属云端虚拟机中执行，执行结果会同步到事件流，为下一轮迭代提供参考。第五步与第六步则是检查与决策：Verifier评估执行结果，若出错则返回第一步重新规划，若成功则推进下一个子任务，全部完成后向用户提交结果并进入等待状态。

Manus公布的数据显示，平均每个任务需要50次工具调用，也就是50轮这样的迭代循环。在大模型幻觉难以完全避免的当下，这套迭代机制通过反复校验与动态调整，实现了无需人工干预的稳定运行，而这背后，离不开上下文工程的极致优化。

二、上下文工程：Manus的核心竞争力

Manus将自身的开发过程称为“随机梯度下降”，不是深度学习中的算法概念，而是指代不断试错、持续调整的工程优化过程。为了让架构稳定运行，团队前后四次重建整个架构，最终提炼出六条核心的上下文优化手段，每一条都直击大模型应用的痛点。

1. 围绕KV-Cache命中率设计：降本增效的关键

KV-Cache命中率是Manus团队最看重的指标之一，它直接决定了模型的推理延迟与运营成本。Manus的场景与聊天机器人不同，大多数任务中输入输出比例达到100:1，即100个输入Token才生成1个输出Token，输入侧的优化空间极大。

从成本与速度来看，以Claude Sonnet为例，缓存Token每百万仅需0.30美元，未缓存则需3.00美元，相差10倍；启用KV-Cache后，推理速度可提升约5倍。而Manus上线至今已处理超过147万亿个Token，在这个规模下，KV-Cache命中率每提高1%，都能带来显著的成本节省与体验提升。

为了提高命中率，Manus采取了三大关键策略：一是保持Prompt前缀稳定（Prefix Caching），禁止在System Prompt头部放置时间戳等动态信息，将其统一放在上下文末尾，这样当输入开头与上次请求一致时，系统可直接复用缓存的KV状态；二是上下文只追加更新，历史对话记录设计为不可变，即使需要压缩上下文，也通过截断头部或外部存储实现，绝不修改中间内容，避免破坏缓存；三是明确标记缓存断点，针对不支持自动前缀缓存的模型，手动插入缓存断点，强制保存中间状态，确保缓存复用的稳定性。

2. 响应预填充：解决工具选择难题

前文提到，工具数量增加会导致模型选择错误的概率上升，进而引发性能暴跌。Manus最初尝试动态加载工具集，类似RAG的按需检索方式，但这种做法会破坏KV-Cache——工具定义通常放在上下文开头，任何修改都会导致后续缓存失效。

最终Manus选择了“响应预填充（Prefill Response）”方案：工具定义在上下文中固定不动，在模型开始生成回复时，系统预先填入部分内容，引导模型走向特定行为。大多数模型都支持这种预填充机制，以Hermes格式为例，函数调用有三种控制模式，Manus通过统一工具命名前缀（如浏览器工具以browser_开头，Shell工具以shell_开头），只需控制预填充长度，就能精确约束Agent的动作空间，无需复杂的状态管理。

更关键的是，Manus在Prompt中硬性规定，Agent必须通过函数调用响应，禁止纯文本回应，即“ You must use function calls to respond ”，这种约束让模型的响应行为更可控，进一步降低了工具选择错误的概率。

3. 文件系统：打造无限上下文

即便当前高级LLM的上下文窗口已扩展到200k，在处理网页内容、PDF文档、API响应等海量信息时，仍容易出现上下文溢出的问题，且上下文过大会导致模型性能下降。Manus的解决方案是将文件系统作为LLM的外接记忆，模仿计算机的虚拟内存机制——上下文窗口是RAM，文件系统是硬盘。

Agent不会将所有外部内容保留在对话历史中，而是将其写入文件，在Prompt中只保留文件路径和摘要。当任务需要细节时，再调用read_file工具按需读取。这种方式既节省了上下文空间，又保证了信息的可恢复性：网页内容可从上下文移除，但URL会保留；文档内容可省略，但文件路径必须留存，需要时可重新读取，避免信息丢失。

4. todo.md：维持大模型的注意力

平均50次工具调用的任务流程，对大模型的注意力是极大的考验——随着上下文增长，模型很容易忘记初始目标，导致任务跑偏。Manus的应对之策是强制Agent定期重写todo.md，在任务推进过程中，不断更新任务执行进度，并将目标与进度刷新到上下文末尾。

这种“复述式”的进度同步，能让LLM时刻关注全局计划，有效缓解注意力丢失问题。比如处理多步骤的数据整理任务时，todo.md会清晰标注“已完成数据爬取，待进行数据清洗，下一步需生成可视化图表”，Agent每次迭代都会看到这份清单，确保任务始终围绕目标推进，不会出现中途偏离的情况。

5. 保留错误信息：实现高效自我修正

大模型的幻觉问题目前无法完全避免，循环执行中难免出现错误。常规做法是清理错误信息后重试，但Manus反其道而行之，将失败的动作和错误堆栈全部保留在上下文中。这种设计的核心逻辑是，让LLM通过错误信息进行少样本学习，快速适应新场景。

比如Agent尝试读取某个文件时返回“文件未找到”，错误信息留在上下文后，下次迭代时Agent就能识别出这条路径无效，主动更换文件路径。错误恢复是优质Agent的核心衡量指标之一，而Manus通过保留错误信息，让模型在试错中不断优化，大幅提升了任务的成功率。

6. 打破Few Shot限制：保持模型的思考灵活性

Few Shot技术通常能提升LLM响应的质量与稳定性，但在Agent系统中有时会起反作用。因为LLM擅长模仿，若上下文充满相似模式，模型可能会盲目遵循重复流程，不再主动思考。Manus曾在简历审查任务中发现，处理到后续简历时，Agent会陷入“打开-阅读-提取-保存”的机械节奏，即便插入新指令，也难以跳出固有模式。

为了解决这个问题，Manus采取了“增加多样性”的策略：同一个搜索工具，有时用{“q”: “…”}，有时用{“query”: “…”}，参数顺序也刻意调整。这些微小变化能打破重复模式，让LLM保持思考的灵活性。这个发现颇为反直觉——通常设计工具会追求标准化，但过度标准化反而会削弱Agent的适应能力，Manus的实践恰恰验证了这一点。

三、执行环境：毫秒级启动的云端虚拟机

决策系统再强大，也需要可靠的执行环境支撑。Agent需要一个能执行代码、安装软件、操作浏览器的真实环境，这个环境必须满足启动快、权限高、隔离性好的要求。Manus最终选择了基于AWS Firecracker的云端虚拟机，截至目前已创建了8000万台虚拟机，而这背后，是对多种方案的反复权衡。

团队最初尝试使用Docker容器，但遇到了两个致命问题：一是启动速度慢，拉取镜像、配置网络、挂载卷等操作通常需要10-20秒，无法满足实时响应的需求；二是Docker作为容器，并非完整操作系统，部分操作无法实现，且资源隔离性不足，难以保障用户数据安全。

经过探索，Manus最终选择了E2B——基于AWS开源的Firecracker微虚拟机技术，能在毫秒级启动轻量级VM。对比E2B、Docker与自建方案的核心维度不难发现，E2B的优势极为明显：

技术维度	E2B	Docker	自建方案
启动速度	~150ms	10-20秒	需数月开发，无明确指标
操作系统功能	完整Linux系统	容器级功能，不完整	需3-5名工程师搭建完整功能
可扩展性	自动扩展，适配海量用户	扩展性一般，需手动配置	需专人维护，扩展成本高
自托管支持	支持，部署便捷	支持，配置复杂	需自行搭建全流程管理体系
上线时间	半天即可完成部署	需额外配置适配，无固定周期	3-5个月开发周期
150毫秒的启动速度，比Docker快了近两个数量级，这让Manus能实现实时响应；而完整的Linux系统则赋予Agent极高的操作自由度，Manus联合创始人Tao Zhang曾直言：“Manus不只是运行几段代码，它使用27种不同工具，需要E2B提供一台完整的虚拟电脑，才能像真人一样工作。”

目前每个用户的任务都在独立的Ubuntu 22.04（linux/amd64）虚拟环境中运行，用户拥有具备sudo权限的ubuntu账号，可自由安装Linux软件包、编译C++代码、运行Docker容器甚至启动Web服务器。系统还预装了Python、JavaScript/TypeScript、Java、Go、C/C++等主流语言，以及React、Vue、Django、Flask、pandas等常用框架，Agent可根据任务需求动态安装额外依赖，让能力边界扩展到整个开源软件生态。

四、数据源与底层模型：可靠性与灵活性的平衡

为了确保处理数据的真实性与时效性，Manus接入了大量权威数据源API，并制定了严格的信息获取优先级：Datasource API > Web Search > 模型内部知识。也就是说，能从官方API获取的数据，绝不依赖搜索引擎；能通过搜索引擎验证的信息，绝不轻信模型的训练知识。这种优先级设计，从源头保障了信息的权威性，避免因模型幻觉导致错误输出。

比如需要查询新加坡天气时，Agent会通过以下代码调用WeatherBank的官方API，直接获取结构化数据：

import sys
sys.path.append('/opt/.manus/.sandbox-runtime')
from data_api import ApiClient
client = ApiClient()
weather = client.call_api('WeatherBank/get_weather', query={'location': 'Singapore'})
print(weather)

这种直接调用官方API的方式，既避免了网页爬取的繁琐，又保证了数据的实时性与准确性，让Manus的输出更具可信度。

在底层模型选择上，Manus做出了一个刻意的战略决策——不自研大模型。团队在博客中解释了背后的原因：在BERT时代，模型必须经过微调与评估才能迁移到新任务，每次迭代需要数周时间，这种缓慢的反馈循环对快速迭代的产品来说是致命的。团队上一个创业公司的惨痛教训就是，从头训练模型做信息提取与语义搜索，结果GPT-3和Flan-T5问世后，自研模型一夜之间变得无关紧要。

因此Manus选择押注上下文工程，不花费精力训练模型，而是专注于如何更好地利用现有顶级模型。这种策略让产品迭代周期从数周压缩到数小时，且与底层模型保持正交——“如果模型进步是上涨的潮水，我们希望Manus成为那条船，而不是固定在海床上的柱子。”

据行业信息分析，Manus使用多个前沿模型组成异构集群，根据任务性质动态路由：Claude 3.5/3.7 Sonnet负责复杂推理与代码生成，Qwen在中文语境下发挥优势，Deepseek-r1专注于任务规划。这种架构让Manus能随时切换到更强的新模型，无需重新训练任何内容，保持技术的领先性。

但这种策略也存在现实问题——高性能架构伴随着海量资源消耗。顶级大模型的Token费用不菲，据报道Manus推出初期的14天内，仅Claude API的调用费用就达到100万美元，处理了超过1亿个Token。每个复杂任务可能触发数百次模型推理，单个任务的边际成本高达数美元。即便通过KV-Cache优化节省了部分成本，但在百亿Token的处理规模下，盈利压力依然不小，这也是Manus没有自研模型的潜在短板。

五、Meta重金收购的底层逻辑

回到最初的问题，Meta为什么愿意花数十亿美元收购Manus？答案藏在Manus的技术验证与战略价值中。

从技术层面看，Manus验证了一个核心公式：Agent = LLM + Environment + Orchestration。在当前大模型能力尚未完全完善的阶段，通过极致的上下文工程与稳健的系统架构，已经能构建出高度可靠的通用智能代理。这套架构不依赖单一技术突破，而是通过工程优化将现有技术的效能发挥到极致，这种可落地、可复用的方案，对Meta来说极具吸引力。

从生态布局来看，Meta拥有全球35亿日活用户与丰富的产品矩阵，这正是通用智能代理的最佳试验田。Manus的智能代理能力可无缝融入Facebook、Instagram、WhatsApp等产品，为用户提供个性化的智能服务，比如自动整理聊天记录、生成社交动态、协助处理工作任务等，进一步提升用户粘性与产品价值。

更重要的是，Manus最宝贵的资产是累积的行动轨迹数据。这些数据包含了Agent如何分解任务、如何修正错误、如何使用工具的详细记录，用这些数据微调Llama模型，能训练出规划能力极强的新一代LLM，这种“行动数据”的价值，是单纯依靠文本训练无法实现的。对Meta来说，这些数据能加速其大模型的迭代，强化在AI领域的竞争力。

Manus团队曾直言，他们的技术原则不是理论推导的结果，而是“反复重写、走进死胡同、在数百万用户中进行真实测试”后得出的实践经验，未必普适，但在实际应用中被证明有效。这种以实践为核心的技术路径，与Meta注重落地的产品策略高度契合。

在AI代理赛道竞争日益激烈的当下，Manus用一套精细化的工程方案，证明了通用智能代理的落地可能性。Meta的收购，不仅是对Manus技术价值的认可，更是对“上下文工程+多智能体协作”这条路径的押注。未来随着Manus的技术与Meta的生态深度融合，或许会催生更具颠覆性的智能产品，重新定义我们与AI的交互方式。

而Manus的成功也给行业带来了启示：在大模型技术日趋同质化的今天，精细化的工程优化与场景化的架构设计，同样能构筑起强大的核心竞争力，成为撬动行业格局的关键力量。