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

本文链接：https://blog.youkuaiyun.com/Python_cocola/article/details/146590093

关于大模型，玄妙之事很多。比如大家都认为 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 执行流程

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

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

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

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

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

基础RAG流程基础 RAG 流程

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

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

图源：Zilliz

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

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

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

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

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

RAG 工作流程简图

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

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

工具调用流程

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

工具描述信息
工具调用

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

3.1 工具描述信息

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

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

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

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

3.2 Function Calling

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

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

获取天气信息

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

import requests
def get_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()
    return weather_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\":\"Paris, 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 上，最终完成一些看起来不可能完成的任务。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述