概念梳理：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. 持續更新的實訓項目帶教直播

這些項目是已經被大量同學驗證有效的，可以被寫進簡歷，大大增加你的面試機會和通過率！

更多實戰安排和成功學員案例，聯系班主任了解~

技術和玩法高速迭代，所以機會窗口不會太久。

唯一的解法就是，小步快跑加入進來。

進來就不怕技術迭代，不進來門檻只會越來越高。