6张图搞懂AI Agent——从ChatBot到数字员工

yuhaiqun1989

317人浏览 · 2026-07-24 09:39:47

yuhaiqun1989 · 2026-07-24 09:39:47 发布

📢 本文是 「108张AI知识卡片·大模型通关手册」 系列第 8 篇。前七篇把 RAG 从入门到高阶讲透了——RAG 解决的是"给模型外挂知识"，但模型拿到知识后还是只能"回答问题"。这篇开启全新话题：Agent——让大模型从"问答机器"变成"数字员工"，自己思考、自己行动、自己纠错。

TL;DR 太长不看
一、Agent：不只是ChatBot，是能自己干活的AI
二、ReAct：推理+行动循环，Agent的灵魂框架
三、记忆Memory：没记忆的Agent就是金鱼脑
四、Skills：Agent能做什么？拆成模块按需调用
五、插件：连接外部世界的桥梁
六、MCP：大模型连接万物的统一协议
七、一张图串起Agent核心链路
八、代码：用ReAct框架搭一个最小Agent
写到最后
系列导航 & 持续更新

TL;DR 太长不看

⚡ 30 秒版：先记这 7 条，细节往下翻。

🔴 Agent：不是更聪明的 ChatBot，是有感知→决策→行动闭环的 AI 系统——能自主完成复杂任务。
🟠 ReAct：推理（Reasoning）+ 行动（Acting）循环——先想想要做什么，再执行动作，再根据结果继续推理，Agent 的灵魂框架。
🟡 记忆Memory：短期记忆保对话上下文（当前会话），长期记忆积累经验知识（跨会话）——没记忆 = 金鱼脑。
🟢 Skills：Agent 的能力拆解成一个个技能模块（搜索、计算、写代码），按需调用组合。
🔵 插件：连接外部世界的桥梁——搜索、画图、写代码、查数据库……插件让 Agent 能力无限扩展。
🟣 MCP：Model Context Protocol，大模型连接万物的统一协议——Agent 生态的 HTTP，一次对接全网工具。
🎁 一句话串起来：Agent 通过 ReAct 循环思考→调用 Skills 执行→借助插件/MCP 对接工具→用 Memory 记住经验→越来越聪明地完成任务。

一、Agent：不只是ChatBot，是能自己干活的AI

请添加图片描述

ChatBot 你问它答，不问就歇着。Agent 你给它一个目标，它自己拆任务、自己找工具、自己执行、自己检查——你只需要说"帮我订一张明天去上海的机票"，它就自己干了。

Agent 解决的核心问题：大模型只会"说"，不会"做"。ChatBot 的闭环是"用户输入→模型输出文字"，Agent 的闭环是"目标→感知→决策→行动→反馈→再决策"——它不是一个更聪明的聊天机器人，是一个能自主完成任务的 AI 系统。

它到底在干嘛（机制层）：Agent 的核心架构是感知-决策-行动循环。感知：接收用户目标 + 环境反馈（上一步行动的结果）。决策：大模型作为"大脑"，根据目标和当前状态决定下一步做什么——调用哪个工具、传什么参数。行动：执行决策结果——调用 API、搜索网页、读写文件、操作数据库。反馈：行动结果返回，Agent 判断任务是否完成——没完成则继续循环，完成了则输出最终结果。和 ChatBot 的本质区别：ChatBot 只走一次"输入→输出"，Agent 走多轮"感知→决策→行动→反馈"循环，直到目标达成。

你能感受到什么（体感层）：你说"帮我查一下明天上海的天气"——ChatBot 会直接用训练数据编一个答案（可能过时），Agent 会调用天气 API 拿到实时数据再告诉你。你说"帮我订机票"——ChatBot 只能告诉你去哪个网站订，Agent 会自己打开订票网站、填信息、确认支付。ChatBot 是"嘴巴"，Agent 是"手脚+嘴巴"。

	ChatBot	Agent
交互模式	一问一答	目标驱动多轮循环
输出	文字	文字 + 行动（API调用/文件操作等）
工具使用	无	有（按需调用）
自主性	被动响应	主动规划执行
错误处理	无	感知反馈→调整策略

