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
