作者 | kong

以OpenAI o1與DeepSeek R1為代表的"類Agent"模型、OpenAI DeepResearch為代表的“真Agent”模型，正在重構AI Agent的技術范式。Agentic Workflow的王座還沒坐熱，強化學習驅動的端到端Agent模型訓練已呼嘯而來。未來趨勢已指明：模型即產品，工程化Agent的命運將如何？一起來洞察全新的Agent技術范式底下的技術及演進過程，提前看到未來的模樣。

歡迎乘坐Agent漫游列車，作為AI Agent的躬身入局者，我將為你講解AI Agent的前世今生并推演一下未來。

一、時間線

我們先來回顧一下基于LLM的Agent發展時間線，LLM的實質性的起源時間只回溯到2017年的注意力機制的提出時間。

在2017年前，AI的世界一片混沌，NLP領域更是停滯在RNN和LSTM止步不前。

《人類群星閃耀時》如果有續集，我認為2017年《Attention Is All You Need》的作者應當在列，論文描述的注意力機制——Transformer架構劃破了AI世界的第二個長夜，一個嶄新的時代光速開啟。

接下來的標識性事件是GPT-3的誕生，代碼生成場景，GitHub Copilot重新定義了代碼補全。

基于GPT 3.5的ChatGPT把通過自然語言聊天的形態把大模型帶到了普羅大眾面前，超越tiktok成為增長最快的app。

GPT-4是首個參數突破萬億的大模型，在2023年，GPT-4的性能無敵，OpenAI也放慢了繼續擴大模型參數的路子，推出插件系統、GPTs等，當年業界大井噴出大量的LLM應用開發框架，CoT思維鏈，Agent理念的祖師爺ReAct都在那時候推出，OpenAI也把工具使用的能力訓練進了模型里，推出FunctionCall，這一年，可謂AI agent的白銀時代。

2024年，Agent在水底下快速發展，模型的預訓練Scaling Law好像失效了，GPT-4停滯不前，GPT-5難產，O1的出現宣告著訓練的路徑要轉向了。

2025年是后預訓Scaling Law開始生效的時間，蟄伏了兩年多的Agent得以浮出水面，而模型側也因為強化學習迎來了第二春：后訓練的Scaling Law。

二、AI Agent是怎樣煉成的

AI Agent是大模型應用的一種特定形態，在深入理解什么是AI Agent之前，我們先直觀理解一下大模型的工作方式：文本補全。

1. LLM工作的核心形態：文本補全

如下圖所示，我們給LLM發一段文本：“下面我將要講一個故事。在很久很久以前，有一個”，大模型會收到輸入后，它會返回一段文本：“小村莊坐落在群山環換之中。村子里住著。。。（省略數百字）”，然后，結束了。

這就是大模型一次工作的典型表現，對輸入的文本進行補全（Text Completion，這是為什么LLM們的接口都是completion、chat/completion的原因）。用戶輸入的部份內容，稱之為提示詞——Prompt，大模型生成的輸出的文本是生成內容——Generated Text。

整個核心形態看似簡單，一次輸入輸出。實際上提示詞與生成內容兩端分別是兩個巨大的領域：提示詞工程與模型預訓練。

通過提示詞，用戶可以讓大模型實現各種場景的文本生成任務，例如詩歌創作、語言翻譯、代碼生成、廣告文案生成等，而提示詞本身的編寫方法和質量也會影響大模型生成內容的效果，因此，如何寫好提示詞是一門綜合性的學問。另一方面，提示詞是通過自然語言來表達的，所以這也造成了大量的非AI科班出身的且非專業開發人員投入到了大模型應用的開發浪潮當中，這個群體形成了提示詞工程的陣營，我們看到的大部份LLM應用側的工作都屬于該陣營。

基于以上對LLM應用的了解，我們繼續往下一站，了解什么是AI Agent。

2. 什么是AI Agent

在業界一度有一個亂象，就是把所有基于大模型的聊天機器人都統稱為智能體即AI Agent。不管你是一個角色扮演的應用，或者通過流程編排出來的一個大模型工作流，還是可以自主決策來去使用工具做任務的真Agent，這些都統稱為AI agent，但這其實是一個誤區和懶惰。現在都說2025年是AI Agent的元年，我們很有必要去澄清一下AI Agent它到底是什么。

AI agent是基于大模型，具備記憶能力、能夠有自主推理和規劃工具的使用，從而來解決問題的智能程序。即AI Agent = 大模型 + 記憶 + 使用工具 + 自主規劃。

基于大模型意味著可以通過自然語言去交互，所以聊天是我們使用AI Agent最直觀感受到的交互方式。

三、多輪對話與記憶

有記憶能力就意味著他能記得跟你過往跟你聊天和互動的歷史，正因為如此，你昨晚和你的AI伴侶聊得火熱，第二天起來TA也不會問你，你是誰，你想干什么？

AI agent要實現記憶能力，簡單的做法就是把前序的聊天記錄附在提示詞里，但很快迎來新的問題，聊天記錄多了，很容易就導致模型上下文爆token無法繼續生成，隨后又發展出只取最近N次聊天記錄、只取與當前問題相關的聊天記錄等等手段。

單有記憶能支持人機之間進行連續的多輪對話還不夠，因為光說不練的也不能叫做Agent。

四、使用工具

所以TA必須得懂得用工具。所謂的使用工具，就是去訪問各種資源，調度數據接口等。例如，我們常見到的一種AI聊天的形態——聯網搜索，你可以把它看成一種使用工具的能力，AI把你的問題和該問題在網絡上相關的一些內容加到一起去，讓大模型給你生成答案。