🎛️ 动手感受：ChatBot vs Agent 对比

操作：同一个任务"查明天上海天气"，分别用纯 ChatBot 和 Agent 模式执行。
你会看到：

ChatBot：直接生成一段文字，可能是过时数据或编造的。
Agent：先决定"需要调用天气API"→调用API→拿到实时数据→格式化输出。
变化说明了什么：Agent 不是"更聪明的 ChatBot"，是"会动手的 AI"——它能把"说"和"做"连起来。

🤔 想一想

Agent 的"自主性"是双刃剑——它能自己决定调用什么工具，但如果决策错了呢？调用了一个删除文件的 API，文件就真没了。Agent 的安全性怎么保证？权限控制（只能调用白名单工具）和人类审批（高风险操作需确认）是两条基本防线。

🔗 顺着他想：Agent 能自己干活，但它怎么决定"先做什么后做什么"？如果任务很复杂（“帮我规划一次旅行”），它需要先推理出子任务，再逐个执行——这个"推理→行动"的循环框架，就是 ReAct。

二、ReAct：推理+行动循环，Agent的灵魂框架

请添加图片描述

Agent 拿到任务后直接开干？那和脚本没区别。真正的 Agent 会"先想再做"——想清楚下一步该干什么，做了之后再看结果，再想下一步。这个"想→做→看→想→做→看"的循环，就是 ReAct。

ReAct 解决的核心问题：Agent 怎么在复杂任务中做决策？ 不是一次性规划完所有步骤，而是"推理一步→行动一步→观察结果→再推理"——边想边做，做错了能调整。

它到底在干嘛（机制层）：ReAct（Reasoning + Acting）把 Agent 的执行循环拆成三个阶段。Thought（推理）：大模型根据当前目标和已有信息，推理出下一步该做什么——“我需要查天气数据，所以应该调用天气 API”。Action（行动）：执行推理结果——调用工具、查询数据库、搜索网页。Observation（观察）：接收行动结果，判断是否需要继续——“天气数据拿到了，但用户还问了温度，我需要再提取温度信息”。循环直到任务完成：Thought→Action→Observation→Thought→Action→Observation→…→Final Answer。和"一次性规划"的区别：ReAct 不要求一开始就想清楚所有步骤——做一步看一步，遇到意外能调整，比"全规划再执行"更鲁棒。

你能感受到什么（体感层）：任务"帮我查上海天气并推荐穿搭"——一次性规划：先查天气→再根据天气推荐穿搭（但查完发现是暴雨，原计划"推荐穿搭"不够，还需要推荐雨具）。ReAct 循环：Thought1"先查天气"→Action1 调用天气API→Observation1"暴雨25°C"→Thought2"暴雨需要推荐雨具和防水穿搭"→Action2 生成推荐→Final Answer。ReAct 的优势在于"根据观察调整策略"——规划阶段想不到的情况，执行时能补救。

🎛️ 动手感受：一次性规划 vs ReAct 循环

操作：同一个多步任务，分别用"先规划全部步骤再执行"和"ReAct 逐步推理执行"，看遇到意外时的表现。
你会看到：

一次性规划：按原计划执行，遇到意外（API 返回错误）不知道怎么办，卡住或输出错误结果。
ReAct：遇到 API 错误→Observation 发现异常→Thought 调整策略（换一个 API 或换个方式查）→继续执行。
变化说明了什么：ReAct 不是"更聪明"，是"更灵活"——它让 Agent 具备了"做错了能改"的能力。

🤔 想一想

ReAct 每一步都要调用大模型做推理——5 步任务就是 5 次 LLM 调用，延迟和成本都翻 5 倍。如果任务很简单（“1+1 等于几”），用 ReAct 就是杀鸡用牛刀。什么时候该用 ReAct，什么时候直接生成？这取决于任务的复杂度和不确定性。

🔗 顺着他想：ReAct 让 Agent 能"边想边做"，但每轮推理都依赖当前上下文——如果对话太长，前面的信息会被"挤掉"。Agent 怎么记住之前做过什么、学到了什么？这就是"记忆"要解决的问题。

三、记忆Memory：没记忆的Agent就是金鱼脑

请添加图片描述

