MLNLP社群是國內外知名的機器學習與自然語言處理社群，受眾覆蓋國內外NLP碩博生、高校老師以及企業研究人員。

社群的願景是促進國內外自然語言處理，機器學習學術界、產業界和廣大愛好者之間的交流和進步，特別是初學者同學們的進步。

來源 | NLP工作站

2025年被視為AI Agent元年，多家科技巨頭已明確表態：

OpenAI CEO奧特曼預測：https://blog.samaltman.com/reflections
微軟在2025年AI六大趨勢中強調：https://news.microsoft.com/source/features/ai/6-ai-trends-youll-see-more-of-in-2025/
谷歌2025年釋出：https://drive.google.com/file/d/1oEjiRCTbd54aSdB_eEe3UShxLBWK9xkt/preview

本文將從四個維度探討AI Agent的發展：

1. 前沿Agent例項分析 – 深入解析OpenAI兩款代表性Agent產品

2. Agent的本質與定義 – 基於Anthropic《Building Effective AI Agents》研究，探討Agent與工作流(Workflow)的根本區別

3. Agent的核心競爭力 – 以Manus為例，分析Agent領域的技術護城河

4. 對演算法工程師的啟示 – 這波Agent浪潮演算法工程師應該要關注哪些方面

OpenAI 25 年釋出的兩款agent 產品

隨著各類Agent產品迅速湧入市場，讓人目不暇接。看不過來怎麼辦？很簡單，最直接的做法就是關注全球最top的AI公司 OpenAI 的釋出動態，透過其釋出的產品來洞察Agent未來的發展方向。

一月份 Open AI Operator

Operator是 openai 釋出的第一款 agent 產品。 Operator是一款能夠自主操作瀏覽器完成任務的AI智慧代理。它基於名為“計算機使用代理”（Computer-Using Agent，簡稱CUA）的新型模型，結合了GPT系列模型的視覺能力和強化學習的高階推理能力，採用端到端的訓練最佳化方式。

Operator基於雲端的虛擬瀏覽器。當用戶啟用 Operator 時，系統會呼叫一個遠端的虛擬瀏覽器來執行任務，在瀏覽器中Operator agent可以像人類一樣透過輸入、點選和滾動等方式與網頁互動，無需依賴定製API整合。使用者只需下達指令，它就能自動完成各種線上任務，如填寫表單、預訂餐廳、購買商品等。Operator 目前僅面向 ChatGPT Pro 訂閱使用者開放。

https://www.bilibili.com/video/BV1tYf7YnEvW/?spm_id_from=333.337.search-card.all.click

OpenAI 似乎希望將 Operator 打造為一種通用性強、適應性廣的工具。Operator 的設計理念與傳統的呼叫 Function API 的方式相比有本質區別。例如，開發一個網購 Agent，如果依賴於呼叫淘寶、京東等平臺的 API，其遷移性會非常有限。一旦目標平臺的 API 發生變化，或者需要遷移到其他平臺（如抖音商城），模型就需要重新適配。而 Operator 透過抽象出人類使用瀏覽器的行為（如滑鼠點選、鍵盤輸入等），理論上能夠實現人類透過瀏覽器完成的任何操作，從而具備更強的通用性和適應性。

不過，從直播展示的案例來看，Operator 的表現還有待最佳化。例如，

長鏈路任務表現欠佳：例如在多個搜尋結果中找不到答案時容易失去方向導致卡住，這個主要是模型問題，應該很快能有所提升。如下面 openai 公佈的 benchmark，operator還遠遠達不到人類水平。
互動形式與驗證機制：頻繁的使用者確認容易中斷任務流程，如中間老是要使用者來填賬號密碼等關鍵資訊。以及難以自動化驗證操作正確性，如在購物場景中，難以確保Operator購買了正確的商品、數量和金額。這個主要是產品設計的問題。

二月份 Open AI Deep Research

Deep Research是專為金融、科學、政策、工程等領域的深度研究設計的AI Agent，提供全面、精準的研究支援，旨在解決高強度知識工作的需求。OpenAI 號稱 5-30分鐘，能出一份專家級別的調研報告。

https://openai.com/index/introducing-deep-research/ https://wiki.ds-int.cn/pages/viewpage.action?pageId=129440918

Openai 上官網的例子

