AI Agent

是什么

大模型的发展已经卷入了下半场，很多公司都已经从「卷模型」转向了「卷智能体」

尤其是最近 Manus 火了之后，关注 AI Agent 的人又多了很多

AI Agent，直译为「AI 代理」，也称为「AI 智能体」

想象一下这个场景：

你需要查一下明天的天气，于是，你问 AI：

你：明天的天气怎么样？
AI：抱歉，我无法获取明天的天气，但是您可以通过 xxx 网站进行查询

也就是说，基于 Chat 模式时，由于 AI 的知识库只能截止到某一时间点，是无法获取最新天气的数据的，但是它会教你如何查询最新的天气信息

为了解决这一问题，AI Agent 出现了，就像字面意思一样，它代替人类去查询了天气，成为了代理。于是乎，有了以下对话：

你：明天的天气怎么样？
AI：经过查询，明天的大致气温为 19℃，降水概率……

简单来说，AI Agent 就是能让大模型（LLM）有一定的动手能力，替用户进行交互，最终自动化地完成任务

AI 等级

OpenAI 对 AI 等级的界定如下：

L1，是 Chatbots（聊天机器人，里程碑：ChatGPT3.5）

L2，是 Reasoners（推理者，如 DeepSeek、GPTo1-o3 等模型）

L3，是 Agents，也就是这篇文章的主要内容，OpenAI 对其的定义是「可以采取行动的系统」

构成

AI Agent 的构成如下：

记忆
- 长期记忆
  如 LLM 训练集中的数据，就是一种长期记忆
- 短期记忆
  如在 System Prompt 中给定的信息，只能短期记忆，对话长度（上下文长度）超限后，LLM 就会忘记
工具
一些接口，LLM 可以在有需要时自己调用，来进行信息获取或执行操作
规划决策
如思维链等，可以更好地处理复杂任务
行动
通过长短期记忆的结合，分解用户提出的任务，进行思考，作出规划，调用合适的外部工具付出行动

Agent = LLM + 记忆 + 规划技能 + 工具使用

实现

目前实现 AI Agent 的方式主要有两种，API（使用 Function Calling 实现）和 GUI

Function Calling

即「函数调用」，也就是开发者手写了一些函数，让 LLM 在有需要时进行调用，最终实现某些功能

实现思路

如上面提到的查询天气的例子，为了让用户能够顺利的查询到天气，我们可以写三个函数：

getPosition()
调用该函数后，获得用户所在位置
getDate()
调用该函数后，获得当前日期
getWeather(地点, 日期)
传入地点、日期后，获得天气详情

设置一个这样的 System Prompt：

当用户需要查询天气时，你可以调用 getPosition()、getDate()、getWeather(地点, 日期)，获取最新的天气。

此时，用户只要提问关于天气的问题，LLM 就会思考是否应该调用这几个函数，如果需要调用，那么就会按照 获取位置 → 获取日期 → 获取天气 的步骤执行，最终获得最新的天气数据

具体实现

我们可以定义这样一段工具描述：

functions = [
    {
        "name": "getPosition",
        "description": "获取用户当前位置",
        "parameters": {"type": "object", "properties": {}}
    },
    {
        "name": "getDate",
        "description": "获取当前日期",
        "parameters": {"type": "object", "properties": {}}
    },
    {
        "name": "getWeather",
        "description": "查询指定地点和日期的天气",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string"},
                "date": {"type": "string"}
            },
            "required": ["location", "date"]
        }
    }
]

一共三个函数，分别执行 获取用户位置、获取当前日期、查询天气 的操作

用户提问时，消息列表变为：

messages = [
    {"role": "user", "content": "明天的天气怎么样？"}
]

创建一个对话：

response = openai.chat.completions.create(
    model="deepseek-chat",
    messages=messages,
    functions=weather_functions  # 上面定义的工具描述
)

模型响应：

{
  "role": "assistant",
  "content": null,
  "function_call": {
    "name": "getPosition",
    "arguments": "{}"
  }
}

将该响应添加到消息列表，此时的消息列表变更为：

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 新增 getPosition 调用请求
    {
        "role": "assistant",
        "content": null,
        "function_call": {
            "name": "getPosition",
            "arguments": "{}"
        }
    }
]

最新的一条消息中有 function_call 字段，此时触发函数执行，返回用户位置并将其包装成对象后放入消息列表

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    {"role": "assistant", "content": null, "function_call": {...}},
    # 需要指定具体的函数名 name，LLM 才知道「昆明」是哪个函数的返回值
    {"role": "function", "name": "getPosition", "content": "昆明"}
]

再次调用 API，模型返回：

{
  "role": "assistant",
  "content": null,
  "function_call": {
    "name": "getDate",
    "arguments": "{}"
  }
}

消息列表更新为：

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 获取地点
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getPosition", "content": "昆明"},
    # 新增 getDate 调用请求
    {"role": "assistant", "content": null, "function_call": {"name": "getDate", ...}}
]

最后一条消息中包含 function_call 字段，触发函数执行，返回当前时间并包装成对象添加到消息列表

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 获取地点
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getPosition", "content": "昆明"},
    # 获取日期
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getDate", "content": "2025-03-16"}
]

此时再次调用 API，返回：

