超碰人人人人人,色婷婷综合久久久久中文一区二区,国产-第1页-浮力影院,欧美老妇另类久久久久久

?聊一下MCP，希望能讓各位清醒一點(diǎn)吧。

先說觀點(diǎn)：MCP不錯(cuò)，但它僅僅是個(gè)協(xié)議而已，很多科普文章中，提到的更多都是愿景，而不是落地的場景。

本文不再重新陳述MCP的基本概念，而是旨在能讓大家了解的是MCP 有什么用？、怎么用？、要不要用？

我準(zhǔn)備了一份MCP實(shí)現(xiàn)的核心代碼，只保留必要的內(nèi)容，五分鐘就能看明白MCP怎么回事。

先上代碼，讓我們看看實(shí)現(xiàn)MCP最核心的部分我們都干了些什么東西。順便讓大家看看MCP到底和Function call是個(gè)什么關(guān)系。

MCP代碼核心邏輯

我們在本地運(yùn)行的MCP，所以使用的是Stdio模式的客戶端和服務(wù)端。也就是：StdioServerTransport和StdioClientTransport

先看打滿日志的demo運(yùn)行起來起來后，我們獲得的信息：

我們的服務(wù)端寫了兩個(gè)簡單的工具，加法和減法。

服務(wù)端啟動成功之后，客戶端成功的從服務(wù)端獲取到了這兩個(gè)工具。

我們發(fā)起了一個(gè)問題：計(jì)算1+1

接下來做的事情就是MCP的客戶端核心三步邏輯：

1. 客戶端調(diào)用AI的function call能力，由AI決定是否使用工具，使用哪個(gè)工具。

2. 客戶端把確定要使用的工具和參數(shù)發(fā)送回服務(wù)端，由服務(wù)端實(shí)現(xiàn)API調(diào)用并返回結(jié)果。

3. 客戶端根據(jù)結(jié)果，再次調(diào)用AI，由AI進(jìn)行回答。

我們一邊看代碼一邊說里面的問題：

第一步調(diào)用AI，決定使用工具

客戶端代碼：

  const response = await this.openai.chat.completions.create({
    model: model,
    messages,
    tools: this.tools, // ! 重點(diǎn)看這里，this.tools是服務(wù)端返回的工具列表
  });

看到了么？這里用的還是Function call! 謠言一：MCP和Function call沒關(guān)系，MCP就可以讓大家調(diào)用工具，終結(jié)了。MCP就是用的function call的能力來實(shí)現(xiàn)的工具調(diào)用。當(dāng)然我們也可以不用Function call，我們就直接用提示詞判斷，也是可以的。

這里要說的是：MCP就是個(gè)協(xié)議。并沒有給大模型帶來任何新的能力，也沒有某些人說的MCP提升了Function call的能力，以后不用Function call了，用MCP就夠了這種話，千萬不要被誤導(dǎo)。

MCP并沒有讓大模型的工具調(diào)用能力提升

在真實(shí)的生產(chǎn)環(huán)境中，目前Function call主要的問題有：

• 工具調(diào)用準(zhǔn)確性不夠。 真正的生成環(huán)境可能不是三個(gè)五個(gè)工具，而是三十個(gè)五十個(gè)。工具之間的界限不夠清晰的話，就會存在模型判斷不準(zhǔn)確的情況。

• 參數(shù)提取準(zhǔn)確性不夠。 特別是當(dāng)一個(gè)工具必填加選填的參數(shù)達(dá)到十個(gè)以上的時(shí)候，面對復(fù)雜問題，參數(shù)的提取準(zhǔn)確率會下降。

• 多意圖的識別。
  用戶的一個(gè)問題涉及到多個(gè)工具時(shí)，目前沒有能夠穩(wěn)定提取的模型。

第二步把工具和參數(shù)發(fā)回服務(wù)端，由服務(wù)端調(diào)用API

客戶端代碼：

const result = await this.mcp.callTool({
  name: toolName,
  arguments: toolArgs,
});

服務(wù)端的代碼：

server.tool(
  "加法",
  "計(jì)算數(shù)字相加",
  {
    "a": z.number().describe("加法的第一個(gè)數(shù)字"),
    "b": z.number().describe("加法的第二個(gè)數(shù)字"),
  },
  async ({ a, b, c }) => {
    console.error(`服務(wù)端: 收到加法API，計(jì)算${a}和$兩個(gè)數(shù)的和。模型API發(fā)送`) 
    // 這里模擬API的發(fā)送和使用
    let data = a + b
    return {
      content: [
        {
          type: "text",
          text: a + '+' + b + '的結(jié)果是：' + data,
        },
      ],
    };
  },
);

發(fā)現(xiàn)問題了么？ API是要有MCP服務(wù)器提供者調(diào)用的。要花錢的朋友！

每一臺MCP服務(wù)器背后都是要成本的，收費(fèi)產(chǎn)品進(jìn)行MCP服務(wù)器的支持還說的過去，不收費(fèi)的產(chǎn)品全靠愛發(fā)電。更不要說，誰敢在生成環(huán)境接一個(gè)不收費(fèi)的私人的小服務(wù)器？

百度地圖核心API全面兼容MCP了，百度地圖是收費(fèi)的，進(jìn)行多場景的支持是很正常的行為。

