如果您身处人工智能领域，您可能最近经常听到“AI Agents”（人工智能代理）这个术语。 在本文中，让我们明确我们在大型语言模型 (LLM) 和人工智能 (AI) 的语境下所说的“Agents”是什么意思。
在深入探讨这个话题之前，有一点需要记住： “agents”这个术语在今天高性能的 LLM 出现之前就已经存在了。 甚至可以说，AI agents 已经存在很长时间了，只是没有今天这种生成式 LLM 作为核心。 然而，改变的是它们变得多么优秀和复杂。 因此，简而言之，您听到更多关于 agents 的信息并不是因为它们是一种全新的技术。 不，您听到更多关于 AI agents 的信息是因为情况变得非常、非常有趣。
什么是 AI Agent
从基本层面上来说，今天的 AI agent 是一个半自主或完全自主的系统，它使用 LLM 作为其“大脑”来进行关键决策和解决复杂任务。 将它们视为自动化的决策引擎，以便您，用户，只需要提出您的查询。 它们运行并使用环境中可用的各种工具来完成任务，以便您可以坐下来放松，同时它弄清楚如何解决您的问题。
Agents 能够自主地指导自己的流程和执行流程，根据手头的任务选择使用哪些工具。 这些工具可以包括网络搜索引擎、数据库、API 等，使 agents 能够与现实世界进行交互。
AI Agents 的简要历史
从技术上讲，AI agents 已经存在很长时间了。 您甚至可以在微软最近发表的关于 AI agents 的文章 中看到，作者们提到了他们早在 2005 年就在研究 AI agents。 然而，我们的 AI agents 的形态和能力在过去几年中发生了显著变化，这主要归功于最新 LLM 的能力。 现在，我们能够将 LLM 作为核心组件来使用，用于规划、推理和行动。
读者：这部分对我 (Tuana) 来说是一件愉快的事情，可以写写并深入研究。 但是，如果历史和研究不是您感兴趣的，请随时跳到下一部分。 我不会介意的。
因此，我想重点介绍一下我们 最近 的 AI agents 历史中的几个里程碑，并且您可以假设从这里开始我们只指的是今天的 AI agents (2025)。 当然，这是我对这个问题的个人看法，回顾过去几年。 但是，让我们回到 ChatGPT 发布之前。 2020 年，发表了两篇论文，我认为可以被视为当前使用 LLM 作为核心决策组件的 AI agents 的开端
- MRKL Systems：发音为“miracle”系统，这篇论文主要集中在语言的局限性上，并研究了我们获得如此多的幻觉响应的 原因。 简而言之，他们强调了我们现在完全理解的事情：语言模型并 不 知道所有事情，它们被设计用来生成语言。 这样想，我们不能期望人们知道我们的生日，除非我们告诉他们。 这篇论文介绍了一种我们可以向语言模型提供外部知识库的方式，以便从中提取相关信息。
- ReAct：在 MRKL systems 之后发表，这篇论文引入了另一个关键组件，它构成了今天的 agent。 这篇论文介绍了一个名为“ReAct”（代表“reason and act”，即“推理和行动”）的提示过程。 简而言之，它强调了一种我们可以构建提示的巧妙方式，从而使 LLM 考虑到手头的问题，推理解决它的选项，选择正确的工具来解决问题，并采取行动。 为了保持 非常 简单，请举以下例子。 除了只提出问题，我们还告诉模型它可以访问哪些资源，并要求它制定一个解决查询的计划。 简而言之，这篇论文介绍了一种开始思考我们的 LLM 指令的方式，以使推理和行动的过程更可靠
注意：论文中推荐的实际 ReAct 提示比这个复杂得多，包括关于如何生成想法、如何推理等的说明。
在我看来，这两篇论文强调了两个非常重要的发现和特征，它们将我们带到了今天的 AI agents：良好的指令和外部工具。 还有成千上万的人开始摆弄这些 LLM，现在我们已经进入了一个我们开始构建越来越复杂的 AI agents 的世界（这些 agents 不再只使用 ReAct 提示方法）。
有了这些，让我们看看今天的 AI agent 的构成。
AI Agent 的核心组件
虽然并非每个 AI agent 都 必须包含所有这些组件，但当我们构建 agents 时，它们至少包含以下组件和过程：LLM、访问工具（通过函数调用）、某种程度的记忆和推理。
让我们深入了解它们的作用
- LLM： 将 LLM 视为操作的大脑。 虽然不一定适用于 每个步骤，但当我们说 2025 年的“agents”时，一个生成模型作为操作的协调者发挥着重要作用。 简单地说，考虑一下上面部分中的示例场景：LLM 决定首先查找
user_calendar，然后查找天气。 - 工具： Agents 的一个很棒的特性是它们通过不同的工具与环境交互。 可以将它们视为“附加组件”，使 agents 更好。 这些工具使 agents 能够超越 LLM 的固定训练知识，通过提供高度相关和实时数据（例如您的个人数据库）和能力（例如发送电子邮件）来实现。 通过函数调用，LLM 可以直接与预定义的工具集交互，扩展 agents 的操作范围和效率。
- 记忆： Agents 通常具有某种形式的记忆（短期记忆和长期记忆），这使它们能够存储推理过程、对话历史记录或在不同执行步骤中收集的信息的日志。 我们需要记忆来用于与我们的 agents 进行的持续对话，以及我们想要返回的对话。 记忆可以用于个性化体验或计划未来决策
- 观察和推理： LLM 是解决问题、任务分解、规划和路由的核心。 它允许 agent 对问题进行推理，将其分解为更小的步骤（如果需要），并决定如何以及何时使用可用的资源/工具来提供最佳解决方案。 但是，并非每个 agent 的构建方式都相同，有时我们在构建 agent 时会将推理作为过程的显式步骤。
重要的是要记住，存在各种设计模式，从而产生 AI agent，并且这些组件的使用程度各不相同。 我们今天看到的 agents 存在于一个范围内，自主性或“agentic”行为的程度很大程度上取决于 LLM 委派的决策权限。 简单来说：有些 agents 被设计成比其他 agents 更独立地运行。
AI Agents 是如何工作的？
我们今天看到的 AI agents 大多数使用 LLM 作为核心决策者/操作的协调者。 当然，这个 LLM 拥有的自主性程度可能会有所不同，我们将在本文的“展望未来”部分中对此进行更多讨论。 但是，让我们首先讨论一个使用 LLM 来进行大部分决策的 AI agent 的基本工作原理。
我注意到的是，当人们现在讨论 LLM 和 agents 时，似乎发生了很多神奇的事情。 因此，在这里，我将尝试解释 AI agent 在后台 实际 发生的事情，它可以使用一些工具。
定义提示
任何使用 LLM 的系统的核心都是一个指令（提示），它为 LLM 设定了其核心目的。 ReAct 论文也清楚地表明了这一点，它强调了一个复杂的提示，定义了一个推理、生成想法、观察的 agent。 例如，LLM 可以被赋予一个指令，说明它是一个“有帮助的助手，可以访问我的数据库以回答我的查询”。
提供工具
接下来，我们需要向 LLM 提供一个工具列表。 这是今天创建 AI agents 最受欢迎的方式之一，尽管并非总是必要的，我们仍然可以在不通过工具和函数调用来创建 agentic 功能。 今天的大多数模型提供商都支持“函数调用”，这使我们能够使用 LLM 访问的工具列表来设置我们的交互，以便在任何给定时间解决查询。
当我们向 LLM 提供工具时，我们告诉 LLM 以下几点。 它使用这些信息来决定何时使用该工具
- 名称： 例如，一个工具的名称可能是
technical_documentation_search - 描述： 这可能是模型在推理使用哪个工具时可以访问的最重要信息。例如，对于工具
technical_documentation_search，我们可以提供描述“当您需要搜索 Weaviate 技术文档以获取答案时很有用”。 - 预期的输入： 请记住，工具是 LLM 外部的。LLM 知道它们的名称，也为它们提供了描述，但生成式大型语言模型的最终任务是生成语言。那么它能做什么呢？嗯，它擅长什么！它可能生成一些内容，返回一个函数（一个工具）的名称以及运行它所需的输入。因此，当我们向 LLM 提供工具列表时，我们也会提供此信息。例如，对于我们的工具
technical_documentation_search工具，我们可以告诉 LLM 它期望query: str才能运行。
如果您有兴趣了解实际情况，可以查看 OpenAI 的函数定义文档，例如。
使用工具
因此，我们有一个 LLM，它知道它可以访问一些工具，如何运行它们以及它们有什么用。但是，LLM 本身并没有内在的能力来，例如，运行一个 Python 脚本……或者搜索您的文档。但是，它可以提供一条消息，解释它打算运行一个工具，以及它想要使用哪些输入。
让我们以以下场景为例
- 我们有一个使用 LLM 的 AI 代理
- 我们提供了
technical_documentation_search作为工具，并提供了预期的输入query: str。我们说它“当您需要搜索 Weaviate 技术文档以获取答案时很有用”。 - 用户询问：“嘿，如何使用 Ollama 与 Weaviate 配合使用？”
在这种情况下，实际发生的情况如下
- LLM 生成的响应归结为“运行工具
technical_documentation_search，使用query = "Using Ollama"”。
因此，实际上，LLM 正在让我们的 AI 代理应用程序采取一步走出自身世界。它指示我们的系统存在一个需要参考的外部资源。
观察工具响应
如果一切顺利，到目前为止，您的 AI 代理已经运行了一个工具。请记住，这个工具可以是任何东西。例如，我们的 technical_documentation_search 工具本身可能是一个 RAG 应用程序（检索增强生成），它本身使用另一个 LLM 来生成对查询的响应。重点是，最终我们可能使用查询“Using Ollama”运行该工具，响应是“您可以通过启用 text2vec-ollama 或 generative-ollama 模块来使用 Ollama，两者都用于嵌入模型和生成模块”，或者类似的内容。但这还不是结束，因为构成我们 AI 代理核心的原始 LLM 还不了解响应。
当一个工具运行时，该工具的结果会返回给代理的 LLM。通常，这会作为一条聊天消息提供，其中角色设置为“function call”。因此，我们的 LLM 知道它看到的是响应不是来自用户，而是它决定运行的工具的结果。LLM 然后观察工具（或工具）的结果，以便向用户提供最终答案。
恭喜！到目前为止，您已经学习了 AI 代理的基础知识！特别是那些依赖工具和函数调用的 AI 代理。我喜欢这样想象：作为 AI 代理核心的 LLM 就像一个拥有咒语书但没有魔杖的巫师。LLM 知道它可以做什么，以及如何做，但它除了说出咒语之外什么也做不了。工具仍然必须在 LLM 之外运行。
什么是“Agentic”AI
有很多新的词汇需要适应，这可能会让人感到困惑。但实际上，对于什么是“agentic AI”与什么是“AI 代理”，我们可以让我们的生活更轻松。AI 代理本质上是agentic的，但 AI 代理通常指的是为特定任务设计的最终应用程序。例如，AI 代理可能是一个文档搜索助手，或者是一个可以访问您的电子邮件和 Slack 的个人助手。
然而，当我们说“Agentic AI”时，我们通常指的是一个设计具有 agentic 组件的系统，例如决策 LLM、推理步骤、一些工具、自我反思等。要被认为是 agentic，并不需要拥有所有组件。相反，它通常展示了其中一些组件的特征。
构建 AI 代理的工具
构建 AI 代理需要集成许多组件和工具，以创建一个能够进行自主或半自主决策、交互和任务执行的系统。虽然高级代理可能非常复杂，但即使是最简单的代理也需要一些基本要素。以下是一些可以帮助您开始构建自己的 AI 代理的资源
1. 语言模型提供商：
AI 代理的基础是一个 LLM，它驱动着它的整个推理。它允许代理理解不同的输入并有效地规划其操作。寻找具有内置函数调用支持的 LLM 也至关重要，以便我们可以将其连接到外部工具和 API。流行的 LLM 提供商包括
- OpenAI：GPT 4o, o3-mini
- Anthropic：Claude 3.5 Sonnet, Claude 3.5 Haiku
- Google：Gemini 2.0 Pro, Gemini 2.0 Flash
- Mistral：Mistral Large, Mistral Small 3
- 使用 Hugging Face 或 Ollama 的开源模型
2. 内存和存储：
代理需要某种持久内存才能随着时间的推移保留上下文。内存可以是两种类型
- 短期记忆：跟踪当前对话或手头任务。
- 长期记忆：记住过去的对话、个性化和经验。
目前，今天为代理提供的两种类型的内存都有许多变体和实现，并且随着技术的进步，我们可能会看到更多。例如，对于短期记忆，我们看到实现方式很简单，就是在每次迭代或消息时向 LLM 提供“对话摘要”，以便导航上下文长度限制。对于长期记忆，我们可能选择使用数据库来备份对话。这甚至可能改变像 Weaviate 这样的向量数据库的角色，它们开始被用作 AI 代理可以从中提取最相关的先前对话片段的长期记忆。
3. AI 代理编排框架：
编排框架充当聪明的指挥家，协调 AI 代理的所有组件，甚至管理多代理设置中的多个代理。它们抽象了大部分复杂性，处理错误/重试周期，并确保语言模型、外部工具/API 和内存系统协同工作。
有几个可用的框架可以简化 AI 代理的开发
- Langgraph：提供了一个结构化的框架，用于定义、协调和执行多个代理。
- LlamaIndex：能够创建具有不同复杂程度的复杂、agentic 系统。
- CrewAI：多代理框架，用于编排具有特定角色、工具和目标的自主 AI 代理。
- Hugging Face smolagents：一个库，只需几行代码即可运行强大的代理。
- Haystack：端到端框架，允许您构建由 LLM 驱动的 AI 应用程序，例如代理。
- OpenAI Swarm：一个教育框架，探索符合人体工程学、轻量级的多代理编排。
- AgentKit：一个 TypeScript 库，用于创建和编排 AI 代理。
4. 工具和 API：
一个代理的能力与它可以访问的工具一样强大。通过连接到各种 API 和工具，代理可以与环境交互并执行诸如 Web 浏览、数据检索、数据库查询、数据提取和分析、代码执行等任务。
像 LlamaIndex 这样的框架提供了预制工具集成，例如 PDF、网站和数据库的数据加载器，以及通过 LlamaHub 与 Slack、Google Drive 等应用程序的集成。 类似地，Langchain 也提供了广泛的类似工具，代理可以轻松使用。 此外，开发者可以根据需要构建自定义工具，通过封装 API 来引入全新的功能。 近期的研究，例如 使用函数调用查询数据库，甚至预示着函数调用在数据库查询方面的潜力。
总而言之，构建 AI 代理就像组装拼图。 你从一个好的语言模型开始，添加合适的工具和 API 集，然后添加记忆，以便代理记住重要信息。 可以使用编排框架来简化流程并将所有内容联系起来，确保每个部分都能完美发挥作用。
AI 代理的未来展望：挑战与进展
AI 代理和代理 AI 的优点在于它仍在不断发展。 尽管我们在这里没有讨论很多内容，例如我们看到的挑战，以及实际构建用于生产的 AI 代理的其他核心组件，例如可观察性，但关于 AI 代理的未来，仍然有一些值得强调的事情。
例如，你可能已经注意到，除非我们花时间有意识地设计我们的代理应用程序，否则似乎很多（太多？）依赖于 LLM 做出正确的判断。 如果代理可以访问搜索工具或知识库，这可能没问题。 但是，如果该工具可以访问你的银行账户，并且代理现在可以为你购买一张非常昂贵的单程票去夏威夷怎么办？
我一直在认真倾听的一个争论是，AI 代理的使用是作为“研究助手”还是作为“我们意志的执行者”。 这是一个简单但重要的争论，而且随着 LLM 变得更好，以及我们在 AI 领域拥有更好的法规和护栏，我们的观点可能会随着时间而改变。
自主级别与人工参与
现在你了解了 AI 代理最基本形式下的运作方式。 但让 LLM 编排一切 不一定（或不建议）这样做。 我们已经看到越来越多的代理将流程委托给更简单、更确定的系统。 在某些情况下，甚至委托给人类。 例如，我们可能会看到更多的人需要在采取行动之前获得人类批准的情况。
我们甚至看到像 Gorilla 这样的工具实现了具有“撤销”功能的代理，允许人类决定是否应该回溯某个操作，从而为流程增加一层人工干预。
多模态 AI 代理
多模态指的是能够利用多种模态的能力，即超越仅仅语言（文本）的能力，并结合图像、视频、音频等。 在某种程度上，技术在很大程度上已经存在。 因此，我们可能会开始看到越来越多的 AI 代理可以与各种媒介进行交互，无论是作为其工具的一部分，还是如果它们使用多模态 LLM 的话。 想象一下，你可以要求 AI 代理“创建一个可爱的猫视频并将其转发到我的电子邮件”！
向量数据库的作用
另一个有趣的话题，尤其是对于我们 Weaviate 来说，是向量数据库在 AI 中的潜在作用的扩展。 到目前为止，我们主要看到向量数据库被用作代理可以访问的知识来源。 然而，可以想象未来我们使用向量数据库以及其他类型的数据库作为代理交互的记忆资源。
AI 代理的示例和用例
AI 代理正在重塑我们的工作方式，这种变化已经在多个行业中显现。 当我们需要完美融合对话和行动时，它们才能发挥最大的作用。 通过自动化重复性任务，它们不仅提高了工作效率，还改善了整体用户体验。 以下是一些 AI 代理在实际应用中的示例
AI 研究代理
AI 研究代理或研究助手简化了分析大量数据、发现趋势和生成假设的过程。 今天，我们已经看到学术界或职场中的人们使用 ChatGPT 作为伴侣来帮助他们收集信息、帮助他们构建思路并为许多任务提供第一步。 在某种程度上，ChatGPT 在其原始形式本身就是一个研究助手代理。 这些代理有时也被称为 “代理 RAG”，其中 AI 代理可以访问多个 RAG 工具，每个工具访问不同的知识库。
客户服务代理
AI 客户服务代理提供 24/7 全天候支持，处理咨询、故障排除并提供个性化互动。 它们可以减少等待时间，并让人工代理处理更复杂的任务。 它们既可以作为客户的研究助手，更快地获取答案，也可以为他们完成任务。
营销与销售代理
这些代理通过分析客户数据、个性化外展和自动化重复性任务（如潜在客户资格认定和电子邮件跟进）来优化营销活动和销售流程。
代码助手代理
这些代理通过建议代码、调试错误、解决工单/问题，甚至构建新功能来帮助开发人员。 这使开发人员可以节省时间并专注于创造性问题解决。 Cursor 和 Copilot 已经有这方面的例子。
总结
本文概述了我们在 2025 年所说的“AI 代理”的总体概念，并简单介绍了它们的工作方式。 尽管我们没有深入研究不同的“代理工作流程”的所有技术细节，但另一篇深入技术细节的博客文章即将发布！ 我们将介绍有助于理解 AI 代理的基本组件，例如提示、工具、观察工具响应以及推理最终答案。 最后，我们展望 AI 代理的未来，讨论当前的不足以及我们可以预期的进展。
博客中提到的许多历史概述也是我（Tuana）在过去几年中的主观看法。 如果你认为我遗漏了关键步骤，请告诉我（X 上的 DM 已打开 X）
准备开始构建了吗？
请查看 快速入门教程，或使用 Weaviate Cloud (WCD) 的免费试用版构建令人惊叹的应用程序。