AI Agent
一、LLM（Large Language Model）大语言模型
LLM 就是大模型，它的一切的核心，我们常说的 Claude、Gemini、ChatGPT、Qwen、DeepSeek 都是模型，有了模型才有了智能化的能力。
但是它只是输出，它任何事情都做不了，所以大模型的最初形态是 ChatBot，一个聊天机器人，只能回答问题。
二、User Prompt 和 System Prompt
2023 年，OpenAI 刚刚发布 ChatGPT 的时候，AI 看起来只是一个聊天框。 我们通过聊天框发送一条消息给 AI 模型，然后 AI 模型生成一个回复。我们发的消息就叫 User prompt。就是用户提示词，一般就是我们提出的问题或者想说的话。
但是现实生活中，当我和不同的人聊天时，即便是完全相同的话，对方也会根据自己的经验给出不同的答案。比如我说我肚子疼，我妈可能会问我要不要去医院，我爸可能会让我去厕所，我女朋友可能直接就来一句，滚一边去，我也疼。但是 AI 没有这样的人设，所以它就只能给出一个通用的回答：如持续不适，请就医。显得非常无趣，于是我就希望给 AI 也加上人设。
最直接的就是把人设信息跟用户要说的话打包成一条 user prompt 发过去。比如：你扮演我的女朋友，我说我肚子疼，然后 AI 可能就回复：滚一边去，我也疼。
但问题是，你扮演我温柔的女朋友，但这句话并不是我们真正想说的内容，显得有一点出戏，于是人们干脆把人设信息单独拎了出来，放到另外一个 prompt 里面，这就是 System prompt。
系统提示词 System prompt 主要用来描述 AI 的角色、性格、背景信息、语气等等，总之，只要不是用户直接说出来的内容，都可以放进 System Prompt 里面。每次用户发送 User prompt 的时候，系统会自动把 System prompt 也一起发给 AI 模型，这样整个对话就显得更加自然了。
在网页端的聊天机器人中， System 往往是系统预设的，用户不能随意更改。但通常来讲，网站会提供一些设置，比如 ChatGPT 里面会有 Personalization，用户可以在里面写下自己的偏好。这些偏好就会自动变成 System prompt 的一部分。
不过即使人设设定的再完美，说到底，还是一个聊天机器人。你问一个问题，最多给你答案，或者告诉你怎么做，实际动手的还是你自己。那么能不能让 AI 自己去完成任务呢？这就是下面要讲的 AI Agent。
三、LLM / Chatbot 的局限性
局限一：无法感知或改变外界环境
举个例子：你想让 ChatGPT 帮你写一个贪吃蛇游戏，它确实可以给你代码，但写完之后，像 " 把代码写入到文件 " 这种事情，还是得你自己动手。也就是说，大模型无法改变外界环境。
反过来，如果你已经有一些贪吃蛇的代码，想让模型基于这些代码来改写、增加功能，你就必须把已有的代码手动复制给模型——如果你不主动告诉它，它是无法自己查到这些代码的。这就是大模型无法感知外界环境的体现。
用一句话来类比：大模型就像一个 " 只能回答问题但没有手脚的老师 " —— 它知道很多，但什么都做不了。
局限二：幻觉（Hallucination）
大模型有时会 " 一本正经地胡说八道 "，生成看起来合理但实际上错误的内容。这是因为模型的本质是在预测 " 下一个最可能的词 "，而不是真的在 " 查资料 "。它基于训练数据中的统计规律来生成文本，所以当它没有可靠信息时，会凭空编造出看似权威的答案。
这也是后面 RAG 技术要解决的核心问题之 —— 让模型基于真实资料回答，而不是凭空编造。
四、AI Agent 的定义
既然大模型有这些局限，那有没有办法解决呢？答案是：给它接上工具、赋予它记忆和规划能力，让它变成一个Agent。
先看一个 Agent 的组成公式：
Agent = LLM（大脑）+ Memory（记忆）+ Planning（规划）+ Tool Use（工具使用）
- 无法感知/改变环境 → Tool Use 解决
- 幻觉 → Memory + RAG 缓解（后面会讲）
目前常见的： Agent 产品有：Manus、NotebookLM、Coze/扣子、豆包、千问。 Coding Agent 有：Claude Code、Cursor。
构建 Agent： 代码的方式： LangChain、LangGraph、CrewAI、Mastra 可视化/低代码的方式：Dify、扣子
举个例子，下面是我用扣子，让它生成了一个贪吃蛇的游戏，你可以说扣子就是一个 Agent。
我的提示词是：写一个贪吃蛇 ，然后 Agent 让大模型开始思考，然后根据用户的提示词制定了一个开发计划，然后它一步步的去调用 Tool，这里的 Tool 会有很多个，比如创建文件的 Tool，读取文件的 Tool，调用 Tool 完以后，有的 Tool 会把结果（Tool Output）返回给大模型，然后模型会继续重新思考，等到任务完成以后，模型会停止思考，输出最终答案和结果。
现在模型的厂商基本上都在做 Agentic（Agent 化）
- 作为模型时： 你问它 " 红烧肉怎么做？"，它吐出一串食谱。这只是知识检索和文本生成。
- 作为 Agent 时： 当你打开千问或者豆包，和它说：" 帮我点一杯奶茶 "，它会调用美团或淘宝闪购的 API，查询你的位置，下单，这一刻，它就是一个 Agent。
区别在于： 模型是它底层智能化的能力，而它外接的 Planning（规划能力）+ Memory（记住了你的地址）+Tool Use（调用 API：比如查询你的位置，查询附近的奶茶店，调用下单接口），让它具备了 Agent 的属性。
五、Context（上下文）
Context 定义：Context 就是模型的全部输入——包括用户问题、背景信息、相关资料、可用工具列表、工具执行结果、历史对话等。模型把这些内容作为上下文，并基于它们来生成答案。
Context Window（上下文窗口）：模型能接收的输入容量上限，以 token 为单位。token 可以理解为文本被拆分成的最小单位（一个 token 大约相当于 0.75 个单词或 1.5 个汉字）。
Context Window 虽然越来越大，但这并不意味着可以把所有资料不加筛选地一股脑塞给模型——输入太杂乱会影响模型理解，输入越多成本也越高、速度越慢。所以光有大窗口还不够，怎么选、选什么内容放进去，反而成了关键。这就是 Context Engineering（上下文工程） 的核心思想：不改变模型结构，只改变模型看到什么。
六、Memory（记忆）
最基础的 Memory 就是 Context（上下文），每个大模型都自带。目前主流模型的上下文长度集中在 128K tokens，旗舰款模型普遍支持 200K - 1M+ tokens。
上下文属于短期记忆，会话结束就消失了。但有很多方法可以实现长期记忆，最常见的包括：
- Markdown 文件记忆（如 Claude.md、Agents.md 等）
- 知识库/RAG 检索（依托向量数据库）
- 记忆变量与片段（结构化存储用户偏好等）
核心思路都是把会话外的信息持久化存储，需要时再检索注入到当前上下文。
6.1、RAG（检索增强生成）
为什么需要 RAG？
假设你想做一个智能客服，需要回答关于公司产品的问题。直觉想法是把产品手册全部塞给模型，但如果手册有上百页甚至上千页，就会遇到三个问题：
- 窗口不够：超过 Context Window 上限，模型读了后面忘了前面
- 成本太高：输入越多，调用成本越高，每次都带上厚厚的手册开销巨大
- 速度太慢：输入越多，模型消化内容越多，输出越慢
那我们是不是可以只把文档中相关的内容发给模型呢？这就是 RAG 登场的地方
RAG 定义
RAG 全称 Retrieval Augmented Generation（检索增强生成），核心思想很简单：先从资料库中检索相关的内容，再基于这些内容来生成答案。先检索，再生成——所以叫检索增强生成。
五个关键环节
RAG 的整体流程分为两个阶段：
提问前（数据准备）：
1. 分片：把文档切分成多个片段。可以按字数分（如 1000 字一个片段）、按段落分、按章节分、按页码分等。
2. 索引：通过 Embedding 将每个片段转换为向量，并存入向量数据库。
- Embedding（嵌入）：把文本转换为向量的过程。含义相近的文本，转换后的向量也相近。例如 " 小明喜欢吃水果 " 和 " 小明爱吃水果 " 的向量会非常接近，而 " 天气真好 " 则距离很远。Embedding 由专门的 Embedding 模型来完成（不是 GPT、Claude 这些对话模型）。
- 向量数据库：专门用来存储和查询向量的数据库，提供计算向量相似度等函数。
提问后（回答生成）：
3. 召回：用户提问后，先将问题通过 Embedding 转为向量，然后在向量数据库中通过向量相似度查询最相关的 top-N 个片段（如 top-10）。
4. 重排 Rerank：从召回的 10 个片段中，使用 rerank 模型精选出 3 个最相关的。
为什么不直接在召回阶段只选 3 个？因为召回和重排使用的相似度计算逻辑不同：
| 召回 | 重排 | |
|---|---|---|
| 方法 | 向量相似度 | Cross Encoder 模型 |
| 特点 | 成本低、速度快、准确率较低 | 成本高、速度慢、准确率高 |
| 类比 | 简历筛选（快但粗） | 面试（慢但准） |
就像公司筛选人才：先从成千上万份简历里粗选 10 个（召回），再通过面试精选 3 个入职（重排）。
5. 生成：把用户问题 + 重排后的 3 个相关片段一起发给大模型，模型根据片段内容生成最终答案。
整体流程回顾
七、Tools
大模型本身只能输出文本——它知道怎么做，但没有手脚去真正执行。工具就是给它接上手脚的方式，有了工具，大模型才能自己查文件、自己写代码、自己运行程序，真正完成任务。
工具的本质是函数，有固定的输入和输出。举个例子：
read_file(路径)→ 返回文件内容write_to_file(路径, 内容)→ 把内容写入文件，返回 " 写入成功 "run_command(命令)→ 执行终端命令，返回执行结果web_search(关键词)→ 联网搜索，返回搜索结果
每个工具做一件事，输入什么、输出什么，都是提前定好的。
那模型是怎么用工具的？
模型本身并不能直接执行工具，它只负责 " 决策 "——判断现在该用哪个工具、传什么参数。真正执行的是 Agent 主程序。流程如下：
- 模型输出：我要调用
get_weather，参数是北京 - Agent 执行：主程序收到请求，执行对应函数（比如去调用天气 API）
- 返回结果：函数返回结果，比如 " 晴，25 度 "，主程序把结果反馈给模型
- 继续推理：模型拿到结果，继续推理下一步（比如组织语言告诉用户“北京今天天气不错”）
这个流程会在下一章的 ReAct 循环里反复出现。
八、Planning（规划）
8.1、ReAct 循环 — Agent 的运行模式
Agent 的运行有很多种模式，其中最有名、使用最为广泛的是 ReAct。
ReAct 定义：ReAct 是 Reasoning and Acting（思考与行动）的缩写，最初由 2022 年 10 月的一篇论文提出。它是目前使用最广泛的 Agent 运行模式，如果你要学习 Agent 的实现原理，就绝对绕不开 ReAct。
四步循环详解：
- Thought（思考）：模型分析当前的任务，决定下一步该做什么。
- Action（行动）：模型决定调用哪个工具（比如
read_file、write_to_file），以及传入什么参数。 - Observation（观察）：模型暂停，等待外部环境执行工具，并将执行结果作为文本反馈给模型。
- Repeat（重复）：模型根据 Observation 的结果，开始新一轮的 Thought。如果认为任务已完成，则输出 Final Answer。
具体举例：贪吃蛇游戏场景
假设用户任务是 " 写一个贪吃蛇游戏，使用 HTML、CSS 和 JS 实现，代码分别放在不同的文件中 "：
| 轮次 | Thought | Action | Observation |
|---|---|---|---|
| 第 1 轮 | 需要创建三个文件，先写 HTML | 调用 write_to_file 写入 index.html | 写入成功 |
| 第 2 轮 | HTML 写好了，接下来写 CSS | 调用 write_to_file 写入 style.css | 写入成功 |
| 第 3 轮 | CSS 也好了，最后写 JS | 调用 write_to_file 写入 game.js | 写入成功 |
| 第 4 轮 | 三个文件都写完了，任务完成 | — | Final Answer: 贪吃蛇游戏已完成 |
每一轮都严格按照 Thought → Action → Observation 的流程执行，直到最后一轮输出 Thought + Final Answer，整个流程结束。
用户提交任务后，任务先到 Agent 主程序，主程序调用模型，模型返回 Thought 和 Action，主程序执行 Action 中的工具，把结果加入历史消息，再次调用模型……如此循环，直到模型返回 Final Answer。
九、MCP（Model Context Protocol）
9.1、什么是 MCP？
MCP 定义：MCP 全称 Model Context Protocol（模型上下文协议），是 Anthropic 公司于 2024 年 11 月 25 日发布的一个标准化协议。简单来说，MCP 就是让 AI 应用以统一方式连接外部工具、数据和服务的标准协议。
9.2、为什么需要 MCP？
前面我们说了，工具对 Agent 就像手脚一样重要。但以前有个大麻烦：工具没有“统一标准”。
- 你想让 AI 读你的 Excel，得写一套代码；
- 想让它查你的 Google Calendar，又要换一套写法。
- 不同的 AI 软件（比如 Claude、Cursor）接入同一个工具的方式都不一样
9.3、mcp 示例
9.4、三个核心概念
MCP Host（宿主应用）
MCP Host 是运行 AI 模型的客户端应用程序，比如 Claude Desktop、Cursor 等。它负责连接和管理一个或多个 MCP Server，为用户提供使用 MCP 功能的界面、安全边界和交互环境。
MCP Server（服务端）
MCP Server 是通过标准化 MCP 协议向 AI 应用开放特定能力的程序，比如文件系统、数据库、GitHub、Slack 等服务。它的核心职责是暴露三类能力：Tools（工具）、Resources（资源） 和 Prompts（提示词），让 AI 能安全访问外部数据或执行操作。
Tool（工具）
就是第七章提到的那些工具函数，只不过在 MCP 体系里，它们由 Server 来统一管理和暴露。比如联网搜索、读取文件、发送邮件、查询数据库——这些都可以作为 Tool 挂在 MCP Server 上，供 AI 按需调用。
三者关系：
MCP Host（AI 应用）通过 MCP 协议连接 MCP Server，发现并调用 Server 提供的 Tool，从而让 AI 模型能够标准化、安全地访问外部数据和执行实际操作。
- Host = 你的「智能助手 App」
- Server = 各种「技能插件商店」
- Tool = 插件里的「具体功能按钮」
- MCP = 统一的「插件接口标准」
这样设计的好处是：开发者不用为每个 AI 应用重复写接口，AI 应用也不用为每个工具单独适配，实现「一次开发，多处复用」。
十、总结
- 核心转变：AI 从“对话者”变成了“行动者”。
- 关键公式：Agent = 大模型 (大脑) + 规划 + 记忆 + 工具。
- 技术栈：理解 Context(上下文)、RAG(长期记忆)、ReAct(思考行动循环)、MCP(工具标准) 是构建 Agent 的基础。