2024年年末Anthropic公司發(fā)布那篇Building effective agents的Blog，無疑是 AI Agent的入門必讀文章之一。其中反復(fù)強(qiáng)調(diào)了，最成功的應(yīng)用案例并非依賴復(fù)雜的框架或?qū)I(yè)的庫，而是采用了簡單且可組合的模式，個(gè)人實(shí)踐下來，深以為然。

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

本篇結(jié)合個(gè)人近期的相關(guān)項(xiàng)目或者比賽經(jīng)驗(yàn)，為大家就其中的五種agent模式應(yīng)用實(shí)踐做下分享，正文特意避免了過多技術(shù)細(xì)節(jié)，專注于核心概念和實(shí)際案例，可放心使用。以下 enjoy:

1、RPA、Workflow、Agent 的區(qū)別

手工整理的三種方法主要區(qū)別

1.1 RPA

在大模型出現(xiàn)前RPA（Robotic Process Automation）無疑是個(gè)十足的解放雙手的利器，可以把操作簡單、規(guī)則明確、大量重復(fù)的工作，按照人類的執(zhí)行規(guī)則和操作過程來執(zhí)行同樣的流程。對人工而言這類工作耗時(shí)耗力且容易出錯(cuò)。定義看起來有點(diǎn)抽象，說起 IPhone 里的快捷指令、EXCEL 里的宏命令大家可能就有概念了。

再舉個(gè)例子，假設(shè)我們想按日抓取新榜微信日榜上榜賬號(hào)的數(shù)據(jù)，用RPA怎么實(shí)現(xiàn)？打開RPA軟件，根據(jù)操作步驟：打開新榜網(wǎng)站-點(diǎn)擊微信熱榜-復(fù)制數(shù)據(jù)-切換日期-復(fù)制數(shù)據(jù)，通過拖拽形式完成流程設(shè)置，點(diǎn)擊運(yùn)營即可實(shí)現(xiàn)數(shù)據(jù)的自動(dòng)獲取并保存在excel上。

影刀 RPA 系統(tǒng)截圖

1.2 Workflow

Workflow是通過預(yù)定義的代碼路徑，協(xié)調(diào)大語言模型(LLM)和工具的系統(tǒng)，相比RPA那種純線性的處理流程，workflow可以根據(jù)LLM的推理能力切換不同的運(yùn)行分支，并在過程中使用預(yù)定義的工具鏈。

Dify“門診導(dǎo)診”工作流截圖

以Dify中的一個(gè)workflow示例“門診導(dǎo)診”為例，可以看到用戶按照要求輸入對應(yīng)的關(guān)鍵信息后，會(huì)先嘗試提取所有的關(guān)鍵信息，如果關(guān)鍵信息不全，則使用條件分支判斷哪一項(xiàng)對話變量為空，如果為空則詢問用戶提供對應(yīng)的信息。如果沒有空的對話變量，就推薦科室。如果有空的變量就繼續(xù)詢問/聊天。

不過這案例不太好的一點(diǎn)是，沒有工具調(diào)用（function calling)，大家感興趣的可以自行探索。（字節(jié)的扣子、支付寶的百寶箱、還有國外的 n8n 等都是類似平臺(tái)）。

Dify的外部工具示例截圖

1.3 Agent

agent 是指LLM能夠動(dòng)態(tài)指導(dǎo)自身流程和工具使用，對如何完成任務(wù)保持控制權(quán)的系統(tǒng)。尤其是可以在DeepSeek-R1、GPT-o1等強(qiáng)思維鏈LLM的加持下處理更加復(fù)雜的問題，并根據(jù)反思修正不斷完善執(zhí)行結(jié)果。

講到這里可能還沒太說清楚workflow和agent之間的直接區(qū)別，下面我會(huì)用些具體的例子來給大家同時(shí)對比三者間的差別。

2、5 種Agent模式梳理

這里再和大家一起先快速回顧下Anthropic在Building effective agents提到的五種agent模式，我會(huì)在必要的模式下附上相關(guān)的實(shí)踐案例。下面會(huì)從基礎(chǔ)構(gòu)建模塊——增強(qiáng)型大語言模型（LLM）入手，逐步提升復(fù)雜度。

2.1 Agent 的基本模塊

