Manus 产品立项初期会议纪要

Manus 张涛：

「前几天翻出来去年 Manus 正式立项那天我们几个讨论的录音，交给 Manus 整理成了这个文件。回头看去这一年，基本上是把当时讨论的点都实现到了。算是很有价值的一次讨论了。

尤其喜欢 Manus 自己写的这句：一个旨在重新定义智能体、致⼒于成为⼈类强⼤⼼智延伸的探索之旅，由此正式启航。」

以下为会议纪要完整内容，来自「潜云思绪」。

引言 

本文基于 Manus 项目立项初期的两次核心讨论录音文字稿整理而成。与初版纪要相比，本扩展版旨在更深入、更细致地还原讨论的全貌，不仅保留了核心议题与时间脉络，更补充了大量的细节、思辨过程以及富有启发性的类比。文章力求全面展现团队人在产品哲学、技术架构、用户体验及市场策略等方面的深度碰撞，为 Manus 项目的后续发展提供一份更丰满、更具参考价值的奠基性文档。

讨论参与者

• Red

• Peak

• 范斌

• 张涛（hidecloud）

• 潘潘（PanPan）

核心议题摘要

讨论的核心议题在扩展后，可以更细致地归纳为以下几个方面：

• 产品哲学：在「无所不能的通用智能体」与「精通特定领域的垂直专家」之间，Manus 应如何定位？这引出了关于产品核心发展路径的「百度模式」与「Hao123 模式」的战略类比。

• 技术架构：如何构建一个真正具备「代理」（Agency）能力的云端环境？重点探讨了「云端浏览器」的实现路径、跨会话的「状态持久化」这一核心痛点，以及安全与易用性的平衡。

• 用户体验：产品的界面应如何设计，以同时满足「只看结果」的管理者与「关心过程」的工程师？这涉及到信任建立、信息过载、以及「渐进式披露」的设计理念。

• 人机协作模式：Agent 的价值究竟在何处？讨论从克服人类的认知局限，到具体的任务执行细节，探索了人与 Agent 之间理想的协作与互动模式。

详细讨论记录

4.1. 产品哲学：通用性与垂直优化的战略抉择

讨论的起点，是关于 Manus 核心定位的思辨。这不仅是功能层面的选择，更关乎产品的长期发展范式。

4.1.1.「百度 vs.Hao123」:两种发展范式的隐喻

Red 提出了一个深刻的类比，将两种不同的 Agent 发展路径比作「百度」与「Hao123」的模式差异。

• Chatbot/Hao123 模式：像传统的 Chatbot 或导航网站，开发者作为「供给侧」，预先实现和集成各种特定功能（链接）。用户能做的事情，被限制在开发者已经提供的能力范围内。这种模式拓展缓慢，且容易陷入同质化竞争。

• Agent/百度模式：首先打造一个具备强大通用能力的底层平台（像搜索引擎，能爬取和理解一切）。这个平台因其通用性，吸引大量用户尝试各种各样的任务（Query）。然后，通过分析高频、高价值的 Query，反向进行优化，推出「框计算」或「阿拉丁卡片」那样的「预设能力」（Preset），使得常见任务能够被「秒级」完成。

Red:「我觉得就是这个类比好，123 加 link 跟百度做抓链接卡片，是两个完全不同的，就是有本质区别的...Chatbot 为什么它现在有瓶颈了？就是它给人感觉是非常通用，但实际上没有那么通用。」

这一思路获得了团队的普遍认同，确立了 Manus「通用性优先，逐步沉淀和优化高频场景」的核心战略。通用性是获客和探索可能性的基础，而后续的优化则是构建核心竞争力和护城河的关键。

4.1.2. 通用性的边界：专业软件与知识冲突

尽管确立了通用性优先，但其边界和挑战也被充分讨论。

范斌提出了一个现实的挑战：对于像专业视频剪辑这样的任务，一个通用的 Agent 如何与 Final Cut Pro 或 Premiere 这样的专业软件竞争？他认为，Agent 在理解和操作复杂图形界面（ComputerUse）方面，短期内难以实现质的突破。