話又說回來，能使用工具的就是Agent了嗎？我們來比較一下元寶聯網搜索的自動擋和手動擋。

在元寶里面，你只要勾選了聯網的手動擋，每次你提問他都會先聯網查詢再給你回答，而聯網的自動擋會先判斷你這個問題需不需要更多輔助它解決的信息，需要了再去聯網搜索，不需要他就直接回答。同樣是使用工具，但手動擋表現出來的是固定的工作模式，而自動擋做法是AI agent的模式，它有自己的自主的規劃和反思過程，這是AI Agent的另一個重要的特征。這個容后詳述。

五、Function Call

回到工具，大模型是怎樣使用工具的呢？我們都知道，大模型是一個文本模型，它只能輸出文本，所以，實際上所謂的使用工具，只是大模型在文本里說明要使用什么工具，LLM的應用程序解釋這段文本找到使用工具的信息，按照大模型的吩附來執行工具的調用，如下圖所示：

上圖中，我們在給大模型的輸入的提示詞內容包括：

• 可用的工具說明，包括工具的功能、接受的參數明細等。
• 工具的調用規范及示例，通過對工具調用的規范進行詳細說明，并使用fewshot的技術來給大模型學習一些例子。
• 用戶問題，最后是附上用戶的提問。

大模型在回復的時候，會按照提示詞中的工具調用規范返回實際的工具使用例子，在上圖中是一串json格式的配置數據，表達了要調用search_web這個工具，參數有query和limit兩個。

后來，這種教大模型如何返回工具使用命令的工作，被OpenAI率先預訓練到模型里面去了，并把這個功能叫Function Call，訓練到模型去即意味著不需要再通過提示詞指導大模型使用工具了，而只需要告知大模型你有什么工具可用即可，在OpenAI的接口中，通過tools指定可用的工具集。

再后來的事大家都知道了，主流的大模型都先后效仿openAI支持了function call。

六、MCP

MCP（Model Context Protocol)是由Anthropic(Claude母公司)在2024年底提出的一種大模型上下文模議，目的是讓Agent能夠更方便地發現和使用來自各處的工具，讓Agent能做的事情更多。最早的落地場景是在Cluade的桌面端中使用，Claude通過MCP協議對用戶計算機的文件進行讀寫和對用戶的電腦進行操作。

MCP隨著AI Agent的出圈也飛速流行起來，當前已然是一片不MCP無Agent的態勢，國內外大模型廠紛紛下場支持MCP，MCP成了事實上的Agent工具使用標準。

關于MCP與大模型Function Call的關系， 經常會被誤讀，說MCP是替代Function Call的。但實際上，Function Call和MCP兩者是不同層面的東西，甚至反過來說，是緊密配合的。如果 一個模型不具備Function Call或等價的能力，那它就用不了MCP。

Function Call是大模型返回調用工具指令的能力，MCP是Agent在工程側的程序具體執行調用工具的手段，一個是說，一個是做。

在有MCP之前，Agent收到大模型的Function Call指令后通過各種方法去調用外部的各種資源和服務的，如要自己實現讀寫文件，查數據庫，調搜索接口等等，這些方法可以千差萬別，開發過程長，成本高。

而MCP的出現，統一了工程側調用工具的規范，它服務的廠商按照MCP Server的標準提供服務，Agent的程序只需要統一使用call_tool這個MCP Client的功能來執行調用即可，一下子節省了大量的工具適配的工作。

所以，MCP不是來代替Function Call的，而是幫工程側調用外部工具提效的。Function Call是使用工具的基石能力，MCP打開了AI Agent連接世界的大門，兩者強強聯合，才是提效的真相。

七、自主規劃與反思

上面說過，只會無差別的使用工具，是不經過事先思考的行為，這種LLM應用不能被稱之為AI Agent。 自主規劃和反思甚至自我批評，是AI Agent模擬人類工作方式的體現，也是AI Agent的核心要素。

1. 規劃：思維鏈（CoT）

思維鏈（Chain of Thought，簡稱CoT；Wei等人2022年提出）已成為提升大模型處理復雜任務性能的事實上的標準提示詞技術。人們通過引導模型"逐步思考"，將任務拆解為多個更小、更簡單的子步驟，從而提供模型的輸出性能。CoT不僅將龐大任務轉化為可管理的分步流程，在DeepSeek R1這類推理模型中，還為理解模型的推理過程提供了透明化的解讀路徑。

除了思維鏈，類似的思路還有思維樹（Tree of Thoughts， ToT）和思維圖（Graph of Thoughts，GoT）。它們都對CoT進行了擴展，在特定的應用場景均有顯著的提升。但是實際應用中，CoT是絕對的主流。

2. 反思：ReAct

反思能力能讓Agent具備迭代出可用答案的可能性。Agent通常不止一次調用LLM和工具，每一次采取行動調用工具后，都需要經過反思來確定是否做好了，不夠好接下來該怎么做。

ReAct（Reasoing Acting， 由Yao在2023年提出）思考框架，它指導AI Agent通過思考、行動、觀察的循環來實成任務。Agent接到任務后的工作流程大致如下：

• 思考(thought)，要解決該問題，下一步需要采取什么行動。
• 行動(action)，大模型輸出行動指令，讓Agent調用外部工具。
• 觀察(observation)，把工具執行的結果給大模型進行觀察。
• 回答(answer)，如果工具執行的結果已能得到答案，組織語言回答。
• 如果目前得到的信息仍無法作答，進入下一次循環，繼續思考使用工具。

看起來是不是很像咱們人類的PDCA（Plan Do Check Act）的翻版？

