## MCP & Function Calling

### 什么是Function Calling？

Function Calling是一种让大语言模型(LLM)能够与外部工具和系统交互的机制。它允许模型在需要时识别并调用适当的工具来获取信息或执行作。




#### **工作原理**
- **工具定义**： 首先，开发者需要定义模型可以使用的工具列表，每个工具包括：
	- 名称（name）
	- 描述（description）
	- 参数信息（parameters），通常使用JSON Schema格式
- **模型决策**： 当用户提出问题时，模型会：
	- 分析问题是否需要外部工具
	- 如果需要，决定调用哪个工具
	- 生成符合要求的参数
- **结构化输出**： 模型会输出一个结构化的响应，通常是类似这样的JSON格式：
```json
{
 "name": "get_weather",
 "arguments": {
   "location": "北京"
 }
}
```

- **后端执行**： 应用程序的后端会执行如下操作。
	- 解析模型的输出
	- 根据工具名称找到对应的函数
	- 使用提供的参数执行该函数
	- 获取执行结果
- **结果反馈**： 执行结果会作为新的上下文提供给模型，模型基于这些信息生成最终的自然语言响应。

### 为什么 Function Calling 不够用，要有 MCP？

#### Function Calling 有哪些问题？
1. 格式依赖和脆弱性问题
	- 模型可能输出不规范的JSON
	- 可能缺少必要字段或参数
	- 格式错误导致整个工具调用失败
	- 需要复杂的Prompt工程来约束输出格式
2. 缺乏标准化
	- 工具难以在不同平台间移植
	- 需要为每个平台重新实现工具集成
	- 增加了开发和维护成本
3. 工具发现机制不足
	- 工具列表通常在会话开始时静态定义
	- 难以动态添加或移除工具
	- 工具元数据描述能力有限
4. 错误处理不统一
	- 每个实现都有自己的一套错误处理机制
	- 难以建立统一的错误恢复策略
	- 错误信息传递不规范

#### MCP 如何解决？
##### 1. 标准化的通信协议
MCP基于JSON-RPC 2.0标准：
```json
// 标准的MCP工具调用请求
{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "北京"
    }
  }
}

// 标准的响应格式
{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "temperature": "25°C",
    "condition": "晴天"
  }
}

// 标准的错误格式
{
  "jsonrpc": "2.0",
  "id": "1",
  "error": {
    "code": -32601,
    "message": "Method not found"
  }
}
```

##### 2. 动态工具发现
```json
// 工具发现请求
{
  "jsonrpc": "2.0",
  "id": "2",
  "method": "tools/list",
  "params": {}
}

// 工具列表响应
{
  "jsonrpc": "2.0",
  "id": "2",
  "result": [
    {
      "name": "get_weather",
      "description": "获取指定地点的天气信息",
      "inputSchema": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "地点名称"
          }
        }
      }
    }
  ]
}
```

##### 3. 标准化的初始化和能力协商
```json
// 初始化请求
{
  "jsonrpc": "2.0",
  "id": "init-1",
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": {},
      "resources": {}
    },
    "clientInfo": {
      "name": "MyAIApp",
      "version": "1.0.0"
    }
  }
}
```

#### 场景对比

- Function Calling场景
	1. 开发者需要为每个LLM平台编写不同的工具集成代码
	2. 工具调用容易因模型输出格式问题而失败
	3. 工具管理复杂，难以动态扩展

- MCP场景
	1. 一次编写，到处使用（Write Once, Run Everywhere）
	2. 标准化协议确保工具调用的可靠性
	3. 动态工具发现和注册机制便于扩展

MCP & Function Calling

- 协程
	- 将线程上执行的任务的**过程**，把这个事件从线程执行中分离出来，并加以保存为**自己的寄存器上下文和栈**。换句话说，复制了线程的内容，但是**只有持有内容而不是执行者**。
	- 基于这种方式，可以**解耦内核态与用户态之间的切换**。因为在程序中一直都是使用一条线程，只不过运行在线程上的任务可以被程序（也就是用户态）控制，随时切换。
	- 如此一来，既保障对于线程这种敏感的资源可以被内核态管理控制**保证安全**，又可以实现切换任务避免用户态和内核态切换的**性能损耗**。
	- **关于轻量级线程**：个人认为将协程描述为轻量级的线程是有些不准确的。因为本质上，协程并没有执行任务的功能，只是“持有”这个任务。不同于线程池中提交的任务，协程是这个“任务”的超集，是“任务执行的整个事件本身”。
	- **被挂起的协程**：协程挂起时，不占用线程，但 I/O 请求已交给操作系统处理；当数据就绪，Go 运行时通过 `netpoller` 监听事件，自动回调会自动唤醒协程，让它继续执行。

协程的个人理解

基于电商秒杀项目中，关于使用 Kafka 替代 Redis Stream 实现消息队列的技术选型，个人认为主要在于可靠性上进行选择。




- 可靠性
	- **持久化 & 故障恢复**：Redis Stream 是基于 Redis 自身实现的持久化，具有内存的持久化特征，主要保证的是服务在宕机后能够快速恢复。AOF 虽然能记录每一条指令，但是持久化到磁盘中是根据**刷盘策略**来决定的，根据`appendfsync`策略选择，决定了**数据丢失的多少**。虽然可以做到零丢失，但是 Redis 作为一个高性能的缓存中间件服务，是不可能牺牲过多的性能来换取绝对的持久化可靠性保证。所以，在消息持久化的可靠性上 Redis 是天然残疾的。
	- **投递、消费可靠**：Redis Stream 是只提供了消费 ACK 机制，并没有提供投递 ACK 机制，可能会出现投递消息丢失的风险。

除了可靠性外，可用性和性能也是几个可考虑的点。
- 可用性
	- Kafka 是天然的分布式架构，Topic、Broker、Partition 的架构能天然而成进行分布式拓展。而 Redis 以单机为主，高可用依赖 Redis Sentinel 或 Cluster。
- 性能
	- 性能上，Kafka 基于批量写 + 零拷贝（sendfile）优化能达到百万吞吐量。而 Redis 基于单线程模型和内存压力吞吐量单机为几万 QPS

电商秒杀项目中 Kafka & Redis Stream 的MQ选型

可是偏偏幸运又再一次垂青了你，在飘零半生之后向你又一次地抛出了橄榄枝。只是，如今的你却不在似年少般的意气风发，只留下了岁月打磨过的沧桑。一路上又是如同故事一般，过五关斩六将，艰难险阻但是却一个接一个地克服，来到最终的舞台时。却又是宿命般，再一次倒在了2：3这个已经PTSD的比分前。

为什么是Ame？为什么又一次是决赛2：3？为什么偏偏是CNDOTA无缘决赛的四年后？为什么是在 CNDOTA 黄昏的一年里？为什么是在Ame最颠沛流离的一年里？

如果这是 TI8 ，又或是 TI10 。我不会难过，也不会悲伤，更不会流泪。只是，偏偏是在这落花时节，在这飘零半生之后，在CNDOTA的黄昏时刻，在CNDOTA连续四年无缘决赛之后，在艰难险阻后，又一次如梦初醒地回到了这个舞台，却戏谑般地2：3倒在了最后一步上。

只是不再似少年时候，在这 CNDOTA 的黄昏时刻，在 Ame 职业生涯的终点站，再也很难有机会再一次见证 CNDOTA 和 Ame 捧起冠军盾了。想起社区常言的一句话：“究竟是怎样的结局，才能配得上这一路上的颠沛流离”。

这样的结局太残忍。