通往 AGI 之路前传：究竟该怎么理解 Agent？

显示全部楼层

关于大模型，玄妙之事很多。比如大家都认为 2025 年是 Agent 爆发年，但是要问 Agent 是什么，怎么定义 Agent 时，一千个人眼中能有一千个 Agent 的概念。Manus 让 Agent 具象化了一些，而 OpenAI 在发布 Agent 开发工具时，给出了两个定义：Agent 是能够独立为用户完成任务的系统[1]；配备了指令和工具的大语言模型[2]。怎么感觉就算 OpenAI 自己的团队都没有把 Agent 的定义统一清楚呢？！

相对来说比较明确的定义是：Agent 可以理解为某种能自主理解、规划决策、执行复杂任务的系统。简单来说就是它可以自主规划并利用工具实现复杂的任务。

从一个应用开发者的角度来看，Agent 就是一种由AI 驱动的应用程序，当然，也有很多人认为 Agent 就是智能时代的 App 形态，并预测今天我们所有的互联网行为都将变成由 Agent 来完成。在本文中，我们尝试理清 Agent 的来龙去脉，首要是解自己之惑，也希望能够对读到本文的朋友有所帮助。

1. 大语言模型：LLMs

要搞清楚 Agent，那首先得看大语言模型：Large Language Models，类似于人的大脑。先来看看 LLMs 的运行原理：

模型以 N 个 Token 作为输入，并生成一个 Token 作为输出，将输出的 Token 与原来的输入拼接到一起，作为新的输入给到大模型，如此循环，直到模型输出结束的 Token。

从其执行原理可以看出，LLMs 无法获取到除训练知识以外的其它知识，也无法保存会话状态，当然也无法调用外部工具。

2. 知识问答助手：RAG、Agentic RAG

当我们为 LLMs 保存会话上下文，让它拥有了短暂“记忆”，便有了现在各种的大模型产品。重新定义了知识获取的方式，只需要和它聊聊天，就可以解答我们各种各样的问题。但在这个时候，还存在一些问题：

LLMs 的知识库是固定的，随着时间的流动，产生出来的新知识它是无法知道的 —— 这就是为什么我们常常会看到许多模型存在时效性的问题；
众所周知的幻觉，当出现模型训练时未出现的知识时，大模型会一本正经地胡说八道。

为了让大模型为我们生成更符合要求的答案，减少幻觉，RAG 的技术体系应运而生，许多人称其为实现大模型应用落地的最后一公里。

在 RAG 的模型中，我们将大模型本身不具备的知识（私有知识库中的内容），通过相关性查询到与用户问题的信息，将这些信息与用户问题进行拼装，作为输入给到大模型，从而约束大模型的输出结果，以此来为我们提供超出预期的体验。

通过 RAG，我们扩展了大模型的能力。但是，就 RAG 技术也有分层了。由于推理模型的大行其道，许多人说传统的 RAG 已经过时，现在已经进入了 Agentic RAG 的阶段，简单来说就是融合了 Agent 能力的 RAG 架构，通过动态规划、多步骤推理和自主决策机制，能够完成复杂任务的闭环。

图源：Zilliz

我还是得感慨一句：大模型真是太卷了，相比愁技术学不过来，可能更关键的是在学的这项技术可能要过时了，当然，更狠的是，刚学会，技术已经过时了 Orz。。。

3. 大模型的手和脚：工具

当你需要将一颗钉子钉到墙上时，家里面有锤子、扳手、电锯等很多工具，你这个时候会选择用锤子，砰、砰、砰几下，钉子就被钉在墙上。

大模型只是一个「脑子」，它擅长处理信息，但缺乏直接感知和影响现实世界的能力。与 RAG 类似，我们可以通过给大模型建造工具，从而将大模型与现有的软件世界与物理世界建立联系，实现大模型能力的扩展。

再来回顾一下 RAG 的工作流程：

从流程中，可以看到，我们通过前置的一些手段，对用户提示词进行改变，为大模型提供更多的信息，最终实现我们的问答机器人。

那有没有一种可能，大模型通过推理，需要进行一些外部资源获取，在给用户内容输出时，进行外部工具调用，最后再输出结果呢？像下面这个流程：

当然，我们可以让我们的「应用」按照这个流程去运行。在这个图中，有两个重要的信息：

工具描述信息
工具调用

这两块内容是什么东西呢？

3.1 工具描述信息

大模型如同一个高度智能的“大脑”，具备强大的推理能力。然而，它不能很好地与外部系统进行交互，肯定也无法知道有什么工具可以使用。为了让大模型有效地使用这些工具，我们需要在提示词中包含了工具的详细描述信息，让大模型了解每个工具的功能和使用方法。

