構建 AI Agent 系統的三個核心模式

你有沒有想過，為什么很多 AI agent 系統在演示時看起來很酷，但一旦投入實際使用就會遇到各種問題？上下文窗口爆滿、響應變慢、對話質量下降，這些都是真實存在的痛點。最近我讀到 Inngest 聯合創始人 Dan Farrelly 的一篇文章，他分享了一個非常有意思的觀點：每個真正能投入生產的 AI agent 系統，最終都會需要三種 sub-agent（子代理）模式。不是兩種，也不是四種，恰好是三種。這個觀點讓我深入思考了很久，因為它觸及了 AI agent 系統設計的本質問題。

Dan Farrelly 在開發通用 AI agent 系統時發現，問題的關鍵不在于你是否需要 sub-agent，而在于你如何把它們連接起來。他提出的三種模式分別是：同步執行并等待結果、異步執行后匯報、以及定時延后執行。聽起來很簡單，但這三種模式背后隱藏著對 AI agent 系統架構的深刻理解。我在研究這個話題時發現，這不僅僅是技術實現的問題，更是關于如何讓 AI agent 真正為用戶創造價值的問題。

我的新書《出海，產品全球化營銷實踐》即將出版發售，為了感謝各位一直支持深思圈的讀者，特地準備了這次贈書活動，可以在第一時間拿到免費的贈書，感興趣的朋友可以填寫以下信息。由于出版社給的數量有限，我會從填寫問卷的同學中篩選一部分贈書，可能沒有辦法保證每一位都拿到，請大家諒解。

Sub-Agent 到底解決了什么問題

在深入了解這三種模式之前，我覺得有必要先理解 sub-agent 存在的根本原因。Dan Farrelly 給出了一個非常清晰的定義：sub-agent 是由父 agent 生成的獨立 LLM 執行上下文，用于處理特定范圍的任務。父 agent 描述任務、提供工具，然后獲得結果。關鍵是，sub-agent 應該在自己的上下文窗口中運行，這樣就不會污染父 agent 的上下文。

這個設計背后的核心目的是 context compression（上下文壓縮）。Cursor 團隊在最近的 Latent Space 訪談中也提到了這一點。Sub-agent 的存在讓父 agent 永遠不需要吸收被委托任務的完整執行軌跡。想象一下，一個 sub-agent 可能讀取了 8 個文件、進行了 15 次工具調用，但父 agent 只會看到一個 750 token 的摘要。

在我看來，這才是 sub-agent 真正的價值所在。很多人以為 sub-agent 的主要作用是實現并行執行，但 Dan 在文章中明確指出，真正的投資回報率來自于上下文管理，而不是并行性。父 agent 保持精簡，就能在單次對話中處理更多任務，不會觸及上下文限制，也不會降低響應質量。Dan 在 Utah 項目的測試中發現，使用 sub-agent 后，添加到父 agent 上下文中的 token 數量減少了 90% 以上。

這個數據讓我意識到一個更深層的問題：我們在設計 AI agent 系統時，往往過度關注功能的豐富性，卻忽視了系統的可持續性。一個 agent 如果在對話進行到一半時就因為上下文窗口滿了而無法繼續工作，那么它再強大的功能也失去了意義。Sub-agent 提供了一種優雅的解決方案，讓系統能夠在保持功能豐富性的同時，維持長期對話的能力。

三種 Sub-Agent 模式的本質

Dan Farrelly 總結的三種核心模式分別是：Sync（同步模式）- "做這件事并等待"、Async（異步模式）- "去做這件事，完成后匯報"、以及 Scheduled（定時模式）- "稍后做這件事"。每個 AI agent 系統都需要這三種模式，它們各有各的用途和考量。

同步模式是最直接的。父 agent 生成一個 sub-agent 并阻塞等待，直到結果返回。Sub-agent 運行、完成工作，然后將摘要作為工具結果返回。Dan 建議在以下情況使用同步模式：父 agent 需要答案才能繼續工作。數據查詢、分析、代碼生成等需要反饋到下一步的任務，任何響應會影響接下來發生什么的情況。

