久久亚洲精品久久爽,99久久精品国产综合,被男子脱掉内裤的美女视频,欧美18性xxxx18性欧美,亚洲国产欧美日韩在线人成

OpenAI 最近發(fā)布了一篇名為《A Practical guide to building AI agents》的指南，對于 Agent 框架、設(shè)計邏輯和編排模式等做了比較詳細的說明，算是面向產(chǎn)品和工程團隊的一份實用指南。

但 LangChain 創(chuàng)始人 Harrison Chase 對于 OpenAI 在文中的一些觀點持有異議，尤其是「通過 LLMs 來主導(dǎo) Agent」的路線，迅速發(fā)表了一篇長文回應(yīng)。

Harrison Chase 認為，并非要通過嚴格的「二元論」來區(qū)分 Agent，目前我們看到大多數(shù)的「Agentic 系統(tǒng)」都是 Workflows 和 Agents 的結(jié)合。理想的 Agent 框架應(yīng)該允許從「結(jié)構(gòu)化工作流」逐步過渡到「由模型驅(qū)動」，并在兩者之間靈活切換。

相比 OpenAI 的文章，Harrison Chase 更認同 Anthropic 此前發(fā)布的如何構(gòu)建高效 Agents 的文章，對于 Agent 的定義，Anthropic 提出了「Agentic 系統(tǒng)」的概念，并且把 Workflows 和 Agents 都看作是其不同表現(xiàn)形式。

總的來說，這是大模型派（Big Model）和工作流派（Big Workflow）的又一次爭鋒，前者認為每次模型升級都可能讓精心設(shè)計的工作流瞬間過時，這種「苦澀的教訓(xùn)」讓他們更傾向于構(gòu)建通用型、結(jié)構(gòu)最少的智能體系統(tǒng)。而以 LangGraph 為代表的后者，強調(diào)通過顯式的代碼、模塊化的工作流來構(gòu)建智能體系統(tǒng)。他們認為結(jié)構(gòu)化的流程更可控、更易調(diào)試，也更適合復(fù)雜任務(wù)。

TLDR

構(gòu)建可靠的 Agentic 系統(tǒng)，其核心難點在于確保 LLM 在每一步都能拿到恰當?shù)纳舷挛男畔?。這既包括精準控制輸入給 LLM 的具體內(nèi)容，也包括執(zhí)行正確的步驟來生成那些有用的內(nèi)容。
Agentic 系統(tǒng)包含 Workflows 和 Agents（以及介于兩者之間的一切）。
市面上大多數(shù)的 Agentic 框架，既不是聲明式也不是命令式的編排工具，而是提供了一套 Agent 封裝能力的集合。
Agent 封裝可以使入門變得更加容易，但它們常常會把底層細節(jié)隱藏起來，反而增加了確保 LLM 在每一步都能獲得恰當上下文的難度。
無論 Agentic 系統(tǒng)是大是小，是 Agents 主導(dǎo)還是 Workflows 驅(qū)動，它們都能從同一套通用的實用功能中獲益。這些功能可以由框架提供，也可以完全自己從頭搭建。
把 LangGraph 理解成一個編排框架（它同時提供了聲明式和命令式的 API），然后在它之上構(gòu)建了一系列 Agent 封裝，這樣想是最恰當?shù)摹?/p>

Founder Park 正在搭建開發(fā)者社群，邀請積極嘗試、測試新模型、新技術(shù)的開發(fā)者、創(chuàng)業(yè)者們加入，請掃碼詳細填寫你的產(chǎn)品/項目信息，通過審核后工作人員會拉你入群～

進群之后，你有機會得到：

高濃度的主流模型（如 DeepSeek 等）開發(fā)交流；
資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；
好用、有趣的產(chǎn)品/案例，F(xiàn)ounder Park 會主動做宣傳。

OpenAI 最近發(fā)布了一篇關(guān)于構(gòu)建 Agents 的指南，其中包含一些誤導(dǎo)性的觀點，比如下面這段：

聲明式 vs 非聲明式某些框架采用聲明式方式，要求開發(fā)者在工作流設(shè)計之初，就通過圖結(jié)構(gòu)明確定義所有的分支、循環(huán)與條件。圖中的結(jié)構(gòu)通常由**節(jié)點（代理）與邊（確定性或動態(tài)的任務(wù)傳遞）**組成。雖然這種方式在可視化表達上更清晰，但隨著工作流的動態(tài)性和復(fù)雜度不斷增加，聲明式方法容易變得繁瑣，并且常常需要學(xué)習專門的領(lǐng)域特定語言，增加了開發(fā)門檻。相較之下，Agents SDK 提供了一種更為靈活的代碼優(yōu)先方案。開發(fā)者可以通過熟悉的編程結(jié)構(gòu)直接表達工作流邏輯，無需提前預(yù)定義整個圖結(jié)構(gòu)，從而實現(xiàn)更加動態(tài)、可擴展的代理編排能力。

