技术更迭

LLM 应用工程化难题

模型与外部世界割裂
- LLM 是基于概率计算的新范式，虽然很强大，但仍需要与传统的结构化计算范式相结合，即通过工具调用来完成精确任务
- 目前传统结构化工具与 LLM 之间是割裂的，LLM 难以直接动态地接入实时数据、数据库或企业工具
- 传统的 API 调用方式零散且不标准，导致开发效率低下
Agent 协作的孤岛效应
- 不同 Agent 框架（LangGraph、AutoGen、CrewAI）各自为政，缺乏统一的通信标准，跨平台协作很难实现
复杂场景的工程化瓶颈
- 从搜索助手到企业知识中台、RAG 与多 Agent 系统需要处理多源数据、多模态交互和长时任务，现有工具链难以提供统一的解决方案

标准化 + 可扩展

模型主控 + 客户端驱动

MCP 将繁琐细节都隐藏到服务器端 - 开发者只需关心 LLM 想用哪个工具做什么 - 不再需要为每个服务编写样板代码 - 即插即用

JSON-RPC 调用

{
  "method": "callTool",
  "params": {
    "tool": "Translate",
    "input": "Hello, world!",
    "target_lang": "zh"
  }
}

核心理念 - 模型主控、客户端驱动服务器调用

基于 MCP 的标准化协议，可以将 AI Agent 轻松地连接到各种外部工具和数据源
MCP 相当于专门为 AI 应用提供的 USB-C 端口
- 即插即用，所有繁琐的事情，都由 MCP Server 根据协议来提供

OpenAI Function Calling vs LangChain Tools vs JSON-RPC

OpenAI Function Calling 和 LangChain Tools 让 LLM 能够实现工具调用，但并没有真正解决 LLM 应用开发的高墙
OpenAI Function Calling 只绑在 GPT 系列上
- 其调用规范、参数定义和返回格式都深度耦合在 OpenAI 的 API 流程中，无法扩展到其它开源或私有模型
LangChain Tools 支持多种模型和工具，但所有能力都要写在 LangChain 框架里面 - Spring AI
JSON-RPC 作为通用远程调用协议，轻量却太过底层 - 只关心发送请求和接收响应
- 不包括 - LLM 的上下文管理、并发会话、流式返回、能力发现等
- 并没有形成面向 LLM + Agent 协作的统一、可插拔、开箱即用的接口规范

MCP 在 JSON-RPC 之上，为 LLM 量身定制

Key	Value
统一工具描述	所有能力用同一份 tool.json 注册，LLM 只按名字 call 即可
会话与权限	自动管理多轮对话状态、工具访问权限和鉴权流程，LLM 无需关心鉴权细节
流式与事件	内建流式数据返回、异步回调和事件订阅，让长任务、实时监控、异步通知都能自然融入推理过程
多层传输	即可跑 HTTP/REST、也可以挂 WebSocket、RPC 或 MQ，灵活适配不同的部署场景

MCP - 模型想用什么工具干啥 - LLM 专注于决策，开发者专注于业务逻辑

MCP 的统一接口让开发者无需为每个场景定制协议，显著降低了工程化成本 - 只需要保留核心决策和业务流程

A2A 协议的职责

Key	Value
统一协议	所有 Agent 均使用同一个消息 schema 进行能力发现与调用
异步协作	支持流式与异步返回，可并发处理多任务
灵活扩展	新 Agent 即插即用，无需额外适配器
解耦实现	Agent 专注业务，底层传输、鉴权、错误处理由协议层统一管理

A2A 协议是一种开放标准，用于让不同平台和框架下的 AI 智能代理能够实现无障碍地信息交换和协作
技术上说
- A2A 通过标准化的组件（如 Agent Cards ）为 Agent 间的相互发现与握手提供了通用语言
- A2A 在 JSON-RPC、HTTP/SSE 等底层传输之上，定义了能力发现、会话管理、任务生命周期管理、消息与内容单元、权限认证、流式与事件等语义
- 使得多 Agent 能够灵活拼接、异步协作，并且具备企业安全与可扩展性
A2A 支持长时任务、多模态协作（文本、图像、音视频），并强调企业安全性
与 MCP 的资源管理结合，A2A 使 Agent 能够动态协商任务分配，实时共享数据洞察
- 一个基于 CrewAI 的客服 Agent 可以通过 A2A 的 LlamaIndex 驱动的知识检索 Agent 协作，共同完成客户问题的精准解答