我理解的同步模式本質上就像函數調用。你調用、等待、獲得返回值。雖然結果會進入父 agent 的上下文窗口，但由于它是摘要而不是完整軌跡，那 90% 以上的壓縮率意味著父 agent 可以委托很多次，上下文才會成為問題。這種設計非常聰明，它在保持控制流清晰的同時，也確保了系統的可擴展性。

異步模式則完全不同。父 agent 啟動一個 sub-agent 后立即繼續對話。Sub-agent 獨立運行，完成后直接向用戶回復。Dan 指出，這應該是你的默認選擇。適用于長時間運行的研究、報告生成、起草、分析等具有副作用但不需要返回值的任務。

父 agent 不等待。Sub-agent 是完全獨立的函數運行。完成后，它會發出一個包含響應和渠道路由信息的事件，回復會通過發起請求的任何渠道傳遞給用戶。這里的權衡是：父 agent 無法整合結果。如果你啟動三個異步 sub-agent，每個都在完全隔離中運行。這是一個特性而非缺陷，零協調開銷，免費的并行執行，但這意味著父 agent 無法在同一輪中跨它們進行綜合。

我覺得異步模式體現了一種非常現代的思維方式。傳統的軟件設計往往追求同步和可預測性，但在 AI agent 的世界里，我們需要接受一定程度的異步性和不確定性。把 sub-agent 想象成同事：你交接工作，說"完成后告訴我"，然后繼續前進。多個異步 sub-agent 可以同時運行，無需任何協調代碼。這種設計不僅提高了效率，也讓系統更加靈活和可擴展。

定時模式是大多數人會忽略的，但 Dan 認為這是最有意思的一種。父 agent 安排一個 sub-agent 在未來特定時間運行。適用于后續跟進、應該智能化的提醒、定期檢查，任何"稍后"應該意味著"在執行時使用最新數據"的情況。

這與傳統的定時任務有本質區別。"提醒我明天上午 9 點檢查部署指標"不是在上午 9 點發送通知，而是在上午 9 點運行一個 agent，實際拉取實時指標并發送分析。"周一向這個線程發送后續郵件"不是在周五編寫的定時消息，而是周一運行一個具有完整線程上下文的 sub-agent。

我認為定時模式揭示了 AI agent 與傳統自動化工具的根本差異。傳統工具執行預設的動作，而 AI agent 在執行時刻根據當前狀態做出決策。這種"延遲執行但智能決策"的能力，讓 AI agent 能夠處理那些需要時間維度考量的復雜任務。定時 sub-agent 是動態的、具有上下文意識的，在執行時使用世界的當前狀態運行。不需要異步之外的新基礎設施，它是相同的函數、相同的處理程序、相同的傳遞機制，唯一的區別是事件上的時間戳字段。

決策框架與實際應用

Dan Farrelly 提供了一個簡單但實用的決策框架：需要結果才能繼續？使用同步模式。獨立任務，不需要阻塞？使用異步模式。多個獨立任務？使用異步模式（并行）。應該在未來特定時間發生？使用定時模式。不確定？默認使用異步，它更便宜，讓父 agent 保持精簡。

讓我印象深刻的是 Dan 的一個建議：不要為模型做選擇，給它提供所有三個工具并配有清晰的描述，讓它自己正確選擇。這體現了一種信任 AI 判斷能力的態度，也反映了現代 LLM 在理解任務需求方面的成熟度。

在實現層面，Dan 的團隊采用了一個非常優雅的設計：一個函數處理三種模式。區別在于它如何被觸發以及結果去哪里。他們使用 Inngest 構建了一個可重用的函數，通過不同的觸發方式和結果路由來區分三種模式。這種統一的設計大大簡化了系統架構，降低了維護成本。

關鍵的區別在于框架指令。同步 sub-agent 被告知要簡潔（父 agent 會綜合）。異步 sub-agent 被告知要詳盡（它們是給用戶的最終答案）。定時 sub-agent 就是帶延遲觸發的異步 sub-agent，不需要特殊處理。