商業問題：幫我查詢過去10年按GDP排名前10的發達國家和前10的發展中國家的iOS和Android採用率、想學習另一種語言的人口百分比以及移動裝置普及率的變化。將這些資訊整理成表格，統計資料分列顯示，並針對ChatGPT目前活躍的市場，為新推出的iOS翻譯應用提供目標市場建議。
大海撈針問題：有一部我前段時間看過的電視節目，我忘了名字，但我記得其中一集的情節。你能幫我找到這集的名字嗎？以下是我記得的情節：兩個男人在玩撲克，其中一人在對方讓他下注後選擇了棄牌。實際上，棄牌的人手牌很好，卻中了對方的虛張聲勢。第二局，同一個人再次棄牌，但這次他的手牌確實很差。一個男人被鎖在房間裡，隨後他的女兒來敲門。兩個男人去了一家肉店，其中一人帶了伏特加作為禮物。請深入瀏覽網路，找到發生這些情節的電視節目那一集。
醫學問題：深入研究透過直接修改四個Yamanaka因子的蛋白質序列來提高OSKM重程式設計效率的嘗試。列出你找到的所有相關論文，作者，使用的方法和結果。研究論文中蛋白質變化和相應結果的模式，並列出科學家為提高效率而修改的前三個領域，以及他們為什麼認為這些變化是有效的。
設計問題：找到證據表明，帶有圖示和標籤的按鈕比沒有標籤的按鈕，或者沒有圖示的標籤按鈕更易用。我知道關於這一點已經有很多使用者研究了，非常希望看到一份詳細的報告，以及一個高階的、一次性的、明確的關於有效性的答案。
購物問題：我在尋找完美的滑雪板。冬天我主要在北海道每月大約兩次進行滑雪。我喜歡經過整理的賽道，但也希望板子偶爾能應對一些新鮮粉雪。我更喜歡多功能的全地形或自由式滑雪板，具有中等彈性，既適合刻滑又能在多變條件下靈活操控。我希望有一個清新、柑橘色調的滑雪板，在雪道上能脫穎而出。我的預算是中檔到略高階，並希望得到在日本可購買的特定品牌和型號的建議。請解釋為什麼每款推薦的滑雪板符合我的需求。還包括任何關於在北海道獨特雪質條件下滑雪的建議或注意事項。請附上物品圖片，並以易於閱讀的表格格式呈現。
一般問題：NFL踢球者的平均退休年齡是多少？

個人實測的例子

例子一：請你幫我列出openai、anthropic、 gemini、 meta 、 qwen、 deepseek、豆包、kimi 、零一萬物、階越星辰、minimax 、智譜、百穿智慧、面壁智慧在 22 年-25年，發表過的大模型，列出每一個大模型發表的時間，模型引數量多大，有什麼版本，是什麼大模型（輸入是什麼，輸出是什麼），是否開源，如開源則列出對應的 huggingface。

這個例子是，考察它深度搜索的能力。這個問題可能我自己整理要半天，想看看 deep research能幫我整理多少資訊出來。

一開始把問題拋給 deep research，deep research 會從問題中找到不確定的因素讓你確定，這種互動可能會持續幾輪，然後才進入它的分析中。

deep research透過收集資訊源，並不斷地整理答案，中間會不斷地規劃任務，反思結果，如搜到第四個資訊源時，發現與前面得出的結論矛盾，會進一步搜尋驗證。下圖右邊是它的整個搜尋過程。

最終，deep research幫我梳理出一張結果表。

例子的問題：這裡如Claude 系列漏了 Claude3、 3.5、 3.7等、 deepseek-V3也不是 25 年 1 月出的，而是24年 12 月出的，這個應該是 deep research引用錯了不正確的資訊源，如把資訊源中的“預測推出”理解成了正式推出等。
例子二：研究《哪吒2》在國際市場的接受度與文化輸出效果，分析其對提升中國文化軟實力的貢獻。

例子的問題：引用的資訊源不夠準確，有時候說引用了 CNN 的報道，但實際開啟，發現並不是 CNN，容易捏造資料，例如說票房 60億，但開啟資料來源，發現數據源並沒有提到 60。

從上面兩個例子可以看到，Deep Research 遠遠不能直接用於生產。

