Manus 产品立项初期会议纪要

Manus张涛：

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

尤其爱好 Manus 本身写的这句：一个旨在从新定义智能体、致⼒于成为⼈类强⼤⼼智延长的摸索之旅，由此正式启航。」

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

https://mp.weixin.qq.com/s/Ud0djNpSAqUoFUYpTzasmg

---

01 引言 

本文基于 Manus 项目立项初期的两次核心评论辩论灌音文字稿整顿而成。与第一版纪要比拟，本扩大版旨在更深刻、更过细地还原评论辩论的全貌，不仅保存了核心议题与时光脉络，更弥补了大年夜量的细节、思辨过程以及富有启发性的类比。文章力争周全展示团队人在产品哲学、技巧架构、用户体验及市场策略等方面的深度碰撞，为 Manus 项目标后续成长供给一份更饱满、更具参考价值的奠定性文档。

Red

Peak

评论辩论的最后，团队敏捷行动，成立了项目组，共享了前期材料，并明白了在产品定义和技巧架构上的分工。一个旨在从新定义智能体、致力于成为人类强大年夜心智延长的摸索之旅，由此正式启航。

范斌

张涛（hidecloud）

潘潘（PanPan）

 

03 核心议题摘要

评论辩论的核心议题在扩大后，可以更过细地归纳为以下几个方面：

• 产品哲学：在「无所不克不及的通用智能体」与「精晓特定范畴的垂直专家」之间，Manus 应若何定位？这引出了关于产品核心成长路径的「百度模式」与「Hao123 模式」的计谋类比。

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

  技巧架构：若何构建一个真正具备「代理」（Agency）才能的云端情况？重点商量了「云端浏览器」的实现路径、跨会话的「状况持久化」这一核肉痛点，以及安然与易用性的均衡。

• 用户体验：产品的界面应若何设计，以同时知足「只算作果」的治理者与「关怀过程」的工程师？这涉及到信赖建立、信息过载、以及「渐进式披露」的设计理念。

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

• 人机协作模式：Agent 的价值毕竟在何处？评论辩论从克服人类的认知局限，到具体的义务履行细节，摸索了人与 Agent 之间幻想的协作与互动模式。

 

05 结论与后续步调

 

04 具体评论辩论记录

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 的运行情况是一个完全的「带桌面情况的虚拟机」，那么它完全可以经由过程模仿人的键鼠操作来直接应用这些专业业软件，从而将通用性推向新的高度。

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

若何将产品哲学落地，关键在于技巧架构的设计。评论辩论的核心集中在若何解决当前 Agent 产品的核肉痛点，构建一个真正稳定、持久且强大年夜的履行情况。

4.2.1.「云端浏览器」与长途交互

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

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

4.2.2. 核肉痛点：状况持久化（Persistence）

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

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

此外，Red 还指出了另一个潜在问题--常识冲突。一个无所不学的的通用 Agent，可能会在不合范畴的常识上产生混淆。例如，用于数据科学的严谨常识，可能与用于市场案牍的创意常识在底层逻辑上是冲突的。这暗示了将来可能须要某种情势的「范畴隔离」或「常识分区」机制。

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:「其实我用 DEV 的时刻不太看右边... 但当然他展示出右边我认为是有意义的... 对，就是信赖问题。那个很重要，就是他正儿八经在搞。」

4.3.2. 对 Devin 界面的批驳与超出

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

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

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

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

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

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

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

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

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

  评论辩论中，团队还花时光商量了 Agent 存在的根本价值，即它若何成为人类才能的延长和弥补。

  4.4.1. 克服人类的认知局限

   

  02 评论辩论介入者

  • 潘潘（PanPan）和张涛（hidecloud）认为，人类在履行复杂义务时存在诸多局限，而这恰是 Agent 的优势地点：

    • 经验主义陷阱：人偏向于依附以前的成功经验，即「不知道本身不知道」，从而错过更优的解决筹划。

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

    • 第一性道理：Agent 则可以不知疲惫地、始终从「第一性道理」出发，经由过程全局搜刮和评估，寻找义务的最短路径。

    潘潘（PanPan）:「人最大年夜的问题我认为还有一个就是不知道本身不知道。」

    张涛（hidecloud）:「然则他永远都邑去第一性道理全局激活。」

    4.4.2.EVE>评论辩论中一段关于游戏《EVE>这恰好揭示了 Agent 的一个潜在的高价值应用处景：作为复杂体系的「总调剂官」或「超等助理」，赞助人类治理和优化那些超出了单人认知和履行才能上限的宏大年夜工程。

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

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

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

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