我特別欣賞他們為什么使用兩個工具而不是一個帶有模式參數的工具的解釋。模型在工具選擇（從列表中選擇）方面比參數優化（閱讀參數描述并正確選擇）更擅長。獨立的工具意味著更清晰的日志、更清楚的追蹤、更容易的調試。這種對細節的關注體現了經驗豐富的工程師對系統可維護性的深刻理解。

在深度控制方面，Dan 的設計也很有意思。Sub-agent 獲得相同的工作空間工具，但不能生成 sub-agent，實現了深度 1 的委托。沒有路由邏輯，沒有任務分類。模型讀取工具描述，決定何時委托有意義，并編寫自然語言任務描述。這種簡單的設計避免了復雜的遞歸問題，同時保持了系統的靈活性。

通用 Agent 為什么勝過專業化 Agent

一旦你有了這三種模式，就會有一個誘人的下一步：為每個領域構建專業化的 agent。一個郵件 agent、一個數據 agent、一個編碼 agent，每個都有自己的工具和提示詞。Dan 明確建議不要馬上跳入這個誘惑。

他的團隊內部構建過專業化 agent 系統和它們之間的自定義路由器。隨著模型的進步，這種專業化變得遠不那么重要，在大多數設置中甚至是一個繁瑣的維護層。這個觀察讓我深思，因為它挑戰了我們在軟件工程中長期以來的一個信條：專業化帶來更好的性能。

Dan 指出了幾個關鍵問題。工具重疊。通用 agent 在編碼工具或模式（如工具搜索、工具發現、技能）方面表現出色，按 agent 分離的整個工具庫有時可能不是你需要的。路由悖論。你需要某種東西來決定哪個專家處理每個請求。硬編碼路由在模糊情況下會失敗。使用 LLM 作為路由器會增加延遲和新的故障模式。如果你的路由 LLM 調用足夠智能，能夠選擇正確的 agent，它難道不能直接完成任務嗎？這看起來就像一個通用 agent 委托了一個"任務"。

"錯誤 agent"問題特別值得關注。當路由器將任務發送給錯誤的專家時，故障模式特別糟糕。錯誤的 agent 會用不完整的能力嘗試任務，可能以微妙錯誤的方式部分成功。系統會信任響應，因為它來自指定的專家。這些是奇怪的故障案例，很難處理或計劃。

評估表面爆炸也是一個實際問題。有 N 個 agent 就需要 N 個獨立的評估套件、1 個路由評估套件、O(N2) 對成對交互測試，以及端到端集成測試。單個通用 agent 只需要一個覆蓋所有能力的評估套件。

我認為這里有一個更深層的洞察：復雜性往往來自過早的優化。我們傾向于在問題還沒有充分暴露之前就試圖通過架構設計來解決它。專業化 agent 看起來是一個優雅的解決方案，但它引入的復雜性可能遠超它解決的問題。

Dan 引用了 Anthropic 的"構建有效 Agent"論文中的觀點："一致的是，最成功的實現并沒有使用復雜的框架或專業庫。相反，它們使用簡單、可組合的模式構建。"Cursor 團隊在播客中也描述了使用"基本通用的任務接口，主 agent 可以定義進入 sub-agent 的內容"。Sub-agent 首先是上下文壓縮邊界，其次才是并行性。模型在運行時定義 sub-agent，而不是開發者在構建時定義。

這讓我想起軟件工程中的一個有趣現象：微服務的爆發然后回歸到模塊化單體。開銷開始超過收益。通用 agent 也類似。從簡單開始，只在必要時專業化，這可能是更明智的策略。

什么時候專業化確實有意義

盡管如此，Dan 也承認在某些情況下專業化確實會勝出。不同的模型要求。一個任務需要視覺能力，另一個需要快速分類，路由到不同的模型。安全邊界。Agent A 訪問客戶數據，Agent B 只訪問公共數據。監管要求。某些領域需要可審計的、獨立的處理管道。經過驗證的評估驅動證據。你的評估顯示專業化 agent 在特定任務上始終優于通用 agent。