看到這段話，我最初是有點火大的。但寫著寫著我就明白了：認真思考 Agent 框架這件事本身就很復(fù)雜！市面上大概有上百種 Agent 框架，衡量它們的維度太多了，而且有時候這些維度還會被混在一起（就像這段引用里那樣）。這里面充斥著大量的炒作、故作姿態(tài)和噪音。關(guān)于 Agent 框架，真正精確的分析和思考反而很少見。所以，這篇博客就是我們在這方面做的一次嘗試。

在接下來的文章內(nèi)容里，我參考了以下幾份資料：

OpenAI 的構(gòu)建 Agents 指南（說實話，我覺得寫得不太行）：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
Anthropic 的構(gòu)建高效 Agents 指南（這篇我非常喜歡）：https://www.anthropic.com/engineering/building-effective-agents?ref=blog.langchain.dev
LangGraph（這是我們自己用來構(gòu)建可靠 Agents 的框架）：https://www.langchain.com/langgraph

01什么是 Agent構(gòu)建難點在哪里？

這部分會提供一些基礎(chǔ)信息，幫助大家更好地理解后續(xù)內(nèi)容。

什么是 Agent

目前，Agent 沒有一個統(tǒng)一的或大家公認的定義，不同的人常常從不同的角度來定義它。

OpenAI 更傾向于從一個比較高屋建瓴、偏思想引領(lǐng)的角度來定義 Agent。

Agents 是那些能代表你獨立完成任務(wù)的系統(tǒng)。

說實話，我個人不太喜歡這個說法。這太籠統(tǒng)了，并不能幫我真正搞清楚 Agent 到底是個什么東西。這種說法太務(wù)虛，一點都不實用。

對比一下 Anthropic 的定義：

「Agent」可以有幾種不同的定義。有些客戶把 Agent 看作是完全自主的系統(tǒng)，能長時間獨立運行，用各種工具完成復(fù)雜的任務(wù)。另一些客戶則用這個詞來指代那些更遵循既定規(guī)則的實現(xiàn)，它們按照預(yù)設(shè)的 Workflows 來走。在 Anthropic，我們把所有這些變體都歸類為 Agentic 系統(tǒng)，但在架構(gòu)上，我們明確區(qū)分 Workflows 和 Agents： Workflows 是通過預(yù)先寫好的代碼路徑來協(xié)調(diào) LLMs 和工具工作的系統(tǒng)。而 Agents 則是由 LLMs 自己動態(tài)地決定流程和工具使用，它們掌控著任務(wù)完成的方式。

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

他們對 Agent 的定義要精確得多，也更技術(shù)化。

他們提到了「Agentic 系統(tǒng)」這個概念，并且把 Workflows 和 Agents 都看作是它的不同表現(xiàn)形式。這一點我非常贊同。

我們在實際生產(chǎn)環(huán)境中看到的「Agentic 系統(tǒng)」，幾乎都是「Workflows」和「Agents」的混合體。

Anthropic 博客文章的后半部分給 Agents 的定義是，「… 通常只是 LLMs 在一個循環(huán)里基于環(huán)境反饋來使用工具?！?/p>

盡管 OpenAI 開頭給 Agent 下了一個非常宏大的定義，但他們實際所指，基本上和 Anthropic 這個說法差不多。

這類 Agent 的配置項（參數(shù)）主要包括：

要使用的模型
要遵循的指令（System Prompt）
可以使用的工具

你的程序會在一個循環(huán)里調(diào)用模型。如果/當模型決定要調(diào)用某個工具時，你就運行那個工具，得到一些觀察結(jié)果或反饋，然后把這些信息再傳回給 LLM。這個過程會一直持續(xù)，直到 LLM 自己決定不再調(diào)用工具（或者它調(diào)用的某個工具觸發(fā)了停止條件）。

OpenAI 和 Anthropic 都明確指出，Workflows 是一種與 Agents 不同的設(shè)計模式。在 Workflows 里，LLM 的控制權(quán)相對較弱，流程更傾向于確定性，這是一個非常有用的區(qū)分點。

OpenAI 和 Anthropic 都明確提到，用戶/客戶并非總是需要 Agents。在很多情況下，Workflows 更簡單、更可靠、成本更低、速度更快，而且性能更好。這里引用自自 Anthropic 的文章：

在使用 LLMs 構(gòu)建應(yīng)用時，我們建議先從最簡單的方案入手，只在確實需要時才增加復(fù)雜性。這可能意味著你根本不需要構(gòu)建 Agentic 系統(tǒng)。Agentic 系統(tǒng)通常會犧牲一些延遲和成本，來換取更好的任務(wù)表現(xiàn)，你應(yīng)該仔細權(quán)衡這種取舍是否劃算。當確實需要更高復(fù)雜度時，Workflows 在處理界定清晰的任務(wù)時，能提供更好的可預(yù)測性和一致性；而當需要在規(guī)?；瘓鼍跋聦崿F(xiàn)靈活性和模型驅(qū)動的決策時，Agents 則是更好的選擇。