ReAct模式是當下AI Agent領域事實上的工作模式，包括基于OpenAI Function Call實現的Agent在內的背后也是同樣的工作模式。只不過，使用內置的Function Call的方式，不需要額外提供提示詞來指導模型行動罷了。

八、為什么Agent不Work

AI Agent在大眾看到之前已經發展了兩年多，直到最近Manus的爆火才被出現在大家面前，根本原因是，Agent的可靠性不足，上限較低。所以一直還擺不上臺面，僅在有限的場景迭代和落地。

實現一個Agent不難，有開發經驗的同學，通過學習在一兩天內可以開發出一個可以運行的Agent，但要做一個可用的Agent，則還需要大量的工作。

判斷一個Agent是否可用，主要取決于具體場景的錯誤容忍度和受眾的介入程度。以AI編程為例，開發者對Agent生成代碼的預期是“規模不大的需求，代碼生成還不錯，會有問題，但可以通過反復溝通去修正，最終達到相對可接受的結果”。所以，Vibe coding這個場景火了，大量不懂代碼的開發者誕生了。Deep Research所關注的研報場景同理。

所以，當下大家能看到的生產級別的Agent，基本上都有這兩個特征：復雜度與規模較低、容錯水平高。

影響Agent在大規模復雜問題上的性能因素是幻覺和記憶管理的挑戰。

1. 一定是幻覺

大模型是一個概率模型，它生成的內容一定的概率是錯誤的，即我們常說的幻覺。

Agent執行一次任務，通常需要組合多次大模型的調用來完成工作，在總體的結果成功率上比單次的大模型調用會更加低。例如：假設平均單次調成大模型生成內容的正確率在90%，那4次組合調用后，正確率直接下降到60-70% 。

2. 記憶管理的難

當前基于大語言模型的Agent普遍面臨"記憶困境"，這種困境源于大模型自身的無狀態特性與人類認知過程中持續演進的記憶機制之間的本質差異。傳統采用簡單對話歷史堆砌的"偽記憶"實現方式，在應對需要長期記憶保持、復雜知識關聯和動態經驗積累的場景時，暴露出一系列結構性矛盾。

3. 上下文窗口的限制

當前主流大模型的上下文處理能力受限于固定長度的窗口機制（如GPT-4的32k tokens）。這種物理限制導致對話輪次或任務復雜度超過窗口容量時，必然發生歷史信息截斷，造成關鍵記憶丟失；其次，隨著上下文長度增加，模型處理效率呈指數級下降。這種矛盾在需要長期任務追蹤的場景（如連續多日項目管理）中尤為突出。

大模型廠商不斷推出支持更大size上下文的模型，截止發稿為止，最大的上下文是Meta的Llama scout 1000萬token。

4. 超長上下文的注意力有效性衰減

盡管上下的尺寸越來越大，甚至能塞下全集的哈里波特了，但是超長上下文注意力的準確性又成了另一個問題。

Transformer架構的自注意力機制雖然賦予了模型強大的上下文關聯能力，但其計算復雜度O(n2)的特性導致隨著上下文長度擴展，有效注意力的分布呈現顯著稀釋效應。根據ICLR 2023的研究成果，在16k tokens的上下文長度下，模型對前20%輸入內容的注意力權重占比超過65%，而對后20%內容的注意力權重不足8%。這種"近因偏好"現象使得早期關鍵信息容易被后續內容覆蓋，導致記憶保持的時序穩定性問題。更嚴重的是，當處理超長文檔（如百頁技術手冊）時，模型可能陷入"注意力渙散"狀態，出現關鍵信息漏讀或誤讀。

Google的BigBird和DeepSeek的NSA(Native Sparse Attention)都在致力于解決這個問題。

5. 相關記憶的準召問題

既然暴力的強塞所有的聊天記錄不行，那就換一種思路吧，只取跟當前問題有關聯的聊天記錄總可以了吧？我們把聊天記錄存在向量數據庫中，通過向量檢查召回關聯的內容，實現按需注入歷史。

然而，向量數據庫的召回也是一個龐大復雜的工程（RAG中的R），召回數據的準確與否，直接決定了大模型回答的質量。為了提升準召率，RAG一路發展到基于知識圖譜的RAG，又到了今天的Agentic RAG，仍然沒有到頭。

有辦法！

方法總比問題多嘛，既然知道agent面臨著怎樣的挑戰，就給出針對性的解決方案吧。為了提升agent的性能，業界提出了各種解決方案，總結起來有3大類。

• 引入workflow，使用固化的工作流程來提升確定性，但同時犧牲掉靈活性。
• 在ReAct框架的基礎上做工程側的極致優化
• 引入多agent，效仿人類團隊協作，突破單agent的極限，發揮群集智慧。

九、workflow的第二春

AI Agent不穩定？那我們來固化工作流程，讓AI在必要的時候工作就好？這個解題思路引出了AI workflow的技術形態。

從技術演進視角來看，Workflow本質上是將低代碼開發框架與LLM相結合的產物，舊瓶裝新酒。其在大模型時代的流行主要源于兩個關鍵因素：首先，當前開發范式已從傳統編碼轉向提示詞工程，開發者需要高頻迭代提示詞而非底層代碼；其次，可視化流程編排顯著降低了調試門檻，使非技術背景人員也能通過直觀界面完成AI能力集成。

現有Workflow更多是業務邏輯的標準化封裝，AI僅作為模塊化組件服務于特定環節。這種架構雖提升了開發效率，但也存在本質局限——既無法實現智能體（Agent）的自主推理能力，也難以支撐復雜場景的端到端智能化。