最大的問題：幻覺，一方面，模型自身可能存在侷限性，導致生成內容的準確性或可靠性不足；另一方面，資訊源的干擾也可能引入錯誤或誤導性的內容。
給我的感覺，Deep Research 不是一個 “無所不能” 的 “研究智慧體”，更像是一個和你一起完成複雜工作的 “虛擬助手”。對於那些本就擅長搜尋和資訊處理的人而言，Deep Research 能夠進一步提升他們的效率，使其如虎添翼。然而，對於那些原本就不擅長搜尋和整理資訊的人，可能並不會節省時間，甚至需要花費更多時間去核實資訊的正確性。這有點像程式設計工具 Cursor，對於會寫程式碼的人，它能極大地提高效率；而對於不會寫程式碼的人，debug 的時間可能比自己從頭開始寫程式碼還要費時。

即使如此，Deep Research對比其它家也效果也領先一大截了，如 Perplexity、Grok3、秘塔AI搜尋，我們也在調研開源的 deep research實現，效果是遠遠達不到 openai 的效果的。

以下是紅杉資本對話OpenAI Deep Research團隊：2025如何成為"智慧體之年"，這篇訪談的資訊量及其之高，全文的核心在於披露了 Deep Research的訓練思路。許多人誤解了Deep Research，尤其市面上出現了大量所謂的復現版本，讓大家的認知出現了偏差。事實上，OpenAI並不是簡單地在GPT基礎上套殼（套殼指的是在 GPT 模型的基礎上，透過定製化的 prompt 以及固定的程式碼流程來實現某功能）。相反，OpenAI 基於 GPT-o3，採用端到端強化學習+高質量訓練資料的方式訓練了一個全新的模型，能夠完全在內部完成搜尋任務：模型學習了基礎的瀏覽能力（搜尋、點選、滾動、檔案解析），以及如何透過強化學習來整合大量網頁資訊，生成結構清晰、來源可靠的研究報告。

https://www.bilibili.com/video/BV14bPGejEmG/?spm_id_from=888.80997.embed_other.whitelist&bvid=BV14bPGejEmG

什麼是端到端的學習？

端到端訓練與傳統的工作流程截然不同。傳統方法通常將複雜任務拆分成多個子任務，如上圖的上面（後面會說到，這種是 workflow），分別處理後再整合結果。例如，某些開源的 Deep Research 專案中，有幾種復現方式

方式一：將使用者問題分解為多個子查詢，每個子查詢由不同模型或模組處理，最後由一個模型統一整合答案。
方式二：模型先給出初步回答，然後自我評價打分，假如評價不 ok，就迴圈修改，直到達到滿意結果，類似於畢業論文的修改過程。

這些都是提前定義好的 workflow，這些workflow雖然在一定程度上能取得不錯的效果，但存在明顯的侷限性：它們依賴於預先搭建好的workflow，限制了模型的自主性和靈活性，難以scaling，難以 cover 無窮無盡的邊緣情況，每當有新的bad cases，可能就要在原來的工作架構上新增解決的模組，導致程式碼越來越臃腫，上限有限。以一個包含四個子任務的串聯任務為例，如果每個子任務的成功率為95%，那麼整體成功率僅為81%。而端到端訓練的單個模型，透過高質量資料+強化學習的加持，有望將整體成功率提升至95%。

端到端訓練是一種更直接、更高效的方法。它摒棄了傳統的工作流程，將整個任務交給一個模型來完成。模型自行決定如何呼叫外部 tool、何時需要拆分子查詢、何時進行自我校驗等，真正實現了“模型即服務”。

說得有點虛，用個具體一點的例子來說明，假如要端到端的學習，我應該怎麼做資料標註呢？可以是，把使用者的問題問 GPT-o3，讓 o3 取樣 10 個不同的答案，由標註者選擇哪個答案最好，用偏好學習的方式訓練獎勵模型，然後再把這個獎勵模型應用到強化學習中。本質在於激勵AI自我學習，比試圖教會AI每一項任務更重要。

Anthropic：《Building Effective AI Agents》

2024年12月，Anthropic釋出了一篇關於構建AI智慧體的重要部落格。Anthropic經過與數十個跨行業團隊的合作，得出一個關鍵結論：最成功的AI Agent並非依賴複雜框架或專用庫，而是採用簡單、可組合的構建模式。簡單點說，簡潔的端到端流程往往比複雜設計更容易維護、最佳化，並取得更顯著的效果提升，更容易取得成功。

