AI Agent 全解析：从 Transformer 到 Multi-Agent 的概念图谱与分层架构

type

Post

status

Published

date

Feb 11, 2026

slug

summary

从 Transformer 到 Multi-Agent，本文先以时间线梳理 AI Agent 的发展脉络，再从行为概念（Function Calling、Tool Calling、Agent、ReAct）与技术名词（Prompt、Tool、MCP、Skills、Context Engineering）两条演进线，一次讲透 AI Agent 的全部核心概念。

AI Agent 发展简史

在深入概念之前，先用一条时间线帮你建立 AI Agent 从何而来、走到了哪里的全局感知：

时间	里程碑事件	意义
2017	Google 发布 Transformer 论文 "Attention Is All You Need"	奠定了所有现代 LLM 的基础架构
2020–2022	GPT-3 → InstructGPT → ChatGPT，Prompt Engineering 兴起	LLM 从实验室走向公众，"对话式 AI" 成为主流交互方式
2022.10	Yao 等人发表 ReAct 论文	首次将推理与行动统一，为 Agent 提供了理论范式
2023.03	AutoGPT 开源，全球爆火	让 "AI Agent" 概念第一次出圈，虽然实用性有限，但点燃了想象力
2023.06	OpenAI 推出 Function Calling API	LLM 首次获得"调用外部函数"的标准化能力
2023.11	OpenAI 升级为 Tool Calling，发布 GPTs 和 Assistants API	并行调用、多工具类型、Agent 开发框架初步成型
2024.11	Anthropic 发布 MCP（Model Context Protocol）	AI 应用与工具/数据源连接有了开放标准，生态互联成为可能
2025	Multi-Agent 架构、Google A2A 协议、Skills 概念涌现	Agent 从单兵作战走向团队协作，从开发走向配置

从纯对话到能调函数，再到自主推理+行动，最后走向标准化协议和多智能体协作——这就是 AI Agent 过去几年的进化路径。接下来，我们把每个关键概念逐一拆解。

AI Agent 的构成

你可以把 AI Agent 想象成一位刚入职的实习生——脑子很聪明（LLM），但对公司的系统一无所知。光有脑子不够，还得给装备、教流程、接系统。

一个完整的 AI Agent 系统并不是"LLM + 几个 API"那么简单，它是一个五层分层架构，从上到下各司其职：

层级	名称	核心职责	关键组件
第 1 层	🧠 决策主体（Agent）	自治实体，接收目标并驱动整个系统运转	LLM（GPT / Claude / Gemini……）
第 2 层	🔄 认知与编排层	统筹推理与行动循环，决定"先想什么、再做什么"	ReAct（认知架构）、编排引擎（Orchestration Engine）
第 3 层	📋 逻辑封装层	将业务流程、指令和评估规则打包成可复用模块	SOP（指令 + 工作流 + 评估规则）、Skills（领域策略）
第 4 层	🔌 连接与标准层	统一 Agent 与外部工具/数据源的连接协议	MCP（互联标准，AI 世界的 USB-C）
第 5 层	⚙️ 执行单元层	最底层的原子能力，Agent 真正"动手"的地方	Tools：API 调用、数据库、文件读写、网络请求、代码执行、消息推送

用一句话串起来：Agent（大脑）通过 ReAct 循环思考和决策，按照 SOP / Skills 编排的业务流程，经由 MCP 标准协议，调用底层 Tools 完成实际操作。

下面这张图可以帮你快速建立直觉：

我们从下往上快速过一遍每一层的作用：

⚙️ 第 5 层 · 执行单元层（Tools）——Agent 的"双手"。每个 Tool 都是一个原子能力：查数据库、发邮件、读文件、跑代码……单独拎出来都很简单，但组合起来就能完成复杂任务。

🔌 第 4 层 · 连接与标准层（MCP）——Agent 的"神经网络"。没有它，每个 Tool 都需要单独写集成代码；有了 MCP，所有工具通过统一协议即插即用。

📋 第 3 层 · 逻辑封装层（SOP + Skills）——Agent 的"工作手册"。SOP 定义了指令、工作流和评估规则（Instruction → Workflow → Evaluation）；Skills 则是将 Tool + Prompt + 业务流程打包成可复用的领域策略，比如"数据分析技能"或"客户服务技能"。

🔄 第 2 层 · 认知与编排层（ReAct + Orchestration Engine）——Agent 的"思维引擎"。ReAct 提供 Thought → Action → Observation 的推理框架，编排引擎则负责统筹调度整个行动循环：该调哪个 Skill？要不要并行执行？结果是否达标？

🧠 第 1 层 · 决策主体（Agent）——整个系统的"灵魂"。它是自治实体和最终决策者，接收用户目标后驱动下面四层协同运转。

💡

Agent 的执行能力标准化（从 Function Calling → MCP → Skills）是工程化落地过程中的自然演进。 它体现了 AI Agent 从简单函数调用到复杂自主系统的发展趋势——每一层的成熟，都在降低上一层的实现门槛。

基础概念

行为概念

行为概念描述的是 LLM "做事"的方式，从最原始的函数调用，到完整的自主推理循环，它们的自主程度逐级递增。

Function Calling

Function Calling 是一切的起点。

2023 年 6 月，OpenAI 在 GPT API 中首次引入了 Function Calling 能力，从此 LLM 不再只是"嘴上说说"——它可以输出一段结构化的 JSON 来告诉你："嘿，我觉得你该调这个函数，参数是这些。"

举个例子，你问："北京今天天气怎么样？"LLM 不会硬编一个天气预报，而是返回：

然后由你的代码去调 API、拿到结果、再喂回 LLM 生成最终回答。

⚠️

注意：Function Calling 本身不执行任何函数。 LLM 只是"建议"调用哪个函数，真正执行的是你的后端代码。你可以理解为它只会"指挥"，不会"动手"。

Tool Calling

Tool Calling 是 Function Calling 的升级版——或者更准确地说，是它的"标准化"。

你可能会困惑：这俩有啥区别？在 OpenAI 的 API 演进中，functions 参数在 2023 年底被标记为 deprecated（已弃用），取而代之的是 tools 参数。二者在原理上几乎一致，但 Tool Calling 做了几件重要的事：

对比维度	Function Calling	Tool Calling
并行调用	❌ 单次只能调一个函数	✅ 一次可返回多个工具调用
工具类型	仅 function	function、retrieval、code_interpreter 等
标准化程度	OpenAI 私有实现	逐渐成为跨厂商通用接口
生态扩展	与单一模型绑定	可对接 MCP 等开放协议

简单来说：Function Calling 是 Tool Calling 的前身。 如果你今天在开发新项目，直接用 Tool Calling 就好，Function Calling 已经是上一代的接口了。

ReAct

ReAct（Reasoning + Acting）是目前最主流的 Agent 实现范式，由 Yao 等人在 2022 年提出。

名字很直白：推理（Reason）和行动（Act）交替进行。 每一步都遵循这样的三拍节奏：

Thought → 我需要查一下用户提到的那家公司的股价 Action → 调用 search_stock(symbol="AAPL") Observation → 返回结果：AAPL 当前价格 $245.32

然后进入下一轮：

Thought → 用户还问了市盈率，我需要再查一下 Action → 调用 get_pe_ratio(symbol="AAPL") Observation → 返回结果：P/E = 28.5

直到 Agent 认为信息足够，输出最终回答。

这种"边想边干"的模式比起纯推理（Chain-of-Thought）和纯行动（直接调工具）都更加强大，因为每一步的推理结果可以指导下一步的行动，每一步的行动结果又可以纠正推理的方向。

Agent

终于到了主角——Agent。

前面讲的 Function Calling 和 Tool Calling 都有一个共同的限制：它们是"一次性"的。 你问一个问题，LLM 返回一个函数调用，你执行完把结果喂回去，故事就结束了。

Agent 不一样。Agent 拥有自主决策的循环：

接收任务

思考该怎么做

选择并调用工具

观察结果

决定是继续行动还是返回结果

重复 2~5，直到任务完成

这就像你给实习生布置了一个任务："帮我查一下上季度华东区的销售数据，做成图表，发给老板。"一个普通的 LLM 只会告诉你"你可以用 SQL 查询然后用 Excel 画图"——说得头头是道，但什么都没干。 而 Agent 会真正地查数据库、调图表 API、发送邮件，全程自主完成。

🎯

Agent 的核心特征：自主性。 它不需要你在每一步都手动喂数据、手动触发下一步。你只管提需求，它自己搞定。

技术名词

如果说行为概念回答的是"LLM 怎么做事"，那技术名词回答的是"LLM 用什么做事"。

Transformer

Transformer 是 2017 年 Google 在论文 "Attention Is All You Need" 中提出的神经网络架构，也是今天所有 LLM 的底层基石。

在 Transformer 出现之前，序列建模的主力是 RNN（循环神经网络）和 LSTM（长短期记忆网络）。它们的致命问题是：必须一个词一个词地顺序处理，既慢又难以捕捉长距离依赖关系。Transformer 用一个叫做 Self-Attention（自注意力） 的机制彻底颠覆了这个范式——它让模型可以同时看到整个句子中的所有词，并自动学习哪些词之间关系更紧密。

打个比方：RNN 像是一个人用手指逐字阅读一本书，而 Transformer 像是一眼扫完整页，直接抓住关键信息。

对比维度	RNN / LSTM	Transformer
处理方式	顺序逐词处理	并行处理整个序列
长距离依赖	容易遗忘（梯度消失）	Self-Attention 直接建立全局连接
训练速度	慢（无法并行化）	快（天然支持 GPU 并行）
扩展性	难以扩展到超大规模	Scale 越大效果越好（Scaling Law）

Transformer 的核心组件包括：

Self-Attention：让每个词都能"关注"序列中的其他词，计算相关性权重

Multi-Head Attention：多组注意力并行运行，捕捉不同维度的语义关系

Position Encoding：给每个词注入位置信息（因为 Transformer 本身不感知顺序）

Feed-Forward Network：对注意力输出做非线性变换

🏗️

Transformer 是 AI Agent 的"地基"。 没有 Transformer，就没有 GPT、Claude、Gemini，自然也就没有后面的 Prompt、Tool Calling、Agent 和 MCP。整条 AI Agent 技术栈，都建立在这篇 2017 年的论文之上。

Prompt

Prompt 是你跟 LLM 说的每一句话——更准确地说，是你发送给模型的全部输入文本。

别小看这个词。在 AI Agent 的语境里，Prompt 远不止"请帮我写一首诗"这么简单。它是 Agent 的操作系统级指令，决定了 Agent 的人格、能力边界和行为模式。

一个典型的 Agent Prompt 通常包含多个层次：

层次	名称	作用	示例
第 1 层	System Prompt	定义 Agent 的身份、规则和能力	"你是一个数据分析助手，只能使用 SQL 查询工具"
第 2 层	Tool Description	向 LLM 描述可用工具的说明书	Tool 的 name / description / parameters
第 3 层	Context / Memory	对话历史、检索到的文档、环境信息	"用户上次问了上海的天气"
第 4 层	User Prompt	用户当前的实际输入	"帮我查一下明天北京的天气"

你看到的只是第 4 层，但 Agent 真正"读"到的是全部四层拼在一起的完整 Prompt。这也是为什么Prompt Engineering（提示词工程） 如此重要——它本质上是在为 Agent 编写"操作手册"。

🧩

Prompt 是 Agent 的灵魂。 Tool 决定了 Agent 能做什么，而 Prompt 决定了它会做什么、怎么做、以什么风格做。同样的工具集，换一套 Prompt，你能得到完全不同的 Agent 人格。

Tool

Tool 是 Agent 能够调用的"外部能力"的统称。

一个 Tool 通常由三部分组成：

名称（name）：search_web、send_email、query_database

描述（description）：告诉 LLM 这个工具是干什么的、什么时候该用

参数（parameters）：JSON Schema 格式，定义输入参数的类型和约束

Tool 的定义本质上就是一份"使用说明书"。LLM 通过阅读这份说明书来决定要不要用、怎么用。这也是为什么好的 Tool 描述至关重要——描述写得烂，LLM 就会误用、滥用或干脆不用。

MCP

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出的开放协议，目标是为 AI 应用与外部工具/数据源之间的连接提供统一标准。

为什么需要 MCP？想象这样一个场景：你有 10 个 AI 应用（IDE 插件、聊天助手、自动化脚本……），同时有 10 个数据源（GitHub、Slack、数据库、日历……）。没有 MCP 的时候，你需要写 10 × 10 = 100 个集成。有了 MCP，每个应用只需实现一个 MCP Client，每个数据源只需暴露一个 MCP Server，问题直接降维成 10 + 10 = 20 个适配。

🔌

MCP 的本质：AI 世界的 USB-C。 正如 USB-C 统一了充电和数据传输接口，MCP 统一了 AI 模型与外部世界的交互接口。

MCP 的架构非常清晰：

组件	角色	类比
MCP Host	AI 应用本体（如 Claude Desktop、IDE 插件）	你的笔记本电脑
MCP Client	与 Server 建立一对一连接的协议客户端	USB-C 接口
MCP Server	暴露 Tools / Resources / Prompts 的服务端	外接设备（硬盘、显示器……）

MCP Server 可以暴露三类能力：

Tools：可执行的函数（查数据库、发邮件、操作文件……）

Resources：上下文数据源（文件内容、数据库记录……）

Prompts：可复用的提示词模板

Context Engineering

Context Engineering（上下文工程） 是 2025 年迅速走红的新概念，被认为是 Prompt Engineering 的"全面升级版"。

如果说 Prompt Engineering 关注的是"怎么写好一句提示词"，那 Context Engineering 关注的是一个更大的问题：在模型有限的上下文窗口里，如何精心编排所有输入信息，使模型产生最理想的行为？

这包括但不限于：

System Prompt：Agent 的身份和规则

Tool 描述：可用工具的说明书

对话历史：哪些保留、哪些压缩、哪些丢弃？

检索结果（RAG）：从知识库中拉取的相关文档

记忆（Memory）：跨会话的长期记忆和短期工作记忆

环境状态：当前时间、用户偏好、系统状态……

Anthropic 在官方博客中这样总结：构建 AI 应用正在从"找到正确的措辞"转变为"找到最有可能让模型产生期望行为的上下文配置"。

🎛️

Context Engineering = 上下文的"总导演"。 Prompt Engineering 只管台词，而 Context Engineering 管整个舞台——灯光（Tool 描述）、布景（检索文档）、演员走位（对话历史管理）、甚至观众席的反馈（用户状态），全部精心编排，让 Agent 的每一次"演出"都恰到好处。

它和 Prompt Engineering 的关系是什么？来看对比：

对比维度	Prompt Engineering	Context Engineering
关注范围	提示词本身的措辞和结构	送入模型的所有信息的编排
核心挑战	"怎么说"才能让模型理解	"放什么"才能让模型做对
典型操作	Few-shot 示例、Chain-of-Thought	RAG 策略、记忆管理、上下文压缩、Tool 描述优化
适用场景	单轮对话、简单任务	多步 Agent、长会话、复杂工作流

简单说：Prompt Engineering 是 Context Engineering 的子集。 当你的 AI 应用从简单聊天升级到多步 Agent 时，你会发现光写好 Prompt 远远不够——你需要管理整个上下文的生命周期，这就是 Context Engineering 的领地。

Skills

Skills 是最近出现的更高层抽象概念，目前尚未形成统一标准，但方向非常明确：把一组 Tool + Prompt + 业务逻辑打包成一个可复用的"技能包"。

