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

这篇文章是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（“工具的提示工程”）中详细介绍了工具开发的最佳实践。

何时使用 Agent： Agent 可用于开放式问题，这些问题难以或不可能预测所需的步骤数，并且无法硬编码固定路径。LLM 可能会运行多个回合，你必须对其决策有一定的信任度。Agent 的自主性使其成为在可信环境中扩展任务的理想选择。

Agent 的自主性意味着更高的成本，以及错误累积的可能性。我们建议在沙盒环境中进行广泛的测试，并配备适当的安全护栏。

Agent 适用的示例：

以下示例来自我们自己的实现：

• 用于解决 SWE-bench 任务的编码 Agent，它根据任务描述对许多文件进行编辑；
• 我们的“computer use”参考实现，其中 Claude 使用计算机来完成任务。

组合和定制这些模式

这些构建块并不是规定性的。它们是一些常见的模式，开发人员可以根据不同的用例对其进行调整和组合。与任何 LLM 功能一样，成功的关键在于衡量性能并对实现进行迭代。再次强调：只有在能够显著改善结果的情况下，才应该考虑增加复杂性。

总结

在 LLM 领域，成功并不在于构建最复杂的系统，而在于构建适合你需求的系统。从简单的提示开始，通过全面的评估对其进行优化，并且只有在更简单的解决方案不够用时才添加多步骤的 Agentic 系统。

在实现 Agent 时，我们尝试遵循三个核心原则：

• 保持 Agent 设计的简洁性。
• 通过显式展示 Agent 的规划步骤来优先考虑透明度。
• 通过全面的工具文档和测试来精心设计你的 Agent-计算机接口（ACI）。

框架可以帮助你快速入门，但在转向生产环境时，不要犹豫，可以减少抽象层并使用基本组件进行构建。通过遵循这些原则，你可以创建出不仅强大，而且可靠、可维护并深受用户信赖的 Agent。

致谢

本文由 Erik Schluntz 和 Barry Zhang 撰写。这项工作借鉴了我们在 Anthropic 构建 Agent 的经验以及客户分享的宝贵见解，对此我们深表感谢。

附录 1：Agent 的实际应用

我们与客户的合作揭示了 AI Agent 的两个特别有前途的应用，它们证明了上述模式的实用价值。这两个应用都说明了 Agent 如何为那些既需要对话又需要行动、具有明确的成功标准、支持反馈循环并集成了有效的人工监督的任务带来最大价值。

A. 客户支持

客户支持将熟悉的聊天机器人界面与通过工具集成而得到增强的功能相结合。这与更开放式的 Agent 天然契合，因为：

• 支持交互自然地遵循对话流程，同时需要访问外部信息和操作；
• 可以集成工具来获取客户数据、订单历史和知识库文章；
• 可以以编程方式处理诸如发放退款或更新工单之类的操作；并且
• 可以通过用户定义的解决方案来清晰地衡量成功。

一些公司已经通过基于使用量的定价模型证明了这种方法的可行性，这些模型仅对成功的解决方案收费，显示出对他们 Agent 有效性的信心。

B. 编码 Agent

软件开发领域已经展现出 LLM 功能的巨大潜力，其能力已从代码补全发展到自主解决问题。Agent 尤为有效，因为：

• 代码解决方案可以通过自动化测试进行验证；
• Agent 可以使用测试结果作为反馈来迭代解决方案；
• 问题空间是明确且结构化的；并且
• 可以客观地衡量输出质量。

在我们自己的实现中，Agent 现在可以仅根据 Pull Request 描述来解决 SWE-bench Verified 基准测试中的实际 GitHub 问题。然而，尽管自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录 2：工具的提示工程

无论你构建哪种 Agentic 系统，工具都可能是 Agent 的重要组成部分。工具使 Claude 能够通过在我们的 API 中指定其确切的结构和定义来与外部服务和 API 进行交互。当 Claude 响应时，如果它计划调用工具，则会在 API 响应中包含一个工具使用块。工具定义和规范应该像你的整体提示一样受到足够的提示工程关注。在这个简短的附录中，我们将介绍如何对工具进行提示工程。

通常有多种方法可以指定相同的操作。例如，你可以通过编写差异(diff)来指定文件编辑，或者通过重写整个文件来指定。对于结构化输出，你可以在 Markdown 中返回代码，也可以在 JSON 中返回。在软件工程中，像这样的差异是表面上的，并且可以无损地从一种转换为另一种。然而，某些格式对于 LLM 来说比其他格式更难编写。编写差异需要在编写新代码之前知道块头中更改了多少行。在 JSON 中编写代码（与 Markdown 相比）需要对换行符和引号进行额外的转义。

我们对决定工具格式的建议如下：

• 在模型把自己“写到角落里”之前，给它足够的 token 来“思考”。
• 保持格式接近模型在互联网上自然看到的文本格式。
• 确保没有任何格式“开销”，例如必须准确计算数千行代码，或对它编写的任何代码进行字符串转义。

一条经验法则是思考人机界面 (HCI) 需要投入多少精力，并计划在创建良好的 Agent-计算机接口 (ACI) 上投入同样多的精力。以下是一些关于如何做到这一点的想法：

• 站在模型的角度思考。根据描述和参数，使用此工具的方式是否显而易见，还是需要仔细考虑？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确边界。
• 如何更改参数名称或描述以使事情更明显？ 可以把这想象成为你团队中的初级开发者编写出色的文档字符串。当使用许多类似的工具时，这一点尤为重要。
• 测试模型如何使用你的工具：在我们的工作台中运行许多示例输入，看看模型会犯哪些错误，并进行迭代。
• 对你的工具进行防呆设计(Poka-yoke)。更改参数，使其更难犯错。

在为 SWE-bench 构建我们的 Agent 时，我们实际上花了更多时间来优化我们的工具而不是整体提示。例如，我们发现，在使用相对文件路径的工具时，当 Agent 移出根目录后，模型会出错。为了解决这个问题，我们将工具更改为始终需要绝对文件路径——并且我们发现模型完美地使用了这种方法。

如何学习大模型

下面这些都是我当初辛苦整理和花钱购买的资料，现在我已将重要的AI大模型资料包括市面上AI大模型各大白皮书、AGI大模型系统学习路线、AI大模型视频教程、实战学习，等录播视频免费分享出来，需要的小伙伴可以扫取。

现在社会上大模型越来越普及了，已经有很多人都想往这里面扎，但是却找不到适合的方法去学习。

作为一名资深码农，初入大模型时也吃了很多亏，踩了无数坑。现在我想把我的经验和知识分享给你们，帮助你们学习AI大模型，能够解决你们学习中的困难。

一、AGI大模型系统学习路线

很多人学习大模型的时候没有方向，东学一点西学一点，像只无头苍蝇乱撞，我下面分享的这个学习路线希望能够帮助到你们学习AI大模型。

二、AI大模型视频教程

三、AI大模型各大学习书籍!

四、AI大模型各大场景实战案例

五、AI大模型面试题库

五、结束语

学习AI大模型是当前科技发展的趋势，它不仅能够为我们提供更多的机会和挑战，还能够让我们更好地理解和应用人工智能技术。通过学习AI大模型，我们可以深入了解深度学习、神经网络等核心概念，并将其应用于自然语言处理、计算机视觉、语音识别等领域。同时，掌握AI大模型还能够为我们的职业发展增添竞争力，成为未来技术领域的领导者。

再者，学习AI大模型也能为我们自己创造更多的价值，提供更多的岗位以及副业创收，让自己的生活更上一层楼。

因此，学习AI大模型是一项有前景且值得投入的时间和精力的重要选择。