LangChain創(chuàng)始人Harrison Chase似乎是個“好斗分子”，經(jīng)常對某些觀點或現(xiàn)象發(fā)表看法甚至寫長文辯論批駁。

比如在2024年，他曾指出AutoGPT等框架的問題在于“試圖完全自主運行”，缺乏人類干預機制。主張通過LangGraph等工具實現(xiàn)“Human-in-the-loop”控制，提倡Agent應支持從結構化工作流到靈活模型的漸進式過渡。

比如對當前爆火的MCP，Chase由開始質(zhì)疑到后來肯定其價值。認可MCP在降低開發(fā)門檻和標準化工具集成方面的潛力，雖然當前存在技術局限性和成功率問題需要突破，但能夠推動AI普及并可能成為行業(yè)標準。這在仍有不少質(zhì)疑聲的情況下，顯得難能可貴。

Chase對OpenAI尤為關注，并經(jīng)常對其新動向發(fā)表看法。2023年OpenAI發(fā)布GPTs時，他肯定GPTs無代碼創(chuàng)新但反對其封閉生態(tài)，并推出開源OpenGPTs提供多模型支持和數(shù)據(jù)控制能力。他認為GPTs適合簡單應用，而復雜場景仍需LangChain等開源框架,體現(xiàn)其開放生態(tài)的技術理念。

最近OpenAI發(fā)布了名為《A Practical Guide to Building AI Agents》的指導手冊，這份短短34頁的文件被認為是當前構建AI智能體的最佳資源，引發(fā)業(yè)界贊譽，甚至被奉為“Agent圣經(jīng)”。

Harrison Chase卻批評這份Agent開發(fā)指南“具有誤導性”，認為其過于強調(diào)Agent與Workflow的二元對立，而現(xiàn)實中系統(tǒng)往往是混合體。他指責該指南脫離生產(chǎn)實際，忽視復雜需求，并過度簡化“大模型主導一切”的思路。

這個觀點，源自其在LangChain官方博客撰寫了一篇名為《How to think about agent frameworks》長文。該文深入探討了構建可靠的Agentic 系統(tǒng)所面臨的挑戰(zhàn)，核心在于確保語言模型（LLM）在每個步驟都擁有適當?shù)纳舷挛?。批判了當前Agent框架領域存在的概念混淆和缺乏精確分析的現(xiàn)象，并提出了理解和比較不同 Agent 框架的關鍵維度。

對OpenAI觀點的批判，可以算是該文的一大看點。文章認為OpenAI 的指南存在概念混淆，未能抓住構建生產(chǎn)級 Agentic 系統(tǒng)的核心挑戰(zhàn)和框架的真正價值。

構建可靠的Agentic系統(tǒng)是一個復雜的問題，核心在于有效地管理和控制傳遞給LLM的上下文。當前的Agent框架格局尚不成熟，大多數(shù)框架僅僅是Agent封裝的集合，僅僅提供了易于入門的Agent封裝，犧牲了對底層邏輯和LLM輸入的精細控制。

這篇文章對Agent框架進行了深入的思考和分析，強調(diào)了控制LLM上下文的重要性，并批評了過度依賴簡單Agent封裝集合的做法。推崇將Agentic系統(tǒng)視為工作流和agents的組合，并介紹了LangGraph作為一個提供了靈活編排能力和底層控制的框架。其觀點鮮明，分析細致，對于理解Agent框架的本質(zhì)和選擇合適的工具具有很高的參考價值。

以下是這篇文章的正文，文章較長，感興趣的小伙伴可以先收藏以后再精讀。文中已經(jīng)附帶了該文提到了所有資源鏈接，不方便上網(wǎng)的朋友，可以后臺回復 250423 獲取相關資源。

OpenAI最近發(fā)布了一份關于構建agents的指南，其中包含一些誤導性的觀點，如下所示：

聲明式與非聲明式

有些框架采用聲明式方法，要求開發(fā)者提前通過由節(jié)點（智能體）和邊（確定性或動態(tài)交接）組成的圖，明確地定義工作流中的每一個分支、循環(huán)和條件判斷。這種方法雖然在視覺上清晰明了，但隨著工作流變得更加動態(tài)和復雜，很快就會變得繁瑣且具有挑戰(zhàn)性，往往還需要開發(fā)者學習專門的特定領域語言。

相比之下，智能體軟件開發(fā)工具包（Agents SDK）采用了更靈活的代碼優(yōu)先方法。開發(fā)者可以直接使用熟悉的編程結構來表達工作流邏輯，無需提前完整地定義整個圖，從而實現(xiàn)更動態(tài)、更具適應性的智能體編排。