簡單來說，workflow本身不是AI Agent，但基于workflow實現的功能可又作為Agent的工具，作為Agent的有機組成部份。

十、Beyond ReActAgent

之前說過ReAct Agent是當下主流Agent的思考與行動框架，但ReAct本身也有著很多的缺點：

走一步看一步，缺乏全盤規劃。每次的思考與決策需要依賴上一次工具的輸出結果。

串行調度工具，每次工具調用都跟隨著一次LLM的調用，沒能靈活高效的對工具的調度進行優化。

所有工具的執行結果，都會追加到大模型的上下文中供觀察使用，經過多次的工具調用來回后，很容易就觸發上下文限制，任務以失敗告終。

針對這些缺點，業界的優化方式也是五花八門，以下舉一些代表性的例子：

1. plan and execute

該思路主要受到Plan-and-Solve論文和Baby-AGI項目的啟發，其核心工作流程包含三個階段：

• 規劃階段 ：首先生成一個全盤的多步驟的詳細行動計劃
• 執行階段 ：按順序執行每個計劃步驟，返回結果
• 重規劃階段：根據執行結果動態調整計劃或返回

這種模式引入了全盤規劃，且子任務的執行分拆到Single-Task Agent上執行，避免了Token在同一個LLM會話上下文中堆積，降低爆Token的可能性。

manus的Agent顯然是借鑒了這種Agent，先生成任務的清單，再對著清單逐個執行，但似乎并沒有看到manus有重新規劃這個步驟。

2. ReWoo

ReWOO（ Reasoning WithOut Observation ）是一種創新的增強語言模型（ALM）框架，旨在通過 模塊化設計 顯著提升多步推理任務的效率與性能。傳統ALM（如ReAct）依賴交替的“推理-工具調用-觀察”流程，導致大量上下文重復輸入和計算資源浪費。ReWOO突破性地將任務分解為三個獨立模塊：

• Planner（規劃器） ：基于大型語言模型（LLM）的推理能力，預先生成任務藍圖，規劃多步推理路徑（如調用工具的順序與邏輯），無需等待工具實時反饋。
• Worker（執行器） ：根據藍圖并行調用外部工具（如搜索引擎、計算器、數據庫），高效收集證據。
• Solver（求解器） ：綜合規劃與證據生成最終答案，具備糾錯與總結能力。

ReWOO最顯著的特點是擁有一個獨立的Solver（求解器）模塊，專門負責綜合規劃結果和工具執行證據，生成最終答案。在worker的執行過程中， ReWOO不去觀察（Observation）工具返回的結果，可以減少token的使用及調用LLM的次數。

ReWOO與Plan and Execute相比有兩個差異：

• worker的任務執行更多是工具執行，不需要額外的LLM來驅動。
• 沒有重新規劃的過程。

3. LLm Compiler

LLMCompiler專為優化大語言模型（LLM）的多工具協作效率而設計的框架。針對傳統方法（如ReAct）因順序執行函數調用導致的延遲高、成本大、準確率受限等問題，LLMCompiler 創新性地引入編譯器式任務編排，通過并行化與動態規劃顯著提升LLM在復雜任務中的表現。

其核心架構：

• 智能規劃器（Planner）：將用戶查詢解析為帶依賴關系的任務DAG，識別可并行執行的函數調用（如并行的網絡搜索與數學計算）。
• 動態調度器（Task Fetching Unit）：實時替換占位變量、分發獨立任務，最大化并行資源利用率。
• 異步執行器（Executor）：通過工具API并發執行任務，支持自定義工具（如搜索引擎、計算器、API代理）。

LLMCompiler同樣是提前做DAG規劃，它通過任務依賴關系來對任務進行并行調度，還可以根據結果進行重新規則。

十一、多Agent

人類社會有一句話“獨行快，眾行遠”，指的是如果要走得更遠，需要團隊合作。在Agent的世界，單個Agent在簡單任務方面的表達已經不錯，但復雜的以及上規模的任務中的表現卻乏善可陳。于是我們不由得去向人類的協同方式學習，讓Agent組成團隊，復刻人類的協同方式，看是否能夠提升性能。

1. 多Agent的形態

根據多Agent的應用場景，我把多Agent的產品形態分為社會協同模擬型與任務導向型 。

(1) 社會協同模擬型

類如“斯坦福小鎮”這一種agent社會化實驗性的形態，稱為社會協同模型型，這類產品不設定具體的任務讓Agent來實現，而是提供了一個開放性的運行環境，讓Agent自發地去協同和產生可能的“化學反應”，用于對Agent社會化協同的學習與研究。

(2) 任務導向型

另一種多agent的形態是目的性很明確的，有清晰的目標和標準的操作流程（SOP)，典型的代表如軟件開發過程、較大篇幅的內容（如論文、小說）等的創作。

MetaGPT是此類型多Agent的代表框架，它通過拆解軟件開發的標準流程，為每個過程設定不同的角色來完成對應的任務，最終實現一個軟件的開完任務。

十二、開發框架

• MetaGPT：基于多智能體協作的軟件開發框架，通過模擬軟件公司角色分工（產品經理/工程師等），將標準操作程序（SOP）編碼為智能體協作流程，支持從需求分析到代碼生成的全生命周期自動化開發，尤其擅長結構化輸出文檔與代碼。
• AutoGen：微軟推出的多智能體對話框架，支持定制化代理角色與自然語言交互，通過模塊化設計簡化復雜任務編排，可無縫集成LLM和工具鏈，其核心優勢在于實現人機混合協作與自動化工作流，特別適合需動態決策的場景。
• CrewAI：開源協作型智能體框架，強調角色扮演與團隊化任務管理，支持自定義代理角色、任務委派及流程控制（順序/層級模式），提供工具集成與知識沉淀機制，適合構建需要明確分工的多代理協作系統（如市場分析/項目管理）。
• Swarm：OpenAI實驗性輕量級框架，聚焦智能體間的動態任務交接（Handoffs），通過函數調用實現執行權轉移，保持高度可控性與透明性，與Chat Completions API深度整合，適合需細粒度控制的小規模多代理交互場景。