Agent 帮你订了机票，5 分钟后你问"我订的是几点的？"——它忘了。每轮对话都从零开始，这就是没有记忆的 Agent：金鱼脑，7 秒就忘。

记忆解决的核心问题：Agent 需要在多轮交互中保持上下文，并在跨会话中积累经验。没有记忆，Agent 无法处理需要"记住之前做过什么"的任务，也无法从历史经验中学习。

它到底在干嘛（机制层）：Agent 的记忆分两层。短期记忆（Working Memory）：当前对话的上下文——用户说了什么、Agent 做了什么、中间结果是什么。实现方式就是 Prompt 里的对话历史（Messages 列表），受上下文窗口限制（如 128K token），超出就截断或摘要。长期记忆（Long-term Memory）：跨会话的经验和知识——用户偏好（“我喜欢靠窗座位”）、历史任务结果（“上次订的是东航”）、通用知识补充。实现方式通常是外部存储（向量数据库/键值数据库），检索后注入 Prompt。短期记忆是"这次对话记住的"，长期记忆是"所有对话积累的"——两者配合，Agent 才能既"当下不糊涂"又"越用越懂你"。

你能感受到什么（体感层）：没记忆：你说"帮我订去上海的机票"→Agent 订好了→你说"改到后天"→Agent 不知道"去上海"这个信息，问"改什么去后天？"。有短期记忆：Agent 知道"去上海的机票"这个上下文，直接改签到后天。有长期记忆：Agent 还记得你上次也选了靠窗座位，这次自动帮你选靠窗——"越用越懂你"的感觉。

	无记忆	短期记忆	短期+长期
多轮对话	每轮从零开始	当前会话连贯	当前会话连贯+跨会话积累
用户偏好	不知道	当前会话知道	永久记住
实现复杂度	低	中	高
存储成本	无	内存	外部数据库

🎛️ 动手感受：无记忆 vs 短期记忆 vs 长期记忆

操作：同一个多轮对话任务，分别关闭记忆/只开短期/开短期+长期，看 Agent 的表现。
你会看到：

无记忆：每轮对话 Agent 都不知道之前说了什么，反复问同样的问题。
短期记忆：当前会话内 Agent 记住了上下文，对话流畅——但新会话又从零开始。
短期+长期：新会话也能记住你的偏好和历史，“越用越懂你”。
变化说明了什么：记忆不是"锦上添花"，是 Agent 从"一次性工具"变成"长期助手"的基础设施。

🤔 想一想

长期记忆存在向量数据库里，检索时用相似度匹配——但"相似"不等于"相关"。你问"订机票"，可能检索出"上次订机票遇到延误"的记忆，这段记忆和当前任务无关，反而干扰决策。长期记忆的"噪声过滤"是个难题——记住什么、忘掉什么，比"全记住"更重要。

🔗 顺着他想：Agent 有了记忆，有了推理框架（ReAct），但"能想"不等于"能做"——它还需要具体的能力。搜索、计算、写代码、查数据库……这些能力怎么组织？按需调用？这就是 Skills 要解决的问题。

四、Skills：Agent能做什么？拆成模块按需调用

请添加图片描述

Agent 什么都会？不，Agent 什么都不会——除非你给它装上 Skills。搜索是 Skill，计算是 Skill，写代码是 Skill，查数据库也是 Skill。Agent 的"能力"不是内置的，是组装的。

Skills 解决的核心问题：Agent 的能力边界怎么定义和扩展？ 把能力拆解成一个个独立的技能模块，Agent 根据任务需要按需调用——不是"什么都会"，是"需要什么就调用什么"。

它到底在干嘛（机制层）：Skill 是一个自包含的能力单元——有明确的输入/输出接口、有独立的执行逻辑、有清晰的描述（让 Agent 知道什么时候该用它）。Agent 拿到任务后，通过 ReAct 推理出"下一步需要什么能力"，然后在 Skills 列表里匹配最合适的 Skill 调用。Skills 的组织方式通常是注册表模式：所有可用 Skills 注册到一个中心表，每个 Skill 带有描述（“搜索网页获取实时信息”）、输入参数（“搜索关键词”）、输出格式（“搜索结果列表”）。Agent 推理时扫描注册表，找到匹配的 Skill 调用。组合是 Skills 的核心优势——单个 Skill 能力有限，但"搜索 Skill + 摘要 Skill + 翻译 Skill"组合起来，就能完成"搜索英文资料并翻译成中文摘要"这种复杂任务。

