為什麼一個 AI 代理不夠用（以及如何同時執行 1,000 個）- Anthropic 的 CJ Avilla 與 Harrison Stall

Anthropic 工程師 CJ Avilla 與 Harrison Stall 主張，解決真正困難的問題要靠多代理協作（multi-agent orchestration），而非把單一代理做得更大；他們以 Ken Thompson 一個月打造 Unix、以及 OS/360 的《人月神話》教訓作為歷史框架。這場在 AI Engineer 活動發表的演講，大部分是對 Flows 的實作導覽——Flows 是 Anthropic 的 Claude Managed Agents API 中的功能，讓 Claude 自行設計並執行多代理拓撲——再加上一大段關於安全與憑證管理的細節。標題中的「1,000 個代理」並非誇大，但範圍很窄：Avilla 說他個人在週五啟動了一條 1,000 代理的 flow，用來打造一套相容於 Unix 的作業系統，85 小時後仍在執行，GitHub repo 裡已累積約 1,000 個 commit。

Avilla 與 Stall 都是 Anthropic 的技術員工。這場議程一部分是產品發表（Flows 在演講前的週五才上線），一部分是附 API 額度與 QR code 的工作坊，一部分是 Q&A。讀者讀完應該能掌握 Flows 的具體運作機制——主導代理（lead agent）、階段（phase）、session thread、預算、中斷、憑證保險庫、環境政策——以及 Anthropic 所說單一代理會碰上的三種失效模式：代理怠惰（agentic laziness）、自我偏好偏誤（self-preferential bias）與目標漂移（goal drift）。

Flows 讓 Claude 自行設計代理拓撲，但執行成本更高

核心發表是 Flows，隨 Claude Managed Agents 一同推出（Anthropic 於 2026 年 4 月發布）。Flows 是 2026 年 5 月上線的「coordinator and roster」多代理 V1 的後繼者。在 V1 中，開發者必須定義每一個子代理，並逐一監聽每個 thread；到了 Flows，主導代理會先寫出計畫，再依階段向外擴充套件到自己的代理群，視任務複雜度動態增減。開發者唯一必須做的，就是傳入多代理設定，並告訴主導代理去執行一套工作流程。

Stall 用單一代理的天花板來鋪陳價值主張：單一代理大約跑一小時，coordinator-and-roster 架構能跑更久，而動態工作流程則可實現「任意複雜、全部平行運作的巢狀代理組合」。他提到那個迷因——大家帶著半開的筆電到處走，只為了讓 Claude Code 保持存活，並反覆按下核准——並說這種做法對社會級別的問題而言「極度受限」。

Avilla 把同一個觀察清單掃描任務分別用單一代理與 flow 執行並比較，是整集中最清楚的成本效益資料點：flow 貴得多，但在找出所有細節上有效得多。他的建議是：當你想要全面檢視、也願意花這筆錢時，就用 flow。

| 面向 | 單一代理 | Coordinator + roster | Flows（動態工作流程） |
|---|---|---|---|
| 開始劣化前的執行時間 | 約 1 小時 | 較長 | 可任意長，多階段 |
| 誰定義子代理 | 不適用 | 開發者逐一定義 | 主導代理自行定義 |
| 上下文隔離 | 無 | 每個 thread | 每個 session thread，實體隔離 |
| 成本 | 最低 | 中等 | 最高 |
| 最適情境 | 快速任務（約 30 秒） | 特定的委派任務 | 宏大、複雜、可驗證的工作 |

Avilla 也點出實務限制：flow 目前上限為 1,000 個代理，而主導代理可以同時跑多條 flow，或在一條 flow 結束後再啟動新的。他也說，凡是單一代理 30 秒內能完成的事，都不適合用 flow。

三種失效模式說明為何單一代理不夠

Avilla 點名單一代理會崩壞的三種具體方式，每一種都對應到一種 flow 設計模式。

代理怠惰（agentic laziness）。 給出像「我們正在發生故障，檢查這 50 個服務，不要碰正式環境」這樣的提示，單一代理看到 35 個服務健康，就會開始說服自己其餘的也沒問題，然後停手。coordinator 也會遇到類似問題，因為它仍得追蹤有多少服務回報過。Flows 的解法是為每個服務配置獨立的代理上下文，讓你確知每一個都被檢查過。

自我偏好偏誤（self-preferential bias）。 叫代理寫一首詩，再問它這首詩好不好——它會說好。寫程式也一樣。Flows 的對策是在隔離的上下文中進行對抗式審查，不受先前審查者檢查過什麼影響，把生成者與判別者之間的落差延伸到大型問題上。

目標漂移（goal drift）。 在故障的例子裡，「不要碰正式環境」這個指令排在最後。當上下文視窗被填滿並反覆壓縮，這項限制可能會遺失。Flows 會把特定目標一致地複製到所有階段的每個子代理中。

