声明

大模型应用工程化过程的三大难题

大模型尽管可以作为智能系统的“核心引擎”，但大模型应用走向深水区的背景下，工程化挑战如影随形。开发者面临三大难题：

模型与外部世界的割裂

大模型是基于概率计算的新范式，其思维、推理能力类似于人脑。这种新范式虽强大，但仍需要与传统的结构化计算范式相结合，也就是通过工具调用来完成精确任务。而目前传统结构化工具和大模型之间是割裂的，大模型难以直接、动态地接入实时数据、数据库或企业工具。传统的 API 调用方式零散且不标准，导致开发效率低下。

Agent协作的孤岛效应

AI Agent 的兴起让“做事”的智能体成为可能，但不同框架（如 LangGraph、AutoGen、CrewAI）各自为政，缺乏统一的通信标准，跨平台协作如同“鸡同鸭讲”。

复杂场景的工程化瓶颈

从搜索助手到企业知识中台，RAG（检索增强生成）与多 Agent 系统需要处理多源数据、多模态交互和长时任务，现有工具链难以提供统一的解决方案。

就在此时，MCP 和 A2A 应运而生，恰如涓涓细流汇聚成江河，为“模型主控、客户端驱动”的范式提供了标准化、可扩展的协议层。它们解决了上述痛点，为大模型应用的工程化铺平了道路。

MCP：模型主控, 客户端驱动

Model Context Protocol(MCP)翻译成中文是模型上下文协议."模型", "上下文"和"协议"这三个词我们每个都认识, 拼在一起就显得有点故弄玄虚.

其实, MCP就是一个为大模型更方便的利用外部资源(主要是工具)而设计的标准化接口, 旨在打破模型与外部数据, 工具之间的壁垒.

传统上, 将AI系统连接到外部工具需要集成多个API.每个API集成都意味着单独的代码, 文档,身份验证方法, 错误处理和维护.这些API就像一扇扇独立的门, 每扇门都有自己的钥匙和规则.

它是一个客户端 - 服务器的架构，其核心理念是“模型主控、客户端驱动服务器调用”——模型负责推理和决策，客户端则动态提供上下文、工具和资源，而这些工具和资源则由外部服务器来提供。

MCP 客户端整合了各种外部服务器资源，可以在需要时进行调用图源 https://norahsakal.com/blog/authors/norah/

A2A: Agent间的"通用语言"

Agent-to-Agent，翻译过来就是“智能代理之间的协议”，听起来又是一个高大上的名词，但本质上讲，它其实就是让不同的智能代理（Agent）能够无障碍地沟通和协作的标准语言。可以把它理解成大模型 Agent 们用来“聊天”的“通用语言”。

Agent 与 Agent 之间的交互，和人类之间的沟通有点类似：不同的人会有不同的能力，每个人只能做自己擅长的事情，但为了共同完成一项任务，必须不断地交换信息、共享知识、甚至协同合作。我们人类解决复杂问题时，会分工明确、相互协作；大模型时代的 Agent 们亦如此。但问题在于，不同的开发者、公司和团队可能会创造出各种各样的 Agent，如果每个 Agent 都有自己的一套沟通方法，那必然是鸡同鸭讲，造成混乱不堪的局面。

于是，A2A 协议应运而生了：它定义了一套清晰、标准的沟通方式，让所有智能代理可以顺畅地交流彼此的需求、能力、决策和状态。Agent 们通过 A2A 沟通，就像大家都学会了同一种语言，不管来自哪个“国家”，都能顺畅无阻地交流、互相配合完成任务。

A2A 通过标准化的组件（如 Agent Cards）为 Agent 间的“相互发现与握手”提供了通用语言。它在 JSON-RPC、HTTP/SSE 等底层传输之上，定义了能力发现（通过 Agent 卡片以及标准化的能力定义）、会话管理、任务生命周期管理、消息与内容单元（Part）、权限认证、流式与事件等语义，使多智能体系统能够灵活拼接、异步协作，并具备企业级安全与可扩展性。

此外，A2A 支持长时任务、多模态协作（文本、图像、音视频），并强调企业级安全性，如 OpenAPI 授权和角色访问控制。与 MCP 的资源管理结合，A2A 使 Agent 能够动态协商任务分配，实时共享数据洞察。例如，一个基于 CrewAI 的客服 Agent 可以通过 A2A 与 LlamaIndex 驱动的知识检索 Agent 协作，共同完成客户问题的精准解答。

MCP与A2A: 相似点与不同点

