學習筆記

TL;DR

多 AI Agent 是否值得使用，取決於任務能否平行拆分、結果能否驗收、出錯是否可補救，以及任務是否常常重複；符合越多條件，越可能省下時間並抵銷額外成本。

快速結論

多 Agent 能提高某些任務的效能，但會增加推理、工具與協調成本。影片引用的研究例子顯示，多 Agent 在特定測試中優於單 Agent，但也可能消耗更多資源，因此不能只看「做得更好」，還要看提升是否值得成本。

適合優先交給多 Agent 的工作，通常可以拆成互不依賴的平行任務，且結果能用來源或明確標準檢查。若任務必須一步接一步傳遞資訊，Agent 之間的摘要與交接可能造成資訊流失；若結果沒有客觀驗收方式，多 Agent 也可能彼此附和錯誤。

實際評估時，可檢查任務是否常做、出錯能否補救，以及人工核對是否比自己完成更省時。影片示範的職缺追蹤與 API 用量檢查都具備重複性、可查證性與相對低的錯誤成本，適合設定成定期工作流。

這支影片在說什麼

影片討論如何判斷每週工作中哪些事情值得使用多 AI Agent。它提出四個評估問題，並說明平行工作、結果驗收、錯誤成本與任務頻率如何影響效益。接著以 Creao 示範建立定期執行的職缺雷達與 API 用量檢查工作流。內容適合考慮把重複工作自動化，或正在評估多 Agent 成本與效益的人。

最重要的 3-5 個重點

1. 多 Agent 的效益要和成本一起評估。 多個模型或 Agent 分工可能提高表現，但推理與工具呼叫也會增加；要確認效能提升是否值得額外開銷。
2. 能平行拆分的任務更適合多 Agent。 多個 Agent 可各自處理互不依賴的資料來源；必須依序交接的任務則可能因摘要傳遞而漏失資訊。
3. 結果必須可驗收。 有原始文件、數據或明確標準可供核對的工作較適合委派；缺少客觀標準時，多 Agent 可能互相附和錯誤。
4. 先考慮錯誤成本與補救方式。 漏掉一筆可下週補上的週報資料，和要求精確、可追溯的付款或發票作業，不能採用相同的委派方式。
5. 重複頻率影響回本速度。 多 Agent 的單次成本較高；日常反覆執行的任務比較有機會攤平初始設定與執行成本。

知識架構

一、先判斷多 Agent 有沒有價值

• 比較預期效能提升與額外成本。
• 分別估算推理、工具使用、協調與人工檢查的負擔。

二、用四個問題篩選任務

1. 任務能否拆成多條平行工作？
2. 產出能否用證據或標準驗收？
3. 出錯的成本有多高，是否能補救？
4. 任務每週或每天會重複幾次？

三、設計工作流

• 把可平行的子任務分配出去。
• 對必須串接的步驟，明訂交接時要傳遞的表格或欄位。
• 設定驗收清單，讓結果依條件檢查。
• 先試跑並修正，再設定排程重複執行。

四、影片示範的兩種用途

• 每週追蹤多家公司職缺與變化。
• 定期檢查多個 API key 或服務的用量是否異常增加。

關鍵概念

• 多 Agent 架構：由多個 Agent 分工完成任務，例如分別查資料、撰寫、檢查或處理不同來源。
• 平行任務：彼此不需等待對方結果、可同時處理的工作。影片以分別查競爭對手官網、社群、新聞與價格為例。
• 串接任務：後一步需要前一步的結果，例如客訴處理中的分類、查訂單、判斷補償與撰寫回信。
• 交接資訊：Agent 把任務狀態交給下一個 Agent 時所提供的內容。若只傳摘要，接手者可能需要重建狀態，造成資訊流失；影片建議使用可核對的表格等格式。
• 認知同化：影片用來描述多個 Agent 在沒有客觀對錯標準時，可能放棄原本正確的判斷、共同接受錯誤結論的現象。
• 驗收標準：判斷產出是否合格的具體依據，例如原始資料來源、要檢查的欄位或 Checklist。
• 可重複工作流：建立一次後定期執行的 Agent 流程。影片示範的工具流程包含建立、交付、修正與排程擴大使用。

重要例子與細節

研究與成本例子

逐字稿提到：

• 某篇研究中，多個模型各自產生答案再逐層整合，在同一預算下的準確率為 71.4%，單一 Agent 為 **68.

7%**。

• 另一個多 Agent 研究系統在內部評測中的分數接近單一模型系統的兩倍，但消耗約 15 倍 token。

這些數字是逐字稿轉寫內容，研究名稱、測試條件與指標細節未完整交代，需回看影片確認。

四個評估問題

問題	適合的情況	影片提醒
能否同時開幾條線？	工作可拆成互不依賴的部分	必須逐步交接的任務可能因資訊傳遞而退步
產出能否驗收？	有來源、數據或明確標準	沒有客觀標準時，多 Agent 可能共同接受錯誤
出錯成本高不高？	錯誤影響低，或能補救	高風險、要求精確與可追溯的工作應限制自由發揮
每週做幾次？	每天或每週反覆執行	執行頻率高較可能攤平固定成本

