Manus 產品立項初期會議紀要

新聞
HongKong
0
04:03 PM · Dec 29 ,2025

Manus張濤:

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

尤其喜歡 Manus 自己寫的這句:一個旨在重新定義智能體、致⼒於成為⼈類強⼤⼼智延伸的探索之旅,由此正式啓航。」

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

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


01 引言 

本文基於 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 的時候不太看右邊... 但當然他展示出右邊我覺得是有意義的... 對,就是信任問題。那個很重要,就是他正兒八經在搞。」

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 的一個潛在的高價值應用場景:作為複雜系統的「總調度官」或「超級助理」,幫助人類管理和優化那些超越了單人認知和執行能力上限的龐大工程。

 

05 結論與後續步驟

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

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

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

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

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

user avatar
0 位用戶收藏了這個故事!
收藏

發佈 評論

Some HTML is okay.