你能感受到什么（体感层）：Agent 只有 3 个 Skills：搜索、计算、翻译。任务"查一下美国GDP并换算成人民币"——Agent 推理：需要搜索美国GDP→调用搜索Skill→拿到GDP数字（美元）→需要换算→调用计算Skill（汇率换算）→输出结果。如果再加一个"画图 Skill"，Agent 就能把结果画成图表——能力扩展 = 加一个 Skill，不需要改 Agent 本身。

🎛️ 动手感受：加/减 Skill 看 Agent 行为变化

操作：同一个任务，先只给 Agent 2 个 Skills（搜索+计算），再加第 3 个（翻译），看 Agent 的决策路径变化。
你会看到：

2 个 Skills：搜索到英文结果→Agent 不知道怎么翻译，直接输出英文或报错。
3 个 Skills：搜索到英文结果→Agent 推理"需要翻译"→调用翻译 Skill→输出中文。
变化说明了什么：Agent 的行为由可用 Skills 决定——加一个 Skill，Agent 就多一种能力路径，不需要改推理逻辑。

🤔 想一想

Skills 越多越好吗？100 个 Skills 注册在表里，Agent 每次推理都要扫描 100 个描述来决定用哪个——匹配精度下降、延迟上升。Skills 的"数量"和"可发现性"之间存在矛盾。怎么让 Agent 在大量 Skills 中快速找到最合适的？分类、标签、语义匹配都是方案，但没有银弹。

🔗 顺着他想：Skills 定义了 Agent “能做什么”，但 Skill 本身怎么和外部世界对接？搜索 Skill 需要调用搜索引擎 API，计算 Skill 需要调用计算服务——这些"对接"的活，由"插件"来干。

五、插件：连接外部世界的桥梁

请添加图片描述

Agent 想查天气，但它的"大脑"（大模型）没有天气数据——它需要一个"手"去拿。插件就是这只"手"：连接外部 API、数据库、服务的桥梁。

插件解决的核心问题：大模型本身是"信息孤岛"，无法访问实时数据和外部服务。插件把外部能力"接"到 Agent 上——搜索、画图、写代码、查数据库、发邮件……Agent 通过插件，从"只会说话"变成"能动手干活"。

它到底在干嘛（机制层）：插件是一个标准化的外部服务接口——定义了 API 端点、请求格式、响应格式。Agent 调用插件的流程：① Agent 推理出"需要调用天气插件"→② 构造请求（城市=“上海”，日期=“明天”）→③ 调用插件 API→④ 接收响应（温度=25°C，天气=暴雨）→⑤ 把响应结果注入 Prompt 继续推理。插件的标准化让"加一个新能力"变成"加一个 API 对接"——不需要改 Agent 的推理逻辑，只需要注册新插件的接口描述。OpenAI 的 Plugin 生态、LangChain 的 Tools 生态，都是这个思路。

你能感受到什么（体感层）：没有插件的 Agent：你问"明天上海天气"→它编一个答案。有天气插件的 Agent：你问"明天上海天气"→它调用天气 API→拿到实时数据→告诉你"明天上海暴雨25°C"。有天气+地图插件的 Agent：你问"明天去上海怎么走"→它先查天气（暴雨）→再查地图（推荐地铁而非自驾）→综合建议"明天暴雨建议坐高铁"。插件越多，Agent 的"手"越长。

	无插件	有插件
数据来源	训练数据（可能过时）	实时 API
能力范围	纯文本生成	文本+API调用+服务操作
扩展方式	换模型	加插件
实时性	无	有

🎛️ 动手感受：加插件前后的 Agent 行为

操作：同一个任务"查最新股价"，分别用无插件 Agent 和有股票 API 插件的 Agent。
你会看到：

无插件：Agent 用训练数据编一个股价，可能是几个月前的。
有插件：Agent 调用股票 API，拿到实时价格，准确输出。
变化说明了什么：插件让 Agent 从"靠记忆回答"变成"靠实时数据回答"——这是 Agent 和 ChatBot 的本质分水岭。

