用 Manus 重建 Manus：什麼變了，什麼出了問題，以及我們現在如何工作
作者：張濤，Manus 共同創辦人兼產品長
九月下旬，在 Manus 2.0 的最後衝刺階段，我在 Slack 上傳了幾條功能需求和缺陷報告給一位工程師。後來我去看他進展如何。他的螢幕上開著一排 agent 工作階段，有的在 Manus 裡，有的在 Codex 裡。我點進其中一個。提示詞就是我在 Slack 上傳的訊息，一字不差地貼進去。
一年前，他會讀我的訊息，理解我的意思，然後開始寫程式碼。而現在，agent 讀取請求、找到相關程式碼，並提出修改方案。工程師的工作是指揮任務、檢查結果，並對最終產出負責。大多數時候請求都在執行中，並不需要他等待。如今在我們這裡，一名工程師同時推進 10 到 20 個請求已是常態。
我為團隊的快速適應感到自豪。但我也感到不安。這個節奏對嗎？還有什麼是我們沒注意到的？
我們在 Manus 建構 agent，所以我們堅持兩條原則：用自己的產品做真實工作，並持續尋找 AI 失靈的地方。
我想記錄一下當人與 agent 預設並肩工作時，一家公司內部會發生什麼。本文涵蓋三個團隊——工程、產品和行銷——並包括那些行不通的地方。這是一份正在進行中的實驗報告，而不是對「AI 原生組織」的定義。
我們目前學到的：
•沒有折衷之道。把 AI 加到舊的工作方式上有時只會增加雜訊。只有當閉環真正形成時，事情才會改變。
•Agent 需要全局視野。更好的脈絡比更好的提示詞為我們帶來的收益更大。
•信任來自測試和脈絡，而不僅僅來自模型品質。
•自主性需要終點線。只有當成功可被驗證時，agent 才能獨立運行。在其他所有地方，由人來決定。
•瓶頸會轉移。當工程變得更快時，決定該建構什麼反而成了限制。
•人的角色並未被削弱，反而更聚焦於高影響力的事情。
1. 沒有折衷之道
在 2026 年之前，我們和大多數公司做的事一樣：把 AI 加到我們已有的工作方式上。這意味著客服用 AI 摘要來標記問題，工程師使用程式設計助手，機器人在頻道裡發布分析。每一塊單獨看都有用，但各塊之間彼此並不相連。在閉環真正形成之前，我們只是在用老辦法工作，只不過多了許多 AI 在互相對話。
有一句話我們常常回到：軟體工程是隨時間累積的程式設計。寫程式碼容易衡量；讓一個複雜產品健康地運行多年則不然。AI 寫程式碼的高佔比可能意味著真實的進展，也可能意味著在堆積日後要有人清理的垃圾。
我們真正在意的考驗更難。Manus 是一款已上線超過一年的複雜產品。它能否在新的工作方式下持續改進而不崩塌，同時每個人都能做得更多？到目前為止，答案是肯定的。
2. 把全局交給 agent
和大多數科技公司一樣，我們在交接環節損失的時間最多。前端工程師和後端工程師會各自解讀一個需求，就介面達成一致，然後花幾天時間修復不匹配的地方。兩個人很少會以相同的方式理解同一個需求。
如果 AI 能跨技術堆疊寫程式碼，是否可以讓一個人端到端地負責一個需求？障礙在於脈絡。我們的程式碼分散在不同的儲存庫中，沒有哪個 agent 能一次看到整個系統。
我們對此的回答始於一次內部實驗。我們想看看在盡可能少的人工輸入和幾乎不手寫程式碼的情況下，AI 能把一個產品做到什麼程度。我們在這個過程中形成的方法，演變成了如今我們稱之為 Manus-mono（或簡稱 Mono）的內部工具。
Mono 並不合併我們的程式碼儲存庫。它是一個統一的入口，加上一份寫給 agent 的手冊：每個儲存庫是做什麼的、它們如何協作、以及我們是如何工作的。agent 會按需拉取所需內容。我們還維護了一個架構決策記錄庫，這樣每次 agent 工作階段開始時，獲得的不僅是程式碼，還有過往決策背後的推理。無論誰與 agent 協作，這個 agent 都掌握著此前所有人的上下文。
Mono 是一步步成長起來的，每一步都解決了上一步暴露出的瓶頸：
1.看清整個系統。我們加入了任何單一儲存庫都無法涵蓋的業務上下文，並使用 Git worktrees 來平行工作。
2.本地驗證。以往推送到測試環境需要 5 到 10 分鐘。現在整個 Manus 技術堆疊可以在一台筆電上執行，檢查只需幾秒。
3.偵錯生產環境問題。透過受限權限，Mono 可以讀取診斷生產環境 bug 所需的日誌、設定和錯誤報告。
4.端到端執行發布。Mono 現在處理那些以往容易卡住的發布環節。審批決策仍由人來做。
5.端到端測試。當驗證成為瓶頸時，Mono 開始使用測試账户，在瀏覽器和行動裝置模擬器中執行真實使用者流程。
（Mono 如何運作以及它如何演進。由一位同事使用 Manus 製作。）
有人會問 Mono 是否是一個程式碼 wiki。文件是其中的一部分，但其餘部分涵蓋了程式碼周圍的一切：我們如何測試、如何發布、決定了什麼以及為什麼這樣決定，還有 agent 可以和不可以觸碰什麼。
隨著時間推移，Mono 已經成為一個共享知識庫，並會隨著大家的持續補充而越來越好。例如，我們的維運工程師厭倦了總被叫去幫忙發布，於是他把發布流程寫進了 Mono。現在任何人都可以執行發布，agent 也可以，但審批仍由擁有發布權限的人來決定。我喜歡團隊這種工作方式：一個人解決了自己的煩惱，整間公司也因此變得稍快一些。
團隊現在預設一個人就能在每個平台上交付一個需求。我們的行動端團隊一直是七個人。他們在兩個產品之間維護四款應用，並與網頁端保持同步節奏。
Mono 在公司內擴散並沒有自上而下的強制推動。我認為這與其說是工具推動，不如說是文化使然。探索 AI 的邊界本就是我們存在的原因之一，而且我們的組織是扁平的。工具能走多遠，取決於組織允許它走多遠。
3. 閉環：從使用者的 bug 報告到經過驗證的修復
Mono 讓任何人都能參與產品的任何部分。這只是其中一半。另一半是讓 agent 能自主發現問題。
在大多數網路公司，使用者的 bug 報告要先經過客服、產品和分流，才能到達能夠修復它的工程師手上。
對我們來說，現在是一個內部 agent 先調查該報告，並把問題追溯到導致它的那次變更。然後它會在 Slack 中發文，並 @ 負責這次變更的工程師。工程師來決定是否屬於自己要修的，然後交給自己的 agent 處理。另一個獨立的 agent 會透過執行相關測試和流程來檢查修復。
三個 agent，三種角色：一個負責分流，一個負責執行，一個負責驗證。中間的人做出判斷。我們越來越多的工程工作現在都以這種方式開始——由 agent 把問題交到人手上。
這個閉環有明確的邊界。讀取使用者報告的 agent 不能變更程式碼。它只能調查並向我們回報。變更來自工程師自己的 agent，並且需要工程師先做決定。任何內容在未經擁有發布權限的人審批之前，都不會發布上線。
4. 我們如何學會信任 Agent 編寫的程式碼
長期以來，合併到主分支的每一次更改都需要兩位資深工程師之一的簽字確認。我們對 AI 的信任還不足以跳過這一步。隨著 Agent 產出的程式碼越來越多，這個審查環節成了瓶頸。
就純粹的編碼能力而言，模型已經相當出色。我們意識到差距歸結為兩點。第一，人知道如何測試自己的工作。第二，人參與了上下游的討論，所以他們知道對業務而言什麼才是「正確」的。正確的程式碼並不等同於正確的產品。
我們從兩方面入手解決：
•讓 Agent 加入討論。現在，每位工程師的 Agent 都會駐留在它被加入的 Slack 討論串中，跟進上下文。當有人最終說「開工」時，Agent 已經知道團隊決定了什麼以及為什麼。
•讓 Agent 進行端對端測試。我們與後端團隊合作，賦予 Agent 在每次更改後於 Manus 中執行真實流程和回歸測試的能力。隨著測試覆蓋率的增長，我們的信任也隨之增長。
如今，每一次更改都要通過這種驗證，並經過執行最強可用模型的程式碼審查機器人審查，對支付等敏感領域還有額外規則。機器人取代了排隊，而不是人的決策。Agent 可以提交 pull request，但未經人的明確核准，無法合併到我們的主分支。要建置什麼、誰可以發布，仍由人來決定。
5. 自主性需要一個終點目標
信任是有邊界的，我們是透過艱難的教訓才明白這一點的。
曾經有一段時間，大家都對完全自主的 Agent 迴圈感到興奮，於是我們試了一次。一個 Agent 從我們的內部回饋管道收集回饋，並為每一條回饋啟動一個專案。一位同事讓它執行了整個週末。週一早上，有超過 200 個專案在等待他的決策。
為什麼不讓 Agent 也替我們做這些決定呢？自主迴圈只有在系統能夠檢查目標是否達成時才有效。測試通過或失敗；頁面能載入或不能載入。而大多數現實工作並沒有這樣的檢查。必須由人來判斷事情是否完成，以及是否值得去做。
那個週末我們得到了兩條教訓。第一，人做決策的速度跟不上一個不受約束的迴圈產生決策的速度。第二，如果沒有人決定某件事是否該做，那就沒有人為結果負責。第 3 節中的 bug 修復迴圈之所以奏效，是因為測試定義了成功。產品決策沒有測試可依，所以 Manus 的每一次產品變更仍然始於一個人決定是否值得去做。
6. 當工程變得更快時，產品反而成了瓶頸
傳統的產品流程有許多交接環節，每一次交接都會讓優先順序稍稍偏移。隨著編碼 Agent 讓工程師效率更高，一個新問題出現了：沒有足夠的產品經理來撰寫好的需求。工程第一次不再是瓶頸。
在 Manus，我們的第一個解決方案是請幾位工程師成為「建造者」，從探索到發布全權負責一個問題。但同時具備技術判斷力和產品判斷力的人寥寥無幾。接著我們讓 PM 來改程式碼，這同樣陷入停滯。交接依然存在，而沒有工程師的直覺，PM 可以改文案和互動，卻改不了底層邏輯。
Mono 解決了這兩個問題，因為它自帶規則：
•任何涉及模型呼叫或成本的更改，都需要在編寫程式碼前獲得負責人的簽字確認。
•每一次更改都要經過與工程師更改相同的審查和測試。
•Mono 可以使用測試帳戶走完註冊和支付流程，並記錄每一步，這樣 PM 就能準確指出出問題的具體時刻。
下面是實際操作中的樣子。一位負責語音轉文字的 PM 讓 Manus 對 10 多個模型進行了基準測試，然後選定了一個。她透過 Mono 拉取前端程式碼，在我們的設計系統中建置了一個 demo，並讓 Manus 把每個使用者場景渲染成圖片供她審閱。她把 demo 轉成了影片。方案清晰到她自己就把該功能建置了出來，包括 Web 和桌面端 UI。
過程中有人做出了三個決定。她選擇了模型。產品和設計團隊審查了演示。一位擁有發布權限的工程師審查了程式碼。一年前，這一切都不可能實現。
我們將這種轉變描述為從人在環中（human in the loop）轉向人在環上（human on the loop）。過去 AI 完成任務的 70-80%，人來補足剩餘部分。現在人來設定規則，監督多個 agent，在關鍵節點檢查方法和結果，必要時介入，並對結果負責。
現在有些 PM 會提交一段簡短的影片，而不是書面規格或原型圖。幾分鐘內，影片就能展示使用場景、每個介面、每次點擊的作用、邊緣情況如何處理，以及底層如何運轉。對我們而言，設計、工程和 QA 能更快就「完成」的定義達成一致，PM 只需講解一次。
（語音輸入的產品需求影片）
如今約有一半的 PM 獨立上線功能，每位 PM 都提交過程式碼。設計師也開始動手了。一位 PM 在 Manus 2.0 中編寫了 Manus Studio 介面的大部分程式碼。另一位編寫了影片編輯器。這些成果的背後，是有人花了數月時間突破自己原有的職位邊界。這是最讓我自豪的地方。
這並不意味著每個人都必須成為開發者。當公司裡任何人都能構建產品時，可能會有人上線一些本不該存在的東西。我們的產品團隊經常問一個問題：「如果這件事只花一秒鐘且零成本，你會上線嗎？」有時答案是否定的。我們仍然需要模組負責人來決定構建什麼、不構建什麼以及使用者最終看到什麼。我們也需要有人來維護像 Mono 這樣的基礎設施。當構建變得容易時，決定構建什麼就更為重要。
7. 行銷工作流中的 AI 隊友
一次行銷合作要經歷腳本審查、定價、合約、審批、付款、上線和成效複盤等環節。這些步驟分散在郵件、合約工具、審批系統、試算表和廣告平台中。過去工作中很大一部分時間都花在了在這些系統間搬運資訊，留給需要判斷力的創意工作的時間很少。
我們從一個小問題入手：合作方內容或廣告上線後，我們往往很晚才知道。於是我們讓 AI 寫了一個腳本來偵測內容何時發布。接著我們想要成效數據。然後是過往合作的複盤。再然後整個內部工作流被打通：當合約簽署或審批通過時，agent 會更新狀態並通知負責下一步的人。
Manus 將這一切構建成了一個內部站點。對人而言，它是儀表板和行事曆。對 agent 而言，它是一組工具。使用這些工具在我們工作流中運作的 agent，就是我們所說的 AI 隊友。它只在團隊為其接入的管道和系統中工作，存取權限僅限於此工作流。
它的工作內容如下：
•它管理自己的佇列。許多人同時向它發訊息，所以它在一個「前台」會話中與所有人溝通，並把任務分派給並行會話。它會判斷某條訊息是否與自己相關，然後再決定是中斷目前工作還是等待。這些規則是它在開發過程中自行提出的，我們審查後予以保留。
•它從轉發的上下文中學習。過去策略調整意味著一場會議和一份書面簡報。現在我們的行銷負責人會把討論轉發給它，並說一句「學習一下」。
•它會關注長期目標。有一次，Slack 討論串中的隊友（它也被加入了該討論串）記不清某個專案的進展。它在未被 @ 的情況下回覆道：「B 還在測試中。要不要等 A 的結果出來再看 B？」
•它會與其他團隊核實事實。在我們上線 3D 模型綁定後，它向產品團隊詢問支援哪些內容。它了解到綁定涵蓋七個類別，包括魚類、蛇類和四足動物，因此我們的描述得以保持準確。
現在隊友們會讓它參與腳本和定價審查，因為它讀過我們過往的合作紀錄。但最終決策仍由人做出。
這個內部站點也能從它的使用者（包括 agent 本身）身上得到改進。當 agent 遇到阻礙時，它會透過回饋介面提交一個請求。該請求會透過 Manus 2.0 中的自動化在 Manus 中建立一項開發任務，由工程師審查變更後再發布。它已經運行了大約一週。我們還需要累積更多案例才能真正依賴它。
那麼團隊裡的人做什麼呢？有三件事仍由他們負責。他們做出並承擔每一項重要決定。他們處理 agent 未見過的情況，並教它該怎麼做或該找誰。當它的分析指向新的角度時，他們會調整它的方向。
8. 減少互相打擾
在所有這些團隊中,許多問題不再需要去打擾某個人。
先問 Agent。一位同事在 Mono 上搭建了一個 Slack 機器人,它執行在雲端電腦上並在話題串中回覆。非工程師用得最多。這個功能是怎麼運作的?這個字串在哪裡?這個發布了嗎?他們不再需要先去找負責人。
開啟會話,而不是詢問進度更新。工程師的進展過去都存在他們自己的 AI 聊天裡,他們一下線就看不見了。所以我們做了一個內部功能,讓專案成員可以看到彼此的會話,並申請加入。工程師可能用 Agent 完成了一個功能的大部分,然後 PM 加入同一個會話來調整間距、樣式和文案。在別人的會話中發文需要對方核准,我們還在完善權限機制。
(示意圖:工程師、PM 和設計師如何在一個會話中協作。並非真實的價格調整。)
重點不是讓大家彼此交流更少,而是讓大家彼此打擾更少。
只決定需要決定的事。我們使用 AI 最多的人保留了一個主會話,專門做一件事:列出需要他決定的事項,並為每一項給出建議。當 Slack 變得繁忙時,他不參與其中,而是問:「我現在需要決定什麼?」
我也做類似的事。我每天有超過 20 個待辦事項,而且正如我公開分享過的,我有 ADHD。對我來說,最難的部分是開始。現在每個待辦都進入一個專屬的 Manus Project,它會把每一項變成單獨的任務。它能啟動的就啟動。遇到不確定的,它會問我背景資訊,以及該由哪位 PM 負責。然後,利用我授予它的對我自己 Slack、Gmail 和 Notion 的存取權限,它會收集上下文,並把一個完整的請求交給 PM,而不是只給一句話。對我來說,這種變化不僅僅關乎效率。我現在每天花在對從何入手感到焦慮上的時間少多了,這在個人層面意義巨大。
9. 這些花費值得嗎?
我們在 AI 上花費很多,並且密切追蹤這些支出。我們不是用它來評判任何人的表現。我們是用它來評判這筆支出本身:它現在是否有回報,或者是否在為未來打基礎?
以下是我們認為它為我們帶來了什麼,以及我們預期成本會如何變化:
•它為我們換來了時間和注意力。隨著團隊壯大,協作會消耗每個人的注意力。AI 保護了每個人的注意力,讓他們能夠更充分地掌控自己的工作。而我們還在繼續招聘。
•使用最好的模型是我們了解 AI 邊界的方式。第 4 節描述的驗證和程式碼審查設定執行在我們能用到的最強模型上。負責開發者生產力的同事稱之為我們最具性價比的支出。
•成本應該透過產品降下來。我們現在越來越多的開發工作發生在我們自己的產品 Manus Studio 中,所以我們的使用資料能告訴我們 tokens 浪費在哪裡。修復會進入產品本身,因此也應該讓 Manus 對使用者更高效。我們預期隨著模型變得更便宜以及我們消除浪費,今天的成本將大幅下降。這是一個信念,而不是承諾!
10. 哪些還沒做好
打擾變少了,但注意力更碎片化了。過去一天處理四五件事的人,現在可能同時推進 20 或 30 件事。每次切換都意味著重新載入上下文。AI 擴展了人們能做的事情,也促使他們做得更多。一位 PM 告訴我,只要有一個任務在跑,她就忍不住要啟動另一個 Agent。做更多的事情不是目標。我們把這當作一個需要解決的問題,而不是值得慶祝的節奏。
資訊更分散了。我們的產品負責人過去了解每一項變更以及背後的原因。現在他有時會截圖一個問題去問 Mono:「這是誰改的?」聽起來好笑,但這個問題是真實的。當每個人都被賦權去改變產品時,誰對整體負責?
共享權限需要重新設計。當工作可以被分享和交接,而 Agent 又出現在我們更多的對話中時,我們必須決定什麼是開放的,什麼需要審批。
我們的解決方案仍然很初級。目前,一個 Agent 監督其他 Agent,只回報哪些卡住了以及哪些需要人來決策。我們知道這還可以做得更好。
11. 我們接下來要做什麼
這些問題指向其他團隊可能也會需要的產品工作。我們並沒有提前規劃這些功能。它們源自我們自己不斷遇到的問題。
•把會話作為共享工作區。一個人提出問題，設計師提出方案，工程師建構它，PM 推動它執行，這一切都在同一個地方發生。
•跨裝置、跨人員流轉的工作。本地機器和雲端機器保持連線，這樣當有人暫時離開時，工作仍能繼續。
•能發現人們未曾考慮過的方案的 Agent。一個在公司系統內執行、擁有合適權限的 Agent，應該能夠提出解決方案，而不僅僅是執行指令。
我們會先在自己身上嘗試這些，然後再帶給使用者。
12. 人們現在在做什麼
那位同時開啟一排 Agent 會話的工程師，不僅僅是一個關於效率的故事。它是組織運作方式的一次變革。過去，公司透過角色和層級來傳遞資訊。一個人能做什麼，取決於他能調動多少人和多少資源。現在，我們花一點時間為 AI 提供上下文和工具，然後花更多時間去做判斷和決策。越來越多的時候，是 Agent 把問題帶到我們面前。但決定如何應對，仍然是我們的工作。
我們開過這樣的玩笑：如果 Manus 能做這麼多，還來辦公室幹什麼？讓 Agent 自己搞定好了。但真正重要的問題，依然需要人來提出、爭論和決策。例如，什麼才算一個好產品？或者，稍微誇張一點地說：是打造一個有真實收入、持續推動 AI 邊界的偉大產品，還是追求利潤率？AI 不知道我們想要哪一個。我們知道。文化和信任，來自我們日復一日、在關鍵時刻一起把事情想清楚的過程。那是每個會話中所有工作所依託的基礎。
所以，就目前而言，這是我們的答案。在我們作為 AI 原生組織的實驗中，人的角色並沒有被削弱。它變得更專注於那些他們能產生最大影響的領域：定義問題、判斷品質、決定什麼值得做、為結果負責。
這也是為什麼我們仍在招聘。人的技能與判斷力處於這種工作方式的核心——而這一點在短期內不會改變。
寫下這篇文章時，我很好奇一年之後它會是什麼樣。每家公司都有不同的目標、結構和文化，所以可能沒有標準答案，也沒有最終形態。但對一家建構 Agent 的公司來說，弄清楚人與 AI 如何協作並不是可選項。它就是工作的一部分。我們會繼續探索，也會繼續分享我們的所學。
關於資料的說明。本文中的數字來自內部記錄。團隊規模和 PM 交付資料截至 10 月下旬。部分內容是估算或個人經驗，而非嚴格的度量。
