概念梳理：Agent、Workflow、Skills、MCP…|agent|json|workflow|上下文|概念梳理|调用

我这两天直播，被问到最多的问题是：

Agent、智能体、Workflow、Skills、MCP这些概念都有啥区别？
OpenClaw 跟他们有啥关系？
老板让给公司部署一个，能行么？
企业需要 OpenClaw 么？Dify 咋办？

今天，给大家梳理一下。

概念的出现和演进

首先，作为产品经理你应该知道，我们使用的所有AI产品，都是通过API接口调用的LLM。

API 请求每一次都是独立的，但是 LLM 的 API 支持通过构造 message 数组的形式，把历史请求和返回的内容拼到当前请求，如：

"messages":[
{"role":"system","content":"你是一个有用的助理"},
{"role":"user","content":"你好AI"},
{"role":"assistant","content":"你好人类"},
{"role":"user","content":"介绍一下你自己"},
]

通过这样构造消息，我们完成了 Chatbot 的开发。

这就是最早的 AI 产品 — 套壳 ChatGPT。

因为 AI 的知识是在训练完后就写死的，不能实时更新、也没有企业内知识，于是我们想到了通过先检索为模型增强它的知识，再让它生成的办法，这就是大名鼎鼎的 RAG — 检索增强生成。

这里检索有两种方式：一种是把它调用搜索引擎 API，在互联网上检索；另一种是在内部知识库里检索。

关于在内部知识库里检索这个方式，人们参考大模型内部知识的结构对自己的知识进行处理。

这就是名震 2023 的知识嵌入-Embedding，存储这些知识的数据库叫做“向量数据库”。

这两种检索的结果最终都还是要回到 API 请求，只是请求内容变成了：

用户问了下面这个问题：
我们检索到了以下资料：
请参考资料回答用户的问题。

所以，RAG 也是 Chatbot 的延伸。

后来，人们想：你 LLM 能不能自己使用搜索工具，别每次都让我们来搞？

LLM：可以，告诉我你那个搜索工具是怎么请求的，不也是个 json 么？我按你要求输出请求需要的内容，完了后面的程序拿去请求，把请求结果拼接到 message 数组里再发给我就好了。

这个让大模型严格输出某种格式有专门的叫法：Function Calling、Tool Call、Tool use…

它们本质上是在提示词里跟 AI 说清楚使用这个工具需要的参数格式，让模型按需求输出就好了。

大概类似（schema 我瞎写的）：

"tools":[
{
"name":"weather",
"description":"需要查天气的时候可以用这个工具",
"schema":"想调用这个工具，得输出下面的格式"
}
]

我们可以一次为 LLM 提供多个工具让它选，于是我们进入到了一种“有点智能”的产品形态：

模型可以根据问题“选择”合适的工具，“调用”后为自己构造上下文。

这里模型只负责输出调用工具所需的 json 格式，工具的具体调用是由我们的程序员写的。

一旦有点智能，人就会分化出两种态度：

我 x，牛 x，搞搞搞！
我 x，垃 x，自己搞！

前面那波人，搞出了当时名噪一时的 AutoGPT：一个让 LLM 能自主选择工具、帮它构造多轮 messages 的 Agent。

后面那波人，则搞出了另一个名噪一时的 Dify：一个把所有工具搞成节点，把它们和 LLM 编排在一张画布上的智能体。

那可是 2023 年，可想而知玩 Agent 的那帮人在顶着什么样的压力…

