AI Day 13: MCP协议与Tool生态 — AI的"USB标准"

日期：2026-04-14 阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15) 标签：MCP Model Context Protocol JSON-RPC Tool Use A2A OAuth 2.1 Agent Ecosystem Anthropic Interoperability

---

学习路径树

AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│   ├── Day 1:  Transformer架构与LLM基础 ✅
│   ├── Day 2:  模型量化与本地部署 ✅
│   ├── Day 3:  训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│   ├── Day 4:  Prompt Engineering与上下文学习(ICL)原理 ✅
│   ├── Day 5:  RAG架构：检索增强生成全链路 ✅
│   ├── Day 6:  向量数据库与Embedding模型 ✅
│   ├── Day 7:  Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│   ├── Day 8:  推理优化：vLLM / TensorRT-LLM / SGLang ✅
│   ├── Day 9:  长上下文技术：RoPE扩展 / Ring Attention ✅
│   ├── Day 10: 多模态模型：Vision-Language架构 ✅
│   ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│   ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│   ├── Day 13: MCP协议与Tool生态 ← 你在这里
│   ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│   └── Day 15: 阶段复习与架构总结
│
├── 第二阶段：工程实践 (Day 16-30)
│   ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│   ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│   └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│   ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│   ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│   └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
    ├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
    ├── Day 47-49: 产品/架构面试模拟
    └── Day 50: 总结与作品集

---

核心概念

一句话定义

MCP (Model Context Protocol) 是Anthropic于2024年11月开源的标准协议，定义AI模型如何发现、连接、调用外部工具和数据源——它是AI生态系统的"USB标准"，将N个AI客户端与M个工具服务的集成复杂度从O(N x M)降至O(N + M)。

金融类比

MCP = 金融行业的 SWIFT 标准

没有SWIFT之前：
  中国银行 → 汇丰: 专用报文格式A
  中国银行 → 花旗: 专用报文格式B
  工商银行 → 汇丰: 又一种格式C
  → 100家银行 × 100家银行 = 10,000种对接方式
  → 每加一家银行，所有现有银行都要新增集成
  → 维护成本指数增长

有了SWIFT之后：
  所有银行都实现SWIFT MT/MX报文标准
  → 100家银行，每家只需实现1次SWIFT接口
  → 新银行加入，接入SWIFT即可与所有银行互通
  → 集成成本从 O(N x M) → O(N + M)

同理，MCP之前的AI工具集成：
  Claude → Slack: 写Slack API集成代码
  Claude → GitHub: 写GitHub API集成代码
  GPT → Slack: 又写一遍Slack集成代码
  GPT → GitHub: 又写一遍GitHub集成代码
  → 每个AI × 每个工具 = 大量重复集成工作

有了MCP之后：
  Slack 实现一个 MCP Server → 所有支持MCP的AI自动接入
  Claude 实现 MCP Client → 自动对接所有MCP Server
  → 新工具只需发布MCP Server，新AI只需支持MCP Client
  → 即插即用，生态网络效应

SWIFT对银行间通信的意义 = MCP对AI工具生态的意义
  → 统一语言、降低摩擦、加速网络效应

为什么2025-2026这个话题最火

2024.11  Anthropic开源MCP协议 → 定义AI工具调用标准
2025.01  Claude Desktop支持MCP → 用户可以安装MCP Server扩展能力
2025.03  MCP规范升级 → 新增Streamable HTTP传输、OAuth 2.1授权
2025.04  OpenAI宣布支持MCP → Agents SDK内置MCP Client → 阵营统一
2025.05  Google发布A2A协议 → Agent间通信标准，与MCP互补
2025.06  MCP Server Registry上线 → 类似npm的工具发现平台
2025.H2  企业级MCP网关产品涌现 → 权限/审计/速率限制
2026.Q1  MCP成为事实标准 → 几乎所有主流AI平台支持

核心趋势:
  2024: Function Calling各家各写 → 碎片化
  2025: MCP统一标准 → 生态整合
  2026: MCP成熟 + A2A互补 → Agent互操作时代

---

知识点1: MCP协议原理

为什么需要MCP

Day 12我们学了Agent框架(ReAct/Tool Use)
  → Agent学会了使用工具
  → 但每个Agent框架定义工具的方式不同：
     LangChain: @tool装饰器 + 自定义Schema
     OpenAI:    function_calling JSON格式
     Anthropic: tool_use XML/JSON格式
     LlamaIndex: FunctionTool类

问题1: 工具提供方的噩梦
  假设你开发了一个"股票分析API"
  → 要支持LangChain用户 → 写LangChain Tool wrapper
  → 要支持OpenAI用户   → 写Function Calling定义
  → 要支持Claude用户   → 写Claude Tool定义
  → 要支持Cursor用户   → 又一种集成方式
  → 每来一个新平台，再写一遍
  → 这就是 O(N x M) 问题

问题2: 工具发现
  Agent怎么知道有哪些工具可用？
  → 传统方式: 开发者硬编码工具列表
  → 没有动态发现机制

问题3: 安全与权限
  Agent调用外部工具的权限管理？
  → 传统方式: 各自实现，没有统一标准
  → 一个Agent拿到数据库写权限 → 潜在灾难

MCP的答案:
  定义一个开放标准协议
  → 工具方只需实现一次MCP Server
  → AI方只需实现一次MCP Client
  → 动态发现、标准化安全模型、统一通信

JSON-RPC 2.0基础

MCP的通信基础是JSON-RPC 2.0——一种轻量级的远程过程调用协议

请求格式:
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_eth_price",
    "arguments": { "currency": "USD" }
  }
}

响应格式:
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "ETH price: $3,456.78"
      }
    ]
  }
}

为什么选JSON-RPC而非REST/gRPC/GraphQL?
  REST:    太重，URL路由+HTTP方法语义与工具调用不匹配
  gRPC:    需要Protobuf编译，工具提供方门槛高
  GraphQL: 查询语法复杂，AI模型生成GraphQL容易出错
  JSON-RPC: 极简(method + params) → LLM容易理解和生成
            → 无状态 → 可在任何传输层上运行(stdio/HTTP/WebSocket)

金融类比:
  JSON-RPC ≈ SWIFT MT报文 → 结构化但简洁
  REST     ≈ 自由格式邮件 → 灵活但不标准
  gRPC     ≈ SWIFT Alliance Lite → 性能好但接入门槛高

Client-Server架构

