Manus AI 把工作流變成專案

Manus AI 把零碎多步工作整理成能直接照抄的代理專案流程。

我玩 autonomous agents 一陣子了，老實說，大多數都像那種很會點頭的實習生：你丟一個任務，它先裝忙，接著亂猜，最後丟你一份看起來很像樣、其實漏洞一堆的東西。我最受不了的就是這個。我要的不是一個永遠說好、永遠附和的聊天框，我要的是能把工作拆開、自己檢查、卡住時知道回頭修的東西，不是每一步都要我盯著。

所以 Manus 會吸引我，不是因為它講得多神，而是它把事情的單位改了：不是「問我任何事」，而是「把專案交給我，我來跑完」。這差很多。當 agent 真的能規劃、執行、驗證、產出可用結果時，我就不是在跟模型聊天，我是在派工。這才是我在意的標準。

我先看的是它到底是不是聊天機器人

觸發我做這篇拆解的來源是 AITinkerers 的 Manus AI 頁面，它把 Manus 描述成一個能端到端執行任務的 autonomous agent。那篇也提到它在 2025 年 3 月推出，還主張在 GAIA benchmark 上表現很強。我這裡把它當錨點，再搭配 Manus 自己的網站 manus.im 來看產品定位。

“Manus AI is a fully autonomous agent engineered for end-to-end complex task execution.”

翻譯一下就是：它想扮演的不是回答器，而是跑流程的人。這個心智模型差很多。聊天機器人是回你一句；task runner 是把事情拆開、照順序做、做完還會看一下有沒有做歪。更好的版本甚至會知道自己卡住了，先補資料，不會硬掰一個答案就交差。

我喜歡這種講法，因為它逼你先問一個很基本的問題：工作單位到底是什麼？如果單位是一個 prompt，你得到的是對話；如果單位是一個 deliverable，你才比較接近真的交辦。Manus 明顯是押後者。這也是為什麼它一直強調 end-to-end execution，而不是「更會講話」。

我之前拿通用模型做研究簡報時就踩過這個坑。我會先要摘要，再要比較表，再要來源，再要草稿。它每一步都能回，但整體看起來還是拼貼感很重，像不同人各做各的。問題不在它不會寫，而是它沒有把整個專案往前推，只是在回最新一句話。

實操寫法很簡單：不要用單一 prompt 去設計 agent。你要用 deliverable 去設計。你如果要市場簡報，就把研究、整理、比較、輸出當成同一個工作；你如果要自動化，就把觸發條件、動作、檢查、交接一次定義清楚。越早把專案名字講明白，後面越少跟工具吵架。

• 把任務寫成結果，不要寫成問題。
• 先列出 agent 要自己蒐集的輸入。
• 先定義最後要交什麼成品。

planner、executor、verifier 這三段才是重點

來源頁面說 Manus 採用多 agent 架構，分成 Planner、Execution、Verification 三個角色。這不是裝飾用名詞，這是核心設計。planner 決定做什麼，executor 負責做，verifier 負責看結果到底有沒有站住腳。

也就是說，它在試著把思考、執行、檢查拆開。我比起那種單一模型一把抓三件事的設計，更信這種拆法。因為一個 agent 同時負責想、做、查，通常會趕工；角色一拆開，至少比較有機會在出貨前抓到自己講胡話。

我自己做過夠多爛 workflow，太知道這個差別了。最常見的失敗不是「模型不會寫」，而是「模型寫得很像那麼回事，卻沒人檢查」。verification 很無聊，但無聊是好事，因為不然你就會拿到一份自信滿滿的錯誤輸出。

實操寫法：就算你不用 Manus，也把這個角色切分抄進自己的 prompt 或 orchestration layer。讓一個步驟專心規劃，一個步驟專心執行，最後一個步驟專心挑毛病。如果你是用 OpenAI API、Anthropic docs，或像 LangChain 這類框架，就不要把三種工作硬塞進同一坨超長指令。