https://www.anthropic.com/engineering/building-effective-agents

What are agents？

Anthropic 把下述兩種統稱為 agentic systems：

Workflows: 透過預定義程式碼路徑協調LLMs和Tools。
Agents: LLM自主決定過程和Tools的使用，控制任務完成方式

從這個定義看，市場上大多數所謂的"智慧體"(包括Manus)實際上是workflows。真正的agents相對較少，如OpenAI的Operator、Deep Research以及Cursor等產品。

When (and when not) to use agents

Anthropic提供了清晰的選擇指南：

從簡單開始：為LLM應用選擇最簡單的解決方案，如一開始透過prompt 來解決，只在必要時增加複雜性
根據任務特性選擇：對於可預測、定義明確的任務，需要一致性時使用workflows；當需要大規模的靈活性和強大的模型來驅動決策時，使用真正的Agent
避免過度設計：對許多應用來說，最佳化單個LLM呼叫(透過檢索和上下文示例)已經足夠

感同身受，很多時候業務部門過來問，能不能用 agents 的方式來解決，但深入分析後發現，簡單的prompts搭配RAG或few-shots就能有效解決。正如Anthropic所言，不要用牛刀來殺雞。

When and how to use frameworks

Anthropic 對市面上如LangGraph、Bedrock、Rivet的看法是，雖然這些框架能幫我們快速搭建應用，但它們往往會給系統增加一層"看不見的面紗"，說白了，就是有些框架會寫得很重，不利於 debug 和最佳化。

Anthropic 的建議是：先試試直接用LLM的API，很多功能幾行程式碼就能搞定。如果真要用框架，一定要了解它底層是怎麼運作的。很多人踩坑，調優不到好的效果就是因為對框架底層機制不清楚。

記住，簡單方案能解決的問題，就別引入不必要的複雜度。

Building blocks, workflows, and agents

Agent的構建分為不同複雜度級別，從基礎的增強型大語言模型Augmented LLM開始，逐步發展到預定義的workflow，最終形成自主的 agent。

Building block: The augmented LLM

增強型大語言模型(augmented LLM)是Agent的基本構建單元，它集成了檢索、工具和記憶等能力。現代模型能夠主動使用這些功能，如生成搜尋查詢和選擇適當工具。

Workflow

包含有以下幾種：

Workflow: Prompt chaining

鏈式工作流就是將複雜任務分解為連續步驟，每步LLM呼叫處理前一步輸出，可新增檢查點（如下圖的Gate）確保過程正確。適用於可清晰劃分的任務，如營銷文案生成後翻譯或先建立文件大綱再撰寫完整內容。

Workflow: Routing

路由工作流就是先給輸入內容"分類"，然後根據這個分類標籤把它送到最合適的專門處理流程去。這種方法在處理那些有明顯不同型別的複雜任務時特別有用，比如可以把各種客服問題分類處理，或者根據問題難度路由到小模型或大模型來回答。

Workflow：Parallelization

並行工作流就是讓多個大語言模型同時處理任務，可以分成兩種方式：一種是"分子任務"，把大任務切成小任務同時處理；另一種是"投票"，讓多個模型做同一件事然後綜合結果。這種方法在需要提高處理速度或者想要多角度意見時非常有用，比如一個模型專注回答問題，另一個專門檢查內容是否得當。具體應用例子包括程式碼安全審查、內容稽核，或者讓每個模型評估不同方面，這樣比讓單個模型同時兼顧所有方面效果更好。

Workflow: Orchestrator-workers

管理者-工作者流程就像有個主管模型當"老大"，它看情況拆任務，看情況把不同的任務派給"小弟"模型幹活，最後把大家的成果合起來。這招最適合處理那種事先不知道要幹啥的複雜活兒，比如改程式碼時不知道要動多少檔案。跟並行不同的是，這種方式沒固定套路，全憑"老大"隨機應變。像複雜程式設計或多源搜尋這種任務比較適合。

Workflow: Evaluator-optimizer

評估者-最佳化者工作流就像一個模型出方案，另一個當評委提意見，然後迴圈改進。適合那些有明確評價標準、需要反覆打磨才能效果好的場景。有點像是我們寫畢業論文，導師不斷反饋，我們不斷修改，直到達到要求。

