AI创想

标题: 什么是智能体agent？ [打印本页]
作者: admin    时间: 7 小时前
标题: 什么是智能体agent？
文章目录


什么是智能体agent？

原文链接：https://windsurf.com/blog/what-is-an-agent
本文探讨了AI智能体的核心概念及其与非智能体系统的区别。智能体系统通过交替调用推理模型（如LLM）和工具来执行任务，而非智能体系统则依赖单一LLM调用生成结果。文章区分了自主智能体与协作智能体，强调当前技术更适用于协作模式，并提出了评估智能体系统的关键问题，包括工具访问、推理模型选择和数据处理。最后，文章提醒避免“苦涩的教训”，即过度依赖人工规则而忽视技术规模化的潜力。
关键点
欢迎来到2025年版的“一个术语被过度使用，以至于它开始失去在对话中的任何实际意义，因为每个人都自信地用它来指代不同的事物”。
这篇文章是为那些在会议、董事会会议或对话中，与人谈论AI智能体，并且
（a）不太确定智能体是什么，以及它与我们迄今为止看到的生成式AI能力有何不同，
（b）不太确定使用该术语的人知道智能体是什么，或者
（c）可能认为他们知道智能体是什么，直到阅读本文的第一句话的人准备的。
最基本的核心思想

为了回答本文的标题，一个智能体AI系统可以简单地被认为是一个接受用户输入，然后交替调用以下内容的系统：
这创建了一个基础的 Agentic Loop：



真的，就是这样。根据这种agent循环向用户公开的方式，代理系统有不同的形式，我们稍后会详细介绍。但是，如果你理解了这些大型语言模型不是作为纯粹的内容生成器（如ChatGPT）使用，而是更多地作为一种工具选择推理组件使用，那么你就已经掌握了大部分内容。
This term “reasoning” is also overused - in the agentic world, it has a very specific meaning. It means using an LLM to choose what action to be taken next, i.e. what tool should be called with what parameters.
“推理”这个术语也被过度使用了 - 在智能体领域，它有一个非常具体的含义。它指的是使用大型语言模型来选择下一步要采取的行动，即应该调用哪个工具以及使用什么参数。
The term “reasoning” has also been used by models like OpenAI’s o1, and reasoning there means something completely different. For these LLMs, “reasoning” refers to chain-of-thought prompting. The idea there is that the model would first output intermediate steps before trying to provide the end response to the query, attempting to mimic more of how a human would work through a question than relying on pure pattern-matching magic. With these models, there are no tools being called (as in the agentic world), just outputs for the LLM being generated in a way that appears as if it is chaining together multiple thinking invocations (thus “chain-of-thought”).
术语“推理”也被 OpenAI 的 o1 等模型使用，但那里的“推理”含义完全不同。对于这些大型语言模型，“推理”指的是思维链提示。其思想是模型首先输出中间步骤，然后再尝试提供对查询的最终响应，从而尝试更像人类一样解决问题，而不是依赖于纯粹的模式匹配。使用这些模型，没有调用任何工具（如在代理世界中），只是以一种看起来像是将多个思维调用链接在一起的方式生成 LLM 的输出（因此称为“思维链”）。
The other misattribution of “agentic” is to what can be referred to as “AI workflows.” For example, someone might build an automation or workflow that takes in a raw document, uses an LLM to do object recognition, then cleans those extracted elements, then uses another LLM to summarize the elements, and then adds the summary to a database. There are multiple LLM calls, but the LLMs are not being used as tool calling reasoning engines. We are specifying what LLMs should be called and how ahead of time, not letting the LLM decide what tools should be called realtime. This is simply an automation, not an agent.
**“自主性”的另一种误用是指所谓的“AI 工作流”。**例如，有人可能会构建一个自动化或工作流，该工作流接收原始文档，使用 LLM 进行对象识别，然后清理提取的元素，然后使用另一个 LLM 总结这些元素，然后将摘要添加到数据库中。这里有多个 LLM 调用，但 LLM 没有被用作工具调用推理引擎。我们是预先指定应该调用哪些 LLM 以及如何调用，而不是让 LLM 实时决定应该调用哪些工具。这仅仅是一个自动化，而不是一个智能体。
理解主动式与非主动式agent的超级简单示例：假设您要求 AI 系统提供制作披萨的食谱。 在非主动式代理的世界中，您只需将提示传递给 LLM，然后让它生成结果：
In an agentic world, one of the tools the agent might have could be to retrieve a recipe from a cookbook, and one of the recipes is for a pizza. In this agentic world, the system will use the LLM (the reasoning model) to determine that, given the prompt, we should be using the “recipe tool” with input of “pizza” to retrieve the right recipe. This tool will then be called, the text of that recipe will be outputted, and then the reasoning model will determine, using the outputs of this tool call, that there is no more work to be done, and it will complete its “loop.”
在一个具有自主能力的世界中，智能体可能拥有的工具之一是从食谱中检索菜谱，其中一个菜谱是关于披萨的。在这个自主世界中，系统将使用LLM（推理模型）来确定，根据提示，我们应该使用“菜谱工具”，并输入“披萨”来检索正确的菜谱。然后，这个工具将被调用，该菜谱的文本将被输出，然后推理模型将使用这个工具调用的输出结果来确定没有更多的工作需要完成，并且它将完成它的“循环”。