OpenAI 的說法也差不多：

在你決定投入精力構(gòu)建 Agent 之前，請先確認你的用例是否明確符合這些標準。否則，用確定性方案可能就足夠了。

實際情況是，我們看到大多數(shù)的「Agentic 系統(tǒng)」都是 Workflows 和 Agents 的結(jié)合。這也就是為什么我們不太喜歡糾結(jié)于某個東西「是不是」一個 Agent，而更傾向于討論一個系統(tǒng)「有多 Agentic」。這里特別感謝 Andrew Ng 提供了這種思考方式：

與其簡單以二元的方式去判斷某個東西是不是 Agent，我覺得更有意義的是去思考一個系統(tǒng)「在多大程度上像 Agent」。「Agentic」這個形容詞，不像「Agent」這個名詞那樣非黑即白，它允許我們?nèi)徱曀羞@類系統(tǒng)，并將它們都包含在這個不斷發(fā)展的領(lǐng)域中。

構(gòu)建 Agents 的難點在哪里？

我想大多數(shù)人都會認同，構(gòu)建 Agents 是件難事，更準確地說構(gòu)建一個 Agents 的原型很容易，但要搭一個可靠的、能支撐公司關(guān)鍵業(yè)務(wù)的應(yīng)用才是難點。

最麻煩的部分在于讓 Agents 應(yīng)用「使其可靠」。目前，很容易就能做出一個在 Twitter 上看起來不錯的 demo。但要讓 Agents 去驅(qū)動一個對業(yè)務(wù)至關(guān)重要的應(yīng)用，沒有大量工作是做不到的。

幾個月前，我們對 Agent 開發(fā)者們做了一項調(diào)查，問他們：「在將更多 Agents 投入生產(chǎn)時，你們遇到的最大障礙是什么？」毫無疑問，排名第一的回答是「performance quality」。讓 Agents 穩(wěn)定可靠地工作，依然是個巨大的挑戰(zhàn)。

那是什么原因?qū)е?Agents 有時候表現(xiàn)不佳呢？是因為背后的 LLM 出錯。

為什么 LLM 會出錯？主要有兩個原因：

一是模型本身能力還不夠；

二是傳遞給模型的上下文信息不對或者不完整。

根據(jù)我們的經(jīng)驗，第二種情況非常常見。那又是什么導(dǎo)致上下文信息傳遞出問題呢？

System Message 不完整或?qū)懙锰?/p>
用戶的輸入太模糊
沒有給 LLM 提供正確的工具
工具的描述寫得不好
沒有傳入恰當?shù)纳舷挛男畔?/p>
工具返回的響應(yīng)格式不對

要構(gòu)建一套可靠的 Agentic 系統(tǒng)，真正的挑戰(zhàn)在于如何確保 LLM 在每一步都能拿到最合適的上下文信息。這包含了兩方面：一是精準控制到底把哪些具體內(nèi)容喂給 LLM，二是執(zhí)行正確的步驟來生成那些有用的內(nèi)容。

在我們討論 Agent 框架的時候，記住這一點非常有幫助。任何讓我們難以精確控制到底把什么傳給 LLM 的框架，都只會礙事。把正確的上下文傳給 LLM 本身就已經(jīng)夠難了，為什么還要讓我們更難呢？

那，什么是 LangGraph？

可以將 LangGraph 理解成一個編排框架（它同時提供了聲明式和命令式的 API），然后在它之上構(gòu)建了一系列 Agent 封裝。

LangGraph 是一個由事件驅(qū)動的框架，專門用來構(gòu)建 Agentic 系統(tǒng)。使用 LangGraph 最常見的方式主要有兩種：

一種是通過聲明式的、基于圖（Graph）的語法
另一種是利用構(gòu)建在底層框架之上的 Agent 封裝

此外，LangGraph 還支持函數(shù)式 API 以及底層的事件驅(qū)動 API，并提供了 Python 和 Typescript 兩個版本。

Agentic 系統(tǒng)可以用節(jié)點（nodes）和邊（edges）來表示。節(jié)點代表一個工作單元，而邊則表示流程的轉(zhuǎn)換。節(jié)點和邊本身就是普通的 Python 或 TypeScript 代碼，所以雖然圖的結(jié)構(gòu)是用聲明式的方式來表示的，但圖內(nèi)部的邏輯運行起來是完全正常的命令式代碼。邊可以是固定的，也可以是條件式的。因此，圖的整體結(jié)構(gòu)是聲明式的，但實際運行時的路徑則可以完全動態(tài)。

LangGraph 內(nèi)置了一個持久化層，這使得其具備容錯能力、短期記憶以及長期記憶。