{
  "role": "assistant",
  "content": null,
  "function_call": {
    "name": "getWeather",
    "arguments": {
      "location": "昆明",
      "date": "2025-03-16"
    }
  }
}

消息列表更新：

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 获取地点
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getPosition", "content": "昆明"},
    # 获取日期
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getDate", "content": "2025-03-16"},
    # 新增 getWeather 调用请求
    {"role": "assistant", "content": null, "function_call": {"name": "getWeather", ...}}
]

再次触发函数，返回天气查询结果，最终消息列表：

messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 获取地点
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getPosition", "content": "昆明"},
    # 获取日期
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getDate", "content": "2025-03-16"},
    # 获取天气
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getWeather", "content": "晴，气温18-25℃"}
]

此时模型会根据完整消息列表生成自然语言回复，并添加到消息列表：


messages = [
    {"role": "user", "content": "明天的天气怎么样？"},
    # 获取地点
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getPosition", "content": "昆明"},
    # 获取日期
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getDate", "content": "2025-03-16"},
    # 获取天气
    {"role": "assistant", "content": null, "function_call": {...}}, 
    {"role": "function", "name": "getWeather", "content": "晴，气温18-25℃"},
    # 最终回复
    {"role": "assistant", "content": "明天昆明晴，气温18到25摄氏度，适宜出行。"}
]

前端在展示时，可以将 role 为 function 及 role 为 assistant 但带有 function_call 的消息列表元素不予展示，这样用户就能得到纯净的聊天体验

GUI Agent

从上面的例子中，不难看出，使用 Function Calling 存在一定缺陷，如我们需要手动定义各种各样的函数，灵活性很差

于是，有人提出了实现 AI Agent 的另一种方案：基于 GUI 实现

说直白一点，就是让 LLM 学会如何自己操作电脑可视化地去完成一些任务

目前，OpenAI、Anthropic（Claude 所属公司）等都发布了自己的 Computer use，直接让 LLM 理解并操作电脑页面

LLM 可以根据用户的指令自动操作电脑（如查看、理解屏幕，并操作光标、输入字符等）

基于截图来理解，也造成了一定的局限性，无法精准捕获一些信息

目前，国内一些厂商也在持续跟进这种 AI Agent 实现模式，比如智谱手机端支持一键点外卖、发微信等，实际上运用的也是这种能力

但是，GUI Agent 的推进较为缓慢，非常不稳定，一些比较困难的任务也无法执行（比如滑动验证进行登录）

展望未来

API Agent vs GUI Agent

说完了两种主流的实现方式，哪种更好？

我认为：现阶段，API Agent 更好，未来，等 LLM 理解能力更上一层楼之后，GUI Agent 更好

Function Calling 还是使用传统的程序开发思维：调接口 → 实现功能，而 AI 进化的最终方向是 AGI（通用人工智能），「通用」二字，单靠 API 调用显然是实现不了的

在电脑上，可以使用命令行完成各种各样的操作（本质上就是调用 API，Manus 就是基于这一原理操作电脑），但在手机上，很多应用并不想开放 API 给他人使用，而且现在基本所有手机厂商都禁用了 ROOT 权限，这也将导致 AI 无法执行一些系统级别的操作（除非手机厂商自己做 AI 并强制所有应用都向外暴露 API 接口，目前只有苹果和鸿蒙可以做到）。再者，一些操作也不是 API 能完成的，比如剪辑视频等

现阶段，毋庸置疑是 API Agent 更好，尤其是在 MCP（大模型上下文协议）逐渐普及后，开发者可以不用再自己另造轮子了，而且现在落地的大部分 AI Agent 产品也都是基于 API 实现的，比如最近大火的 Manus

入口收割

试想一下，未来某一天，你不再需要与各类 App 交互，只需要与 Agent 交互，由它代理你完成所有任务，这是一件好事吗？

我认为：对用户来说，是好事。但对开发者来说，不一定是好事。

对用户来说，只需要简单的交流，就能完成复杂的交互，心智负担大大减小

但是对于开发者来说，需要将某些功能的入口暴露给 Agent，一旦用户习惯了以 Agent 作为首要交互手段，那 App 自身的流量将会急剧减小。

（如苹果的 Apple Intelligence 就要求开发者将交互入口交出来）

更不要提如果到时候某些厂商推出一个「竞价排名」，把给钱多的入口展示靠前，变成了另一种垄断，用户和开发者就都成了输家。这样的 AI，真的是我们所期望的吗？

新的浪潮

从现在的趋势不难看出，许多厂商在保住自己基本盘（LLM）的基础上，已经开始了 Agent 的竞争，而且打得已经很激烈了，AI Agent 势必会是继 LLM 后的新一大趋势，AI 能否在各领域平稳落地，就看 Agent 的未来发展

这场没有硝烟的战争注定是漫长的，也将会是一场新的浪潮

人工智能

一文掌握 AI Agent 核心

AI Agent

是什么

AI 等级

构成

实现

Function Calling

实现思路

具体实现

GUI Agent

展望未来

API Agent vs GUI Agent

入口收割

新的浪潮

添加新留言

已有 1 条留言

一文掌握 AI Agent 核心

AI Agent

是什么

AI 等级

构成

实现

Function Calling

实现思路

具体实现

GUI Agent

展望未来

API Agent vs GUI Agent

入口收割

新的浪潮

《小丑牌》

二十二

添加新留言

已有 1 条留言