这是一份关于 Manus 联合创始人兼首席科学家 季逸超 深度访谈的详细分析。内容涵盖了他的创业历程、Manus 的诞生与转型、对 AI Agent（智能体）的深刻理解以及对未来的展望。
摘要
本次访谈的主角是 Manus 的联合创始人兼首席科学家 季逸超。他有着非典型的成长路径：出身于北大物理教授与中关村初代创业者的家庭，早在大二就因开发 iOS 第三方浏览器赚得第一桶金，随后在 NLP（自然语言处理）领域深耕，经历过从早期的词向量技术到 BERT 时代的变迁。他的上一段创业经历是试图通过构建自研搜索引擎 Magi 来挑战 Google，虽然在技术上取得了“知识图谱自动构建”等突破，但最终因非技术壁垒和商业化落地困难而告终。这段经历让他深刻意识到“垂直整合”（Vertical Integration）的痛苦以及在巨头垄断下做基础设施的艰难。
在经历了一段大厂工作和短暂的休息后，季逸超加入了由前同事 Xiao Hong（小红）创立的团队，共同打造了 Monica 和随后的 Manus。Manus 的诞生并非一蹴而就，团队最初试图开发一款“AI 原生浏览器”，但在开发数月后，通过冷静的市场分析和自我反思（发现产品不够“酷”、无法说服用户迁移），毅然决定砍掉该项目。这一决策转向促成了 Manus 的诞生——一个运行在云端的、通用的全能 Agent。
Manus 的核心哲学在于不做“工具”，而是模拟“人”。季逸超认为，通用 Agent 不应受限于特定领域的规则（Workflow），而应像人一样，通过通用的接口（屏幕、键盘、鼠标）去操作计算机完成各种任务。Manus 坚持“纯血 Agent”路线，即由智能本身驱动决策，而非人为设定的死板流程。在技术策略上，Manus 选择不自研基座模型，而是通过极其复杂的 Context Engineering（上下文工程）和虚拟化环境（Sandbox），榨干现有最强模型（如 Claude, Gemini, GPT）的能力，并通过巨大的 Token 消耗量反向影响模型厂商的优化方向。对于未来，季逸超坚信 Agent 将从辅助角色转变为生产力的主力，并强调“不作恶”、不仅是替代更是“增强”人类的能力。
内容精简
早期探索与创业复盘：从浏览器到知识引擎
季逸超的创业故事始于移动互联网的蛮荒时期。早在高中时期，他就敏锐地捕捉到了 App Store 带来的全球化变现机会，开发了一款名为“猛浏览器”（Meng Browser）的 iOS 应用。这款产品利用了当时移动网络不稳定的痛点，通过预加载技术优化浏览体验，为他赚取了数十万美元的第一桶金。然而，随着移动互联网巨头的入场和商业模式的变迁（从付费下载转为免费+内购），这款浏览器最终自然消亡。这段经历让他明白了两点：一是技术创新需要结合时代红利；二是纯工具类的产品在巨头面前缺乏护城河。
随后，季逸超投身于 NLP 领域，创立了 Magi。这是一个极具野心的项目，旨在通过 AI 自动阅读全网信息，构建一个无需人工干预的、实时更新的知识图谱，并试图打造下一代搜索引擎。技术上，Magi 实现了从非结构化文本中自动提取实体和关系（Open Information Extraction），在某些指标上甚至超越了 Google 的知识图谱。然而，这次创业也是一次惨痛的教训。季逸超反思道，他们低估了搜索引擎的非技术壁垒（如数据源生态、用户习惯），且在商业化上过于理想化。更重要的是，他深刻体会到了“垂直整合”的痛苦：作为一家初创公司，既要自研底层模型，又要搭建基础设施，还要做上层应用，这导致产品迭代深受模型研发周期的拖累。每当大厂（如 Google 或 OpenAI）发布一个通用的新模型，他们数月的垂直优化可能瞬间变得毫无意义。这种“被降维打击”的 PTSD（创伤后应激障碍）直接影响了他后来在 Manus 的技术选型——坚决不自研基座模型，而是专注于应用层和 Agent 框架。
Manus 的诞生：并在云端重塑计算
Manus 的诞生源于一次“壮士断腕”般的转型。加入 Monica 团队后，季逸超和小红最初的想法是利用他们在浏览器插件上的成功经验，打造一款独立的“AI 原生浏览器”。团队投入了数月时间，甚至产品已经开发到了可用的阶段。然而，在内部测试和深度思考后，他们发现这款产品存在致命逻辑硬伤：
- 端侧模型的局限：在用户本地运行模型既费电又无法提供最顶级的智能体验。
- 体验的割裂：让 AI 接管用户的本地浏览器会打断用户的操作流（例如 AI 在填表时，用户无法随意滚动屏幕），这就像两个人抢一台电脑，体验极差。
- 价值存疑：并没有什么功能是必须通过独立浏览器才能实现，而插件做不到的。
在看到 The Browser Company (Arc 浏览器) 创始人的反思后，团队达成共识：浏览器不适合作为创业公司的颠覆方向。此时，他们观察到了 Cursor（AI 代码编辑器）的非典型用法——很多非程序员用它来做数据分析、写文章，甚至只是单纯地聊天。这让他们意识到：编程不是一个垂直领域，而是一种通用的解决问题的媒介。
于是，Manus 的概念应运而生：一个运行在云端的、通用的 Agent。它不再运行在用户的本地设备上，而是拥有自己独立的云端虚拟机（Sandbox）。这意味着 Manus 可以像一个随时待命的远程实习生，在云端 7x24 小时地通过浏览器、命令行、代码环境去执行长链路的任务（Long-horizon tasks），而不会占用用户的本地算力或干扰用户的正常操作。这种“云端浏览器”（Browser in the Air）的架构，让 Manus 能够并发处理大规模任务（如同时调研 100 家公司的 CEO），这是传统 Chatbot 或本地 Agent 无法想象的。
通用 Agent 的哲学：做“人”而非做“工具”
Manus 的核心产品哲学是坚持做“通用 Agent”（General Agent）。季逸超认为，市面上大多数所谓的 Agent 其实是 Workflow（工作流），即通过人为设定的规则和步骤来约束 AI 的行为。这种做法虽然短期内能提高稳定性，但天花板很低，因为它扼杀了智能模型的泛化能力和创造力。
Manus 选择了一条更难的路：模拟人，而非制造工具。
- 输入输出的通用性：就像人类通过眼睛看屏幕、通过手敲键盘鼠标来操作电脑一样，Manus 通过通用的接口与数字世界交互。它不依赖于特定的 API（虽然有 API 更好），而是能够像人一样阅读文档、学习软件使用方法，甚至在遇到未知文件格式时，自动去 GitHub 下载解析工具来处理。
- 纯血 Agent（Pure-blood Agent）：季逸超强调，Manus 的决策过程是由智能模型（Intelligence）主导的，而非规则代码。例如，在进行数据可视化时，Manus 不是被代码写死“必须用红色柱状图”，而是具备审美和纠错能力。如果生成的图表不好看或有重叠，Manus 能像人一样“看”一眼（多模态能力），意识到问题并自动修改。
- 拒绝人格化：虽然 Manus 模拟人的操作能力，但季逸超反对将其“人格化”或强行赋予其人类的组织架构（如强行分为产品经理、程序员等角色）。他认为模型拥有比人类更全面的知识，不应受到人类分工局限的束缚。
这种通用性带来了巨大的网络效应潜力。Manus 不仅仅是一个单点工具，它能串联起各种垂直 SaaS 服务（如 Notion, Stripe, Linear）。通过“原子能力的组合”，Manus 的能力随着集成服务的增加而指数级增强，最终形成一个以通用 Agent 为中心的生态网络。
技术策略：借力打力与反向定义模型
在技术路线上，Manus 采取了极具智慧的“借力打力”策略。吸取了上一段创业的教训，Manus 坚决不涉足基座模型的训练，而是通过极高的 Token 消耗量和高质量的反馈数据，反向影响上游模型厂商（OpenAI, Google, Anthropic）。
- 成为模型厂的“甲方”：由于 Agent 的运作模式是“思考-行动-观察”的无限循环，Manus 的 Token 消耗量是普通 Chatbot 的百倍甚至千倍。这使得 Manus 成为全球各大模型厂商的顶级客户。季逸超利用这一话语权，直接向模型厂商提需求，甚至参与定义新的 API 标准（如 Google 的并行 Function Calling）。
- Context Engineering（上下文工程）：Manus 的核心技术壁垒在于如何构建 Agent 的运行框架。这包括如何让模型意识到“记忆压缩”的必要性、如何管理云端文件系统、如何设计非原生的 Action Space 等。他们发现，与其追求无限长的 Context Window，不如训练模型学会像人一样“做笔记”和“遗忘”。
- 弱到强的泛化验证：为了确保架构的领先性，Manus 团队会用较弱的模型（如 Claude 3 Haiku）来打磨 Agent 框架，确保当更强的模型（如 Claude 3.5 Sonnet）发布时，Agent 的能力能获得最大的增益（Delta）。这种策略保证了 Manus 永远是模型能力进步的最大受益者，而非受害者。
季逸超认为，未来的 AI 竞争中，应用层公司拥有独特的数据飞轮——用户的行为轨迹（Trajectory）和修正反馈（Feedback）。这些数据是基座模型厂商无法直接获取的，也是 Manus 能够持续优化体验、构建壁垒的关键。
问答
1. Manus 为什么不做垂直领域的 Agent，而坚持做通用 Agent？ 答： 季逸超认为垂直 Agent 本质上是在做“工具”，而通用 Agent 是在模拟“人”。从技术架构上看，底层模型和运行环境（虚拟机）本身就是通用的，做垂直反而是在人为增加约束。从商业逻辑看，通用 Agent 能够覆盖用户的长尾需求，捕捉那些无法被单一垂直产品满足的场景（如处理冷门文件格式），从而给用户带来惊喜（Aha moment）。此外，通用 Agent 具有更强的品牌心智和使用频次，避免了垂直工具低频、难留存的问题。
2. 为什么 Manus 选择不自研基座模型？ 答： 这是一个基于过往失败教训的战略选择。季逸超在上一段创业中深受“垂直整合”之苦，产品迭代被模型研发拖累。在 AI 时代，基座模型竞争极其激烈且同质化，应用层公司自研模型不仅成本高昂，而且很难跑赢巨头。Manus 选择将模型训练“外包”给巨头，利用自身巨大的 Token 消耗量和业务场景数据，反向要求模型厂商优化，从而保持产品的敏捷性和领先性。
3. Manus 如何应对 OpenAI 或 Google 等巨头的竞争？ 答： 季逸超认为这是一种“竞合关系”。虽然巨头也在做 Agent，但他们的包袱更重。例如，ChatGPT 的 Agent 仍然是 Chatbot 的附属品，面向的是大众市场；而 Manus 专注于服务对质量要求极高的“Prosumer”（专业消费者），这部分人群需要的是极致的生产力工具而非简单的问答。此外，Manus 的通用架构使其能灵活调用各家最强的模型（如用 Claude 写代码，用 Gemini 看视频），而单一模型厂商往往受限于自家模型。
4. 早期 Manus 发布时为什么要使用邀请码机制？ 答： 这并非为了饥饿营销，而是受限于当时的云端算力。Agent 的运行机制导致其对推理算力（Inference Compute）的需求是传统 Chatbot 的数十倍甚至上百倍。在 Manus 发布初期，全球各大云厂商都没有准备好应对如此高并发的 Agent 负载。为了防止系统崩溃，团队不得不通过邀请码来严格控制用户数量。这也侧面反映了 Agent 是一场对基础设施的全新挑战。
5. 季逸超如何看待 AI 时代的组织架构和人才？ 答： 他认为 AI 时代的组织不需要像传统软件公司那样庞大。Manus 团队保持了精简（约 100 人），但极度推崇全员使用 AI 工具。团队中有两个特殊的部门：Sandbox Team（负责维护云端操作系统，教 AI 用电脑）和 Agent Team（负责 Agent 框架和评估）。他特别强调“身心健康”对创业者的重要性，拒绝“艺术家”式的偏执，推崇理智、务实和快速试错的文化。