Peak 则给出了一个更具未来感的设想：如果 Agent 的运行环境是一个完整的「带桌面环境的虚拟机」，那么它完全可以通过模拟人的键鼠操作来直接使用这些专业业软件，从而将通用性推向新的高度。

此外，Red 还指出了另一个潜在问题--知识冲突。一个无所不学的的通用 Agent，可能会在不同领域的知识上产生混淆。例如，用于数据科学的严谨知识，可能与用于市场文案的创意知识在底层逻辑上是冲突的。这暗示了未来可能需要某种形式的「领域隔离」或「知识分区」机制。

4.2. 技术架构：构建真正的「云端代理」

如何将产品哲学落地，关键在于技术架构的设计。讨论的焦点集中在如何解决当前 Agent 产品的核心痛点，构建一个真正稳定、持久且强大的执行环境。

4.2.1.「云端浏览器」与远程交互

实现 Agent 对 Web 的复杂操作，是项目的技术基石。团队探讨了「Browser in Browser」的概念，即在用户的浏览器中，运行一个来自云端的、被 Agent 完全控制的浏览器实例。

张涛（hidecloud）调研并分享了一个名为 XPRA 的开源项目。该项目能将远程应用的界面以流式（Streaming）的方式传输到前端，并且只传输发生变化的像素区域，这为实现低延迟的远程应用交互提供了可行的技术参考。

张涛（hidecloud）:「…这个项目他自己都带了一个那个 H5 的一个客户端，就是直接显示他 Server 那边传输过来的东西.. 很符合我们这种需求嘛。」

4.2.2. 核心痛点：状态持久化（Persistence）

团队一致认为，当前市面上 Agent 产品（如 Devin）最大的短板在于其「一次性」的会话机制。每次任务都是一个全新的、无菌的环境，这导致了大量重复工作和糟糕的用户体验。

Peak:「Devin 的 session 的 credential 不能持久化。对，这也是咱们一定要解决的事儿。…. 这我觉得 agent 就 agency 最重要一点，这才真正代理，要不然他其实一次性的。」

Manus 必须从根本上解决这个问题，实现全面的状态持久化。讨论中明确了需要持久化的几个关键部分：

• 登录状态（Cookies&LocalStorage）:这是实现真正「代理」的基石。Agent 必须能够保持在各种网站上的登录状态，避免每次都需要用户手动介入。团队的目标是，用户只需登录一次，Agent 就能长期代表用户进行操作。

• 文件系统：为每个用户或每个项目提供一个持久化的工作目录。所有生成的文件、下载的数据、编写的代码都应该被保存下来，方便在不同会话之间复用和选代。

• 环境变量与密钥管理：对于 APIKeys 等敏感信息，直接写入代码或使用传统的。env 文件都存在安全隐患或体验问题。Devin 的做法是提供一个独立的 secret 配置界面。Manus 需要设计一套既安全又对开发者友好的密钥管理系统。

4.2.3. 用户接管（Interactive Mode）

在 Agent 遇到障碍（如复杂的验证码、两步验证登录）时，必须有一个流畅的机制让用户能够「接管」浏览器，完成操作后，再将控制权交还给 Agent。这被认为是弥补当前 AI 能力不足、确保任务能顺利完成的关键环节。

4.3. 用户界面与交互体验：在「信任」与「控制」之间寻求平衡

产品的界面设计，被认为是决定用户接受度的关键。讨论围绕着 Devin 的界面布局展开，并对其优缺点进行了深入剖析。

4.3.1. 界面的双重角色：建立信任与提供控制

Devin 的界面分为左右两栏：左侧是对话流，右侧是 Agent 的工作区（Planner，Shell，Browser）。团队发现，这个设计巧妙地服务了两类不同的用户心智：

• 对于管理者/非技术用户（以 Red 为代表）:他们可能并不关心右侧窗口里具体的代码或命令，但这个窗口的存在，动态地展示了 Agent「正在忙碌」，从而建立起一种「它在认真干活」的信任感。

• 对于工程师/专业用户（以潘潘、范斌为代表）:他们需要看到过程的细节，以便进行调试、监督和修正。右侧的工作区为他们提供了这种必要的「控制感」和透明度。