這個持久化層還支持「人工參與決策」（human-in-the-loop）和「人工監(jiān)督流程」（human-on-the-loop）的模式，比如中斷、批準、恢復(fù)以及時間回溯（time travel）等功能。

LangGraph 內(nèi)建支持多種流式傳輸，包括 tokens 的流式輸出、節(jié)點狀態(tài)的更新和任意事件的流式推送。同時，LangGraph 可以與 LangSmith 無縫集成，方便進行調(diào)試、評估和可觀測性分析。

Agentic 框架都有哪些類型？

Workflows vs Agents

大多數(shù)框架都提供了一些更高級別的 Agent 封裝，有些框架也會為常見的 Workflows 提供一些封裝。LangGraph 是一個用于構(gòu)建 Agentic 系統(tǒng)的低層編排框架。它支持 Workflows、Agents，以及介于兩者之間的任何形態(tài)。我們認為這一點至關(guān)重要。正如前面提到的，生產(chǎn)環(huán)境中大多數(shù)的 Agentic 系統(tǒng)都是 Workflows 和 Agents 的組合。一個成熟的生產(chǎn)級框架必須同時支持這兩種模式。

我們回想一下構(gòu)建可靠 Agents 的難點，即要確保 LLM 拿到正確的上下文。Workflows 之所以有用，部分原因就在于它們能夠?qū)⒄_的上下文傳遞給給 LLMs ，可以精確地決定數(shù)據(jù)如何流動。

當考慮要在「workflow」到「agent」的范圍內(nèi)構(gòu)建應(yīng)用程序時，需要考慮兩件事：

可預(yù)測性（Predictability） vs 自主性（agency）
低門檻（low floor），高上限（high ceiling）

可預(yù)測性（Predictability） vs 自主性（agency）

當系統(tǒng)越偏向 Agentic，其可預(yù)測性就會越低。有時候，你希望或需要你的系統(tǒng)具有可預(yù)測性，這可能是出于用戶信任、合規(guī)要求或其他原因?？煽啃圆⒉坏韧诳深A(yù)測性，但在實踐中，它們可能密切相關(guān)。

你希望你的應(yīng)用在這個曲線上處于什么位置，這非常取決于具體的應(yīng)用場景。LangGraph 可以用來構(gòu)建處于這個曲線任何位置的應(yīng)用，允許你自由地將系統(tǒng)調(diào)整到你想要的狀態(tài)。

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

在思考框架時，考慮它們的「門檻」和「上限」是很有幫助的：

低門檻（Low floor）：一個低門檻的框架對新手友好，容易上手。
高門檻（High floor）：一個高門檻的框架意味著學(xué)習曲線陡峭，需要大量的知識或?qū)I(yè)經(jīng)驗才能有效使用。
低上限（Low ceiling）：一個低上限的框架意味著它的能力有限，你能用它完成的事情不多（很快就會覺得不夠用）。
高上限（High ceiling）：一個高上限的框架提供了廣泛的能力和靈活性，能支持高級用例（它能和你一起成長）。

Workflow 框架提供了高上限，但門檻也高，但需要自己編寫很多 Agent 的邏輯。

Agent 框架則是低門檻，但上限也低——雖然容易上手，但不足以應(yīng)對復(fù)雜的用例。

LangGraph 的目標是兼具低門檻（提供內(nèi)置的 Agent 封裝，方便快速啟動）和高上限（提供低層功能，支持實現(xiàn)高級用例）。

Declarative vs non-declarative（聲明式與命令式）

聲明式框架有其優(yōu)勢，也有劣勢。這是程序員之間一個似乎永無止境的爭論，每個人都有自己的偏好。

當人們說「非聲明式」時，通常隱含的意思是它的替代方案是命令式（imperative）。

大多數(shù)人可能會把 LangGraph 描述成一個聲明式框架。但這只說對了一部分。

首先，雖然節(jié)點和邊之間的連接是通過聲明式方式定義的，但實際的節(jié)點和邊本身不過是 Python 或 TypeScript 函數(shù)。所以，LangGraph 其實是聲明式和命令式的一種混合。

其次，除了我們推薦的聲明式 API，我們實際上還支持其他 API。具體來說，我們支持函數(shù)式 API 和事件驅(qū)動 API。雖然我們認為聲明式 API 是一個很有用的思考模型，但我們也認識到它并非適用于所有人。

人們對 LangGraph 的一個常見評價是，它就像 Tensorflow（一個聲明式深度學(xué)習框架），而像 Agents SDK 這樣的框架則像 Pytorch（一個命令式深度學(xué)習框架）。

這個說法是完全錯誤的。像 Agents SDK（以及早期的 LangChain， CrewAI 等）這樣的框架，既不是聲明式的也不是命令式的，它們只是封裝。它們提供一個 Agent 封裝（一個 Python 類），這個類里面封裝了很多用于運行 Agent 的內(nèi)部邏輯。它們算不上真正的編排框架，僅僅是一種封裝。