大模型开发范式

RAG和Agent是大模型应用开发的目前最常用也最通用的2个范式

而有了 MCP 协议，无论是 RAG，还是 Agent+Tool Calls（或称 Function Calling），这两个大模型应用开发的关键范式，都将得益于 MCP 提供的工具发现和主动调用能力。

对于 RAG 来说，MCP 通过定义统一的 SessionMessage 协议和工具发现机制，使 RAG 能够无缝接入多源数据检索，只需一次集成即可动态检索并注入上下文，大幅提高了检索增强生成的准确性和可维护性。同时，MCP 为 Agent 提供了标准化的工具调用接口和结果回传格式，让大模型可以自主选择、分步调度各类工具执行复杂任务，无需手动注册或编码集成。这将显著提升 Agent 应用的开发效率和扩展能力。

最后结合A2A:

A2A的5大核心设计原则

第一是拥抱 Agent 能力：A2A 不仅仅是将远端 Agent 视为工具调用，而是允许 Agent 以自由、非结构化的方式交换消息，支持跨内存、跨上下文的真实协作。与此同时，Agent 无需共享内部思考、计划或工具，因此 Agent 相互之间成为黑盒，无需向对方暴露任何不想暴露的隐私。

第二是基于现有标准：在 HTTP、Server-Sent Events、JSON-RPC 等成熟技术之上构建，确保与现有 IT 架构无缝集成。

第三是企业级安全：A2A 内置与 OpenAPI 同级别的认证与授权机制，满足企业级安全与合规需求。

第四是长任务支持：除了即时调用，还可管理需人机环节介入、耗时数小时甚至数天的深度研究任务，并实时反馈状态与结果。

第五是多模态无差别：不仅限于文本，还原生支持音频、视频、富表单、嵌入式 iframe 等多种交互形式。

A2A协议的角色

A2A 协议定义了三个角色。

用户（User）：最终用户（人类或服务），使用 Agent 系统完成任务。

客户端（Client）：代表用户向远程 Agent 请求行动的实体。

远程 Agent（Remote Agent）：作为 A2A 服务器的“黑盒”Agent。

需要注意的是，在 A2A 框架中，客户端（Client）通常也是一个具有一定决策能力 Agent。它代表用户行事，可以是应用程序、服务或另一个 AI Agent，负责选择合适的远程 Agent 来完成特定任务，管理与远程 Agent 的通信、认证和任务状态。

而远程 Agent（Remote Agent）则是执行实际任务的 Agent，作为“黑盒”存在，提供特定领域的专业能力，通过 AgentCard 声明自己的技能和接口，保持内部工作机制的不透明性。这种设计使得 A2A 成为一个真正的 Agent-to-Agent 协议，而不仅仅是客户端 - 服务器架构的变种。

在实际应用中，我们可以看到多个 Agent 形成的网络，其中一个 Agent 可以同时是某些交互中的 Client，又在其他交互中作为 Remote Agent。例如，一个负责旅行规划的 Agent 可能作为 Client 向地图 Agent、酒店预订 Agent 和航班查询 Agent 发送请求，然后整合这些信息为用户提供完整的旅行方案。这种灵活的角色设计使得 A2A 协议能够支持复杂的 Agent 生态系统，实现 Agent 之间的专业分工和协作。

A2A协议的核心对象

A2A 协议设计了一套完整的对象体系，包括 Agent Card、Task、Artifact 和 Message。它们用于实现不同 Agent 之间的高效协作，这些核心对象相互配合，共同构成了 A2A 的通信框架。

Agent Card

每个支持A2A的远程Agent需要发布一个JSON格式的"Agent Card", 描述该Agent的能力和认证机制.Client可以通过这些信息选择最适合的Agent来完成任务.

我们来看看一个典型的Agent Card长什么样:

{
  "name": "Google Maps Agent",
  "description": "Plan routes, remember places, and generate directions",
  "url": "https://maps-agent.google.com",
  "provider": {
    "organization": "Google",
    "url": "https://google.com"
  },
  "version": "1.0.0",
  "authentication": {
    "schemes": "OAuth2"
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/html"],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "route-planner",
      "name": "Route planning",
      "description": "Helps plan routing between two locations",
      "tags": ["maps", "routing", "navigation"],
      "examples": [
        "plan my route from Sunnyvale to Mountain View",
        "what's the commute time from Sunnyvale to San Francisco at 9AM"
      ],
      "outputModes": ["application/html", "video/mp4"]
    }
  ]
}

Task