Red:「其实我用 DEV 的时候不太看右边... 但当然他展示出右边我觉得是有意义的... 对，就是信任问题。那个很重要，就是他正儿八经在搞。」

4.3.2. 对 Devin 界面的批判与超越

尽管 Devin 的设计有其合理性，但团队也指出了其明显的不足：

• 信息过载：一上来就将所有工作组件（Planner，Shell，Browser，Editor）全部平铺给用户，会造成巨大的认知负担，尤其是对新用户。

• 缺乏全局概览：潘潘（PanPan）尖锐地指出，其 Editor 没有文件目录树，这对于任何写过代码的人来说都是难以忍受的。「我都没有一个 overview」，这使得理解和修改一个稍复杂的项目变得异常困难。

• 功能组织混乱：将表格、文档等不同类型的内容都塞进一个「Browser」标签页里，既不符合用户直觉，也限制了未来的扩展性。

基于这些批判，团队提出了 Manus 的 Ul 设计哲学：

• 渐进式披露（Progressive Disclosure）:默认呈现给用户的应该是一个极其简洁的界面（可能只有一个对话框）。随着任务的展开，Agent 所使用的工具（如 Shell，Browser）才作为独立的窗口或标签页「浮现」出来。

潘潘（PanPan）:「我觉得它 confuse 原因是不是因为上来它就什么都在？就如果你想象右边这个类似于就是普通用户用 Windows 的那个任务栏，一开始其实是只有 plaanner，然后它一点一点随着工作逐渐出来...」

• 操作系统隐喻（OS-like Metaphor）:将不同的核心功能（如浏览器、表格、文档编辑器）设计成独立、平等的「一级应用」，而不是混乱地嵌套。用户可以在这些「应用」之间切换，就像在 Windows 或 macOS 中一样。这为未来的功能扩展提供了清晰、可伸缩的框架。

4.4. 人机协作：Agent 作为人类心智的延伸

讨论中，团队还花时间探讨了 Agent 存在的根本价值，即它如何成为人类能力的延伸和补充。

4.4.1. 克服人类的认知局限

潘潘（PanPan）和张涛（hidecloud）认为，人类在执行复杂任务时存在诸多局限，而这正是 Agent 的优势所在：

• 经验主义陷阱：人倾向于依赖过去的成功经验，即「不知道自己不知道」，从而错过更优的解决方案。

• 缺乏持续性：人很难长时间、高强度地专注于一个任务而不分心。

• 第一性原理：Agent 则可以不知疲倦地、始终从「第一性原理」出发，通过全局搜索和评估，寻找任务的最短路径。

潘潘（PanPan）:「人最大的问题我觉得还有一个就是不知道自己不知道。」

张涛（hidecloud）:「但是他永远都会去第一性原理全局激活。」

4.4.2.EVE Online 的启示：复杂系统与长期规划

讨论中一段关于游戏《EVE Online》的「题外话」，实际上为 Agent 的应用场景提供了一个有趣的类比。EVE 是一个拥有极其复杂的经济系统和生产链的科幻网网游，玩家需要像经营一个国家一样，进行长期的资源规划、生产调度和战略博弈。许多玩家军团甚至需要使用 Excel 表格来管理其庞大的生产体系。

这恰恰揭示了 Agent 的一个潜在的高价值应用场景：作为复杂系统的「总调度官」或「超级助理」，帮助人类管理和优化那些超越了单人认知和执行能力上限的庞大工程。

结论与后续步骤

这两次深入的讨论，不仅为 Manus 项目的正式启动扫清了思想上的障碍，更形成了一系列宝贵的、可指导后续工作的核心原则。

• 战略层面，确立了「通用性平台+高频场景优化」的双轮驱动策略。

• 技术层面，明确了以「状态持久化」和「云端浏览器」为核心，构建真正具备「代理」能力的架构。

• 产品层面，提出了以「渐进式披露」和「操作系统隐喻」为指导，打造兼具信任感与控制感的下一代 Agent 界面。

讨论的最后，团队迅速行动，成立了项目组，共享了前期资料，并明确了在产品定义和技术架构上的分工。一个旨在重新定义智能体、致力于成为人类强大心智延伸的探索之旅，由此正式启航。

文章来自微信公众号 “ Founder Park ”