Agent 封裝（Abstractions）

大多數(shù) Agent 框架都包含 Agent 封裝。它們通常開始時是一個類，里面包含了 prompt、model 和 tools。然后陸續(xù)增加一些參數(shù)，最后，你就會看到一大堆參數(shù)，它們控制著多種多樣的行為，所有這些都封裝在一個類后面。如果你想看看里面到底發(fā)生了什么，或者想修改邏輯，就得深入到這個類里去改源代碼。

這些封裝最終會讓你非常非常難以理解或控制到底在每一步傳遞給 LLM 的具體內(nèi)容是什么。這一點非常重要，擁有這種控制能力對于構(gòu)建可靠的 Agents 至關(guān)重要（正如前面討論的那樣）。這就是 Agent 封裝的危險之處。

我們是吃過虧才學(xué)到的這一點。這正是早期 LangChain 中 chains 和 agents 的問題所在。它們提供的封裝反而成了障礙。兩年前的那些早期封裝中，有一個 Agent 類就接收 model、prompt 和 tools。這個概念并不新鮮，但當時它沒有提供足夠的控制權(quán)，現(xiàn)在也一樣。

需要明確的是，這些 Agent 封裝確實有其價值。它們讓入門變得更容易。但我認為這些 Agent 封裝還不足以構(gòu)建可靠的 Agents（也許永遠都不能）。

我們認為，看待這些 Agent 封裝最好的方式，就像看待 Keras 一樣。它們提供了更高層的封裝，能夠讓使用者更容易上手。但關(guān)鍵在于，要確保它們是構(gòu)建在更低層框架之上的，這樣你才不會很快就遇到瓶頸，被它限制住。

這也就是為什么我們在 LangGraph 之上構(gòu)建了 Agent 封裝。它提供了一個輕松上手 Agents 的方式，但當你需要時，可以隨時「轉(zhuǎn)換」到更底層的 LangGraph 功能。

Multi Agent

通常情況下，Agentic 系統(tǒng)不會只包含一個 Agent，而是會包含多個。OpenAI 在他們的報告中提到：

對于許多復(fù)雜的 Workflows 來說，將提示和工具分散到多個 Agents 中有助于提高性能和可擴展性。當你的 Agents 未能遵循復(fù)雜的指令或持續(xù)選擇錯誤的工具時，你可能需要進一步拆分系統(tǒng)，引入更多分工明確的 Agents。

多 Agent 系統(tǒng)的關(guān)鍵在于它們?nèi)绾瓮ㄐ?。同樣，?gòu)建 Agents 的難點也在于把正確的上下文信息傳遞給 LLMs。Agents 之間的通信因此非常重要。

有很多種方法可以實現(xiàn)這一點?！窰andoffs」（交接）就是其中一種方式，這是 Agents SDK 中的一個 Agent 封裝，我個人還挺喜歡的。

但有時候，這些 Agents 之間最好的通訊方式是 Workflows。想象一下 Anthropic 博客文章里的那些 Workflow 圖示，把里面的 LLM 調(diào)用替換成 Agents。這種 Workflows 和 Agents 的混合模式，往往能帶來最好的可靠性。

同樣，Agentic 系統(tǒng)不僅僅是 Workflows，也不僅僅是 Agent。它們是兩者的結(jié)合。正如 Anthropic 在他們的博客文章中指出的那樣：

組合和定制這些模式這些構(gòu)建模塊并非一成不變的指令。它們是開發(fā)者可以根據(jù)不同的用例進行調(diào)整和組合的常見模式。

Agent 框架到底有什么價值？

在定義并探討了評估框架時應(yīng)關(guān)注的不同維度后，現(xiàn)在讓我們來解答一些常見問題。

我們經(jīng)常看到有人質(zhì)疑構(gòu)建 Agentic 系統(tǒng)是否需要框架。那么，Agent 框架到底能提供哪些價值呢？

框架的通用價值在于它們提供了一些實用的封裝，這些封裝讓上手變得容易，并為工程師提供了一種統(tǒng)一的構(gòu)建方式，從而方便新人加入和項目維護。正如上面提到的，Agent 封裝也有明顯的缺點。對大多數(shù) Agent 框架而言，這幾乎是它們提供的唯一價值。我們努力確保 LangGraph 不會出現(xiàn)這種情況。

Short term memory短期記憶

如今大多數(shù) Agentic 應(yīng)用都包含某種多輪對話（比如聊天）組件。LangGraph 提供了生產(chǎn)級別的存儲能力，支持實現(xiàn)多輪對話體驗（Threads）。

Long term memory長期記憶

雖然還在早期階段，但我非?？春?Agentic 系統(tǒng)從自身經(jīng)驗中學(xué)習的能力（比如跨對話記憶信息）。LangGraph 為跨 Thread 的長期記憶提供了生產(chǎn)級別的存儲支持。

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