Agent的底座是通過檢索、工具和記憶等功能增強(qiáng)的LLM，大模型通過推理能力來主動(dòng)運(yùn)用這些功能，比如通過介入搜索API來生成搜索查詢，選擇合適的工具以及決定保留哪些信息作為記憶后續(xù)使用。需要說明的是，一般需要根據(jù)特定用例對這些功能進(jìn)行定制。

Building effective agents的Blog原文配圖

實(shí)現(xiàn)這些增強(qiáng)功能的方法有很多，可以人肉的一個(gè)個(gè)寫代碼去調(diào)用對應(yīng)的 API，也可以類似 Zapier(通過GPTs 使用)、以及 Claude客戶端的 MCP（回頭出一期單獨(dú)講下）上下文協(xié)議（model context protocol）來實(shí)現(xiàn)。借助類似工具作為開發(fā)者只需簡單地進(jìn)行客戶端實(shí)現(xiàn)，就能融入不斷壯大的第三方工具生態(tài)系統(tǒng)。

2.2 基本的 Workflow

Prompt Chaining將一項(xiàng)任務(wù)分解為一系列步驟，每次大語言模型調(diào)用都會(huì)處理上一步的輸出。可以在任何中間步驟添加編程式檢查（見下圖中的 “Gate”），從而 double check 確保流程仍按計(jì)劃進(jìn)行。

當(dāng)任務(wù)能夠輕松、清晰地分解為固定的子任務(wù)時(shí)，這種 workflow 最為理想。主要目的是通過將每個(gè) LLM 調(diào)用的任務(wù)簡化，以犧牲一些延遲來換取更高的準(zhǔn)確性。

出處同上

p.s. 相比于 RPA 而言，這種 workflow 仍然是多了任務(wù)分解的步驟，而不是人為定義的固定流程。

2.3 Workflow之間的選擇

路由功能先對任務(wù)進(jìn)行分類，然后將其導(dǎo)向特定的后續(xù)任務(wù)。路由適用于復(fù)雜任務(wù)，這些任務(wù)存在明顯不同的類別，分開處理會(huì)更有效。分類由 LLM 或更傳統(tǒng)的分類模型來完成。比如將不同類型的客戶服務(wù)查詢（常見問題、退款請求、技術(shù)支持）導(dǎo)向不同的下游流程、提示和工具。或者將簡單、常見問題路由到諸如 Claude 3.5 Haiku 這樣較小的模型，將困難、罕見問題路由到諸如 Claude 3.5 Sonnet 這樣能力更強(qiáng)的模型，以優(yōu)化成本和速度。

出處同上

舉一個(gè)最近參加金融問答系統(tǒng)比賽中的一個(gè)問題分類的設(shè)計(jì)。比賽的要求是構(gòu)建一個(gè)金融領(lǐng)域的多輪問答系統(tǒng)，能夠根據(jù)提供的結(jié)構(gòu)化和非結(jié)構(gòu)化金融數(shù)據(jù)，回答用戶的各種金融問題。在 workflow 的開始先進(jìn)行問題分類，然后根據(jù)三種問題分類后續(xù)執(zhí)行不同的流程。

圖示為完整多輪問答系統(tǒng)架構(gòu)，問題分類是其中的第一步

圖示為問題分類的核心處理邏輯，基于特征分析和LLM語義推理

2.4 Workflow 之間的并行

同時(shí)處理一項(xiàng)任務(wù)，并通過編程方式匯總其輸出結(jié)果。這種并行化工作流程主要有兩種關(guān)鍵變體：分塊處理：將任務(wù)分解為多個(gè)獨(dú)立的子任務(wù)并并行運(yùn)行。投票機(jī)制：多次執(zhí)行同一任務(wù)以獲取不同的輸出結(jié)果。

Building effective agents的Blog原文配圖

關(guān)于將任務(wù)分解為多個(gè)獨(dú)立的子任務(wù)并并行運(yùn)行的例子，可以參考下我在 Coze 上開發(fā)的一個(gè)播客總結(jié)的項(xiàng)目。

Coze的個(gè)人播客總結(jié)工作流截圖

因?yàn)楣俜降?Speech2text 插件最長支持 15 分鐘的音頻輸入，而一個(gè)播客動(dòng)輒就一個(gè)多小時(shí)，所以需要先把原始播客音頻進(jìn)行分段后進(jìn)行文本轉(zhuǎn)錄，然后再使用 LLM 合并轉(zhuǎn)錄的結(jié)果。

2.5 Workflow: 協(xié)調(diào)者-工作者模式