当前，对于工具描述信息一般包含以下几个信息：

name（名称）：这是工具的唯一标识符，就像工具的“名字”一样。当大模型决定调用某个工具时，它会输出这个名称，以便系统准确地执行相应的操作。
description（描述）：这是对工具功能的详细解释，相当于工具的“说明书”。它告诉大模型这个工具是用来做什么的，可以解决哪些问题，有哪些优势和局限性。
parameters（参数）：这是调用工具时需要提供的参数信息，就像工具的“操作指南”。它告诉大模型在使用工具时需要提供哪些输入，以及这些输入应该是什么格式和类型。

通过将这些工具描述信息融入提示词中，我们可以让大模型充分了解可用的工具，并在需要时使用这些工具。

3.2 Function Calling

再来回忆一下：大模型本身不具备执行工具的能力，但它可以生成工具名称和执行工具所需的参数信息，因此，我们可以将函数执行的交由一个系统完成，工具执行完成后，将执行结果返回给大模型，大模型再次根据结果综合回答问题。

OpenAI 就开放了 Function Calling 的方式，用于扩展大模型的能力。以获取天气信息为例，一起来看看 Function Calling 的执行过程：

在运行这个流程之前，我们可以简单定义一个python函数，用于实现天气信息获取：

importrequests
defget_weather(location):
 """
  获取指定城市的的温度
 
  参数:
  location (str): 城市名
 
  返回:
  dict: 包含温度信息的字典
  """
  base_url ="https://api.example.com/weather"
 
 # 构建 API 请求
  params = {"q": location}
  response = requests.get(base_url, params=params)
  response.raise_for_status() # 如果请求失败，这将引发一个异常
  weather_data = response.json()
 returnweather_info

在流程的第一步，按照 OpenAI 的要求的格式，描述这个工具：

tools = [{
 "type":"function",
 "function": {
   "name":"get_weather",
   "description":"Get current temperature for a given location.",
   "parameters": {
     "type":"object",
     "properties": {
       "location": {
         "type":"string",
         "description":"City and country e.g. Bogotá, Colombia"
        }
      },
     "required": [
       "location"
      ],
     "additionalProperties": False
    },
   "strict": True
  }
}]

然后通过 API ，将请求发送给大模型：

completion = client.chat.completions.create(
  model="gpt-4o",
  messages=[
    {
     "role":"user",
     "content":"What is the weather like in Paris today?"
    }
  ],
  tools=tools
)

模型会根据问题和提供的工具描述信息，自动判断是否需要调用工具，此时模型会返回返回工具调用的请求，如下：

{
 "id":"call_12345xyz",
 "type":"function",
 "function": {
   "name":"get_weather",
   "arguments":"{\"location\":\"aris, France\"}"
  }
}

接收到这个信息后，表示需要执行一次工具调用，此时，我们需要在本地完成get_weater的调用，并将结果返回给模型：

{
"role":"function",
"name":"get_weather",
"content":"{\"tempture\": 14}"
}

管中窥豹，通过 Function Calling 的流程，可以相对清晰地感知到大模型与工具交互的流程。

3.3 MCP 开放协议

对于现如今软件世界来说，我们有很多「工具」可以供外部调用，但要将这些工具与大模型打通，还需要很多工程化的工作需要做。

在 2024 年， Anthropic 发布了一个开放协议： Model Context Protocol (MCP) ，实现在 AI 应用程序与本地或远程资源之间实现安全、受控的交互。其核心是一个client-server架构，MCP 主机应用程序可以连接到多个服务。

MCP 架构

一个开放的协议，将Host与Server分离开，作为服务的提供方，我可以去专注的开发我的原子能力，而作为Host的开发者，不用再考虑我要实现什么功能，需要做很多的开发工作。通过 MCP，打破原子能力之间的壁垒，快速实现多原子能力的融合。

4. 智能体

最后，我们回到本文最重点的内容，什么是 Agent：可以自主规划并利用工具实现复杂的任务目标。通过 LLM，将记忆、规划、工具、行动串联起来，组成一个复杂的系统，就组成了一个 Agent。

作为程序员，看到这个图后，最直观的感受就是：Agent 系统就是一个基于 LLM 的工程化产品，将 LLM 的能力通过软件的方式提供出去。在整套系统中，工具、记忆是其关键的部分，但我觉得最为关键的是，把记忆、工具、规划、行动这些部分连起来的线，只有一个良好的架构，才能将不同的能力组合到我们的 Agent 上，最终完成一些看起来不可能完成的任务。

准备好构建你的 Agent 了吗？