AI|Agent Basic
基础定义
简单来说:普通的LLM只负责解答问题,而AI Agent替人干活(完成具体岗位的实际工作)
AI Agent的能力:
- 对目标会进行分析拆解。用户只提出目的最终实现效果,Agent会拆解补全中间步骤。
- 会基于自己的理解自己想下一步应该做什么。
- 会使用工具,例如发送邮件,查询API,操作文件。
- 能反复尝试,遇到错误重试。
举一个最简单的例子,对AI说:帮我安排一个厦门两日游,预算 1500,带父母,尽量轻松。
普通的LLM:生成一段文字回复,结束。
AI Agent:
理解目标:地点:厦门 时间:两天 人群:父母 → 不要太累 预算:1500
自己拆任务:查交通、查住宿、查景点、排路线、控制预算
调用工具:查天气 API、查地图、查酒店平台、查高铁 / 飞机
反复判断
- 这个路线太累了 → 换
- 预算超了 → 调整
- 下雨 → 改室内景点
给你最终结果:一份“已经替你想过、算过、改过”的方案,虽然不是最终但却是可用的的版本。
基础概念
提示词
提示词分为很多种,有用户提示词也有系统提示词等
用户输入的消息就是用户提示词
系统提示词则更相当于一种”人设”/规范/基本盘要求
Function Call
在 LLM 最基本的文字对话基础上,拓展 LLM 的能力,由不同函数逻辑实现(例如查询某指定时区的时间日期)
一般的流程是:
- 客户端代理会将所有注册的 Function Call 全部提供给 LLM
- 在用户跟大模型对话后,大模型会思考分析后选择具体调用哪一个,告诉客户端
- 之后客户端通过 Function Call 来调用具体逻辑
这一流程下来,虽然 LLM 本身并不具备查询天气的能力,对用户来说 LLM 已经正确返回答案了,实际上这背后就是 Function Call 的作用
MCP
MCP 本身只是协议,就好比 USB 接口,通过台式机主板上预留 USB 接口,插入各种同样实现了 USB 协议的外设(键盘,鼠标),便可以实现文本键入以及鼠标移动用户交互。用户并不关心键盘和鼠标是如何跟计算机交互通信的,它只需要将这两个 USB 接口设备连接在一起即可实现功能。
同理 MCP 也是如此,MCP客户端预留了对 MCP 协议标准的实现,而MCP服务器(比如查询指定时区的时间日期服务器)也按 MCP 的标准来。客户端应用程序侧的MCP客户端就可以将大模型在理解用户输入、思考分析后返回的请求诉求,标准化地向 MCP 服务器执行工具调用。
所以我们常用的 AI 客户端 / AI IDE / OpenCode等软件应用(专业名词叫做 Host),其实可以理解为是内置了一份 MCP 客户端,将 LLM 的工具调用指令翻译成 MCP 协议消息,发送给 MCP Server。
以用户问 AI “今天天气怎么样”为例,来看流程:
- 用户 → AI客户端(如 Claude Desktop)
- AI客户端 → LLM(托管在云端或本地)
- LLM 分析用户意图 → 返回需要调用天气工具的指令
- AI客户端 收到指令 → 通过 MCP 协议调用 MCP 天气服务器
- 天气服务器 返回结果
- AI客户端 → LLM(再次调用,传入天气结果)
- LLM 生成自然语言回答
- 用户看到答案
LLM 是 “决策大脑”,只输出调用指令;MCP 是 “通信管道”,负责应用与外部服务的标准化交互,两者分工明确、互不重叠。
Skills
Skills 是**让 AI 记住”怎么为你做事”**的机制。
在没有 Skills 之前,每次和 AI 对话都要重新解释:
- 你的代码规范是什么
- 你喜欢用什么命名风格
- 你的项目架构是怎样的
- 你的工作流程偏好
AI 每次都是从零开始,无法积累经验。
Skills 在 Anthropic 提出(2025年10月),本质是一个打包好的提示词 + 工具集合:
1 | |
Function Call / MCP / Skills 对比
| 概念 | 角色 | 类比 | 解释 |
|---|---|---|---|
| Function Call | 让 LLM 调用单个函数 | 投篮动作 | 调用能力 |
| MCP | 标准化协议,连接 AI 与外部服务 | 篮球场规定标准 | 连接标准 |
| Skills | **让 AI 记住”怎么做”**,沉淀经验 | 教练的战术板,告诉这个运动员 “这个队该怎么配合” | 经验沉淀 |
RAG
检索增强生成,是为了解决 LLM 可能因训练数据过时导致的幻觉问题,即:一本正经的胡说八道
通过 RAG 可以让 LLM 查阅指定资料后再回答
1 | |
如果说 Skill 是解决 AI 不会的事情教他怎么做的问题,RAG 解决的则是 AI 不知道的事情告诉他在哪里