很多 Agentic 系統(tǒng)通過引入一些 Human-in-the-loop 組件會變得更好。例如，從用戶那里獲取反饋、批準某個工具調(diào)用，或者修改工具調(diào)用的參數(shù)。LangGraph 內(nèi)置支持在生產(chǎn)系統(tǒng)中實現(xiàn)這些 Workflows。

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

除了允許用戶在 Agent 運行時參與之外，允許用戶在 Agent 運行結(jié)束后檢查它的運行軌跡，甚至可以回到之前的步驟，然后從那里（做些修改后）重新運行也很重要。我們稱之為 Human-on-the-loop，LangGraph 內(nèi)置提供了相關(guān)支持。

Streaming 流傳輸

大多數(shù) Agentic 應(yīng)用運行需要一些時間，因此向最終用戶提供實時更新對于提供良好的用戶體驗來講至關(guān)重要。LangGraph 內(nèi)置支持 tokens、圖的步驟以及任意流的流式傳輸。

Debugging/observability調(diào)試/可觀測性

構(gòu)建可靠 Agents 的難點在于確保向 LLM 傳遞了正確的上下文，能夠檢查 Agent 執(zhí)行的每一個精確步驟，以及每一步的精確輸入/輸出，這對于構(gòu)建可靠的 Agents 至關(guān)重要。LangGraph 與 LangSmith 無縫集成，能夠提供一流的調(diào)試和可觀測性能力。注意：AI 的可觀測性與傳統(tǒng)軟件的可觀測性不同（這值得專門寫一篇文章討論）。

Fault tolerance 容錯

容錯是構(gòu)建分布式應(yīng)用的傳統(tǒng)框架（如 Temporal）的關(guān)鍵組成部分。LangGraph 通過持久化 Workflow 和可配置的重試機制，使容錯變得更容易。

Optimization 優(yōu)化

與其手動調(diào)整 Prompt，有時候定義一個評估數(shù)據(jù)集，然后基于數(shù)據(jù)集自動優(yōu)化 Agent 可能更容易。LangGraph 目前沒有「開箱即用」地支持這一點，我們認為現(xiàn)在還為時尚早。但我想提到這一點，因為它是一個值得考慮的有趣維度，也是我們一直在關(guān)注的方向。DSPY 是目前在這個領(lǐng)域做得最好的框架。

所有這些價值主張（除了 Agent 封裝之外），對于 Agents、Workflows 以及介于兩者之間的任何形態(tài)都提供了價值。

那么，你真的需要一個 Agentic 框架嗎？

如果你的應(yīng)用不需要所有這些功能，并且/或者你愿意自己去構(gòu)建它們，那么你可能就不需要框架。其中一些功能（比如 Short term memory）并不是特別復(fù)雜。但另一些功能（比如 Human-on-the-loop，或 LLM 特定的可觀測性）則更為復(fù)雜。

關(guān)于 Agent 封裝，我認同 Anthropic 在他們文章中的說法：

如果你確實使用了框架，請確保你理解其底層的代碼。對底層機制的錯誤假設(shè)是導(dǎo)致客戶錯誤的一個常見原因。

LLMs 越來越厲害

都會變成 Agents 而不是 Workflows？

關(guān)于 Agents（相較于 Workflows）的一個常見論點是：雖然它們現(xiàn)在可能還不夠好用，但將來會變得更好，到那時，你只需要那些簡單的、能夠調(diào)用工具的 Agents 就夠了。

我認為以下幾點可能都是事實：

這些能夠調(diào)用工具的 Agents 的性能繼續(xù)提升
能夠控制輸入給 LLM 的內(nèi)容依然會非常重要（垃圾進，垃圾出）
對于一些應(yīng)用來說，簡單的工具調(diào)用循環(huán)可能就足夠了
對于另一些應(yīng)用來說，Workflows 就是更簡單、更便宜、更快、也更好的
對于大多數(shù)應(yīng)用來說，生產(chǎn)環(huán)境中的 Agentic 系統(tǒng)將是 Workflows 和 Agents 的結(jié)合。

我不認為 OpenAI 或 Anthropic 會反對以上任何一點，來看 Anthropic 文章中的說法：

在使用 LLMs 構(gòu)建應(yīng)用時，我們建議先從最簡單的方案入手，只在確實需要時才增加復(fù)雜性。這可能意味著你根本不需要構(gòu)建 Agentic 系統(tǒng)。Agentic 系統(tǒng)通常會犧牲一些延遲和成本，來換取更好的任務(wù)表現(xiàn)，你應(yīng)該仔細權(quán)衡這種取舍是否劃算。

以及 OpenAI 文章中的說法：

在你決定投入精力構(gòu)建 Agent 之前，請先確認你的用例是否明確符合這些標準。否則，確定性方案可能就足夠了。