虽然这种差异现在可能说得通了，你可能会问——这有什么有趣的？这似乎只是方法上的一种技术性问题。
好吧，这很有趣，原因有以下几点：
想象一下，如果这个例子更复杂一些。比如“用健康食材，以那不勒斯风格制作披萨的食谱”。非代理系统或许能凭借生成模型的强大能力，生成一些合理的结果。但随着请求变得越来越详细和复杂，仅仅通过一次调用LLM来完美实现请求的可能性就越来越小。另一方面，代理系统可能会首先推理使用一个工具，调用LLM来描述那不勒斯市如何制作披萨，然后推理使用一个工具来执行网络搜索，查找哪些食材可以被归类为健康食材，最后才推理使用检索食谱的工具，并将前几个步骤的信息作为潜在的可配置输入提供给最终工具。这种步骤的分解应该会让人觉得很自然，因为这正是我们人类的工作方式，并且应该减少潜在结果的差异，因为代理正在使用我们更了解并且可以更好地控制的工具。虽然不能保证一定有效，但与非代理方法相比，这种代理方法让AI系统有更好的机会把事情做对。
我们可以为代理提供的工具可以弥补大型语言模型（LLM）的不足。请记住，大型语言模型是随机系统，完全基于自然语言的模式运行。它们对非文本概念没有内在的理解。大型语言模型不擅长数学？我们可以添加一个计算器工具。大型语言模型不知道当前时间？我们可以添加一个系统时间工具。大型语言模型无法编译代码？我们可以添加一个构建工具。现在，推理模型（代理世界中的大型语言模型）实际上不需要从本质上知道如何做数学、报时或编译代码。相反，它只需要知道何时适合使用计算器、查找系统时间或尝试构建一些源代码，并能够确定这些工具的正确输入应该是什么。知道如何调用这些工具更容易处理，并且可以基于文本上下文。
这些工具实际上可以改变世界的状态，而不仅仅是提供文本回应。例如，在披萨的例子中，假设我们希望 AI 将披萨食谱发送给我的妹妹。也许代理可以访问我的联系人并发送短信。代理将能够进入一个循环——首先推理以检索食谱，然后推理以检索我妹妹的联系信息，然后推理以发送短信。前几个步骤可能可以通过一些非常聪明的 RAG 来实现，但最后一步呢？这种实际采取行动的能力，而不仅仅是生成文本，使得自主系统具有非常强大的潜力。
恭喜，你现在知道什么是 Agent 了！但还有更多的背景知识和信息，让你在关于“Agent”的对话中更具优势……
我们是如何走到今天以及为什么是现在

在我们深入探讨可用于就自主系统进行有意义讨论的思维模型之前，我们将先简单回顾一下我们是如何走到今天的，并根据人工智能工具实现自主的方式，对其类型进行一些澄清。我们将在软件工程领域进行讨论，以避免内容过于抽象。
如果你还记得几年前的世界，在生成式人工智能工具出现之前，人类实际上是需要工作的。这些工作可以被表示为一个行动的时间线。在软件工程中，这可能包括在 StackOverflow 上做一些研究，运行一个终端命令，或者实际编写一些代码。
how-humans-work-9s

