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

大模型很多技术干货，都可以共享给你们，如果你肯花时间沉下心去学习，它们一定能帮到你！

大模型玩家

1170人浏览 · 2025-02-22 10:19:28

大模型玩家 · 2025-02-22 10:19:28 发布

感觉对于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+教育：智能教学助手和自动评分系统使个性化教育成为可能。通过AI分析学生的学习数据，提供量身定制的学习方案，提高学习效果。
②AI+医疗：智能诊断系统和个性化医疗方案让医疗服务更加精准高效。AI可以分析医学影像，辅助医生进行早期诊断，同时根据患者数据制定个性化治疗方案。
③AI+金融：智能投顾和风险管理系统帮助投资者做出更明智的决策，并实时监控金融市场，识别潜在风险。
…
这些案例表明，学习大模型课程不仅能够提升个人技能，还能为企业带来实际效益，推动行业创新发展。

大模型就业发展前景

根据脉脉发布的《2024年度人才迁徙报告》显示，AI相关岗位的需求在2024年就已经十分强劲，TOP20热招岗位中，有5个与AI相关。
在这里插入图片描述字节、阿里等多个头部公司AI人才紧缺，包括算法工程师、人工智能工程师、推荐算法、大模型算法以及自然语言处理等。

除了上述技术岗外，AI也催生除了一系列高薪非技术类岗位，如AI产品经理、产品主管等，平均月薪也达到了5-6万左右。
AI正在改变各行各业，行动力强的人，早已吃到了第一波红利。