是Client和Remote Agent之间协作的核心概念.一个Task代表一个需要完成的任务, 包含状态/历史记录和结果.

Task的具体状态列表如下:

submitted（已提交）
working（处理中）
input-required（需要额外输入）
completed（已完成）
canceled（已取消）
failed（失败）
unknown（未知）

Artifact(成果)

Artifact 是 Remote Agent 生成的任务结果。Artifact 可以有多个部分（parts），可以是文本、图像等。

Message(消息)

Message 用于 Client 和 Remote Agent 之间的通信，可以包含指令、状态更新等内容。一个 Message 可以包含多个 parts，用于传递不同类型的内容。

A2A协议工作流程

接下来，我们通过 A2A 协议的工作流程和具体示例，来展示这些对象如何协同工作，完成 Agent 之间的对话。

A2A 协议的典型工作流程如下：

能力发现：每个 Agent 通过一个 JSON 格式的 “Agent Card” 公布自己能执行的能力（如检索文档、调度会议等）。
任务管理：Agent 间围绕一个 “task” 对象展开协作。该对象有生命周期、状态更新和最终产物（artifact），支持即时完成与长跑任务两种模式。
消息协作：双方可互发消息，携带上下文、用户指令或中间产物；消息中包含若干 “parts”，每个 part 都指明内容类型，便于双方就 UI 呈现形式（如图片、表单、视频）进行协商。
状态同步：通过 SSE 等机制，Client Agent 与 Remote Agent 保持实时状态同步，确保用户看到最新的进度和结果。

下面用一个简单的例子展示 A2A 协议的基本请求 - 响应流程：

Client 发送任务

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tasks/send",
  "params": {
    "id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "请分析下面5位候选人是否符合岗位需求，并推荐最佳人选。"
        }
      ]
    },
    "metadata": {}
  }
}

Remote Agent响应

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
    "sessionId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
    "status": {
      "state": "completed"
    },
    "artifacts": [
      {
        "name": "result",
        "parts": [
          {
            "type": "text",
            "text": "第二位候选人最符合你的需求!"
          }
        ]
      }
    ],
    "metadata": {}
  }
}

以“招聘候选人搜寻”这个应用场景为例：

用户在统一界面下向自己的 Agent 发起“寻找 XX 岗位候选人”请求。
Client Agent 根据岗位需求调用简历检索 Agent、技能筛选 Agent 等多个 Remote Agent。
各 Agent 协同返回候选人名单（artifact），并由 Client Agent 汇总、展示。
后续可继续调用“面试安排 Agent”“背景调查 Agent”，形成端到端招聘流程自动化。

A2A 协议中，Agent 之间除了基本的任务处理外，A2A 还支持流式响应，使用 Server-Sent Events（SSE）实现流式传输结果；支持 Agent 请求额外信息的多轮交互对话和长时间运行任务的异步通知，以及多模态数据，如文本、文件、结构化数据等多种类型。

A2A的生态与未来

A2A 是 Google 在大模型应用开发的关键节点推出的关键协议，充满了强行卡占生态位的意味。自从 Transformer 的论文发布以来，Google 作为 AI 浪潮的一贯引领者和开拓者，起了大早，赶了晚集，2023 年以来被 OpenAI 和 Anthropic 等一众小弟远远甩在身后，因此此时此刻的 A2A 绝对不容有失。

目前，Google Cloud 已联手 50 多家技术与服务伙伴（包括 Atlassian、Salesforce、MongoDB、Accenture、Deloitte 等），共建 A2A 生态。未来预计将在开源社区中逐步完善规范，并推出生产级实现，推动异构 Agent 在企业级场景中的深度互操作，助力跨系统、跨组织的智能协作大规模落地。

小结

大模型没有自主完成现实任务, 所以出现Agent, 而各大Agent各自为政, 没有统一的规范, MCP应运而生.
MCP 提供了统一的上下文管理与工具调用接口，整合了大模型驱动的概率计算与传统工具驱动的结构化计算。A2A 则为多 Agent 协同注入了开放标准。
A2A 和 MCP 的互补关系：

MCP: 提供垂直集成，将代理连接到工具和资源。
A2A: 提供水平通信，将代理连接到其他代理。

Google A2A 协议中的 Agent 跨越了“组织或技术边界”（Organizational or technological boundaries），这表明这些 Agent 系统可能属于不同的组织或建立在不同的技术栈上，但它们仍然可以通过标准化的 A2A 协议有效地通信。这种架构使得不同厂商、不同技术框架开发的代理能够维持自己的内部实现细节，同时实现互操作，这正是 A2A 协议的核心价值主张之一。这是 A2A 协议的重要特点，它实现了真正的 Agent 到 Agent 的通信模式。

