從RPA到AI Agent：五種Agent模式全解析，搭配兩個實踐項目介紹（text2SQL、流水解析）
2024年年末Anthropic公司發布那篇Building effective agents的Blog，無疑是 AI Agent的入門必讀文章之一。其中反復強調了，最成功的應用案例并非依賴復雜的框架或專業的庫，而是采用了簡單且可組合的模式，個人實踐下來，深以為然。
https://www.anthropic.com/research/building-effective-agents本篇結合個人近期的相關項目或者比賽經驗，為大家就其中的五種agent模式應用實踐做下分享，正文特意避免了過多技術細節，專注于核心概念和實際案例，可放心使用。以下 enjoy:
1、RPA、Workflow、Agent 的區別
手工整理的三種方法主要區別
1.1 RPA
在大模型出現前RPA（Robotic Process Automation）無疑是個十足的解放雙手的利器，可以把操作簡單、規則明確、大量重復的工作，按照人類的執行規則和操作過程來執行同樣的流程。對人工而言這類工作耗時耗力且容易出錯。定義看起來有點抽象，說起 IPhone 里的快捷指令、EXCEL 里的宏命令大家可能就有概念了。
再舉個例子，假設我們想按日抓取新榜微信日榜上榜賬號的數據，用RPA怎么實現？打開RPA軟件，根據操作步驟：打開新榜網站-點擊微信熱榜-復制數據-切換日期-復制數據，通過拖拽形式完成流程設置，點擊運營即可實現數據的自動獲取并保存在excel上。
影刀 RPA 系統截圖
1.2 Workflow
Workflow是通過預定義的代碼路徑，協調大語言模型(LLM)和工具的系統，相比RPA那種純線性的處理流程，workflow可以根據LLM的推理能力切換不同的運行分支，并在過程中使用預定義的工具鏈。
Dify“門診導診”工作流截圖
以Dify中的一個workflow示例“門診導診”為例，可以看到用戶按照要求輸入對應的關鍵信息后，會先嘗試提取所有的關鍵信息，如果關鍵信息不全，則使用條件分支判斷哪一項對話變量為空，如果為空則詢問用戶提供對應的信息。如果沒有空的對話變量，就推薦科室。如果有空的變量就繼續詢問/聊天。
不過這案例不太好的一點是，沒有工具調用（function calling)，大家感興趣的可以自行探索。（字節的扣子、支付寶的百寶箱、還有國外的 n8n 等都是類似平臺）。
Dify的外部工具示例截圖
1.3 Agent
agent 是指LLM能夠動態指導自身流程和工具使用，對如何完成任務保持控制權的系統。尤其是可以在DeepSeek-R1、GPT-o1等強思維鏈LLM的加持下處理更加復雜的問題，并根據反思修正不斷完善執行結果。
講到這里可能還沒太說清楚workflow和agent之間的直接區別，下面我會用些具體的例子來給大家同時對比三者間的差別。
2、5 種Agent模式梳理
這里再和大家一起先快速回顧下Anthropic在Building effective agents提到的五種agent模式，我會在必要的模式下附上相關的實踐案例。下面會從基礎構建模塊——增強型大語言模型（LLM）入手，逐步提升復雜度。
2.1 Agent 的基本模塊
Agent的底座是通過檢索、工具和記憶等功能增強的LLM，大模型通過推理能力來主動運用這些功能，比如通過介入搜索API來生成搜索查詢，選擇合適的工具以及決定保留哪些信息作為記憶后續使用。需要說明的是，一般需要根據特定用例對這些功能進行定制。
Building effective agents的Blog原文配圖
實現這些增強功能的方法有很多，可以人肉的一個個寫代碼去調用對應的 API，也可以類似 Zapier(通過GPTs 使用)、以及 Claude客戶端的 MCP（回頭出一期單獨講下）上下文協議（model context protocol）來實現。借助類似工具作為開發者只需簡單地進行客戶端實現，就能融入不斷壯大的第三方工具生態系統。
2.2 基本的 Workflow
Prompt Chaining將一項任務分解為一系列步驟，每次大語言模型調用都會處理上一步的輸出。可以在任何中間步驟添加編程式檢查（見下圖中的 “Gate”），從而 double check 確保流程仍按計劃進行。
當任務能夠輕松、清晰地分解為固定的子任務時，這種 workflow 最為理想。主要目的是通過將每個 LLM 調用的任務簡化，以犧牲一些延遲來換取更高的準確性。
出處同上
p.s. 相比于 RPA 而言，這種 workflow 仍然是多了任務分解的步驟，而不是人為定義的固定流程。
2.3 Workflow之間的選擇
路由功能先對任務進行分類，然后將其導向特定的后續任務。路由適用于復雜任務，這些任務存在明顯不同的類別，分開處理會更有效。分類由 LLM 或更傳統的分類模型來完成。比如將不同類型的客戶服務查詢（常見問題、退款請求、技術支持）導向不同的下游流程、提示和工具。或者將簡單、常見問題路由到諸如 Claude 3.5 Haiku 這樣較小的模型，將困難、罕見問題路由到諸如 Claude 3.5 Sonnet 這樣能力更強的模型，以優化成本和速度。
出處同上
舉一個最近參加金融問答系統比賽中的一個問題分類的設計。比賽的要求是構建一個金融領域的多輪問答系統，能夠根據提供的結構化和非結構化金融數據，回答用戶的各種金融問題。在 workflow 的開始先進行問題分類，然后根據三種問題分類后續執行不同的流程。
圖示為完整多輪問答系統架構，問題分類是其中的第一步
圖示為問題分類的核心處理邏輯，基于特征分析和LLM語義推理
2.4 Workflow 之間的并行
同時處理一項任務，并通過編程方式匯總其輸出結果。這種并行化工作流程主要有兩種關鍵變體：分塊處理：將任務分解為多個獨立的子任務并并行運行。投票機制：多次執行同一任務以獲取不同的輸出結果。
Building effective agents的Blog原文配圖
關于將任務分解為多個獨立的子任務并并行運行的例子，可以參考下我在 Coze 上開發的一個播客總結的項目。
Coze的個人播客總結工作流截圖
因為官方的 Speech2text 插件最長支持 15 分鐘的音頻輸入，而一個播客動輒就一個多小時，所以需要先把原始播客音頻進行分段后進行文本轉錄，然后再使用 LLM 合并轉錄的結果。
2.5 Workflow: 協調者-工作者模式
在 “協調者 - 工作者” 工作流程中，一個核心LLM會動態分解任務，將其委派給 “工作者” 大語言模型，然后綜合這些模型的結果。這個workflow非常適合處理復雜任務，特別是那些無法預先確定所需子任務的情況（例如在編程中，需要修改的文件數量以及每個文件的修改性質很可能取決于具體任務）。
Building effective agents的Blog原文配圖
盡管在架構上與并行化相似，但 “協調者 - 工作者” 工作流程的關鍵區別在于其靈活性 —— 子任務并非預先定義，而是由協調者根據特定輸入來確定。
3、案例：銀行流水分析工具的三種實現
流水分析在信貸風控領域有較為重要的作用，尤其是在當前經濟下行背景下，傳統基于稅票數據的分析可能并不能很好的反映企業的經營穩定性。換句話說，發票和納稅數據的正常，并不能代表企業的現金流是健康的。
但不同銀行的流水格式有所區別，且不同類型的數據清洗有一定的工程量。因此小的金融機構往往會選擇直接采購第三方的流水解析服務，這種外采（尤其是SaaS化的外采）在信息安全上存在潛在隱患。此外，當前息差空間不斷收窄的背景下，合理的壓降風控成本也是重要的話題。在當前LLM加持下的agent下已經初步具備了低成本、高擴展的新方法。
以下就作者業務實操中實踐的一個三階段的流水分析實現為大家做個示例說明：
3.1 第一代：RPA 流水線(效率優先)
文件上傳 → 模板匹配 → 固定規則提取 → 報表生成。
本地運行頁面，根據硬編碼規則進行單家銀行流水解析
使用本地部署的LLM根據預設風控策略生成的分析報告
適用于場景單一銀行標準化流水分析。
3.2 第二代：Workflow 引擎(靈活擴展)
多格式識別 → 規則庫匹配 → 動態清洗 → 智能校驗，內置多家銀行的解析模板，支持字段映射自助配置。
3.3 第三代：Agent 架構(動態建模)
環境感知 → LLM 推理 → 動態建模 → 自優化系統，適用未知的流水格式。
4、寫在最后
有許多框架能讓 Agent 系統更易于實現，包括LangChain的LangGraph、亞馬遜云科技的Amazon Bedrock等，這些框架簡化了調用LLM、定義和解析工具以及串聯調用等標準底層任務，讓起步變得容易。
但框架本身也會增加額外的抽象層，可能會掩蓋底層的提示和響應，加大調試難度。更需要注意的是，在簡單設置就能滿足需求的情況下，它們也容易誘使新手開發增加復雜性，舍本逐末的追求大而全（血淚史）。
MVP的開發階段，建議還是直接調用LLM的API，很多模式也只需幾行代碼就能實現。如果使用框架，務必理解底層代碼。最后附上官方提供的兩個代碼示例供大家參考，后續有機會再給大家做拆解展示。
??常見工作流和智能體的“最小實現”示例：
https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
??“Agent 使用計算機” Demo 代碼：
https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo
