Manus创业历程：从爆火到争议，核心技术揭秘

作者 林易

编辑 重点君

从全球爆火，到成功融资，再到被曝删博、裁员、跑路新加坡，Manus仅仅用了四个月，就把一条新兴赛道的创业演示了个遍。

有人认为Manus开了一个很坏的头，利用中国工程师资源打造产品，迅速融资，裁员跑路......

在一片争议声中，今天凌晨，这家公司的联合创始人季逸超罕见发声，发布了长达数千字的博客，试图把舆论拉回到产品和技术本身，也第一次公开回应了这场起落背后的关键教训。

四个月从爆火到争议

我们先简单回顾一下。今年3月，Manus因“全球首个通用Agent”概念走红，当时有人说这是中国的“第二个DeepSeek时刻”。

5月，Manus很快完成由硅谷顶级风投Benchmark领投的7500万美元B轮融资，估值飙升至5亿美元。外界对它的一度期待极高。

但6月底，Manus突然被媒体曝出多起争议事件：部分员工称被无预警裁员、创始团队在社交平台上大规模删博、公司主体搬到新加坡，舆论哗然。

一时间，删博、裁员、跑路，成了这家明星Agent创业公司的主要标签。

联合创始人凌晨发长文

面对外界质疑，季逸超这次选择用一篇技术向的长文作答，首次系统总结了团队对Agent产品和技术的核心认知：

1、选择上下文工程，而非端到端自研大模型。Manus创始人上一家公司曾尝试从零训练NLP模型，结果被GPT-3等大模型淘汰。这次复盘后，他们选择不再自研底层模型，而是专注于如何基于开源或商业大模型，做“上下文工程”，把现有能力最大化发挥出来。

2、KV缓存命中率是代理系统的核心指标。多轮智能代理与单轮聊天不同，输入输出比可能高达100:1，长输入会极大影响延迟和推理成本。上下文设计的目标是最大化KV缓存命中率，这要求提示要稳定、上下文只追加不修改、保证前缀可重复利用。

3、工具管理避免动态增减，用遮蔽代替删除。代理功能多，动作空间会迅速扩大，模型更易选错。动态添加或删除工具会导致缓存失效。Manus的实践是用上下文状态机管理工具可用性：通过屏蔽Token概率，而非直接从上下文移除，既保证灵活性，又保留缓存。

4、把文件系统当作无限上下文。大模型上下文窗口再大也有限，且超长上下文会拉低推理速度、抬高成本。Manus做法是把文件系统当作代理的外部记忆，信息可随时存取，保证历史状态可查、可读写、可恢复。

5、用显式“背诵”机制操控模型注意力。在长任务中，Manus会自动生成todo.md，把任务拆解成可执行清单，并不断更新，把目标重复写到上下文末尾，相当于“反复提醒模型”，避免任务中途跑偏。

6、不抹掉错误，保留失败信息以帮助模型自我修正。智能体必然会出错，与其隐藏错误、重新开始，不如把失败信息留在上下文里，让模型“看到”失败路径，形成负面示例，从而减少同类错误。

7、一句话总结就是：上下文工程是一门新兴的实验科学，Manus想用上下文塑造代理的行为和能力：不是比拼模型多聪明，而是比拼怎么让模型更有用。

复盘之外，争议未平息

从这篇博客看得出，Manus并非完全是个“PPT项目”。它确实做了不少面向Agent场景的底层探索，也踩过不少坑。

但这篇长文没提到外界最关心的问题：公司为什么要搬去新加坡？国内被裁员工如何善后？等等。

这些问题，季逸超没有回答，博客里也没提。

季逸超在结尾写道：“智能代理的未来将由一个个情境逐步构建。精心设计每一个情境。”

当下的现实是，Manus是否还有机会把这些“情境”从技术文档带回真正的用户手里？

一切仍未有定论。

博文链接：

https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

   以下为Manus 联合创始人季逸博客原文（由GPT翻译）：

面向AI 代理的上下文工程：构建 Manus 的经验教训