來源：市場資訊

（來源：OpenCV與AI深度學習）

視覺/圖像重磅干貨，第一時間送達!

很多人一聽到這個問題，就開始羅列一堆技術名詞：ReAct、Plan-and-Execute、Reflection、Multi-Agent…

如果面試官繼續追問：為什么會出現這些范式？各自解決什么？本質區別在哪？項目里怎么選？，很多人可能就會卡殼了。

這些范式實際上都在解決一個問題：當任務越來越復雜時，如何讓 Agent 變得更可靠？

隨著任務從簡單的單工具調用，發展到多步驟長任務、跨領域復雜任務，再到企業級生產任務，Agent 暴露出一系列問題：長任務容易失控偏離目標、輸出質量不穩定、單 Agent 上下文窗口有限、生產環境缺乏可控性與合規性等等。

不同范式針對不同階段的核心痛點提出了解決方案，但同時也會引入新的成本和挑戰。

作為工程師，我們的核心能力不是背誦名詞，而是理解背后的權衡取舍（Trade-off），并根據實際場景選擇最合適的技術方案。

一、ReAct

一句話總結：走一步，看一步，邊想邊做。

ReAct（Reasoning + Acting）是 Agent 領域最經典、最基礎的范式，也是絕大多數 Agent 系統的起點。它解決了 Agent 領域最原始的問題：任務過程不確定，無法預先知道需要哪些步驟。

它的核心思想非常樸素：讓大模型在『思考』和『行動』之間交替進行，通過與環境的持續交互來推進任務，而不是一次性生成完整答案。

很多任務根本不是一次工具調用就能完成的，大模型無法通過單次推理預測出最終的執行路徑，必須依賴中間步驟的反饋來決定下一步動作。

比如排查接口變慢問題，我們事先根本不知道問題出在應用、數據庫、緩存、網絡還是下游服務。模型必須先查一個線索，根據結果再決定下一步查什么，像偵探一樣一步步逼近真相。

工作流程

ReAct 的核心是一個不斷循環的動態過程：

• 思考：分析當前收集到的信息與最終目標的差距，生成下一步的行動意圖。