這個觀點最初讓我很生氣，但開始寫回應時我意識到：思考agentic框架是很復雜的事情！大概有100種不同的智能體框架，從很多不同維度去比較它們，有時候它們會被混為一談（就像在這句引用中那樣）。外界有很多炒作、故作姿態(tài)和干擾信息。關于智能體框架，目前鮮有人進行精確的分析或深入思考。我們撰寫這篇博客就是為了嘗試進行這樣的分析。我們將涵蓋以下內(nèi)容：

背景信息

• 什么是agent？
• 構建agent有什么難點？
• 什么是LangGraph？

Agentic框架的風格

• “Agents”與“工作流”
• 聲明式與非聲明式
• Agent封裝
• 多agent（Multi agent）

常見問題

• 框架的價值是什么？
• 隨著模型不斷優(yōu)化，一切是否會從工作流轉變?yōu)橹悄荏w？
• OpenAI 在其觀點中出現(xiàn)了哪些失誤？
• 所有agentic框架如何比較？

在這篇博客中，我將反復引用一些資料：

• OpenAI的構建agents指南（我認為不是特別好）：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf?ref=blog.langchain.dev
• Anthropic關于構建有效agents的指南（我非常喜歡）：https://www.anthropic.com/engineering/building-effective-agents?ref=blog.langchain.dev
• LangGraph（我們構建可靠agents的框架）：https://github.com/langchain-ai/langgraph?ref=blog.langchain.dev

背景信息

為博客的其余部分奠定基礎的有用背景信息。

 什么是agent

Agents沒有一致的定義，它們通常通過不同的視角提供。OpenAI采用更高層次、更具思想引領性的方法來定義agent。

Agents是代表您獨立完成任務的系統(tǒng)。

我個人不喜歡這個。這是一個模糊的陳述，并不能真正幫助我理解什么是agents。這只是思想領導力，根本不實用。

將此與Anthropic的定義進行比較：

“Agents”可以通過多種方式定義。一些客戶將agents定義為完全自主的系統(tǒng)，這些系統(tǒng)在較長時間內(nèi)獨立運行，使用各種工具完成復雜的任務。其他人使用該術語來描述遵循預定義工作流的更規(guī)范的實施。在Anthropic，我們將所有這些變體歸類為agentic系統(tǒng)，但在工作流和agents之間劃定了一個重要的架構區(qū)別：

工作流是通過預定義的代碼路徑編排LLM和工具的系統(tǒng)。

另一方面，agents是LLM動態(tài)指導自己的流程和工具使用，保持對他們完成任務方式的控制的系統(tǒng)。

我更喜歡Anthropic的定義，原因如下：

• 他們對agents的定義要精確得多，也要技術性得多。
• 他們還引用了“agentic systems”的概念，并將工作流和agents歸類為此系統(tǒng)的變體。我喜歡這個。

我們在生產(chǎn)中看到的幾乎所有“agentic系統(tǒng)”都是“工作流”和“agents”的組合。

在博客文章的后面，Anthropic將agents定義為“......通常只是使用基于環(huán)境反饋的工具的LLM循環(huán)。

盡管他們一開始對agents的定義很宏大，但這基本上也是OpenAI的意思。這類agent是通過以下參數(shù)進行定義的：

• 要使用的模型
• 要使用的說明（系統(tǒng)提示符）
• 要使用的工具

您可以在循環(huán)中調(diào)用模型。如果/當它決定調(diào)用一個工具時，你運行那個工具，獲得一些觀察/反饋，然后將其傳回LLM。您將一直運行，直到LLM決定不調(diào)用工具（或調(diào)用觸發(fā)停止條件的工具）。

OpenAI和Anthropic都稱工作流是與agents不同的設計模式。LLM在那里的控制較少，流程更具確定性。這是一個有用的區(qū)別！

OpenAI和Anthropic都明確指出，您并不總是需要agents。在許多情況下，工作流更簡單、更可靠、更便宜、更快、性能更高。來自Anthropic帖子的一句話：

使用LLM構建應用程序時，我們建議找到盡可能簡單的解決方案，并且僅在需要時增加復雜性。這可能意味著根本不構建agentic系統(tǒng)。agentic系統(tǒng)通常會以延遲和成本為代價來獲得更好的任務性能，您應該考慮何時進行這種權衡是有意義的。

