【AI大模型】关于什么是Agent、如何构建Agent，最近最值得读的文章（没有之一）

“Agent”的定义多种多样。一些客户将 Agent 视为完全自主的系统，能够在长时间内独立运行，利用各种工具来完成复杂的任务。另一些客户则用这个词来描述遵循预定义工作流程、更具规范性的实现。在 Anthropic，我们将所有这些类型都归为agentic systems，但在架构上，我们会对工作流和 Agent 做出重要的区分：

嘴巴吃糖了

1042人浏览 · 2025-01-22 10:30:19

嘴巴吃糖了 · 2025-01-22 10:30:19 发布

前言

这篇文章是Claude官方文章，特别推荐！！

感觉对于Agent是一个非常好的科普。

AI Dancer团队特翻译如下，请大家参考。

内容比较长，可以收藏慢慢看哦~

过去这一年，我们和许多团队一起，在各个领域开发 LLM agent。说来也有意思，那些最成功的项目，靠的都不是什么复杂的框架，或者特别的什么库，而是一些很简单的、可以灵活组合的模式。

在这里，我将分享从与客户交流和亲身实践中所获得的经验，也为开发者朋友们，提点实在的建议，帮你们做出真正有用的 LLM agent。

什么是 Agent？

“Agent”的定义多种多样。

一些客户将 Agent 视为完全自主的系统，能够在长时间内独立运行，利用各种工具来完成复杂的任务。

另一些客户则用这个词来描述遵循预定义工作流程、更具规范性的实现。

在 Anthropic，我们将所有这些类型都归为agentic systems，但在架构上，我们会对工作流和 Agent 做出重要的区分：

工作流是由预定义的编码路径来编排 LLM 和工具的系统。
另一方面，Agent 则是 LLM 动态指导自身流程和工具使用的系统，它们掌控着自己完成任务的方式。

下文中，我们将详细探讨这两种 Agentic 系统。在附录 1（“Agent 的实际应用”）中，我们介绍了客户在哪些领域发现了这类系统的特殊价值。

注：本文按照通俗易懂的语言进行翻译，如有不懂，可用AI工具转化为更加通俗易懂的语言，我们在结尾附prompt。

何时（以及何时不）使用 Agent

在使用 LLM 构建应用时，我们建议尽可能找到最简单的解决方案，只在必要时才增加复杂性。

这意味着，有时甚至完全不需要构建 Agentic 系统。Agentic 系统通常会牺牲一定的延迟和成本来换取更好的任务性能，你需要仔细考虑这种权衡是否值得。

当确实需要更复杂的方案时，对于那些定义明确的任务，工作流能够提供可预测性和一致性；而当需要大规模的灵活性以及模型驱动的决策时，Agent 则是更好的选择。

不过，对于许多应用来说，通过检索和上下文示例来优化单个 LLM 调用，通常就已经足够了。

何时以及如何使用框架

有许多框架可以简化 Agentic 系统的实现：

LangChain 的 LangGraph；
Amazon Bedrock 的 AI Agent 框架；
Rivet，一个拖拽式的图形界面 LLM 工作流构建器；以及
Vellum，另一个用于构建和测试复杂工作流的图形界面工具。

这些框架通过简化一些标准的底层任务，例如调用 LLM、定义和解析工具，以及将多个调用链接在一起，让上手变得更加容易。然而，它们通常会引入额外的抽象层，这可能会掩盖底层的提示和响应，使得调试变得更加困难。它们还可能诱使你在原本可以用更简单设置就能搞定的情况下，添加不必要的复杂性。

我们建议开发者们一开始直接使用 LLM API：许多模式只需几行代码即可实现。 如果你确实要用框架，请确保你理解了底层代码。对“引擎盖”下内容的错误假设，是客户经常犯错的一个常见原因。

构建块、工作流和 Agent

在本节中，我们将探讨在生产环境中常见的 Agentic 系统模式。我们会从最基础的构建块——增强型 LLM 开始，逐步提升复杂性，从简单的组合式工作流，到自主的 Agent。

构建块：增强型 LLM

Agentic 系统的基本构建块是经过增强的 LLM，这些增强包括检索、工具和记忆等。我们当前的模型可以主动使用这些能力——生成它们自己的搜索查询、选择合适的工具，并决定要保留哪些信息。