🤔 想一想

插件调用有安全风险——Agent 自己决定调用什么 API、传什么参数，如果它调了一个"删除所有文件"的 API 呢？插件权限控制是关键：只允许调用白名单 API、敏感操作需人类审批、限制单次调用的参数范围。Agent 的"自主性"和"安全性"永远在博弈。

🔗 顺着他想：每个插件都是独立对接的——天气插件对接天气 API，股票插件对接股票 API。如果 Agent 要对接 100 个服务，就要写 100 个插件适配器？有没有一种"统一协议"，让 Agent 一次对接就能连接所有服务？这就是 MCP。

六、MCP：大模型连接万物的统一协议

请添加图片描述

100 个服务 = 100 个插件适配器？每个服务的 API 格式不同、鉴权方式不同、返回格式不同——每对接一个就要写一套适配代码。MCP 就是来终结这种"一对一适配"的。

MCP（Model Context Protocol）解决的核心问题：大模型和外部工具之间缺乏统一协议。每个工具都有自己的 API 格式，Agent 每对接一个工具就要写一套适配代码——N 个工具就是 N 套适配。MCP 定义了一套标准协议，让 Agent 一次对接就能连接所有支持 MCP 的工具——就像 HTTP 统一了 Web 的通信方式。

它到底在干嘛（机制层）：MCP 的架构分三层。MCP Host：发起请求的客户端——你的 Agent 应用（如 Claude Desktop、Cursor）。MCP Server：提供工具/资源的服务端——每个外部服务实现一个 MCP Server，暴露标准化的工具列表和调用接口。MCP Protocol：Host 和 Server 之间的通信协议——定义了工具发现（Server 告诉 Host 我有哪些工具）、工具调用（Host 请求调用某个工具）、结果返回（Server 返回工具执行结果）的标准格式。关键点：Host 只需要实现一次 MCP 客户端，就能连接所有 MCP Server——“一次对接，全网工具”。Server 端也只需要实现一次 MCP 接口，就能被所有 MCP Host 调用——“一次适配，全网可达”。

你能感受到什么（体感层）：没有 MCP：你想让 Agent 用 5 个工具，就要写 5 个适配器——每个的 API 格式、鉴权方式、错误处理都不同。有 MCP：5 个工具各实现一个 MCP Server，Agent 只需要实现一个 MCP Client，5 个 Server 自动被发现和调用——加第 6 个工具？只要它支持 MCP，零代码就能接入。MCP 之于 Agent，就像 HTTP 之于 Web——统一协议让生态爆发成为可能。

	传统插件	MCP
对接方式	一对一适配	统一协议
新工具接入	写新适配器	实现 MCP Server
工具发现	手动注册	自动发现
生态	孤岛	互通

🎛️ 动手感受：传统插件 vs MCP 对接

操作：对比两种方式接入一个新工具（如 Notion API）——传统方式写适配器 vs Notion 提供 MCP Server 直接对接。
你会看到：

传统方式：查 Notion API 文档→写鉴权逻辑→写请求封装→写响应解析→调试→接入完成，耗时数小时。
MCP 方式：启动 Notion MCP Server→Agent 自动发现工具→直接调用，耗时几分钟。
变化说明了什么：MCP 把"工具对接"从"写代码"变成"配服务"——开发者不需要理解每个 API 的细节，只需要知道"这个 MCP Server 提供什么工具"。

🤔 想一想

MCP 是 Anthropic 提出的协议，目前还在早期——不是所有工具都支持 MCP，而且 MCP 自身的标准还在演进。如果 MCP 没有成为行业标准，而 OpenAI 推出了自己的协议呢？Agent 生态可能再次碎片化。协议的战争，历史上重复了无数次（Betamax vs VHS、蓝光 vs HD DVD）——最终赢家由生态决定，不是技术。

🔗 顺着他想：MCP 解决了"Agent 和工具怎么连接"的问题，但 Agent 之间怎么连接？两个 Agent 怎么协作完成一个任务？一个 Agent 做规划、另一个做执行，它们之间怎么通信？这就是 A2A（Agent-to-Agent）协议的事，下一篇进阶篇会讲。