當需要更高的復雜性時，工作流為定義明確的任務提供可預測性和一致性，而當需要大規(guī)模的靈活性和模型驅動的決策時，agents是更好的選擇。

OpenAI說了類似的話：

在承諾構建agents之前，請驗證您的使用案例是否可以清楚地滿足這些標準。否則，確定性解決方案可能就足夠了。

在實踐中，我們看到大多數(shù)“agentic系統(tǒng)”是工作流和agents的組合。這就是為什么我實際上討厭談論某物是否是agent，而更喜歡談論一個系統(tǒng)的agentic性如何。感謝偉大的吳恩達（Andrew Ng）的這種思考方式：

我認為，與其以二元方式選擇某物是否是agent，不如將系統(tǒng)視為在不同程度上類似agent會更有用。與名詞“agent”不同，形容詞“agentic”允許我們思考這樣的系統(tǒng)，并將它們?nèi)考{入這個不斷增長的運動中。

  構建agents有什么難點？

我想大多數(shù)人都會同意構建agents很困難?；蛘吒_切地說，將agents構建為原型很容易，但要可靠，可以為業(yè)務關鍵型應用程序提供支持？這很難。

棘手的部分正是使其可靠。您可以輕松地制作在Twitter上看起來不錯的演示。但是，您能否運行它來支持業(yè)務關鍵型應用程序？并非沒有大量的工作。

幾個月前，我們對agent構建者進行了一項調(diào)查，并詢問他們：“在生產(chǎn)中投入更多agents的最大限制是什么？到目前為止，排名第一的回答是“performance quality”，讓這些agents工作仍然非常困難。

是什么導致agents有時表現(xiàn)不佳？因為LLM搞砸了。

為什么LLM會搞砸？兩個原因：（a）模型不夠好；（b）錯誤（或不完整）的上下文被傳遞給模型。

根據(jù)我們的經(jīng)驗，它通常是第二種用例。這是什么原因造成的？

• 不完整或簡短的系統(tǒng)消息
• 模糊的用戶輸入
• 無法使用正確的工具
• 工具描述不佳
• 未在正確的上下文中傳遞
• 格式不正確的工具響應

構建可靠的agentic系統(tǒng)的難點是確保LLM在每個步驟都有適當?shù)纳舷挛摹＿@包括控制進入LLM的確切內(nèi)容，以及運行適當?shù)牟襟E來生成相關內(nèi)容。

在討論agentic框架時，記住這一點會很有幫助。任何使準確控制傳遞給LLM的內(nèi)容變得更加困難的框架只會妨礙您。將正確的上下文傳遞給LLM已經(jīng)夠難的了，為什么要讓自己更難呢？

什么是LangGraph

最好將LangGraph視為一個編排框架（具有聲明式和命令式API），并在其上構建了一系列Agent封裝。

LangGraph是一個用于構建agentic系統(tǒng)的事件驅動框架。兩種最常見的使用方式是：

• 基于圖形的聲明式語法
• Agent封裝（構建在較低級別的框架之上）

LangGraph還支持功能性API（functional API）以及底層的事件驅動API（event-driven API）。存在Python和Typescript變體。

Agentic系統(tǒng)可以表示為節(jié)點和邊。節(jié)點表示工作單元，而邊緣表示過渡。節(jié)點和邊只不過是普通的Python或TypeScript代碼。因此，雖然圖形的結構以聲明性方式表示，但圖形邏輯的內(nèi)部功能是正常的命令式代碼。邊緣可以是固定的，也可以是有條件的。因此，雖然圖形的結構是聲明式的，但通過圖形的路徑可以是完全動態(tài)的。

LangGraph帶有一個內(nèi)置的持久層。這將啟用容錯、短期記憶和長期記憶。

此持久層還支持“人在環(huán)”和“人在環(huán)”模式，例如中斷、批準、恢復和時間旅行。

LangGraph內(nèi)置了對流的支持：of tokens、節(jié)點更新和任意事件。

LangGraph與LangSmith無縫集成，用于調(diào)試、評估和可觀測性。

Agentic框架的風格

Agentic框架在幾個維度上有所不同。理解而不是混淆，這些維度是能夠正確比較agentic框架的關鍵。

工作流與Agents（Workflows vs Agents）

大多數(shù)框架都包含更高級別的Agent封裝。一些框架包括一些常見工作流的封裝。LangGraph是一個用于構建agentic系統(tǒng)的低級編排框架。LangGraph支持工作流、agents以及介于兩者之間的任何內(nèi)容。我們認為這至關重要。如前所述，生產(chǎn)中的大多數(shù)agentic系統(tǒng)都是工作流和agents的組合。生產(chǎn)就緒型框架需要同時支持這兩者。