后来，随着大型语言模型的出现，我们开始获得能够很好地完成特定范围任务的系统。例如，ChatGPT回答问题，GitHub Copilot自动补全几行代码等等。这些工具之所以能够被信任，是因为它们同时满足了两个条件：
后者这种情况实际上非常关键。多年来，人们一直在构建基于LLM的系统，用以解决极其复杂的任务，并展示了令人难以置信的演示。然而，其中许多只是演示，无法投入生产并获得信任，这导致炒作与现实之间普遍脱节，并随之而来的是幻灭的低谷。
以 pull request 为例。这对用户来说具有明显的价值（没有人喜欢编写拉取请求描述），但想想用户长期信任它所需的准确度水平。如果人工智能第一次出错地描述了拉取请求？用户将永远检查所有文件并自己编写描述，从而使该工具的价值失效。该用例所需的稳健性标准非常高，并且可能无法通过今天的技术来实现。话虽如此，虽然这种LLM技术并不完善，但它也在迅速改进，因此可以以足够稳健的水平解决的任务复杂性前沿也在不断提高。总有一天，人工智能将能够稳健地编写 pull request 描述。
我跑题了。最初有用的和可能的交集仅限于我所说的“副驾驶式”系统。这些是 AI 系统，它们会调用一次 LLM 来解决一个非常有限的任务，例如响应提示或生成自动完成建议。人类始终参与其中，在“接受”结果之前对其进行审查，因此 AI 失控的潜在问题并不存在。主要问题是幻觉问题，这个术语指的是模型提供的结果不准确，这是由于模型本身非常自信（这些模型是在互联网上的文本上训练的，每个人在互联网上都很自信），并且没有必要的知识来将响应置于现实之中（这些模型本质上只是超级复杂的模式匹配算法）。因此，**这些副驾驶式系统通过越来越强大的检索增强生成 (即“RAG”) 方法得到了改进，这是一种花哨的说法，指的是这些系统首先检索相关信息，以将响应置于用户查询的基础之上，用这些信息增强用户的查询，并将这些累积的信息传递给 LLM 以进行最终生成。**这种对能够执行有限任务的 AI 系统的知识访问定义了基于 LLM 的应用程序的最初几年 - “copilot”时代：
how-copilots-work-9s

These copilot-like, non-agentic systems were the ones that were driving real value at a consistency level that a user would trust the system long-term. That being said, it is not that the idea of an “agentic system” is anything new.
这些类似于Copilot的non-agentic系统正在以一种用户长期信任该系统的一致性水平驱动真正的价值。 话虽如此，“agentic system”的想法并不是什么新鲜事物。
第一个流行的 Agent 框架 AutoGPT 实际上是在 2023 年初，ChatGPT 发布后不久推出的。这里的 Agent 方法是让 Agent 循环自主进行，因此用户只需提供提示，让 Agent 完成其工作，然后查看结果。本质上，由于这些系统可以访问工具并执行多次 LLM 调用，因此它们可以更长时间地运行，并且可以完成比类似 Copilot 的系统范围更大的任务：
然而，尽管AutoGPT仍然是有史以来最受欢迎的GitHub存储库之一，但使用该框架创建的代理并没有真正流行起来。**一年后，Cognition推出了Devin，它被宣传为一个功能齐全的AI开发者，可以取代人类软件开发者。**同样，作为一个完全自主的代理系统，拥有一些非常强大的工具，但如今只能解决相对简单的问题。
发生了什么？如果说 Agent 应该如此强大，为什么用户主要从 RAG 驱动的非 Agentic 副驾驶式系统获得价值，而不是从这些 Agentic 系统获得价值？
Well, remember the intersection between “useful problem” and “technology is ready to be robust enough”? That’s the general challenge with these autonomous agentic systems. While these autonomous agents are where the world is clearly heading, the LLMs are likely not good enough today to complete the complexities of these tasks end-to-end without any human involvement or correction.
嗯，记住“有用的问题”和“技术足够成熟可靠”之间的交集吗？这是这些自主代理系统面临的普遍挑战。虽然世界显然正朝着自主代理的方向发展，但就目前而言，大型语言模型可能还不够完善，无法在没有任何人为干预或纠正的情况下，端到端地完成这些复杂任务。
This reality brought upon a new approach to agents, one grounded in a recognition that there is going to be some balance between what the human should do and what the agent should do. To distinguish from the autonomous approach to agents, we will refer to these as collaborative agents, or AI flows for shorthand.
这种现实带来了一种新的智能体方法，**这种方法基于一种认知，即人类应该做什么和智能体应该做什么之间需要保持某种平衡。**为了区别于智能体的自主方法，我们将这些智能体称为协作智能体，或简称为 AI flows。
换句话说，在这个现实中，人类观察智能体的行为很重要，智能体观察人类的行为也很重要。
回到“有趣的问题”和“足够强大的技术”的交汇点，协作式自主方法所需的技术稳健性门槛远低于自主式自主方法。这是因为人类可以随时纠正人工智能的中间步骤，需要批准人工智能的某些操作（例如，执行终端命令），并负责实时审查更改。
这就是当今所有普遍可用的、确凿地增加价值的自主应用所采取的方法，例如 Windsurf 的 Cascade、Cursor 的 Composer Agent 和 GitHub Copilot Workspaces。通过流程，人类和代理始终在相同的世界状态下运作：
We go through all of these lengths just to distinguish between an autonomous agent and a collaborative agent, because they are actually drastically different approaches towards building an “agentic” system. Different amounts of human-in-the-loop, different levels of trust required, different methods of interaction, etc. Because the term “agent” is overused, there is frequently a lot of chatter about building autonomous agents and pointing to agentic systems like Windsurf’s Cascade as evidence for agents working, when in reality these two approaches are drastically different.
我们不遗余力地区分自主代理和协作代理，因为它们实际上是构建“agent”系统的截然不同的方法。不同程度的人工参与，不同的信任级别要求，不同的交互方法等等。由于“agent”一词被过度使用，因此经常会有人谈论构建自主代理，并以 Windsurf 的 Cascade 等代理系统为例来证明代理的有效性，但实际上这两种方法截然不同。
如何从思维上剖析“一个智能体系统”