Agent

相比於 workflow，Agent 的設計反而是很簡單。背後依靠強大的推理模型，讓模型自己去理解複雜輸入、進行推理和規劃、使用工具以及從錯誤中恢復。

Agent在迴圈(loop)中工作，根據輸入自己選擇合適的工具，並能根據環境反饋調整策略——例如當代碼執行失敗時，能根據錯誤資訊自動修正；或根據問題性質自主決定採用sequence還是Parallel的workflow方式解決。

智慧體的核心在於模型主導全部決策過程，人類無需預先定義詳細流程，只需在特定情況下提供少量干預，如在Deep Research中我們只需要確認關鍵的資訊或在Operator中當輸入賬號密碼等敏感資訊需要人類干預。本質上，agent將複雜任務的規劃和執行權交給模型，所謂模型即服務，採用端到端的最佳化來提升效果。

Summary

最後 anthropic 的總結是：

做 LLM 專案最重要的不是構建最複雜的系統，而是為你的需求找到最合適的解決方案，建議從簡單提示開始，只在必要時才引入複雜的智慧體系統。

實施智慧體時要堅持三個原則：保持設計簡潔、確保模型規劃過程透明、精心打造工具介面並做好測試。雖然框架能幫你快速起步，但隨著專案走向生產環境，適當減少抽象層並直接使用基礎元件可能更有優勢。遵循這些原則，你將能建立既強大又可靠、易於維護且受使用者信任的智慧體系統。

對這篇部落格的看法

十分的認同，Anthropic的部落格闡述的就是 less is more 的道理，往往成功的應用都不會太複雜的真理。跟 openai 的採訪中端到端最佳化的理念是 match 的，越是通用形型的 agent 構建應越要遵循這個思路。

聊聊 Manus

最後聊聊manus，manus 的賬號我拿不到，還沒體驗過，看了些 b 站上的評測影片，原理應該好簡單，核心工作流程如下：

任務規劃 – 使用Claude 3.7等高階LLM接收使用者問題並規劃出詳細的ToDo List。
任務分發 – 透過較小模型（如Qwen）判斷每個子任務應該交給哪個專門的agent處理。
執行代理 – 主要依靠三個agent：瀏覽器操作代理（類似Operator）；搜尋API呼叫代理；編寫程式碼的 agent。
結果彙總 – 當子任務完成後，任務彙總生成器（估計用的也是Claude）讀取ToDo List和各子任務結果，整合為最終輸出。

來自寶玉老師《Manus 的護城河在哪裡？》：https://mp.weixin.qq.com/s/ji1YlVNarMfNCF3Fo6BwfQ

從技術角度看，Manus 其實沒什麼真正的護城河。它的架構說白了就是 workflow 和 agent 的組合：前面做任務規劃和最後總結是 workflow 那一套，中間執行各個子任務就是靠獨立 agent。

通用型 agent 面臨兩大難題：

得把 OpenAI 那套端到端最佳化做到極致，這需要特別強的基模、高質量資料和穩定的強化學習演算法
通用就意味著在專業領域上洞察深度和效率比不過垂類的agent，這是先天限制

雖然技術門檻不高，但產品體驗本身也能成為競爭力。當各家產品效果都差不多時，就看誰給使用者的體驗更好了。只要 Manus 能：

做出好用的產品體驗
建立起使用者反饋改進的飛輪
先一步佔領通用 agent 市場

這樣的策略其實挺合理的。

最終，怎麼樣的 Agent 能脫穎而出

做個不嚴謹的預測，僅供討論

短期預測

在短期內，基於行業經驗並結合微調的 Workflow 方案仍將佔據主導地位。這一判斷的依據是，即使是強如 OpenAI 等頂級機構開發的接近通用形態的 Operator 和 Deep Research，也遠遠未能達到直接應用的效果。具體原因如下：