平行與串接工作的比較

• 適合平行：一次盤點四家競爭對手，分別查官網、社群、新聞和價格，最後彙整。
• 需要串接：客訴信先分類，再查訂單、判斷補償，最後回信。影片建議把可平行的步驟先拆出，並要求交接時傳遞可核對的資料。
• 逐字稿引用一項 Google Research 比較：可平行的任務最高進步 81.8%；逐步依賴的任務可能退步 39% 至 70%。具體研究設定未完整說明，請見「待確認資訊」。

驗收與錯誤例子

• 逐字稿提到一個由六個 Agent 組成的系統，加入一個會亂講話的 Agent 後，準確率下降 48.5 個百分點。
• 影片將原因連結到多 Agent 在缺乏客觀判準時可能彼此附和，並指出同一底層模型的 Agent 可能共享盲點。
• 資料查證的例子是：一個 Agent 提出數字，另一個直接核對原始文件。
• 文案方向等較主觀的任務，若沒有明確 Checklist，影片認為不適合只靠多 Agent 互相評選。

成本與任務頻率

• 影片以一次模型呼叫約為「一倍」成本、具規劃與工具使用的 Agent 流程約為「三倍」、整個 Agent 團隊約為「八倍」作比較；計算口徑未說明。
• 逐字稿提到一份顧問公司調查：客服工作約四個月出頭回本，法務工作接近十五個月。調查名稱與計算條件未交代。
• 影片另稱加入中央協調者作為驗證關卡，可降低錯誤；逐字稿記為降低四倍，實際指標與條件不明。

影片中的工作流示範

職缺雷達

• 設定每週一寄送報告，追蹤指定科技公司。
• 平行蒐集新開職缺、已消失職缺、職缺內容或技能變化，以及社群上知名人士加入公司的消息。
• 聚焦軟體工程、AI、Infra、後端與 AI 產品等方向。
• 報告包含職缺、公司、出現日期與值得關注的原因。
• 第一次執行後沒有前一週基準；後續可與上次結果比較。
• 影片示範先試跑、查看細節與結果，再設定每週排程。

API 用量檢查

• 定期查看多個 AI 服務的 API 用量。
• 把突然高於平均值 30% 的情況標示出來，並寄送通知。
• 執行前要先提供或連接相關用量資料來源；影片示範以定期檢查為目標。

可學習的洞察

1. 先拆任務，再決定 Agent 數量。 若工作可以獨立切分，平行處理才較可能帶來效率提升。
2. 把「可核對」當成委派條件。 要能指出結果依據的來源、欄位或標準，才容易發現錯誤。
3. 讓交接資料可見。 對有依賴關係的任務，事先指定交接格式，降低下一步因摘要不足而誤解的機會。
4. 先從低錯誤成本的重複工作開始。 例如可自行核對、錯誤後能補救的追蹤與報表任務。
5. 主觀工作也需要明確檢查表。 逐字稿建議把期待轉為 A、B、C 等可檢查條件，再讓 Agent 依條件交付。

可行動的整理

• 列出自己每週重複進行的工作，逐項回答四個評估問題。
• 優先挑選可平行、能查證、出錯可補救且重複頻率高的任務試跑。
• 對需要串接的流程，先畫出步驟與依賴關係，並定義每個交接點要傳遞的資料格式。
• 為每種產出寫一份簡單的驗收 Checklist，包含資料來源、必要欄位與合格條件。
• 對 API 用量或其他週期性報表，明訂檢查頻率、異常門檻、通知對象與人工核對方式。
• 記錄單次執行成本、人工檢查時間、錯誤與

補救情形，定期比較是否仍值得使用多 Agent。

• 研究細節、數字與研究名稱可列為待查項目，回看影片或原始研究後再納入知識庫。

複習問題

1. 評估工作是否適合多 Agent 的四個問題是什麼？
2. 為什麼可平行執行的工作較適合多 Agent？逐字稿提到的主要風險是什麼？
3. 在沒有客觀驗收標準的任務中，多 Agent 可能出現什麼問題？
4. 為什麼錯誤成本與任務重複頻率會影響多 Agent 是否值得使用？
5. 職缺雷達示範包含哪些可追蹤內容？第一次執行後還缺少什麼比較基準？

待確認資訊

• 逐字稿中的研究名稱、作者、年份與測試條件未完整辨識；包括 71.4%／68.7%、15 倍 token、81.8%、退步 39% 至 70%，以及準確率下降 48.5 個百分點等數字。
• 「成功率四成五以上時，多 Agent 團隊表現開始變差」的研究或判斷條件不明。
• 中央協調者驗證關卡「降低錯誤四倍」的指標與適用條件不明。
• 顧問公司調查的名稱、樣本、回本計算方式與成本範圍不明。
• 一次模型呼叫約一倍、Agent 流程約三倍、Agent 團隊約八倍的成本比較口徑不明。
• 工具名稱、功能名稱與部分設定在逐字稿中有辨識不清之處；API 用量資料來源及職缺追蹤來源的具體整合方式亦未完整說明。