文：王智遠(yuǎn) | ID:Z201440

昨天（4月19日），字節(jié)推出通用AI Agent平臺扣子空間（Coze Space），目的讓用戶和AI Agent高效協(xié)作，完成各種復(fù)雜的任務(wù)。

核心能力有三個：任務(wù)自動化、專家Agent生態(tài)、以及打通MCP擴(kuò)展集成；據(jù)說，未來還將開放開發(fā)者平臺，支持開發(fā)者將應(yīng)用發(fā)布至扣子空間。

01

拿到邀請碼，趕緊試了試。新建兩個任務(wù)，一個整理內(nèi)容，另一個生成一個研究報告。

整理內(nèi)容上，選擇了探索模式。

上傳4個文件，全是Word文檔，跟它說：幫我把這幾個文件里的內(nèi)容整理一下。它就開始干活了，這個任務(wù)它分成了三個步驟。

第一步，它跟我說，把這幾個文件的內(nèi)容混在一起整，輸出一個新文件；第二步，它說已經(jīng)把文件格式轉(zhuǎn)換好了，把Excel轉(zhuǎn)成CSV，Word轉(zhuǎn)成Markdown，再把Markdown轉(zhuǎn)成TXT。

第三步，它說已經(jīng)提取關(guān)鍵信息，總結(jié)出文件核心觀點(diǎn)，現(xiàn)在要梳理下邏輯結(jié)構(gòu)，輸出成一個Markdown格式的文檔就可以了。

整個過程大概花了不到30秒。

說到優(yōu)點(diǎn)，整理內(nèi)容結(jié)構(gòu)清晰，能清楚看到報告基本框架。比如：概述、特點(diǎn)、市場定位、目標(biāo)、未來規(guī)劃都非常清晰。

缺點(diǎn)也很明顯，內(nèi)容不夠詳細(xì)、大而全，重要東西根本沒提到。要是我想了解更多，再跟它發(fā)信息，它又重新開始一輪探索，這有點(diǎn)尷尬了。

相比之下，Kimi、Grok或者Qwen整理出來的內(nèi)容更完整，還能接著提問、優(yōu)化，效率好像更高。這是我對探索模式的感受。

再來說說規(guī)劃模式。

我跟他說：現(xiàn)在要寫一篇關(guān)于扣子空間的內(nèi)容。然后請你幫我規(guī)劃一下，告訴我該從哪些方面入手。它第一步挺讓我滿意，把需求提煉出來，整理成提示詞。

并說：第一步要先收集信息，第二步要規(guī)劃文章邏輯，第三步梳理邏輯，最后一步結(jié)構(gòu)化輸出，這些提示詞我可以改，也可以直接點(diǎn)開始。

執(zhí)行步驟也挺清楚，按照上面的提示詞一步步來；不過整個過程時間比較長，因?yàn)橐?guī)劃步驟多，大概花了13分鐘。

13分鐘里，我能清楚看到他每一步都在深度思考。我還能看到他是怎么思考的。比如：它會去瀏覽各種網(wǎng)站，像人人都是產(chǎn)品經(jīng)理、鈦媒體、騰訊新聞等。

不過，搜索范圍和深度比智譜GLM、Kimi的探索版、Grok3要差一些。我提一個問題，他匆匆調(diào)取三五個信息源，就結(jié)束總結(jié)了。

每一輪結(jié)束后，它會生成一個Markdown格式的文檔存起來。過程中可以點(diǎn)擊右側(cè)直接查看，它還提供代碼模式，直接下載，挺透明。

最終生成完，它會形成一個Markdown文檔，還包含一個.gsx文件。前者我可以直接下載，后者能在網(wǎng)站里打開。

說說它的優(yōu)勢，一，內(nèi)容很全面，文檔大概有8000字，上下文記憶模型還不錯；二，它能自主規(guī)劃并生成網(wǎng)站，可視化能力也挺強(qiáng)。

劣勢也很明顯，內(nèi)容深度不夠，抓取信息、生成文本都比較表面，純理論、廢話多，沒加入具體的研究案例。

還有一點(diǎn)，它目前支持多任務(wù)同時進(jìn)行。新建一個任務(wù)，返回主頁面再建一個，它依然可以同步運(yùn)行。這就是我對規(guī)劃模式的整體感受。

一句話總結(jié)即：能跑通流程，但還有很大的提升空間。

02

體驗(yàn)完之后，我感覺MCP平臺是不是卷錯方向了。

MCP（Model Context Protocol）平臺的核心，是用一個標(biāo)準(zhǔn)化協(xié)議，重新定義AI應(yīng)用和外部系統(tǒng)怎么合作。

以前，各種任務(wù)系統(tǒng)之間對接很麻煩。

釘釘審批流程要單獨(dú)對接CRM、ERP系統(tǒng)，開發(fā)成本高，更新也很慢；百度千帆AppBuilder以前接入企業(yè)數(shù)據(jù)庫，得為MySQL、MongoDB分別開發(fā)接口。用了MCP之后，直接調(diào)用一個預(yù)置的“MCP SQL Server”，就能搞定不同數(shù)據(jù)庫的對接。