Avilla 把這些連結到歷史框架：Thompson 的 Unix 之所以成功，是因為由一個人掌握「概念完整性」——整個專案都在同一個腦袋裡。IBM OS/360 的經理 Fred Brooks 把教訓寫成《人月神話》，其中包括外科手術團隊模式：一位主刀者，周圍約 10 位專家。Linux 核心展示了規模化版本：Linus Torvalds 在 1998 年碰到臨界點，告訴貢獻者他要去度假，請大家別再塞爆他的信箱。隔天，Larry McVoy 發文說「問題在於 Linus 無法規模化」，並推銷版本控制。約 2002 年，Torvalds 從星形結構（36個參與者全都直接對他貢獻）轉向由受信任維護者組成的分層網路。Avilla 直接類比：今天在協作眾多代理的開發者，將會感受到同樣的瓶頸。

「問題在於 Linus 無法規模化。」——Larry McVoy，由 CJ Avilla 引用

階段層級的模型與預算分配是主要的調校槓桿

Avilla 說明如何透過為不同階段指派不同模型與代理數量來塑造一條 flow。在觀察清單掃描器中，掃描階段可以用 Haiku——快又便宜——每個 ticker 配兩個 Haiku 代理做全面掃描。審查階段可以用 Fable，每個 ticker 配兩到三個代理以追求深度。每個階段都可以依你當下想投入多少而擴張或縮減。

他建議在對重大任務執行 flow 之前，先建立完整的 eval set。在提示方面，Anthropic 發現較模糊、自由形式的初始指令效果更好：告訴 Claude 使用工作流程、每個代理負責一個 ticker、描述你在找什麼，讓 Claude 先建出初始 flow，再微調。

預算在啟動前以 session 為單位設定。如果 flow 觸及預算，你會收到「budget reached」事件；你可以在 session 進行中調高預算，flow 會從中斷處接續，不會丟棄已完成的工作。Stall 說模型在執行時並不知道自己有多少預算——這是刻意的，因為「如果你告訴它預算，Claude 會有點焦慮」。中斷則是另一個 API 事件（user.interrupt），會停止 flow，讓你能重新下提示。

Avilla 把預算與 Managed Agents 一項名為 outcomes 的功能搭配使用：指定你想要的結果與你預期的評分標準，再加上一筆預算，讓代理在兩者範圍內工作。

安全性的基礎在於把大腦與手分開

Stall 用演講的後半段談安全，主張最重要的架構決策，就是大腦（推論迴圈與 session 狀態）與手（代理實際採取行動之處）完全分離。他列出六項具體風險：掃描開放網際網路帶來的提示注入（prompt injection）、憑證外洩、資料外傳、超出指派任務範圍的越權行為、缺乏可視性，以及失控的 session。

憑證機制是技術上最具體的部分。每個需要機密的容器，持有的都是假機密，一旦使用就失效。唯有在出口代理（egress proxy）層，真正的憑證才會在對外送出時被替換上去。Stall 說，沒有辦法用提示誘導 Claude，或存取沙箱來取出真正的憑證。憑證保險庫以環境變數儲存機密，並有兩個設定欄位：注入位置（機密該放在對外請求的哪個位置，例如 bearer token 或請求主體）與允許的主機（替換適用於哪個網域，如此一來 Twilio 金鑰永遠不會被送到任意網域）。

Stall 給開發者的框架是三個動詞：宣告（declare，代理是什麼、許可權、角色設定、技能、工具）、圍堵（contain，實體限制——環境政策限制網域，允許網頁搜尋但不允許網頁抓取，或反之）、偵測（detect，持久的事件串流，讓你能中斷任何走錯方向的 session）。

其他控制項包括：透過 enabled: false 欄位預設停用網頁抓取與網頁搜尋；逐一啟用 MCP 工具，因為你無法事先知道某個 MCP 伺服器會回傳什麼（他提出 GitHub 遭入侵、冒出一個外傳工具的場景）；以及環境層級的網路限制，讓對未列出網域的呼叫在防火牆層就失敗。

Stall 最省力的一項建議：把許可權政策從「always ask」改成 Auto Mode。他引用研究指出，人類在被反覆詢問時大約有 97% 會核准，這使手動核准成為薄弱的控制；相對地，Claude「有耐心得多」，能判斷某次工具呼叫是安全還是具破壞性。

Bug Hunter 與 Explainer Studio 展示了實際生產中的模式

兩條具名的 flow 說明瞭這套做法。Bug Hunter 審查 pull request，把程式碼切片後交給各自獨立的代理上下文，由它們標出潛在問題。第二階段讓一位審查者對每個被標記的問題表示同意或不同意。第三階段挑出可能是真的候選項，執行驗證階段——下載 repo 並嘗試重現該 bug。結果以行內 PR 留言呈現，並附上嚴重性優先序。Avilla 的重點是，人類審查者會帶來關於程式庫遙遠角落的上下文，而 Bug Hunter 能自動浮現這些橫向貫穿的問題。它可作為範本使用，也能透過 Claude Code 中的 Claude API skill 取用。

