Agent Teams vs Dynamic Workflows
這支 Kelly Tsai 的影片把三種常被混在一起的協作模式拆開：subagents、agent teams、dynamic workflows。影片的核心訊息很清楚：這三者不是同義詞，而是不同的協作層級；差別不只是「有幾個 agent」，而是 AI 之間要不要直接溝通、編排是不是決定性的、以及人類要介入到什麼程度。
三種模式
1. Subagents
- 主控 agent 把任務切開，分給各自獨立的分身。
- 分身彼此不聊天，只把結果回傳給主控。
- 適合完全獨立、可平行處理的工作，例如批次檔案檢查、履歷初篩、各自爬不同網站。
2. Agent Teams
- 底下的 agent 共享一個群組式工作空間。
- 可互相傳訊息、共用待辦清單、即時對齊方向。
- 適合彼此有依賴、需要邊做邊對齊的任務，例如產品規格討論、設計與工程協作。
3. Dynamic Workflows
- 主控 agent 不只分工，而是根據任務進展動態決定要召喚多少子 agent。
- 目標是讓模型自己產生編排計畫，最後再整合結果回報。
- 適合高度可拆解、但子問題數量與深度要視中途發現而調整的工作。
Cross-session messaging：有傳訊、沒有共享工作空間
BusinessNext 2026-08-10 整理 Claude Code v2.1.224 的 cross-session messaging。它讓各自獨立、由人分別駕駛的 session 互相傳送純文字摘要，可用來詢問長任務進度、交接決定或同步不同 worktree 的變更；但訊息不帶對話歷史、檔案或權限，也不提供共享待辦清單。
因此它位在 subagents 的獨立性 與 agent teams 的互動性 之間：比完全隔離多一條 handoff 通道，卻比共享群組工作空間窄；它也不是 dynamic workflow 的主控編排器。接收端的 accept／hold／refuse、不能代替人類授權，以及重複訊息節流，讓「能互相說話」和「能替人作決定」保持分離。這個差異應和 ai-collaboration-compounding-workflow、agent-experience 一起評估。
Grok Bot：把 Agent Teams 產品化成工具內交付
BusinessNext 2026-08-12 報導 SpaceXAI 的 Grok Bot early beta：一個「幕僚長」Bot 統籌收件匣、費用、招募與除錯等專責 Bot，Bot 之間可傳訊、共用專案上下文，只有需要判斷時才把人拉回來。這比單純 subagents 更接近 Agent Teams，但又加入可重複執行的 routine；雲端 computer-use 也讓 Bot 能直接登入沒有現成 API 或 MCP 的工具，把完成品放回真人原本使用的系統。產品仍是 early beta，方案、功能與實測效果保留為 SpaceXAI／BusinessNext attribution，不當成獨立 benchmark。
影片的判斷重點
影片不是在說「多 agent 一定比較強」，反而在強調：
- 並行 不等於 分工。
- 多 agent 常常會因為傳話、上下文遺失、與成本疊加而變慢。
- 如果任務本質上需要同一套上下文，單一 agent 可能更穩。
- 真正值得開團隊的情境，是大量獨立子任務、或需要即時互相修正的情境。
Google Research 的 scaling agent systems 研究補上量化版本的同一條規則：多 agent 不是「越多越好」，而是要對齊任務結構。它在 180 個 agent configurations 上比較 single-agent、independent、centralized、decentralized、hybrid 五種架構，發現可平行任務如 Finance-Agent 上 centralized coordination 可比單一 agent 提升 80.9%，但 PlanCraft 這類嚴格序列任務中，多 agent 反而下降 39–70%。
這篇研究也把 architecture 當成 reliability / safety feature：independent multi-agent 因缺乏互查機制，錯誤放大可到 17.2x；centralized orchestrator 則把錯誤放大壓到 4.4x，因為 orchestrator 變成驗證瓶頸。對 cognitive-load-agent-orchestration 與 agent-framework-selection 來說，實務判準可簡化成三個 measurable task properties：子任務可拆解度、序列依賴強度、工具數量／tool-coordination tax。
這個觀點與 dynamic-agent-workflows 很接近，但影片額外補了一塊：Agent Teams 的互動性。也就是說，dynamic workflows 偏向可重播、決定性的編排；agent teams 則偏向執行中可互相對話、即時調整。
Sakana Fugu 則代表另一種產品化路線：把多 agent / 多模型編排直接封裝成「一個模型 API」。使用者不需要定義 subagents、agent teams 或 dynamic workflows，而是呼叫 sakana-fugu 這類 orchestrated endpoint；底層 routing、角色分配與協調策略由 provider 處理。這讓採用成本下降，但也降低了 agent-trace-observability 與 workflow 可除錯性。
實務啟示
- 先判斷任務是否真的需要多 agent。
- 如果子任務彼此獨立，優先用 subagents。
- 如果子任務需要互相看見彼此的工作，才考慮 agent teams。
- 如果你需要的是自動規劃、動態擴縮與可驗收的編排，dynamic workflows 更合適。
- 在 code / product / research 場景，最重要的不是「開幾個 agent」，而是設計好依賴關係、驗證節點與成本上限。
- 若任務有高 decomposability、低序列依賴，可考慮 centralized orchestration；若任務需要單一路徑推理或高工具密度，先用單一 agent + harness gate。