當然，langchain和langgraph這類框架同樣是可以用于搭建多agent的，沒把它們列在上面僅僅是因為這兩個框架它的普適性更廣，不是專為多agent而專門提供的。

1. 協同架構

langgraph把多Agent的協同架構做了一下匯總，除了自定義架構，大致有以下幾種類型：

• Network（網狀），網狀架構允許每個Agent間互相通訊，該架構的自由度高，但可控性差，適用于社會協同模擬型的Agent形態。
• supervisor（監督者），該架構有一個管理者Agent，其他所有Agent之間不能直接溝通，只能與管理者Agent進行溝通。這種架構適用于對任務導向型的多Agent形態，可控性較高，但管理者Agent的智能程度會成為整個多Agent網絡的瓶頸。

a. supervisor的結構看起來還跟單Agent的結構很相似，實際上，把非管理者Agent看成一個個工具的話，它就等同于一個單Agent，即圖中的supervisor(as tools)的結構。

b. 所以，多Agent并不神秘，你在以前做單Agent的時候極有可能就已經實現過as tools這種supervisor架構的多Agent應用了。上面"plan and execute"中描述的形態也可以視為一種多Agent。

Hierarchial（層級監督者），層級監督者是由多個監督者網絡進行堆疊而成的，如果把監督者網絡看成一個小組由一個組長帶領多個組員，那層級監督者網絡則更大的的組織，例如是一個中心，甚至是部門，業務線等。

十三、Agentic Workflow

agentic workflow最早由吳恩達提出。簡而言之，它的目標是解決復雜任務，通過分解任務、多角色Agent協同、迭代改進的手段來實現。它有以下四大機制：

• 工具調用(Tool Use)
• 多 Agent 協作（Multi-agent）
• 規劃能力（Planning）
• 反思機制（Reflection）

光看上面的描述，定義是相當的模糊的，我們拿上文中出現過的LLM應用和Agent來對比一下，以便進一步理解agentic workflow。

1. 與“plan and execute“ agent的區別

上面講的Plan and Execute形態的Agent看起來就具備”分解任務”、 “子任務執行Agent”、“迭代改進”等等環節，其中子任務執行Agent是一個通用的執行者，負責遍歷任務并執行。

而Agentic workflow對任務執行的要求是由不同角色的Agent來執行不同性質的任務，哪個角色應該執行什么任務。

所以，如果把plan and execute模式升級一下，定義多個特定職能的Agent作為子任務的執行者，有針對性的選擇任務來執行，可以得到近似agentic workflow的效果。

2. 與workflow + LLM的區別

它和“workflow的第二春”中說的workflow + LLM又有什么區別呢？從幾個維度來對比：

(1) 動態規劃能力

Agentic Workflow：通過 AI Agent 的推理能力動態分解復雜任務（任務分解模式），并根據環境反饋調整執行路徑。

Workflow + LLM：LLM 僅作為靜態模塊嵌入預定義流程。

(2) 自我迭代優化

Agentic Workflow：引入反思模式（Reflection），通過執行結果評估和策略校準形成閉環。

Workflow + LLM：缺乏反饋循環，輸出質量依賴單次提示效果，無法自我優化。

(3) 執行主體性質

Agentic Workflow：以 AI Agent 為核心，具備長期記憶（如向量數據庫存儲用戶畫像）和工具調用權限（如 API、搜索引擎），形成類人認知架構。

Workflow + LLM：LLM 作為流程中的“工具人”，僅處理特定環節（如文本生成），無自主決策權。

(4) 任務協作模式

Agentic Workflow：支持多 Agent 協同（如數據分析 Agent 與優惠優化 Agent 聯動），通過信息傳遞形成集體智能。

Workflow + LLM：流程由人工預先編排，各模塊獨立運行，缺乏動態協作。

(5) 小結

Agentic Workflow是由AI Agent集體動態生成并可隨機變動的協作流程，而workflow + LLM中的workflow是一種由開發者定義的靜態工作流。

3. 示例分析

下圖所描述的是一個通過CrewAI實現的多agent智能化的客戶優惠推薦系統。

藍色部份是定義了一種工作流程及每個節點的任務：

• 提取購買記錄：基于用戶ID和時間范圍查詢數據。
• 匹配最優優惠：通過SQL連接（JOIN）購買記錄與優惠表，按折扣排序。
• 生成通知文案：整合優惠信息，添加表情符號，生成吸引人的消息。

綠色部份是定義了三種不同職能的Agent：

• 購買歷史分析Agent：編寫SQL查詢客戶購買記錄。
• 優惠管理Agent：結合購買歷史與優惠表，篩選最優折扣。
• 創意文案Agent：生成個性化優惠通知。
• 工作流程：CrewAI框架協調Agent們執行任務，輸出最終優惠通知。

CrewAI在任務的調度模式上有兩種，一種順序執行(sequential)，一種是層級模式(hierarchical)，后者由一個管理者LLM來動態調度執行。

竊以為hierarchical模式才是真正意義上的agentic workflow，因為工作流是動態的，可通過反思機制進行實時調整的，是由管理者LLM來自主決定的。而順序執行的模式，和workflow + LLM的模型沒有本質的區別。