讓我們記住構建可靠agents的難點：確保LLM具有正確的上下文。工作流有用的部分原因是，它們可以輕松地將正確的上下文傳遞給LLM。您可以決定數(shù)據(jù)的流動方式。

當您考慮要在“workflow”到“agent”的范圍內(nèi)構建應用程序時，需要考慮兩件事：

• 可預測性vs能動性
• 低地板，高天花板

隨著您的系統(tǒng)變得更加agents，它將變得難以預測。

有時，您希望或需要您的系統(tǒng)是可預測的，出于用戶信任、監(jiān)管或其他原因。

可靠性并不能100%與可預測性相聯(lián)系，但在實踐中，它們可能密切相關。

您希望在此曲線上的位置因您的應用而異。LangGraph可用于在此曲線上的任何位置構建應用程序，允許您移動到曲線上您想要的點。

高門檻，低上限（High floor, low ceiling）

在考慮框架時，考慮它們的floors和ceilings可能會有所幫助：

• 低地板：低地板框架對初學者友好且易于上手
• 高樓層：具有高樓層的框架意味著它具有陡峭的學習曲線，需要大量知識或專業(yè)知識才能開始有效地使用它。
• 低天花板：天花板低的框架意味著它對它可以完成的事情有限制（你很快就會超越它）。
• 高天花板：高天花板框架為高級用例提供了廣泛的功能和靈活性（它會與您一起成長？

工作流框架的上限很高，但門檻也很高，您必須自己編寫大量agent邏輯。

Agentic框架的門檻較低，但上限較也-易于上手，但對于復雜的用例來說還不夠。

LangGraph的目標是兼具低門檻（內(nèi)置Agent封裝，使其易于上手）和高上限（實現(xiàn)高級用例的低級功能）。

聲明式與非聲明式（Declarative vs non-declarative）

聲明式框架有很多好處，但也有缺點。這是程序員之間看似無休止的爭論，每個人都有自己的偏好。

當人們說非聲明式時，他們通常暗示命令式作為替代項。

大多數(shù)人會將LangGraph描述為一個聲明式框架。這只是部分正確。

首先，雖然節(jié)點和邊之間的連接是以聲明方式完成的，但實際的節(jié)點和邊只不過是Python或TypeScript函數(shù)。因此，LangGraph是聲明式和命令式的混合體。

其次，除了推薦的聲明式API之外，我們實際上還支持其他API。具體來說，我們支持功能性API和事件驅動型API。雖然我們認為聲明式API是一個有用的心智模型，但我們也認識到它并不適合所有人。

關于LangGraph的一個常見評論是它類似于Tensorflow（一種聲明式深度學習框架），而像Agents SDK這樣的框架類似于Pytorch（一種命令式深度學習框架）。

這是不正確的。像Agents SDK（以及最初的LangChain、CrewAI等）這樣的框架既不是聲明式的，也不是命令式的——它們只是封裝。它們有一個Agent封裝（一個Python類），它包含一堆運行agents的內(nèi)部邏輯。它們并不是真正的編排框架。它們只是封裝的。

 Agent封裝（Agent Abstractions）

大多數(shù)agent框架都包含agent封裝。它們通常從涉及提示、模型和工具的類開始。然后他們添加了更多參數(shù)...然后是更多......然后甚至更多。最終，您最終會得到一連串控制大量行為的參數(shù)，所有這些參數(shù)都封裝在一個類后面。如果你想查看發(fā)生了什么，或者改變邏輯，你必須進入類并修改源代碼。

這些封裝最終使理解或控制LLM所有步驟中的內(nèi)容變得非常非常困難。這很重要，擁有此控件對于構建可靠的agents至關重要（如上所述）。這就是Agent封裝的危險。

我們從痛苦的過程中學到了這一點。這是原始LangChain鏈和agents的問題。他們提供了阻礙的封裝概念。兩年前的原始封裝之一是接受模型、提示和工具的agent類。這并不是一個新概念。它當時沒有提供足夠的控制，現(xiàn)在也沒有。

需要明確的是，這些Agent封裝具有一定的價值。它使入門變得更加容易。但我認為這些Agent封裝還不足以構建可靠的agents（也許永遠）。

我們認為思考這些agent封裝的最佳方式是像Keras一樣。它們提供更高級別的封裝，以便輕松入門。但至關重要的是，要確保它們構建在較低級別的框架之上，這樣你就不會受其局限（不會因為其功能的局限性而無法進一步拓展）。

