白话A2A
暴论：mcp，a2a发展到后面，本质是一回事，现在出现a2a是mcp刚起步，发展很不成熟；且谷歌想要标准制定权。毕竟无论是MCP还是A2A都是人定的标准，当系统复杂起来之后，两者会无限趋同 首先以一个简单的例子说明现在意义下的MCP和A2A 1）MCP (Model Context Protocol) - “工具箱协议” 简单来说：MCP就像是给AI配备了一个标准化的工具箱，让AI知道如何正确使用各种工具。 AI需要查天气时，MCP告诉它：“去这个网址，用这种格式请求，你会得到这种格式的天气数据” AI需要计算时，MCP说：“这个计算器接受这些数字格式，会返回这种结果” 2）A2A (Agent-to-Agent Protocol) - “AI之间的电话标准” 简单来说：A2A是让不同AI之间能够直接对话的标准，像不同国家的人用英语交流。 想象你(用户)需要规划一次旅行。你不必分别问导游AI路线、问天气AI天气、问餐厅AI美食推荐… 有了A2A，你只需告诉一个主AI：“帮我规划巴黎三日游” 然后，旅游AI会自动"打电话"给天气AI获取天气预报，“打电话"给餐厅AI获取美食推荐，“打电话"给地图AI规划最佳路线…最后把完整计划呈现给你。 笔者揣测：【是不是很像强大版的MCP…MCP请求的server可以是一个简单的工具，也可以是app，更可以是AI啊。】 关键区别： MCP：让AI知道如何使用工具（天气API、计算器等） A2A：让AI知道如何与其他AI交谈（不必共享代码、记忆或资源） 接下来开启正文：Google定义的A2A是啥？ A2A系统中存在三个大的主体，用户，客户端（client|host），服务器（server，remote agent），各自，以及相互之间交互都定义了一套标准。 客户端： 就是一个主控。用于与 A2A 服务器（Agent）进行交互。负责接收用户请求、制定具体任务，并向远程代理提出需求，任务分发，接收响应。简单来说，就是知道什么Agent有什么能力，实现任务委派（支持异步执行）和结果整合。众所周知，Agent操作一次往往时间很长，因此在任务委派之后还会有个状态管理，时不时看一眼Agent结果返回了没有，要不要舍弃这次任务。既然是Agent，就应该是面向各种场景，流式非流式，传递各种类型的内容（文本、数据、文件），等等这些都需要规定标准。此外，还有维护会话状态和上下文等等脏活累活。从以上描述来看，往深了做，就是一个超级无敌复杂的系统。 服务器：可以简单理解为各类部署好的Agent。各类Agent需要遵循一套结构化模式。 以下简单展示Agent server的标准化定义结构。主要是Agent标准化定义+任务管理（怎么接受，怎么响应，应对流式请求…）。 客户端-服务器之间的交互：最简单就是一个json传来传去，此处采用JSON-RPC 2.0协议。往深了做，又是各种场景的优化。 JSON-RPC 2.0简单语法： --> 发送到服务器的数据 <-- 发送到客户端的数据 使用位置参数的 RPC 调用： --> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} <-- {"jsonrpc": "2.0", "result": 19, "id": 1} --> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2} <-- {"jsonrpc": "2.0", "result": -19, "id": 2} 使用命名参数的 RPC 调用： --> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3} <-- {"jsonrpc": "2.0", "result": 19, "id": 3} --> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4} <-- {"jsonrpc": "2.0", "result": 19, "id": 4} 客户端-服务器之间信息传输的一个例子： 总结：LLM发展到现在，可以开始畅想Agent盛宴了。任何Agent在任何场所调用任何工具，有一个统一的标准会很好，于是有了MCP。任何人想要在任何场所任何环境调用任何Agent，于是又了A2A。但其实无需纠结谁是谁，无需纠结两者有没有重叠。因为在我看来都一样，就是我更好得解决问题的一种方式罢了。统一度量衡注定是有深远价值的。