是否一類應(yīng)用，簡單的工具調(diào)用循環(huán)就足夠了呢？我認為，這可能只在你使用的是一個針對你的特定用例、用大量數(shù)據(jù)訓(xùn)練/微調(diào)/通過強化學(xué)習優(yōu)化的模型時，才有可能實現(xiàn)。這種情況可以通過兩種方式發(fā)生：

你的任務(wù)是獨一無二的。你收集大量數(shù)據(jù)，并自己訓(xùn)練/微調(diào)/通過強化學(xué)習優(yōu)化模型。
你的任務(wù)并非獨一無二。大型模型實驗室正在用代表你的任務(wù)的數(shù)據(jù)進行訓(xùn)練/微調(diào)/通過強化學(xué)習優(yōu)化。

（題外話：如果我正在一個垂直領(lǐng)域創(chuàng)業(yè)，而我的任務(wù)并非獨一無二，我會非常擔心我公司的長期生存能力。)

你的任務(wù)是獨一無二

我敢打賭，大多數(shù)用例（尤其是大多數(shù)企業(yè)級用例）都屬于這一類。AirBnb 處理客戶支持的方式，與 Klarna 處理客戶支持的方式不同，也與 Rakuten 處理客戶支持的方式不同。這些任務(wù)中存在大量的微妙之處。一家在客戶支持領(lǐng)域領(lǐng)先的 Agent 公司「Sierra」，他們構(gòu)建的不是一個單一的客戶支持 Agent，而是一個客戶支持 Agent 平臺：

Sierra Agent SDK 讓開發(fā)者能夠使用一種聲明式的編程語言，通過可組合的技能來表達流程性知識，從而構(gòu)建強大靈活的 Agents。

他們之所以需要這樣做，是因為每家公司的客戶支持體驗都足夠獨特，以至于一個通用 Agent 無法達到所需的性能。

舉一個使用針對特定任務(wù)訓(xùn)練的模型、采用簡單工具調(diào)用循環(huán)的 Agent 的例子：OpenAI 的 Deep Research。所以這是可以做到的，并且可以做出令人驚嘆的 Agents。

如果你能針對你的特定任務(wù)訓(xùn)練一個 SOTA 模型，那么是的，你可能確實不需要一個支持任意 Workflow 的框架，你只需要一個簡單的工具調(diào)用循環(huán)就夠了。在這種情況下，Agents 將優(yōu)于 Workflows。

在我看來，一個非常開放的問題是：有多少 Agent 公司擁有數(shù)據(jù)、工具或知識來為他們的任務(wù)訓(xùn)練一個 SOTA 模型？目前，我認為只有大型模型實驗室能夠做到這一點。但這種情況會改變嗎？一家小的垂直創(chuàng)業(yè)公司能否為其任務(wù)訓(xùn)練一個 SOTA 模型？我對這個問題非常感興趣。如果你目前正在做這件事，請務(wù)必聯(lián)系我們。

你的任務(wù)并非獨一無二

我認為有些任務(wù)足夠通用，以至于大型模型實驗室能夠提供足夠好的模型，來處理這些非通用任務(wù)中的簡單工具調(diào)用循環(huán)。

OpenAI 通過 API 發(fā)布了他們的 Computer Use 模型，這是一個針對通用計算機使用數(shù)據(jù)微調(diào)的模型，目標是讓它在那個通用任務(wù)上表現(xiàn)足夠好。（題外話：我認為它離足夠好還差得遠）。

Code 是一個有趣的例子。編程相對來說比較通用，而且代碼無疑是 Agent 迄今為止一個突出的用例。Claude code 和 OpenAI 的 Codex CLI 是兩個代碼 Agents 的例子，它們都使用了簡單的工具調(diào)用循環(huán)。我強烈認為，基礎(chǔ)模型在訓(xùn)練時使用了大量的編程數(shù)據(jù)和任務(wù)。

（Anthropic 的官網(wǎng)文檔中證明了他們是這樣做：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/text-editor-tool?ref=blog.langchain.dev）。

有趣的是，當通用模型用這些數(shù)據(jù)訓(xùn)練時，這些數(shù)據(jù)的確切形態(tài)有多重要？Ben Hylak 前幾天發(fā)了一條很有意思的推文，似乎引起了很多人的共鳴：

模型現(xiàn)在不知道怎么用 Cursor 了。它們都被優(yōu)化去適配終端了。這就是為什么 3.7 和 o3 在 Cursor 里表現(xiàn)糟糕，但在外面又很厲害的原因。

這可能暗示著兩件事：

你的任務(wù)必須非常非常接近通用模型訓(xùn)練時使用的任務(wù)。你的任務(wù)與訓(xùn)練任務(wù)相似度越低，通用模型對你的用例來說可能就越不夠好。