4. Why Do Multi-Agent LLM Systems Fail?

多Agent看起來很美，但在實際的落地過程卻也有一地雞毛的時候，加州大學伯克利分校等機構經過研究發表的《Why Do Multi-agent LLM Systems Fail》的論文指出了多Agent架構失敗的原因：

(1) 系統設計與規范問題（占37.2%）

• 核心問題：架構設計缺陷、角色定義模糊、對話流程管理不當。
• 違反任務規范：智能體未遵循任務約束
• 角色越權：智能體超出職責范圍（如CPO擅自定義產品愿景）。
• 步驟重復：冗余步驟導致效率低下。
• 對話歷史丟失：上下文截斷引發邏輯斷裂。
• 終止條件不明確：無法判斷任務何時完成。

(2) 智能體間協作錯位（占31.4%）

核心問題：溝通機制低效、信息共享不足、協作流程失控。

• 對話重置：意外重啟對話導致進展丟失。
• 信息隱瞞：關鍵數據未共享（如手機代理未告知API格式要求）。
• 任務偏離：討論偏離核心目標（如32%的任務因跑題失敗）。
• 推理-行動不匹配：邏輯推理與執行行為矛盾。

(3) 任務驗證與終止問題（占31.4%）

核心問題：驗證機制缺失或低效、過早終止任務。

• 過早終止：未完成必要步驟即結束（如棋類游戲未驗證規則）。
• 驗證不完整：僅檢查表面問題（如代碼編譯通過但功能錯誤）。
• 錯誤驗證：驗證邏輯存在缺陷（如接受非法棋步輸入）。

從智能體間協作錯位中可以看到，多agent不僅復刻了人類協同的形態，還把人與人溝通的壞毛病也學習了，會隱瞞，跑題和知行不一。

十四、中場戰事，推理“類Agent“的崛起

上面工程側為了Agent輸出更好的性能，想盡了辦法極致壓榨。模型側也沒閑著，也一直在探尋著新的Scaling Law。

OpenAI推出了推理模型O1，它的工作方式是在輸出內容前先進行一次內部思考(推理)，然后再基于思考的結論來組織回答。這種分段式的生成像極了agent的工作方式，所以，我對O1的第一反應是openAI搞了個推理的agent？大模型Scaling Law到頭了，改搞工程agent了？后來看到技術實現才得知O1是強化學習的產物，O1仍然是一個模型，但它像agent一樣工作的模式以致我在后來把它們稱為"類agent"模型。

1. 猶抱琵琶半遮臉的O1

O1剛出來的時候，推理的過程是完全不可見的，一個Loading轉了幾分鐘看不到里面發生了什么。OpenAI是這樣解釋原因的：

• 技術權衡：思維鏈的忠實性和可讀性是監控模型推理過程的前提，但若在思維鏈上加入政策合規性或用戶偏好的訓練，會破壞其有效性。因此，OpenAI選擇不向用戶展示原始思維鏈，以避免潛在的干擾。
• 競爭優勢：隱藏推理細節可保護核心技術不被競爭對手模仿，尤其是在模型邏輯推理能力顯著超越同行的背景下。
• 用戶體驗優化：原始思維鏈可能包含冗長且復雜的中間步驟，直接展示會影響交互效率。OpenAI轉而提供模型生成的思維鏈摘要，以更簡潔的方式呈現推理結果。

2. 掀桌子的DeepSeek R1

DeepSeek是配得上偉大這樣的贊譽的。

DeepSeek R1以更高的性能、低一個數量級的成本、開源的方式打臉了O1，掀翻了桌子。R1發布即公開了推理過程思維鏈的全部內容。DeepSeek成了真正的“OpenAI”。

(1) DeepSeek公開了R1的訓練技術細節：

R1-Zero版本完全摒棄監督微調，通過多目標強化學習（創新的GRPO算法）整合準確性、推理速度與資源消耗指標。其中GRPO算法可以降低對標注數據的依賴，大大降低了訓練成本。

(2) 但由于R1-Zero存在思維鏈的可讀性問題，在R1的正式版的訓練時，分拆成了兩次的SFT+RL的步驟：

• 加入了一些冷啟動數據（思維鏈內容）對V3進行有監督微調，再強化學習得到較好的思維鏈可讀效果；
• 基于上一個Checkpoint模型生成60萬條思維鏈內容再加上20萬條生成的的示例數據進行監督微調，最后通過強化學習進行對齊得到R1。

過程如下圖所示：

3. 強化學習是后訓練的Scaling Law

如果拋開思維鏈的可讀性不談，R1-Zero已經是一個高性能的推理模型，在Zero的訓練細節上我們看到只需要強化學習就夠了。R1-Zero向我們傳遞了一個最重要的信息：有針對性的強化學習訓練的效果可能優于單純增加大模型參數量做預訓練的效果，這也是OpenAI O1背后的秘密。OpenAI看起來已經放棄了更大規模參數預訓練模型的路子，而全面轉向了后訓練+強化學習，強化學習是新的Scaling Law。

強化學習，它不算是一種新技術了，它原理是通過生成結果對模型進行的獎勵和懲罰反饋，讓模型在無數次的生成和反饋中調整和優化并找到最有效的工作方式，而不需要教模型怎么做。

O1首先驗證了新的訓練路徑，R1把全部的細節公諸于眾，一時間，強化學習訓練成了大模型廠商們的Next。Claude sonnet 3.7跟上了節奏推出推理版，并針對復雜的代碼問題進行了強化學習，在生成代碼方面性能較sonnet 3.5有顯著提升；openAI 推出的DeepResearch就是基于O3端到端訓練的Agent模型。

