背景：AI 集成的演进

随着大语言模型（LLM）的能力边界不断扩展，如何让 AI 安全、高效地与外部世界交互成为了核心问题。从最初的简单 API 调用，到今天的复杂 Agent 系统，AI 集成方案经历了显著的演进。

当前主流的三种方案各有侧重：

方案定位核心解决的问题
Function Calling模型原生能力让 LLM 学会"使用工具"
LangChain应用开发框架简化 LLM 应用开发流程
MCP标准化协议统一 AI 与外部系统的交互方式

理解它们的差异，有助于在技术选型时做出更合适的决策。

三种方案概览

MCP（Model Context Protocol）

MCP 是一个开放协议标准，定义了 AI 模型与外部系统交互的规范。它不绑定任何特定框架或语言，目标是成为"AI 时代的 HTTP"。

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   AI 模型    │◄───►│  MCP 协议层  │◄───►│  外部工具    │
│  (Any LLM)   │     │ (标准接口)   │     │ (MCP Server)│
└─────────────┘     └─────────────┘     └─────────────┘

LangChain

LangChain 是一个Python/JS 应用框架，提供了构建 LLM 应用的完整工具链，包括提示词管理、链式调用、Agent 编排等。

┌─────────────┐     ┌─────────────────────────────┐
│   AI 模型    │◄───►│        LangChain 框架        │
│             │     │  (Chains + Agents + Memory)  │
└─────────────┘     └─────────────────────────────┘
                              │
                    ┌─────────┼─────────┐
                    ▼         ▼         ▼
               ┌────────┐ ┌────────┐ ┌────────┐
               │ 工具 A  │ │ 工具 B  │ │ 工具 C  │
               └────────┘ └────────┘ └────────┘

Function Calling

Function Calling 是模型厂商提供的原生能力，允许模型输出结构化的函数调用请求，由客户端执行后返回结果。

┌─────────────────────────────────────────────────────┐
│                    对话流程                          │
├─────────────────────────────────────────────────────┤
│  用户："北京天气怎么样？"                             │
│  ─────────────────────────────►                     │
│                    LLM 推理                          │
│                         │ 识别需要调用 get_weather   │
│                         ▼                           │
│  ◄──────────────────────┐                           │
│  {"name": "get_weather",│ 输出函数调用               │
│   "arguments": {"city": "北京"}}                     │
│  ───────────────────────┘                           │
│                         │ 客户端执行                  │
│                         ▼                           │
│  ◄──────────────────────┐                           │
│  "北京今天晴，25°C..."   │ 返回结果给 LLM            │
└─────────────────────────────────────────────────────┘

MCP：模型上下文协议

核心设计

MCP 的设计哲学是**“一次实现，到处使用”**。它通过标准化协议解耦了 AI 模型与工具实现：

// MCP Server 定义示例
type MCPServer struct {
    Tools map[string]Tool
}

type Tool struct {
    Name        string
    Description string
    InputSchema jsonschema.Schema
    Handler     func(context.Context, Request) (Response, error)
}

关键特性

  1. 协议标准化

    • 统一的工具发现机制
    • 标准化的请求/响应格式
    • 类型安全的 JSON Schema 验证

  2. 传输层抽象

    • 支持 stdio、SSE、HTTP 等多种传输
    • 可插拔的架构设计

  3. 上下文管理

    • 内置会话状态管理
    • 支持多轮交互的上下文保持

代码示例

// 创建 MCP Server
server := mcp.NewServer("weather-server")

// 注册工具
server.AddTool(mcp.Tool{
    Name:        "get_weather",
    Description: "获取指定城市的天气",
    InputSchema: mcp.MustSchema(WeatherRequest{}),
    Handler: func(ctx context.Context, req WeatherRequest) (*mcp.ToolResponse, error) {
        weather, err := fetchWeather(req.City)
        if err != nil {
            return nil, err
        }
        return mcp.NewToolResponse(weather), nil
    },
})

// 启动服务
server.ServeStdio()

LangChain：编排框架

核心设计

LangChain 的核心是**“链式组合”（Chains）和“智能体”（Agents）**模式：