推理模型有待發展：當前的推理模型，如 gpt-o3 和 deepseek-R1，仍存在一些問題。例如，幻覺問題尚未解決，且在一些高難度的 benchmark 上，其分數也未達到優秀水平。Deepseek號稱 R2 將在效能上大幅提升，側面證明現在的 R1 還有好大的提升空間。
強化學習方法仍需探究：目前，強化學習被認為是構建強大效果和泛化性的核心。然而，如何構建高質量的強化學習資料集，以及選擇何種強化學習演算法，這方面的論文研究好像比較少。例如，Deepseek 採用的是 GROP 演算法，kimi1.5 採用的是線上策略映象下降的變體，而 OpenAI 則採用 PPO 演算法，不同機構選擇的演算法各不相同，這側面證明還沒探索出最佳實踐。
業務場景尚在探索階段：不同行業和應用場景對 Agent 的需求存在較大差異，需要時間來積累行業經驗。

長期預測

從長期來看，端到端訓練的 Agent 將逐漸崛起，成為主流。因為，端到端訓練的 Agent 更符合 Agent 的本質形態，即模型能夠在 in a loop 中自主處理問題，具有更高的上限。以包含 4 個子任務的串聯任務為例，即使每個子任務的成功率為 95%，那麼整體的成功率也僅為 81%。相比之下，端到端訓練的單個模型，結合超高質量的資料+強化學習，是有望將整體成功率提升至 95%。基於這一趨勢，未來可能出現以下情況：

頂級的 Agent 可能工程程式碼及其簡潔，所謂模型即服務：這種簡潔的背後，是超高質量的訓練資料+極致的端到端強化訓練。所有 if-else 和 workflow 的選擇將由模型自身判斷完成，而非依賴人工編寫的規則程式碼。
通用 Agent 更有可能在 Openai 這種公司出現：通用型 Agent 的研發需要強大的基模和經驗豐富的強化學習工程師。因此，像 OpenAI、Anthropic、DeepSeek 這樣的搞基礎模型公司的更具優勢，更有可能率先推出通用型 Agent。想想其它公司，假如能o3這些基模都拿不到的情況下，又怎麼微調出超強泛化性的模型呢？基本沒可能。其他公司更有可能在垂直領域找到發展機會，透過專注於特定行業或應用場景，實現差異化競爭。

對於應用型演算法工程師的啟發

相信不會多久，老闆就會讓各位演算法工程師做一些agent，畢竟現在的市場這麼焦慮，應用型工程師嘛，就是為了用演算法解決實際問題，這裡聊聊應用型演算法工程師怎麼在這波 agent 浪潮中發育。

積累場景測試集，持續測試新的模型。多積累業務場景測試集或自己感興趣的測試集。當新的模型出現時，利用成熟的測試框架快速驗證其效能和適用性。新模型層出不窮，而且現在好多都是付費營銷啦～只有多測試，才能做到心中有數，應對自如。
學會微調，積累微調insight。要取得好的效果還是需要微調。無論是SFT還是RL，日常閱讀論文時，要重點關注論文中資料的構建和實驗思路。雖然現在有如llama_factory、openrlhf等微調框架，讓微調變得簡單，但工程師更重要的是積累微調的insight。例如，何時需要微調，何時透過改prompt即可解決問題；如何構建高質量資料集，怎麼讓業務同事也心甘情願幫你標資料，多少資料能達到什麼效果；何時使用SFT，何時使用RL。這些除了透過閱讀論文獲取一些方向思路外，更重要的是在自己的業務場景中多嘗試。
工程實踐中避免過度設計。遇到新場景時，優先考慮“做減法”，而非“加積木”。例如，你開發了一個演算法應用，一段時間後產品經理提出需要處理一個邊緣情況，此時你不應優先考慮疊加新的處理模型或增加模型，而是：檢視新出的模型是否能解決該情況，並簡化之前的流程。這對應第一點，積累場景測試集，持續測試新的模型；基於對業務和資料的理解，嘗試透過高質量業務資料+微調的方式解決問題，甚至合併之前的流程。這對應第二點，學會微調，積累微調經驗。
選擇與大模型協同發展的方向儘可能選擇那些隨著大模型的升級，應用效果會變得更好的解決方案，而不是做那些更強大的模型出來後之前的努力就白費的解決方案。
靈活運用workflow與端到端最佳化對於能夠快速透過workflow達到交付要求的場景，直接使用工作流即可。所以工程師還是需掌握各類框架，以快速靈活應對不同需求。但如果是一個長期需要不斷最佳化的應用，那麼請考慮一下采用端到端最佳化的形式。