当前位置：首页 > news >正文

动手学Agent：Agent设计模式——构建有效Agent的7种模型

news 2025/9/17 13:32:11

Agent本身的定义也不是绝对的，从LLM到最高等级的Agent，中间是有大量灰度地带的，在Anthropic看来，Agent可以以多种方式定义，有些人将完全自主系统定义为Agent，而另一些团队则将预定义的工作流程定义为Agent。在Anthropic，所有这些变种都定义为Agent系统（Agentic System）。

Workflow和Agents的区别：

Workflow：LLMs和工具通过预定义的代码路径编排的系统，也就是用户输入后，它的执行路径，是能够提前预料的，是有人工构建的，像基于Coze、Dify、n8n等平台搭建的应用，绝大多数属于这一类
Agents：LLMs动态指导自己的流程和工具使用，典型的，比如Cursor、Windsur、Claude Code这种编程智能体，你发送指令后，后续它会先向你做一些澄清、帮你开始编写一份技术文档还是调用MCP工具来获取一些API使用说明等，没人能确切地知道其执行路径

为什么上一篇介绍完“正统”的Agent设计模式后，这一篇还要介绍一些Workflow呢？这是因为当前落地的绝大多数Agent仍以Workflow形式为主，它有三大显著的优势：

上手很快，门槛比较低，即使没有学过编程，也能拖拽出一个可以用的应用
不同场景有自己固定的成熟流程，使用Workflow是将这些流程融入AI非常低成本的方式
试错成本低，熟悉基本概念后，对于一个不太复杂的场景，一两天就能用Coze、Dify之类的搭建出看起来像样的应用，而构建高度自主化的Agent，则周期长、成本高

Anthropic在原文的多个地方强调寻找尽可能简单的解决方案，这也确实是一个非常务实的建议，毕竟，在没有清晰实现路径的情况下，小步快跑才是更优选择。

1 何时该使用与不该使用Agents

使用LLMs构建应用程序时，建议尽可能找简单的解决方案，仅在需要时增加复杂性。这意味着可能根本不需要构建Agent。Agent系统通常以高延迟和高成本为代价来获得更好的任务性能。

当需要更高的复杂性时，Workflow为定义明确的任务提供可预测性和一致性，当需要大规模的灵活性和模型驱动的决策时，Agents是更好的选择。但是，对于大多数应用，使用检索和In-Context样例优化单个LLM就足够了。

2 代理系统的常见模式

这部分从基础构建块——增强LLM开始，逐步增加复杂性，从简单组合的工作流到自主代理。

2.1 增强LLM

通过检索、工具、记忆等模块来增强LLM

在这里插入图片描述

2.2 链式调用

这种模式由一系列Prompt + LLM串联成链式结构组成，链可以将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输出，可以对任何中间步骤添加检查（下图中的Gate）

适用模式的样例：

生成营销副本，然后将其翻译为不同的语言
编写文档的大纲，检查大纲是否满足特定条件，然后根据大纲编写文档

2.3 路由模式

将输入分类，然后将其定向到后续的任务。

对于有些输入，优化一种类型的输入可能会损害其他输入的性能（跷跷板），这种情况适合使用这种模式。

适用这种模式的样例：

将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具中
将简单/常见问题路由到较小的模型，将困难/不寻常的问题路由到更强大的模型，以优化成本和速度

2.4 并行化

这种模式适合同时处理多个任务，并以编程方式聚合其输出。

当任务可以并行以提高速度时，或者需要多个视角或尝试以更高的置信度结果时，这种方式比较有效。

对于有多个考虑因素的复杂任务，将每个考虑因素都由单独的LLM处理时，通常效果会更好。

适用这种模式的样例：

聚合
- 实施查询护栏，其中一个模型实例处理用户查询，另一个检查用户输入是否存在不当内容
- 自动化评估，每个LLM调用评估模型在给定Prompt下性能的区别
投票
- 使用不同的Prompt检查代码是否存在漏洞
- 评估给定的内容是否不合适，不同的Prompt评估不同的方面或者要求不同的投票阈值来平衡误报和漏报

2.5 编排器-Worker

在这种模式下，中央LLM会动态分解任务，然后将其委派给worker LLMs，并合并结果。

这种Workflow适合无法预测所需子任务的复杂任务（例如，在编码过程中，需要修改的文件数量和每个文件要修改的内容很可能依赖于任务）。

它和并行模式虽然在拓扑结构上类似，但主要的区别是灵活性——子任务不是预定义的，而是编排模块根据特定输入确定的。

适用这种模式的样例：

每次对多个文件进行复杂更改的编码产品
涉及从多个来源收集和分析信息以查找可能的相关信息的搜索任务

2.6 评估-优化模式

在这种工作流中，一个LLM调用负责生成，而另一个LLM调用在循环中提供评估和反馈。

当有明确的评估标准，并且迭代优化提供可衡量的价值时，此工作流特别有效，这种模式已经有自主Agent的雏形了，把Evaluator部分加上环境反馈，这基本上就跟上篇文章介绍的ReAct很像了。

适用这种模式有两个判断标准：

反馈可以由人类清晰表述时，LLM的输出根据反馈可以明显得到改善
LLM可以提供这样的反馈

这类似人类作家在制作精美的文档时可能经历的迭代协作过程。

适用这种模式的样例：

文学翻译，其中有细微的差别，翻译LLM最初可能无法捕获到，但评估LLM可以提供有用的批评
复杂的搜索任务，需要多轮搜索和分析以收集全面的信息，评估LLM可以决定是否需要进一步搜索

下面是使用Dify搭建的一个反思翻译的流程，也就是吴恩达之前开源的反思翻译项目的Dify实现：

下面是实际翻译效果，从翻译结果来看，反思翻译质量明显是高于初始翻译的。

2.7 Agents

随着 LLM 在关键能力（理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复）方面的成熟，人工智能正在生产中崭露头角。Agents通过人类用户的命令或与人类用户的互动讨论开始工作。一旦任务明确，Agents就会独立进行规划和操作，并有可能返回人类获取进一步的信息或判断。在执行过程中，Agents从环境中获取每一步的 “基本事实”（如工具调用结果或代码执行情况）以评估其进度至关重要。然后，代理可以在检查点或遇到阻碍时暂停，以获得人工反馈。任务通常会在完成后终止，但通常也会包含停止条件（如迭代的最大次数）以保持控制。

代理可以处理复杂的任务，但它们的实现通常很简单。它们通常只是基于环境反馈循环使用工具的 LLM。因此，清晰周到地设计工具集及其文档至关重要。