好了，终于到了你们期待已久的部分——一个快速检查清单，其中包含了我们所涵盖的所有内容，以便能够
(a) 推理关于“agent”的对话，以及
(b) 提出能够触及技术核心的问题。
这些问题中的许多问题本身都可以成为文章，但我将尝试提供一个有用的初步了解。
Question 1: 讨论的系统真的是自主的吗？
显然，太多人在系统实际上不是自主的时候称其为“自主的”。大型语言模型是否被用作调用推理模型的工具，并且实际上是否有工具被调用？或者这只是一些思维链推理或其他使用相同术语但含义不同的东西？
Question 2: 它是自主的还是协作的？
这种agent系统的方法是指agent在后台工作而无需人工干预，还是指agent有能力独立执行多个步骤，但嵌入到现有的工作系统中，并且仍然有人工参与？
如果是前一种情况，请追问一个问题——现在的模型是否真的足够好，能够以用户可以依赖的一致性来推理所涉及的数据和工具的规模和复杂性，从而保证整体智能体的可靠性？或者，提出构建一个自主智能体的建议，听起来理论上很棒，但实际上并不实用？
Question 3: 智能体是否拥有所有必要的输入和组件，使其本身就具有强大的能力？
这开始涉及到区分不同 Agent 实现方式（特别是协作 Agent 或流程）的核心，它们试图解决相同的任务。
Question 3a: 代理可以使用哪些工具？
不仅是工具列表，这些工具是如何实现的？例如，Windsurf 的 Cascade 采用了一种独特的网络搜索方法，通过分块和解析网站内容来实现。此外，添加自己独特的工具是否容易？Anthropic 的模型上下文协议（MCP）等方法旨在标准化一种低摩擦的方式，将新工具整合到现有的智能体系统中。
Question 3b: 智能体使用什么推理模型？
记住评估LLM时，重点在于其调用工具的能力，而不是它在各种任务和主题的标准基准测试中是否表现最佳，这一点非常重要。仅仅因为一个模型擅长回答编码问题，并不意味着它就擅长以自主方式选择正确的工具来解决与编码相关的任务。没有适用于所有任务的最佳推理模型，虽然像Anthropic的Claude 3.5 Sonnet这样的模型在历史上一直是工具调用方面最好的模型之一，但这些模型正在迅速改进。因此，考虑agent是否可以选择使用不同类型的模型可能更为合适，这个问题是很有意义的。
Question 3c: agent如何处理现有数据？
agent可以访问哪些数据源？ agent对这些数据源的访问是否尊重用户已有的访问控制规则（尤其是在协作agent领域）？ 有时答案并不像数据源本身那么简单——对于代码库，agent是否只能访问用户 IDE 中当前检出的存储库，或者它可以访问其他存储库中的信息来帮助确定结果。 后者可以增加价值，因为代码是分布式的，但随后关于访问的问题变得更加重要。
总的来说，agentic改变了我们思考数据检索问题的范式。在类似副驾驶的系统中，你只能对大型语言模型进行一次调用，因此你只有一次检索机会，这导致了越来越复杂的 RAG 系统。借助agentic，如果第一次检索返回的结果不佳，推理模型可以选择使用不同的参数再次进行检索，重复此过程，直到确定已收集到所有相关信息以采取行动。这与人类浏览数据的方式非常相似。 因此，如果对话过于深入地围绕 RAG、解析和中间数据结构展开，请问一个问题——我们是否为agentic世界过度复杂化了？稍后会详细介绍这一点……
话虽如此，如果数据中存在结构，那么询问这些数据源中的信息是如何被处理的，就是合理的。例如，我们处理代码库，而代码是高度结构化的，因此我们可以采用诸如抽象语法树（AST）解析之类的巧妙技术，以便智能地对代码进行分块，从而使任何试图推理或搜索代码库的工具更容易。智能预处理和多步骤检索并不相互排斥。
Question 3d: 协作式代理或流程如何捕捉用户意图？
是否存在任何隐式信号，可以通过人类用户的手动操作来捕捉，而这些信号永远不会被显式编码？现在，agent可能不知道茶水间里说了些什么，但通过“读取”用户的心思，往往可以创造出更加有价值和神奇的体验，这令人惊讶。在我们的世界里，这种意图可以从用户在 IDE 中打开的其他标签页、在文本编辑器中刚刚进行的编辑、刚刚执行的终端命令、粘贴到剪贴板中的内容等等中找到。这又回到了降低使用代理的激活能量的问题——如果每次都期望用户详细说明每一个可以从这些隐式信号中推导出的细节，那么用户对 AI 结果质量的期望值将会更高。
Question 4: 这个 Agent 的用户体验真正出色之处是什么？
到目前为止，我们已经讨论了所有会影响智能体结果质量的因素。你可能会发现关于智能体系统的讨论主要集中在这些因素上，但是任何认真对待创建能被用户实际采用的智能体系统的人，都应该关注用户体验的各个方面，这些方面能使智能体的使用更加顺畅，即使底层智能体没有任何改变。用户体验的许多方面构建起来并非易事，因此应该仔细考虑。
Question 4a: 这个自主系统的延迟是多少？
假设两个自主系统执行相同的特定任务，一个需要一个小时，而另一个需要一分钟。 如果你知道这些系统肯定会成功完成任务，那么你可能不太关心时间差异，因为你在此期间可以做其他事情。 但是如果代理有可能失败呢？ 你会非常喜欢后者，因为你会更快地看到失败，也许可以改变一些提示，给代理更多的指导等等。 实际上，延迟问题一直是完全自主代理面临的主要挑战之一，因为从历史上看，自主代理完成任务所需的时间比人工手动完成任务的时间更长； 除非自主代理的成功率非常高，否则就不会被使用。
显式地指出延迟有两个原因。首先，代理构建者经常添加复杂、缓慢的工具来提高质量，而没有考虑到对用户体验的影响，也没有认真权衡利弊。其次，在堆栈的每个部分改进延迟都是一个非常困难的问题——模型推理优化？提示构建以最大化缓存？在工具中并行化工作？通常需要一整套不同的工程师技能来提高延迟。
Question 4b: 用户如何观察和引导智能体？
这是协作智能体相对于自主智能体的巨大优势，但执行起来很少是简单的。 例如，如果一个编码智能体可以在 IDE 中的多个文件中进行多次编辑，开发者如何有效地审查这些更改（与查看单个自动完成建议或在聊天面板中查看响应大不相同）？
同样地，人们需要时间来积累在特定环境中执行特定任务的最佳实践经验。你能构建什么样的用户体验，让人类能够引导智能体掌握这些最佳实践？例如，**Windsurf的Cascade可以接收用户定义的规则，或者通过简单的方式标记已知上下文来引导智能体。**是的，任何智能体的目标都是能够独立完成任何事情，但如果人类能够轻松地帮助智能体更轻松地完成工作，那么智能体就能更快地完成更高质量的工作。
问题 4c：agent如何集成到应用程序中？
这完全取决于如何优化调用agent以及如何利用其输出。ChatGPT 的普及使得聊天面板成为调用任何基于 AI 的系统的默认方法。虽然这可能是一种方式，但它不必是唯一的方式。例如，Windsurf 的 Cascade 可以通过其他方式调用，例如一个简单的按钮来解释一段代码，并且上下文可以通过许多不需要复制粘贴文本的方式传递给 Cascade，例如 Previews 允许将控制台日志和 UI 组件传递给 Cascade。
Question 4d: 主动性体验如何与非主动性体验相平衡？
这可能出乎意料，但并非所有事情都需要主动性。例如，如果开发人员只是尝试进行本地化的重构，他们应该使用命令和Tab的某种组合，这两种非主动性的“copilot式”体验对于此类任务来说既快速又高效。Agent是新的前沿，但这并不意味着我们有了一个新的锤子，所有问题都是钉子！经常问“我们需要为此任务构建一个Agent吗？”是有用的。
在这里，我们仍然只是略窥门径，但这份清单应该能帮助你展开关于agent的对话，提出切中要害的问题，并将一些现实主义注入到想法中。
痛苦的教训