這就是我們在LangGraph上構建Agent封裝的原因。這提供了一種開始使用agents的簡單方法，但如果您需要轉義到較低級別的LangGraph，則可以輕松實現(xiàn)。

 多agent（Multi Agent）

通常，agentic系統(tǒng)不只包含一個agent，而是包含多個agents。OpenAI在他們的報告中說：

對于許多復雜的工作流，將提示和工具拆分到多個agents中可以提高性能和可擴展性。當您的agents未能遵循復雜的說明或始終選擇不正確的工具時，您可能需要進一步劃分您的系統(tǒng)并引入更多不同的agents。

多agent系統(tǒng)的關鍵部分是它們?nèi)绾瓮ㄐ?。同樣，構建agents的難點是獲得LLM的正確上下文。這些agents之間的溝通很重要。

有很多方法可以做到這一點！交接是一種方式。這是我非常喜歡的Agents SDK的Agent封裝。

但這些agents人員的最佳通信方式有時是工作流。獲取Anthropic博客文章中的所有工作流程圖，并將LLM調(diào)用替換為agents。工作流和agents的這種混合通?？商峁┳罴芽煽啃浴?/p>

同樣，agentic系統(tǒng)不僅僅是工作流，或者只是一個agent。它們可以而且通常是兩者的組合。正如Anthropic在他們的博客文章中指出的那樣：

組合和自定義這些模式

這些構建塊不是規(guī)范性的。它們是開發(fā)人員可以塑造和組合以適應不同用例的常見模式。

常見問題

在定義并探索了您應該評估框架的不同軸之后，現(xiàn)在讓我們嘗試回答一些常見問題。

框架的價值是什么？

我們經(jīng)?？吹饺藗冑|(zhì)疑他們是否需要一個框架來構建agentic系統(tǒng)。agentic框架可以提供什么價值？

Agent封裝（Agent abstractions）

框架通常很有用，因為它們包含有用的封裝，這些封裝使入門變得容易，并為工程師提供了一種通用的構建方式，從而更容易載入和維護項目。如上所述，Agent封裝也有真正的缺點。對于大多數(shù)agentic框架，這是它們提供的唯一價值。我們非常努力地確保LangGraph不會出現(xiàn)這種情況。

短期記憶（ Short term memory）

如今，大多數(shù)agenttic應用程序都涉及某種多輪次（例如聊天）組件。LangGraph提供生產(chǎn)就緒型存儲，以實現(xiàn)多輪次體驗（線程）。

長期記憶（Long term memory）

雖然還處于早期階段，但我非常看好agentic系統(tǒng)從他們的經(jīng)驗中學習（例如，在對話中記住事物）。LangGraph為跨線程內(nèi)存提供生產(chǎn)就緒存儲。

人機協(xié)同（Human-in-the-loop）

許多agentic系統(tǒng)通過一些人機協(xié)同組件變得更好。示例包括從用戶那里獲取反饋、批準工具調(diào)用或編輯工具調(diào)用參數(shù)。LangGraph提供內(nèi)置支持，以在生產(chǎn)系統(tǒng)中啟用這些工作流。

人工監(jiān)督（Human-on-the-loop）

除了允許用戶在agent運行時影響agent之外，允許用戶在事后檢查agent的軌跡，甚至返回到前面的步驟，然后從那里重新運行（有更改）也很有用。我們稱之為Human-on-the-loop，LangGraph為此提供了內(nèi)置支持。

流傳輸（Streaming）

大多數(shù)agentic應用程序需要一段時間才能運行，因此向最終用戶提供更新對于提供良好的用戶體驗至關重要。LangGraph提供內(nèi)置的Token、Graph steps和任意流的流式處理。

調(diào)試/可觀察性（Debugging/observability）

構建可靠智能體的難點在于確保向大語言模型（LLM）傳遞正確的上下文。能夠檢查agents所采取的確切步驟，以及每個步驟中的確切輸入和輸出，對于構建可靠的agents至關重要。LangGraph 能與 LangSmith 無縫集成，以實現(xiàn)一流的調(diào)試和可觀測性。

注意：人工智能可觀測性與傳統(tǒng)軟件可觀測性有所不同（這值得單獨寫一篇文章來探討）。

容錯能力（Fault tolerance）

容錯能力是傳統(tǒng)框架（如Temporal）用于構建分布式應用程序的一個關鍵組成部分。LangGraph憑借持久化工作流和可配置的重試機制，讓實現(xiàn)容錯變得更加容易。

