从Openclaw回看Manus的产品哲学Manus在成立之初定位的开发AI浏览器，通过LLM的推理能力，自动操作浏览器帮助用户完成各种复杂任务，但是最终这个想法没有成功，manus团伙曾经分享过原因：认为这个方案在真实场景中暴露了一个致命问题：当AI接管浏览器控制权时，用户界面被锁定，人无法进行任何干预。这种“浏览器不可用”的状态，严重割裂了用户的工作流，破坏了核心体验。从我的视角观察，核心原因并不是这个原因，从技术来讲，完全可以新起一个无头浏览器来实现，核心原因在于这一路径在工程和体验上不可持续：- 执行环境不可控。在本地环境中，AI 的执行依赖于用户设备的复杂上下文，包括操作系统差异、浏览器版本、权限体系、运行资源等以。这些不可控变量显著放大了模型决策的不确定性，导致行为稳定性难以保证。
- 门槛更高。安装在本地，需要用户具备特定的执行环境，包括依赖安装、权限授权以及资源占用管理。这对于一个商业化产品来说，前期很难推广。
- 风险不可隔离。虚拟机坏了，销毁重建即可，代价为零。而本地环境一旦被误操作，可能造成无可挽回的数据损失。在模型能力尚不稳定的 2024 年，把不确定性隔离在云端沙盒里，是唯一负责任的工程选择。
于是，他们放弃了直接控制本地浏览器的思路，转而采用了“云端沙盒执行”模式。在这种新模式下，当用户提出任务需求（例如“制作一份关于新能源市场的幻灯片”）时，系统会在一个独立的云端环境中启动浏览器，并自动完成所有信息搜集、整理和初步生成工作，而用户的本地设备与浏览器则完全不受干扰。这一点和26年不同，26年之所以Openclaw能火起来，核心在于产品定义更加符合人类对于AI终极体的想象：- Always On，Always Ready，长期在线，不是干完就走
- Your Personal AI，是你的，会跟着你成长，拥有更加完善的记忆能力。
- Proactive Intelligence，有主动性，不用等你吩咐
但是从技术上来说，24-25年其实并不具备开发Openclaw这种软件的条件。首先，在25年，随着Claude code的大火，模型在coding能力上有了明显进步，可以更加精准、稳定的控制你的电脑完成任务。其次，Openclaw开源的特性，让用户对于产品接受程度更高，只要可用，即使配置麻烦一点、稳定性差一点也可以接受，如果Openclaw是商业化产品我觉得其实也很难。更重要的是，skills生态的发展，让智能体拥有了各行各业一大批最佳实践给到模型，让他能够以低门槛的方式服务于我们的日常工作很多场景。关于manus产品定位
- 产品哲学：在「无所不能的通用智能体」与「精通特定领域的垂直专家」之间，Manus 应如何定位？这引出了关于产品核心发展路径的的战略类比。
- 技术架构：如何构建一个真正具备「代理」（Agency）能力的云端环境？
- 用户体验：产品的界面应如何设计，以同时满足「只看结果」的管理者与「关心过程」的工程师？这涉及到信任建立、信息过载、以及「渐进式披露」的设计理念。
- 人机协作模式：Agent 的价值究竟在何处？讨论从克服人类的认知局限，到具体的任务执行细节，探索了人与 Agent 之间理想的协作与互动模式。
产品哲学
百度 vs.Hao123:两种发展范式的隐喻
Red （Manus创始人）提出了一个深刻的类比，将两种不同的 Agent 发展路径比作「百度」与「Hao123」的模式差异。- Agent/百度模式：首先打造一个具备强大通用能力的底层平台（像搜索引擎，能爬取和理解一切）。这个平台因其通用性，吸引大量用户尝试各种各样的任务（Query）。然后，通过分析高频、高价值的 Query，反向进行优化，推出「框计算」或「阿拉丁卡片」那样的「预设能力」（Preset），使得常见任务能够被「秒级」完成。它是需求反向驱动，优化是被真实需求倒逼出来的，而不是被产品经理拍脑袋预设的。
- Hao123模式：编辑预先把有价值的的网站整理成分类导航，用户进来，在已有的链接里找自己想要的东西。这个模式的优点是结果可控、体验稳定；缺点也同样致命——它能提供的一切，都被供给侧的人工整理能力所硬性封顶。每新增一个场景，都需要人去配置；用户的真实需求一旦超出预设范围，就直接碰壁。扩展是线性的，天花板是可见的
Chatbot 为什么它现在有瓶颈了？它们看起来功能丰富，实则是把有限的预设工作流包装成了对话界面——给人通用的感觉，但实际上极不通用。用户一旦提出超出开发者预设的任务，系统立刻露馅。这正是当前大量 Chatbot 类产品遭遇增长瓶颈的根本原因：它的边界，从第一天就已经被划死了。这一思路获得了团队的普遍认同，确立了 Manus「通用性优先，逐步沉淀和优化高频场景」的核心战略。通用性是获客和探索可能性的基础，而后续的优化则是构建核心竞争力和护城河的关键。任何预设用户场景的产品都极易陷入同质化竞争。原因很简单：当你预定义了用户能做什么，你能收集到的需求和竞争对手收集到的本质上是同一批——都是该场景下的共性痛点。功能做出来大家大同小异，只能靠不断堆叠新功能、试图用"全面性"留住用户，但这是一场没有终点的消耗战。
而"通用"平台的逻辑完全不同。因为你没有预设边界，用户会在你的平台上"用出"各种意想不到的需求——这些需求不是你设计出来的，是用户自己创造的。更关键的是，这些需求模式天然只存在于你的系统中，它们就是你独有的数据壁垒。你可以针对高频需求做定向优化，而这些优化方向是竞争对手看不到的，因为他们的平台上根本不会涌现同样的使用模式。
通用性的边界：专业软件与知识冲突
尽管确立了通用性优先，但其边界和挑战也被充分讨论。范斌提出了一个现实的挑战：对于像专业视频剪辑这样的任务，一个通用的 Agent 如何与 Final Cut Pro 或 Premiere 这样的专业软件竞争？他认为，Agent 在理解和操作复杂图形界面（ComputerUse）方面，短期内难以实现质的突破。Peak则给出了一个更具未来感的设想：如果 Agent 的运行环境是一个完整的「带桌面环境的虚拟机」，那么它完全可以通过模拟人的键鼠操作来直接使用这些专业业软件，从而将通用性推向新的高度。此外，Red还指出了另一个潜在问题--知识冲突。一个无所不学的的通用 Agent，可能会在不同领域的知识上产生混淆。例如，用于数据科学的严谨知识，可能与用于市场文案的创意知识在底层逻辑上是冲突的。这暗示了未来可能需要某种形式的「领域隔离」或「知识分区」机制。技术架构
如何将产品哲学落地，关键在于技术架构的设计。讨论的焦点集中在如何解决当前 Agent 产品的核心痛点，构建一个真正稳定、持久且强大的执行环境。云端浏览器与远程交互
实现 Agent 对 Web 的复杂操作，是项目的技术基石。团队探讨了「Browser in Browser」的概念，即在用户的浏览器中，运行一个来自云端的、被 Agent 完全控制的浏览器实例。**张涛（hidecloud）**调研并分享了一个名为 XPRA 的开源项目。该项目能将远程应用的界面以流式（Streaming）的方式传输到前端，并且只传输发生变化的像素区域，这为实现低延迟的远程应用交互提供了可行的技术参考。张涛（hidecloud）:「…这个项目他自己都带了一个那个 H5 的一个客户端，就是直接显示他 Server 那边传输过来的东西.. 很符合我们这种需求嘛。」
核心痛点：状态持久化（Persistence）
团队一致认为，当前市面上 Agent 产品（如 Devin）最大的短板在于其「一次性」的会话机制。每次任务都是一个全新的、无菌的环境，这导致了大量重复工作和糟糕的用户体验。比如：- 登录的github、社交平台、调用的API等相关凭证每次新的任务都需要重新输入。
- 之前生成的文件、代码等任务结束后沙箱销毁，文件消失。
Manus 必须从根本上解决这个问题，实现全面的状态持久化。讨论中明确了需要持久化的几个关键部分：- 文件系统：为每个用户或每个项目提供一个持久化的工作目录。所有生成的文件、下载的数据、编写的代码都应该被保存下来，方便在不同会话之间复用和选代。
- 环境变量与密钥管理：对于 APIKeys 等敏感信息，直接写入代码或使用传统的。env 文件都存在安全隐患或体验问题。Devin 的做法是提供一个独立的 secret 配置界面。Manus 需要设计一套既安全又对开发者友好的密钥管理系统。
但是本质上这种持久化只是具备了工具记忆——他解决是东西不丢失，但是并不能真正理解你。如果要真正让一个agent从工具进化为“代理人”，还需要记住你的个人偏好、领域知识、技能等。用户接管（Interactive Mode）
在 Agent 遇到障碍（如复杂的验证码、两步验证登录）时，必须有一个流畅的机制让用户能够「接管」浏览器，完成操作后，再将控制权交还给 Agent。这被认为是弥补当前 AI 能力不足、确保任务能顺利完成的关键环节。用户界面与交互体验
在信任与控制之间寻求平衡
产品的界面设计，被认为是决定用户接受度的关键。讨论围绕着 Devin 的界面布局展开，并对其优缺点进行了深入剖析。界面的双重角色：建立信任与提供控制
Devin 的界面分为左右两栏：左侧是对话流，右侧是 Agent 的工作区（Planner，Shell，Browser）。团队发现，这个设计巧妙地服务了两类不同的用户心智：- 对于管理者/非技术用户（以 Red 为代表）:他们可能并不关心右侧窗口里具体的代码或命令，但这个窗口的存在，动态地展示了 Agent「正在忙碌」，从而建立起一种「它在认真干活」的信任感。
- 对于工程师/专业用户（以潘潘、范斌为代表）:他们需要看到过程的细节，以便进行调试、监督和修正。右侧的工作区为他们提供了这种必要的「控制感」和透明度。
Red:「其实我用 DEV 的时候不太看右边... 但当然他展示出右边我觉得是有意义的... 对，就是信任问题。那个很重要，就是他正儿八经在搞。」
对 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 中一样。这为未来的功能扩展提供了清晰、可伸缩的框架。人机协作：Agent 作为人类心智的延伸
讨论中，团队还花时间探讨了 Agent 存在的根本价值，即它如何成为人类能力的延伸和补充。克服人类的认知局限
潘潘（PanPan）和张涛（hidecloud）认为，人类在执行复杂任务时存在诸多局限，而这正是 Agent 的优势所在：- 经验主义陷阱：人倾向于依赖过去的成功经验，即「不知道自己不知道」，从而错过更优的解决方案。
- 缺乏持续性：人很难长时间、高强度地专注于一个任务而不分心。
Agent 则可以不知疲倦地、始终从「第一性原理」出发，通过全局搜索和评估，寻找任务的最短路径。结论与后续步骤
这两次深入的讨论，不仅为 Manus 项目的正式启动扫清了思想上的障碍，更形成了一系列宝贵的、可指导后续工作的核心原则。战略层面，确立了通用性平台+高频场景优化的双轮驱动策略。技术层面，明确了以状态持久化和云端浏览器为核心，构建真正具备「代理」能力的架构。产品层面，提出了以渐进式披露和操作系统隐喻为指导，打造兼具信任感与控制感的下一代 Agent 界面。讨论的最后，团队迅速行动，成立了项目组，共享了前期资料，并明确了在产品定义和技术架构上的分工。
夜雨聆风
