W
AI-Wiki
ENTITY

Manus

定义或身份

Manus 是一款通用 AI Agent 产品，也是其团队总结 Agent上下文工程实践 摘要 的核心实验载体。

在文中，Manus 不是一个单点能力工具，而是一个围绕“长链路任务如何稳定完成”而设计的通用智能体系统。它依托前沿大模型的上下文学习能力构建 Agent，而不是优先走“训练一个端到端基础智能体模型”的路线。

这一选择与团队早期经验直接相关。Peak 提到，在更早的 NLP 时代，模型迁移到新任务往往需要先微调再评估，每次迭代可能耗时数周；而对 PMF 之前、需要快速试错的产品来说，这种反馈速度几乎不可接受。其上一家创业公司曾从零训练开放信息抽取和语义搜索模型，但在 GPT-3 与 Flan-T5 出现后迅速失去优势。也正因如此，Manus 明确押注 上下文工程：希望把改动周期从“数周”压缩到“数小时”。

Peak 用一句话概括这种产品定位：如果模型进步是上涨的潮水，他们希望 Manus 是船，而不是钉在海床上的柱子。也就是说，Manus 的产品设计目标之一，就是尽量与底层模型演进保持正交，在模型升级时能快速吸收收益，而不是被绑定在某一代自研模型能力上。

角色职责

作为通用 Agent，Manus 的职责不是只回答问题，而是在接到用户任务后，持续通过工具调用、环境交互、观察结果累积与下一步决策，完成多步骤任务。

文中描述的典型循环是：

  • 接收用户输入；
  • 模型基于当前上下文，在预定义动作空间中选择一个动作；
  • 在环境中执行动作；
  • 读取动作产生的观察结果；
  • 将动作与观察追加进上下文；
  • 进入下一轮，直至任务完成。

在 Manus 的实现中，这个环境可以是带工具的执行环境，例如虚拟机沙箱。其职责边界因此比普通聊天机器人更宽：不仅要“生成答案”，还要在多轮执行中维持计划、选择工具、处理错误、保留记忆，并在上下文不断膨胀的情况下继续稳定行动。

文中还给出了一个重要量化特征：Manus 的典型任务平均需要约 50 次工具调用。这说明它面向的是需要持续行动和中途修正的复杂任务，而不是一问一答式的短事务。

关键信息

1. 作为通用 Agent，Manus 强调能力之间的复合效应

Peak 提到，团队讨论某个功能实现时，会习惯性追问：这个功能能不能在产品里形成网络效应。

对 Manus 而言，每新增一项能力，目标都不是孤立地多一个功能点，而是让它与已有能力产生耦合后的复合收益。文中给出的例子是：加入图像读取能力后，Manus 不仅能看图，还能自行调试其生成的数据可视化代码，甚至“神奇地修复其他模块的问题”。

这说明 Manus 的产品观并非简单功能堆砌，而是重视能力单元之间相互增强的效果。这与 可组合能力单元设计 的思路高度一致：单一能力是否可用只是起点，更关键的是它进入系统后，是否能放大其他能力的上限。

2. Manus 依托前沿模型构建，而不是重投入训练端到端 Agent

团队在项目初始阶段面临过一个明确抉择：

  • 方案一：利用开源基础模型训练一个端到端智能体；
  • 方案二：依托前沿模型的上下文学习能力，在其之上构建智能体。

Manus 最终选择了第二条路。原因不是理论偏好，而是迭代效率与产品生存现实：

  • 可以在几小时内发布改进，而不是等几周；
  • 能更快进行产品试错；
  • 能随着底层模型进步同步升级，而不必重走训练周期；
  • 在 PMF 前阶段更适合快速探索。

因此，Manus 在文中的身份不仅是“一个 Agent 产品”，也是“围绕大模型上下文学习能力进行工程封装”的产品样本。

3. Manus 的方法来自多次真实重构，而非一次性定型

Peak 明确表示，围绕上下文工程，Manus 已经四次重构智能体框架。触发重构的原因不是抽象的架构洁癖，而是每次都发现了“更好的上下文塑造方式”。

团队把这种手工架构搜索、提示微调和经验试错的过程戏称为“随机梯度下降（Stochastic Graduate Descent）”。这个说法本身也传达出 Manus 的工程风格：

  • 上下文工程不是纯理论推导，而是实验科学；
  • 好方案往往是在大量失败和局部最优中收敛出来的；
  • 架构、提示、工具组织与执行状态管理都需要反复重写。

因此，Manus 不是一套从第一天就稳定成型的 Agent 框架，而是一个不断重构、不断吸收生产反馈的系统。

4. Manus 的核心实践围绕上下文工程，而不是单纯提示词优化

文中把 Manus 总结出的关键方法集中在上下文塑造上，主要包括：

这些实践共同说明，Manus 所说的 Agent 能力，不是建立在一个超级提示词上，而是建立在上下文结构、执行环境、记忆外化、动作约束和错误恢复机制之上的工程系统。

细节与边界

KV 缓存是 Manus 视角下最关键的生产指标之一

Peak 直言，如果只能选一个指标，KV 缓存命中率可能是生产级 AI Agent 最重要的单一指标，因为它直接影响延迟和成本。

这与聊天机器人不同。Manus 这类 Agent 在多轮工具调用中，上下文每一步都持续增长，而每步输出通常只是较短的结构化函数调用。文中给出的平均比例是：输入 token 与输出 token 约为 100:1。这意味着预填充成本远高于解码成本，缓存命中率对总体性能的影响极大。

文中还给出具体价格差异：以 Claude Sonnet 为例，缓存输入 token 的价格是 0.30 美元/百万 token，而未缓存输入 token 是 3 美元/百万 token，相差 10 倍。

因此，Manus 的一些工程边界非常明确：

  • 系统提示前缀要尽量稳定；
  • 避免在前缀中插入精确到秒的时间戳，否则哪怕只差一个 token，也会让后续缓存失效；
  • 上下文应保持追加式，而不是回写式修改；
  • 动作和观察的序列化必须确定性稳定，例如 JSON 键顺序不能漂移；
  • 某些推理框架若不自动支持增量前缀缓存，就必须手动插入缓存断点，且至少要覆盖系统提示末尾；
  • 若采用 vLLM 等自托管框架，还要确保启用前缀/提示缓存，并通过会话 ID 等方式把同一会话稳定路由到一致工作节点。

这也解释了为什么 Manus 不愿频繁改动前部工具定义：一旦上下文前缀变化，整条长链路的缓存收益就会被破坏。