關鍵原則是：專業化應該由測量的必要性驅動，而不是架構美學。從通用開始，在有意義時再專業化。這個原則不僅適用于 AI agent 系統，也適用于幾乎所有的軟件設計。我們經常被"完美架構"的追求所誘惑，但真正的智慧在于認識到什么時候簡單就是最好的。

在我看來，這種務實的態度是構建可持續 AI agent 系統的關鍵。技術進步的速度非常快，今天看起來必要的專業化，明天可能就變得多余。保持系統的靈活性和可適應性，比追求當下的完美架構更重要。

未來的探索方向

Dan 的團隊目前使用的方法是通用的，適用于所有三種模式：同步、異步和定時。他們正在探索一些新的方向。自我迭代 agent。有了定時 sub-agent，為什么 agent 不能繼續在自己和系統上迭代？成本和預算自然會成為考慮因素。

編排感知。異步和定時 sub-agent 返回它們的事件 ID。通過 API 和上下文，系統中的任何 agent 或 sub-agent 都可以知道什么在運行、在哪里運行，獲取狀態和結果。它不再只是循環加扇出，而是變成了一個網絡。

回調和其他模式。當前的參考示例使用渠道作為工作完成時的回調機制，但具有不同類型回調的通用 sub-agent 系統會是什么樣子？例如更新 Linear 任務、在數據庫中存儲研究或報告的引用。工具可以用于此，但回調提供某種程度的保證。

這些探索方向讓我看到了 AI agent 系統演進的可能路徑。從簡單的請求-響應模式，到復雜的網絡狀協作，再到自主的持續優化。每一步都建立在堅實的基礎之上，而不是追求華而不實的創新。

我對這個話題的一些思考

讀完 Dan Farrelly 的這篇文章，我有幾點深刻的感受。AI agent 系統的設計，本質上是在管理復雜性。我們傾向于通過添加更多功能、更多專業化來解決問題，但往往忽視了簡單性的力量。三種 sub-agent 模式的價值不在于它們有多復雜，而在于它們多么清晰地映射了實際需求。

上下文管理是一個經常被低估的問題。我們看到 LLM 的上下文窗口越來越大，從 4K 到 8K 到 32K 甚至 100K，很容易認為上下文限制不再是問題。但 Dan 的實踐表明，即使有更大的上下文窗口，有效的上下文管理仍然至關重要。一個能夠在長對話中保持清晰和高效的系統，遠比一個依賴巨大上下文窗口的系統更可持續。

異步思維在 AI agent 系統中特別重要。傳統軟件往往追求同步和可預測性，但在處理復雜任務時，接受異步性實際上能帶來更好的用戶體驗。用戶不需要等待一個長時間運行的任務完成才能繼續對話，系統可以在后臺處理，完成后通知用戶。這種設計更符合人類的工作方式。

通用性與專業化的平衡是一個永恒的主題。軟件工程的歷史充滿了鐘擺式的擺動：從單體到微服務再回到模塊化單體，從通用到專業再回到通用。Dan 的建議是從通用開始，只在有明確證據時才專業化，這是一個經過實踐驗證的智慧。

最后，我覺得這篇文章最有價值的地方在于它的務實性。它不是在推銷某種理想化的架構或炫技性的技術，而是在分享真實的實踐經驗和思考。在 AI agent 這個快速發展的領域，這種腳踏實地的態度特別珍貴。

如果你正在構建 AI agent 系統，我建議你認真考慮這三種 sub-agent 模式。不要被復雜的架構誘惑，從簡單開始，讓實際需求驅動你的設計決策。保持系統的靈活性，因為這個領域變化太快，今天的最佳實踐明天可能就過時了。最重要的是，關注真正重要的事情：上下文管理、用戶體驗和系統的長期可維護性。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來