用其他特定任務(wù)的數(shù)據(jù)來訓(xùn)練通用模型，可能會降低它在你任務(wù)上的性能。我相信，與 Cursor 用例相似的數(shù)據(jù)，用于訓(xùn)練新模型的量即使不多，也和終端數(shù)據(jù)一樣多。但如果新加入的這些數(shù)據(jù)形態(tài)稍微有點不同，它就會壓倒其他類型的數(shù)據(jù)。這意味著目前通用模型很難在大量任務(wù)上都表現(xiàn)得非常出色。

即使對于那些 Agents 比類似 Workflow 的方案更受青睞的應(yīng)用來說，你仍然會從框架中那些與低層 Workflow 控制無關(guān)的功能中受益：比如 Short term memory 存儲、Long term memory 存儲、Human-in-the-loop、Human-on-the-loop、Streaming、Fault tolerance、Debugging/observability。

OpenAI 的觀點哪里不對？

如果我們回顧一下 OpenAI 的觀點，會發(fā)現(xiàn)它建立在一些錯誤的二分法之上，混淆了「Agentic 框架」的不同維度，從而夸大了他們單一封裝的價值。具體來說，它混淆了「聲明式 vs 命令式」與「Agent 封裝」，以及「Workflows vs Agents」。

歸根結(jié)底，它沒有抓住構(gòu)建生產(chǎn)級 Agentic 系統(tǒng)的主要挑戰(zhàn)，也沒有認清框架應(yīng)該提供的核心價值，即一個可靠的編排層，它能讓開發(fā)者明確控制 LLMs 接收到的上下文信息，同時無縫處理持久化、容錯、Human-in-the-loop 交互等生產(chǎn)環(huán)境的關(guān)鍵問題。

讓我們逐條分析他們觀點中我認為有問題的地方：

「聲明式 vs 非聲明式」

LangGraph并不是完全聲明式的——但它足夠聲明式，所以這并不是我主要想吐槽的點。我主要想吐槽的是，「非聲明式」這個說法用得太隨意了，而且容易誤導(dǎo)。通常大家批評聲明式框架時，更偏愛命令式框架。但 Agents SDK 并非命令式框架，它是一種封裝的概念。一個更恰當?shù)臉祟}應(yīng)該是「聲明式 vs 命令式」、「你需要一個編排框架嗎」、「為什么你只需要 Agent 封裝」或者「Workflows vs Agents」，這取決于他們真正想論證什么（他們似乎想在下面同時論證這些）。

「隨著 Workflows 變得越來越動態(tài)和復(fù)雜，這種方法會迅速變得笨拙和具有挑戰(zhàn)性」。

這跟聲明式還是非聲明式一點關(guān)系都沒有，它完全是關(guān)于 Workflows vs Agents 的問題。你完全可以用聲明式的圖來表達 Agents SDK 中的 Agent 邏輯，而且這個圖的動態(tài)性和靈活性，和 Agents SDK 本身是一樣的。

再說到 Workflows vs Agents。很多 Workflows 并不需要更高程度的動態(tài)性和復(fù)雜性。OpenAI 和 Anthropic 也都認同這一點。能用 Workflows 的時候就應(yīng)該用 Workflows。大多數(shù) Agentic 系統(tǒng)都是兩者的結(jié)合。是的，如果一個 Workflow 真的非常動態(tài)和復(fù)雜，那就用 Agent。但不要什么都用 Agent。OpenAI 自己在這篇文章前面就說過這一點。

「通常需要學(xué)習專門的領(lǐng)域特定語言」

同樣，Agents SDK 不是一個命令式框架，它是一種封裝的概念。Agents SDK 有自己的領(lǐng)域特定語言（就是它的封裝）。我認為，目前階段，學(xué)習和使用 Agents SDK 的封裝，比學(xué)習 LangGraph 的封裝更麻煩。很大程度上是因為構(gòu)建可靠 Agents 的難點在于確保 Agent 有正確的上下文，而 Agents SDK 在這方面對開發(fā)者的遮蔽程度，比 LangGraph 要嚴重得多。

「更靈活」

這個說法絕對不屬實，恰恰相反。你能用 Agents SDK 做到的任何事，用 LangGraph 都能做到。Agents SDK 能做到的，可能只占 LangGraph 能力的 10%。

「代碼優(yōu)先」

使用 Agents SDK，你寫的是他們定義好的封裝。使用 LangGraph，你寫的是大量的普通代碼。我看不出 Agents SDK 怎么就「代碼優(yōu)先」了。

「使用熟悉的編程結(jié)構(gòu)」

使用 Agents SDK，你得學(xué)習一整套全新的封裝。使用 LangGraph，可以編寫大量的普通代碼。還有什么比這更熟悉的編程結(jié)構(gòu)嗎？

「實現(xiàn)更動態(tài)和適應(yīng)性強的 Agent 編排」

同樣，這跟聲明式還是非聲明式無關(guān)，這是 Workflows vs Agents 的問題。參考上面的觀點。

各種 Agent 框架之間該怎么比較？

我們討論了很多 Agent 框架的不同構(gòu)成要素：