# LangChain 的典型用法
from langchain import OpenAI, LLMChain, PromptTemplate
from langchain.agents import initialize_agent, Tool

# 定义工具
tools = [
    Tool(
        name="Search",
        func=search_engine.run,
        description="用于搜索实时信息"
    ),
    Tool(
        name="Calculator", 
        func=calculator.run,
        description="用于数学计算"
    )
]

# 初始化 Agent
agent = initialize_agent(
    tools, 
    llm,
    agent="zero-shot-react-description"
)

# 运行
agent.run("2024年诺贝尔物理学奖得主是谁？他们的主要贡献是什么？")

关键特性

  1. 丰富的集成生态

    • 预置了数百种工具和数据源的集成
    • 支持主流模型厂商（OpenAI、Anthropic、Cohere 等）

  2. 开发抽象层

    • Prompt 模板管理
    • 输出解析器（Output Parsers）
    • 记忆模块（Memory）

  3. Agent 模式

    • ReAct、Plan-and-Execute 等推理模式
    • 多 Agent 协作框架（LangGraph）

适用场景

  • 快速原型开发
  • 需要复杂编排逻辑的应用
  • 利用现有集成生态

Function Calling：原生能力

核心设计

Function Calling 是模型层的原生能力，不同厂商的实现略有差异：

OpenAI 风格：

response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "北京天气如何？"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string"}
                },
                "required": ["city"]
            }
        }
    }]
)

Anthropic 风格：

response = client.messages.create(
    model="claude-3-opus-20240229",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "获取天气信息",
        "input_schema": {...}
    }],
    messages=[{"role": "user", "content": "北京天气如何？"}]
)

关键特性

  1. 零依赖

    • 不需要额外框架
    • 直接调用模型 API

  2. 原生优化

    • 模型针对函数调用进行了微调
    • 准确率通常高于通用方案

  3. 厂商绑定

    • API 格式不统一
    • 切换模型成本较高

深度对比

架构设计哲学

维度MCPLangChainFunction Calling
抽象层级协议层应用框架层模型能力层
耦合度低（协议解耦）中（框架依赖）高（厂商绑定）
可移植性高（跨模型/语言）中（Python/JS）低（厂商特定）
标准化程度高中低

关键洞察：

  • MCP 是横向协议，目标是成为行业标准
  • LangChain 是纵向框架，追求开发效率最大化
  • Function Calling 是点状能力，提供最直接的工具使用能力

开发体验

┌──────────────────────────────────────────────────────────────┐
│                    实现一个天气查询功能                        │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Function Calling (OpenAI):                                  │
│  ─────────────────────────                                   │
│  1. 定义函数 schema                                          │
│  2. 在 API 调用中传入 tools 参数                              │
│  3. 解析 response 中的 function_call                         │
│  4. 执行函数并返回结果                                        │
│  5. 将结果追加到 messages 再次调用                            │
│  【约 50 行代码】                                             │
│                                                              │
│  LangChain:                                                  │
│  ──────────                                                  │
│  1. 用 @tool 装饰器定义工具                                   │
│  2. 创建 Agent 并传入工具列表                                 │
│  3. 调用 agent.run()                                         │
│  【约 20 行代码，但引入框架依赖】                              │
│                                                              │
│  MCP:                                                        │
│  ────                                                        │
│  1. 实现 MCP Server 注册工具                                  │
│  2. 客户端通过 MCP 协议连接                                   │
│  3. 模型自动发现并使用工具                                     │
│  【Server 约 30 行，客户端约 10 行，解耦彻底】                 │
│                                                              │
└──────────────────────────────────────────────────────────────┘

生态与扩展性

能力MCPLangChainFunction Calling
工具生态新兴（快速增长）成熟（300+ 集成）依赖上层封装
跨语言✅ 任何语言⚠️ 主要 Python/JS❌ 绑定厂商 SDK
模型无关✅ 完全无关⚠️ 需要适配层❌ 厂商特定
社区活跃度高（Anthropic 推动）高（LangChain 公司）中（各厂商独立）

工具复用示例：

