在開始動手之前，想先把核心名詞的定義與範疇固定下來，並將關鍵概念釐清。

最近標題寫著「多 Agent」的教學非常多，但實際點進去，很多是一個 Agent 掛了好幾個工具。Agent 這個詞本身定義就很鬆，說誰錯也不太公平。只是對這個系列來說，這個差別剛好決定了後面每一個設計，所以花一篇講清楚。

我把常見的做法分成三種型態，下圖先有個整體印象。

型態 A：單一 Agent

一次 LLM 呼叫，沒有工具，也沒有迴圈。把一段文字貼給 ChatGPT 請它改寫，就屬於這一型。

它很適合語言轉換類的工作，例如摘要、翻譯、改寫、分類。但只要需要外部事實，例如「A10293 這張單現在到哪了」，它就無能為力，只能用猜的。

型態 B：單一 Agent 加上工具

這是目前最多人在做的東西，也是 n8n 的 AI Agent 節點最典型的用法。

運作方式是一個迴圈。以 Day 04 會做的單兵 Agent 為例，客人問「我的訂單 A10293 什麼時候會到？」，n8n 實際跟模型來回了兩次：

1. 第一次呼叫：模型沒有直接回答，而是回傳一個工具呼叫 get_order({"order_id":"A10293"})。
2. n8n 執行 get_order 這個工具，把查到的訂單資料當成一則新訊息，接在對話後面。
3. 第二次呼叫：模型看到訂單資料，寫出回信。

如果模型一直要求呼叫工具，n8n 會跑到 AI Agent 節點的 Max Iterations 上限（預設 10 次）才停。

這個型態的特徵是：整個過程只有一份 System Prompt、一個對話紀錄、一個決策者。工具是手腳，不是同事。它不會思考，也不會跟你說「你給我的資訊不夠」，參數進去、資料出來，就這樣。

型態 C：Multi-Agent

差別只有一個，但影響很大：底下的 W1、W2 各自是一次獨立的 LLM 推理，有自己的 System Prompt、自己的對話紀錄、自己的工具。

用 API 的角度看會更清楚。型態 B 從頭到尾只有一個 messages 陣列在長大；型態 C 則是每個 Agent 各有一個 messages 陣列，主管的對話裡看不到專員查資料的過程，只看得到專員最後回報的結果。

因為是獨立推理，W1 會判斷、會回報「查不到」、也會說明缺了什麼資訊。它比較像同事，而不是函式。

三種型態的比較

最後一列要記住。Multi-Agent 等於拿成本和延遲，去換正確率和可維護性，這筆交易不一定划算。實際差多少，Day 28 會用 50 封評估信的數字回答。

我自己用的判斷方法

看到一個號稱多 Agent 的專案，我會問三個問題：

1. 總共有幾份 System Prompt？只有一份，就是型態 B。
2. 子單元失敗的時候，會不會說明原因？只會回傳空結果或錯誤碼，那它是工具。
3. 能不能把某個子單元單獨拿出來測試？

第三個最實用。能不能幫它出一份考卷，是 Agent 和工具最實際的分界。Day 15 會真的讓三位專員各考 20 題。

對應到 n8n 2.38 的節點

最後一列常被忽略。很多人以為要讓 LLM 自己決定派給誰才算 Multi-Agent，其實派工完全可以是寫死的條件判斷，架構一樣是 Multi-Agent。Day 18 會把這三種派工方式都做出來，用同一批信比較。

其他框架怎麼稱呼這些東西

如果你之後想從 n8n 換到程式框架，名詞大致可以這樣對應：

框架的細節 Day 30 再談，這裡只是想說明：不管用什麼工具，要回答的設計問題都一樣。

回到好豆選物：它需要哪一型？

從需求反推：

• 一封信可能同時問訂單和商品知識，需要兩種資料來源。
• 「查不到這張訂單」和「FAQ 沒寫」是兩種失敗，後續處理不一樣。
• 回信語氣是一整套獨立規則，跟查資料無關。
• 客訴信要能明確判斷成「這封交給人處理」。

第二點和第四點決定了答案。系統需要能分辨失敗原因的子單元，也需要一個明確的轉人工出口，這就是型態 C。

不過我不打算直接跳過去。Day 04 到 Day 07 會先把型態 B 認真做出來、實際測過，看它哪裡夠用、哪裡不夠。沒有這個對照組，後面拆分的好處就只是嘴上說說。

小結

型態 B 和型態 C 的分界，在於子單元有沒有自己的 System Prompt 和對話紀錄；最實用的判斷方法，是看能不能單獨幫它出考卷。另外，派工交給 LLM 或寫死在流程裡都算 Multi-Agent，差別只在誰做決定。

明天開始動手：用 Docker 架好 n8n、接上 Ollama，順便分享兩個我實測才搞清楚的 Ollama 參數細節。