010. 一次叫醒 41 個 Agent｜速度背後是五百萬 token
真正的新能力，不是模型突然更聰明，而是它能把一份工作拆成大量獨立呼叫，再把結果收回來。
影片一開始就用一個很有張力的畫面示範 Dynamic Workflow：講者 Nate Herk 要 Claude Code 審查自己累積的 41 個 Skills。系統沒有讓一個模型從第一份文件慢慢看到第四十一份，而是啟動 41 個 Haiku workers，每個 worker 負責一份 Skill，再由一個 Opus synthesis agent 排名、找模式、提出改善建議。
結果是一份可以瀏覽的 HTML 報告。它不只列出好壞，還指出每份 Skill 的高價值修正，以及未來新增 Skill 時應避免的問題。平行工作確實縮短了牆上時間，但講者也立刻秀出代價：這次執行約用了 500 萬 input tokens。
原始影片的價值，不只是介紹一個新命令，而是把多 agent 系統最容易被忽略的帳攤開來看。當每個 worker 都要重新讀取自己的上下文、工具說明與任務材料，「平行」不是免費加速，而是拿更多模型呼叫換時間與覆蓋率。
這也提醒我們，不要把所有看起來會「叫其他 agent 做事」的功能混成一類。Skill、Subagent、Agent Team、Goal 與 Workflow 的差異，不只在 agent 數量，而在於三件事：計畫由誰持有、workers 能否互相溝通、任務要向深處迭代還是向寬處展開。
給讀者的 Takeaway
- Dynamic Workflow 用更多模型呼叫換取平行速度與覆蓋率。
- 五百萬 tokens 是講者的個人實測，不是固定價格。
- 先看任務結構，再決定 agent 數量；不要反過來為新功能尋找用途。
021. 先把名詞拆開｜Skill、Subagent、Agent Team 各自解什麼問題
Skill 解決「怎麼做」，Subagent 解決「誰先去做」，Team 解決「怎麼一起做」。
Skill 最接近一份可重用的 recipe。它把做事方法、限制、工具與輸出契約寫下來，讓主 session、automation、Subagent、Agent Team 成員或 Workflow worker 都能調用。它的核心價值是重複性：同類任務不必每次重新解釋。
Subagent 則是隔離上下文的委派。主 session 可以把研究、檔案探索或一段容易塞滿 context 的工作交出去。Subagent 擁有自己的 context window，完成後把結果回報主 session；多個 Subagents 可以平行存在，但依影片的分類，它們不直接互相對話。
Agent Team 多了一層協作。成員可以有不同角色、工具與專長，共享 task list，也能互相交換訊息。這使它適合設計評審、war room、辯論或需要相互修正的任務。但每次溝通都會增加上下文與協調成本，團隊不會因為成員變多就自然變好。
Workflow 的 worker 更像大批獨立 lanes。它們依編排腳本分別處理切片，通常不需要彼此討論，最後才由 synthesis agent 收斂。這種結構特別適合「同一份 rubric 套到很多項目」：四十一份 Skills、數百個檔案、許多獨立研究問題，都是天然候選。
這四種能力不是互斥選項。Skill 可以被 Subagent 使用，Subagent 可以存在於 Team 或 Workflow 中，worker 也可以呼叫 MCP、CLI 與 API。比較合理的理解方式是：Skill 提供局部能力，其他機制決定如何配置計算與溝通。
給讀者的 Takeaway
- 重複方法用 Skill，隔離旁支工作用 Subagent。
- workers 必須互相討論時，才需要 Agent Team。
- 大量獨立切片需要同時展開時，Workflow 才開始有優勢。
032. 複雜度階梯｜能力增加時，風險與成本也一起上升
最強的模式，不等於最適合眼前工作的模式。
影片把能力排成一座很實用的階梯：主 session、Skill、Subagent、Agent Team、Dynamic Workflow。每往上一層，系統可以處理更大的工作，但也同時增加 token、權限、觀測、失敗處理與結果整合的負擔。
主 session 的優點是最直接。做單一修改、回答快速問題、檢查一段程式碼時，讓同一個 agent 從頭到尾持有上下文，通常最便宜也最容易理解。Skill 讓這份能力可重用，仍沒有增加新的協作拓樸。
Subagent 引入第一個分岔：主 session 要決定什麼值得委派，以及何時接受子任務結果。Agent Team 再加入成員間通訊，除了工作本身，還要管理衝突、重複探索與共識。Workflow 則把規模放到最大，必須限制每個 worker 的資料範圍，設計一致的輸出格式，並安排最後的合併與驗證。
因此，階梯上升時增加的不只是「功能」。當某個 worker 誤讀需求，錯誤可能被 synthesis agent 放大；當工具權限過寬，數十個 workers 都可能接觸不必要的檔案或服務；當輸出契約不一致，最後的彙整者會花大量 tokens 清理格式。
講者強調 Workflow 執行前會要求確認，也能查看 raw script。這些保護很重要，但不能取代任務設計。真正的安全邊界仍然是：資料最小化、工具最小權限、worker 數量上限、可停止性，以及明確的交付物。
給讀者的 Takeaway
- 每提升一層，都要能說明新增的協作成本換來什麼。
- 多 agent 任務需要一致 rubric 與輸出 schema。
- 執行確認只是最後一道門，範圍與權限要在 prompt 階段就限制。
043. Workflow 的核心｜計畫離開對話，變成可執行腳本
Workflow 最關鍵的轉變，是 plan 不再只存在模型的下一次回答裡。
一般 Subagent 委派中，主 agent 持有整體計畫：它決定先做什麼、再叫誰、何時整合。Dynamic Workflow 的不同，在於 Claude Code 會先產生一份 JavaScript workflow file，再執行這份腳本來啟動 workers、分派資料與收集結果。
計畫被外部化之後，會得到三個工程上的好處。第一，使用者可以在執行前查看腳本，而不是只能相信對話中的口頭計畫。第二，腳本可以保存、版本化與重跑。第三，執行中的 workers、模型、tokens、工具與時間可以被觀測，而不是混在一條長對話裡。
但「動態」並不表示 workers 隨意發揮。比較精確的說法是：系統根據使用者給的目標，動態生成一份本次適用的編排；一旦開始執行，多數 workers 仍是在明確 lane 裡完成既定任務。它不是每個 agent 都自由討論，也不是無限迴圈。
影片示範的 Skill audit prompt 很具體：指定兩個 Skills 位置、評分項目、pass/fail 條件、trigger quality、每份 Skill 的最高價值修正，以及最後的全體排名。正因為輸出契約清楚，四十一份結果才有辦法被同一個 synthesis agent 合併。
另一個容易忽略的細節是儲存位置。講者發現生成的 Workflow 預設未必落在專案內，因此另外要求保存到 project workflow directory。對團隊而言，這不是小事：如果編排腳本代表可重複的工程流程，它就應該和程式碼一樣接受 review、版本控制與變更紀錄。
給讀者的 Takeaway
- Workflow 是可執行、可觀測、可重跑的編排，不只是更長的 prompt。
- 動態的是編排生成；worker 仍應有清楚邊界。
- 值得重跑的 Workflow 應進專案版本控制。
054. 深度與寬度｜Goal 持續追完成，Workflow 平行鋪開
Goal 問「完成了嗎？」；Workflow 問「可以同時拆成多少份？」
影片用 depth versus width 區分 /goal 與 Workflow，這是整支影片最可移植的框架。
Goal 偏向深度。agent 會反覆工作、檢查客觀完成條件，再決定是否進入下一輪。測試是否通過、migration 是否完成、清單是否歸零，都能形成 done == true 的終止條件。它可能使用 Subagents，但核心仍是沿著同一目標向下迭代。
Workflow 偏向寬度。它先把工作切成許多可平行的 lanes，讓 workers 同時處理，再把結果收斂。每個 worker 通常只完成分配到的部分，不負責判斷整體是否已經真正完成。
兩者理論上可以組合：Goal 在每輪啟動 Workflow，大量 workers 做水平掃描，彙整後再由 Goal 判斷是否要進下一輪。這會形成很強的自治系統，也會形成很強的花費與失控能力。沒有預算上限、最大輪數、停止條件與人工 checkpoint 時，這種組合不應成為預設。
工程上常見的誤判，是把「任務很難」直接等同於「需要很多 agents」。難題有時需要的是一個 agent 深入理解並反覆驗證，而不是五十個 workers 各讀一小段。只有當各部分的依賴低、輸出可標準化、合併成本可控時，寬度才真正帶來收益。
給讀者的 Takeaway
- 需要持續驗證完成條件，用 Goal 型迴圈。
- 需要大量互不依賴的切片，用 Workflow 型平行。
- Goal 包 Workflow 前，必須先設輪數、預算與人工 checkpoint。
065. Token 經濟學｜真正昂貴的是每個 worker 都要讀一次世界
平行運算縮短等待時間，卻不會縮短所有 agents 加總後讀過的內容。
講者的兩個數字很醒目：Skill audit 約用了 500 萬 input tokens；另一個掃描桌面、local files 與 repositories 的測試，據他表示消耗了每月 200 美元方案約一半額度。它們不能直接換算成普遍價格，卻準確指出成本來源。
每個 worker 都是一個獨立模型呼叫。它需要 System Prompt、工具描述、任務指令，以及被分配的檔案或資料。若四十一個 workers 都讀到大量重複背景，總 input 會快速膨脹。output 可能很短，但讀取本身已經產生成本。
控制成本的第一步不是把所有 workers 換成便宜模型，而是減少不必要的 context。把每個 worker 的輸入限制在單一檔案或清楚切片；把共同 rubric 寫短；避免把整個 repository 丟給每一個 worker；要求結構化、精簡的回傳。模型選型是在這些工作完成後的第二層優化。
影片也建議 workers 可使用 Haiku，再讓較強模型負責 synthesis。這種「便宜模型做一致性高的局部判斷，強模型做跨結果整合」很合理，但前提是局部任務真的能以一致 rubric 評分。若每個切片都需要深度架構判斷，便宜 worker 產生的噪音，可能讓最後的 synthesis 更貴。
最實際的預算公式不是精確美元，而是一個乘法概念：
總成本 ≈ worker 數量 × 每個 worker 的平均輸入 × 模型單價 + synthesis 成本
任何一項失控，總量都會迅速放大。
給讀者的 Takeaway
- 先縮小每個 worker 的 context，再談換便宜模型。
- worker 模型與 synthesis 模型可以分層。
- prompt 應明確限制 scope、deliverable、輸出長度與 worker 數量。
076. 選型準則｜先問能否獨立切片，再決定要不要編排
新能力值得理解，但只有解決真實痛點時才值得啟動。
這支影片最後的一張投影片，可以整理成一份務實的選型表：
- 快速問答、單一修改：直接使用主 session。
- 重複出現、方法穩定的工作：做成 Skill。
- 容易污染主 context 的旁支任務：交給 Subagent。
- 多個角色必須交換意見與修正彼此：使用 Agent Team。
- 必須持續迭代直到客觀條件成立：使用 Goal。
- 可拆成大量獨立切片、平行能顯著加速：使用 Dynamic Workflow。
最重要的判斷題只有一句：這件事是否能拆成許多彼此獨立、可以同時執行，而且能用一致格式驗收的部分？
若答案是否定的，增加 workers 往往只會增加重複閱讀與整合負擔。若答案是肯定的，還要繼續問：每一份切片值得一次完整模型呼叫嗎？錯誤能否被最後的驗證攔住？工具權限是否足夠小？預算與停止條件是否清楚？
Dynamic Workflow 的成熟用法，不是讓 agent 數量看起來壯觀，而是讓編排具備工程品質：輸入可追溯、workers 有界、輸出可驗證、過程可觀測、腳本可 review、成本可預估。
影片裡四十一個 agents 同時工作的畫面很吸引人，但真正值得帶走的不是「四十一」。而是講者最後那句克制的提醒：知道一個功能做什麼，不表示你每天都需要使用它，也不表示不用就落後。
給讀者的 Takeaway
- Workflow 的必要條件是可獨立切片、可平行、可標準化驗收。
- 高風險任務要有 synthesis 之外的最終驗證。
- 最小可行的協作模式，通常也是最容易維護的模式。