4. 產品的R1“后遺癥“

DeepSeek R1在2025年的春節期間爆火出圈，成了國民級的AI應用。R1的交互簡單樸素，先是輸出一大段思考過程，再生成最終的答案，輸出推理的過程讓用戶避免了漫長的等待，在正式答案出來之前，閱讀一下推理過程也是一件有意思的事。

R1的產品交互也瞬間成為了教科書級別的范例。它的兩階段輸出的形態正快速統一Agent們的輸出行為。

(1) R1前Agent輸出招式

Agent不像LLM，能快速地開始輸出答案，Agent通常有一系列的中間工作步驟，到最后一步才會輸出給用戶的答案，而這中間會有頗長的一段等待時間，為了緩解用戶在等待過程的焦慮和優化等待體現，Agent們都很努力在嘗試把中間過程也通過各種方式輸出給用戶：

例如ChatGPT是這樣的：

dify是這樣的：

我們的FoT Agent是這樣的：

然而，這些努力并沒有什么作用，Agent的用戶們對這些輸出的中間過程并不買單，抱怨看不懂，出結果又慢。

(2) R1后的統一“深度思考”

R1出來后，Agent產品們除了在模型層面光速接入DeepSeek之外，在產品交互也是象素級的致敬著R1。例如，我們的媒資助手Agent是一個基于DeepSeek V3的ReAct Agent，它把ReAct每一步思考（Thought）的過程組裝起來，偽裝成深度思考的過程，看起來毫無違和感：

還有微信讀書的AI問書、微信輸入法的問AI，底層的架構是基于小size的QWen模型做了SFT的Agent + Deepseek R1做最終解讀，而在交互層，也是把Agent的工作過程和R1的思考融合呈現到深度思考的內容里了：

不再有花哨的loading和中間步驟的結構化呈現過程，只剩下樸實無華的“深度思考”樣式的過程文本，也貌似讓原來挑剔無比的用戶滿意了，感謝偉大的DeepSeek！端的是一個大道至簡，大巧不工啊哈哈。

十五、下半場：模型即產品與Agent社會化協同

我把OpenAI的Deep Research問世看作AI Agent下半場開始的標記性事件。Agent正式進入模型內化的新階段。沿著中場戰事的推理“類Agent”模型同樣的進化路子，Deep Research基于O3通過端到端的強化學習得到了一個"真.Agent"模型。

1. 模型即產品

Deep Research這個"真.Agent"有兩個特點：

• 端到端訓練，就是它的訓練是全鏈路的，對于做研報這個場景，從拿到問題、使用網絡搜索工具、多輪驗證重做到最終輸出完整的研報的整個鏈路都在訓練范圍內。它不再像過去只讓模型針對問題只做一次的文本輸出。
• Agent模型，對，Deep Research的工作形式是一個Agent，但技術上它是以一個模型出現的。在此之前，我們基于常規的LLM也可以做Deep Research這類型的工作，那就是寫代碼開發一個Agent（大家可以看到現在有很多開源版的Deep Research），這需要在工程側來發力。但現在，OpenAI的Deep Research告訴大家，原來工程上要做的事情現在不需要了，我們只需要通過強化學習就可以讓模型本身掌握原來要用工程來控制的工作方式，同時還能達到更高的質量。即，工程復雜度沒了，效果還更好了。

對比一下O1和Deep Research:

• O1推理模通過強化訓練“推理”能力，推理能力得到了質的飛躍
• Deep Research通過強化訓練“做研報”的過程（包括使用搜索工具）和質量得到了一個做高質量研報的Agent。

嗯，AI Agent下半場的玩法變了：你想要什么樣的Agent，通過強化學習訓練一個Agent模型，而不一定要通過編寫工程代碼來實現它，而這個Agent模型就是一個產品。這就是最近流行起來的一個說法：模型即產品。說的是，未來針對場景化的產品需求，可以基于大模型通過強化學習對場景進行訓練，最終交付一個Agent模型作為產品，不再區分什么模型層，應用層，而是模應一體了。就在前兩周，OpenAI的O3也正式發布，O3表現出來的則是一個比Deep Research更通用的Agent模型。這進一步指明了Agent模型化、模應一體化的道路。

2. 工程化Agent的生存空間

如果AI Agent的下半場是面向場景的端到端Agent模型的戰場，那原來通過工程化手段做的Agent是否還有生存空間呢？答案是確定的，在接下來的一段時間內（至少兩年），三種形態的Agent會持續共存：

• 純工程Agent，即由提示詞工程加代碼實現Agent，在產品的MVP階段用于快速驗證產品，或產品流量不大，對Token成本不敏感的場景，適合用這種方式落地。它的實現門檻低，包括技術實現和成本都一樣，甚至通過當下流行的可視化Agent搭建平臺，不用寫代碼就可以快速搭建起來。
• SFT Agent，指針對Agent的行為（包括但不限規劃和反思能力等）進行了有監督微調——目的是讓指令跟隨相對更穩定、節省提示詞成本。實際上，節省提示詞成本是做SFT Agent的最大的動機，相比起提示詞token成本的下降，微調帶來的指令跟隨穩定性的提升可能沒那么顯著，這也是吳恩達一直說絕大多數Agent應用都能通過提示詞來解決的原因。所以，SFT Agent較為適用于大流量但工具需要支持動態添加的場景。
• 端到端Agent模型，即針對垂直場景，通過端到端強化學習進行后訓練的模型。它適用于大流量且需求明確垂直的場景。