MCP底层架构

MCP协议层(Protocol layer)详解

MCP架构中的Host, Client和Server

在 MCP 架构中，“Host” 指的是最终承载大模型和用户界面的应用，比如桌面端的 Claude 客户端、IDE 插件或自研的聊天机器人后台。一个 Host 启动时，会在内部创建一个 MCP Client 实例，这个 Client 负责与外部的 MCP Server 建立一对一的连接（通常通过 stdio、HTTP+SSE 或其他支持的传输层）。

接入层面的 “Client” 正是这个 MCP 客户端，它把上层业务或大模型交互中产生的“请求”（例如“列出可用工具”“执行代码分析”）打包成符合 JSON-RPC 2.0 的消息，再通过底层传输通道发给 Server；同时，它也能接收来自 Server 的 Notification（如“工具状态更新”），并把所得数据交回给 Host，以便拼接到模型的 Prompt 中或做二次处理。

而 MCP “Server” 则是真正提供上下文内容和工具执行能力的进程或服务。它在启动时会注册一系列接口（Resource 列表、工具调用、文件系统访问、外部 API 调用等），并监听来自 Client 的 JSON-RPC 消息。当收到“调用某个工具”这样的请求时，Server 会校验参数、调用相应逻辑，将结果封装成 Result 消息回传；如果出现异常，则返回带有标准错误码（如 ParseError、InvalidParams、MethodNotFound）的 Error 响应。

整个交互流程可以分为三个阶段。

握手初始化：Host 的 MCP Client 向 Server 发起 initialize 请求，双方交换协议版本与能力列表，并用 initialized 通知确认；
正常通信：Client/Server 可双向发起 Request–Response（同步调用）或单向 Notification（异步事件），大模型应用只需按需调用 Client 的接口；
优雅收尾：通信完成后，任意一端可调用 close() 或因底层通道断开而触发连接关闭。

在上面的 MCP 连接生命周期中，Client 和 Server 之间可以传递下列类型的 MCP 消息类型：

Request：期待收到响应。
Result：请求成功的响应。
Error：请求失败时返回。
Notification：单向消息，无需响应。

通过这种分层设计，MCP 将“业务逻辑”与“上下文 / 工具管理”解耦：Host 只管“我需要哪些信息 / 能力”；Server 负责“我怎样取到或实现这些能力”。最终，在 Host 内部，大模型得到的不再是死板的 API 返回值，而是经过精心组织的上下文提示，能够更灵活、更安全地调用外部工具、访问数据源，这样就扩展了大模型能力，让它可以对接更多复杂场景。

MCP协议交互流程

MCP协议传输层(Transport layer)详解

MCP的传输方式

MCP 支持多种传输方式以适配不同场景：

Stdio: 这是最轻量的 stdio 通道，借助标准输入 / 输出即可完成同机进程间的双向通信，适合本地进程间的通信。
HTTP+SSE: 基于 HTTP 的单向推流与单向发送组合（SSE + POST），适合浏览器前端与微服务后端的分离部署。服务器端使用 Server-Sent Events 推送消息给客户端。客户端通过 HTTP POST 发送请求。
Streamable HTTP: 更完善的 Streamable HTTP 场景中，POST 请求能返回 JSON 或切换到 SSE 流，在同一路径上混合使用 HTTP POST（发送请求）和 SSE（接收流式响应），支持 mcp-session-id 会话管理、断点续传以及 JSON/SSE 混合响应。
Websocket: 基于 WebSocket 全双工通道，建立后客户端和服务端都可以随时推送 JSON-RPC 消息。适合低延迟、高频率的实时双向交互，以及真正的全双工 WebSocket 通道，为低延迟、高频双向交互提供最佳性能。

所有传输都遵循 JSON-RPC 2.0 格式，无论选哪一种，Host 启动时都会分别构造 ClientSession 和 ServerSession，将它们的读写流对接到相应的底层通道——本地时可把一端的 stdout 连到另一端的 stdin，远程时则通过 HTTP 或 WS 长连接互联。

如果觉得文章对你有用，请随意赞赏

人工智能(5): MCP

http://blog.yan.cpolar.cn/archives/mcp

作者

yanwei

发布于

2025-08-25

更新于

2025-08-26

许可协议

CC BY 4.0