Claude MCP: 不是一个好方案也不是一个好消息

开发调优
1

先说结论, 我认为MCP并不是一个好的解决方案

MCP直觉上和Function Tool 以及 ReAct, ToolUse 几乎是一致的:

现在的解决方案是什么?

抽象出了三种主要的交互类型:

  1. Prompt: 主要是作为Prompt模板
  2. Tool: 可以被调用的函数
  3. Resource: 各种可以被Parse为文本的资源

其中Prompt主要是为了Claude Desktop准备

Resource和Tool没有本质的区别, 其实最终都是一个功能函数的调用.

在之前已经比较成熟的方案是什么? FC以及ReAct.

那么Claude有什么区别呢? 现在还没有进行抓包, 还不知道claude对于上下文的处理是不是还像ReAct那么丑陋, 需要巨大的上下文, 以及连续的请求.

所以我认为本质上MCP是提供了一个Proxy/SideCar 的 IDL, 将函数定义和函数调用分开.

LLM Client只和Proxy进行交互, Proxy根据LLM Client所需要的调用, 进行Remote Call

END

MCP本质上只是一个工程方案, 而且从现在的代码来看, 甚至称不上是一个优雅的方案

就现阶段而言, 我不认为MCP能够称之为是一个: protocol, 本质上就是Proxy + Function Call

Claude最近一直再发力, 对于已经很久没有动静的产业届来说, 这不是一个好消息

7 个赞
2

对于一个闭源的客户端，比如 Claude desktop，你如何添加 function call 供其使用？MCP 就是答案。

3

认得是claude3.5

4

感觉就是为了解耦统一接口，他把自己或者其他大模型定义为host,应用程序内置client,这样方便更多的人来开发server或者叫给它赋能.虽谈不上优雅，这不是刚开始么不是，未来说不好变种成啥。该吐槽的是我免费用户体验不太行，客户端还卡死过

1 个赞