Agent才剛剛進入大眾的視野，在技術和生態側，隨著MCP和A2A等協議的成熟及智能體生態的發展，Agent的進化會進一步加速，有更多的可能性在等待著我們。

3. Agent的社會化協同

以及A2A為代表的Agent間協同協議拉開了Agent社會化協同的大幕。

之前我們提的多agent和agentic workflo中的agent們的通訊，就如果我們在一個小團隊里面緊密協同那樣。而Google提出的A2A協議，把Agent之間的協同范圍一下子提升到了全球的范圍，它為每個Agent派發了身份證（AgentCard），在經過認識、握手后（鑒權），Agent們可以進行溝通和協作。

展開想象一下：

• 每個人都配套一個人個的Agent，用于代表你跟Agent的世界來交互，這個場景就很好玩了，跟朋友們約出去玩？讓咱們的Agent們先商量一下，給我們一個方案；
• 買機票？我也不需要直接用某程的平臺，只需要交代我的專屬Agent，它自動發現和跟服務商的Agent（機構Agent）來溝通并支付就OK了。
• 你看，一個賽博數字世界就這么展開了。

我愿把這種場面稱之為Agent的社會化協同，它將最大程度上復刻人類社會的形同范式，Agent間需要有驗證機制，能互相加好友，具備支付能力，能主動發起任務等等。技術上，這將有模型技術之外的海量的agent社會基礎平臺等著被搭建。包括Agent通訊的安全、信用、支付體系等等。

十六、致親愛的乘客

1. 做AI的領導者

AI正在對全行業進行無差別的顛覆，所有人都面臨著工作方式的升級。不是說有全新職業的出現，而是大部份職業都會被要求原地升級 + AI。

我們每個人都會從個人勞動者轉變成AI領導者，我們要提升自己的AI領導力。

過去，我們通過個人的專業能力來交付工作成果，個人要親自去執行具體的任務。

現在到不遠的未來，是我們帶著AI一起工作并完成目標，我們作為AI的領導者，需要對AI團隊進行目標設定，對AI協作過程進行管理和干預，對AI最終產出進行驗收。

雖然執行性的工具會逐漸交給AI，但這并不意味著對個人的專業能力不作要求了。相反，它對我們的專業能力要求更高了，因為我們需要以內行人的角度來驗收AI給我們產出的東西，減少的只是我們做具體任務的時間。

因為AI，未來可能每個行業都可能呈現出兩頭重，中間輕的形成。以軟件開發這個崗位來做一下推演。

Vibe Coding這個詞相信大家已有所耳聞，現在越來越多完全沒有編程經驗的人（暫稱為小白）通過Cursor這類AI編程工具搖身變成了開發者，這類開發者自己動手解決長尾的、相對簡單的個性化的需求，中低端的開發者的工作將會由小白們+AI來接管。但是大規模，嚴肅的生產型應用，小白 + AI也是無法掌控的，這個場景需要更專業的工程師，甚至是架構師+AI來支撐，AI一定是必備的了。可見，小白和架構師就是兩頭，初中級的工程師如果想要繼續留在這個行業，是需要進一步提升自己的專業能力和AI領導力的。

所以：全面擁抱AI吧，以最快的速度。

2. 我們的征程是星辰大海

當瓦特改良的蒸汽機轟鳴著撕裂中世紀余暉，當珍妮紡織機的梭子編織出工業文明的經緯，舊時代的質疑聲總如潮水般涌來——1830年馬車上揮舞的皮鞭在對抗鐵路鋼軌，1910年馬車夫的咒罵聲淹沒在福特T型車的鳴笛中。歷史總在證明：人類對變革的恐懼，終將被創新者的勇氣鍛造成進步的階梯。

站在AI浪潮席卷全球的臨界點，我們目睹著更宏大的技術躍遷。AlphaGo落子的清脆聲響徹人類智慧圣殿，ChatGPT的字符洪流重塑知識生產邊界，波士頓動力的機械骨骼正在突破生物運動的極限。如同十九世紀紡織女工面對蒸汽機時的惶恐，今日的焦慮不過是文明躍遷時的引力震蕩。

但請記住：馬車消亡時，人類獲得了駕馭鋼鐵的速度；紡車停轉時，世界收獲了機械紡織的精度；而當AI接管程式化勞動，我們終將解鎖更珍貴的創造力密碼。凱恩斯曾在汽車取代馬車的年代預言："我們終將學會游泳，在技術的海洋里。" 數據顯示，自動駕駛技術每年將挽救全球130萬條生命；AI醫療系統已能診斷出人類醫生難以察覺的早期病癥。

那些被技術重塑的行業，正在誕生更璀璨的新職業星辰：提示詞工程師構筑人機對話的巴別塔，AI倫理師守護智能時代的道德羅盤，元宇宙建筑師在數字空間重構文明形態。正如馬車夫轉型為汽車司機，紡織女工成為流水線技師，每一次技術革命都在創造更高階的人類價值。

不必困在技術性失業的敘事繭房，人類真正的對手從來不是機器，而是固守成規的思維慣性。當NASA用AI分析億萬光年外的星云數據，當腦機接口幫助漸凍癥患者重獲交流能力，我們分明看見：智能革命正在拓展人類探索的邊疆。

心存焦慮時，請回望文明長河中的燈塔——蒸汽機沒有埋葬人類，電力沒有禁錮光明，互聯網更未終結真實。我們的征途注定是星辰大海，在算法與神經元共舞的新紀元，唯有保持認知的流動性，在持續迭代中鑄造不可替代性，方能在技術洪流中錨定航向。正如航海者從不詛咒潮汐，真正的勇者會將AI化作駛向星海的方舟。（by Deepseek）