MCP和A2A协议的最小化实践
本章我们将通过MCP和A2A协议的最小化调用流程，来说下MCP协议和A2A协议的使用方式。
不过在此之前，我们先说下，在没有MCP和A2A之前，我们如何使用大模型
首先是RAG工程，虽然大模型具有大量的知识，且推理能力非常之强，但是在现实世界之中，数据仍然在不断地更新，而且很多数据也只存在于企业内部。这时候就需要使用RAG作为检索增强生成上场的时刻。
RAG支持将LLM和外部数据源相结合，利用向量的相似程度，来检索数据，识别用户查询相关信息，从而加入到上下文中，并根据上下文信息进行响应。
其增强了LLM对于知识的使用能力，但是其没有增强大模型的行动能力，也就是大模型只能进行简单的问答，没有办法帮助用户进行操作，也就是进行实际的方案执行。
因此Agent模型应运而生，利用COT思考链或者诸如Function Calling的方式将LLM和工具集成进来。
其让大模型支持使用工具，并采用如下的链路进行工具使用
1.理解需求，规划方案 –> 2.依次调用工具 –> 3.获取工具结果 –> 4.反复思考，反复执行2和3步骤 –> 5.呈现结果。
利用诸如Function Calling或者Anthropic的Tool Use，实现了大模型调用工具的方案。
现在，业界由上面的两个协议发展出了MCP协议。
其支持AI去连接不同工具，提供了一个标准的诸如Type-C的接口，不同工具以相同方式和LLM进行集成。
现在Agent可以一方面使用RAG，且RAG支持使用SessionMessage协议和工具发现机制，让其无缝接入多源数据检索。且提供了标准化的工具调用接口和结果回传格式，在Agent中还可以支持接入多种工具。
这里我们以Cursor+DuckDB为例，说下如何使用MCP
Cursor是一个标准的MCP Client，其驱动Claude或者其他模型进行模型交互。
而DuckDB是一个线上的数据库，其暴露了相关MCP交互的JSON，并准备了一个online的MCP Server。方便我们以最简化的方式演示MCP Server
这里我们直接进行演示，首先我们在知道了DuckDB是做什么的，之后就可以进入Github中查看https://github.com/motherduckdb/mcp-server-motherduck，其提供了MCP配置说明。
|
{
“mcpServers”: { “mcp-server-motherduck”: { “command”: “uvx”, “args”: [ “mcp-server-motherduck”, “–db-path”, “md:”, “–motherduck-token”, “<YOUR_READ_SCALING_TOKEN_HERE>”, “–saas-mode” ] } } } |
在获取到这个JSON样本之后，就可以在Cursor的客户端，通过选择MCP进行配置
复制并配置到mcp.json文件中
|
{
“mcpServers”: { “mcp-server-motherduck”: { “command”: “uvx”, “args”: [ “mcp-server-motherduck”, “–db-path”, “md:”, “–motherduck-token”, “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InRvaHVhbmdqaWFAZ21haWwuY29tIiwic2Vzc2lvbiI6InRvaHVhbmdqaWEuZ21haWwuY29tIiwicGF0IjoiLUFvRmlRcE9xREZNb05sVFdwZzJha28yMDNnc0tkM3VyMXhBeHRKS3phZyIsInVzZXJJZCI6ImU0ZmUwZTYxLTgxMDEtNDdlZC05OGNhLTJmNGQ2MjZkYTUxYyIsImlzcyI6Im1kX3BhdCIsInJlYWRPbmx5IjpmYWxzZSwidG9rZW5UeXBlIjoicmVhZF93cml0ZSIsImlhdCI6MTc0Nzc0MTUxOX0.kmAvQ2AllpYo9UdotsqaysLHfe_yU51EeOpXYd85bkc” ] } } } |
之后，将数据提前上传到云端，就可以通过Cursor进行使用了
在对话页面之中 通过输入文本进行对话
调用mother dock来进行数据分析，查找年度的图书销量
这就是一个简单的MCP协议的使用和测试。
那么进入到第二part
这一部分，我们会说如何让不同供应商和不同框架下的Agent彼此进行通信协作。这一全新协议就是Google的Agent-to-Agent协议。
Agent2Agent是为了让不同平台，不同厂商，不同操作层上的Agent可以动态发现，调用并协同完成复杂任务。
在A2A协议内部，存在着五大核心设计原则，
分别是拥抱Agent能力，
允许Agent互成黑盒，无需向着对方暴露隐私
基于现有的标准，
基于现在的HTTP，SSE，JSON-RPC 技术上哦古剑
企业级安全，
内置授权机制
多模态无差别，
支持文本，音频，视频等交互形式
长任务支持，
支持长时间的长任务需求，可以实时反馈状态。
在此过程中，A2A定义多个不同的角色
- 用户 最终用户，来使用Agent完成任务
- 客户端 代表用户向着远程Agent发送请求
- 远程Agent，作为A2A服务器的黑盒Agent
在这一点，MCP和A2A协议有一定的不同，即远程也是一个具有一定决策功能的Agent
而且远程接收方，可能不支持是一个单一Agent，而是一个智能体组。这个智能体组可以基于LangGraph框架实现，诸如AutoGen或者CrewAI框架实现。
那么我们看下A2A协议内部交互时的核心对象
主要由Agent Card、 Task、 Artifact、 Message四部分构成
对于Agent Card，这是Agent 的名片
每一个支持A2A的远程Agent需要发布一个JSON格式的Agent Card，描述这个Agent的能力和认证机制，Client可以通过这些信息选择最合适的Agent完成任务。
|
{
“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”] } ] } |
上面就是谷歌地图的Agent的Card
其次是Task
代表着一个任务，内部包含着状态，历史记录和结果。
对于状态，包含 submitted，working，input-required， completed，canceled， failed，unknown
Artifact
是指的远程的Agent返回的结果，可以包含多个部分，比如文本，图像
Message
用于Client和Remote Agent
包含指令，状态更新等内容，也可以包含多个parts，传递不同的类型内容。
具体的流程为
- 能力发现，每个Agent通过Agent Card，在Server上注册自己
- 任务管理，客户端通过task，驱动Agent，完成一个task
- 消息协作，双方互发消息，携带上下文，用户指令和中间产物，也就是传递多个parts
- 状态同步，同步双方状态，确保用户查看最新状态
这里以一个查找候选人的场景为例
- 首先用户在界面下向自己的Agent发起查找候选人的请求
- 然后Client端的Agent根据Card获取到诸如简历搜索Agent，技能筛选Agent等多个Agent
- 处理完成返回名单交由Client Agent汇总展示
就目前来说，A2A作为Google推出的当家花旦，也是在和多个不同公司一同，共建A2A生态，未来预计将在开源社区中逐步完善落地。
总结一下，我们简单说了下A2A和MCP的内部详情和基本使用。
通过这种架构，最终实现了相互协同。实现了Agent和工具的交互，Agent和Agent 的交互。