如果 Tool 是一把螺丝刀，那 Skill 就是"组装一台电脑"这个完整技能——它知道什么时候用螺丝刀、什么时候用扳手、以什么顺序操作。

层级	概念	粒度
最细粒度	Tool	单个函数 / API 调用
中间层	MCP Server	一组相关 Tool 的标准化封装
最粗粒度	Skill	Tool + Prompt + 业务流程编排

Skills 代表的方向是：Agent 不仅要有工具，还要有"经验"。 未来，你可能不再需要从零编排 Agent 的每一步，而是像安装 App 一样给它装上各种 Skill。

概念全景图

让我们用一张表把所有概念串起来，方便你随时回看：

概念	出现时间	一句话解释	类别
Transformer	2017	基于自注意力机制的神经网络架构，所有现代 LLM 的基石	技术
Prompt	2020	发送给 LLM 的完整输入，Agent 的身份与行为由此定义	技术
Prompt Engineering	2020–2022	通过精心设计提示词来引导 LLM 输出理想结果的系统方法论	技术
ReAct	2022.10	Thought → Action → Observation 的循环推理-行动范式	行为
Agent	2023.03	拥有自主决策循环的 AI 系统	行为
Function Calling	2023.06	LLM 输出结构化 JSON 来"建议"调用某个函数	行为
Tool / Tool Calling	2023.11	Function Calling 的标准化升级版，支持并行和多工具类型	行为
MCP	2024.11	AI 应用与工具/数据源之间的统一开放协议	技术
Skills	2025	Tool + Prompt + 业务逻辑的高级封装	技术
Context Engineering	2025	编排送入模型的所有信息，Prompt Engineering 的全面升级	技术

未来展望

AI Agent 的演进方向已经越来越清晰：

从"对话"到"协作"。 今天的 Agent 大多还是单打独户，但 Multi-Agent 架构正在成为热点——多个专业 Agent 各司其职、相互协作，像一支 AI 团队一样完成复杂项目。Google 的 A2A（Agent-to-Agent）协议和 MCP 正在为这种协作铺路。

从"开发"到"配置"。 随着 MCP 生态的成熟和 Skills 概念的落地，构建一个 Agent 的门槛会越来越低。未来，普通用户可能只需要在商店里选几个 Skill、连上几个 MCP Server，就能组装出一个高度定制化的个人助手。

从"助手"到"同事"。 当 Agent 具备了长期记忆、持续学习和主动行动的能力，它将不再是一个"被动等待指令的工具"，而是一个"主动发现问题、提出建议、执行任务的数字同事"。

这场变革才刚刚开始，而此刻正是入场的最佳时机。

📎 参考文章

ReAct Prompting | Prompt Engineering Guide — ReAct 范式的系统讲解

What is Model Context Protocol (MCP)? - IBM — IBM 对 MCP 的深度解读

Introducing the Model Context Protocol - Anthropic — Anthropic 官方 MCP 发布公告

MCP Architecture Overview — MCP 官方架构文档

Understanding the Difference Between Function Calling and Tools — Function Calling 与 Tool 的对比分析

Building ReAct Agents from Scratch - Google Cloud — 从零构建 ReAct Agent 实战

Effective Context Engineering for AI Agents - Anthropic — Anthropic 官方 Context Engineering 实践指南

写在最后

回顾整篇文章，我们从 AI Agent 的三要素（大脑 + 工具 + 行动循环）出发，依次拆解了 Function Calling → Tool Calling → Agent → ReAct 这条从简单到自主的行为演进线，以及 Tool → MCP → Skills 这条从单一到生态的技术演进线。

如果你只记住一件事，就记住这个：Function Calling 让 LLM 学会了"指挥"，Tool Calling 让它学会了"协调"，ReAct 让它学会了"思考着行动"，而 MCP 和 Skills 则让整个生态真正连接并可复用。

AI Agent 不是又一个被过度炒作的概念——它是 LLM 从"能说会道"进化到"能说会做"的关键拐点。现在，轮到你去构建属于自己的 Agent 了。

💡

欢迎您在底部评论区留言，一起交流~