優(yōu)化（Optimization）

有時，定義評估數(shù)據(jù)集，然后根據(jù)此自動優(yōu)化agents，有時比手動調(diào)整提示更容易。LangGraph目前不支持開箱即用，我們認為現(xiàn)在還為時過早。但我想包括這一點，因為我認為這是一個值得考慮的有趣維度，也是我們一直在關注的事情。是目前最好的框架。

所有這些價值屬性（除了Agent封裝）都為agents、工作流以及介于兩者之間的所有內(nèi)容提供了價值。

那么，您真的需要一個agentic框架嗎？

如果您的應用程序不需要所有這些功能，并且/或者您想自己構建這些功能，那么您可能不需要這些功能。其中一些（如短期記憶）并不是非常復雜。其中其他方法（如Human-on-the-loop或LLM特定的可觀察性）則更為復雜。

關于Agent封裝：我同意Anthropic在他們的帖子中所說的：

如果您確實使用框架，請確保您了解底層代碼。對引擎蓋下內(nèi)容的錯誤假設是客戶錯誤的常見來源。

隨著模型變得更好，一切都會成為agents而不是工作流嗎？

支持agents的一個常見論點（與工作流相比）是，雖然它們現(xiàn)在不起作用，但它們將來會起作用，因此您只需要簡單的工具調(diào)用agents。

我認為有很多事情可能是真的：

• 這些工具調(diào)用agents的性能將上升
• 能夠控制進入LLM的內(nèi)容（垃圾輸入、垃圾輸出）仍然非常重要
• 對于某些應用程序，此工具調(diào)用循環(huán)就足夠了
• 對于其他應用程序，工作流程將更簡單、更便宜、更快、更好
• 對于大多數(shù)應用程序，生產(chǎn)agentic系統(tǒng)將是工作流和agents的組合

我不認為OpenAI或Anthropic會爭論這些觀點中的任何一個？來自Anthropic的帖子：

使用LLM構建應用程序時，我們建議找到盡可能簡單的解決方案，并且僅在需要時增加復雜性。這可能意味著根本不構建agentic系統(tǒng)。agentic系統(tǒng)通常會以延遲和成本為代價來獲得更好的任務性能，您應該考慮何時進行這種權衡是有意義的。

來自OpenAI的帖子：

在承諾構建agents之前，請驗證您的使用案例是否可以清楚地滿足這些標準。否則，確定性解決方案可能就足夠了。

是否有應用程序需要這個簡單的工具調(diào)用循環(huán)就足夠了？我認為，只有當您對特定于您的用例的大量數(shù)據(jù)使用經(jīng)過訓練/微調(diào)/RL的模型時，這可能才是正確的。這可以通過兩種方式發(fā)生：

• 您的任務是獨一無二的。您收集了大量數(shù)據(jù)并訓練/微調(diào)/RL您自己的模型。
• 您的任務并非獨一無二。大型模型實驗室正在對代表您的任務的數(shù)據(jù)進行訓練/微調(diào)/RL。

（旁注：如果我在一個我的任務不獨特的領域建立一家垂直創(chuàng)業(yè)公司，我會非常擔心我的創(chuàng)業(yè)公司的長期生存能力）。

您的任務是獨一無二的（Your task is unique）

我敢打賭，大多數(shù)用例（當然大多數(shù)企業(yè)用例）都屬于這一類。AirBnb處理客戶支持的方式與Klarna處理客戶支持的方式不同，后者與Rakuten處理客戶支持的方式不同。這些任務中有很多微妙之處。Sierra作為客戶支持領域的領先agent公司，不是構建單個客戶支持agent，而是構建客戶支持agent平臺：

Sierra Agent SDK使開發(fā)人員能夠使用聲明式編程語言來構建強大、靈活的agents，使用可組合技能來表達過程知識

他們需要這樣做，因為每家公司的客戶支持體驗都足夠獨特，而通用agent的性能不夠。

Agent的一個示例是一個簡單的工具調(diào)用循環(huán)，使用針對特定任務訓練的模型：OpenAI的Deep Research。所以這是可以做到的，而且它可以產(chǎn)生驚人的agents。

如果您可以在特定任務上訓練SOTA模型，那么是的，您可能不需要支持任意工作流的框架，您只需使用一個簡單的工具調(diào)用循環(huán)。在這種情況下，agents將優(yōu)先于工作流。

