夜雨聆风大家好，我是不想刷算法的懒羊羊
AI的浪潮愈发汹涌，agent开发成为新的风口，随之而来的是一堆把人绕晕的名词
MCP、Skill、Function Calling、Workflow、ReAct、Plan-and-Execute、Reflection
今天我们就来做个汇总，看看这些新词到底在讲啥玩意，同时还要知道他们之间的区别是什么
比如：
MCP 和 Function Calling 都能让模型用工具，他们到底有什么区别？ Skill 是不是就是一个提示词？ Workflow 和 Agent 是一回事吗？ ReAct 和 React 前端框架有没有关系？ Plan-and-Execute 和 Reflection 又是在解决什么问题？
先把这些概念放到同一张图里，看清楚他们分别站在哪个位置。
大模型本身可以理解、推理、生成文本。但真实业务里，我们还希望他能：
读到外部资料 调用系统接口 按固定流程干活 遇到复杂问题会拆解 做完之后还能自己检查一遍
于是出现了agent，而这些名词，本质上都是在让agent从能用变成好用的关键能力
先记住一句话：
Function Calling 解决“模型怎么提出调用工具”，MCP 解决“工具怎么标准化接入”，Skill 解决“经验怎么复用”，Workflow / ReAct / Plan-and-Execute / Reflection 解决“任务怎么组织执行”。
是不是稍微清楚一点了？
下面我们一个一个看。
一、Function Calling：让模型按格式提出工具调用请求
先看最常见的 Function Calling。
现在很多平台也会把它叫做 Tool Calling，本质上说的是同一类事情。
很多人第一次听到这个词，会以为是大模型真的跑去调用了某个函数。
其实不是。
更准确地说：
Function Calling 是让模型在需要使用外部能力时，按你定义好的格式，输出一次“我要调用哪个函数、参数是什么”的请求。
真正执行函数的，还是你的程序。
举个例子：
用户问：
帮我查一下哈尔滨今天的天气你提前告诉模型，现在有一个工具：
{"name": "get_weather","description": "查询城市天气","parameters": {"city": "string" }}模型发现自己不知道实时天气，于是不会直接瞎编，而是返回类似这样的结构：
{"name": "get_weather","arguments": {"city": "哈尔滨" }}然后你的后端程序拿到这个结构化结果，真正去调用天气接口。
天气接口返回结果后，再把结果塞回上下文，让模型组织成自然语言回答用户。
整个过程可以理解为：
你告诉模型有哪些函数可以用 模型判断是否需要调用函数 模型生成函数名和参数 应用程序真正执行函数 函数结果返回给模型 模型生成最终答案
所以 Function Calling 的关键点不是“调用”，而是“结构化地表达调用意图”。
他解决的是一个很实际的问题：
以前你让模型输出 JSON，很可能今天多一个逗号，明天少一个字段，后端解析的时候血压拉满。
Function Calling 相当于把输出格式收紧，让模型更稳定地告诉程序：
我要用哪个工具，以及这个工具需要什么参数。
Function Calling 是模型先根据用户意图决定“要不要调、调哪个、参数是什么”，再由你的代码执行。
模型像一个会写调用单的人，但不是那个真正去仓库搬货的人。
二、MCP：给 AI 工具接入加一层统一插座
理解了 Function Calling，再来看 MCP。
MCP 全称是 Model Context Protocol，中文可以理解为模型上下文协议。
他的目标是：
用一套统一协议，让 AI 应用连接各种外部工具、数据源和工作流。
如果不使用 MCP，会发生什么？
假设你做了一个 AI 编程助手，希望它能访问：
本地文件 Git 仓库 数据库 Jira Sentry 浏览器
每接一个系统，都要写一套适配逻辑。
A 工具一种认证方式，B 工具一种返回格式，C 工具又一堆奇怪参数。
最后你的项目很容易变成“接口适配器大杂烩”。
MCP 想解决的就是这个问题。
他更像 AI 世界里的 USB-C：
不管后面接的是文件系统、数据库，还是某个 SaaS 服务，对 AI 应用来说，都尽量通过统一协议来发现和调用。
MCP 里有几个角色：
Host：用户真正使用的 AI 应用，比如聊天客户端、IDE、智能体平台Client：Host 里面负责和某个 MCP Server 建连接的组件Server：对外暴露工具、资源、提示词的服务
MCP Server 通常可以暴露三类东西：
Tools：可以被模型请求执行的动作，比如查数据库、创建工单、读取文件Resources：可以提供给模型读取的上下文数据，比如文件内容、接口返回、业务文档Prompts：可复用的提示词模板或任务入口
client和server端之间的标准传输方式有stdio和streamableHTTP两种（SSE已经在去年被Athropic官方标记为不推荐使用），底层数据传输格式采用JSON-RPC-2.0
那么 MCP 和 Function Calling 的区别是什么？
这俩确实很像，因为最后看起来都是“模型在用工具”。
但是他们站的位置不一样。
Function Calling 更偏模型和应用之间的一种工具调用机制。
你把函数 schema 给模型，模型返回函数名和参数，你的程序执行。
MCP 更偏外部工具和 AI 应用之间的一套接入协议。
它规定一个工具服务应该怎么被发现、怎么描述能力、怎么被调用、怎么返回结果。
如果用快递打比方：
Function Calling 像“用户填了一张标准快递单” MCP 像“所有驿站、快递柜、分拣中心之间遵守的一套物流接口”
这两个不是竞争关系。
一个 AI 应用完全可以先通过 MCP 接入很多工具，再把这些工具以 Function Calling / Tool Calling 的形式交给模型选择。
所以不要问“有了 MCP 还要不要 Function Calling”。
更合理的理解是：
Function Calling 管模型怎么提出调用，MCP 管工具怎么接进来。
三、Skill：把一类任务的经验打包
再来看 Skill。
这个词在不同平台里定义会有差异，但核心思想很接近：
Skill 是把某一类任务的知识、步骤、模板、脚本、素材打包成一个可复用能力。
它不像 Function Calling 那样，只描述一个具体函数。
它也不像 MCP 那样，重点在协议连接。
Skill 更像一个“做事说明书 + 小工具箱”。
比如一个“写公众号文章”的 Skill，里面可能包含：
标题风格要求 开头怎么引入 图片怎么命名 Markdown 模板 常用检查清单 生成封面图或流程图的脚本
当用户说“帮我写一篇公众号文章”时，AI 就可以加载这个 Skill，按照里面沉淀好的经验去做。
这里最容易混淆的是：
Skill 不是单纯的一句 Prompt。
Prompt 更像你临时对模型说的一段话。
Skill 更像一个长期沉淀下来的任务包。
里面可以有 Prompt，也可以有代码、模板、示例、图片资源、检查流程。
再换个角度：
Function Calling：一个具体动作，比如“查询订单” MCP：把外部系统标准化接入，比如“订单系统以 MCP Server 形式暴露出来” Skill：指导 AI 怎样完成一类任务，比如“如何写一篇订单异常分析报告”
Function Calling 更像按钮。
MCP 更像插座。
Skill 更像老师傅留下来的操作手册。
四、Workflow：流程是提前设计好的
上面讲述的是赋予agent的能力，从这里开始就是约束和指引agent工作的流程框架，他要求模型必须按照什么样的模式去行动
首先是Workflow 这个词。
在 AI 应用里，Workflow 指的是：
开发者提前设计好任务步骤，模型只是流程中的一个或多个节点。
比如你要做一个“自动写文章”的工作流：
输入主题 生成大纲 搜索资料 生成正文 检查错别字 生成配图 导出 Markdown
这条路线是提前写好的。
模型可以参与每一步，但整体流程不是它临场决定的。
Workflow 的好处是稳定、可控、适合业务系统。
比如报销审批、客服工单、合同审查、内容审核，这类任务通常都有明确步骤，不适合让模型完全自由发挥。
但是缺点也很明显：
流程越固定，灵活性越差。
如果用户的问题完全不按套路来，Workflow 可能就会显得比较笨。
所以 Workflow 更像流水线。
每个工位干什么，先后顺序是什么，提前就安排好了。
五、ReAct：一边思考，一边行动
接着是 ReAct。
它的核心循环很简单：
思考 -> 行动 -> 观察结果 -> 再思考 -> 再行动 -> ...举个例子：
用户问：
帮我看看这个项目为什么启动失败一个 ReAct 风格的 Agent 可能会这样做：
先思考：启动失败可能和依赖、配置、端口、环境变量有关。
然后行动：读取日志。
观察结果：日志里提示端口被占用。
再思考：需要查看哪个进程占用了端口。
再行动：执行命令查看端口占用。
观察结果：发现另一个服务占用了 8080。
最后回答：问题原因是端口冲突，可以关闭旧进程或修改端口。
这就是 ReAct 的味道。
它不是提前把所有步骤写死，而是每拿到一个新观察结果，就重新判断下一步做什么。
所以 ReAct 很适合：
排查问题 搜索资料 使用工具探索未知环境 任务路径不确定的场景
和 Workflow 相比：
Workflow 是“先规定路线，再按路线走”。
ReAct 是“边走边看路牌，随时调整下一步”。
当然，这也意味着 ReAct 更容易跑偏。
如果没有工具权限、边界条件和终止条件，它可能会绕很久，甚至越查越远。
六、Plan-and-Execute：先做计划，再分步执行
Plan-and-Execute 从名字上就能看出思路：
先让模型规划任务，再让执行器按计划一步步完成。
比如用户说：
帮我做一个 AI 名词扫盲文章Plan-and-Execute 风格可能会先生成一个计划：
收集需要解释的名词 按“工具接入、任务组织、反思优化”分类 为每个名词写定义和例子 加入容易混淆概念的对比 生成配图 最后通读润色
然后执行器按这个计划逐步推进。
它和 ReAct 的区别在于：
ReAct 更像“每走一步想一步”。
Plan-and-Execute 更像“先画一张地图，再按照地图执行”。
Plan-and-Execute 适合比较长、比较复杂、可以拆步骤的任务。
比如写方案、做调研、迁移项目、生成测试计划。
它的优点是全局感更强，不容易只盯着眼前一步。
但缺点也很现实：
计划可能不准。
如果中间发现环境和预想不一样，就需要重新规划。
所以很多实际 Agent 系统会把它和 ReAct 结合起来：
先整体计划，执行过程中每一步再根据观察结果微调。
七、Reflection：做完之后自己审一遍
最后来看 Reflection。
Reflection 可以理解为“反思”或者“自我检查”。
它的核心思路是：
模型先生成一个结果，再让模型或另一个评估器检查这个结果，提出反馈，然后继续修改。
比如写文章时：
第一轮生成正文。
第二轮检查：
有没有概念说错 有没有前后重复 有没有读者看不懂的地方 语气是不是太像说明书
第三轮根据反馈重写。
这就是一个非常典型的 Reflection 流程。
如果用更工程一点的说法，它也经常被叫做“生成器 - 评估器 - 优化器”模式。
这里有几个容易混淆的地方：
Reflection 不是 Plan。
Plan 发生在做事之前，先想怎么做。
Reflection 发生在做事之后，检查做得怎么样。
Reflection 也不是 ReAct 里的 Observation。
Observation 通常是工具或外部环境返回的事实，比如日志、网页内容、接口结果。
Reflection 是对当前答案或过程的评价，比如“这个解释不够清楚”“这个结论证据不足”。
当然，Reflection 也不是万能的。
模型自己检查自己，有时候也会一本正经地漏掉问题。
所以在关键场景里，最好配合测试、规则校验、人工审核、真实数据验证一起用。
别把“自我反思”当成“绝对正确”。
人都做不到，模型更不能强求。
八、把这些概念放在一起
最后，我们把这些词重新放到一张对比图里。
如果只想快速判断，可以这么记：
Function Calling：让模型按结构化格式提出工具调用请求。
MCP：让工具、数据源、提示词以统一协议接入 AI 应用。
Skill：把某一类任务的经验和资源打包复用。
Workflow：流程提前写好，模型按节点参与执行。
ReAct：模型边思考边行动，根据观察结果动态决定下一步。
Plan-and-Execute：先整体规划，再按步骤执行。
Reflection：做完之后评估、反馈、修改，提高结果质量。
如果用一句更口语的话总结：
Function Calling 负责“怎么喊工具”，MCP 负责“工具怎么接进来”，Skill 负责“经验怎么传下来”，Workflow 负责“路线怎么排”，ReAct 负责“边走边判断”，Plan-and-Execute 负责“先画地图再出发”，Reflection 负责“做完回头检查”。
在一个真实的agent里，这些东西往往不是单独出现，而是组合使用。
比如一个比较完整的 AI 编程助手，可能是这样的：
用 Skill 加载代码审查规范 用 MCP 连接本地文件、Git、Issue 系统 用 Function Calling 让模型选择读取文件或执行命令 用 Plan-and-Execute 先拆解修复计划 用 ReAct 在排查过程中根据日志不断调整 用 Reflection 最后检查改动有没有遗漏 用 Workflow 把这一整套流程固定成团队工具
当然这只是其中部分功能，实际情况要更加复杂，比如要考虑一个agent的安全权限，上下文管理，记忆系统，hook以及多智能体协同等等，有机会我们展开细细聊聊
关于 AI 名词扫盲的文章就介绍到这里了，想要分享和补充的朋友欢迎在评论区留言。
我是不想刷算法的懒羊羊，一个非科班转码的后端新人，希望这篇文章对你有帮助，喜欢就点赞关注吧！
