Agent

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (LLM) 智能体。始终如一地，最成功的实施并没有使用复杂的框架或专门的库。相反，他们是用简单的、可组合的模式构建的。 在这篇文章中，我们分享了我们从与客户合作和自己构建智能体中学到的经验，并为开发人员提供了关于构建有效智能体的实用建议。 什么是智能体？“智能体” 可以通过几种方式定义。一些客户将智能体定义为在较长时间内独立运行的完全自主的系统，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循预定义工作流程的更具规范性的实现。在 Anthropic，我们将所有这些变体归类为智能体系统，但在工作流程和智能体之间进行了重要的架构区分： 工作流程是通过预定义的代码路径协调大语言模型和工具的系统。另一方面，智能体是大型语言模型动态地指导其自身流程和工具使用的系统，保持对其如何完成任务的控制。下面，我们将详细探讨这两种类型的智能体系统。在附录 1 (“实践中的智能体”) 中，我们描述了客户发现使用这些类型的系统具有特殊价值的两个领域。 何时 (以及何时不) 使用智能体当使用大语言模型构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。 当需要更高的复杂性时，工作流程为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例优化单个大语言模型调用通常就足够了。 何时以及如何使用框架有许多框架可以使智能体系统更容易实现，包括： 来自 LangChain 的 LangGraph；Amazon Bedrock 的 AI 智能体 (AI Agent) 框架；Rivet，一个拖放式 GUI 大语言模型工作流程构建器；以及Vellum，另一个用于构建和测试复杂工作流程的 GUI 工具。这些框架通过简化标准的底层任务 (如调用大语言模型、定义和解析工具以及将调用链接在一起) 使入门变得容易。但是，它们通常会创建额外的抽象层，这可能会掩盖底层的提示和响应，从而使调试变得更加困难。当更简单的设置就足够时，它们也可能使添加复杂性变得很有诱惑力。 我们建议开发人员从直接使用大语言模型 API 开始：许多模式可以用几行代码实现。如果您确实使用了框架，请确保您了解底层的代码。对底层原理的错误假设是客户错误的常见来源。 请参阅我们的 cookbook 以获取一些示例实现。 构建模块、工作流程和智能体在本节中，我们将探讨我们在生产中看到的智能体系统的常见模式。我们将从我们的基础构建模块——增强型大语言模型——开始，并逐步增加复杂性，从简单的组合工作流程到自主智能体。 构建模块：增强型大语言模型智能体系统的基本构建模块是通过检索、工具和记忆等增强功能增强的大语言模型。我们目前的模型可以积极地使用这些功能——生成他们自己的搜索查询，选择合适的工具，并确定要保留哪些信息。 我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的 LLM 提供简单、完善的文档界面。虽然有很多方法可以实现这些增强功能，但一种方法是通过我们最近发布的 模型上下文协议 (Model Context Protocol)，该协议允许开发人员通过简单的 客户端实现 与不断增长的第三方工具生态系统集成。 在本帖的剩余部分，我们将假设每个大语言模型调用都可以访问这些增强的功能。 工作流程：提示链提示链将任务分解为一系列步骤，其中每个大语言模型调用处理前一个调用的输出。您可以在任何中间步骤中添加程序化检查 (请参阅下图中的“gate”) 以确保过程仍在轨道上。 何时使用此工作流程： 此工作流程非常适合可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个大语言模型调用成为更简单的任务来权衡延迟以获得更高的准确性。 提示链有用的示例： 生成营销文案，然后将其翻译成不同的语言。编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。工作流程：路由路由对输入进行分类并将其定向到专门的后续任务。此工作流程允许关注点分离，并构建更专业的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。 何时使用此工作流程： 路由适用于以下复杂任务：存在最好单独处理的不同类别，并且可以通过大语言模型或更传统的分类模型/算法准确处理分类。 路由有用的示例： 将不同类型的客户服务查询 (一般问题、退款请求、技术支持) 定向到不同的下游流程、提示和工具。将简单/常见的问题路由到较小的模型 (如 Claude 3.5 Haiku)，将困难/不常见的问题路由到功能更强大的模型 (如 Claude 3....

反思是一种用于提高代理和类似 AI 系统质量与成功率的提示策略。本文概述了如何使用 LangGraph 构建 3 种反思技术，包括 Reflexion 和语言代理树搜索的实现。 关键链接 简单反思： （Python）反思： （Python）语言智能体树搜索： （Python）Youtube反思是一种提示策略，用于提升智能体和类似 AI 系统的质量和成功率。它通过提示大语言模型（LLM）反思和批评其过去的行为，有时还会结合外部信息，如工具观察。 人们常提到“系统1”和“系统2”思维，系统1是反应迅速或本能的，而系统2则更为有条理和反思性。正确应用反思，可以帮助 LLM 系统摆脱纯粹的系统1思维模式，表现出更接近系统2的行为。 反思需要时间！本文中的方法都用了一些额外的计算换取更好的输出质量。虽然这可能不适合低延迟应用，但对于知识密集型任务，响应质量比速度更重要，确实值得这样做。 以下是三个示例： 基本反思 链接： （Python， Youtube） 这个简单示例由两个 LLM 调用组成：一个生成器和一个反思器。生成器尝试直接响应用户请求，反思器则扮演老师角色，对初始响应提供建设性的批评。 循环进行固定次数后，返回最终生成的输出。 简单反思循环 我们可以在 LangGraph 中定义以下循环： from langgraph.graph import MessageGraph builder = MessageGraph() builder.add_node("generate", generation_node) builder.add_node("reflect", reflection_node) builder.set_entry_point("generate") def should_continue(state: List[BaseMessage]): if len(state) > 6: return END return "reflect" builder.add_conditional_edges("generate", should_continue) builder.add_edge("reflect", "generate") graph = builder.compile() MessageGraph 表示一个有状态图，其中“状态”只是一个消息列表。每次调用生成器或反思节点时，它会将一条消息添加到状态的末尾。最终结果由生成器节点返回。 这种简单的反思方式有时可以通过让 LLM 多次尝试改进输出，并让反思节点在批评输出时扮演不同角色，从而提高性能。 然而，由于反思步骤不依赖于任何外部过程，最终结果可能不会显著优于原始结果。我们来探索一些可以改善这一情况的其他技术。 反思 链接：（Python， Youtube）...

本文是 LangChain 官方发布的关于 Agent 的系列文章，这里我将其汇总和翻译了一下 什么是智能体？ “什么是智能体？” 我几乎每天都会被问到这个问题。在 LangChain，我们构建工具来帮助开发人员构建大语言模型 (LLM) 应用程序，尤其是那些作为推理引擎并与外部数据和计算源交互的应用程序。这类系统通常被称为“智能体”。 每个人对智能体的定义似乎都有些不同。我的定义可能比大多数人的更技术化： 智能体是使用 LLM 来决定应用程序控制流的系统。 即便在这里，我也不得不承认我的定义并不完美。人们常常认为智能体是高级的、自主的、类人的——但如果只是一个简单系统，其中大语言模型 (LLM) 在两条路径之间进行选择呢？这虽然符合我的技术定义，但并不符合大家对智能体能力的普遍认知。智能体到底是什么，确实很难准确定义！ 这就是为什么我非常喜欢 Andrew Ng 上周的推文。在推文中，他建议“与其争论哪些工作应该包含或排除为真正的智能体，我们可以承认系统的智能行为有不同的程度。”就像自动驾驶汽车有不同的自动驾驶级别一样，我们也可以将智能体的能力视为一个光谱。我非常同意这个观点，我认为 Andrew 表达得很好。未来，当有人问我什么是智能体时，我会转而讨论什么是“智能行为”。 智能行为是什么意思？ 去年我做了一个关于 LLM 系统的 TED 演讲，并使用下面的幻灯片来讨论 LLM 应用程序中存在的不同自主级别。 一个系统越“智能”，LLM 决定系统行为的程度就越高。 使用 LLM 将输入路由到特定下游工作流具有一定程度的“智能”行为。这会在上图的Router类别中。 如果你使用多个 LLM 进行多个路由步骤？这会介于Router和State Machine之间。 如果其中一个步骤是确定是否继续或结束——有效地允许系统在完成之前循环运行？这会属于State Machine。 如果系统正在构建工具，记住这些工具，然后在未来的步骤中使用它们？这类似于Voyager 论文中实现的，非常智能，属于更高的Autonomous Agent类别。 这些“智能”定义仍然非常技术化。我更喜欢“智能”的技术定义，因为我认为它在设计和描述 LLM 系统时很有用。 为什么“智能”是一个有用的概念？ 与所有概念一样，值得问的是我们为什么需要“智能”这个概念。它有何帮助？ 了解你的系统有多智能可以指导你在开发过程中的决策——包括构建、运行、与之交互、评估甚至监控它。 你的系统越智能，编排框架就越有帮助。如果你正在设计一个复杂的智能系统，拥有一个具有正确抽象概念的框架可以加速开发。这个框架应该对分支逻辑和循环有一流的支持。 你的系统越智能，运行就越困难。它会越来越复杂，某些任务将需要很长时间才能完成。这意味着你会希望将任务作为后台运行。这也意味着你希望有持久的执行能力来处理中途发生的任何错误。 你的系统越智能，你就越希望在运行时与它交互。你会希望能够观察内部发生的情况，因为所采取的确切步骤可能事先未知。你会希望能够在特定时间点修改智能体的状态或指令，如果它偏离了预定路径，可以将其拉回正轨。 你的系统越智能，你就越希望有一个为这些类型的应用程序构建的评估框架。你会希望多次运行评估，因为有大量随机性叠加。你会希望能够不仅测试最终输出，还测试中间步骤，以测试智能体的效率。 你的系统越智能，你就越希望有一个新型的监控框架。你会希望能够深入了解智能体所采取的所有步骤。你还会希望能够根据智能体所采取的步骤查询运行情况。 了解和利用系统中的智能能力光谱可以提高开发过程的效率和健壮性。 智能是新的 我经常思考的一个问题是，在这场热潮中，什么是真正新的。我们是否需要为人们构建的 LLM 应用程序提供新工具和新基础设施？还是以前的通用工具和基础设施就足够了？ 对我来说，你的应用程序越智能，拥有新工具和基础设施就越关键。这正是促使我们构建LangGraph，一个帮助构建、运行和交互智能体的编排器，以及LangSmith，一个用于 LLM 应用程序的测试和可观测性平台。随着我们在智能光谱上不断前进，支持性工具的整个生态系统需要重新构想。 什么是“认知架构”？ 更新：有几位读者指出，“认知架构”这个术语在神经科学和计算认知科学中有丰富的历史。根据维基百科的定义，“认知架构”既指关于人类心智结构的理论，也指这种理论的计算实现。这个定义（以及相关的研究和文章）比我在这里提供的定义更为全面。所以这篇博客应该被视为我在过去一年中构建和帮助构建基于大语言模型 (LLM) 应用程序的经验与这一研究领域的对照。 在过去的六个月里，我经常使用“认知架构”这个短语，而且以后可能会更多地使用。这是我第一次从 Flo Crivello 那里听到的术语——所有的功劳都归于他，我认为这是一个很棒的术语。那么我究竟指的是什么呢？...