當前，AI 領域呈現出一種近乎“追星式”的熱情氛圍，每當有新的東西釋出，便迅速引發廣泛關注與高度評價，彷彿技術變革即將一觸即發。同時大家情緒也波動劇烈，從“危機論”到“爆發論”頻繁切換。OpenAI 最近出的《A Practical guide to building AI agents》的指南，就是他們最近捧上天的“神作”。它直接被捧成了“聖經”，一時間風頭無兩。
這份 34 頁的指南被譽為“市面上最優秀的資源”，旨在為產品和工程團隊提供構建 AI 智慧體的實用方法，涵蓋了 Agent 的定義、識別 Agent 應用場景、設計框架、邏輯和編排模式等關鍵方面。
不過，以冷靜理性著稱的 LangChain 創始人 Harrison Chase 對 OpenAI 的這份指南中提出的一些核心觀點表達了強烈異議，甚至表示該指南一開始就讓人感到“惱火”。他公開批評這份指南“具有誤導性”，並罕見地進行了逐字逐句的分析。
他認為，OpenAI 在定義 Agent 時採取了一種過於僵硬的“二元對立”方法。實際上，目前大多數“Agentic 系統”都是 Workflows 和 Agents 的有機結合。而理想的 Agent 框架應當能夠支援從“結構化工作流”向“由大模型驅動”的模式逐步過渡，並且在兩者之間靈活切換。
所以，可以說這場爭論的核心依然是一個老問題：究竟是應該讓“大模型直接掌控一切”，還是堅持“依然需要自己寫程式碼”？（過去叫“Chains”，現在更多人用“Workflows”來表達。）
在構建與大模型相關的應用過程中，越來越多的人逐漸認識到一個殘酷的現實：數百個工程師小時投入的精細流程和手動調優，往往在下一次大型模型更新後，一夜之間就被徹底摧毀。
比如說早期使用 GPT-2 開源模型的工程師，當時因為模型本身能力差，能處理的上下文視窗又小，推理能力也很弱，開發者不得不在模型外手寫大量程式碼，讓其儘可能的可靠地工作起來。但隨著模型逐漸變得聰明，大家又不得不一段段地刪掉原先寫的那些複雜程式碼。這種反覆被打擊、被迫重新適應的經歷，正在成為 AI 工程師們必須經歷的一次又一次的慘痛教訓。
傳統的軟體系統設計，大多遵循清晰的請求 – 響應模式。前端傳送請求，後端接收請求，訪問資料庫，執行變更，再返回結果。這種模式在過去幾十年裡構建了無數成功的系統。而即便引入了自動化或程式碼生成工具，本質上，真正起作用的仍是工程師在開發階段對程式碼的精細打磨。程式碼一旦部署到生產環境，執行的就是確定性的、靜態的計算過程。
但今天，越來越多的系統開始引入模糊計算（fuzzy compute），依靠大模型進行動態推理和生成響應。以 OpenAI 為例，全球數以萬計的應用正在呼叫其模型服務，每次呼叫並不是簡單的 CRUD 操作，而是依賴模型的推理能力在執行時做出決策。這種變化意味著，應用程式的行為不再由靜態程式碼全權決定，而是由不斷進化的模型能力動態驅動。而且，不論你是否持續最佳化自己本地的程式碼，只要大模型在背後不斷進化，呼叫這些模型的應用自然也會獲益。
與此同時，大模型自身的進步速度遠超預期。今年 OpenAI 和 Gemini 的 Deep Research 專案的成功，就是充分利用 O3 進行研究規劃和推理執行的例子；隨後 Bolt 和 Manus AI 也基於 Claude 做出了類似實踐，而且幾乎未使用複雜的工作流工程。
這些都說明，隨著大模型能力越來越強，傳統那套“人精細打磨、模型配合執行”的模式正在變得越來越吃力，而讓模型自主推理、動態決策的系統，反而越來越有優勢。
因此這也決定了我們到底是繼續靠人手設計複雜的工作流，讓模型在框架裡跑，還是直接利用大模型越來越強的推理能力，搭建更靈活、更通用的 Agent。
Harrison Chase 認為目前 Agent 並沒有一個統一的或大家公認的定義，不同的人常常從不同的角度來定義它。
OpenAI 認為，Agent 是“能代表你獨立完成任務的系統”，但這種說法較為籠統、務虛，一點也不實用。Harrison Chase 更喜歡 Anthropic 的定義，認為他們的定義更精確，更技術化：
不同客戶對 Agent 的認知存在差異。有些人將 Agent 視為完全自主的系統，能夠長時間獨立執行，靈活使用各種工具來完成複雜任務。 也有些人認為 Agent 是遵循預設規則、按照固定 Workflows 運作的系統。在 Anthropic，我們把所有這些變體都歸類為 Agentic 系統，但在架構上，我們明確區分 Workflows 和 Agents： Workflows：依靠預先編寫好的程式碼路徑，協調 LLM 和工具完成任務；Agents：由 LLM 動態推理，自主決定任務流程與工具使用，擁有更大的決策自由度。
對於 Agent 的配置，通常包括模型、指令和工具，且多在迴圈中執行任務。兩者的主要區別在於，Workflows 更為確定性和可控，適合簡單任務；而 Agents 更靈活、適合複雜的、需要動態決策的場景。
大多數情況下，簡單的 Workflows 就足夠用，只有在任務複雜且需要更高靈活性時，才需要構建 Agentic 系統。正如 Anthropic 提到的：“在開始構建 Agent 之前，確保你的用例確實需要它。” 因此，Harrison Chase 指出，我們不需要像 OpenAI 那樣，去糾結某個系統“是不是”一個 Agent：
另外，搭建一個 Agent 原型並不難，真正的挑戰在於，如何構建一個穩定可靠、能支撐關鍵業務的 Agent 系統。如今，做一個在 Twitter 上好看的 demo 很容易，但要支撐實際業務，“沒有大量工作是做不到的”。
Harrison Chase 表示他們之前做過一次針對 Agent 開發者的調查，調查顯示“效能質量（performance quality）”被認為是將 Agents 投入生產的最大障礙。也就是說，讓 Agents 穩定可靠地工作，依然是個巨大的挑戰。
LLM 本身能力存在侷限性，且在上下文資訊傳遞方面常出現錯誤或不完整的情況，後者在實踐中更為普遍。導致 Agent 效果不佳的常見原因包括：System Message 不完整或過於簡短、使用者輸入模糊不清、未向 LLM 提供正確的工具、工具描述不清晰、缺乏恰當的上下文資訊以及工具返回的響應格式不正確。
Agentic 框架主要分為提供高級別 Agent 封裝和常見 Workflow 封裝兩種型別。而像 LangGraph 這樣的底層編排框架，則可同時支援 Workflows、Agents 以及二者之間的混合形態，這對於構建生產級 Agentic 系統至關重要。
構建可靠 Agents 的關鍵挑戰在於確保大模型接收到正確的上下文資訊，而 Workflows 的優勢在於它們能夠將正確的上下文傳遞給給 LLMs ，可以精確地決定資料如何流動。
構建應用時，需要在“可預測性 vs 自主性”和“低門檻 vs 高上限”之間找到平衡。當系統越偏向 Agentic，其可預測性就會越低。Workflow 框架提供了高上限，但門檻也高，但需要自己編寫很多 Agent 的邏輯。Agent 框架則是低門檻，但上限也低——雖然容易上手，但不足以應對複雜的用例。像 LangGraph 這樣的框架，目標是兼具低門檻（提供內建的 Agent 封裝，方便快速啟動）和高上限（提供低層功能，支援實現高階用例）。
許多 Agent 框架提供的 Agent 封裝（如包含 prompt、model 和 tools 的類）雖然易於上手，但可能限制對 LLM 輸入輸出的控制，從而影響可靠性，早期的 LangChain 也曾面臨類似問題，“它們提供的封裝反而成了障礙”。
在實際應用中，Agentic 系統往往並非由單一 Agent 組成，而是由多個 Agent 協作完成。在多 Agent 系統中，通訊機制至關重要。因為構建可靠 Agent 的核心，依然是確保 LLM 能接收到正確、充分的上下文資訊。為了實現高效通訊，常見的方法包括「Handoffs」（交接）等模式，像 Agents SDK 就提供了這種風格的封裝。
但有時候，這些 Agents 之間最好的通訊方式是 Workflows。而 Workflows 和 Agents 的混合模式，往往能帶來最好的可靠性，因此 Agentic 系統往往是 Workflows 與 Agents 的結合體。如 Anthropic 所總結的：“這些構建模組並非一成不變的指令，而是可以根據具體用例自由調整和組合的常見模式”。
而 Agent 框架則透過提供統一封裝、記憶管理、人機協作、流式處理、可觀測性和容錯機制，大幅降低構建可靠 Agentic 系統的複雜度，但前提是開發者需理解其底層機制。
Chase 認為，未來所有應用都將由簡單的、能夠呼叫工具的 Agents 主導的觀點是值得商榷的。雖然工具呼叫 Agents 的效能在提升，但“能夠控制輸入給 LLM 的內容依然會非常重要（垃圾進，垃圾出）”，簡單的 Agent 迴圈並不能覆蓋所有應用需求。
實際上，對於很多企業級應用來說，任務本身具有大量細微差異，難以靠單一、通用的 Agent 處理。“每家公司的客戶支援體驗都足夠獨特，以至於一個通用 Agent 無法達到所需的效能”，這也是 Sierra 選擇構建客戶支援 Agent 平臺而非單一 Agent 的原因。
OpenAI 的 Deep Research 專案是 Agent 的一個好例子，這同時也證明了針對特定任務訓練的模型可以只用簡單 Agent 迴圈。它的成功前提是：“你能針對你的特定任務訓練一個 SOTA 模型”，而當前只有大型模型實驗室能夠做到這一點。對於大多數初創公司或企業使用者來說，這並不現實。
在通用任務領域，Claude code 和 OpenAI 的 Codex CLI 是兩個程式碼 Agents 的例子，它們都使用了簡單的工具呼叫迴圈。但 Chase 認為，其基礎模型在訓練時使用了大量的程式設計資料和任務，這些領域資料的確切形態也影響巨大。正如 Chase 引用 Ben Hylak 的觀察：
因此，總結來看，簡單 Agents 在特定條件下有效，但僅限於資料和任務極為匹配的場景。對絕大多數應用而言，Workflows 仍然不可或缺，且生產環境中的 Agentic 系統將是 Workflows 和 Agents 的結合。
Chase 指出，OpenAI 在討論 Agentic 框架時，其觀點建立在一些錯誤的二分法之上，混淆了“Agentic 框架”的不同維度，從而誇大了他們單一封裝的價值。歸根結底，他們沒有準確把握生產級 Agentic 系統的核心挑戰，也沒有清晰認識到框架真正應該提供的價值——即一個可靠、透明的編排層，能夠讓開發者精確控制傳遞給 LLM 的上下文，同時無縫處理持久化、容錯、Human-in-the-loop 等生產關鍵問題。
他認為 OpenAI 的論述中存在以下幾方面的問題（除去一些王婆賣瓜的觀點）：
-
OpenAI 將“宣告式 vs 非宣告式”與“是否需要編排框架”混為一談
LangGraph 並不是完全宣告式的 —— 但它已經足夠宣告式了，主要的問題是，“非宣告式”這個說法承擔了太多含義，而且具有誤導性。通常，當人們批評宣告式框架時，他們傾向於更偏好命令式框架。“但 Agents SDK 並不是一個命令式框架，它是一種封裝”。
-
錯誤歸因 Workflows 的侷限性
OpenAI 聲稱：“隨著 Workflows 變得越來越動態和複雜，這種方法會迅速變得笨拙和具有挑戰性。”
但實際上，這與宣告式或非宣告式無關，而是 Workflows 和 Agents 的應用場景問題。你完全可以用宣告式的圖來表達 Agents SDK 中的 Agent 邏輯，而且這個圖的動態性和靈活性，和 Agents SDK 本身是一樣的。
更重要的是，大部分應用場景下，Workflows 足夠簡單直接，OpenAI 和 Anthropic 自己也承認這一點。因此，我們應該儘可能使用 Workflows，大多數 Agentic 系統都是兩者的結合。只有在確實需要時才引入更復雜的 Agent，但不要什麼都用 Agent。
-
低估了 Agents SDK 本身的學習複雜度
OpenAI 暗示使用框架會引入新的領域特定語言，增加學習成本。但實際上：“Agents SDK 本身就是一種新的封裝，它也需要學習，而且學習曲線更陡峭。” 特別是在確保正確上下文傳遞這一關鍵點上，Agents SDK 比 LangGraph 反而增加了開發難度。
-
關於“靈活性”的錯誤陳述
OpenAI 宣稱 Agents SDK 更靈活，但實際情況是：“用 Agents SDK 能做到的事情，只是 LangGraph 能力範圍的 10%。” LangGraph 提供了更通用、更強大的編排能力，而不是簡單封裝特定模式。
-
關於“實現更動態和適應性強的 Agent 編排”的誤導
最後，OpenAI 認為 Agents SDK 可以實現更動態、更適應性的編排，但這本質上還是一個“Workflows vs Agents”的設計權衡問題。
最後，Harrison 在他的文章中還做了一件很酷的事情，那就是他列了一個表格，把現在市面上所有相關的 Agent 框架都拿出來做了個全面的比較。
對於想要深入瞭解和選擇 Agent 框架的開發者來說，它提供了一個結構化的、易於理解的方式來比較不同框架的能力，幫助開發者做出更明智的決策，並認識到優秀 Agent 框架應該具備的關鍵特性。
參考連結：
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 前線整理，不代表平臺觀點，未經許可禁止對全文或部分內容進行轉載。
4 月 28 日 20:00，白鯨開源 CEO 郭煒 · Kong 中國區總裁戴冠蘭 · GMI Cloud 中國 VP 蔣劍彪，三位專家深度剖析出海實戰要點，歡迎掃碼預約或點選下方預約卡片。