Explainer Studio 負責生成 Anthropic 從其 ClaudeDevs 帳號發布的動畫影片。它先跑研究階段（規劃、偵查、事實查核），建立簡報，再交給製作階段，由製作階段製作並動畫化個別場景；其他階段則處理音效、旁白與指令碼。Avilla 說，四年前得花約 20 小時才能動畫化的影片，現在只要對 flow 下一個小小的提示。他指出它不會自動上傳到 YouTube，而且你可以餵給它在 Claude Design 中建立的品牌樣式，讓輸出符合你的字型與配色。

Q&A 中的實務解答

Q&A 涵蓋了廣泛的實務問題。關鍵立場如下：

• Claude Code 與 Flows 的差別。 Ultra Code 是互動式、終端機導向、一次性的例項；Flows 則是 API 層級、可重複、由觸發驅動的版本。Stall 說 Anthropic 把 Ultra Code 的方法論一般化成了 Flows。
• 子代理之間的通訊。 沒有讓子代理 A 直接傳訊給子代理 B 的 API。子代理共用檔案系統，可藉此傳遞訊息。thread 的訊息送出／接收事件會揭露代理之間的通訊。
• 上下文隔離。 每個代理都有自己的 session thread，在資料庫中有實體隔離的上下文視窗。預設不會外洩。每個代理都有自己的系統提示。
• 檔案系統許可權。 目前沒有針對目錄路徑的許可權層——只能靠提示。Stall 說這看起來很有用，他們可能會做。變通做法是工具許可權：攔截檔案讀取請求，檢查是哪個代理發出的，再予以拒絕。
• flow 中的人為回饋。 透過自訂工具實作——給 Claude 一個「request human feedback」工具，並回應該工具呼叫。
• 無限迴圈與連鎖錯誤。 設定預算作為護欄。Stall 說 Claude 在偵測行為異常的子代理並自動將其切除上「相當擅長」。
• 代理數量增加的邊際效益遞減。 Stall 說他沒有好數字，並稱這是新的研究領域；他不會意外日後能算出每個子代理的增量能力曲線。Avilla 補充，同樣 100 個代理，組織成 flow 會比毫無結構地丟向問題表現得更好。
• 自架。 Flows 搭配自架沙箱可立即運作；有些功能在那裡未獲完整支援，但 Anthropic 盡量讓功能在所有環境都能用。
• 分享代理。 沒有一鍵分享。有 Terraform provider 可建立代理，主控臺也有匯出功能。Avilla 說最常見的散佈途徑，是在 API 之上打造你自己的產品介面。
• 巢狀深度。 目前只有一層巢狀。Anthropic 基於安全考量，尚未支援任意複雜的超大型 fanout。
• 私有資料存取。 MCP tunnel，使用 Cloudflare tunnel，可在不向開放網際網路暴露任何東西的情況下提供私有 MCP 存取。
• 最佳化 Token 花費。 使用 Claude Code 中的 hill climb skill（Claude API skill 的子指令）來反覆改進提示，並用 Dreaming 產品來跨 session 凝鍊與改善記憶庫。Avilla 描述自己用 hill climb 和孩子一起做比手畫腳遊戲，由 Claude 生成 artifact 來記錄 session，並調整每秒幀數與提示細節。
• 視覺化。 主控臺會即時顯示拓撲，並讓你深入檢視個別子代理與 thread 訊息內容。儀錶板建構在公開 API 上，所以任何看得到的東西都能自己手刻。
• 責任歸屬。 Stall 以自己不是律師為由不回答，只把它定調為跨技術堆疊各層的縱深防禦。

1,000 代理作業系統實驗

Avilla 最具體的規模展示，是他在演講前的週五啟動的一條 flow。提示大致是：Ken Thompson 用一週做出 Unix，你能不能試著做一套相容於 Unix、內建 Python 直譯器的作業系統，使用 flows，儘管放手勇敢去做，最多可用 1,000 個代理。他給它一個 GitHub repo 作為工作區，並要求組一支用 Sonnet 5.5 的檔案撰寫團隊，在每個 flow 階段結束時寫檔案，讓他能藉由讀 repo 追蹤進度。截至演講時，它已跑了約 85 小時，進入第三或第四條 flow，累積約 1,000 個 commit。還沒完成。

這是整集中對 Stall 所歸功於舊金山 AI Engineer 的 Tarek 與 Gary 之「煮沸海洋」框架最清楚的佐證——那個訊息是：有了能力強大的模型，現在該是不合理、更有野心地去做事的時刻。Avilla 的實驗同時也是最誠實的反面例證：這場 1,000 代理協作的旗艦展示並未如期完成。

值得持續追蹤的綜合觀察：Anthropic 押注 1960 與 1970 年代軟體工程的組織教訓——概念完整性、外科手術團隊、以分層信任取代星形拓撲——能直接移轉到代理協作上，而且規模化的產品化會發生在 API 層，而非終端機。尚未化解的張力真實存在。成本隨能力上升，而整集除了「宏大、複雜的任務」之外，並未提供何時值得用 flow 的公式。模型依設計並不知道自己有多少預算。巢狀上限為一層。而那個掛頭牌的實驗——1,000 個代理打造一套作業系統——在議程結束時仍在苦苦運轉。