如果你身处 AI 领域，最近你可能会频繁听到 AI Agent（代理、智能体）这个词。在本文中，我们将深入探讨当我们在大型语言模型（LLM）和人工智能（AI）的语境中提到 Agent 时，究竟是什么意思。
在我们深入讨论之前，有一点需要记住，那就是 Agent 这个词在今天的高性能 LLM 出现之前就已经存在了。我们甚至可以说，AI Agent 早就存在了，只是没有以今天的生成型 LLM 作为核心。然而，发生了变化的是它们变得更强大和复杂了。因此，简而言之，你现在听到更多关于 Agent 的讨论，并不是因为它们是全新的技术，而是因为它们变得非常、非常有趣。
什么是 AI Agent ?
从基础层面上看，今天的 AI Agent 是一个半自动或完全自动的系统，它使用 LLM 作为“大脑”来进行关键决策和解决复杂任务。你可以把它们看作是自动化的决策引擎，这样你作为用户，只需要提出你的查询。它们会在可用的工具环境中运作，使用各种工具来为你完成任务，让你可以坐下来放松，等着它处理问题。
Agent 会自主地指挥自己的流程和执行，选择根据当前任务使用哪些工具。这些工具可以包括网页搜索引擎、数据库、API 等，使得 Agent 能够与现实世界进行互动。
AI Agent 简史
AI Agent 实际上已经存在很长时间了。你甚至可以在微软最近发布的关于 AI Agent 的文章[1]中看到，作者提到他们早在 2005 年就开始研究 AI Agent。然而，近年来，尤其是得益于最新的 LLM 的能力，我们的 AI Agent 形态和功能有了显著变化。现在，我们能够将 LLM 作为核心组件，来进行规划、推理和执行。
既然如此，我想突出一下近年来 AI Agent 的几个里程碑，你可以认为从这里开始我们只讨论今天（2025年）的 AI Agent。当然，这是我回顾过去几年的个人经验。不过，让我们把时钟拨回到 ChatGPT 发布之前。2020 年，有两篇论文可以视为现代 AI Agent 的开端，这些 AI Agent 将 LLM 作为核心决策组件：
MRKL Systems：读作“miracle systems”（“奇迹系统”），这篇论文主要集中在语言模型的局限性上，研究了为什么我们会得到如此多的虚假响应。简单来说，论文指出了我们现在完全理解的事实：语言模型并不懂得所有事情，它们的设计目的是生成语言。可以这么理解，我们不能期望别人知道我们的生日，除非我们告诉他们。这篇论文提出了一种方法，可以为语言模型提供外部知识库，让它们能够查询并提取相关信息。[2]
ReAct：这篇论文稍微晚于 MRKL 系统发布，介绍了一个对今天 Agent 至关重要的组件。ReAct 代表“Reason and Act”（推理和行动），它提出了一种巧妙的提示结构，使得 LLM 能够考虑问题、推理解决方案、选择合适的工具并付诸实施。简单来说，举个例子：不仅仅提出问题，还告诉模型它可以使用哪些资源，并要求它制定解决查询的计划。简而言之，这篇论文介绍了一种新的思考方式，使得 LLM 的推理和行动过程更加可靠。[3]
注意：论文中推荐的实际 ReAct 提示比这更为复杂，包含了如何生成思维、如何推理等指令。
在我看来，这两篇论文突出了两个非常重要的发现和特征，它们促成了今天的 AI Agent：良好的指令和外部工具。再加上成千上万的人开始尝试这些 LLM，现在我们已经进入了一个世界，我们开始构建越来越复杂的 AI Agent（这些 Agent 不仅仅使用 ReAct 提示方法）。
接下来，让我们看看今天的 AI Agent 由哪些核心组件构成。
AI Agent 的核心组件
虽然并非每个 AI Agent 都必须包含所有这些组件，但当我们构建 Agent 时，至少会包括以下几个组件和过程：LLM、访问工具（通过函数调用）、一定程度的记忆和推理。
让我们深入了解它们各自的作用：
LLM：可以把 LLM 看作是整个操作的“大脑”。虽然并非每一步都由它来负责，但当我们提到 2025 年的 Agent 时，生成模型在操作中扮演着重要的协调角色。简单来说，回到上面提到的例子：正是 LLM 决定了首先查找用户的日历，然后再查看天气。
工具：Agent 的一个重要特点是它们通过不同的工具与环境互动。可以将这些工具视为“附加组件”，使 Agent 更加高效。这些工具让 Agent 超越 LLM 的固定训练知识，通过提供高度相关的实时数据（例如个人数据库）和能力（如发送电子邮件），拓宽了它们的应用范围。通过函数调用，LLM 可以直接与预定义的一组工具交互，从而扩大 Agent 的操作范围和效率。
记忆：Agent 通常具有某种形式的记忆（包括短期和长期记忆），允许它们存储推理过程的日志、对话历史或在不同执行步骤中收集的信息。我们需要记忆来支持与 Agent 的持续对话，以及那些我们希望稍后再回来的对话。记忆可以用来个性化体验或规划未来的决策。
观察与推理：LLM 是问题解决、任务分解、规划和路径选择的核心组件。它允许 Agent 推理一个问题，将其分解为更小的步骤（如果需要），并决定如何以及何时使用可用的资源/工具来提供最佳解决方案。然而，并不是每个 Agent 都一样，有时我们会在构建 Agent 时显式地将推理作为过程的一部分。
一个重要的要点是，AI Agent 有多种设计模式，这些组件可以在不同程度上使用。我们今天看到的 Agent 处于一个连续体上，它们的自主性或 Agent 行为”很大程度上取决于将多少决策权委托给 LLM。简单来说：一些 Agent 设计得更加独立，而另一些则依赖于更多的外部输入和控制。
AI Agent 是如何工作的 ?
今天我们看到的大多数 AI Agent 使用 LLM 作为核心决策者/操作协调者。LLM 的自主性程度当然有所不同，我们将在本文的“未来展望”部分进一步讨论。但首先，让我们从基础开始，讨论一下一个主要依赖 LLM 做出大部分决策的 AI Agent 是如何工作的。
我注意到，最近当人们讨论 LLM 和 Agent 时，似乎有很多“魔法”在背后发生。所以，在这里，我将尽力解释一下，一个能够访问某些工具的 AI Agent 背后到底发生了什么。
定义提示（Prompt）
任何使用 LLM 的系统的核心都是一个指令（提示），它为 LLM 设定了其核心目的。ReAct 论文也通过突出一个复杂的提示，清晰地展示了如何定义一个推理、生成思维和观察的 Agent。例如，我们可以给 LLM 这样的指令：“你是一个有用的助手，可以访问我的数据库，以便回答我的查询。”
提供工具
接下来，我们需要为 LLM 提供一个工具列表。这是目前创建 AI Agent 最常见的方式之一，尽管它并非总是必要的，我们仍然可以在没有工具和函数调用的情况下创建具有 Agent 功能的系统。如今大多数模型提供商都支持“函数调用”，这让我们能够设置与 LLM 的交互，列出它在任何时候都可能使用的工具，以便解决查询。
当我们为 LLM 提供工具时，我们需要告诉 LLM 一些信息。LLM 利用这些信息来决定何时使用工具：
名称：例如，一个工具可能叫做 technical_documentation_search。
描述：这是模型在推理时用来判断使用哪个工具的最重要信息。例如，对于 technical_documentation_search 工具，我们可以提供描述：“当你需要搜索内部技术文档以寻找答案时非常有用”。
预期输入：记住，工具是外部于 LLM 的。LLM 知道它们的名称，也知道它们的描述，但归根结底，生成型语言模型的任务是生成语言。那么它能做什么呢？它能做它擅长的事情！它可能生成一个内容，返回一个函数（工具）的名称，以及它运行所需的预期输入。因此，当我们提供工具列表时，我们还需要提供这些信息。例如，对于我们的 technical_documentation_search 工具，我们可以告诉 LLM，它需要 query: str 作为输入。
如果你有兴趣了解这个在实际操作中是如何工作的，你可以查看 OpenAI 的函数定义文档：
https://platform.openai.com/docs/guides/function-calling
使用工具
所以，我们有了 LLM，LLM 知道它可以访问一些工具，知道如何运行它们，以及它们的用途。然而，LLM 并没有固有的能力去执行比如运行 Python 脚本……或者搜索你的文档。不过，它可以提供一个消息，解释它打算运行哪个工具，并且告诉我们它希望使用哪些输入来运行该工具。
让我们用以下场景举个例子：
我们有一个使用 LLM 的 AI Agent。
我们提供了 technical_documentation_search 工具，预期输入为 query: str。并且描述是“当你需要搜索内部技术文档以寻找答案时非常有用”。
用户提问：“嘿，怎么将 Ollama 与 DeepSeek R1 一起使用？”
在这个场景中，实际发生的事情是：
LLM生成一个回复，简化为：“运行工具 technical_documentation_search，query = "Using Ollama and DeepSeek R1"。”
实际上，LLM 使我们的 AI Agent 应用程序走出了自己的“世界”。它指示系统去引用一个外部资源。
观察工具响应
如果一切顺利，到这一步，你的 AI Agent 已经运行了一个工具。记住，这个工具可以是任何东西。例如，我们的 technical_documentation_search 工具本身可能是一个 RAG（Retrieval Augmented Generation，检索增强生成）应用程序，它本身使用另一个 LLM 来生成查询的响应。重点是，最终我们可能通过查询“Using Ollama and DeepSeek R1”运行了该工具，响应是“你可以通过启用 ollama pull deepseek-r1 来拉取 DeepSeek R1 模型，并通过 ollama run deepseek-r1 来运行 DeepSeek R1 模型”，或者类似的内容。但这还不是结束，因为构成我们 AI Agent 核心的原始 LLM 还没有得到响应。
当工具运行时，工具的结果会返回给 Agent 的 LLM。通常，这会作为一个聊天消息提供，角色设置为“函数调用”。所以，LLM 知道它看到的响应不是来自用户，而是它决定运行的工具的结果。然后，LLM 观察工具（或多个工具）的结果，向用户提供最终答案。
恭喜你！
到这一步，你已经了解了构成 AI Agent 的基础，尤其是那些依赖工具和函数调用的 Agent。我喜欢将其比作这样：LLM 作为 AI Agent 的核心协调者，就像一个拿着魔法书却没有魔杖的巫师。LLM 知道自己能做什么，也知道怎么做，但它做不到的更多的是仅仅说出咒语。工具依然需要在 LLM 之外运行。
什么是 Agentic AI ?
首先 Agentic 是一个形容词。
有很多新的术语需要适应，这可能会让人感到困惑。但实际上，当我们讨论 Agentic AI 和 AI Agent 时，我们可以让自己更加轻松地理解。AI Agent 本身就是一种 Agentic AI，但 AI Agent 通常指的是一个为特定任务设计的最终应用程序。例如，AI Agent 可能是一个文档搜索助手，或者是一个能够访问你邮箱和微信的个人助手。
然而，当我们说 Agentic AI 时，通常指的是一个设计上包含了诸如决策性 LLM、推理步骤、可能的一些工具、自我反思等 Agentic 组件的系统。为了被认为是 Agentic 的，它不需要具备所有这些组件，而是通常展示了其中某些组件的特征。
构建 AI Agent 的工具
构建 AI Agent 需要整合多个组件和工具，尤其是要创建一个能够进行自主或半自主决策、交互和任务执行的系统。尽管高级的 Agent 可能非常复杂，即使是最简单的 Agent 也需要一些基本元素。以下是一些可以帮助你开始构建 AI Agent 的资源：
1. 语言模型提供商
AI Agent 的基础是 LLM，它为 Agent 提供整个推理能力。LLM 让 Agent 能够理解不同的输入并有效地规划其行动。选择一个支持内建函数调用的 LLM 也非常重要，这样我们就能将它连接到外部工具和 API。常见的 LLM 提供商包括：
OpenAI: GPT-4, o3-mini
Ali: Qwen-2.5，DeepSeek-R1, llama-3 等
Google: Gemini 2.0 Pro, Gemini 2.0 Flash
Mistral: Mistral Large, Mistral Small 3
使用 Hugging Face 或 Ollama 的开源模型
2. 记忆与存储
Agent 需要某种形式的持久性记忆来保存上下文。记忆可以分为两种类型：
短期记忆：用于跟踪当前的对话或正在进行的任务。
长期记忆：用于记住过去的对话、个性化信息和经验。
目前，Agent 的短期和长期记忆都有很多不同的实现方式，随着技术的进步，我们可能会看到更多的变种。例如，针对短期记忆，我们可以通过向 LLM 提供“对话摘要”来帮助它管理上下文长度限制。对于长期记忆，我们可能选择使用数据库来备份对话。这可能会改变像 Weaviate 这样的向量数据库的角色，AI Agent 可以从中提取最相关的先前对话内容被用作长期记忆。
3. AI Agent 编排框架
编排框架就像是智能指挥官，协调 AI Agent 的所有组件，甚至在 Multi-Agent（多 Agent）设置中管理多个 Agent。它们抽象掉了大部分复杂性，处理错误/重试循环，并确保语言模型、外部工具/API 以及记忆系统能够顺利协同工作。
目前有几个框架可以简化 AI Agent 的开发：
Langgraph：提供一个结构化的框架，用于定义、协调和执行多个 Agent。
LlamaIndex：使得创建具有不同复杂度的复杂 Agent 系统成为可能。
CrewAI：一个多 Agent 框架，用于编排具有特定角色、工具和目标的自主 AI Agent。
Hugging Face smolagents：一个使你能在几行代码中运行强大的 Agent 的库。
Haystack：一个端到端框架，允许你构建像 Agent 这样的 AI 应用，支持 LLM。
OpenAI Swarm：一个教育框架，探索符合人体工程学的轻量级多 Agent 编排。
4. 工具与 API
Agent 的能力取决于它能访问的工具。通过连接各种 API 和工具，Agent 可以与环境进行互动，执行诸如网页浏览、数据检索、数据库查询、数据提取与分析、代码执行等任务。
像 LlamaIndex 这样的框架提供了现成的工具集成，例如 PDF、网站和数据库的数据加载器，以及像 Slack、Google Drive 这样的应用程序集成。类似地，Langchain 提供了广泛的工具供 Agent 使用。此外，开发者还可以根据需要构建自定义工具，通过包装 API 来引入全新的功能。最近的研究，例如《通过函数调用查询数据库》[4]，甚至暗示了函数调用对数据库查询的潜力。
总的来说，构建 AI Agent 就像拼装一个拼图。你从一个良好的语言模型开始，添加合适的工具和 API，然后加入记忆功能，让 Agent 记住重要的东西。可以使用编排框架来简化流程，并将各个部分结合在一起，确保每个部分都能完美配合。
AI Agent 的未来：挑战与机遇
AI Agent 和 Agentic AI 的一个伟大之处在于它仍在不断发展。尽管我们在这里没有讨论所有的挑战，以及构建实际生产环境中的 AI Agent 所涉及的其他核心组件，如可观察性，但有几件事可能值得强调，特别是关于 AI Agent 的未来。
例如，你可能已经注意到，除非我们花时间刻意设计我们的 Agentic 应用程序，否则可能会发现很多（也许是过多）依赖于 LLM 做出正确的决策。如果 Agent 可以访问搜索工具或知识库，或许没问题。但如果这个工具可以访问你的银行账户，而 Agent 现在能为你购买一张非常昂贵的单程机票去夏威夷呢？
我最近一直在听的一个辩论是，AI Agent 的使用是否更多的是作为“研究助手”，还是作为“我们意图执行者”。这是一个简单但重要的辩论，可能随着 LLM 的不断改进以及我们在 AI 领域拥有更好的规范和限制，我们的看法也会发生变化。
自主性等级与人类介入
现在你理解了一个最基本的 AI Agent 是如何操作的。但并不一定（或不建议）让 LLM 成为一切操作的协调者。我们已经开始看到越来越多的 Agent 将过程委托给更简单、更确定的系统。在某些情况下，这些过程甚至委托给人类。例如，我们可能会看到越来越多的场景，要求人类在某个操作发生之前进行批准。
我们甚至看到像 Gorilla 这样的工具实现了具有“撤销”功能的 Agent，允许人类决定是否回退某个操作，从而将人类介入（Human in Loop）添加到整个过程当中。[5]
多模态 AI Agent
多模态指的是能够使用不止一种模态，也就是超越语言（文本），包括图像、视频、音频等。技术在这方面基本上已经到位。因此，我们可能会看到越来越多的 AI Agent 能够与各种媒介互动，或者作为其工具的一部分，或者如果它们使用多模态 LLM，则天生具备这些功能。想象一下一个 AI Agent，你可以让它“创建一段可爱的小狗视频，并发送到我的邮箱！”
向量数据库的作用
另一个有趣的话题是向量数据库在 AI 中的作用可能会扩展到什么程度。目前，我们主要看到向量数据库作为 AI Agent 可以访问的知识源。然而，很容易想象一个未来，我们将向量数据库以及其他类型的数据库，作为 Agent 交互的记忆资源。
AI Agent 的实例和应用场景
AI Agent 正在重塑我们的工作方式，这种变化已经在多个行业中可见。当我们需要完美结合对话和行动时，AI Agent 最为闪耀。通过自动化重复任务，它们不仅提高了工作效率，还改善了整体用户体验。以下是一些实际应用的 AI Agent 实例：
1. AI 研究助手
AI 研究助手，可以简化分析大量数据、识别趋势和生成假设的过程。今天，我们已经看到学术界或职场中的人们，使用 ChatGPT 作为助手，帮助他们收集信息、构建思路，并在许多任务中提供第一步。可以说，ChatGPT 本身就是一个研究助手 Agent。这些类型的 Agent 有时也被称为 Agentic RAG，即 AI Agent 可以访问多个 RAG 工具，每个工具访问不同的知识库。
2. AI 客户服务
AI 客户服务 Agent 提供24/7的支持，处理查询、故障排除和提供个性化互动。它们减少了等待时间，让人类能处理更复杂的任务。它们既可以作为客户的研究助手，快速为其提供答案，也能为客户完成任务。
3. 营销与销售 Agent
这些 Agent 通过分析客户数据、个性化推广和自动化重复任务（如潜在客户资格认证和邮件跟进）来优化营销活动和销售流程。
4. 代码助手Agent
这些 Agent 通过建议代码、调试错误、解决工单/问题，甚至构建新特性来帮助开发者。这使得开发者能够节省时间，专注于创造性问题解决。像 Cursor 和 Copilot 这样的工具就是其中的例子。