• Planner：列步驟、依賴、風險。
• Executor：用工具把步驟做完。
• Verifier：拿原始目標回頭對照。

工具不是加分項，是 agent 能不能落地的分水嶺

AITinkerers 那頁寫 Manus 會整合 browser 和 database 之類的工具。這句看起來很普通，但你想想有多少「agent」其實只會吐字，連真實世界都碰不到。工具使用才是它有沒有真的在工作。不能 browse、不能 query、不能 extract、不能 write back，說穿了就是個會寫稿的助手，不是 agent。

翻譯一下就是：Manus 想碰現實。它能抓最新資訊、走網站流程、把多個來源拼起來。這差別很大，因為前者是「我幫你想」，後者是「我幫你做完」。

我遇過一堆 agent demo，一碰到登入頁、奇怪表格、或是多一步驗證就死掉。通常這就是產品開始認真，或是開始露餡的地方。browser tool 不花俏，但很重要。database 也一樣，因為一旦能讀寫結構化資料，agent 就不是一次性的玩具，而是能接進 workflow 的零件。

實操寫法：先列出你的 workflow 真正需要哪些工具，再去看模型強不強。做研究，通常是 browser、筆記、引用擷取；做 ops，通常是 browser 加 spreadsheet 或 database；做客服，通常是 ticket system 加 retrieval layer。任務活在哪個系統，agent 就得有那個系統的工具。

而且工具清單不要寫得很虛。什麼叫「可以上網」？我要知道它能不能搜尋、點擊、擷取、摘要、保留來源。我也要知道它能不能把資料寫回 database，不是只會盯著看。

GAIA 這種 benchmark 才比較像真的工作

來源頁面還主張 Manus 在 GAIA benchmark 的各種難度上都有很強表現。這件事我會看，因為 GAIA 不是那種只測嘴上功夫的東西。它本來就是拿來考 real-world assistant tasks，重點在推理、工具使用、以及多步驟完成。

也就是說，它想測的不是「講得像不像」，而是「有沒有把事情做完」。這個區別我很在意。很多模型都很會裝懂，但能一路走到終點的很少。

我不會把 benchmark 當成神諭，畢竟 benchmark 很容易被拿來亂解讀。我會把它當線索：設計團隊是不是在優化複雜任務下的執行力。如果你的工作本來就包含研究、瀏覽、整理、驗證，那 GAIA 至少算是對到邊。

我以前看團隊追 benchmark 分數追到走火入魔，結果跟自己實際工作完全不相干。那很浪費。比較好的做法是問：這個 benchmark 像不像我真的要做的事？如果你的任務本來就有多來源、幾個死路、最後還要交成品，那就拿這種任務去測。

實操寫法：評估 agent 時，別拿玩具 prompt。直接丟你最髒、最麻煩的真實任務，裡面要有多個來源、幾個卡點、還有一個你能判斷好壞的 final artifact。它如果撐得住，你就學到東西了；它如果掛掉，漂亮 demo 也救不了。

autonomy 有用，但前提是你先把籠子蓋好

Manus 被描述成 autonomous，聽起來很爽，但 autonomy 沒有邊界，通常只是讓你更快犯大錯。重點不是放生 agent，而是讓它不用每十秒問一次可不可以。

翻譯一下就是：操作的人還是要先把邊界設好。哪些工具能碰、哪些要先驗證、什麼叫成功、什麼時候要停下來問人，這些都要先定。autonomy 不是人格特質，是一份合約。

這件事我也吃過虧。第一次讓 agent 跑長流程時，我只顧著看能力，忘了控管。它確實做了一些有用的事，但也自己跑去做我根本沒交代的支線。後來不是把它變更聰明，而是把任務縮小、停損條件寫死。