但是，还有最后一件事。我把它单独列出来是因为，如果这篇文章你最终只用了一个问题，那应该是这个问题：“我们是否违反了痛苦的教训？”
The Bitter Lesson is derived from the eponymous article by Richard Sutton, and the main (rephrased) takeaway is that more compute, more data, and generally more scale of technology will always eventually lead to systems that will outperform any system that relies on human-defined structure or rules. We saw it with CNNs outperforming hand-crafted rules for edge and shape detection in computer vision. We saw deep search and then deep neural networks outperform any rule-based computer systems on chess, go, and more complex games. Even LLMs are an example of this trend, outperforming any “traditional” NLP methods.
苦涩的教训 源自 Richard Sutton 的同名文章，其主要（改述的）结论是，更多的计算、更多的数据以及通常更大规模的技术最终将总是导致系统优于任何依赖于人类定义的结构或规则的系统。我们已经在 CNN 在计算机视觉中胜过用于边缘和形状检测的手工规则中看到了这一点。我们看到深度搜索和深度神经网络在国际象棋、围棋和更复杂的游戏中胜过任何基于规则的计算机系统。即使是 LLM 也是这种趋势的一个例子，胜过任何“传统”的 NLP 方法。
有了agent，我们再次有可能忘记痛苦的教训。我们可能会认为我们更了解某个特定用例，因此我们需要花费大量时间来精心设计正确的提示，或者确保我们明智地选择哪些工具子集是有价值的，或者尝试任何其他方法来注入“我们的知识”。归根结底，这些模型将继续改进，计算将继续变得更便宜、更强大，而所有这些努力都将化为乌有。
Don’t fall into the trap of the Bitter Lesson.
不要陷入“苦涩的教训”的陷阱。
结论

这就是全部内容！您现在已经了解了自主系统的基础知识。如果您想通过视频格式了解更多信息，并观看软件开发代理的实际应用，可以查看我们与 DeepLearning.ai 团队合作制作的这门课程。



欢迎光临 AI创想 (https://www.llms-ai.com/) Powered by Discuz! X3.4