停止構建 AI Agent！這裏有 5 個更簡單的 LLM 工作流模式，能解決 90- 的問題

大家好，我是 Tony Bai。

如果你正在開發 AI 應用，你很可能聽說過、嘗試過，甚至正在掙扎於構建一個 “AI Agent”。

我們都看過那些令人心潮澎湃的 Demo：一個 AI Agent 被賦予一個目標，然後它就能自主地規劃、調用工具、瀏覽網頁、編寫代碼，最終完成任務。於是，我們紛紛投身其中，搭建記憶系統、定義工具、編寫角色背景…… 感覺就像在創造一個真正的數字生命，充滿了力量和進步感。

但現實往往是殘酷的。正如資深 AI 教育者 Hugo Bowne-Anderson 在他那篇引爆討論的文章《Stop Building AI Agents》中描述的，他曾用 CrewAI 構建了一個 “研究小組”：三個 Agent、五個工具，紙面上完美，實踐中一塌糊塗。

這是一個 “美麗的計劃，以壯觀的方式分崩離析”。這個故事聽起來熟悉嗎？

Hugo 一針見血地指出：問題的根源，可能不是你的實現細節，而是你從一開始就選擇去構建一個 Agent。

AI Agent 的真正 “魔鬼”：失控的工作流

要理解爲什麼 Agent 如此脆弱，我們必須先弄清它的定義。一個 LLM 應用通常具備四個特性：

  1. 記憶 (Memory): 讓 LLM 記住過去的交互。

  2. 信息檢索 (Information Retrieval): 通過 RAG 等方式爲 LLM 提供上下文。

  3. 工具使用 (Tool Usage): 賦予 LLM 調用函數和 API 的能力。

  4. 工作流控制 (Workflow Control): 讓 LLM 的輸出來決定下一步使用哪個工具以及何時使用。

這第四點，正是 “Agent” 的定義，也是問題的核心！

當我們構建一個 Agent 時，我們實際上是把系統的控制權交給了 LLM。我們希望它能像一個自主的決策者一樣，動態地編排整個工作流程。

但這就像是讓一個充滿創造力、才華橫溢但情緒不定的藝術家去擔任整個交響樂團的指揮。他可能會即興發揮出驚人的樂章，但更可能的是，他會忘記看樂譜，讓整個演奏陷入混亂。

大多數 Agent 系統崩潰，不是因爲功能太少，而是因爲複雜度太高、控制權失控。

Hugo 用一張簡單的決策圖告訴我們，在絕大多數場景下，我們需要的根本不是 Agent。

那麼，如果不是 Agent，我們應該構建什麼？

你應該構建的 5 個 LLM 工作流模式

答案是：用更簡單的、由你（開發者）的代碼來控制流程的工作流模式。 下面這 5 個模式，源自 Anthropic 的研究，並由 Hugo 在實踐中驗證，足以解決 90% 的真實世界問題。

(1) 提示詞鏈 (Prompt Chaining)

💡 用例： 根據領英資料，撰寫個性化的推廣郵件。

這是一個典型的順序任務。你先用一個 LLM 調用將非結構化的個人資料文本，轉換爲結構化的數據（姓名、公司、職位），然後再用第二個 LLM 調用，基於這些結構化數據和公司背景，生成一封定製郵件。

(2) 並行化 (Parallelization)

💡 用例： 從一份簡歷中，同時提取多個部分的信息。

當你想一次性處理多個獨立的子任務時，並行化是最佳選擇。你可以定義多個並行的任務，如提取工作經歷、提取技能列表、提取教育背景，然後讓它們同時運行，最後彙總結果。

(3) 路由 (Routing)

💡 用例： 一個客戶支持工具，根據用戶問題類型分發到不同的處理流程。

路由模式就像一個智能交換機。你先用一個 LLM 或簡單的邏輯來對輸入進行分類（例如，這是 “賬單問題” 還是 “技術問題”），然後將請求“路由” 到相應的專有處理函數或工作流中。控制權一旦交出，就不再收回。

(4) 編排器 - 工作者 (Orchestrator-Worker)

💡 用例： 一個需要將任務動態分解成多步的郵件生成器。

這看起來像路由，但有一個關鍵區別：控制權始終在 “編排器” 手中。編排器（可以是 LLM 或你的代碼）負責做決策和協調，而 “工作者”（通常是具體的函數）負責執行。例如，編排器先調用 LLM 將目標公司分類爲“科技” 或“非科技”，然後選擇一個專門的 “科技郵件工作者” 或“非科技郵件工作者”來撰寫郵件，並管理整個流程的始終。

(5) 評估器 - 優化器 (Evaluator-Optimizer)

💡 用例： 優化一封營銷郵件的語氣和結構，以滿足特定標準。

當你對輸出質量有極高要求時，這個模式非常有用。一個 “生成器”LLM 先生成初始內容，然後一個“評估器”LLM 對其進行打分。如果分數不達標，“評估器” 會提供反饋，然後 “生成器” 根據反饋進行優化，如此循環，直到滿足質量要求或達到重試上限。

那麼，什麼時候才真正需要 Agent？

讀到這裏，你可能會問，Agent 是否就一無是處？並非如此。Hugo 指出，Agent 在一類特定場景中表現出色：當有一個敏銳的人類在環中（Human-in-the-Loop）時。

在這些場景中，Agent 是一個創造力的放大器，而非一個自主的工人。它適用於不穩定的、探索性的工作，而非需要穩定可靠的自動化流程。

小結：放棄對 Agent 的執念，迴歸簡單

AI Agent 的概念被過度炒作和濫用。在大多數真實世界的應用中，我們並不需要一個擁有自主意識、能動態控制一切的複雜系統。

我們需要的，是更清晰、更簡單、更可控的工作流結構。上述 5 種模式，爲我們提供了強大的武器庫。它們提醒我們軟件工程的第一原則：從簡單開始，逐步增加複雜性，並始終將控制權留在最可靠的地方——你自己的代碼裏。

所以，下一次當你準備構建下一個 LLM 應用時，請先停下來問自己：我真的需要一個 Agent 嗎？還是一個簡單的 “提示詞鏈” 或“路由器”就足夠了？

這個問題的答案，可能會爲你節省下數週甚至數月的調試時間。

資料地址：https://decodingml.substack.com/p/stop-building-ai-agents

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0ezuXX6FB5KFQJRa_2yfdA

猜你喜歡