來看看百煉吧，阿里的百煉目前推出了MCP的功能，支持在百煉上部署MCP server。

也是要花錢的朋友~，三方API調(diào)用費(fèi)用另算。

阿里的魔塔社區(qū)提供了大量的MCP，可以看到有一些大廠的服務(wù)在，當(dāng)然有收費(fèi)的有免費(fèi)的，各位可以嘗試

第三步客戶端根據(jù)結(jié)果，再次調(diào)用AI，由AI進(jìn)行回答。

客戶端代碼：

messages.push({
  role: "user",
  content: result.content,
});
const aiResponse = await this.openai.chat.completions.create({
  model: model,
  messages: messages,
});

從服務(wù)端返回的結(jié)果，添加到messages中，配合提示詞由大模型進(jìn)行回復(fù)即可。

這一步屬于正常的流程，沒什么好說的。

那么問題是：我們使用MCP來實(shí)現(xiàn)，和我們自己實(shí)現(xiàn)這套流程有什么區(qū)別么？我們?yōu)槭裁匆肕CP呢？

當(dāng)初群里朋友第一次提到MCP的時(shí)候，我去看了一眼文檔，給了這樣的結(jié)論：

大廠為了搶生態(tài)做的事情，給落地的流程中定義了一些概念，多了腦力負(fù)擔(dān)，流程和自己實(shí)現(xiàn)沒區(qū)別。

對于工具的使用，自己實(shí)現(xiàn)和用MCP實(shí)現(xiàn)有什么區(qū)別么？

自己實(shí)現(xiàn)的流程和邏輯是這樣的：

1. 我們的提示詞工程師寫好每個(gè)工具的提示詞
2. 我們的后端工程師寫好模型的調(diào)用，使用的是前面寫好的提示詞
3. 提供接口給前端，等待前端調(diào)用
4. 前端調(diào)用傳入query，后端通過AI獲取了工具
5. 通過工具配置調(diào)用API，拿到數(shù)據(jù)交給AI，流式返回用戶。

MCP的邏輯是這樣的：

1. 我們的提示詞工程師寫好每個(gè)工具的提示詞
2. 我們后端工程師分別寫好MCP服務(wù)端、MCP客戶端
3. MCP客戶端提供個(gè)接口給前端，等待前端調(diào)用
4. 前端調(diào)用傳入query，MCP客戶端調(diào)用AI，獲取了工具。
5. 客戶端把確定要使用的工具和參數(shù)發(fā)送會服務(wù)端，由服務(wù)端實(shí)現(xiàn)API調(diào)用并返回結(jié)果。
6. 客戶端根據(jù)結(jié)果，再次調(diào)用AI，由AI進(jìn)行回答，流式返回用戶。

看吧，本質(zhì)上是沒有區(qū)別的。

什么？你說MCP服務(wù)端，如果日后需要與其他企業(yè)進(jìn)行合作，可以方便的讓對方的MCP客戶端調(diào)用？ 我們的客戶端也可以很方便的接入別人的MCP服務(wù)端。

不好意思，不用MCP也可以，因?yàn)镕unction call的參數(shù)格式已經(jīng)確定了，這里原本存在差異性就極小。而且MCP也并沒有解決這個(gè)差異性。還是需要客戶端進(jìn)行修改的。

MCP真正的意義

現(xiàn)在還是諸神混戰(zhàn)時(shí)期，整個(gè)AI產(chǎn)品的上下游所有的點(diǎn)，都具有極高的不確定性。

MCP給出了一個(gè)技術(shù)標(biāo)準(zhǔn)化的協(xié)議，是大家共建AI的愿景中的一環(huán)，潛力是有的。

但是Anthropic真的只是在乎這個(gè)協(xié)議么？前面的內(nèi)容我們也看到了，MCP和我們自己實(shí)現(xiàn)的流程幾乎是一樣的。但是為什么還要提出MCP呢？

為了生態(tài)控制權(quán)和行業(yè)話語權(quán)。

MCP它表面上是一個(gè)開放的協(xié)議，旨在解決AI模型與外部工具集成的碎片化問題，但其實(shí)他就是Anthropic對未來AI生態(tài)主導(dǎo)權(quán)的競爭。

未來MCP如果真的作為一個(gè)標(biāo)準(zhǔn)的協(xié)議成為大家的共識，圍繞這個(gè)協(xié)議，甚至每家模型的工具調(diào)用格式都將被統(tǒng)一，此時(shí)Anthropic在委員會里的位置呢？不言而喻啊。

結(jié)語

最后把我的策略分享給大家吧：

打算在圈子里玩的部分，就和大家用一樣的，不在圈子里玩的，其實(shí)自己團(tuán)隊(duì)實(shí)現(xiàn)也是OK的。

我這邊更多的是自己團(tuán)隊(duì)實(shí)現(xiàn)的，而且在這個(gè)實(shí)現(xiàn)過程中大家對模型應(yīng)用、AI產(chǎn)品的理解不斷地在提升。

希望各位讀者也多進(jìn)行嘗試，這樣未來面對新出的各路牛鬼蛇神時(shí)大家才能有更多的判斷力。

共勉吧！

轉(zhuǎn)自https://juejin.cn/post/7492271537010671635