Manus 產品立項初期會議紀要

Manus 張濤：

「前幾天翻出來去年 Manus 正式立項那天我們幾個討論的錄音，交給 Manus 整理成了這個文件?；仡^看去這一年，基本上是把當時討論的點都實現到了。算是很有價值的一次討論了。

尤其喜歡 Manus 自己寫的這句：一個旨在重新定義智能體、致?于成為?類強??智延伸的探索之旅，由此正式啟航?！?/p>

以下為會議紀要完整內容，來自「潛云思緒」。

??關注 Founder Park，最及時最干貨的創業分享

超 17000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

本文基于 Manus 項目立項初期的兩次核心討論錄音文字稿整理而成。與初版紀要相比，本擴展版旨在更深入、更細致地還原討論的全貌，不僅保留了核心議題與時間脈絡，更補充了大量的細節、思辨過程以及富有啟發性的類比。文章力求全面展現團隊人在產品哲學、技術架構、用戶體驗及市場策略等方面的深度碰撞，為 Manus 項目的后續發展提供一份更豐滿、更具參考價值的奠基性文檔。

02討論參與者

• Red

• Peak

• 范斌

• 張濤（hidecloud）

• 潘潘（PanPan）

03核心議題摘要

討論的核心議題在擴展后，可以更細致地歸納為以下幾個方面：

• 產品哲學：在「無所不能的通用智能體」與「精通特定領域的垂直專家」之間，Manus 應如何定位？這引出了關于產品核心發展路徑的「百度模式」與「Hao123 模式」的戰略類比。

• 技術架構：如何構建一個真正具備「代理」（Agency）能力的云端環境？重點探討了「云端瀏覽器」的實現路徑、跨會話的「狀態持久化」這一核心痛點，以及安全與易用性的平衡。

• 用戶體驗：產品的界面應如何設計，以同時滿足「只看結果」的管理者與「關心過程」的工程師？這涉及到信任建立、信息過載、以及「漸進式披露」的設計理念。

• 人機協作模式：Agent 的價值究竟在何處？討論從克服人類的認知局限，到具體的任務執行細節，探索了人與 Agent 之間理想的協作與互動模式。

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 的運行環境是一個完整的「帶桌面環境的虛擬機」，那么它完全可以通過模擬人的鍵鼠操作來直接使用這些專業業軟件，從而將通用性推向新的高度。

此外，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 的時候不太看右邊... 但當然他展示出右邊我覺得是有意義的... 對，就是信任問題。那個很重要，就是他正兒八經在搞?！?/blockquote>

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）:「但是他永遠都會去第一性原理全局激活?！?/blockquote>

4.4.2.EVE Online 的啟示：復雜系統與長期規劃

討論中一段關于游戲《EVE Online》的「題外話」，實際上為 Agent 的應用場景提供了一個有趣的類比。EVE 是一個擁有極其復雜的經濟系統和生產鏈的科幻網網游，玩家需要像經營一個國家一樣，進行長期的資源規劃、生產調度和戰略博弈。許多玩家軍團甚至需要使用 Excel 表格來管理其龐大的生產體系。

這恰恰揭示了 Agent 的一個潛在的高價值應用場景：作為復雜系統的「總調度官」或「超級助理」，幫助人類管理和優化那些超越了單人認知和執行能力上限的龐大工程。

05結論與后續步驟

這兩次深入的討論，不僅為 Manus 項目的正式啟動掃清了思想上的障礙，更形成了一系列寶貴的、可指導后續工作的核心原則。

• 戰略層面，確立了「通用性平臺+高頻場景優化」的雙輪驅動策略。

• 技術層面，明確了以「狀態持久化」和「云端瀏覽器」為核心，構建真正具備「代理」能力的架構。

• 產品層面，提出了以「漸進式披露」和「操作系統隱喻」為指導，打造兼具信任感與控制感的下一代 Agent 界面。

討論的最后，團隊迅速行動，成立了項目組，共享了前期資料，并明確了在產品定義和技術架構上的分工。一個旨在重新定義智能體、致力于成為人類強大心智延伸的探索之旅，由此正式啟航。

轉載原創文章請添加微信：founderparker