七、一张图串起Agent核心链路

6 个概念串成一条从"目标"到"完成"的 Agent 执行链路：

用户目标
   │
   ① Agent 接收目标      ← 感知：理解用户要什么
   │
   ② ReAct 推理循环      ← Thought→Action→Observation→循环
   │
   ③ 查记忆              ← 短期记忆（当前上下文）+ 长期记忆（历史经验）
   │
   ④ 匹配 Skills         ← 根据推理结果，从注册表找到合适的技能
   │
   ⑤ 调用插件/MCP        ← 插件对接具体API / MCP统一协议连接服务
   │
   ⑥ 执行→反馈→继续      ← 行动结果反馈回ReAct循环，直到目标达成
   │
   最终结果 → 输出给用户

一句话串起来：Agent 通过 ReAct 循环思考→调用 Skills 执行→借助插件/MCP 对接工具→用 Memory 记住经验→越来越聪明地完成任务。

八、代码：用ReAct框架搭一个最小Agent

from openai import OpenAI

client = OpenAI(api_key="你的KEY", base_url="https://api.openai.com/v1")

# ① 定义Skills（工具）
def search_weather(city: str) -> str:
    """模拟天气API"""
    weather_db = {"上海": "暴雨25°C", "北京": "晴30°C", "广州": "多云28°C"}
    return weather_db.get(city, "未找到该城市天气")

def calculate(expr: str) -> str:
    """简单计算器"""
    try:
        return str(eval(expr))
    except:
        return "计算错误"

tools = {
    "search_weather": {"func": search_weather, "desc": "查询城市天气，参数：city(城市名)"},
    "calculate": {"func": calculate, "desc": "数学计算，参数：expr(表达式如'25*7')"}
}

# ② ReAct循环
def agent_run(task: str, max_steps: int = 5):
    messages = [
        {"role": "system", "content": f"""你是一个Agent，用ReAct框架完成任务。
可用工具：{list(tools.keys())}
每步输出格式：
Thought: 你的推理
Action: 工具名(参数)
或 Final Answer: 最终答案"""},
        {"role": "user", "content": task}
    ]

    for step in range(max_steps):
        resp = client.chat.completions.create(model="gpt-4o-mini", messages=messages)
        reply = resp.choices[0].message.content
        messages.append({"role": "assistant", "content": reply})
        print(f"[Step {step+1}] {reply[:200]}")

        if "Final Answer:" in reply:
            return reply.split("Final Answer:")[1].strip()

        if "Action:" in reply:
            import re
            match = re.search(r'Action:\s*(\w+)\(([^)]*)\)', reply)
            if match:
                tool_name, arg = match.group(1), match.group(2).strip('"\'')
                if tool_name in tools:
                    result = tools[tool_name]["func"](arg)
                    messages.append({"role": "user", "content": f"Observation: {result}"})
                else:
                    messages.append({"role": "user", "content": f"Observation: 工具{tool_name}不存在"})

    return "达到最大步数，任务未完成"

# ③ 运行
print(agent_run("查一下上海天气，如果下雨推荐室内活动"))

这段代码实现了一个最小 ReAct Agent：定义了 2 个 Skills（天气查询+计算器），Agent 通过 Thought→Action→Observation 循环推理执行。生产环境要做的升级：加 Memory（对话历史+长期记忆）、加更多 Skills、换 MCP 协议对接工具、加错误恢复和人类审批。

写到最后

RAG 让大模型有了"外挂知识"，Agent 让大模型有了"手和脚"——从"只会说"到"能干活"，这是 AI 从工具到助手的质变。但这只是 Agent 的入门：ReAct 是最基础的推理框架，Memory 只讲了短期+长期两层，Skills 和插件还是"一对一对接"，MCP 的生态才刚起步。下一篇进阶篇会讲：多 Agent 协作（A2A 协议）、NL2SQL（Agent 和数据库的桥梁）、对话状态跟踪（多轮对话的记忆管理）、Vibe Coding 和 Spec Coding（Agent 帮你写代码的两种方式）。

如果你读下来觉得真有用：