┌──────────────────────────────────────────────────────────────┐
│                        MCP 架构全景                           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌─────────────┐     ┌──────────────┐     ┌──────────────┐  │
│  │  MCP Host    │     │  MCP Host     │     │  MCP Host    │  │
│  │  (Claude     │     │  (Cursor/     │     │  (自研       │  │
│  │   Desktop)   │     │   VS Code)    │     │   Agent)     │  │
│  └──────┬──────┘     └──────┬───────┘     └──────┬──────┘  │
│         │                    │                     │         │
│         ▼                    ▼                     ▼         │
│  ┌─────────────┐     ┌──────────────┐     ┌──────────────┐  │
│  │ MCP Client  │     │ MCP Client   │     │ MCP Client   │  │
│  │ (协议实现)   │     │ (协议实现)    │     │ (协议实现)    │  │
│  └──────┬──────┘     └──────┬───────┘     └──────┬──────┘  │
│         │                    │                     │         │
│         ├────────────────────┼─────────────────────┤         │
│         │            MCP 协议层                     │         │
│         │        (JSON-RPC 2.0)                    │         │
│         ├────────────────────┼─────────────────────┤         │
│         │                    │                     │         │
│         ▼                    ▼                     ▼         │
│  ┌─────────────┐     ┌──────────────┐     ┌──────────────┐  │
│  │ MCP Server  │     │ MCP Server   │     │ MCP Server   │  │
│  │ (Ethereum)  │     │ (PostgreSQL)  │     │ (Slack)      │  │
│  └──────┬──────┘     └──────┬───────┘     └──────┬──────┘  │
│         │                    │                     │         │
│         ▼                    ▼                     ▼         │
│  ┌─────────────┐     ┌──────────────┐     ┌──────────────┐  │
│  │  Ethereum   │     │  Database     │     │  Slack API   │  │
│  │  RPC Node   │     │  Instance     │     │  Service     │  │
│  └─────────────┘     └──────────────┘     └──────────────┘  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

三个角色:
  Host:   AI应用容器（Claude Desktop、Cursor、自研Agent平台）
          → 管理MCP Client生命周期
          → 负责用户交互和模型调用
          → 一个Host可以连接多个MCP Server

  Client: MCP协议实现层
          → 与一个MCP Server维持1:1连接
          → 处理协议握手/能力协商
          → 管理消息路由

  Server: 工具/数据提供方
          → 暴露Tools/Resources/Prompts
          → 可以是本地进程(stdio)或远程服务(HTTP)
          → 连接实际的后端系统

三大原语: Tools / Resources / Prompts

MCP Server暴露三种能力（Primitives），各有明确职责:

┌─────────────────────────────────────────────────────────────┐
│                    MCP 三大原语                               │
├────────────┬────────────────┬────────────────────────────────┤
│   原语      │ 类比           │ 说明                           │
├────────────┼────────────────┼────────────────────────────────┤
│ Tools      │ 银行柜台操作    │ 可执行的动作（转账/查询/交易）   │
│            │ (主动操作)      │ 由Model主动调用                │
│            │                │ 可能有副作用（写入/修改状态）     │
├────────────┼────────────────┼────────────────────────────────┤
│ Resources  │ 银行对账单      │ 可读取的数据/文件               │
│            │ (被动读取)      │ 由Client或User触发读取          │
│            │                │ 只读，无副作用                   │
├────────────┼────────────────┼────────────────────────────────┤
│ Prompts    │ 银行业务模板    │ 预定义的交互模板                │
│            │ (流程模板)      │ 由User选择使用                  │
│            │                │ 标准化常见工作流                  │
└────────────┴────────────────┴────────────────────────────────┘

详细说明:

1. Tools（工具）—— AI的"手"
   → 模型可以主动调用的操作
   → 类似API endpoint
   → 需要人类确认机制（因为有副作用）
   示例:
     - send_transaction: 发送链上交易
     - execute_swap: 执行DEX兑换
     - create_proposal: 创建DAO提案
     - send_slack_message: 发送消息

2. Resources（资源）—— AI的"眼"
   → 通过URI标识的只读数据
   → 类似文件系统或REST GET
   → 模型不直接调用，由Client根据上下文注入
   示例:
     - eth://mainnet/balance/{address}: 读取ETH余额
     - postgres://db/users: 读取用户表
     - file:///path/to/config.json: 读取配置文件
     - resource://aave/tvl: 读取Aave TVL数据

3. Prompts（提示模板）—— AI的"标准操作手册"
   → 预定义的提示模板，可含参数
   → 用户显式选择使用
   → 标准化常见任务的交互方式
   示例:
     - "analyze-token": 代币分析模板（输入合约地址 → 标准化分析流程）
     - "audit-contract": 合约审计模板
     - "write-sql-query": SQL查询编写模板

Sampling能力

Sampling（采样）是MCP中一个独特且强大的反向能力:

常规流程:   Host → Client → Server   (Host调Server的工具)
Sampling:   Server → Client → Host   (Server请求Host的LLM能力)

┌──────────┐  1.请求Sampling  ┌──────────┐  2.转发请求  ┌──────────┐
│MCP Server│ ──────────────► │MCP Client│ ──────────► │ MCP Host │
│          │                 │          │             │ (含LLM)  │
│          │ ◄────────────── │          │ ◄────────── │          │
│          │  4.返回结果      │          │  3.LLM推理  │          │
└──────────┘                 └──────────┘             └──────────┘

为什么需要Sampling?
  场景: MCP Server在处理复杂任务时，需要LLM帮忙做判断
  例如: Ethereum MCP Server收到"分析这个合约是否有漏洞"请求
        → Server拿到合约代码
        → 需要LLM来分析代码（Server自己没有推理能力）
        → 通过Sampling反向请求Host的LLM
        → 得到分析结果后返回给用户

金融类比:
  普通流程: 客户经理(Host)指示后台(Server)执行操作
  Sampling: 后台在执行过程中遇到复杂判断
           → 反过来咨询风控专家(Host的LLM)
           → 得到判断结果后继续执行

安全考虑:
  → Sampling请求经过Host审核 → Host可以拒绝不当请求
  → Host控制哪些Server有Sampling权限
  → Host可以修改/过滤Sampling的prompt（防止注入攻击）

---

知识点2: MCP vs 其他方案

全面对比