字節(jié)扣子空間接入高德地圖服務(wù)，用了MCP協(xié)議，本質(zhì)也是為了縮短開發(fā)和工具調(diào)用的時間。

再看看開發(fā)和維護(hù)成本方面，MCP是組件資產(chǎn)化和生態(tài)復(fù)用，把任務(wù)系統(tǒng)開發(fā)，從「手工作坊」升級成「工業(yè)化生產(chǎn)」的過程。

比如，支付功能集成，傳統(tǒng)方式要5個人天，用了MCP可能只要0.5個人天；跨平臺數(shù)據(jù)同步，傳統(tǒng)方式要8個人天，用了MCP只要1個人天。

開放協(xié)作生態(tài)這塊，MCP屬于「人在環(huán)路」機(jī)制。

什么意思呢？

任務(wù)執(zhí)行到關(guān)鍵節(jié)點(diǎn)時，系統(tǒng)會自動觸發(fā)人工確認(rèn)；比如合同審核，最后你要簽字，這樣一來，既利用了自動化的效率，又能在關(guān)鍵時刻控制風(fēng)險，平衡兩者。

這種機(jī)制讓MCP通過協(xié)議中立性和工具可插拔性，打破了傳統(tǒng)生態(tài)的割據(jù)，讓任務(wù)系統(tǒng)從封閉走向開放。

所以，MCP平臺的本質(zhì)是什么？

表面看，它就是一個任務(wù)系統(tǒng)。但深層來看，它是通過協(xié)議層的抽象，把任務(wù)執(zhí)行從“工具驅(qū)動”升級為「意圖驅(qū)動」。

什么是意圖驅(qū)動？

我要查詢訂單狀態(tài)、獲取天氣信息、處理投訴等，MCP通過智能路由，識別出我的意圖，然后在任務(wù)執(zhí)行過程中，根據(jù)實(shí)際情況，進(jìn)行調(diào)整。

如果某個服務(wù)不可用，系統(tǒng)可以自動切換到備用服務(wù)。鑒于此，這項革新的核心價值可以歸結(jié)為三點(diǎn)：

一，降低依賴，系統(tǒng)之間不再緊緊綁在一起，改動起來更輕松；二，靈活應(yīng)對：流程不是固定的，能隨時根據(jù)需求和資源變化調(diào)整；三，開放共享，打破封閉，讓更多工具和資源可以互通復(fù)用。

說白了，這種革新，是讓任務(wù)系統(tǒng)，從「死板的執(zhí)行工具」，變成「靈活的智能連接器」，能更好地對接AI能力和實(shí)際需求。

03

再看看現(xiàn)在的MCP平臺，有沒有“重復(fù)造輪子”的問題？

目前，傳統(tǒng)網(wǎng)絡(luò)接口（比如RESTful API和OpenAPI）已經(jīng)非常成熟，它們像不同軟件之間的“通信橋梁”，用起來很方便。

現(xiàn)在，MCP要求把現(xiàn)有的接口重新封裝成一個專用的“服務(wù)”。這不僅增加了開發(fā)成本，還未能解決核心的交互問題。

舉個例子：

直接調(diào)用接口生成數(shù)據(jù)結(jié)構(gòu)（相當(dāng)于把數(shù)據(jù)打包成標(biāo)準(zhǔn)格式）其實(shí)更簡單，而MCP的協(xié)議層抽象，可能顯得有些“過度設(shè)計”。

再看看函數(shù)調(diào)用機(jī)制。MCP實(shí)現(xiàn)了不同模型之間的統(tǒng)一調(diào)用，但在一些高頻輕量的任務(wù)中，大家還是更傾向于使用原廠接口。在簡單的查詢場景里，函數(shù)調(diào)用依然是最高效的。

另外，對開發(fā)者來說，學(xué)習(xí)MCP的協(xié)議語法、工具鏈和調(diào)試規(guī)范（比如：服務(wù)器發(fā)送事件SSE的傳輸配置）增加了不少復(fù)雜度；而傳統(tǒng)的接口調(diào)用，只要掌握基本的網(wǎng)絡(luò)通信技能就夠了。

更重要的是，在多模態(tài)數(shù)據(jù)處理（比如：同時處理文字、圖片、聲音等復(fù)雜數(shù)據(jù)）這種場景下，MCP協(xié)議的擴(kuò)展性目前還得打個問號；可以說，協(xié)議的復(fù)雜度可能已經(jīng)超出了實(shí)際需求。

再說說，標(biāo)準(zhǔn)化與碎片化的悖論。

現(xiàn)在很多大廠都在推出自己的MCP市場，但這些服務(wù)互不兼容。阿里云只支持通義千問模型，這就導(dǎo)致了一個問題：可能會形成類似Android的碎片化生態(tài)，和協(xié)議初衷背道而馳。

開源社區(qū)的工具（比如魔塔社區(qū)）和企業(yè)級方案之間也有技術(shù)斷層，中小開發(fā)者不得不面對「適配多套協(xié)議」的困境。

