隆重介紹 Deep Agents 中的動態 Subagents

隨著 Agent 承擔的任務越來越複雜，它們往往會面臨兩個難題：

1. 無法可靠地大規模完成工作
2. 難以有效管理自身的上下文

為了解決這些挑戰，我們一直在嘗試一種名為「動態子代理」的解決方案（dynamic subagents）：與其透過通用的工具呼叫來指派子任務，不如讓 Agent 編寫一個簡短的腳本，由這個腳本來驅動子代理的執行。這意味著模型可以利用其擅長的程式碼模式（例如迴圈、分支或並行處理）來撰寫適合特定任務的編排邏輯。

為什麼需要動態子代理？

Deep Agents 已經支援 子代理。它們能隔離上下文，讓主 Agent 委派獨立的工作單元，並將中間結果保留在主上下文視窗之外。那麼，我們為什麼還需要動態子代理呢？

使用一般的子代理時，它們是由主模型直接逐一呼叫的。這種方式在小規模運作時沒有問題。但當你需要生成數百個子代理，或編排邏輯涉及條件判斷或多階段流程時，這種方法就行不通了。

動態子代理透過程式化編排解決了這個問題。Agent 不是逐輪進行工具呼叫，而是撰寫一個簡短的腳本，這個腳本負責編排和呼叫子代理，並在一個輕量級的直譯器中執行。

一個典型的例子是：為一份 300 頁的文件，每頁配一個子代理進行處理。與其呼叫子代理工具 300 次，Agent 只需寫一個迴圈：

1const results = await Promise.all(pages.map(page =>
2  task({ description: `Summarize page ${page.number}`, subagentType: "summarizer" })
3));

這解鎖了基於工具呼叫的編排方式無法可靠達成的兩件事：

大規模的確定性覆蓋。 缺乏結構時，Agent 會自行判斷範圍，可能篩選了 500 項中的 75 項就認為完成了。但一個分發迴圈不會。覆蓋率變成了一種結構性的保證，而不是一個提示工程的問題。

可靠的複雜編排。 將編排邏輯寫成程式碼，比讓模型將其重現為一系列工具呼叫更加可靠。尤其在處理「扇出 + 綜合」、「多階段流程」或「條件分支」時更是如此。

這與 Claude Code 中的工作流程 和 遞迴語言模型 (RLMs) 背後的構想相同：模型編寫程式碼，然後由程式碼來分發更多 Agent。

快速入門

動態子代理需要兩個要素：子代理 來分發工作，以及一個程式碼直譯器：一個安全、輕量級的執行環境，用來讓模型編寫和執行編排程式碼。Deep Agents 包含一個基於 QuickJS 的可選程式碼直譯器。要使用它，請安裝 QuickJS 中介軟體套件，然後在 create_deep_agent 的 middleware 參數中傳入 CodeInterpreterMiddleware。

1pip install -U "deepagents[quickjs]"

1from deepagents import create_deep_agent
2from langchain_quickjs import CodeInterpreterMiddleware
3
4agent = create_deep_agent(
5    model="openai:gpt-5.5",
6    middleware=[CodeInterpreterMiddleware()],
7)

Deep Agents 內建了一個通用型的子代理，因此已經有一個通用的子代理設定檔可以在工作流程中使用。對於專業化的工作流程，你可以配置自訂子代理，並為它們設定各自的名稱、描述和系統提示詞：這些名稱和描述就是 Agent 用來判斷該使用哪個角色的依據。

要觸發動態子代理，請在提示詞中包含「工作流程」這個詞，就像這樣：

1result = await agent.ainvoke({
2    "messages": [{"role": "user", "content": "Run a workflow that reviews every file in src/routes/ and summarizes the top risks."}]
3})

與程式碼 Agent 搭配使用

體驗動態子代理最快的方式是使用 dcode，這是我們基於 Deep Agent 構建的終端程式碼 Agent。它預設啟用了程式碼直譯器，所以無需任何設定 — 動態子代理開箱即用。

安裝

1curl -LsSf https://langch.in/dcode | bash

執行

1dcode

要觸發動態子代理，只需要求一個「工作流程」。Agent 不會自己埋頭苦幹，也不會嘗試用其原生的任務工具來管理子代理的扇出，而是會撰寫一個編排腳本，該腳本會呼叫內建的 task() 全域函數並在程式碼直譯器中執行。例如：「執行一個工作流程，審查 src/ 中的每個檔案是否有 SQL 注入風險。」

當子代理生成時，dcode 會將它們即時顯示在動態子代理面板中，並按分發階段進行分組。

你可以透過 dcode 最快地體驗，但也可以透過 ACP（例如在 Zed 中）在你選擇的工具中使用它。

運作原理

Agent 被授予一個評估工具。它編寫在直譯器內安全執行的 JavaScript。當子代理配置完畢後，直譯器會暴露一個內建的 task() 全域函數，用來從程式碼中分發子代理。根據手頭的任務，模型會編寫不同的程式碼 — 一個迴圈、一個分支、一個 Promise.all — 然後直譯器會確定性地執行它。

task() 接受一個描述（description）、一個子代理類型（subagentType），以及一個可選的回應模式（responseSchema）— 當提供了後者時，結果會是一個已經型別化的物件，可以直接過濾或傳遞給下一步。

1const result = await task({
2  description: "Review src/auth/login.ts for security issues.",
3  subagentType: "reviewer",
4  responseSchema: {
5    type: "object",
6    properties: {
7      severity: { type: "string", enum: ["high", "medium", "low"] },
8      issues: { type: "array", items: { type: "string" } },
9    },
10  },
11});
12
13const critical = result.severity === "high" ? result.issues : [];
14critical; // model sees the last line