┌──────────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│              │    MCP       │ OpenAI       │ LangChain    │ 直接API      │
│              │              │ Function     │ Tools        │ 调用         │
│              │              │ Calling      │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 标准化程度    │ 开放协议      │ 厂商私有      │ 框架标准     │ 无标准        │
│              │ JSON-RPC 2.0 │ OpenAI格式    │ 库内约定     │ 各写各的      │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 可发现性      │ 动态发现      │ 静态注册      │ 手动注册     │ 无            │
│              │ tools/list   │ 写死在请求中  │ 代码中定义    │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 跨平台       │ 一次实现      │ 仅OpenAI     │ 仅LangChain  │ 每家写一遍   │
│              │ 处处可用      │ 生态内        │ 生态内       │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 传输层       │ stdio/       │ HTTP only    │ 进程内调用    │ HTTP         │
│              │ SSE/HTTP     │              │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 安全模型     │ OAuth 2.1    │ API Key      │ 无内建       │ 自行实现      │
│              │ 权限协商      │              │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 生态规模     │ 快速增长      │ 最大         │ 较大         │ N/A          │
│ (2026)       │ 1000+Server  │ 插件生态      │ 工具库       │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 状态管理     │ 有状态连接    │ 无状态请求    │ 框架管理     │ 自行实现      │
│              │ 会话+上下文   │ 每次带全信息  │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ Sampling     │ 支持         │ 不支持       │ 不支持       │ 不支持        │
│ (反向LLM)    │              │              │              │              │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 适用场景     │ 通用标准      │ OpenAI应用   │ Python       │ 快速原型      │
│              │ 企业级部署    │ 快速集成      │ Agent开发    │ 简单集成      │
└──────────────┴──────────────┴──────────────┴──────────────┴──────────────┘

各方案深度分析

1. OpenAI Function Calling
   优势: 简单直观，与GPT模型深度优化
   劣势: 锁定OpenAI生态，每次请求需要发送完整工具定义
         → 100个工具 = 每次请求加几千token → 成本高
   现状: 2025年OpenAI Agents SDK已内置MCP Client支持
         → 说明OpenAI也认可MCP的方向

2. LangChain Tools
   优势: Python生态丰富，社区活跃
   劣势: 仅限Python/JS，与框架深度耦合
         → 换框架 = 重写所有工具
         → 2025年LangChain也加了MCP适配层(langchain-mcp-adapters)
   现状: 从竞争转向兼容

3. 直接API调用
   优势: 灵活，完全控制
   劣势: 每个API × 每个Agent = 巨大维护成本
         → 没有标准化的工具描述 → AI不知道如何调用
         → 没有安全框架 → 权限管理靠开发者自觉

4. MCP
   优势: 开放标准 + 动态发现 + 安全模型 + 跨平台
   劣势: 相对较新，Server质量参差不齐
         → 但2025年已被OpenAI/Google/Microsoft等巨头认可
   现状: 2026年已成为事实标准(de facto standard)

金融类比:
  Function Calling ≈ 银行内部报文格式 → 行内好用，跨行不通
  LangChain Tools  ≈ 某银行联盟的清算协议 → 联盟内好用，联盟外不认
  直接API          ≈ 两家银行私下约定格式 → 灵活但不可扩展
  MCP              ≈ SWIFT/ISO 20022 → 全球标准，虽有学习成本但一劳永逸

---

知识点3: MCP Server开发

TypeScript SDK示例

// 一个完整的DeFi价格查询MCP Server示例
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 创建MCP Server实例
const server = new McpServer({
  name: "defi-price-server",
  version: "1.0.0",
  description: "DeFi token price and market data"
});

// 定义 Tool: 查询代币价格
server.tool(
  "get_token_price",
  "Get the current price of a cryptocurrency token",
  {
    // 参数Schema（使用Zod）
    token: z.string().describe("Token symbol, e.g. ETH, BTC, UNI"),
    currency: z.string().default("USD").describe("Quote currency")
  },
  async ({ token, currency }) => {
    // 实际调用价格API
    const response = await fetch(
      `https://api.coingecko.com/api/v3/simple/price?ids=${token}&vs_currencies=${currency}`
    );
    const data = await response.json();

    return {
      content: [
        {
          type: "text",
          text: `${token.toUpperCase()} price: ${currency} ${data[token]?.[currency] ?? "N/A"}`
        }
      ]
    };
  }
);

// 定义 Tool: 查询协议TVL
server.tool(
  "get_protocol_tvl",
  "Get Total Value Locked (TVL) for a DeFi protocol",
  {
    protocol: z.string().describe("Protocol name, e.g. aave, uniswap, lido")
  },
  async ({ protocol }) => {
    const response = await fetch(
      `https://api.llama.fi/tvl/${protocol}`
    );
    const tvl = await response.json();

    return {
      content: [
        {
          type: "text",
          text: `${protocol} TVL: $${(tvl / 1e9).toFixed(2)}B`
        }
      ]
    };
  }
);

// 定义 Resource: 读取市场概览数据
server.resource(
  "market-overview",
  "defi://market/overview",
  async (uri) => {
    const response = await fetch("https://api.llama.fi/protocols");
    const protocols = await response.json();
    const top10 = protocols.slice(0, 10).map((p: any) =>
      `${p.name}: $${(p.tvl / 1e9).toFixed(2)}B`
    ).join("\n");

    return {
      contents: [
        {
          uri: uri.href,
          mimeType: "text/plain",
          text: `Top 10 DeFi Protocols by TVL:\n${top10}`
        }
      ]
    };
  }
);

// 定义 Prompt: 代币分析模板
server.prompt(
  "analyze-token",
  "Analyze a DeFi token comprehensively",
  {
    token: z.string().describe("Token symbol to analyze")
  },
  ({ token }) => ({
    messages: [
      {
        role: "user",
        content: {
          type: "text",
          text: `Please analyze the token ${token} comprehensively:
1. Current price and market cap
2. Price trend (7d/30d/90d)
3. Key use cases and utility
4. Risk factors
5. Comparison with competitors
Use the available tools to fetch real-time data.`
        }
      }
    ]
  })
);

// 启动Server（stdio传输）
const transport = new StdioServerTransport();
await server.connect(transport);

Python SDK示例

# Python版MCP Server示例
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent, Resource
import httpx

server = Server("defi-price-server")