在 “協(xié)調(diào)者 - 工作者” 工作流程中，一個(gè)核心LLM會(huì)動(dòng)態(tài)分解任務(wù)，將其委派給 “工作者” 大語言模型，然后綜合這些模型的結(jié)果。這個(gè)workflow非常適合處理復(fù)雜任務(wù)，特別是那些無法預(yù)先確定所需子任務(wù)的情況（例如在編程中，需要修改的文件數(shù)量以及每個(gè)文件的修改性質(zhì)很可能取決于具體任務(wù)）。

Building effective agents的Blog原文配圖

盡管在架構(gòu)上與并行化相似，但 “協(xié)調(diào)者 - 工作者” 工作流程的關(guān)鍵區(qū)別在于其靈活性 —— 子任務(wù)并非預(yù)先定義，而是由協(xié)調(diào)者根據(jù)特定輸入來確定。

3、案例：銀行流水分析工具的三種實(shí)現(xiàn)

流水分析在信貸風(fēng)控領(lǐng)域有較為重要的作用，尤其是在當(dāng)前經(jīng)濟(jì)下行背景下，傳統(tǒng)基于稅票數(shù)據(jù)的分析可能并不能很好的反映企業(yè)的經(jīng)營穩(wěn)定性。換句話說，發(fā)票和納稅數(shù)據(jù)的正常，并不能代表企業(yè)的現(xiàn)金流是健康的。

但不同銀行的流水格式有所區(qū)別，且不同類型的數(shù)據(jù)清洗有一定的工程量。因此小的金融機(jī)構(gòu)往往會(huì)選擇直接采購第三方的流水解析服務(wù)，這種外采（尤其是SaaS化的外采）在信息安全上存在潛在隱患。此外，當(dāng)前息差空間不斷收窄的背景下，合理的壓降風(fēng)控成本也是重要的話題。在當(dāng)前LLM加持下的agent下已經(jīng)初步具備了低成本、高擴(kuò)展的新方法。

以下就作者業(yè)務(wù)實(shí)操中實(shí)踐的一個(gè)三階段的流水分析實(shí)現(xiàn)為大家做個(gè)示例說明：

3.1 第一代：RPA 流水線(效率優(yōu)先)

文件上傳 → 模板匹配 → 固定規(guī)則提取 → 報(bào)表生成。

本地運(yùn)行頁面，根據(jù)硬編碼規(guī)則進(jìn)行單家銀行流水解析

使用本地部署的LLM根據(jù)預(yù)設(shè)風(fēng)控策略生成的分析報(bào)告

適用于場景單一銀行標(biāo)準(zhǔn)化流水分析。

3.2 第二代：Workflow 引擎(靈活擴(kuò)展)

多格式識(shí)別 → 規(guī)則庫匹配 → 動(dòng)態(tài)清洗 → 智能校驗(yàn)，內(nèi)置多家銀行的解析模板，支持字段映射自助配置。

3.3 第三代：Agent 架構(gòu)(動(dòng)態(tài)建模)

環(huán)境感知 → LLM 推理 → 動(dòng)態(tài)建模 → 自優(yōu)化系統(tǒng)，適用未知的流水格式。

4、寫在最后

有許多框架能讓 Agent 系統(tǒng)更易于實(shí)現(xiàn)，包括LangChain的LangGraph、亞馬遜云科技的Amazon Bedrock等，這些框架簡化了調(diào)用LLM、定義和解析工具以及串聯(lián)調(diào)用等標(biāo)準(zhǔn)底層任務(wù)，讓起步變得容易。

但框架本身也會(huì)增加額外的抽象層，可能會(huì)掩蓋底層的提示和響應(yīng)，加大調(diào)試難度。更需要注意的是，在簡單設(shè)置就能滿足需求的情況下，它們也容易誘使新手開發(fā)增加復(fù)雜性，舍本逐末的追求大而全（血淚史）。

MVP的開發(fā)階段，建議還是直接調(diào)用LLM的API，很多模式也只需幾行代碼就能實(shí)現(xiàn)。如果使用框架，務(wù)必理解底層代碼。最后附上官方提供的兩個(gè)代碼示例供大家參考，后續(xù)有機(jī)會(huì)再給大家做拆解展示。

??常見工作流和智能體的“最小實(shí)現(xiàn)”示例：
https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
??“Agent 使用計(jì)算機(jī)” Demo 代碼：
https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo