AI Agent 核心概念全景图：Prompt、RAG、微调、Tool Call、状态机、Workflow 与 MCP

很多人以为 AI Agent 只是"大模型加一个聊天框"。真到落地时才发现，真正决定系统质量的，往往不是模型本身，而是 Prompt、知识检索、工具调用、状态管理、任务编排和外部能力接入这些基础能力。

如果你最近在看 AI Agent，会反复遇到这些词：

Prompt
RAG
Fine-tuning
Tool Call / Function Calling
状态机
Workflow
MCP

它们都和 Agent 有关，但又不在一个层面上。

最常见的困惑不是"不会写代码"，而是：

这些概念分别在解决什么问题？边界在哪？做项目时又该怎么组合？

这篇文章的目标很简单：把这些概念放到同一张架构地图里讲清楚，让你对 AI Agent 建立一套能直接指导工程落地的认知框架。

先记住一句话

如果只想先抓住主线，可以先记住下面这 7 句话：

Prompt：告诉模型这次该怎么做
RAG：给模型补充这次需要参考的知识
Fine-tuning：让模型长期习惯这样做
Tool Call：让模型从"会说"变成"会做"
状态机：描述 Agent 当前运行到哪一步
Workflow：规定任务接下来该怎么走
MCP：让工具、资源和上下文用统一协议接入

你会发现，这些概念并不是替代关系，而是分工关系。

一张图看懂 AI Agent

查知识
调工具
不需要
用户输入
Prompt 组装
大模型推理
是否需要外部能力
RAG 检索
Tool Call
外部系统 / API / 数据库
直接生成结果
Agent 状态机
Workflow 编排
MCP 接入协议
日志 / 审计 / 回放 / 前端展示

图 1：一个可落地 AI Agent 的典型能力分层

从这张图里，可以先得到一个很重要的判断：

Prompt 是任务入口
RAG 解决知识补充
Tool Call 解决行动能力
Workflow 解决多步编排
状态机解决运行过程可控
MCP 解决外部能力标准化接入
微调则作用在模型本身，用来提升长期稳定性

概念速览：先看边界，再看定义

概念	核心作用	最适合解决	不适合解决
Prompt	定义本次任务、角色、规则	快速控制模型行为、搭 MVP	长期稳定固化复杂行为
RAG	在运行时补充外部知识	私有文档、规则手册、可变知识	固化行为习惯、实时执行动作
Fine-tuning	把模式"练进模型"	固定格式输出、稳定分类、专用小模型	频繁变化的知识、实时信息
Tool Call	调用外部函数与系统	查库、发请求、创建工单、执行操作	替代任务编排和权限治理
状态机	管理运行阶段	展示中间态、支持恢复、排障	描述完整业务流程
Workflow	编排步骤与分支	多步任务、条件判断、异常兜底	替代状态可观测设计
MCP	标准化接入工具与上下文	多工具纳管、平台化复用	替代模型决策本身

这张表建议反复看。很多项目里的混乱，根源就是把这些职责混在了一起。

1. Prompt：AI Agent 的起点，不是终点

Prompt 到底是什么

Prompt 可以理解为你给模型的任务说明书。但在真实 Agent 系统里，它通常不是一句简单提问，而是一组动态拼装后的上下文。

常见组成包括：

System Prompt：角色、目标、边界
Developer Prompt：开发者约束
User Prompt：用户当前请求
Conversation Context：多轮对话历史
Retrieved Context：RAG 返回的资料
Tool Results：工具执行结果
Output Schema：输出格式要求

所以，Prompt 的本质不是"问一句话"，而是：

给模型一份当前任务的完整执行说明。

Prompt 主要解决什么问题

它主要负责三件事：

定义角色：你是谁
定义任务：你现在要做什么
定义规则：你应该怎样做，不能怎样做

比如：

你是一个企业客服助手
不允许编造订单状态
如果参数不全，优先追问用户
最终必须输出 JSON

Prompt 的优势和边界

Prompt 的优势很明显：

上手快
成本低
试错快
适合 MVP 和规则频繁变化的场景

但它也有天然边界：

上下文一长，规则容易被稀释
约束越多，冲突越多
稳定性不如训练后的能力
复杂系统不能只靠 Prompt 硬撑

一个实用判断是：

Prompt 适合"快速控制"，不适合"长期硬编码一切"。

2. RAG：让模型具备"查资料"的能力

RAG 是什么

RAG 的全称是 Retrieval-Augmented Generation，中文通常叫"检索增强生成"。

它的核心思想很直白：

先查资料，再回答问题。

也就是说，RAG 不是把知识训练进模型，而是在运行时把相关内容检索出来，临时补充给模型。

RAG 最适合解决什么问题

RAG 最适合处理下面这类问题：

模型原本不知道
模型知道，但不够准确
知识经常变化
需要来源可追溯

典型场景包括：

企业内部制度问答
产品文档问答
API 文档问答
合同条款检索
运维 SOP 查询
私有知识库问答

RAG 的基本流程

用户问题
Query 理解或重写
检索
向量检索 / 关键词检索 / 混合检索
召回候选内容
重排与过滤
拼接上下文
大模型生成答案

图 2：一个典型 RAG 流程不只是"向量检索"，还包括召回、重排和上下文组装

真实工程中的 RAG 通常还会涉及：

文档切片
embedding 向量化
lexical 词汇检索
hybrid retrieval 混合检索
rerank 重排
引用来源展示
低置信度兜底

RAG 的核心边界

RAG 擅长补充知识，但不擅长固化行为。

例如：

"公司退款规则是什么？"适合 RAG
"永远使用统一客服语气回复"更适合 Prompt 或微调

所以可以用一句话记忆：

RAG 解决的是"模型这次需要知道什么"。

3. Fine-tuning：把能力练进模型

微调是什么

Fine-tuning 指的是在已有模型基础上，用特定任务数据继续训练，让它更擅长某个领域、某种输出方式或某类固定任务。

一个很直观的比喻是：

Prompt：考试前提醒注意事项
RAG：考试时允许查资料
微调：平时就把这类题练熟

微调最有价值的地方

微调最适合解决的不是"补知识"，而是"固化模式"。

典型收益包括：

固定输出格式更稳定
统一语气和风格更一致
分类、抽取、路由更可靠
减少超长 Prompt 依赖
让小模型承担专用任务

特别适合的任务有：

文本分类
意图识别
结构化抽取
风险标签识别
标准化报告生成

微调不该承载什么

下面这些内容通常不适合靠微调承载：

经常变化的业务规则
最新文档内容
实时数据库真值
需要精确查询的外部信息

一句话概括它的边界：

微调解决的是"模型长期习惯怎么做"，不是"模型这次该查什么"。

4. Tool Call：让模型真正开始"做事"

Tool Call 是什么

Tool Call 或 Function Calling，本质上是让模型在推理过程中不只输出自然语言，还能请求调用某个外部函数。

比如用户说：

帮我查一下今天上海的天气。

模型不需要直接猜答案，而是可以生成这样的调用意图：

json 复制代码

{
  "tool": "get_weather",
  "arguments": {
    "city": "Shanghai",
    "date": "today"
  }
}

然后由系统实际执行工具，把结果再交回模型，完成最终回答。

为什么 Tool Call 是 Agent 的关键分水岭

没有 Tool Call，模型更多是在"表达"：

会说
会解释
会分析
会建议

有了 Tool Call，模型才真正有机会"执行"：

查数据库
调业务接口
发邮件
创建工单
查询订单
控制设备
写入系统记录

也就是说：

Tool Call 是 AI Agent 从"会聊天"走向"会执行"的关键一步。

一个典型执行链路

外部系统工具层大模型 Agent 系统用户外部系统工具层大模型 Agent 系统用户帮我查一下订单状态组装 Prompt 与上下文请求调用 query_order_status(order_id) 执行工具调用查询订单系统返回订单结果工具结果将结果回传模型生成最终回复你的订单已发货，预计明天送达

图 3：模型负责"决定调什么"，系统负责"真的去执行"

Tool Call 的工程难点

真正的难点从来不只是"接口能不能调通"，而是：

什么时候该调工具
该调哪个工具
参数如何补齐
参数是否合法
工具失败如何重试或兜底
多工具如何协作
如何避免死循环调用
如何做权限校验和审计

所以，Tool Call 很重要，但它本身并不等于完整的 Agent 系统。

5. 状态机：管理 Agent 的运行过程

为什么 Agent 需要状态机

一个真实 Agent 并不是永远处于"回答中"这一种状态。

它通常会经历很多中间态：

空闲等待
任务规划
工具执行中
等待工具返回
等待用户确认
汇总结果
已完成
已失败

如果没有状态机，你会很快遇到这些问题：

前端无法展示中间态
日志难排查
执行链路不易追踪
暂停、恢复、重试难实现

状态机到底在定义什么

状态机定义的是：

Agent 有哪些状态，以及这些状态之间允许如何转换。

例如：
idle
planning
running_tool
waiting_approval
summarizing
waiting_tool
completed
failed

图 4：状态机关注的是"当前处于哪个运行阶段"

状态机的价值

状态机最大的价值，在于让 Agent 具备更强的可控性和可观测性：

前端可以展示真实运行阶段
后端更容易做日志收口
更方便 trace 和 replay
更适合做中断恢复和失败治理

对于产品化 Agent 而言，状态机几乎是标配。

6. Workflow：让复杂任务可以被编排

Workflow 是什么

Workflow 可以理解为：

把复杂任务拆成多个明确步骤，并定义输入、输出、执行顺序、条件分支和异常处理。

例如，一个企业客服 Agent 的工作流可能是：

识别用户意图
判断是否需要查知识库
判断是否需要查订单
调知识库检索
调订单系统查询
汇总结果
记录日志或创建工单

这就是一条完整的 Workflow。

Workflow 和状态机最容易混淆

它们的区别可以直接用一张表看懂：

维度	状态机	Workflow
关注点	当前处于什么状态	接下来该执行什么步骤
回答的问题	现在在哪	下一步怎么走
典型内容	planning、waiting_tool、completed	检索、查库、审批、总结、兜底
主要价值	可观测、可恢复、可治理	可编排、可控制、可扩展

一个很好记的类比是：

状态机像"演员当前状态"
Workflow 像"整部戏的剧本流程"

二者经常同时出现，但并不是一回事。

为什么生产环境离不开 Workflow

因为真实业务任务往往都包含：

多步判断
条件分支
工具协作
用户确认
异常兜底
人工介入

如果没有 Workflow，系统很容易退化成：

一切都交给模型自由发挥。

这对 Demo 也许足够，对生产环境通常不够。

7. MCP：统一工具与上下文接入的标准协议

MCP 是什么

MCP 通常指 Model Context Protocol。

你可以先把它理解为：

一种用于标准化接入工具、资源和上下文的协议。

它不替代 Tool Call，也不替代模型本身，而是在解决更底层的问题：

当 Agent 需要接越来越多外部能力时，如何用统一方式接入和治理？

MCP 在解决什么

如果没有统一协议，接一个工具通常都要分别处理：

参数定义
schema 说明
调用方式
返回格式
鉴权方式
错误处理
能力暴露方式

当你要接 GitHub、Jira、数据库、CRM、文档系统、内部 API 时，重复适配的成本会越来越高。

MCP 的价值就在于：

统一工具暴露方式
统一资源暴露方式
统一 schema 约束
统一上下文读取方式
统一能力发现机制

MCP 和 Tool Call 的区别

这是最容易被混淆的一组概念。

概念	关注层面	核心问题
Tool Call	模型执行层	现在要不要调函数？调哪个？参数是什么？
MCP	工具接入层	这些工具和资源如何以统一协议暴露出来？

一个更直白的类比是：

Tool Call 像"我要打电话"
MCP 像"统一的通讯录、号码规范和拨号协议"

所以两者不是替代关系，而是协作关系。

8. 把这些概念重新放回同一张架构图

到这里，再看下面这张图，层次就会清晰很多：
作用于
用户输入
Prompt 层

角色 / 规则 / 任务
大模型推理
RAG 层

知识检索与增强
Tool Call

工具调用决策
外部工具 / API / 数据库
Workflow

任务编排
状态机

运行状态管理
MCP

统一接入协议
Fine-tuning

能力内化
结果输出 / 前端展示 / 审计 / 回放

图 5：同一套 Agent 系统里，不同能力模块分别在不同层面发挥作用

如果要把它们再压缩成一句话：

Prompt 定义本次任务
RAG 提供本次知识
Fine-tuning 提升长期稳定性
Tool Call 提供行动能力
Workflow 规定步骤
状态机管理过程
MCP 标准化外部接入

9. 一个真实场景：运维分析 Agent 是怎么工作的

为了让上面的概念更落地，我们看一个典型场景。

用户对运维 Agent 说：

帮我看看昨天生产环境 API 错误率为什么突然升高。

一个成熟的 Agent 系统通常会这样工作。

第一步：Prompt 定义任务

系统先告诉模型：

你是运维分析助手
不允许编造监控数据
需要先查监控，再查日志
输出必须包含结论、证据和建议

第二步：Workflow 决定执行顺序

工作流可以定义为：

识别这是"故障分析"请求
查询监控平台
查询日志平台
对齐时间窗口
汇总证据
输出结论和建议

第三步：状态机描述运行阶段

这个过程里，Agent 可能会依次经历：

planning
running_tool
waiting_tool
summarizing
completed

前端就可以把这些中间态实时展示给用户。

第四步：Tool Call 调工具

模型可能发起：

query_metrics(service, time_range)
query_logs(service, level, time_range)

第五步：MCP 提供统一接入

如果监控平台、日志平台、工单平台都通过 MCP 暴露能力，Agent 的接入和治理成本就会低很多。

第六步：RAG 补充背景知识

如果还需要引用：

系统架构文档
错误码说明
历史故障复盘

那么就可以通过 RAG 把这些资料补充给模型。

第七步：微调提升稳定性

如果这个 Agent 长期要输出固定格式的故障分析报告，并且组织内部有统一术语和风格，那么微调就会有明显价值。

这个例子最能说明的一点是：

AI Agent 从来不是某一个技术点，而是多个能力模块的协同。

10. 做 AI Agent 最常见的 6 个误区

误区 1：把 Prompt 当成万能解法

Prompt 很重要，但它更像快速控制手段，不是万能底座。规则一多、流程一长，只靠 Prompt 往往会变脆。

误区 2：把 RAG 当成训练模型

RAG 不会修改模型参数，它只是把外部资料在运行时补充给模型。

误区 3：把微调当成知识库

如果知识经常更新，优先应该考虑 RAG、数据库查询或工具调用，而不是微调。

误区 4：把 Tool Call 理解成接口代理

难点不在"能不能调接口"，而在"何时调、调什么、调完怎么处理、失败怎么兜底、权限如何治理"。

误区 5：把 Workflow 和状态机混为一谈

Workflow 负责步骤编排，状态机负责运行状态管理。一个回答"怎么走"，一个回答"走到哪"。

误区 6：把 MCP 当成另一份接口文档

MCP 的价值不只是描述接口，而是让工具、资源和上下文以统一协议被发现、接入和治理。

11. 从 0 到 1，AI Agent 应该按什么顺序搭

如果你准备从零开始做一个 Agent，通常可以按这个顺序推进：

第一阶段：先把 Prompt 跑通

先验证两件事：

这个任务是否真的适合用 LLM
模型是否能在 Prompt 驱动下完成基础能力

这一步的目标不是做完整系统，而是快速验证价值。

第二阶段：补上 RAG

如果业务依赖私有知识、规则手册、产品文档，那么应尽早引入 RAG，让回答更准确、更可追溯。

第三阶段：接入 Tool Call

如果任务不只是问答，还需要查数据、改状态、联动系统，那么 Tool Call 很快就会成为核心能力。

第四阶段：加入状态机和 Workflow

当系统进入多步执行、长链路任务、前端中间态展示阶段，状态机和 Workflow 就会从"可选项"变成"刚需"。

第五阶段：再考虑微调

当你已经遇到下面这些问题时，再认真考虑微调：

Prompt 越写越长
few-shot 越堆越多
输出风格不稳定
高并发下成本压力大
希望小模型承担专用任务
已积累足够高质量样本

第六阶段：平台化时引入 MCP

当你的 Agent 开始：

接入越来越多外部系统
面向多个业务团队复用
需要统一工具治理与纳管

这时 MCP 的价值会越来越明显。

结语

AI Agent 不是"大模型外面套一层壳"，而是一整套围绕理解、检索、调用、编排、执行和治理展开的系统能力组合。

真正重要的，不是死记术语，而是搞清楚三件事：

每个概念分别解决什么问题
它们各自的边界在哪里
你的业务到底需要哪几层能力

当你把这张"能力地图"看清楚之后，再做架构设计、技术选型和工程落地，很多问题都会简单得多。

附：一句话速记版

Prompt：告诉模型这次该怎么做
RAG：给模型补充这次需要参考的知识
Fine-tuning：让模型长期习惯这样做
Tool Call：让模型可以调用外部能力
状态机：描述 Agent 当前处于哪个运行阶段
Workflow：规定任务接下来该怎么走
MCP：统一工具、资源和上下文的接入协议