我悟了！論MCP Server與工作流在智能體開發(fā)場景中的作用和區(qū)別 原創(chuàng)
今天討論的是個(gè)很無聊的話題---意義，但是卻困擾我很長時(shí)間。最近突然頓悟了，有種開竅的感覺，下面我把最近關(guān)于智能體開發(fā)中工作流、Mcpserver的一些思考分享給大家，希望得到大家的指正。
閱讀本文前，默認(rèn)大家已經(jīng)對智能體開發(fā)、Mcp工作流、Dify有了一定的認(rèn)識(shí)，如果還沒了解過，可以看我以前的文章。
??智能體（Agent）的 3種表現(xiàn)類型：聊天助手、工作流與對話流??
??不再混淆了！一文揭秘MCP Server、Function Call與Agent的核心區(qū)別??
其實(shí)不管工作流還是MCP Server,適合傳統(tǒng)行業(yè)的,主要有以下兩條智能體路線：
1. 大模型+MCP+軟件工具 ，這個(gè)更接地氣，更有生產(chǎn)價(jià)值 ，因?yàn)閷I(yè)數(shù)據(jù)和資料的生產(chǎn)處理依然教給傳統(tǒng)專業(yè)的生產(chǎn)軟件去操作，只是決策者由人變成了大模型。在這個(gè)路線中，大模型充當(dāng)軍師和將軍的角色，出謀劃策，排兵布陣和帶兵打仗的活，都要一手抓。
2. 大模型+RAG+知識(shí)庫/工作流，這條路目前研究的人也比較多，出現(xiàn)的也比較早，以Coze和Dify平臺(tái)為例，但是目前真正有價(jià)值的落地場景還是屈指可數(shù)。玩過工作流的朋友，應(yīng)該比較清楚，在這個(gè)路線中，大模型充當(dāng)大頭兵的角色，干的都是小活臟活累活。
上面兩條線路的主要區(qū)別就是MCP模式和工作流誰占主導(dǎo)的問題。
Dify 類工作流，是一種人為設(shè)定的???思維鏈???和行動(dòng)鏈，什么時(shí)候思考，什么時(shí)候用什么工具都由人設(shè)定好，基于人的專業(yè)能力而定。MCP模式是把思維和行動(dòng)的權(quán)利讓渡給大模型，讓大模型通過??? ReAct ???這種范式，去決定下一步思考干什么，該用什么工具，調(diào)用哪些接口，獲取什么數(shù)據(jù)。
但是 MCP模式想做好，想要每次得到穩(wěn)定可靠的輸出結(jié)果，也必須要用結(jié)構(gòu)化提示詞或者工作流再去指導(dǎo)大模型使用MCP,基于 MCP的提示詞設(shè)計(jì)和工作流設(shè)計(jì)也將會(huì)一種更高階的編程語言。
到最后，就是你中有我，我中有你。Dify工作流可以將MCP Server作為工作流中的某個(gè)關(guān)鍵節(jié)點(diǎn)；同樣，Dify工作流可以發(fā)布為Mcp Sever，由大模型選擇和使用。
MCP Server與Dify工作流分別從協(xié)議層和應(yīng)用層重構(gòu)了智能體開發(fā)范式：前者如同"智能體的USB HUB"，解決工具接入標(biāo)準(zhǔn)化問題；后者則是"智能體的流程圖繪制板"，解決任務(wù)執(zhí)行結(jié)構(gòu)化問題。二者的協(xié)同使用，既能通過MCP突破工具生態(tài)限制，又能借助Dify保證核心業(yè)務(wù)流程可控性，共同推動(dòng)AI應(yīng)用從"功能堆砌"向"智能協(xié)同"演進(jìn)。
簡而言之，MCP解決工具碎片化問題，Dify解決流程碎片化問題，共同構(gòu)建完整Agent開發(fā)生態(tài)，兩者是能力互補(bǔ)的關(guān)系。
不過作為大模型和MCP連接的平臺(tái)，Cursor、Claude Desktop、Vscode + Cline以及各種收費(fèi)或者免費(fèi)的大模型Chat客戶端，最近紛紛上線了功能。其實(shí)一般傳統(tǒng)行業(yè)的軟件都需要編程，所以 Cursor +MCP 更有實(shí)用價(jià)值，Chat 客戶端+MCP 目前更適合個(gè)性化的小場景需求。
但是像什么操作文件列表 控制瀏覽器、讀取數(shù)據(jù)庫的單個(gè)MCP server ，感覺都很尋常的技術(shù)，不過是把之前的腳本 API 或者rpa技術(shù) 用MCP 協(xié)議封裝成了MCP server,原子化功能的mcp意義不大，怎么把這些能力縫合成一個(gè)能解決實(shí)際問題的業(yè)務(wù)項(xiàng)目才有意義。
三月初爆火的Manus把這些能力縫合了，但是做的還是那些采集數(shù)據(jù)寫個(gè)沒啥用的數(shù)據(jù)報(bào)告之類的場景。
核心還是業(yè)務(wù)需求 還是我們?nèi)说哪芰?。我們到底想用來干什么，解決什么問題。這個(gè)東西純靠技術(shù)，靠程序員是解決不了這個(gè)問題的。
所以智能體場景一定是垂直的，而不是通用的，真正能思考出落地業(yè)務(wù)場景的人，這個(gè)人可能就是項(xiàng)目經(jīng)理 一線銷售 公司老板 行業(yè)專家，但是這部分人精力有限，不能深入了解技術(shù)細(xì)節(jié)，可能又想不出很具體的基于 MCP 的場景需求來。主要問題是技術(shù)方案和業(yè)務(wù)適配兩個(gè)部分從業(yè)者很難同時(shí)具備這兩樣能力。
發(fā)現(xiàn)真的對用戶有價(jià)值的工作流，將會(huì)是這個(gè)行業(yè)的競爭力和壁壘，技術(shù)反而平權(quán)沒有壁壘。
以上就是我最近一段時(shí)間的思考，分享出來，希望得到大家的積極評(píng)論和反饋。
本文轉(zhuǎn)載自公眾號(hào)九歌AI大模型 作者：九歌AI