另外，MCP的協(xié)議擴(kuò)展性也存在局限。目前它的權(quán)限控制只能到會話級別，往深層次的就不支持了，這對于金融、醫(yī)療行業(yè)有很大制約性。

值得一提的是安全性。MCP的「人在環(huán)路」機(jī)制依賴人工干預(yù)，但現(xiàn)在很多MCP平臺卻希望實(shí)現(xiàn)自動化流程，這其實(shí)和技術(shù)創(chuàng)新的方向有點(diǎn)背道而馳。

因?yàn)樵诙郃gent協(xié)作時，規(guī)劃有效性不足，會導(dǎo)致級聯(lián)故障，一個小問題引發(fā)一連串的大麻煩，你還修改不了；反之，用戶希望的是：哪個環(huán)節(jié)不滿意，都能參與進(jìn)去。

至于，商業(yè)化問題就更不用說了。

目前MCP市場的應(yīng)用主要集中在生活服務(wù)類工具上（天氣查詢、地圖導(dǎo)航），但在制造業(yè)領(lǐng)域，像OT系統(tǒng)，這樣的接入案例還很少，而且，復(fù)雜工業(yè)協(xié)議里的MCP也沒有被突破。

雖然Serverless部署降低了運(yùn)維負(fù)擔(dān)，但像阿里云這樣的平臺，計費(fèi)模式不夠透明，長期使用下來的成本可能比自建API還高。

所以，我個人認(rèn)為，它的商業(yè)價值，還存在驗(yàn)證性，未來要推動協(xié)議標(biāo)準(zhǔn)化和行業(yè)深度適配。

04

既然這樣，問題來了，什么樣的MCP平臺具備商業(yè)價值？或者說能被中小企業(yè)用起來？

我沒辦法從宏觀角度回答這個問題，但從具體使用場景出發(fā)，可以談?wù)劯惺堋?/p>

假設(shè)要用一個MCP平臺來搭建一個高效工作流，比如做PPT或者搞用戶研究，那我更喜歡一種叫「規(guī)劃模式」的方式。

所謂規(guī)劃模式，即把想法告訴系統(tǒng)，通過不斷交互和補(bǔ)充內(nèi)容，系統(tǒng)能夠記住需求，并逐步幫我規(guī)劃出一個可行性的報告或解決方案。

這種模式是從用戶角度出發(fā)，讓用戶在使用MCP平臺時，感覺像在Notion上完成一項任務(wù)一樣自然；雖然Notion本質(zhì)是個協(xié)作筆記管理工具，但從底層邏輯來看，它和MCP平臺的使用體驗(yàn)其實(shí)是相通的。

比如：

我在Notion里輸入一個問題，用斜杠（/）調(diào)用各種工具，基于問題的內(nèi)容選擇合適的工具，最終完成整個工作流；如果把這種體驗(yàn)搬到MCP平臺上，其實(shí)是輸入問題后，通過調(diào)用不同的AI模型或工具，一步步完成任務(wù)。

從這個角度反推，開發(fā)者要做這幾件重要的事：

一，建立通用任務(wù)框架；開發(fā)者要先設(shè)計一個通用任務(wù)框架，可以適用于多種場景；二，支持靈活交互；在用戶使用過程中，最好能支持暫停或調(diào)整任務(wù)流程，這樣才能為未來的自動化打下基礎(chǔ)。

三，提升任務(wù)的準(zhǔn)確性；只有當(dāng)任務(wù)的每個環(huán)節(jié)都能被精準(zhǔn)規(guī)劃和執(zhí)行時，才有可能實(shí)現(xiàn)真正的自動化。換句話說，中間過程不用人工干預(yù)，則很難更聰明。

從企業(yè)角度看也是一樣。假設(shè)我在釘釘、飛書的生態(tài)中想用一個MCP平臺，我會怎么用呢？

舉個例子：

我是一名銷售，定期拜訪客戶并形成資料，最后匯報給老板。整個過程可能會是這樣的：

首先是信息沉淀。拜訪完客戶后，把信息整理出來，這一步涉及AI輔助撰寫內(nèi)容；撰寫完成后，把內(nèi)容整理成一份可視化報告，這一步要MCP平臺調(diào)用可視化工具，最后，我要把這份報告發(fā)到領(lǐng)導(dǎo)的郵箱里，調(diào)用郵箱工具。

所以，整個流程用MCP串聯(lián)起來是：調(diào)用寫作工具、調(diào)用可視化工具、調(diào)用外部郵箱、定時發(fā)送給工具進(jìn)行分發(fā)。

從這個角度看，MCP平臺的作用是通過協(xié)議或API把這些工具串聯(lián)起來，形成一個完整的工作流。

因此，一個好的MCP平臺應(yīng)該能讓用戶像在Notion上完成任務(wù)一樣輕松，同時為開發(fā)者提供足夠的擴(kuò)展性和靈活性。

再對比字節(jié)的扣子平臺，它扣的緊用戶需求嗎？我覺得第一步做對了，但任務(wù)過程的干預(yù)還不夠靈活，至于生態(tài)的補(bǔ)齊，這要時間。

以上，是我的看法。