實操寫法：先設硬限制再跑。決定它能不能寄信、改資料、還是只能先產出草稿。決定它要不要引用來源、遇到失敗要不要先問、還是可以重試後繼續。你如果是在做內部 workflow，這些 guardrails 最好直接寫進 prompt 和 tool layer。

• 先定義允許與禁止的工具。
• 設定最大重試次數。
• 最後輸出前一定要有驗證步驟。

Manus 真正值錢的是專案模式，不是產品崇拜

這裡很多人會跳過。他們看到一個很炫的 agent，就開始把產品本身當答案。我覺得這方向反了。真正值得學的是 workflow pattern：plan、execute、verify、deliver。Manus 有意思，是因為它把這個 pattern 包成一般人能試的東西。

也就是說，就算你從來不用 Manus，你還是可以抄它的結構。你可以把同樣的形狀放進 prompt chain、workflow engine，或你們公司內部的 agent。供應商沒那麼重要，操作模型才重要。

我不是說 Manus 就是終點。我是說它把問題講對了：大多數 AI 工具還停在建議層，真正的工作需要完成。只要 agent 能從髒亂輸入走到可交付成果，中間還會自我檢查一下，那就是不同層級的工具。

實操寫法：先挑一個你每週都在重複的流程，直接重建成專案。可以是 research summary、onboarding checklist、support triage、競品分析、或內容草稿。給它清楚 brief、工具集、驗證步驟、最後交付物。然後看它到底是幫你省時間，還是只是在製造更多 review 工作。

可抄的模板

# Autonomous Agent Project Template

## Goal
把一個零碎、多步驟任務，變成有 planning、execution、verification 的可交付專案。

## Use when
- 任務不只一步
- 任務需要外部工具或新資料
- 你要的是 final artifact，不只是建議

## Inputs
- Task brief:
- Target audience:
- Required sources or systems:
- Allowed tools:
- Forbidden actions:
- Success criteria:
- Stop conditions:

## Agent roles
### Planner
1. 用一句話重述目標。
2. 把任務拆成有順序的步驟。
3. 標出依賴與風險。
4. 決定完成需要哪些證據。

### Executor
1. 依序執行步驟。
2. 只使用允許的工具。
3. 保留來源、筆記與中間產物。
4. 卡住就標記，不要自己亂補。

### Verifier
1. 對照 success criteria。
2. 檢查缺步、弱證據、未支持的主張。
3. 確認成品能直接交付或轉交。
4. 如果失敗，回到最小壞掉的步驟。

## Prompt skeleton
You are running a project, not answering a single question.

Goal:
[insert goal]

Context:
[insert background]

Allowed tools:
[insert tools]

Forbidden actions:
[insert restrictions]

Process:
1. Plan the work.
2. Execute the work.
3. Verify the result.
4. Deliver the final artifact.

Output format:
- Final answer
- Sources used
- Open issues
- Verification notes

## Review checklist
- 任務有沒有 end-to-end 完成？
- 有沒有用對工具？
- 有沒有自己驗證？
- 有沒有亂講沒根據的東西？
- 成品能不能直接交出去？

## Example use case
Research brief:
- Gather 3-5 sources
- Extract key claims
- Compare positions
- Draft summary
- Verify citations
- Return final brief

## Operational note
如果 agent 開始亂跑，先縮任務，不要先加智商。

這份模板我故意寫得很素。不要魔法詞，不要假裝人格，不要那種「請保持樂於助人」的廢話。我想看到的是 workflow，本體要清楚，角色要分開，限制要寫死，這樣 agent 才不會自己發明規則。

如果你要把它接進真的 stack，直接塞進你現有的 orchestration layer 就好。不管是簡單 prompt chain、tool-calling loop，還是公司內部 workflow service，結構才是重點，模型只是引擎。

來源致謝：原始脈絡主要來自 AITinkerers 的 Manus AI 頁面 與 Manus 官方網站，另外參考了 GAIA benchmark 的任務設定。上面這份模板與拆法是我根據這些資料整理出的衍生實作版本。