更多資訊，請參閱文件中的程式化子代理和直譯器。

常見的編排模式

Anthropic 的動態工作流程推廣了一套適用於平行 Agent 工作的編排模式。它們不是你可以開啟的功能，而是隨著工作自然產生的形狀，當任務改變時，Agent 會自動適應不同的模式。下表將每種模式映射到其最適合的工作類型。

接下來，我們將深入探討每種模式如何在 Deep Agents 中運作，並附有即時追蹤。我們還製作了一個影片解釋這六種模式，你可以在這裡查看。

分類與執行

首先對項目進行分類，然後根據分類結果，將每個項目交由專門的子代理處理。這讓你可以處理混合輸入，其中不同的項目需要不同的專業知識。

使用案例： 分類處理支援票證、錯誤日誌、使用者反饋，或任何需要根據類型進行不同處理的批量項目。

範例：處理待處理的支援票證。Agent 讀取票證並將每個票證分類為錯誤、功能請求或問題。錯誤交給錯誤調查員，功能請求交給功能分析師，問題則交給支援回覆員。最終結果是按類別分組的摘要。

在此處查看追蹤。

扇出與綜合

Agent 將相同類型的工作平行分發給多個項目，然後合併結果。

使用案例： 跨目錄的程式碼審查、分析一批文件、處理日誌檔案、在多項服務上執行相同的檢查。

範例：對原始碼目錄進行逐檔案安全性審查。Agent 發現 src/ 下的每個 TypeScript 檔案，並為每個檔案平行分發一個安全性審查員。然後將結果合併成一份單一的優先級報告，包含嚴重性評級和需要修改的程式碼行。

在此處查看追蹤。

對抗驗證

一種兩遍模式。第一遍產出發現結果。第二遍將每個發現結果發送給獨立的驗證員，只有通過一致性驗證的發現結果才會被保留。當正確性比速度更重要時，這可以減少誤報。

使用案例： 誤報成本高昂的安全審計、合規檢查，以及任何需要對調查結果有高度信心的審查。

範例：一次無法容忍誤報的安全審計。審計員對潛在漏洞進行廣泛搜尋，然後將每個發現結果交給一個獨立的驗證員，該驗證員重新閱讀程式碼並返回「已確認」或「已駁回」的判定。只有被確認的發現結果才能進入最終報告。

在此處查看追蹤。

生成與篩選

多個子代理為同一個問題生成獨立的解決方案。Agent 在程式碼中進行比較、評分和篩選結果，只保留最佳方案。

使用案例： 架構提案、重構策略、內容變體，以及在最終確定前探索多種選項能產生更好結果的任何任務。

範例：對多個競爭的速率限制器重新設計方案進行排名。Agent 讓一個架構師產出若干個對 rate-limiter.ts 的獨立重新設計方案，每個方案都寫入自己的檔案以避免互相覆蓋。然後根據在突發情況下的正確性、多實例支援和複雜度進行評分。最強的方案獲勝，並附有其勝出的理由。

在此處查看追蹤。

錦標賽

各種方案由一個評審子代理進行兩兩比較，優勝者進入下一輪淘汰賽。

使用案例： 基於主觀標準的優化、風格選擇、在競爭性實作之間做出選擇。

範例：針對混亂的 createOrder 處理器的重寫方案進行配對淘汰賽。幾位編寫者各自產出一個候選重寫方案，各有不同的優先級，然後一個評審者將它們兩兩比較，逐輪選出優勝者，直到產生一個冠軍。它會附上評審者的推理過程。

在此處查看追蹤。

持續迭代直到完成

Agent 運行一個發現迴圈，對已經找到的結果進行去重，直到沒有新的發現為止。當工作的範圍事先未知時，這個模式非常有用。

使用案例： 徹底搜尋、檢測死程式碼、依賴審計，以及任何追求完整性而非固定結果數量的掃描。

範例：基於迭代的安全性掃描。Agent 執行一次掃描，在程式碼中檢查它的發現，只有當上一輪發現了新的問題時，才啟動下一輪掃描。當一輪掃描沒有發現任何新問題時停止。它會報告匯總後的發現總數以及總共進行了多少輪掃描。

在此處查看追蹤。

結論

動態子代理是賦予 Agent 更多自主性和可靠性的方法。程式碼負責處理覆蓋率和中間上下文，而模型仍然專注於需要判斷力的核心工作。上述模式只是一個起點。在實踐中，Agent 會根據任務需求組合和混合使用它們。

這是遞迴語言模型概念最簡單的體現。一個 Agent 編寫程式碼，而這個程式碼又分發更多的 Agent。這是一個遞迴呼叫自身的 Agent，它不受上下文視窗的限制，也不會被束縛在固定的工作流程中。一個 Agent 可以將問題分解到所需的粒度，然後以任何適合的形式重新組合這些碎片。上面強調的編排模式只是對這種可能性的初步探索，而隨著模型在編寫程式碼方面變得越來越擅長，這個天花板只會不斷提高。

Dynamic subagents 正是 Deep Agents 讓你在今天就能掌握這項技術的方式。現在就開始為你的 Agent 添加程式碼直譯器，或者直接使用 dcode，它內建了動態子代理功能，開箱即用。

致謝

本文由 @colifran_ 和 @huntlovell 共同撰寫。感謝 @hwchase17、@masondrxy 和 @chester_curme 的審閱與寶貴意見。