整理 | Tina

當(dāng)前，AI 領(lǐng)域呈現(xiàn)出一種近乎“追星式”的熱情氛圍，每當(dāng)有新的東西發(fā)布，便迅速引發(fā)廣泛關(guān)注與高度評價，仿佛技術(shù)變革即將一觸即發(fā)。同時大家情緒也波動劇烈，從“危機(jī)論”到“爆發(fā)論”頻繁切換。OpenAI 最近出的《A Practical guide to building AI agents》的指南，就是他們最近捧上天的“神作”。它直接被捧成了“圣經(jīng)”，一時間風(fēng)頭無兩。

這份 34 頁的指南被譽(yù)為“市面上最優(yōu)秀的資源”，旨在為產(chǎn)品和工程團(tuán)隊(duì)提供構(gòu)建 AI 智能體的實(shí)用方法，涵蓋了 Agent 的定義、識別 Agent 應(yīng)用場景、設(shè)計(jì)框架、邏輯和編排模式等關(guān)鍵方面。

不過，以冷靜理性著稱的 LangChain 創(chuàng)始人 Harrison Chase 對 OpenAI 的這份指南中提出的一些核心觀點(diǎn)表達(dá)了強(qiáng)烈異議，甚至表示該指南一開始就讓人感到“惱火”。他公開批評這份指南“具有誤導(dǎo)性”，并罕見地進(jìn)行了逐字逐句的分析。

他認(rèn)為，OpenAI 在定義 Agent 時采取了一種過于僵硬的“二元對立”方法。實(shí)際上，目前大多數(shù)“Agentic 系統(tǒng)”都是 Workflows 和 Agents 的有機(jī)結(jié)合。而理想的 Agent 框架應(yīng)當(dāng)能夠支持從“結(jié)構(gòu)化工作流”向“由大模型驅(qū)動”的模式逐步過渡，并且在兩者之間靈活切換。

所以，可以說這場爭論的核心依然是一個老問題：究竟是應(yīng)該讓“大模型直接掌控一切”，還是堅(jiān)持“依然需要自己寫代碼”？（過去叫“Chains”，現(xiàn)在更多人用“Workflows”來表達(dá)。）

為什么路線之爭至關(guān)重要？

在構(gòu)建與大模型相關(guān)的應(yīng)用過程中，越來越多的人逐漸認(rèn)識到一個殘酷的現(xiàn)實(shí)：數(shù)百個工程師小時投入的精細(xì)流程和手動調(diào)優(yōu)，往往在下一次大型模型更新后，一夜之間就被徹底摧毀。

比如說早期使用 GPT-2 開源模型的工程師，當(dāng)時因?yàn)槟Ｐ捅旧砟芰Σ睿芴幚淼纳舷挛拇翱谟中。评砟芰σ埠苋酰_發(fā)者不得不在模型外手寫大量代碼，讓其盡可能的可靠地工作起來。但隨著模型逐漸變得聰明，大家又不得不一段段地刪掉原先寫的那些復(fù)雜代碼。這種反復(fù)被打擊、被迫重新適應(yīng)的經(jīng)歷，正在成為 AI 工程師們必須經(jīng)歷的一次又一次的慘痛教訓(xùn)。

傳統(tǒng)的軟件系統(tǒng)設(shè)計(jì)，大多遵循清晰的請求 - 響應(yīng)模式。前端發(fā)送請求，后端接收請求，訪問數(shù)據(jù)庫，執(zhí)行變更，再返回結(jié)果。這種模式在過去幾十年里構(gòu)建了無數(shù)成功的系統(tǒng)。而即便引入了自動化或代碼生成工具，本質(zhì)上，真正起作用的仍是工程師在開發(fā)階段對代碼的精細(xì)打磨。代碼一旦部署到生產(chǎn)環(huán)境，執(zhí)行的就是確定性的、靜態(tài)的計(jì)算過程。