我心中一個非常開放的問題是：有多少agent公司將擁有數(shù)據(jù)、工具或知識來為他們的任務訓練SOTA模型？此時此刻，我認為只有大型模型實驗室才能做到這一點。但這種情況會改變嗎？小型垂直初創(chuàng)公司能否為他們的任務訓練SOTA模型？我對這個問題很感興趣。如果您目前正在執(zhí)行此作，請聯(lián)系我們！

您的任務不是唯一的（Your task is not unique）

我認為有些任務足夠通用，大型模型實驗室將能夠提供足夠好的模型，以便在這些非通用任務上執(zhí)行簡單的工具調(diào)用循環(huán)。

OpenAI通過API發(fā)布了他們的計算機使用模型，該模型是在通用計算機使用數(shù)據(jù)上微調(diào)的模型，旨在在該通用任務中足夠好。（旁注：我認為它還不夠好）。

Code就是一個有趣的例子。編碼相對通用，到目前為止，編碼絕對是agents的一個突破性用例。Claude代碼和OpenAI的Codex CLI是使用這個簡單工具調(diào)用循環(huán)的編碼agents的兩個示例。我敢打賭，基本模型經(jīng)過了大量編碼數(shù)據(jù)和任務的訓練。

這篇文檔，證明Anthropic是這樣做的：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/text-editor-tool?ref=blog.langchain.dev

有趣的是——當通用模型基于這些數(shù)據(jù)進行訓練時，這些數(shù)據(jù)的具體形態(tài)有多重要呢？Ben Hylak前幾天發(fā)了一條有趣的推文，似乎引起了很多人的共鳴。

• 模型不再知道如何使用Cursor。
• 它們都針對終端進行了優(yōu)化。這就是為什么Claude 3.7和OpenAI o3在Cursor中如此糟糕，而在Cursor之外又如此令人驚嘆。

這可能表明兩件事：

• 你的任務必須與通用模型所接受的訓練任務高度相似。你的任務與通用模型的訓練任務相似度越低，通用模型適用于你的使用場景的可能性就越小。
• 用其他特定任務的數(shù)據(jù)來訓練通用模型，可能會降低其在你任務上的表現(xiàn)。我敢肯定，在訓練新模型時，使用了大量（甚至更多）與Cursor使用場景相似的數(shù)據(jù)。但如果突然涌入大量稍有不同形式的新數(shù)據(jù)，那么這些新數(shù)據(jù)的影響力就會超過其他任何類型的數(shù)據(jù)。這意味著，目前通用模型很難在眾多任務上都表現(xiàn)得極為出色。

即使是在那些更傾向于使用智能體（而非類似工作流的方式）的應用場景中，你仍然能夠從框架的某些特性中獲益，而這些特性與低級別的工作流控制并無關聯(lián)，比如短期記憶存儲、長期記憶存儲、人在回路（實時參與決策等）、人在環(huán)上（定期監(jiān)督等）、流式處理、容錯能力以及調(diào)試/可觀測性。

 OpenAI的觀點中有什么地方是錯誤的？

如果我們重新審視OpenAI的立場，我們會發(fā)現(xiàn)它以錯誤的二分法為前提，這些二分法將“agentic框架”的不同維度混為一談，以夸大其單一封裝的價值。具體來說，它將“聲明式與命令式”與“Agent封裝”以及“工作流與agents”混為一談。

最終，它錯過了構建生產(chǎn)agentic系統(tǒng)的主要挑戰(zhàn)以及框架應該提供的主要價值，即：一個可靠的編排層，使開發(fā)人員能夠明確控制到達其LLM的上下文，同時無縫處理持久性、容錯和人機交互等生產(chǎn)問題。

讓我們分析一下我認為他們觀點有爭議的具體部分：

聲明式VS非聲明式（Declarative vs non-declarative graph）

有些框架采用聲明式方法，要求開發(fā)者提前通過由節(jié)點（agents）和邊（確定性或動態(tài)交接點）組成的圖，明確地定義工作流中的每一個分支、循環(huán)和條件判斷。雖然這種方法在視覺呈現(xiàn)上較為清晰，但隨著工作流變得更加動態(tài)和復雜，它很快就會變得繁瑣且具有挑戰(zhàn)性，往往還需要開發(fā)者學習專門的特定領域語言。

相比之下，Agents SDK采用了更靈活的“代碼優(yōu)先”方法。開發(fā)者可以直接使用熟悉的編程結構來表達工作流邏輯，而無需提前完整地預定義整個圖，從而實現(xiàn)更動態(tài)、更具適應性的智能體編排。

