Agent

本文是 LangChain CEO Harrison Chase 在 OpenAI 发布了一份关于构建智能体 ( agents ) 的指南之后写的一篇文章，这篇文章主要用于指出 OpenAI 的智能体指南中的一些误导性观点，并给出了自己的一些看法。 定义区分： 工作流 (Workflows)：通过预定义代码路径编排 LLM 和工具，可预测性高。 代理 (Agents)：LLM 动态指导自身流程和工具使用，灵活性高。作者更倾向于 Anthropic 对此的精确技术定义。 代理失败原因：LLM 表现不佳通常源于上下文问题，如：系统提示不完整、用户输入模糊、工具描述/访问不当、未传入正确上下文、工具响应格式不佳等。 LangGraph 特点： 提供底层编排能力（节点 Nodes 和边 Edges）。 支持声明式（图结构）和命令式（节点/边内部逻辑）编程。 内置持久化层，支持容错、短期/长期记忆。 支持“人在回路”（human-in-the-loop）和“人监控回路”（human-on-the-loop）模式。 内置流式处理（streaming）支持。 与 LangSmith 集成，提供调试、评估和可观测性。 框架价值：除了代理抽象，好的框架还应提供：短期/长期记忆管理、人机交互支持、流式输出、调试/可观测性、容错机制等。这些价值对工作流和代理都适用。 对 OpenAI 指南的批评：作者认为 OpenAI 的指南： 错误地将 LangGraph 等声明式方法描绘为繁琐且不灵活。 混淆了“声明式 vs 命令式”与“工作流 vs 代理”以及“抽象”的概念。 声称 Agents SDK 等“非声明式”（实为抽象）方法更灵活、“代码优先”，作者认为这与事实相反。 未能抓住构建可靠代理系统的核心挑战（上下文控制）和框架应提供的核心价值（可靠的编排层）。 多代理系统：关键在于代理间的通信机制，工作流常用于组织多个代理的协作。 框架对比：作者提供了一个电子表格链接，用于比较 LangGraph, Agents SDK, CrewAI, AutoGen 等多种框架在不同维度（如编排 vs 抽象、特性支持）上的表现。 原文：如何看待 AI 智能体框架 总结：...

本文的核心观点是，真正的 生成式 AI LLM 智能体 (agents) 正在到来，它们与目前常见的基于工作流的系统有着本质的区别。这些新型智能体能够进行规划、记忆，并有效地执行多步骤、长期的任务。与预定义规则和提示的工作流系统不同，真正的 LLM 智能体能够动态地指导自身流程和工具使用，从而克服了传统方法在可扩展性和长期效能方面的局限性，并有望在各个领域带来颠覆性变革。文章强调，要实现真正的 LLM 智能体，需要采用 强化学习 (RL) 与推理 (Reasoning) 相结合的方法，并克服数据和计算方面的挑战，以推动这项技术的民主化发展。 LLM 智能体的定义与兴起： 文章指出，OpenAI 在 2025 年 1 月发布的 DeepResearch 以及 Claude Sonnet 3.7 是真正的 LLM 智能体的早期例证。Anthropic 将 LLM 智能体定义为能够动态控制自身流程和工具使用的系统，这与通过预定义代码路径编排 LLM 和工具的工作流系统形成对比。 工作流系统的局限性： 文章批评了当前许多 “智能体” 系统，如 Manus AI，实际上是工作流系统，它们在规划、记忆和长期行动方面存在根本性缺陷，例如无法有效规划搜索策略、难以维持超过 5-10 分钟的任务、以及长期行动中容易累积错误。 “苦涩的教训” (Bitter Lesson)： 文章引用了 Richard Sutton 的 “苦涩的教训”，指出在 AI 智能体中硬编码知识和规则虽然短期内有效，但长期来看会阻碍进步。真正的突破来自于扩展计算规模，并基于搜索和学习的方法。这表明，依赖预定义提示和规则的工作流系统注定会遇到瓶颈。 RL + Reasoning 是制胜之道： 文章强调，真正的 LLM 智能体需要通过 强化学习 (RL) 进行训练，并结合推理能力。训练过程涉及生成草稿、评估结果 (通过验证器 verifiers) 以及迭代优化。DeepSeek 的 GRPO 算法和 vllm 技术被认为是实现高效 RL 训练的关键。 数据和计算的挑战与解决方案： 训练 LLM 智能体，特别是对于复杂任务如搜索，需要大量的行动序列数据。由于缺乏公开的 agentic 数据，文章提出了通过模拟 (emulation) 和合成数据生成来解决数据瓶颈的思路。例如，可以创建网络搜索的模拟环境，并利用 Common Crawl 等数据集进行训练。 LLM 智能体的应用前景： 文章展望了 LLM 智能体在搜索之外的应用，例如网络工程 (自动生成设备配置、分析网络拓扑) 和金融领域 (数据标准转换)。这些应用场景都超越了传统工作流系统的能力，需要智能体具备自主规划和动态决策的能力。 技术民主化的必要性： 文章最后指出，目前 LLM 智能体技术主要掌握在少数大型实验室手中，为了促进技术发展和应用普及，需要推动 LLM 智能体训练和部署的民主化，例如开放验证器、 GRPO 训练样本以及复杂的合成管线和模拟器。 原文：真正的 LLM Agents 即将到来 实际的大语言模型 AI 智能体 (LLM Agent) 即将到来。它们将被训练 现在“智能体”这个词随处可见。然而，在大语言模型 (LLM) 驱动的智能体研究领域，一项最重要的研究进展却几乎没有引起人们的注意。...

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (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 那里听到的术语——所有的功劳都归于他，我认为这是一个很棒的术语。那么我究竟指的是什么呢？...