但今天，越來越多的系統(tǒng)開始引入模糊計(jì)算（fuzzy compute），依靠大模型進(jìn)行動態(tài)推理和生成響應(yīng)。以 OpenAI 為例，全球數(shù)以萬計(jì)的應(yīng)用正在調(diào)用其模型服務(wù)，每次調(diào)用并不是簡單的 CRUD 操作，而是依賴模型的推理能力在運(yùn)行時做出決策。這種變化意味著，應(yīng)用程序的行為不再由靜態(tài)代碼全權(quán)決定，而是由不斷進(jìn)化的模型能力動態(tài)驅(qū)動。而且，不論你是否持續(xù)優(yōu)化自己本地的代碼，只要大模型在背后不斷進(jìn)化，調(diào)用這些模型的應(yīng)用自然也會獲益。

與此同時，大模型自身的進(jìn)步速度遠(yuǎn)超預(yù)期。今年 OpenAI 和 Gemini 的 Deep Research 項(xiàng)目的成功，就是充分利用 O3 進(jìn)行研究規(guī)劃和推理執(zhí)行的例子；隨后 Bolt 和 Manus AI 也基于 Claude 做出了類似實(shí)踐，而且?guī)缀跷词褂脧?fù)雜的工作流工程。

這些都說明，隨著大模型能力越來越強(qiáng)，傳統(tǒng)那套“人精細(xì)打磨、模型配合執(zhí)行”的模式正在變得越來越吃力，而讓模型自主推理、動態(tài)決策的系統(tǒng)，反而越來越有優(yōu)勢。

因此這也決定了我們到底是繼續(xù)靠人手設(shè)計(jì)復(fù)雜的工作流，讓模型在框架里跑，還是直接利用大模型越來越強(qiáng)的推理能力，搭建更靈活、更通用的 Agent。

Workflows 和 Agents 應(yīng)該怎么選？

Agent 的定義

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

OpenAI 認(rèn)為，Agent 是“能代表你獨(dú)立完成任務(wù)的系統(tǒng)”，但這種說法較為籠統(tǒng)、務(wù)虛，一點(diǎn)也不實(shí)用。Harrison Chase 更喜歡 Anthropic 的定義，認(rèn)為他們的定義更精確，更技術(shù)化：

不同客戶對 Agent 的認(rèn)知存在差異。有些人將 Agent 視為完全自主的系統(tǒng)，能夠長時間獨(dú)立運(yùn)行，靈活使用各種工具來完成復(fù)雜任務(wù)。 也有些人認(rèn)為 Agent 是遵循預(yù)設(shè)規(guī)則、按照固定 Workflows 運(yùn)作的系統(tǒng)。在 Anthropic，我們把所有這些變體都?xì)w類為 Agentic 系統(tǒng)，但在架構(gòu)上，我們明確區(qū)分 Workflows 和 Agents： Workflows ：依靠預(yù)先編寫好的代碼路徑，協(xié)調(diào) LLM 和工具完成任務(wù)； Agents ：由 LLM 動態(tài)推理，自主決定任務(wù)流程與工具使用，擁有更大的決策自由度。

對于 Agent 的配置，通常包括模型、指令和工具，且多在循環(huán)中執(zhí)行任務(wù)。兩者的主要區(qū)別在于，Workflows 更為確定性和可控，適合簡單任務(wù)；而 Agents 更靈活、適合復(fù)雜的、需要動態(tài)決策的場景。

大多數(shù)情況下，簡單的 Workflows 就足夠用，只有在任務(wù)復(fù)雜且需要更高靈活性時，才需要構(gòu)建 Agentic 系統(tǒng)。正如 Anthropic 提到的：“在開始構(gòu)建 Agent 之前，確保你的用例確實(shí)需要它。” 因此，Harrison Chase 指出，我們不需要像 OpenAI 那樣，去糾結(jié)某個系統(tǒng)“是不是”一個 Agent：

“在實(shí)際應(yīng)用中，我們發(fā)現(xiàn)大多數(shù)‘Agentic 系統(tǒng)’其實(shí)是 Workflows 和 Agents 的結(jié)合。這也是為什么我更傾向于討論一個系統(tǒng)‘有多 Agentic’。”