// 一个 MCP Server 可以被多种客户端使用
// 1. Claude Desktop
// 2. 自建的 Web 应用
// 3. 命令行工具
// 4. 其他编程语言编写的客户端

// 而 LangChain 的工具通常只能在 LangChain 生态内使用
// Function Calling 的 schema 需要为每个模型单独定义

性能与开销

指标MCPLangChainFunction Calling
延迟中（协议解析）高（框架开销）低（直接调用）
吞吐量高（可独立部署）中（Python GIL 限制）高
资源占用低（Go/Rust 实现）高（Python 生态）低
冷启动中高低

性能优化建议：

  • MCP：使用 Streamable HTTP 传输，连接池复用
  • LangChain：考虑使用 LangServe 部署为独立服务
  • Function Calling：批量请求，合理使用缓存

选型指南

选择 MCP 如果：

  • ✅ 需要跨模型、跨语言的工具复用
  • ✅ 构建可插拔的 AI 基础设施
  • ✅ 追求长期标准化和生态互操作性
  • ✅ 团队技术栈多元（Go/Python/TS 等）

选择 LangChain 如果：

  • ✅ 快速开发原型或 MVP
  • ✅ 需要丰富的预置集成（向量数据库、文档加载器等）
  • ✅ 复杂的 Agent 编排逻辑（多 Agent 协作、条件分支等）
  • ✅ 团队以 Python/JS 为主

选择 Function Calling 如果：

  • ✅ 简单场景，追求最低延迟
  • ✅ 已绑定特定模型厂商（如 GPT-4）
  • ✅ 不想引入额外依赖
  • ✅ 对性能极度敏感

混合方案

实际项目中，往往会组合使用：

┌─────────────────────────────────────────────┐
│               应用层                         │
│  ┌─────────────────────────────────────┐   │
│  │        LangChain/LangGraph          │   │
│  │    (编排复杂业务逻辑、Agent 协作)      │   │
│  └──────────────────┬──────────────────┘   │
│                     │                       │
│           ┌─────────┴─────────┐             │
│           │   MCP Client      │             │
│           │  (协议适配层)      │             │
│           └─────────┬─────────┘             │
│                     │                       │
│    ┌────────────────┼────────────────┐     │
│    ▼                ▼                ▼     │
│ ┌────────┐    ┌────────┐    ┌────────┐    │
│ │MCP Svr │    │MCP Svr │    │Direct  │    │
│ │Search  │    │Weather │    │GPT Call│    │
│ └────────┘    └────────┘    └────────┘    │
└─────────────────────────────────────────────┘

未来趋势

MCP 的发展方向

  1. 生态快速扩张

    • 官方 Registry 即将推出
    • 更多语言实现（Python、Rust、Java）
    • 企业级特性（认证、审计、限流）

  2. 标准化进程

    • 有望成为 AI 集成的"USB 接口"
    • 各大模型厂商可能原生支持

  3. 与 LangChain 的关系

    • LangChain 已添加 MCP 适配器
    • 两者走向融合而非竞争

LangChain 的演进

  1. 从框架到平台

    • LangSmith：可观测性平台
    • LangServe：部署服务
    • LangGraph：复杂编排

  2. MCP 集成

    • 作为工具的另一种加载方式
    • 保持框架的编排优势

模型厂商的策略

  • OpenAI：优化 Function Calling 准确性，推出 Agents SDK
  • Anthropic：全力推动 MCP 成为行业标准
  • Google：Gemini Function Calling + Vertex AI 工具生态

总结

MCPLangChainFunction Calling
本质开放协议开发框架模型能力
最佳场景基础设施/标准化应用开发/快速迭代简单集成/性能优先
长期价值生态互操作性开发效率模型优化
学习曲线中等陡峭平缓

最终建议：

  1. 新项目：优先考虑 MCP，投资未来标准
  2. 现有 LangChain 项目：逐步引入 MCP Server，保持框架优势
  3. 简单场景：直接使用 Function Calling，避免过度工程
  4. 企业级应用：MCP + LangChain 混合架构，兼顾标准化与灵活性

技术选型没有银弹，理解各方案的本质差异，才能做出适合当下、兼顾未来的决策。

参考资料