我们建议重点关注实现的两个关键方面：根据你的特定用例定制这些能力，并确保它们为你的 LLM 提供一个简单、文档完善的接口。虽然实现这些增强的方法有很多，但其中一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），该协议允许开发者通过一个简单的客户端实现与不断增长的第三方工具生态系统集成。

在本文的后续部分，我们将假设每次 LLM 调用都可以访问这些增强的能力。

工作流：提示链

提示链将一个任务分解成一系列步骤，其中每个 LLM 调用都处理前一个调用的输出。你可以在任何中间步骤上添加程序化的检查（参见下图中的“关卡”），以确保流程仍在正轨上。

何时使用此工作流： 当任务可以轻松、清晰地分解为固定子任务时，此工作流是理想选择。其主要目的是通过将每个 LLM 调用简化成一个更容易的任务，来用延迟换取更高准确性。

提示链适用的示例：

生成营销文案，然后将其翻译成不同的语言。
撰写文档大纲，检查大纲是否符合特定标准，然后根据大纲撰写文档。

工作流：路由

路由将输入进行分类，并将其定向到专门的后续任务。此工作流允许分离关注点，并构建更具针对性的提示。如果没有这个工作流，针对一种类型的输入进行优化可能会损害其他类型输入的性能。

何时使用此工作流： 对于那些存在明显类别、且这些类别最好分开处理的复杂任务，以及当分类可以由 LLM 或更传统的分类模型/算法准确处理时，路由非常有效。

路由适用的示例：

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

工作流：并行化

LLM 有时可以同时处理一项任务，并将其输出以编程方式聚合。这种工作流，即并行化，主要有两种表现形式：

分段： 将一项任务分解成多个独立的子任务并行运行。
投票： 多次运行同一个任务以获得多样化的输出。

何时使用此工作流： 当可以将任务分割成多个子任务以提高速度，或者当需要多个视角或尝试来获得更高置信度的结果时，并行化非常有效。对于具有多个考虑因素复杂任务，LLM 通常在每个考虑因素由单独的 LLM调用处理时表现得更好，这样可以集中关注每个特定方面。

并行化适用的示例：

分段：

实施安全护栏，其中一个模型实例处理用户查询，而另一个模型实例则筛查其中不当的内容或请求。这种方式往往比让同一个 LLM 调用同时处理安全护栏和核心响应效果更好。
自动评估 LLM 性能，其中每个 LLM 调用评估模型在给定提示上性能的不同方面。

投票：

审查一段代码是否存在漏洞，其中几个不同的提示会审查代码，并在发现问题时标记出来。
评估一段给定的内容是否不当，多个提示评估不同的方面，或要求不同的投票阈值，以平衡假阳性和假阴性。

工作流：协调器-工作器

在协调器-工作器工作流中，一个中央 LLM 动态地分解任务，将它们委派给工作器 LLM，并综合它们的结果。

何时使用此工作流： 这种工作流非常适合那些你无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量以及每个文件中的更改性质可能取决于具体的任务）。虽然它在结构上与并行化相似，但关键的区别在于它的灵活性——子任务不是预先定义的，而是由协调器根据特定的输入来确定的。

协调器-工作器适用的示例：

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

工作流：评估器-优化器

在评估器-优化器工作流中，一个 LLM 调用生成响应，而另一个 LLM 调用则在一个循环中提供评估和反馈。

何时使用此工作流： 当我们有明确的评估标准，并且当迭代改进能带来可衡量的价值时，这个工作流特别有效。适合使用此工作流的两个明显标志是：首先，当人们明确表达出反馈意见时，LLM 的响应可以得到显著改进；其次，LLM 能够提供此类反馈。这类似于人类作者在撰写一篇精雕细琢的文档时可能会经历的迭代写作过程。

评估器-优化器适用的示例：

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

Agent

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

Agent 可以处理复杂的任务，但它们的实现通常很简单。它们通常只是在一个循环中根据环境反馈使用工具的 LLM。因此，清晰且深思熟虑地设计工具集及其文档至关重要。我们在附录 2（“工具的提示工程”）中详细介绍了工具开发的最佳实践。