另外，搭建一個 Agent 原型并不難，真正的挑戰(zhàn)在于，如何構(gòu)建一個穩(wěn)定可靠、能支撐關(guān)鍵業(yè)務(wù)的 Agent 系統(tǒng)。如今，做一個在 Twitter 上好看的 demo 很容易，但要支撐實(shí)際業(yè)務(wù)，“沒有大量工作是做不到的”。

Harrison Chase 表示他們之前做過一次針對 Agent 開發(fā)者的調(diào)查，調(diào)查顯示“性能質(zhì)量（performance quality）”被認(rèn)為是將 Agents 投入生產(chǎn)的最大障礙。也就是說，讓 Agents 穩(wěn)定可靠地工作，依然是個巨大的挑戰(zhàn)。

LLM 本身能力存在局限性，且在上下文信息傳遞方面常出現(xiàn)錯誤或不完整的情況，后者在實(shí)踐中更為普遍。導(dǎo)致 Agent 效果不佳的常見原因包括：System Message 不完整或過于簡短、用戶輸入模糊不清、未向 LLM 提供正確的工具、工具描述不清晰、缺乏恰當(dāng)?shù)纳舷挛男畔⒁约肮ぞ叻祷氐捻憫?yīng)格式不正確。

Workflows 和 Agents 混合模式更為可靠

Agentic 框架主要分為提供高級別 Agent 封裝和常見 Workflow 封裝兩種類型。而像 LangGraph 這樣的底層編排框架，則可同時支持 Workflows、Agents 以及二者之間的混合形態(tài)，這對于構(gòu)建生產(chǎn)級 Agentic 系統(tǒng)至關(guān)重要。

構(gòu)建可靠 Agents 的關(guān)鍵挑戰(zhàn)在于確保大模型接收到正確的上下文信息，而 Workflows 的優(yōu)勢在于它們能夠?qū)⒄_的上下文傳遞給給 LLMs ，可以精確地決定數(shù)據(jù)如何流動。

構(gòu)建應(yīng)用時，需要在“可預(yù)測性 vs 自主性”和“低門檻 vs 高上限”之間找到平衡。當(dāng)系統(tǒng)越偏向 Agentic，其可預(yù)測性就會越低。Workflow 框架提供了高上限，但門檻也高，但需要自己編寫很多 Agent 的邏輯。Agent 框架則是低門檻，但上限也低——雖然容易上手，但不足以應(yīng)對復(fù)雜的用例。像 LangGraph 這樣的框架，目標(biāo)是兼具低門檻（提供內(nèi)置的 Agent 封裝，方便快速啟動）和高上限（提供低層功能，支持實(shí)現(xiàn)高級用例）。

許多 Agent 框架提供的 Agent 封裝（如包含 prompt、model 和 tools 的類）雖然易于上手，但可能限制對 LLM 輸入輸出的控制，從而影響可靠性，早期的 LangChain 也曾面臨類似問題，“它們提供的封裝反而成了障礙”。

像 Agents SDK（以及早期的 LangChain， CrewAI 等）這樣的框架，既不是聲明式的也不是命令式的，它們只是封裝。它們提供一個 Agent 封裝（一個 Python 類），這個類里面封裝了很多用于運(yùn)行 Agent 的內(nèi)部邏輯。它們算不上真正的編排框架，僅僅是一種封裝。 這些封裝最終會讓你非常非常難以理解或控制到底在每一步傳遞給 LLM 的具體內(nèi)容是什么。這一點(diǎn)非常重要，擁有這種控制能力對于構(gòu)建可靠的 Agents 至關(guān)重要。這就是 Agent 封裝的危險之處。

在實(shí)際應(yīng)用中，Agentic 系統(tǒng)往往并非由單一 Agent 組成，而是由多個 Agent 協(xié)作完成。在多 Agent 系統(tǒng)中，通信機(jī)制至關(guān)重要。因?yàn)闃?gòu)建可靠 Agent 的核心，依然是確保 LLM 能接收到正確、充分的上下文信息。為了實(shí)現(xiàn)高效通信，常見的方法包括「Handoffs」（交接）等模式，像 Agents SDK 就提供了這種風(fēng)格的封裝。