• `行動：將意圖轉化為標準的外部工具調用參數（如 API 請求、SQL 查詢）。

• 觀察：接收外部環境或工具返回的真實數據，并將該數據注入到下一次的上下文輸入中。

簡單來說就是：先基于當前信息思考下一步該做什么，調用對應的工具執行這個行動，觀察工具返回的結果，再將結果作為新的輸入繼續思考，如此反復直到任務完成。

優缺點與適用場景

? 優點：

• 極其簡單：實現成本低，新手半天就能上手。

• 靈活性極強：能動態適應環境變化，遇到意外情況可以及時調整策略。

• 可解釋性好：每一步的思考過程都清晰可見，出了問題很容易調試和審計。

? 缺點：

• 容易迷失方向：在長任務中可能忘記最初的目標，甚至陷入死循環或重復勞動。

• 效率低 & 成本高：每一步都需要調用一次大模型，且每次調用都會攜帶之前的完整上下文，延遲和成本隨步驟線性增長。

• 缺乏全局視野：只能看到眼前的一步，可能會做出短視的決策，從而導致全局不一定最優。

適用場景：線上排障、信息搜索、探索性分析等過程不確定的任務。

二、Plan-and-Executor

一句話總結：先規劃做什么，再一步一步做。

ReAct 解決了『讓 Agent 動起來』的問題，但它的靈活性也帶來了致命缺陷：當任務變得復雜且漫長時，模型很容易在執行過程中偏離目標、重復調用工具，或者陷入過度思考的死循環。

它就像一個沒有導航的新手司機，雖然能隨機應變，但很容易走彎路甚至迷路。

為了解決長任務失控的問題，人們提出了 Plan-and-Executor 范式（規劃執行式）。

它的核心思想非常符合人類的做事習慣：在開始行動之前，先做一個全局計劃。把復雜的大任務拆解成一系列清晰有序的小步驟，然后再按照計劃一步步執行。

工作流程

Plan-and-Executor 把整個任務分成了兩個獨立階段，可由不同的模型進行處理。

• 規劃階段（通常 1 次）：深入理解用戶的最終目標，把復雜大任務拆解成清晰有序的小步驟，確定每個步驟的目標、輸入、輸出以及相互依賴關系，最終生成完整的結構化執行計劃。

• 執行階段：按照計劃依次執行每個小步驟，每個步驟可以直接調用工具完成或者用簡單的 ReAct 循環。

由于執行過程中可能會遇到『計劃趕不上變化』的情況，成熟的系統一般還會加上重規劃階段：當執行過程中發現原計劃不可行、環境發生變化或出現新的信息時，會根據最新的執行結果重新調整甚至完全重寫計劃。

在實際應用中，Plan-and-Execute 經常與 ReAct 組合使用：Planner 負責全局任務拆解，Executor 使用 ReAct 處理每個子步驟中的不確定性，中途發現問題再觸發重規劃。這就像軟件開發流程：PRD 寫得再完整，實際編碼時也會發現各種邊界條件需要調整。

優缺點與適用場景

? 優點：

• 目標感強：有明確的執行路線圖，不容易偏離目標。

• 效率更高 & 成本更低：復雜的全局規劃只需要用大模型調用一次，執行階段的子任務可以分發給更小、更快、更便宜的模型。

• 可預測性好：可以大致知道 Agent 會做什么，需要多長時間，便于進度管理。

? 缺點：

• 計劃可能過時：如果環境在執行過程中發生變化，原來的計劃可能不再適用

• 靈活性較差：遇到計劃外的情況時，調整能力不如 ReAct。

• 規劃難度大：對于非常復雜或模糊的任務，生成一個好計劃本身就是挑戰。

適用場景：寫調研報告、生成長文、遷移代碼、制定測試計劃等目標明確、步驟較多的結構化長任務。

三、Reflection

一句話總結：做完之后，回頭看看做得好不好。

ReAct 解決了 『怎么讓 Agent 動起來』 的問題，Plan-and-Execute 解決了 『怎么讓 Agent 不迷路』 的問題。但還有一個很重要的問題沒有解決：怎么保證 Agent 做的事情是對的？

無論是 ReAct 還是 Plan-and-Execute，它們都有一個共同特點：只向前走，不回頭看。Agent 執行完一個步驟之后，默認自己做的是對的，不會檢查自己做得好不好，有沒有錯誤，更不會主動修正。

這在很多場景下是不可接受的。比如讓 Agent 寫代碼，往往有很多 bug；讓 Agent 寫文章，可能有很多邏輯錯誤或事實錯誤；讓 Agent 生成 SQL，可能會有語法錯誤或邏輯漏洞。

為了解決輸出質量不穩定的問題，人們提出了 Reflection 范式（反思式）。

它的核心思想也來自人類的做事方式：先執行，再反思，后修正。 Agent 完成一個步驟或整個任務后，會站在一個旁觀者的角度，對自己的工作成果進行批判性評估，找出存在的問題和不足，然后根據反思的結果進行修正和改進。

工作流程

Reflection 的核心是一個生成 - 反思 - 修正的循環：

• 生成：根據任務要求和已有信息，生成初步的結果。

• 反思：站在第三方視角，按照預設的評估標準（如正確性、完整性、可讀性）對結果進行批判性檢查，列出存在的問題和改進點。

• 修正：針對反思發現的問題，對結果進行針對性修改和完善。

優缺點與適用場景

? 優點：

• 結果質量高：通過多次迭代和自我修正，顯著提升輸出的準確性和質量。

• 錯誤率低：能夠主動發現并糾正自己的錯誤。

• 學習能力強：能夠從錯誤中吸取教訓，不斷改進。

? 缺點：

• 速度慢：每一次反思和修正都需要額外的大模型調用。

• 成本高：大模型調用次數是其他范式的 2-3 倍。

• 可能陷入無限循環：如果反思不夠準確，可能會反復修改同一個問題。

適用場景：代碼生成、文檔寫作、復雜推理、數據分析報告等對質量要求較高的任務。

四、Multi-Agent

一句話總結：一個人做不完的活，分給幾個人一起做。

當任務的復雜度超過了單個大模型的能力邊界時，即使有了規劃和反思，單智能體仍然會顯得力不從心。一個 Agent 既要理解需求，又要查資料，又要寫代碼，又要測試，又要 Review，很容易出現上下文爆炸，也容易顧此失彼。

為了解決單智能體能力和上下文有限的問題，人們提出了 Multi-Agent 范式（多智能體協作）。

它的核心思想來自人類社會的分工協作：不要讓一個 Agent 干所有事，而是把復雜任務拆給多個具有不同專長的 Agent，通過分工協作共同完成。

常見協作模式

在現代大模型工程落地中，Mutil-Agent 主要有以下三種協作形態：

1. 指揮官 - 工人模式（最常用）

• 核心特點：存在一個明確的中央協調者（指揮官），擁有最高決策權。它負責理解全局目標、拆解任務、分配子任務給工人 Agent、匯總結果并進行最終驗收。工人 Agent 只負責執行自己擅長的具體子任務，不參與全局決策。

• 典型案例：一個軟件開發團隊，指揮官是產品經理，工人分別是前端工程師、后端工程師、測試工程師等。

流水線模式

• 核心特點：任務被拆分成多個連續的、線性的階段，每個階段由一個專門的 Agent 負責。前一個 Agent 的輸出是后一個 Agent 的唯一輸入，信息沿著流水線單向流動，沒有反饋回路。

• 典型案例：一個內容生產流水線：選題 Agent → 寫作 Agent → 編輯 Agent → 排版 Agent → 發布 Agent。

圓桌討論模式

• 核心特點：所有 Agent 地位平等，沒有中央決策者。它們通過輪流發言、交換信息、提出觀點、互相辯論的方式，共同探索問題的解決方案，最終通過投票或共識來做出決策。

• 典型案例：一個戰略決策團隊，包括市場分析師 Agent、技術專家 Agent、財務專家 Agent、風險評估 Agent。

工業實現中還需要考慮很多關鍵問題：共享狀態的存儲方式（黑板、消息總線、分布式文件系統）、沖突解決機制、并行執行支持、人類介入節點設計等。

優缺點與適用場景

? 優點：

• 能力邊界極大擴展：通過分工弱化了單個 Agent 的心智負擔，能搞定端到端的超大型復雜項目。

• 專業化程度高：每個 Agent 都可以專注于自己擅長的領域，做到極致。

• 上下文隔離：不同 Agent 維護自己的上下文，避免了單 Agent 的上下文爆炸問題

• 可擴展性好：可以通過增加 Agent 的數量來提升系統的能力。

• 支持并行執行：多個獨立的子任務可以同時進行，大幅提升效率

? 缺點：

• 復雜度急劇增加：系統設計和調試難度大大增加。

• 通信成本高：Agent 之間的通信和協調需要消耗大量資源。

• 可能出現沖突：不同 Agent 之間可能會有意見分歧或者任務沖突。

適用場景：軟件開發、企業級項目管理、復雜市場調研等需要分工協作的超復雜任務。

五、Agentic Workflow

一句話總結：預定義好步驟，模型一步一步做。

前面幾種范式都或多或少地追求 Agent 的『自主性』 ，但在真實的生產環境中，完全自主的 Agent 往往是不可接受的。生產系統最看重的是可控性、穩定性和合規性，而不是酷炫的自主能力。

教學 Demo 里，Agent 想查什么就查什么，想調用什么工具就調用什么，看起來很酷。但在真實業務里，你要考慮權限、合規、審計、成本、失敗重試、人工兜底。如果讓一個完全自主的 Agent 直接對接生產系統，它可能會調用不該調用的接口，生成不合規的話術，或者在關鍵流程里做出錯誤判斷，造成不可挽回的損失。

為了解決生產落地可控性不足的問題，人們提出了Agentic Workflow范式（工作流式）。

它的核心思想非常簡單：用規則和流程控制整體路徑，用大模型處理每個節點的具體工作。

說白了，很多生產環境里的 Agent，不是『完全自主智能體』，而是『帶 LLM 能力的自動化流程』。這并不低級，恰恰相反，這才是目前最務實的落地方向。

工作流程

1. 預先定義標準化的業務流程和執行規則。

2. 在需要智能處理的節點嵌入大模型能力。

3. 由規則引擎控制流程的流轉和分支判斷。

4. 在關鍵節點設置人工審核和兜底機制。

優缺點與適用場景

? 優點：

• 流程可控：關鍵節點可審計，符合企業合規要求。

• 容易接入：可以無縫集成到企業已有業務架構中。

• 成本更低：只在需要的地方使用大模型，避免不必要的調用。

• 穩定性高：規則和模型結合，比純模型驅動更可靠。

? 缺點：

• 自由度下降：Agent 不能完全自主決策。

• 靈活性較差：流程變更需要修改 Workflow 定義。

適用場景：客服工單處理、審批流程、數據處理流水線等具有規定流程的企業級生產場景。

六、如何選型

這些范式之間不是互斥的，而是互補和組合的關系。每一種范式都有自己最擅長解決的問題，也有自己的局限性，沒有一種范式是萬能的。

在實際應用中，我們一般也不會單獨使用某一種范式，而是會根據任務的特點，把多種范式組合起來使用。這就像構建一個軟件系統：

• ReAct 是函數調用：處理單個具體的操作，靈活但缺乏全局結構。

• Plan-and-Execute 是模塊劃分：先把系統拆分成多個功能模塊，再逐一實現。

• Reflection 是單元測試：對每個模塊的輸出進行質量檢查，確保符合要求。

• Multi-Agent 是微服務架構：把復雜系統拆分成多個獨立的服務，各司其職，互相協作。

• Agentic Workflow 是CI/CD 流水線：定義整個系統的執行流程和規則，確保穩定、可控、可審計。

常見的范式組合：

在真實的線上項目中，我們通常基于最小必要復雜度原則：能用簡單的就不用復雜的，切忌過度設計。很多人一開始就想做一個無所不能的 Multi-Agent 系統，結果發現調試困難、成本高昂、穩定性差，最后還不如一個簡單的 ReAct Agent 好用。

選型時可以問四個問題：

1. 步驟能否事先列全？能 → 偏 Plan 或 Workflow；不能 → 偏 ReAct。

2. 錯了代價多大？高 → 必須 Reflection + 自動化測試/規則，最好加人工節點。

3. 是否需要多專業角色？是 → 再考慮 Multi-Agent；否 → 單 Agent 往往夠用。

4. 合規與審計要求？強 → Workflow 為主，Agent 能力收進邊界內。

七、面試怎么答

當面試官問你 ：“說一下 Agent 的常見范式" 時，最忌諱的就是直接背名詞。你應該展現出你的工程思維和取舍觀，可以參考以下回答框架：

1. 總述演化邏輯：Agent 的常見范式不是孤立的概念，而是一條隨著任務復雜度提升逐步演化的路徑。它們本質上都是在解決同一個問題：如何讓 Agent 更可靠。

2. 逐一介紹范式：按照演化順序，對每種范式，按照它解決了前一種范式的什么問題→核心思想是什么→適用場景是什么的邏輯來介紹。

3. 強調組合關系：這些范式不是互斥的。實際系統里經常是先 Plan 拆任務，再讓 Executor 用 ReAct 執行，最后接 Reflection 做質量檢查；如果任務很復雜，可以拆成 Multi-Agent；如果要進生產，可能還需要用 Workflow 約束關鍵路徑。

4. 給出選型原則：最重要的選型原則是最小必要復雜度。能用簡單范式解決的問題，絕對不要用復雜的范式。

5. 升華工程觀：不同范式沒有絕對好壞，核心看任務復雜度、不確定性、可控性要求和成本。生產環境里，通常不是追求 Agent 越自主越好，而是把模型能力放在合適的位置，讓它在可控邊界內解決問題。

這個回答邏輯清晰，層次分明，既有概念，也有工程判斷，面試官一定會對你刮目相看。