动不动输出 json 的时候带着```，或者非得解释一下自己的 json
动不动被调用工具返回的信息撑爆了上下文窗口
动不动陷入一种不解决问题的循环、或者闭着眼说瞎话交付垃圾给你

所以主流还是 Workflow 们，从 2023 到 2025 整整两年，因为可控可编排，备受企业青睐。

以至于，到现在，Agent 这词一直和智能体一起放在各种岗位招聘描述里

你 Agent 不行，我智能体先用用怎么了。

实际上，我们要清楚一件事：虽然国区用“智能体”称呼 Workflow 编排出来的产品形态，但是当时可是因为不相信它“智能”。

它本质上还是 Chatbot，只是我们在那个请求 API 里塞了一连串工具产出的上下文。

复杂不能造就智能，简单才能。

Agent 分支才真的配得上是“智能”体，因为它们的底层逻辑就是一个简单的可以循环执行大模型请求、工具调用、消息拼接的程序。

当人类问题进入 Agent，循环就启动了：

审视问题、拆解问题
使用工具为解决问题构造上下文
再次发给模型：审视问题、拆解问题
使用工具为解决问题构造上下文
再次发给模型：审视问题、拆解问题

直到某次请求大模型时，大模型返回的结果是：ok，用户的问题被解决了。

万物皆是工具，万事皆可循环。

这个形态，真正成为生产力是 2024 年下半年 sonnet-3.7 发布以后。

先是 Cursor，然后是 Manus。

考虑到每个 Agent 都要用工具，要用很多工具，Claude（发布 sonnet-3.7 那个）说：要不咱们搞个标准吧，大家写工具的时候都按照这个标准来，这样写好的工具就能复用了。

这个标准就是 MCP：为模型 M 构建上下文 C 时的协议 P。

这个概念，随着 Manus 爆火，火了大半年。

它本质上还是 Tool，只是大家都按照一个标准写（客户端和服务），用起来会更方便。

但不管 MCP 还是 Tool，都有一个致命的问题：

关于这个工具的一切（名字、描述、参数结构）都会被塞进 Agent 的上下文里，即便 Agent 用不到它。

相当于，你手机上下载了一堆 App，但不是每一个都一直被打开使用。

这事，也一直没个解决方案，直到 Claude 自己下场做了个 Agent 才被解决。

事情是这样的：

Claude 发现：癌，你 Cursor 这 Agent 挺废 token 啊！你一火，我这嗷嗷赚钱！

于是，它们自己也弄了一个更好用的，让大家烧更多 token。

Claude 没有写应用程序，而是直接把自己塞进终端里了。

为啥用终端这种上古神器呢？

因为 Cursor 要为用户编写程序，就必须拥有能在用户的电脑上创建“程序代码文档”的工具。

终端(CMD)这个上古神器就非常符合需求：它拥有操作系统最底层的权限，别说创建文档了，重装系统它都能做到(伏笔)。

于是，Claude 最大客户 Cursor 的最大竞品，Claude Code 横空出世，成为整个 2025 年开发者们的心头好。

Claude Code 作为一个 Agent，肯定支持让用户配置 MCP 来拓展 LLM 可使用的工具列表。

但是，MCP 这东西太占用上下文空间了。

于是 Claude 团队心想：

你配置一 MCP 或者工具进来，不就是告诉大模型遇到这种该怎么办、怎么调用我这程序么
不管你啥程序，来到我 Claude Code，最终不都是在终端里的一条指令么
那么我们能不能这样：你先告诉我你是干嘛的，具体咋干先别提；等我需要用你了，再来看看你具体咋用。
你给我一个文档，开头是简单描述，下面是详细介绍，详细介绍里如果涉及的使用工具程序，你告诉我在终端里运行啥指令，具体的程序文档参考资料，你弄个文件夹放一块。

这就是 Skills - 技能。

再后来的故事，相信大家都知道了：一个外国小伙，财富自由了没事干，自己写了一个“Claude Code”，把它安装到电脑上，给了它所有权限。

系统提示词是：别问，直接干！

然后把它接入到了飞书里，以方便自己不在电脑前的时候，也能给它的“Claude Code”发消息。

名为：～Clawbot～～Moltbot～ OpenClaw。

企业怎么选？

上完历史课，大家应该也清楚了：

Dify 类 Workflow，属于需要严格控制 LLM 上下文构造的 ChatBot 分支
OpenClaw 属于相信 LLM 比人类更会编排流程的 Agent 分支

这俩没有好坏之分，只是不同场景、不同可控性要求的两个选择。

当你需要更标准化的流程、需要严格按照指定步骤完成上下文构造、并严格审阅 LLM 的输出，那么部署一个 Dify 或者自研一套可编排工具的 ChatBot 产品很合适。

当你能接受更高的自由度、或者执行自己无法胜任但相信模型能搞定的任务，OpenClaw 类 Agent 是更好的选择。

如果你既想体验先进刺激的 Agent，又希望 Agent 作业过程可控，可以把你编排的 Workflow 封装成技能 Skills，让 Agent 按编排好的流程作业。

产品经理们怎么学？

OpenClaw 带来了一个让大家更好转型的抓手：一次范式转移，激发了更多团队想要尝试变革，带来了更多岗位和话题切入点。

但是，关于打造一款 Agent 所需的基本功，一个都不会少。

比如最基本的一个问题：设计 Agent 时，如何写提示词？

这个问题的答案，几乎包含了此刻一个产品经理关于 AI 大模型的全部基本功。

欢迎报名我的 AI 产品经理转岗特训营！你需要要的一切，我过去一整年都在迭代、准备。

这套课程经过了 2 年 + 7 轮迭代，包含了过去 2 年 AI 产品一路进化过来的所有必备技能。

不管你是要做公司的 AI 赋能规划还是要转岗成为一名大模型行业从业者，它都能以更快的速度帮你补齐：

开篇建立全局认知，包括整个 AI 行业的生态图景、AI 业务类型和 AI 岗位职责，像你第一轮刷 JD 一样，先找到明确的方向
4 节课极速带你入门但是非常扎实的掌握大模型的底层原理，确保你跟面试官聊基本认知的时候不露怯（其实学完你会站到比大部分人更高的认知维度）。
放心，原理都是浅显易懂的（只要你会玩狼人杀就能听懂）。但是这些知识基建非常重要，“速成”但不是“催熟”的，我会确保你面试的时候问到“为什么这么设计提示词”时，也能对答如流。
课程的核心章节用 13 节课讲透了提示词工程RAG知识库Dify微调四个实战必学技能
前面说到的 Vibe Coding 技能，课程也有讲，只不过比你想象中的要快：只要 4 节课，你就能开发以一个自己的 MCP 出来！
紧接着是从需求到产品设计上线的全流程串讲：面试最容易被问到的“这个场景怎么用 AI 赋能”我有一整节课专门教你如何拆解；我甚至为上下文构建和 PRD 那节课专门写了一个 4 万字的 AI 产品专属 PRD（
最后一章是 3 节手把手教你筛 JD、改简历、准备面试的内容，还提供了 100 道 AI 面试真题的解析
以及本文提到的 Agent 原理和实践更新内容。