但有時候，這些 Agents 之間最好的通訊方式是 Workflows。而 Workflows 和 Agents 的混合模式，往往能帶來最好的可靠性，因此 Agentic 系統(tǒng)往往是 Workflows 與 Agents 的結(jié)合體。如 Anthropic 所總結(jié)的：“這些構(gòu)建模塊并非一成不變的指令，而是可以根據(jù)具體用例自由調(diào)整和組合的常見模式”。

而 Agent 框架則通過提供統(tǒng)一封裝、記憶管理、人機(jī)協(xié)作、流式處理、可觀測性和容錯機(jī)制，大幅降低構(gòu)建可靠 Agentic 系統(tǒng)的復(fù)雜度，但前提是開發(fā)者需理解其底層機(jī)制。

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

大模型越來越厲害，那么是不是都會變成 Agents？

Chase 認(rèn)為，未來所有應(yīng)用都將由簡單的、能夠調(diào)用工具的 Agents 主導(dǎo)的觀點(diǎn)是值得商榷的。雖然工具調(diào)用 Agents 的性能在提升，但“能夠控制輸入給 LLM 的內(nèi)容依然會非常重要（垃圾進(jìn)，垃圾出）”，簡單的 Agent 循環(huán)并不能覆蓋所有應(yīng)用需求。

實(shí)際上，對于很多企業(yè)級應(yīng)用來說，任務(wù)本身具有大量細(xì)微差異，難以靠單一、通用的 Agent 處理。“每家公司的客戶支持體驗(yàn)都足夠獨(dú)特，以至于一個通用 Agent 無法達(dá)到所需的性能”，這也是 Sierra 選擇構(gòu)建客戶支持 Agent 平臺而非單一 Agent 的原因。

OpenAI 的 Deep Research 項(xiàng)目是 Agent 的一個好例子，這同時也證明了針對特定任務(wù)訓(xùn)練的模型可以只用簡單 Agent 循環(huán)。它的成功前提是：“你能針對你的特定任務(wù)訓(xùn)練一個 SOTA 模型”，而當(dāng)前只有大型模型實(shí)驗(yàn)室能夠做到這一點(diǎn)。對于大多數(shù)初創(chuàng)公司或企業(yè)用戶來說，這并不現(xiàn)實(shí)。

在通用任務(wù)領(lǐng)域，Claude code 和 OpenAI 的 Codex CLI 是兩個代碼 Agents 的例子，它們都使用了簡單的工具調(diào)用循環(huán)。但 Chase 認(rèn)為，其基礎(chǔ)模型在訓(xùn)練時使用了大量的編程數(shù)據(jù)和任務(wù)，這些領(lǐng)域數(shù)據(jù)的確切形態(tài)也影響巨大。正如 Chase 引用 Ben Hylak 的觀察：

當(dāng)前的模型已經(jīng)不再擅長在 Cursor 中工作了。 它們的優(yōu)化方向主要是針對終端環(huán)境，這也是為什么 3.7 和 o3 在 Cursor 里體驗(yàn)較差，但在其他環(huán)境中表現(xiàn)出色的原因。

因此，總結(jié)來看，簡單 Agents 在特定條件下有效，但僅限于數(shù)據(jù)和任務(wù)極為匹配的場景。對絕大多數(shù)應(yīng)用而言，Workflows 仍然不可或缺，且生產(chǎn)環(huán)境中的 Agentic 系統(tǒng)將是 Workflows 和 Agents 的結(jié)合。

OpenAI 的觀點(diǎn)哪里不對？

Chase 指出，OpenAI 在討論 Agentic 框架時，其觀點(diǎn)建立在一些錯誤的二分法之上，混淆了“Agentic 框架”的不同維度，從而夸大了他們單一封裝的價值。歸根結(jié)底，他們沒有準(zhǔn)確把握生產(chǎn)級 Agentic 系統(tǒng)的核心挑戰(zhàn)，也沒有清晰認(rèn)識到框架真正應(yīng)該提供的價值——即一個可靠、透明的編排層，能夠讓開發(fā)者精確控制傳遞給 LLM 的上下文，同時無縫處理持久化、容錯、Human-in-the-loop 等生產(chǎn)關(guān)鍵問題。

他認(rèn)為 OpenAI 的論述中存在以下幾方面的問題（除去一些王婆賣瓜的觀點(diǎn)）：