@server.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="get_token_price",
            description="Get current price of a crypto token",
            inputSchema={
                "type": "object",
                "properties": {
                    "token": {"type": "string", "description": "Token symbol"},
                    "currency": {"type": "string", "default": "usd"}
                },
                "required": ["token"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "get_token_price":
        async with httpx.AsyncClient() as client:
            resp = await client.get(
                f"https://api.coingecko.com/api/v3/simple/price",
                params={"ids": arguments["token"], "vs_currencies": arguments.get("currency", "usd")}
            )
            data = resp.json()
            price = data.get(arguments["token"], {}).get(arguments.get("currency", "usd"), "N/A")
            return [TextContent(type="text", text=f"Price: ${price}")]
    raise ValueError(f"Unknown tool: {name}")

# 启动
async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(read_stream, write_stream)

Transport层详解

MCP支持三种传输层，适用不同场景:

┌──────────────┬─────────────────┬─────────────────┬─────────────────┐
│              │ stdio           │ SSE             │ Streamable HTTP │
│              │ (标准输入输出)   │ (Server-Sent    │ (2025年3月新增) │
│              │                 │  Events)        │                 │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 连接方式     │ 子进程管道       │ HTTP长连接       │ HTTP请求/响应   │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 适用场景     │ 本地Server      │ 远程Server      │ 远程Server      │
│              │ IDE插件         │ 需要Server推送   │ 无状态/有状态   │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 状态         │ 有状态          │ 有状态          │ 可选有状态      │
│              │ (进程生命周期)   │ (SSE连接周期)    │ (Session管理)   │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 部署复杂度    │ 低(启动进程)    │ 中(需HTTP服务)  │ 中(标准HTTP)    │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 典型用途     │ Claude Desktop  │ 云端MCP服务      │ 企业级API       │
│              │ Cursor          │ 需要推送通知     │ Serverless部署  │
├──────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 2026趋势     │ 开发/本地       │ 逐渐被替代      │ 生产首选        │
└──────────────┴─────────────────┴─────────────────┴─────────────────┘

Streamable HTTP（2025年新增）关键设计:
  → 单一HTTP endpoint接收所有请求
  → 响应可以是普通JSON或SSE流
  → 支持无状态(serverless)和有状态(session)两种模式
  → 解决了SSE方案的诸多限制（防火墙/代理/连接管理）

金融类比:
  stdio     ≈ 银行内部系统直连 → 安全快速但仅限内部
  SSE       ≈ 实时行情推送 → 需要持续连接
  HTTP      ≈ 标准银行API → 通用、可扩展、企业级

---

知识点4: 2025-2026 MCP生态

官方维护的MCP Server

Anthropic和社区维护的官方参考实现:

开发工具类:
  ├── filesystem    → 文件读写/搜索/目录操作
  ├── git           → Git仓库操作（log/diff/commit/branch）
  ├── github        → GitHub API（PR/Issue/Repo管理）
  ├── gitlab        → GitLab API
  └── puppeteer     → 浏览器自动化

数据库类:
  ├── postgres      → PostgreSQL查询/Schema探索
  ├── sqlite        → SQLite数据库操作
  └── redis         → Redis缓存操作（社区）

通信类:
  ├── slack         → Slack消息/频道管理
  ├── google-maps   → Google Maps API
  └── fetch         → 通用HTTP请求

搜索类:
  ├── brave-search  → Brave搜索引擎
  └── exa           → Exa AI搜索（语义搜索）

数据分析类:
  ├── memory        → 知识图谱式持久记忆
  └── sequential-thinking → 动态推理链

社区MCP Server爆发（2025-2026）

MCP Server生态在2025年经历了npm式的爆发:

数据库/存储:
  ├── MongoDB MCP      → 文档数据库操作
  ├── Pinecone MCP     → 向量数据库检索
  ├── Elasticsearch MCP → 全文搜索
  ├── S3 MCP           → AWS S3文件管理
  └── Supabase MCP     → Supabase全功能

开发/运维:
  ├── Docker MCP       → 容器管理
  ├── Kubernetes MCP   → K8s集群操作
  ├── Terraform MCP    → 基础设施即代码
  ├── Sentry MCP       → 错误监控分析
  └── Datadog MCP      → 系统监控

商业SaaS:
  ├── Notion MCP       → 知识库管理
  ├── Linear MCP       → 项目管理
  ├── Figma MCP        → 设计稿操作
  ├── Salesforce MCP   → CRM操作
  └── HubSpot MCP      → 营销自动化

内容/媒体:
  ├── YouTube MCP      → 视频信息获取
  ├── Twitter/X MCP    → 社交媒体分析
  └── Spotify MCP      → 音乐服务

生态规模（2026年初估算）:
  → 官方+社区MCP Server: 1000+
  → 月活MCP连接数: 百万级
  → 已成为AI工具集成的事实标准

Web3相关MCP Server

Web3 MCP生态是2025年增长最快的垂直领域之一:

基础设施层:
  ├── Ethereum MCP Server
  │   → 读取余额/交易/合约状态
  │   → 调用合约函数(读/写)
  │   → 监听事件(Event Subscription)
  │   → 支持多链(Ethereum/Polygon/Arbitrum/Base)
  │
  ├── Alchemy MCP Server
  │   → Alchemy增强API（NFT/Token/Webhook）
  │   → getTokenBalances / getNFTs / getAssetTransfers
  │   → 支持所有Alchemy支持的链
  │
  └── Solana MCP Server
      → Solana链交互（账户/交易/Program）

数据分析层:
  ├── Dune MCP Server
  │   → 执行Dune SQL查询
  │   → 获取Dashboard数据
  │   → "帮我查过去30天Uniswap的交易量" → 自动生成SQL并执行
  │
  ├── DefiLlama MCP Server
  │   → TVL/收益率/稳定币数据
  │   → 协议对比分析
  │
  └── The Graph MCP Server
      → 执行Subgraph查询
      → GraphQL → MCP Tool映射

DeFi交互层:
  ├── Uniswap MCP Server
  │   → 获取报价/执行Swap/管理流动性
  │   → "帮我用500 USDC在Uniswap上换ETH" → 生成交易
  │
  ├── Aave MCP Server
  │   → 存款/借款/还款/清算查询
  │
  └── 1inch MCP Server
      → 聚合多DEX最优报价

安全/合规层:
  ├── Token Security MCP
  │   → 合约风险扫描（蜜罐/貔貅检测）
  │   → 授权(Approval)风险检查
  │
  └── Address Screening MCP
      → 地址风险评分（OFAC/制裁名单/混币器关联）
      → 合规检查自动化

实际使用场景:
  用户对Claude说:
    "帮我分析地址0x123...的资产情况，检查是否有风险授权"

  Claude自动:
    1. 调用 Ethereum MCP → 获取ETH余额和ERC20持仓
    2. 调用 Alchemy MCP  → 获取NFT持仓和交易历史
    3. 调用 Token Security MCP → 扫描授权风险
    4. 调用 DefiLlama MCP → 获取持仓代币的市场数据
    5. 整合所有数据 → 生成综合分析报告

金融行业MCP Server

传统金融 + MCP 正在2025-2026快速融合:

市场数据:
  ├── Bloomberg MCP（企业内部）
  │   → 实时行情/财务数据/新闻
  │   → 需要Bloomberg Terminal授权
  │
  ├── Alpha Vantage MCP
  │   → 股票/外汇/加密货币行情
  │   → 免费API + MCP封装
  │
  └── Yahoo Finance MCP
      → 公开市场数据

交易执行:
  ├── Interactive Brokers MCP
  │   → 下单/查持仓/风险查询
  │   → 需要IB账户
  │
  └── Alpaca MCP
      → 美股交易API
      → 支持Paper Trading

合规/风控:
  ├── Chainalysis MCP
  │   → 链上地址风险评分
  │   → KYT(Know Your Transaction)
  │
  └── Elliptic MCP
      → 反洗钱(AML)筛查

对金融PM的意义:
  → MCP让AI Agent能够直接操作金融系统
  → 不再是"生成报告" → 而是"执行交易+监控+预警"
  → 金融机构需要设计MCP层的权限和风控体系

MCP Server Registry与发现机制

2025年下半年至2026年，MCP生态的关键基础设施逐步成熟:

发现机制演进:
  2024.11: 手动配置JSON文件（claude_desktop_config.json）
  2025.H1: GitHub awesome-mcp-servers列表
  2025.H2: 官方MCP Server Registry上线
  2026.Q1: IDE内建Server搜索/安装

Registry核心功能:
  → 发布: 开发者提交MCP Server元数据
  → 搜索: 按名称/标签/类别查找Server
  → 验证: 基础安全扫描和兼容性测试
  → 版本管理: 语义化版本 + 变更日志
  → 评分系统: 使用量/稳定性/安全评分

类比:
  MCP Registry ≈ npm/PyPI for AI tools
  → npm: JavaScript包的发现与分发
  → MCP Registry: AI工具的发现与分发

  金融类比:
  MCP Registry ≈ SWIFT的BIC目录(银行识别码)
  → 要给某银行转账 → 先查BIC/SWIFT Code
  → 要用某个工具 → 先在Registry查MCP Server

---

知识点5: MCP安全模型

安全是MCP能否进入生产环境的关键

AI Agent直接操作外部系统 → 安全风险远超传统API调用

风险矩阵:
┌──────────────┬────────────────────────┬──────────────────────┐
│ 风险类型     │ 具体场景               │ 严重程度             │
├──────────────┼────────────────────────┼──────────────────────┤
│ 越权操作     │ Agent删除数据库         │ 灾难级               │
│ 数据泄露     │ Agent把私钥发给用户     │ 灾难级               │
│ 提示注入     │ 恶意Server操纵Agent    │ 高                   │
│ 供应链攻击   │ 恶意MCP Server包       │ 高                   │
│ 资源滥用     │ Agent无限循环调用API   │ 中                   │
│ 隐私问题     │ Agent读取不该看的文件   │ 中-高                │
└──────────────┴────────────────────────┴──────────────────────┘

金融场景的安全要求尤其严格:
  → 一个MCP Server能调用交易API → 可能造成真实资金损失
  → AI Agent执行转账 → 必须有与银行同等级的授权控制
  → 读取客户数据 → 必须符合GDPR/隐私法规

MCP内建安全机制

1. 权限协商（Capability Negotiation）
   → 连接建立时，Client和Server交换能力列表
   → Client明确告知Server允许/禁止的操作
   → 最小权限原则

   初始化握手:
   Client → Server: {
     "method": "initialize",
     "params": {
       "capabilities": {
         "tools": { "listChanged": true },
         "sampling": {}           // 允许Server请求Sampling
       }
     }
   }
   Server → Client: {
     "result": {
       "capabilities": {
         "tools": {},             // Server提供Tools
         "resources": {}          // Server提供Resources
       }
     }
   }

2. 人类确认（Human-in-the-Loop）
   → Tool调用前，Host向用户展示即将执行的操作
   → 用户显式确认或拒绝
   → 高风险操作（写入/交易/删除）强制确认

   流程:
   LLM决定调用tool → Host拦截 → 展示给用户:
     "AI wants to execute: send_transaction
      To: 0xABC...
      Amount: 1.5 ETH
      [Approve] [Deny]"
   → 用户点击Approve → 才真正执行

3. Transport层安全
   → stdio: 本地进程隔离，无网络暴露
   → HTTP/SSE: 必须TLS加密
   → 服务端验证Client身份

OAuth 2.1集成（2025年重大更新）

2025年3月MCP规范重大更新: 内建OAuth 2.1授权框架

为什么需要OAuth 2.1?
  → 早期MCP: 仅靠stdio进程隔离 → 本地够用
  → 远程MCP Server: 需要标准化的身份认证和授权
  → 企业场景: 员工A能查数据但不能改，员工B能执行交易

OAuth 2.1 in MCP:
┌──────────┐  1.发现授权端点   ┌───────────────┐
│MCP Client│ ──────────────► │ MCP Server     │
│          │ ◄────────────── │ (Authorization │
│          │  2.返回OAuth元数据│  Server)       │
│          │                 └───────────────┘
│          │  3.用户授权
│          │ ──────────────► ┌───────────────┐
│          │ ◄────────────── │ OAuth Provider │
│          │  4.获得Token     │ (Okta/Auth0)  │
│          │                 └───────────────┘
│          │  5.带Token调用
│          │ ──────────────► ┌───────────────┐
│          │ ◄────────────── │ MCP Server     │
│          │  6.授权后的响应   │ (Resource)     │
└──────────┘                 └───────────────┘

关键设计:
  → 基于RFC 9728的OAuth Protected Resource Metadata
  → Server通过 /.well-known/oauth-authorization-server 暴露认证信息
  → 支持PKCE（Proof Key for Code Exchange）防CSRF
  → 支持Dynamic Client Registration（MCP Client自动注册）
  → Token scope精确到工具级别（读取余额 vs 执行交易）

金融场景应用:
  银行内部MCP Server:
    → Scope: balance:read          → 查询账户余额
    → Scope: transaction:read      → 查看交易记录
    → Scope: transaction:execute   → 执行转账（需要二次授权）
    → Scope: admin:full            → 管理员权限

  DeFi MCP Server:
    → Scope: price:read            → 查看价格（公开）
    → Scope: portfolio:read        → 查看持仓（需授权）
    → Scope: swap:execute          → 执行交易（需钱包签名）

企业级部署安全考虑

企业在生产环境部署MCP时的安全架构:

┌─────────────────────────────────────────────────────┐
│                  企业MCP安全架构                      │
│                                                     │
│  ┌──────────┐    ┌──────────────┐    ┌──────────┐  │
│  │ AI Agent │ ──►│  MCP Gateway  │──►│MCP Server│  │
│  │ (内部)   │    │  (安全网关)    │    │ (内/外部)│  │
│  └──────────┘    │              │    └──────────┘  │
│                  │ ┌──────────┐ │                   │
│                  │ │ 审计日志  │ │                   │
│                  │ │ 速率限制  │ │                   │
│                  │ │ 权限检查  │ │                   │
│                  │ │ 数据脱敏  │ │                   │
│                  │ │ 异常检测  │ │                   │
│                  │ └──────────┘ │                   │
│                  └──────────────┘                   │
└─────────────────────────────────────────────────────┘

MCP Gateway关键功能:
  1. 认证: 验证Agent/用户身份
  2. 授权: 检查角色权限（RBAC/ABAC）
  3. 审计: 记录所有Tool调用（谁在什么时候调了什么工具）
  4. 速率限制: 防止资源滥用
  5. 数据脱敏: 敏感字段自动遮罩（身份证号/银行卡号）
  6. 异常检测: 识别异常调用模式（AI被注入攻击时的行为偏离）
  7. 断路器: Server故障时自动熔断

金融机构必须额外考虑:
  → 合规审计: 所有AI操作留痕，满足监管要求
  → 灾难恢复: MCP Gateway故障不应导致核心系统不可用
  → 隔离: 生产环境MCP Server与测试环境严格隔离
  → 加密: 端到端加密，数据不落盘

---

知识点6: A2A协议 — Agent间通信标准

A2A（Agent-to-Agent Protocol）概述

2025年5月，Google发布A2A协议:

MCP解决的问题: AI Agent如何调用外部工具？    (Agent ↔ Tool)
A2A解决的问题: AI Agent如何与其他Agent协作？ (Agent ↔ Agent)

┌──────────────────────────────────────────────────┐
│              协议层全景                            │
│                                                  │
│  ┌──────────┐   A2A协议    ┌──────────┐          │
│  │ Agent A  │ ◄──────────► │ Agent B  │          │
│  │ (贷款审批)│              │ (风控评估)│          │
│  └────┬─────┘              └────┬─────┘          │
│       │                         │                │
│       │ MCP协议                  │ MCP协议        │
│       │                         │                │
│  ┌────┴─────┐              ┌────┴─────┐          │
│  │ 征信查询  │              │ 黑名单查询│          │
│  │ MCP Server│              │ MCP Server│          │
│  └──────────┘              └──────────┘          │
│                                                  │
│  MCP = Agent与Tool之间的垂直通信                   │
│  A2A = Agent与Agent之间的水平通信                   │
└──────────────────────────────────────────────────┘

MCP与A2A的关系: 互补而非竞争

一个完整的Multi-Agent系统需要两层协议:

┌─────────────┬──────────────────┬──────────────────────┐
│             │ MCP              │ A2A                  │
├─────────────┼──────────────────┼──────────────────────┤
│ 通信方向     │ Agent ↔ Tool     │ Agent ↔ Agent        │
├─────────────┼──────────────────┼──────────────────────┤
│ 核心问题     │ 如何调用工具      │ 如何委托/协作任务    │
├─────────────┼──────────────────┼──────────────────────┤
│ 发现机制     │ tools/list       │ Agent Card           │
│             │ 工具能力列表      │ Agent能力描述JSON    │
├─────────────┼──────────────────┼──────────────────────┤
│ 状态管理     │ 请求-响应        │ 任务状态机            │
│             │ 较简单           │ submitted→working    │
│             │                  │ →completed/failed    │
├─────────────┼──────────────────┼──────────────────────┤
│ 通信模式     │ 同步为主         │ 异步为主             │
│             │ 短时操作         │ 长时任务             │
├─────────────┼──────────────────┼──────────────────────┤
│ 推送者       │ Anthropic        │ Google               │
├─────────────┼──────────────────┼──────────────────────┤
│ 成熟度(2026) │ 生产就绪         │ 早期采用             │
└─────────────┴──────────────────┴──────────────────────┘

金融场景示例（两者协同）:

场景: "帮我评估这笔跨境贷款的风险"

  用户 → 主Agent(贷款经理Agent)
         │
         ├─ A2A → 征信评估Agent
         │         │
         │         ├─ MCP → 征信数据库Server → 查询借款人征信
         │         └─ MCP → 法院判决Server   → 查询诉讼记录
         │         ← A2A(返回征信报告)
         │
         ├─ A2A → 外汇风险Agent
         │         │
         │         ├─ MCP → 汇率API Server → 获取汇率
         │         └─ MCP → 新闻API Server → 获取地缘政治新闻
         │         ← A2A(返回外汇风险评估)
         │
         └─ A2A → 合规Agent
                   │
                   ├─ MCP → 制裁名单Server → OFAC筛查
                   └─ MCP → KYC Server     → 身份验证
                   ← A2A(返回合规检查结果)
         │
         整合所有Agent报告 → 生成贷款风险评估报告

要点:
  → MCP负责每个Agent与具体工具/数据的交互（垂直）
  → A2A负责Agent之间的任务委托和结果汇总（水平）
  → 两者组合才能构建真正的Multi-Agent系统

A2A核心机制

Agent Card（Agent名片）:
  → 每个Agent发布一个JSON描述文件
  → 类似MCP Server的tools/list，但描述的是Agent能力

  {
    "name": "credit-risk-agent",
    "description": "Evaluates credit risk for loan applications",
    "url": "https://agents.bank.com/credit-risk",
    "capabilities": {
      "streaming": true,
      "pushNotifications": true
    },
    "skills": [
      {
        "id": "credit-scoring",
        "name": "Credit Risk Scoring",
        "description": "Calculate credit risk score for individuals/businesses"
      }
    ],
    "authentication": {
      "schemes": ["oauth2"]
    }
  }

任务生命周期:
  submitted → working → completed
                     → failed
                     → canceled
                     → input-required (需要更多信息)

  → 支持长时间运行的任务（传统API调用通常要求快速返回）
  → 支持流式更新（Agent在working过程中推送进度）
  → 支持协商（Agent可以要求更多输入信息）

---

知识点7: MCP对产品和架构的影响

获客逻辑的根本变化

传统SaaS获客:
  用户 → Google搜索 → 找到你的网站 → 注册 → 使用
  用户 → 应用商店 → 找到你的App → 下载 → 使用
  → 竞争焦点: SEO、广告投放、产品体验

MCP时代的获客:
  用户 → 对AI说"帮我做XXX" → AI自动发现你的MCP Server → 调用
  用户甚至不知道你的产品名字 → 但你的工具被AI选中使用了
  → 竞争焦点: Tool描述质量、功能独特性、执行可靠性

金融场景:
  传统: 用户主动打开Bloomberg/Wind → 搜索数据 → 导出分析
  MCP:  用户对AI说"帮我对比过去3年中美利差走势"
        → AI发现并调用Bloomberg MCP Server
        → 用户可能从未直接登录Bloomberg界面

这对产品经理意味着:
  1. API-first → MCP-first: 新产品首先考虑MCP Server暴露
  2. UI不再是唯一入口: AI成为主要交互界面
  3. Tool描述 = 新的SEO: 工具的名称和description决定被AI选中的概率
  4. 可靠性 > 花哨功能: AI会记住哪些工具经常失败

API-first到MCP-first的演进

产品架构演进路线:

Phase 1: UI-first（传统）
  用户 → Web/App UI → 后端API → 数据库
  → 所有能力通过界面暴露

Phase 2: API-first（2015-2024）
  用户 → Web/App UI ─┐
  开发者 → REST API  ─┼→ 后端服务 → 数据库
  合作方 → SDK       ─┘
  → 核心能力通过API暴露，UI只是消费者之一

Phase 3: MCP-first（2025+）
  用户 → Web/App UI  ─┐
  开发者 → REST API   ─┤
  AI Agent → MCP Server┼→ 后端服务 → 数据库
  其他Agent → A2A     ─┘
  → 核心能力通过MCP暴露，API和UI都是消费者
  → MCP Server成为产品最重要的"接口"

产品设计checklist:
  □ 核心功能是否已有MCP Server？
  □ Tool描述是否清晰、AI友好？
  □ 错误信息是否对AI可理解？（不能只返回500错误）
  □ 是否有适当的权限粒度？
  □ 是否发布在MCP Registry？

Agent App Store的可能性

MCP Registry + OAuth + 发现机制 → 类似App Store的Agent工具市场

┌────────────────────────────────────────────────────┐
│            Agent App Store 设想                     │
│                                                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐         │
│  │ DeFi套件 │  │ 合规套件 │  │ 交易套件 │         │
│  │ ────────│  │ ────────│  │ ────────│         │
│  │ Uniswap │  │ OFAC筛查│  │ 下单执行 │         │
│  │ Aave    │  │ KYC验证 │  │ 持仓管理 │         │
│  │ Curve   │  │ AML监控 │  │ 风险计算 │         │
│  │ 1inch   │  │ 审计报告 │  │ 策略回测 │         │
│  └──────────┘  └──────────┘  └──────────┘         │
│                                                    │
│  安装: 一键添加到你的AI Agent                       │
│  计费: 按调用次数/按月订阅                          │
│  评价: 可靠性/速度/数据质量评分                      │
│  认证: 官方验证 / 安全审计通过                       │
└────────────────────────────────────────────────────┘

商业模式可能性:
  1. 免费+高级: 基础功能免费，高级Tool收费
  2. 按调用计费: 每次Tool调用$0.001-$0.01
  3. 订阅制: 企业级功能按月/年订阅
  4. 数据变现: 使用数据分析（匿名化）

对Web3的特殊影响:
  → DeFi协议的MCP Server = 新的获客渠道
  → AI Agent成为DeFi的主要用户（非人类）
  → Gas费优化、MEV保护 → AI比人类执行得更好
  → 协议可能为AI Agent设计专门的接口和费率

对Web3协议的深远影响

MCP正在改变Web3协议的产品设计思路:

传统DeFi交互流程:
  用户 → 打开DApp网站 → 连接钱包 → 手动操作 → 签名交易
  → 高门槛、UX差、容易出错

MCP+Agent时代的DeFi:
  用户 → 对AI说"把我的ETH分散存入收益最高的3个借贷协议"
  AI Agent:
    1. 调用 DefiLlama MCP → 对比各协议收益率
    2. 调用 Token Security MCP → 检查各协议安全性
    3. 调用 Aave/Compound/Morpho MCP → 模拟存款
    4. 计算最优分配方案 → 展示给用户
    5. 用户确认 → 批量执行交易
  → 用户不需要懂DeFi，AI处理所有复杂性

对协议产品经理的影响:
  1. UI可能不再是主战场 → MCP Server的质量决定AI流量
  2. 需要设计"AI友好"的接口 → 清晰的参数、详尽的错误信息
  3. 协议间竞争维度变化 → 被AI推荐的概率 > 直接用户获取
  4. 安全审计范围扩大 → MCP Server本身也需要审计
  5. 新的增长指标: MCP调用量 / AI Agent用户数

金融产品架构启示:
  → 每个金融产品都应该有MCP Server层
  → 核心银行系统 → 账户查询/转账/报表的MCP Server
  → 风控系统 → 风险评估/规则查询的MCP Server
  → 合规系统 → 筛查/报告的MCP Server
  → 统一通过MCP Gateway管理安全和权限

---

今日思考

思考1: MCP会不会重蹈USB的标准之战？

历史教训:
  USB之前有: 串口、并口、PS/2、FireWire → 最终USB统一
  MCP之前有: Function Calling、LangChain Tools → MCP正在统一

但风险仍在:
  → Google推A2A，可能在Tool层也推自己的标准？
  → OpenAI虽然支持MCP，但自家Plugins/GPTs也是生态壁垒
  → 中国AI公司可能推出本土化MCP变体

我的判断:
  MCP大概率成为事实标准（类似USB-C取代一切）
  原因:
  1. Anthropic不是平台公司 → 没有动机锁定生态 → 信任度高
  2. OpenAI主动采纳 → 最大生态的加入验证了标准
  3. 协议足够简单 → 实现门槛低 → 快速扩散
  4. 先发优势 → 已有1000+ Server → 网络效应

  对产品经理的行动建议:
  → 现在就开始为产品设计MCP Server
  → 不要观望，标准化的早期参与者获益最大
  → 就像2010年做移动App → 2025年做MCP Server

思考2: MCP如何改变金融行业的AI落地路径？

金融行业AI落地一直很慢，核心障碍:
  1. 数据孤岛: 每个系统的数据格式不同
  2. 合规要求: 数据不能随便出系统
  3. 集成成本: 与核心系统对接需要大量开发

MCP如何破解:
  障碍1 → MCP标准化数据接口 → 不同系统暴露统一格式的Resources
  障碍2 → OAuth 2.1 + 审计日志 → 满足合规的同时允许AI访问
  障碍3 → 一次实现MCP Server → 所有AI Agent都能接入

具体路径:
  Phase 1（现在）: 只读MCP Server → AI读取数据做分析
    风险低、合规压力小、价值立竿见影
    → 客户画像分析、市场报告生成、合规检查

  Phase 2（6-12个月）: 受控写入 → AI执行低风险操作
    有人工确认、有回滚机制
    → 自动填表、标准化报表生成、客户通知发送

  Phase 3（1-2年）: 自主操作 → AI全流程自动化
    完善的权限、审计、熔断机制
    → 自动化交易执行、智能风控响应、合规自动报告

  这与我10年金融系统经验高度相关:
  → 我做过核心银行系统对接 → 理解集成痛点
  → 现在MCP提供了标准化方案 → 可以设计更优的集成架构

思考3: MCP-first思维对产品经理意味着什么？

类比移动互联网转型:
  2007年iPhone发布 → "Mobile-first"思维
  → 不是把网页缩小到手机 → 而是从手机出发重新设计产品

  2024年MCP发布 → "MCP-first"思维
  → 不是给现有产品加个MCP接口 → 而是从AI Agent出发重新设计产品

具体变化:
  传统产品设计:
    定义用户 → 设计UI → 实现后端 → 暴露API → （也许）加AI功能

  MCP-first产品设计:
    定义能力 → 设计MCP Server → 确保AI可调用 → （也）设计UI → 优化人机双通道

  产品经理新技能树:
    ├── 理解MCP协议原语（Tools/Resources/Prompts）
    ├── 设计AI友好的Tool接口（命名/描述/参数/错误处理）
    ├── 安全架构思维（OAuth/权限/审计）
    ├── 多Agent编排思维（MCP+A2A）
    └── 新增长指标（AI调用量/Agent满意度/工具被选中率）

  对Web3 PM尤其重要:
    DeFi协议的下一代用户可能主要是AI Agent
    → 设计MCP Server = 设计"给AI用的产品"
    → 这是全新的设计思维

---

面试表达

问题: 什么是MCP？为什么它对AI产品重要？

30秒版本:
"MCP是Anthropic开源的AI工具调用标准协议，类似USB标准。
之前每个AI平台要单独集成每个工具，N×M的复杂度。
MCP统一了接口，工具方实现一次Server，AI方实现一次Client，
自动对接所有工具。2025年OpenAI等巨头也采纳了MCP，
它正在成为AI生态的事实标准。"

2分钟版本:
"MCP（Model Context Protocol）是Anthropic 2024年底开源的标准协议，
定义了AI模型如何发现和调用外部工具。

用金融行业类比，MCP就像SWIFT标准——
SWIFT之前，银行间通信要两两定制格式，100家银行就有上万种对接方式。
SWIFT统一了报文格式，每家银行只需实现一次。

MCP同理。之前LangChain、OpenAI、Claude各有自己的工具定义方式，
工具提供方要为每个平台分别适配。
MCP基于JSON-RPC 2.0定义了三种原语：
Tools（可执行操作）、Resources（可读取数据）、Prompts（交互模板）。

2025年的关键里程碑是OpenAI宣布支持MCP，
加上OAuth 2.1安全模型和Streamable HTTP传输的加入，
MCP已具备企业级部署条件。

对产品经理而言，MCP带来了根本性的获客逻辑变化——
传统产品通过UI获客，MCP时代AI Agent成为产品的主要消费者。
API-first要升级为MCP-first，
Tool的描述质量和执行可靠性取代了UI设计成为新的竞争焦点。"

追问准备:

Q: MCP和Function Calling有什么区别？
A: "Function Calling是各家AI厂商自己定义的工具调用格式，
   绑定特定平台。MCP是开放协议，一次实现处处可用。
   类比：Function Calling是各银行的内部报文格式，
   MCP是SWIFT这样的行业标准。
   而且MCP支持动态发现、标准安全模型、Sampling等Function Calling没有的能力。"

Q: MCP和A2A是竞争关系吗？
A: "不是，完全互补。MCP解决Agent与Tool之间的垂直通信，
   A2A解决Agent与Agent之间的水平协作。
   一个完整的Multi-Agent系统两者都需要。
   类比：MCP像银行内部系统对接标准，
   A2A像银行间的清算协议——一个管内部操作，一个管跨行协作。"

Q: 如何评估一个MCP Server的质量？
A: "五个维度：第一，Tool描述清晰度——AI能否理解该工具的用途和参数；
   第二，执行可靠性——超时率、错误率；
   第三，安全性——是否有适当的认证和权限控制；
   第四，性能——响应延迟是否影响Agent体验；
   第五，错误处理——错误信息是否对AI可理解，不能只返回500。"

---

学习资源

官方资源

MCP Server目录

技术文章

Web3 MCP相关

视频教程

---

明日预告

Day 14: 模型评估 — Benchmark / Arena / 安全评估

核心问题:
  我们学了这么多模型和技术（Transformer/Reasoning/Agent/MCP）
  → 但如何客观评估一个模型的能力？
  → 如何对比不同模型？
  → 如何确保模型的安全性？

  金融场景:
    要为银行选一个AI模型用于客服/风控/投研
    → 怎么评估？"感觉GPT-4比较好"不够
    → 需要系统化的评估框架和Benchmark

预习:
  → MMLU/HumanEval/GSM8K等经典Benchmark
  → Chatbot Arena(LMSYS)的ELO评分体系
  → 安全评估: 红队测试/对抗攻击/偏见检测
  → 企业级模型选型方法论

与今日关系:
  Day 13 MCP    → 定义了AI如何连接外部工具（协议标准）
  Day 14 评估    → 定义了如何衡量AI的能力和安全（评估标准）
  组合 = 选对模型 + 连对工具 → 构建可靠的AI系统
       → 这两者都是架构师必须掌握的"标准化"思维

---

Day 13 总结: MCP（Model Context Protocol）是2024-2026年AI基础设施领域最重要的标准化突破。Anthropic以开放协议的方式定义了AI模型与外部工具的通信标准，基于JSON-RPC 2.0、三大原语（Tools/Resources/Prompts）和Sampling机制，将N个AI客户端与M个工具服务的集成复杂度从O(N x M)降至O(N + M)。2025年OpenAI的采纳和OAuth 2.1安全模型的加入标志着MCP从实验走向生产就绪。配合Google的A2A协议（Agent间通信），AI生态的"协议层"已经成型：MCP管Agent与Tool的垂直连接，A2A管Agent与Agent的水平协作。对金融行业而言，MCP解决了长期困扰AI落地的数据孤岛和集成成本问题——每个系统只需实现一次MCP Server，即可被所有AI Agent安全访问。对产品经理而言，MCP带来了根本性的思维转变：从API-first到MCP-first，AI Agent成为产品的主要消费者，Tool描述质量和执行可靠性取代UI设计成为新的竞争焦点。这不是简单的技术升级，而是产品获客逻辑和架构设计范式的重塑。