概念梳理：Agent、Workflow、Skills、MCP…

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

1. Agent、智能体、Workflow、Skills、MCP这些概念都有啥区别？
2. OpenClaw 跟他们有啥关系？
3. 老板让给公司部署一个，能行么？
4. 企业需要 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 格式，工具的具体调用是由我们的程序员写的。

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

1. 我 x，牛 x，搞搞搞！
2. 我 x，垃 x，自己搞！

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

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

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

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

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

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

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

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

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

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

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

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

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

直到某次请求大模型时，大模型返回的结果是：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 团队心想：

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

这就是 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 赋能规划还是要转岗成为一名大模型行业从业者，它都能以更快的速度帮你补齐：

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

7. 最后一章是 3 节手把手教你筛 JD、改简历、准备面试的内容，还提供了 100 道 AI 面试真题的解析
8. 以及本文提到的 Agent 原理和实践更新内容。

详细的课程大纲和学习计划，可以联系班主任获得。

如果你想要抓住这波金三银四转岗的机会，我还提供了实训项目带教，帮你补齐没有项目经验的短板。

1. 5个应对招聘 AI 能力要求的实训项目
2. 5个企业级项目&产品经理能力养成实训3. 持续更新的实训项目带教直播

这些项目是已经被大量同学验证有效的，可以被写进简历，大大增加你的面试机会和通过率！

更多实战安排和成功学员案例，联系班主任了解~

技术和玩法高速迭代，所以机会窗口不会太久。

唯一的解法就是，小步快跑加入进来。

进来就不怕技术迭代，不进来门槛只会越来越高。