• OpenAI 將“聲明式 vs 非聲明式”與“是否需要編排框架”混為一談

LangGraph 并不是完全聲明式的 —— 但它已經(jīng)足夠聲明式了，主要的問題是，“非聲明式”這個說法承擔(dān)了太多含義，而且具有誤導(dǎo)性。通常，當(dāng)人們批評聲明式框架時，他們傾向于更偏好命令式框架。“但 Agents SDK 并不是一個命令式框架，它是一種封裝”。

• 錯誤歸因 Workflows 的局限性

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

但實(shí)際上，這與聲明式或非聲明式無關(guān)，而是 Workflows 和 Agents 的應(yīng)用場景問題。你完全可以用聲明式的圖來表達(dá) Agents SDK 中的 Agent 邏輯，而且這個圖的動態(tài)性和靈活性，和 Agents SDK 本身是一樣的。

更重要的是，大部分應(yīng)用場景下，Workflows 足夠簡單直接，OpenAI 和 Anthropic 自己也承認(rèn)這一點(diǎn)。因此，我們應(yīng)該盡可能使用 Workflows，大多數(shù) Agentic 系統(tǒng)都是兩者的結(jié)合。只有在確實(shí)需要時才引入更復(fù)雜的 Agent，但不要什么都用 Agent。

• 低估了 Agents SDK 本身的學(xué)習(xí)復(fù)雜度

OpenAI 暗示使用框架會引入新的領(lǐng)域特定語言，增加學(xué)習(xí)成本。但實(shí)際上：“Agents SDK 本身就是一種新的封裝，它也需要學(xué)習(xí)，而且學(xué)習(xí)曲線更陡峭。” 特別是在確保正確上下文傳遞這一關(guān)鍵點(diǎn)上，Agents SDK 比 LangGraph 反而增加了開發(fā)難度。

• 關(guān)于“靈活性”的錯誤陳述

OpenAI 宣稱 Agents SDK 更靈活，但實(shí)際情況是：“用 Agents SDK 能做到的事情，只是 LangGraph 能力范圍的 10%。” LangGraph 提供了更通用、更強(qiáng)大的編排能力，而不是簡單封裝特定模式。

• 關(guān)于“實(shí)現(xiàn)更動態(tài)和適應(yīng)性強(qiáng)的 Agent 編排”的誤導(dǎo)

最后，OpenAI 認(rèn)為 Agents SDK 可以實(shí)現(xiàn)更動態(tài)、更適應(yīng)性的編排，但這本質(zhì)上還是一個“Workflows vs Agents”的設(shè)計(jì)權(quán)衡問題。

最后，Harrison 在他的文章中還做了一件很酷的事情，那就是他列了一個表格，把現(xiàn)在市面上所有相關(guān)的 Agent 框架都拿出來做了個全面的比較。

對于想要深入了解和選擇 Agent 框架的開發(fā)者來說，它提供了一個結(jié)構(gòu)化的、易于理解的方式來比較不同框架的能力，幫助開發(fā)者做出更明智的決策，并認(rèn)識到優(yōu)秀 Agent 框架應(yīng)該具備的關(guān)鍵特性。

https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

https://blog.langchain.dev/how-to-think-about-agent-frameworks/

https://docs.google.com/spreadsheets/d/1jzgbANBVi6rNzZVsjZC2CSaCU-byXGlSs0bgy2v2GNQ/edit?gid=0#gid=0

https://www.youtube.com/watch?v=-rsTkYgnNzM

聲明：本文為 AI 前線整理，不代表平臺觀點(diǎn)，未經(jīng)許可禁止對全文或部分內(nèi)容進(jìn)行轉(zhuǎn)載。

4 月 28 日 20:00，白鯨開源 CEO 郭煒 · Kong 中國區(qū)總裁戴冠蘭 · GMI Cloud 中國 VP 蔣劍彪，三位專家深度剖析出海實(shí)戰(zhàn)要點(diǎn)，歡迎掃碼預(yù)約或點(diǎn)擊下方預(yù)約卡片。

今日薦文

你也「在看」嗎？