“聲明式VS非聲明式”（Declarative vs non-declarative graph）

LangGraph不是完全聲明式的，但它足夠聲明性，所以這不是我的主要抱怨。我的主要抱怨是“非聲明式”做了很多工作并且具有誤導性。通常，當人們批評聲明式框架時，他們更喜歡一個更命令式的框架。

但Agents SDK不是一個強制性框架。這是一個封裝的概念。更合適的標題是“聲明式vs命令式”或“是否需要編排框架”或“為什么Agent封裝就是你所需要的”或“工作流與agents”，這取決于他們想要爭論的內(nèi)容（他們似乎在下面爭論了兩者）。

“隨著工作流程變得更加動態(tài)和復雜，這種方法很快就會變得繁瑣和具有挑戰(zhàn)性”

這與聲明式或非聲明式?jīng)]有任何關系。這與工作流與agents有關。您可以輕松地將Agents SDK中的agent邏輯表示為聲明式，并且該圖形與Agents SDK一樣動態(tài)和靈活。

關于工作流程與agents的點。許多工作流不需要這種級別的動態(tài)性和復雜性。OpenAI和Anthropic都承認這一點。當您可以使用工作流時，您應該使用工作流。大多數(shù)agentic系統(tǒng)是組合。是的，如果工作流確實是動態(tài)且復雜的，請使用agent。但不要對所有事情都使用agent。OpenAI在論文的前面就字面地說了這一點。

“通常需要學習專門的領域特定語言”

同樣Agents SDK不是一個命令性框架，而是一個封裝的概念。它還具有特定于域的語言（它的封裝）。我認為，在這一點上，必須學習和解決Agents SDK封裝問題比必須學習LangGraph封裝更糟糕。主要是因為構建可靠agents的難點是確保agent具有正確的上下文，而Agents SDK比LangGraph更能混淆這一點。

“更靈活”

這絕對不是真的。這與事實相反。您可以使用Agents SDK執(zhí)行的所有作，以及LangGraph執(zhí)行的所有作。Agents SDK只允許您執(zhí)行LangGraph所能執(zhí)行的作的10%。

“代碼優(yōu)先”

使用Agents SDK，您可以編寫其封裝。使用LangGraph，您可以編寫大量普通代碼。我不明白Agents SDK如何更注重代碼優(yōu)先。

“使用熟悉的編程結構”

使用Agents SDK，您必須學習一組全新的封裝。使用LangGraph，您可以編寫大量普通代碼。還有什么比這更熟悉的呢？

“實現(xiàn)更動態(tài)和適應性更強的agents編排”

同樣地這與聲明式與非聲明式無關。這與工作流與agents有關。見上一點。

 比較agentic框架

我們已經(jīng)討論了agentic框架的許多不同組件：

• 它們是靈活的編排層，還是只是一個Agent封裝？
• 如果它們是靈活的編排層，它們是聲明式的還是其他的？
• 這個框架提供了哪些功能（除了Agent封裝）？

我認為嘗試在電子表格中列出這些維度會很有趣。我試圖在這個問題上盡可能公正。

目前，它包含與Agents SDK、Google的ADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastra、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPy的比較。

在線鏈接：https://docs.google.com/spreadsheets/d/1B37VxTBuGLeTSPVWtz7UMsCdtXrqV5hCjWkbHN8tfAo/edit?ref=blog.langchain.dev&gid=0#gid=0

結論

• 構建可靠的agentic系統(tǒng)的難點是確保LLM在每個步驟都有適當?shù)纳舷挛?。這包括控制進入LLM的確切內(nèi)容，以及運行適當?shù)牟襟E來生成相關內(nèi)容。
• Agentic系統(tǒng)由工作流和agents（以及介于兩者之間的所有內(nèi)容）組成。
• 大多數(shù)agentic框架既不是聲明式也不是命令式編排框架，而只是一組Agent封裝。
• Agent封裝可以使入門變得容易，但它們通常會混淆，并且難以確保LLM在每個步驟中都有適當?shù)纳舷挛摹?/li>
• 各種形狀和大小的agentic系統(tǒng)（agents或工作流）都受益于同一組有用的功能，這些功能可以由框架提供，也可以從頭開始構建。
• 最好將LangGraph視為一個編排框架（具有聲明式和命令式API），并在其上構建了一系列Agent封裝。

參考來源：????https://blog.langchain.dev/how-to-think-about-agent-frameworks/???

本文轉載自?????王吉偉?????，作者：王吉偉?