單一 Agent 的 AI 程式開發對工程師來說是一場惡夢
單一 Agent 的 AI 程式開發對工程師來說是一場惡夢
由 @MilksandMatcha 和 @0xSero 創作
我支付了預付訂閱費（每月 200 美元），寫下我自認為正確的 Prompt（同時身兼 Prompt 工程師與 context 工程師），然後開始等待。35 分鐘後，Agent 仍然處於「正在合成」、「正在研讀」、「正在執行」以及「正在萌芽」（到底是誰想出這些詞的）的狀態。
最後，我得到了一堆糟糕的程式碼、一個臃腫的 context window，而我正用左手數著剩餘的 token。
好吧，我拿了個蘋果，壓縮一下 context，輸入一些嚴厲的言語辱罵，從頭重新解釋一切，並祈禱下一次嘗試能比上一次走得更遠……結果卻被同樣的失敗再次打擊。
到了現在，AI 程式開發的火花與樂趣早已蕩然無存。
別再當個「一次性」的 Sloperator
這就是單一 Agent 的天花板。任何使用 AI Agent 進行開發的開發者，一旦專案從一個 3D HTML 貪食蛇遊戲升級到任何更實用的東西時，就會立刻撞上這個天花板。原因有二：
我們對單一 Agent 的期望太高了
我們沒有將問題拆解成足夠簡單、可驗證的任務
雖然這時候大多數人會向你兜售：(a) 一門沒用的 Prompt 工程課程，(b) 另一個管理你 context 的 SaaS 工具，(c) 或者問你為什麼還沒試試幾秒鐘前剛發布的新模型，但我們今天不會這麼做。
相反地，我們將帶你了解真正有效的方法：經營一個適當的後勤團隊。也就是 Multi-agent 工作流程。
歡迎來到後勤廚房
最近幾週，Multi-agent 工作流程變得更加實用，原因有幾個：底層模型變得更強大，且熱門的 AI 程式開發 Agent 讓 Multi-agent 的編排變得更容易設定。在上個季度，OpenAI 在 Codex 工作流程中推出了更深度的編排功能，而 Anthropic 則持續擴展 Claude Code 和 MCP 生態系統。
不過，最大的突破在於速度。OpenAI 最新的模型之一 Codex Spark（由 @cerebras 提供支援）運行速度約為每秒 1,200 個 token，這使得引入平行處理和驗證步驟變得切實可行，否則這些步驟在過去會因為太耗時而無法執行。
以一個使用 Codex 和 Figma MCP 將網站複製到 Figma 的任務為例，單一 Agent 工作流程平均每次運行需要 36.5 分鐘，平均需要 12 次人工介入（且失敗率為 100%），而利用 CodeX Spark 的 Multi-agent 工作流程僅需 5.2 分鐘，只需 2 次人工介入，且第一次嘗試就成功了。
什麼是 Multi-agent 工作流程？
Multi-agent 工作流程從架構層面解決了單一 Agent 的天花板問題。不再是由一個廚師包辦所有事情，而是由一位主廚（Head Chef）接收訂單，將其拆解成有範圍限制、可驗證的工單，並將每一張工單交給一位廚房助手（Line Cook）去執行。
主廚（Orchestrator）：
主廚的工作是接收來自人類的訂單，將其拆解成一份可執行的工單列表，然後呼叫廚房助手去完成每一個較小、有範圍限制的工作。Orchestrator 負責規劃、協調和任務拆解。它唯一的工具是 delegate_task，它只能看到高層級的目標以及子 Agent 輸出的摘要。
廚房助手（Subagents）：
廚房助手的工作是接收主廚給予的工單（任務分配）並完成工作，過程中不需多問。每一位廚房助手都有自己全新的工作站（context window），完成工作後交出成品，然後打卡下班。Subagents 可以讀取、寫入、使用 MCP 以及任何所需的工具。它們只會看到分配給自己的 Prompt 和一個全新的 context window（沒有之前的歷史紀錄）。
保持井然有序的秘訣在於：廚房助手不會收到完整的訂單歷史紀錄。它也不會收到你那份 15,000 個 token 的總體規劃文件，它不需要看那些。它只需要獲得烹飪一道特定菜餚所需的「最小可行 context」。
在像 Codex 這樣的 AI Agent 中，你只需明確告訴你的 Agent「使用子 Agent」即可建立一位廚房助手。這個新的實例會獲得一個 Prompt、一組它可以存取的檔案，以及它所需的任何 context。
經營後勤團隊的三大即時優勢
與其試圖一次性完成你正在建構的任何東西，或者堅持使用單一、頂尖但昂貴的模型，採用 Orchestrator 和 Subagents 可以為你帶來三個明顯的優勢。
1. Token：你的有效 context window 從約 200K 擴展到 25M+
人類、Orchestrator 和 Subagents 的互動方式如下：
人類只與 Orchestrator 對話。
Orchestrator 被剝奪了除
delegate_task之外的所有工具。如果 Orchestrator 想要採取行動，它會透過
delegate_task產生一個 Subagent。每個 Subagent 都有自己全新的 context window，只從一個 Prompt 開始。
Subagents 可以讀取、寫入、使用 MCP 以及任何其他工具。
Subagents 將其工作摘要回傳給主廚。
這意味著 Orchestrator 永遠不需要直接讀取檔案、寫入檔案或查看工具呼叫結果，從而有效地將其 context window 擴展到它所能產生的所有 Subagents。你可以整天工作而不會丟失 context、不需要壓縮，也不需要重新開始。
2. 控制：你可以在 Agent 迴圈的每一步強制執行順序工作流程
與其讓一個 Agent 完成探索、烹飪、品嚐和擺盤，不如將每個步驟變成精確、順序性的工單。這也是針對不同任務使用不同模型的絕佳時機。有了像 Codex Spark（約 1,200 toks/sec）這樣顯著更快的模型，我們可以增加驗證和 QA 步驟，這些步驟在過去通常太過耗時。
Orchestrator 遵循腳本，每個階段產生一個 Subagent：
Sub-agent A 將訂單拆解成包含子任務和標準的「合約」。
Sub-agent B 探索下一個子任務。
Sub-agent C 測試前一個子任務產生的程式碼。如果測試通過驗證標準，則繼續。否則，重新產生一個負責程式撰寫的廚房助手來修復已識別的問題。
Sub-agent D 記錄子任務並更新範圍檢查清單。
如果還有剩餘的子任務，則從第 2 步繼續。否則，服務結束。
在內部測試中，這種順序迴圈與相同簡報下的單一 Agent 運行相比，減少了 84.3% 的人工介入。
3. 速度：你可以平行執行定義明確的任務
如果你的任務允許，你可以平行產生多個 Subagents。這非常適合：
產生 Logo、圖片、吉祥物、asset、模型、設計或測試。
以快上幾個數量級的速度探索龐大的程式庫。
快速建構多個頁面，其中每個 Subagent 在程式庫的不同部分工作，且不會互相覆寫。
執行五個平行的吉祥物產生任務大約需要一分鐘，而順序執行則需要五分鐘，在以品味為導向的探索任務中，速度提升了約 5 倍。
5 種真正有效的模式
在過去的幾週裡，我們嘗試了數十種跨不同 AI Agent 的工作流程和設定。以下是我們在建構 Multi-agent 工作流程中發現成功的五種模式。
如果你是新手，請從最上面開始，一步步往下看 :)
模式 1：備料線（The Prep Line）
在服務開始前，專業廚房不會只有一個廚師慢慢地切每一種蔬菜。它有一排備料廚師，每個人都在同一個工作站獨立工作，一個切洋蔥，一個處理紅蔥頭，一個分裝蛋白質。最後，副主廚會檢查並挑選出合格的成品。
這對於設計探索、程式碼變體或測試產生等任務來說是正確的形態。讓你的廚房助手各自產生許多選項，然後你再手動挑選最好的。每一位廚房助手都獨立處理相同的簡報，而你（是的，你確實有一項小任務）負責審核結果。這是讓你熟悉 Multi-agent 工作流程最簡單的方法，因為每個任務都是完全獨立的，沒有檔案衝突、依賴關係圖或合併邏輯。
舉個例子：我們想為 Parchi 建立 50 種吉祥物變體，所以我們派遣了 5 個 Codex Spark Subagents，每個產生 10 種變體。然後我們挑選出我們喜歡的，剩下的就丟棄。
這種模式最棒的地方在於：它也是將「品味」注入 AI 工作流程的好方法。現今的模型幾乎沒有品味。
很有可能，你可能也缺乏品味。對於大多數開發者來說，暴力破解的解決方案是搜尋設計或圖形模式的範例，或者給予 AI 程式開發 Agent 足夠多的風格指南，以至於你還不如自己寫 HTML/CSS。與其進行那種乏味的手動過程，不如讓你的主廚呼叫一隊廚房助手，然後挑選你最喜歡的。
模式 2：晚餐尖峰（The Dinner Rush）
在週五晚上的晚餐尖峰時段，廚房裡的每個工作站（炒鍋、烤架、冷盤、甜點）都在同時運作。每位廚房助手負責不同的工作，但他們同時擺盤，共同完成同一張工單。
這就是「群體（swarms）」背後的概念，由 MoonshotAI 在訓練 Kimi-K2.5 時首創。在群體模式下，每位廚房助手負責一個單一、有範圍限制、明確的任務。這些廚房助手同時運行，共同為一個共享目標做出貢獻。
適合的情況：建構應用程式的多個獨立組件、為不同模組編寫測試，或將頁面從一個框架移植到另一個框架。
這種設定需要幾件事到位：
你需要一個非常具體的工作範圍。
該範圍需要拆解成個別、可驗證的步驟。
每個任務必須有明確記錄的依賴關係。
每個任務應該只需要變更一組預定義的檔案，這樣廚房助手就不會互相覆寫。
重要提示：關鍵要求是任務不能共享檔案。一旦兩位廚房助手需要編輯同一個檔案，你就需要另一種模式。
模式 3：順序套餐（Courses in Sequence）
品嚐菜單不會一次全部上桌。開胃小點（amuse-bouche）會在任何人開始準備前菜前送出，前菜清空後主菜才會開始擺盤，甜點則等待輪到它。但在單一道菜內，每個工作站都在平行烹飪。
這就是「分階段平行執行」背後的想法。你將專案拆解成套餐（或「波次」），其中每一道菜都嚴格依賴於前一道菜。在每一道菜內，任意數量的任務和廚房助手都可以平行運行。這非常適合較大的專案，例如完整的應用程式重構或大型重構。
要使這種模式有效，你需要依賴樹、嚴格的順序和精煉的 Prompt。值得參考 https://factory.ai/news/missions 來看看他們是如何處理這個問題的。
這是一個重構整個 UI 的真實範例。第一階段（Course 1）進行探索和映射，而第二階段（Course 2）則建立在這種共享理解之上。兩階段的廚房助手都不需要完整的對話歷史紀錄。他們只獲得與其工單相關的確切 context 簡報。
作為人類，你明確定義了所需內容。套餐結構為你提供了平行處理和順序控制，這就是為什麼它比純粹的群體模式更能擴展到實際專案的原因。
模式 4：備料到擺盤的組裝（The Prep-to-Plate Assembly）
你的廚房助手不會每個人都從頭開始製作一道菜。一個工作站負責修剪和調味蛋白質，下一個負責煎烤，再下一個在烤箱中完成，最後由傳菜員擺盤和裝飾。每個工作站都有一個明確的工作，乾淨地交接，且不會將前一張工單的醬汁帶入下一張。
在這種模式下，廚房助手沿著傳菜口順序操作。每個廚師執行一個較小的任務，驗證它，然後將工件交給下一個工作站。
這種模式非常適合具有明確、可觀察和可驗證結果的長期任務、研究密集型任務或多步驟管道。核心原則：不要將不相關的歷史紀錄拖入一個巨大的執行緒中。每個階段獲得足夠的 context 來完成其部分，然後交接。狀態存在於檔案和任務佇列中，而不是對話中。
階段之間乾淨交接。狀態存在於檔案和任務佇列中，而不是對話歷史紀錄中。在一個目標是在特定硬體上運行自定義模型的範例中，每位廚房助手都有明確、有界限的工作。
這是一個目標是在特定硬體上運行自定義模型的範例。特別注意每位廚房助手是如何擁有明確、有界限的工作的。
模式 5：戈登·拉姆齊來了（Here comes Gordon Ramsay）
在專業廚房中，廚師製作菜餚，但它不會直接送到顧客手中（我們希望如此）。相反，它會先經過檢查。一個人檢查烹飪是否正確，另一個人檢查它是否符合訂單且擺盤正確。
這最後一種模式與其說是一種專案架構，不如說是一種紀律：你將編寫程式碼的廚房助手與檢查程式碼的廚房助手分開。一個建構者負責烹飪，而兩位驗證者（一位程式碼審查員和一位視覺/功能測試員）平行運行以驗證輸出。如果任何一位驗證者標記了問題，建構者就會獲得另一次機會。特別是有了像 Codex Spark 這樣近乎即時的程式開發模型，增加驗證幾乎是零成本的。
在這個工作流程中，一次只有一個建構者在編寫，但多個驗證者可以同時運行。這是避免合併衝突和 context 漂移最重要的一條規則，並且適用於此清單中的每一種其他模式。
何時使用它：永遠使用。無論你正在運行哪種模式，都要在上面疊加這一層。將建構與驗證分開，可以在失敗級聯到下游任務之前捕捉到它們。在驗證步驟中使用瀏覽器自動化、截圖和確定性測試。目標是沒有任何廚房助手的輸出能在沒有證據證明其有效的情況下進入傳菜口。
未來趨勢
如果你從這篇反思中學到了一件事，那就是：單一 Agent 一次性完成任務的時代已經結束了。我們還處於早期階段，隨著模型變得更快、context window 變得更長，以及工具變得成熟，這些模式將持續演進。
脫下圍裙，穿上主廚的外套吧。你現在正在經營廚房，而你的團隊正在等待。你可以在這裡閱讀更多關於如何開始使用 Codex 和 Codex Spark 的資訊。
感謝 Zhenwei Gao 和 James Wang 的意見，以及 @brickywhat，他首先向我們介紹了「sloperator」這個詞。插圖由 @halleychangg 繪製。